لطفا منتظر باشید ...
Getting Ready for Win64
Win64, which is supported (at the time of writing) by Windows XP and 2003 on AMD''s AMD64 (Opteron and Athlon 64) processor family and Intel''s Itanium processor family (previously known by code names such as Merced, McKinley, Madison, and IA-64), will be an increasingly important factor in the building of large applications. The essential difference between Win32 and Win64 is the size of pointer variables (64 bits in Win64) and the size of virtual address space.
Throughout this book, Win64 migration is discussed as appropriate, and the programs are built so that a simple compiler switch will enable you to build the programs as Win64 applications. The example program projects on the book''s Web site are set up to generate 64-bit migration warnings, and most (but not all) warning situations have been eliminated from the code.
Most of the differences, from a programming point of view, concern the size of pointers and careful avoidance of the assumption that a pointer and an integer (LONG, DWORD, and so on) are of the same length. Thus, the types DWORD32 and DWORD64 are defined so that you explicitly control variable size. Two other types, POINTER_32 and POINTER_64, control pointer size.
With a little care, you will find that it is fairly simple to ensure that your programs will run under either Win32 or Win64, and, in general, we will continue to use Windows, or sometimes Win32, to refer to the API. Chapter 16 provides more information on Win64, including information on source and binary compatibility issues.
UNIX and Linux programmers will find some interesting differences in Windows. For example, Windows HANDLEs are "opaque." They are not integers allocated in sequential order. Thus, the fact that 0, 1, and 2 are special file descriptor values, which is important to some UNIX programs, has no analogy in Windows.
Many of the distinctions between, say, process IDs and file descriptors go away. Windows simply uses a HANDLE for both. Many important functions treat file, process, event, pipe, and other handles identically.
UNIX programmers familiar with short, lowercase function and parameter names will need to adjust to the more verbose Windows style. The Windows style is closer to that of HP (formerly DEC and Compaq); OpenVMS and OpenVMS programmers will find many familiar features. One reason for the similarity to OpenVMS is that the original VMS architect, David Cutler, assumed a similar role with NT and Windows.
Critical distinctions are made with such familiar concepts as processes. Windows processes do not, for example, have parent-child relationships, although Windows processes can be organized into job objects.
Finally, Windows text files represent the end-of-line sequence with CRLF rather than with LF as in UNIX.
