Share via

Port from UNIX to Win32

  • Article

When migrating applications from UNIX to Windows, there are several options:

  • Running UNIX applications on Windows NT using the POSIX subsystem

  • Using UNIX libraries to port applications from UNIX to Win32

  • Porting applications from UNIX to Win32 natively

The first option UNIX programmers look at is the Windows NT POSIX subsystem. However, it only supports POSIX 1003.1, which was the only POSIX version standardized when Windows NT was created. Since then, there has been little demand for extending this subsystem, because most applications have been converted to Win32. The 1003.1 system is of limited interest for fully featured applications, because it does not include many capabilities (such as those in 1003.2, network support, and so on). Full featured applications run under the Windows NT POSIX subsystem do not have access to Windows NT features available to Win32 applications, such as memory-mapped files, networking, and graphics. Applications such as VI, LS, and GREP are the main targets for the Windows NT POSIX subsystem.

The second option UNIX programmers normally consider is using third-party UNIX-like libraries to let their UNIX code compile as a Win32 executable. Several commercial (and at least one public domain) libraries do this. This is an option for some applications. The advantage of these porting libraries is that they minimize the initial porting effort. The main disadvantage, for a competitive software product, is that a native Win32 port of an application will generally be faster and will inevitably have more functionality. It can be awkward for the application to step outside of its UNIX shell if it needs to make Win32 calls to get more power from Windows NT.

The third option is porting UNIX applications directly to Win32. Using ANSI C/C++ libraries, and commercial C compiler libraries, many of the traditional system calls relied on by UNIX applications are available in Win32 applications.

The output model of stdio-based applications does not need to be changed, since the Win32 console APIs mimic the stdio model, and versions of cursors exist that use the Win32 console APIs.

Berkeley socket-based applications need very few changes to work as Win32 applications. The Windows Sockets interface was designed for portability with BSD sockets, with minimal changes that are noted in the introductory sections of the WinSock specification. See .

Windows NT supports DCE-compliant RPC, so RPC-based applications are easily usable. See the .

One of the largest areas of difference is in the process model. UNIX has fork; Win32 does not. Depending on the use of fork and the code base, Win32 has two APIs that can be used: CreateProcess and CreateThread. A UNIX application that forks multiple copies of itself can be reworked in Win32 to have either multiple processes or a single process with multiple threads. If multiple processes are used, there are multiple methods of IPC that can be used to communicate between the processes (and perhaps to update the code and data of the new process to be like the parent, if the functionality that fork provides is needed). See .

Windows and UNIX graphical models are very different. UNIX uses the X Window System GUI, while Windows uses GDI. Though similar in concept, there is no simple mapping of the X API to the GDI API. However, OpenGL support is available for migrating UNIX OpenGL-based applications. And there are X clients and X servers for Windows. See for information on GDI.

Basic UNIX applications, including many CGI applications, should port easily to Visual C++ running on Windows NT. Functions like open, fopen, read, write and others are available in the Visual C++ run-time library. Also, there is a one-to-one mapping between C UNIX APIs and Win32 APIs: open to CreateFile, read to ReadFile, write to WriteFile, ioctl to DeviceIOControl, close to CloseFile, and so on.