Windows to Linux porting library Linux Library

Porting a Windows application to Linux can be easier than you expect .

Windows to Linux Porting Library

Are You looking for linux equivalent functions to Windows critical sections, threads, handles etc. Well, here you found it!

Porting Windows applications to Linux can result to an unpredictable time consuming process especially with OS dependend task like threads, events, critical sections, shared libraries, INI files.

The majority of Windows applications were developed without considering the need to port them ever to Linux or at least in the near future. For some Windows applications porting them to Linux can become a porting nightmare. Using the right tools it doesn’t have to be one.

The Windows to Linux Porting Library (W2LPL) offers a Windows (WIN32 API) style API under Linux and enables a smooth port of an Windows application to Linux.

The Windows to Linux Porting Library (W2LPL) eases the transition from a Windows API application to a Linux application by offering some of the most wanted features from the Windows API inside the Linux environment e.g.

Handling of Threads
beginthread, beginthreadex, GetExitCodeThread, GetCurrentThread, GetCurrentThreadId, .

Handling of Critical Sections
InitializeCriticalSection, EnterCriticalSection, LeaveCriticalSection, TryEnterCriticalSection, DeleteCriticalSection, .

Event handling
CreateHandle, CloseHandle, SetEvent, ResetEvent, PulseEvent, WaitForSingleObject, WaitForMultipleObjects, .

Handling of profile files (INI files)
WritePrivateProfileString, GetPrivateProfileString, GetPrivateProfileInt, GetPrivateProfileSection, .

Searching for files
FindFirstFile, FindNextFile, FindClose, .

Sleep & Timing
Sleep, GetSysTime, GetElapsedTime, .

. and other helper functions.

Please also consult the manual for more details.

The Windows to Linux Porting Library (W2LPL) offers portable functions to incorporate into a Linux 32 bit or 64 bit application.

Speed-up your Windows to Linux port and create a stable Linux application by using the Windows to Linux Porting Library (W2LPL). It is already in use in known commercial developments e.g. SuperCom for Linux.

And, if your application does Serial or TCP data communications consider the many options of SuperCom, the portable data communication toolkit.

License Information

One license per developer. A site license can be used by an unlimited number of developers working for the same entity (e.g. company) within the same physical location (building or city limits).
Executables developed using the W2LPL library can be distributed royalty free. More .

Supported compilers

C, C++, Pascal, and any other compiler / language using Linux shared libraries (.so). Optionaly, a C/C++ static library can also be provided.

Supported Operating Systems

Linux 2.4 or newer and also to it compatible OS.

Q: Will this library port GUI code blocks also ?
A: W2LPL supports a function set as listed in the manual. The GUI is a huge part and W2LPL does offer any support for this.

F: no #ifdef’s ?
A: The W2LPL library enables to compile a common source code in Windows and Linux. In order to enable this equivalent functions were implemented for Linux.

F: Speed ?
A: The W2LPL library is well designed and optimized. By using ready made and matured functions the application can gain stability and under circumstances some speed advantage. But the major profit is the short path required to port a Windows application to Linux.

Windows to Linux Porting Tools — Library to easily port a Windows application to Linux — Win32 to Linux library — Port Windows Application to Linux — Critical Sections — Event Handles — Thread

Источник

Porting from Windows to Linux, part 1

Hi and welcome to a blog series about how to port graphics applications from Windows to Linux. The series will have three parts: Today, in the first part, we’ll be looking at prerequisites for porting. These are things you can do any time to facilitate porting later on, while still working on Windows exclusively. In the second part, the actual porting work will be done, and in the last part, I’ll talk a bit about the finishing touches, rough edges, and how to keep everything working. All of this is based on my experience with porting my research framework; which is a medium-sized project (

180 kLoC) that supports Linux, Windows and Mac OS X.

However, before we start, let’s assess the state of the project before the porting begins. For this series, I assume you have a Visual Studio based solution written in C++, with Direct3D being used for graphics. Your primary development environment is Visual Studio, and you haven’t developed for Linux before. You’re now at the point where you want to add Linux support to your application while keeping Windows intact – so we’re not talking about a rushed conversion from Windows to Linux, but of a new port of your application which will be maintained and supported alongside the Windows version.

Prerequisites

Let’s start by sorting out the obvious stuff: Your need a source control solution which will work on Linux. If your project is stored in TFS, now is the time to export everything to your favourite portable source control. If you are not sure what to choose, take Mercurial, which comes with a nice UI for all platforms.

Next, check all your dependencies. If you rely on WIC for image loading, you’ll have to find a portable solution first. In my experience, it’s usually easier to have the same code running on Windows and Linux later on than having a dedicated path for each OS. In my project, I wrapped the low-level libraries like libpng or libjpg directly instead of using a larger image library.

Now is also the time to write tests. You’ll need to be able to quickly verify that everything is working again. If you haven’t written any automated tests yet, this is the moment to start. You’ll mostly need functional tests, for instance, for disk I/O, so focus on those first. I say mostly functional tests, as unit tests tend to be OS agnostic. In my framework, unit tests cover low-level OS facilities like threads and memory allocators, while everything else, including graphics, is covered by functional tests.

For testing, I can highly recommend Google Test. It’s not designed for functional tests right away, but it’s very easy to write a wrapper around a Google Test enabled project for functional testing. My wrapper is written in Python and sets up a new folder for each functional test, executes each test in a new process and gathers all results.

Finally, if you have any build tools, make sure that those are portable now. I used to write them in C# when it was really new, but since a few years, I use only Python for build tools. Python code tends to be easy to maintain and it requires no build process whatsoever, making it ideally suited for build system infrastructure. Which brings us to the most important issue, the build system.

Build system

If you are using Visual Studio (or MSBuild from the command line), stop right now and start porting it to a portable build system. While in theory, MSBuild is portable to Linux using xbuild, in practice, you’ll still want to have a build system which is developed on all three platforms and used for large code bases. I have tried a bunch of them and finally settled with CMake. It uses an arcane scripting language, but it works, and it works reliably on Windows, Linux, and Mac OS X.

Porting from Visual Studio to CMake might seem like a huge effort at first, but it’ll make the transition to Linux much easier later on. The good thing about CMake is that it works perfectly on Windows and it produces Visual Studio project files, so your existing Windows developer experience remains the same. The only difference is that adding new source files now requires you to edit a text file instead of using the IDE directly, but that’s about it.

While writing your CMake files, here’s a few things you should double-check:

• Are your path names case-sensitive? Windows doesn’t care, but on Linux, your include directory won’t be found if you mess up paths.
• Are you setting compiler flags directly? Check if CMake already sets them for you before adding a huge list of compiler flags manually.
• Are your dependencies correctly set up? With Visual Studio, it’s possible to not define all dependencies correctly and still get a correct build; while other build tools will choke on it. Use the graph output of CMake to visualize the dependencies and double check both the build order, and the individual project dependencies.

With CMake, you should also take advantage of the “Find” mechanism for dependencies. On Linux, nearly all dependencies are available as system libraries, serviced by the package manager, so it definitely makes sense to link against the system version of a dependency if it is recent enough.

The end result of this step should be exactly the same binaries as before, but using CMake as the build system instead of storing the solutions directly in source control. Once this is done, we can start looking at the code.

Clean code

Did you ever #include system headers like in your code? Use system types like DWORD ? Now is the time to clean up and to isolate these things. You want to achieve two goals here:

• Remove system includes from headers as much as possible.
• Remove any Visual C++ specific code.

System headers should be only included in source files, if possible. If not, you should isolate the classes/functions and provide generic wrappers around them. For instance, if you have a class for handling files, you can either use the PIMPL idiom or just derive a Windows-specific class from it. The second solution is usually simpler if your file class is already derived from somewhere (a generic stream interface, for instance.) Even if not, we’re wrapping an extremely slow operating system function here (file reads will typically hit the disk), so the cost of a virtual function call won’t matter in practice.

To get rid of Visual C++ specific code, turn on all warnings and treat them as errors. There are a bunch of bogus warnings you can disable (I’ve blogged about them previously), but everything else should get fixed now. In particular, you don’t want any Visual C++ specific extensions enabled in headers. The reason why you want all warnings to be fixed is that on Linux, you’ll be getting hundreds of compile errors and warnings at first, and the less these are swamped by issues that are also present on Windows, the better.

While cleaning up, you should pay special attention to integer sizes. Windows uses 32-bit long s in 64-bit mode, Linux defaults to 64-bit long s. To avoid any confusion, I simply use 64-bit integers when it comes to memory sizes.

The better you clean up your code, the less work you’ll have to spend later during porting. The goal here should be to get everything to build on Windows, with platform specific files identified and isolated.

So much for today! Next week, we’ll look at how to get rid of Direct3D and how to start bringing up the code base on Linux. Stay tuned!

Источник

Porting windows application to linux

I have an application which I need to port on Linux. I was thinking to use Free Pascal the problem is the application uses Windows API’s to perform tasks such as serial port communication etc. Is there a msdn for linux users or a book covering how linux works internaly if there are apis.

I am very confused.

5 Answers 5

Well, it’s sad to say but if your code in very Windows-dependend (not VCL depended!) then probably it’ll be faster to write the application from the begining rather then porting it.

But if it’s only serial port matter then give a try to multiplatform SynaSer library, find it here: http://synapse.ararat.cz.

Robert Love has a book on Linux Systems Programming — that will cover this area and Love’s books are generally good, so it is worth looking at.

It’s not entirely clear from your question, but if your concern is that there are specific calls to hardware controlling functions in your Windows application that make it difficult to port I would suggest that is a misplaced fear. Both Windows and Linux operate on the principle that the application level programmer should be kept away from the hardware and that all that should be handled by the operating system kernel and only be accessible to applications via system calls. As the kernels of different operating systems face similar demands from users/applications, they tend to have system calls that do the same sorts of things. It is necessary to match the system calls to one another but I can see no reason why that should be impossible.

What may be more troublesome is that your Windows application may rely heavily on the Windows executive’s windowing code/API. Again finding analogues for your code is not impossible but is likely to be a bit more complex e.g. in Linux this stuff is generally not handled in the kernel at all (unlike Windows).

But then again, your code may be written against a portable toolkit/library like Qt which would make things a lot easier.

Источник

Windows2Linux Porting

Recently I faced one very interesting task. I had to port an application from one platform (Windows) to another (Linux). It is an interesting topic. First, knowledge of several platforms and writing the code for them is a good experience for every developer. Secondly, writing an application for different platforms makes it widespread and needed by many. So, I would like to share my impressions concerning this process. This article is intended for everybody who wants to write a cross-platform application.

Our task

Receiving the project specification, we usually see only one target platform in the “Platforms” section (e.g., Windows) and that is why we enjoy its advantages and disadvantages. Let’s imagine that you receive the task where it is proposed to run the application on the other platform (e.g., Linux). Or imagine that you have to use the code, which was written for one platform, on another platform. From this point you start to face difficulties. You start to plan the porting taking into account all the specifics of the program architecture. And if the architecture was wrong from the very beginning (I mean that it did not expect the porting between the platforms), it can turn out that you have to remake a lot. Let’s examine the example of the code (file attached to this article). This program opens the PhysicalDrive0 , acquires MBR and writes it to the file, then defines the disk configuration and saves it to a separate file. The code was written only for Windows with all its consequences.

Please look at the code before reading the article (BackupMBR_win.zip attached to this article). This is the project of VisualStudio2008.

There must be no difficulties in such small example. But you can meet problems even here. The code is very simple and does not require many checks, deletion processing, etc. This code is not a standard but it lets to show what you should do during the porting of your application from Windows OS to Linux OS.

Compilers and IDE

When porting from Windows OS to Linux OS is performed, the porting from Microsoft Visual C++ to GCC(G++) is the most commonly used. Many of you may think that GCC and G++ are two different compilers. But it is not so. GCC («GNU C Compiler») was created in 1987 by Richard Stallman and it could compile only C code at that time. With time the compiler developed and supported not only C and C++ codes but also other programming languages. Now the GCC is interpreted as «GNU Compiler Collection». G++ is a part of GCC and is used to compile *.cpp files. GCC is used, in its turn, to compile *.с files. Though, you can compile the *.cpp file using GCC by indicating specific flags. GCC and G++ compile the C++ code in the same way.

Let’s return to the porting from Visual C++ to GCC (G++). It is worth paying attention to the difference between them. GCC is stricter to the standard than the Microsoft compiler. It means that in some situation the GCC compiler returns an error message and does not compile the source code while the Microsoft compiler just returns the warning message. Let’s examine some moments that are frequently met during the porting from Visual C++ to GCC. You can google it but I would like to repeat it myself.

1. Use #ifndef/#define/#endif instead of #pragma once. GCC understands the #pragma once directive beginning from the version 3.4. That is why check the version of your compiler. If it is lower than 3.4, there is no need to correct the following code during the porting.

1. Used types. During the porting, watch the types you use because GCC doesn’t understand all of them. It is better to create a separate file in the project (e.g., types.h file) and to put there all types that GCC does not understand.

1. Assembler insertions. Be careful during the porting of ASM insertions to the project for GCC. They have another appearance and syntax. GCC uses AT&T ASM. It differs from Intel ASM, which is used in Visual C++. An example is provided below (the following example is taken from http://asm.sourceforge.net//articles/linasm.html; for more information about AT&T ASM also see this reference).

mov al,bl
mov ax,bx
mov eax,ebx
mov eax, dword ptr [ebx]

movb %bl,%al
movw %bx,%ax
movl %ebx,%eax
movl (%ebx),%eax

P.S. For conversion, you can use the Intel2gas utility (see http://www.niksula.hut.fi/

mtiihone/intel2gas/). But to my opinion, it is more convenient only for the high volume of the ASM code. And anyway you should bring the code to the compilable state.

1. Using the #pragma comment directive (lib, «libname.lib»). It is convenient to hook libraries in the project with the help of this directive in Visual C++. But GCC does not contain such one. That is why, for GCC, you should define the libraries you want to hook in the command line. For example:

As you can see, Linux libraries have *.a extension and not *.lib extension as in Windows OS. Dynamic libraries also have another extension (*.so instead of *.dll) and they link not in such way as in Windows OS. For more information about the types of libraries in Linux OS see http://www.yolinux.com/TUTORIALS/LibraryArchives-StaticAndDynamic.html.

You can learn more about how to hook DLL function in Windows from another our article.

1. Macros. Macros in GCC differ from the analogous ones in Visual C++. During the code porting to GСС, check the macros in the code. It’s possible that the implementation of such macro will not be performed. In such situation, it is better to find its implementation in Visual С++ and port it to GCC. The following table provides examples of frequently used macros.

Let’s examine them. The first six macros are implemented in both compilers in the same way and are often used in logging. The differences begin from __FUNCTION__ . In Windows OS, it writes not only the name of the function (as in Linux OS) but also the namespace and the class from where the call was performed. Its analog in Linux OS is not __FUNCTION__ but __PRETTY_FUNCTION__ . MSC_VER and __GNUC__ / __GNUC_MINOR__ / __GNUC_PATCHLEVEL__ also have different types of returned data. For example, MSC_VER = 1500 for Visual C++, for GNU 3.2.2 it is __GNUC__ = 3 , __GNUC_MINOR__ = 2 , __GNUC_PATCHLEVEL__ = 2 .

If the target platform does not include the needed macro, find its implementation and port it. Macro can be also written in ASM (for the code optimization). Do not hurry and rewrite it from Intel to AT&T and vice versa. It is better to check once more if there is its implementation in С++. Also take into account that Linux OS can run on devices with ARM processor. In this case the macro, which was written under AT&T, will not work and you will have to implement it under another type of the processor.

Let’s move to IDE. There are lots of them and you have the possibility to choose. Let’s examine some of them (taking into account that the project was initially written in Visual Studio, our task is to choose IDE for working in Linux OS):

Pic.1 Code::Blocks. Start Page.

It is often proposed as the substitution of Visual Studio for those who port their project to Linux OS. IDE can open Visual Studio projects under Windows OS and Linux OS. I built a project with its help and I can say that it is very convenient.

It is another free IDE. If you write in C++, download it together with the CDT plug-in. After installation IDE supports only Java by default and if you install CDT plug-in after, the auto-add-on probably will not work.

Pic.3 QT Creator. Start Page

When I first worked with Linux I used this IDE. Its interface is simple (developers must have followed the example of XCode interface during the development of Qt Creator). And you do not have to use Qt while working in Qt Creator. Just configure the project using the *.pro file (in it, libraries that are statically linked, *.h and *.cpp files, the type of the application are defined).

Pic.4 Emacs. Start Page

This IDE is for experienced developers under Linux OS. The problem of this IDE is that it can take long to learn how to work with Emacs. And the skills are quickly lost, as people say. You will be able to perform the majority of commands by using hot keys or the Emacs command line. Even while opening the file you will be asked to define the file path in the command line. But on the other hand, this tool is very powerful and flexible.

I introduced four IDEs that are the most popular among the developers under Linux OS. For example, I work with QtCreator but there must be no problems while working with other IDEs (do not forget about problems with Emacs). So, it is your time to choose.

I want to add a few words about the debuggers. Sometimes I did not manage to debug the code using the native IDE debugger. That is why I had to search for the alternative. I used two debuggers: Insight and kdbg. I also tried to use ddd debugger but I did not like it. So use the one you like more. With time you will find the one that will meet the maximum of your demands.

Porting of the application

Let’s return to the code we examined in the second part. As we can see in the API code, functions are used directly without the wrappers above the API level. You may say that it is not bad: errors are handled, the code works, so why not to leave it as it is? There is a reason not to leave as it is. When you port the application to another platform, there will be one more problem of searching API functions in the code and their replacement. For example, the CreateFileW function (disk opening and creation of the file from the MBR disk) is represented twice in the examined code. And the program is simple in itself. If the project is big and you do not use wrappers above the API level, the code will repeat itself a lot. And it means that you will have to change a lot during the porting to another platform.

That is why the first step is to write the library that contains all used APIs and that implements the methods of working with them. It must also contain all functions specific for the definite platform. Such library will have the necessary interface, and during the porting, you will have to make some corrections only in it.

Let’s examine the schemes that illustrate the thoughts mentioned above. The majority of developers extract the core of their application into the separate libraries (Business Logic) that implement the definite interface. Such library also implements the separate GUI that will use this very library. This is correct, convenient and also it works. But there is one nuance that we just mentioned.

There must be the Platform Compatibility Layer for the cross-platform applications. This is the component that will stand between the API level and the core of your application. It is necessary to include the following components in it:

• working with files;
• working with sockets;
• working with ports;
• ASCII/Unicode
• Threading API

Let’s start from the very beginning. Let’s try to port our application. We must define the code that will be included in the «Platform Compatibility Layer». The following table displays the comparison between Windows and Linux API.

Table 1. Comparing Linux and Windows API.

Linux API

The first function that we use is the CreateFileA function. We need it to open the device (in this case, it is PhysycalDrive0 ). We call it with the following parameters:

With the help of the first parameter we define the path of the device we are opening \\\\.\PhysicalDrive0 . In Linux OS, all devices have the format of simple files and are located in the /dev directory. There you can find the required device (it is /dev/sda device in my system). You can define the path to the device on your computer by entering the mount command in Linux terminal. This command is used for device mounting. But such command without any parameters will display all mounted devices in the system. The following example is the example of mount command for my system:

Let’s examine the first line, where:

/dev/sda1 — the path to the device file
/ — the path of the mounted filesystem
type ext3 — the filesystem type
rw — read and write permissions.

Hard drives are usually indicated as /dev/sd* and /dev/hd* in Linux OS. If the computer has three hard drives, they will be indicated as /dev/sda, /dev/sdb, /dev/sdc. The number that follows after the name of the hard drive defines the partition number on this drive. To open the disk, use the open() function.

According to the manual, this function juxtaposes the full file path with the descriptor of the file, which it returns. Descriptor is the analog of HANDLE in Windows OS. It can be used for read/write/lseek functions. If you did not manage to open/create a file, the function returns -1. Permission of file access is defined in the flags parameter. For /dev/sda, set the O_RDONLY flag (it is an analog of GENERIC_READ for CreateFileA ). For more information about flags see the manual. So, for Linux OS, the open() function will look like the following:

It is more compact than in Windows OS. Now it is necessary to write the function that will be common for Windows and Linux OS. First, let’s define how this function will look like. CreateFileA can be assumed as a basis. There are three parameters out of 7 that do not change in the program:

As these parameters have the same value, we exclude them from the target function. You may say that we limit the functionality defining one and the same value to some parameters. But we did not change them in the program, those values, which are defined, are enough for us. It means that the function performs the program minimum and can cover the functionality that we need. It is worth defining here how we use one or another API function. The minimum functionality is usually enough. But on the other hand, if we want to set the FILE_SHARE_READ value to the dwSharedMode parameter, we will hit a problem. It is not enough that we must add changes to the function, but also we will have to change the number of parameters in all its calls. That is why it is necessary to define what exactly you want, for example, from CreateFileA and how you will use it. Then it will be clear how the wrapper over this function will look like.

So, we came to conclusion that the function will have 4 parameters. Now we have to confirm them on both platforms. I will port the minimum of them: GENERIC_READ (to open the file for reading) and GENERIC_WRITE (to open the file for writing). These parameters are similar to O_RDONLY and O_WRONLY parameters for the open() function. dwCreationDisposition defines the way of opening the file. I used two values: OPEN_EXISTING (the file opens; if there is no file, the error is returned) and CREATE_ALWAYS (a new file is created; if such file already exists, it is rewritten). There are no such parameters for the open() function. The closest will be the O_CREAT parameter. This flag is used for file creation and corresponds to CREATE_ALWAYS parameter. You don’t need to use the OPEN_EXISTING value for the open() function. You may say that the FILE_ATTRIBUTE_NORMAL value of the dwFlagsAndAttributes also did not change and that we have to exclude it from the parameters. But as it was mentioned earlier, the open() function has one more mode parameter. It defines the file permission, as you remember. Let’s define the FILE_ATTRIBUTE_NORMAL = 0644 parameter (the owner of the file has read and write permissions, others only read permission). It is not right as we cannot define other file permissions but it is enough for porting our application. It is a certain support point. But it is easy to correct: we just find the value correspondence for the necessary parameters for both platforms.

We compared all parameters that are interesting for us and now can start writing the function itself. What is the process of writing? We use the #ifndef/#define/#elif/#endif preprocessor directives. We use the following construction:

By using this construction, we can single out parts of the code that are specific for a definite platform. With the help of this method you can single out not only the parts of functions but also the whole functions.

As we can see, both methods prove its value. The first one is less readable; the second one contains more code but it is easier to make changes in it. I would advise you to use the second one but it is your right to choose. As an alternative, you can separate off all to the header files.

Let’s look how the function will look like after making all changes in it:

As it can be seen from the code, we took into account everything mentioned above. The received create_io_file wrapper does not implement all the features of CreateFileA and open but it is an example of how you can implement the cross-platform wrapper above the API level. You can port the rest of functions in the same way (see file_io.h/file_io.cpp file).

Besides API, we used DeviceIOControl to receive the disk geometry. The get_drive_info() function is represented below:

There is an analog of DeviceIOControl in Linux. It is the ioctl function, which receives the device descriptor and can return the requested information about it. By calling DeviceIOControl with the IOCTL_DISK_GET_DRIVE_GEOMETRY parameter we receive the DISK_GEOMETRY structure as a result. It looks like this:

To receive the similar structure with the disk geometry in Linux, call the ioctl function with the HDIO_GETGEO parameter and reference the following structure:

Having compared the structures, we notice the absence of one of the fields. The hd_geometry structure does not contain the BytesPerSector value. This can be corrected by calling the ioctl function with the BLKSSZGET parameter, which according to Linux sources returns the block device sector size. These are the specifics of porting this function. The final variant looks like the following:

There is one more function left. It is the store_drive_geometry function but it does not require the change of the code. It can be easily ported. Such effect can be achieved by using STL (see http://cplusplus.com), boost (see http://boost.org) or Qt libraries. All these libraries are cross-platform and allow writing the easily ported code. For example, in STL, the wrapper above the API level is already implemented for the work with files and the library is already cross-platform. So pay attention to using such libraries. It can make your work easier.

Windows->Linux. A few words

We examined only one of many components from the list that change during the porting. I would like to say a few words about the rest of them.

ASCII/Unicode. Here we can meet problems because the size of the wchar_t type in Windows is twice smaller than in Linux (2 bytes in Windows and 4 bytes in Linux). The reason is that Linux uses UTF-32 character encoding and Windows — UCS-2. The difference in character encodings can be solved by setting the GCC flag during the compilation:

Attention should be paid to all char wchar_t conversions and to the use of Unicode during the transfer between systems.

Threading API. It is better to implement it using boost or Qt libraries. It means that the work with threads has many pitfalls and it will be difficult to implement everything by yourself and it will also take you too long. That is why, as I have already said, it is better to use ready solutions.

The End

I tried to represent in brief some key moments that you can face during the porting of the application from Windows OS to Linux OS. I rather managed to show how to implement cross-platform wrappers for API by giving an example. You can come to one more conclusion from the information mentioned above. During the porting of applications it is worth paying attention to the ready implementations of cross-platform libraries (such as STL, boost and QT).

Additional materials

Look through all files attached to the article.

Источник

Windows API