[NOTE: This document is still under construction.]
When migrating server applications from UNIX to Windows NT, there are a few options:
At first, UNIX programmers look at the Windows NT POSIX subsystem as an option. However it is only has support of POSIX 1003.1, which was the only POSIX "dot" standardized when Windows NT was created. Since then, there has been little demand for extending this subsystem, since most ISVs have converted their applications to Win32. The 1003.1 system is not too interesting for fully-featured apps, since it does not include many abilities (such as those in 1003.2, network support, etc). They do not have access to Windows NT features available to Win32 applications, such as memory mapped files, networking, graphics, etc. Applications such as VI, LS, and GREP are the main targets for the Windows NT POSIX subsystem.
The next option UNIX programmers normally look at are using third-party UNIX-like libraries to let their UNIX application code compile as a Win32 executable. There are a few commercial (and at least one public domain) libraries which do this. This is an option for some applications. The advantage of these porting libraries is that 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, as it can be messy 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 this takes the application onto the path of a native Win32 application anyway...
The approach to port UNIX applications directly to Win32 is the most efficient and powerful. Using ANSI C/C++ libraries, and commercial C compiler libraries, many of the traditional system calls relied on by UNIX applications are available by Win32 applications.
The output model of Stdio-based applications does not need to be changed, as the Win32 Console APIs mimic the stdio model, and versions of curses exist which use the Win32 Console APIs.
Berkeley socket-based applications need very few changes to work as Win32 applciations. The Windows Sockets interface was designed for portability with BSD sockets, with minimal changes (which are clearly noted in the introductory sections of the WinSock specification.
Windows NT supports DCE-compliant RPC, so RPC-based applications will be easily usable.
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 codebase, Win32 has two things which could be used, CreateProcess() and CreateThread(). Basically, a UNIX app which forks multiple copies of itself can be reworked in Win32 to either have multiple processes or a single process with multiple threads. If multiple processes, there are multiple methods of IPC that can be to communicate beteween the processes (and perhaps to update the code and data of the new process to be like the parent, if needing that functionality that fork() provides).
The graphical model is very different. UNIX has a defacto GUI of the X Window System, Windows has GDI. While vaguely similar in concept, there is no simple mapping of X API to GDI API. In addition, OpenGL support is available, for migrating UNIX OpenGL-based applications. There are X clients and X servers for Windows.
Basic UNIX applications -- such as many CGI applications -- will find Windows NT pretty familiar. Functions like open(), fopen(), read(), write(), etc are available in the C runtime library of most Win32 C compilers. As well, there is a one-to-one mapping of these UNIX APIs to Win32 APIs, open() to CreateFile(), read() to ReadFile(), write() to WriteFile(), ioctl() to DeviceIOControl(), close() to CloseFile(), etc.
If you have feedback or additional resources to add to this document,
please e-mail Lee Fisher.