Appendix B. Windows, UNIX, and C Library Comparisons

Appendix B. Windows, UNIX, and C Library Comparisons The tables in this appendix show the Windows (Win32 and Win64) functions described in the main text along with the corresponding UNIX/Linux[1] and ANSI Standard C library functions, if any. [1] More precisely, "UNIX" means the POSIX functions specified in The Single UNIX Specification (http://www.opengroup.org/onlinepubs/007908799/). UNIX and Linux implement this specification. In turn, the specification has its historical origins in UNIX. The tables are arranged by chapter (some chapters are combined). Within each chapter, they are sorted first by functionality area (file system, directory management, and so on) and then by the Windows function name. Each table row gives the following information: The functionality area (subject) The Windows function name The corresponding UNIX function name. In some cases, there are more than one. The corresponding C library function name, if any Comments as appropriate The notation used in the tables requires some explanation. The Microsoft Visual C++ library contains some UNIX compatibility functions. For example, _open is the compatibility library function for UNIX open. If the UNIX function is in italics, there is a compatibility function. An asterisk next to the name indicates that there is also a wide character Unicode version. For example, there is a _wopen function. A program that uses just the Standard C library, and no Windows or UNIX system functions, should compile, build, and run on both systems if normal precautions are taken. Such a program will, however, be limited to file and I/O operations. Commas separating functions indicate alternatives, often using different characteristics or emulating one aspect of the Windows function. Semicolons separating functions indicate that you use the functions in sequence to emulate the Windows function. Thus, fork; exec corresponds to CreateProcess. An underlined entry indicates a global variable, such as errno. In a few cases, the UNIX equivalent may be stated imprecisely in terms such as "terminal I/O" for Windows functions such as AllocConsole. Often, "Use C library" is the appropriate comment, as in the case of GetTempFileName. In other cases, the situation is reversed. Thus, under the UNIX signal management functions (sigaddset and so on), the Windows entry is "Use SEHVEH" to indicate that the programmer should set up structured or vectored exception handlers and filter functions to get the desired behavior. Unlike UNIX, Windows does not support process groups, so the Windows entries are "N/A," although job management, as done by the programs in Chapter 6, could emulate process relationships. There are numerous "N/A" entries, especially for the C library, if there is no comparable function or set of functions. This is the case, for example, with directory management. The POSIX threads (Pthreads) functions are the UNIX equivalents shown in the tables for Chapters 710, even though they are not properly a part of UNIX. Furthermore, even though many UNIX implementations have their own synchronization objects similar to events, mutexes, and semaphores, there is no attempt to list them here. Generally, the correspondence is more precise in the earlier chapters, particularly for file management. The systems tend to diverge with the more advanced functionality and, in many cases, there is no C library equivalent. For example, the UNIX and Windows security models differ significantly, so the relationships shown are, at best, approximations. These functional correspondences are not exact. There are many differences, small and large, among the three systems. Therefore, these tables are only for guidance. The individual chapters discuss many of the differences.