One 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 and Windows 2000.

The following list provides Microsoft and third-party resources for porting and supporting UNIX migration to Visual C++:

Another 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 curses exist that use the Win32 console APIs. For more information, see SetConsoleCursorPosition.

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.

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

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). For more on IPC, see Interprocess Communications.

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 Device Contexts for information on GDI.

Basic UNIX applications, including many CGI applications, should port easily to Visual C++ running on Windows NT and Windows 2000. 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.

Another option UNIX programmers look at is the Windows NT and Windows 2000 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 and Windows 2000 POSIX subsystem do not have access to Windows NT and Windows 2000 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 and Windows 2000 POSIX subsystem.

Reference

Concepts

Other Resources