GETTING READY FOR WIN64
” sometimes appea rs in macro names, such as ,
even though the macro is also used with Win64.
• The former requirement, no longer relevant, for backward compatibility
means that numerous 16-bit functions are never used in this book, even
though they might seem important.
is such a function; always use
to open an existing file.
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,
Mad ison, and IA-64), will be an increas
i ngly important factor i n the building of
large applications. The essential di fference 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
ms 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 programm
ing point of view, concern the size of
pointers and careful avoidance of the assumption that a pointer and an integer
, , and so on) are of the same length. Thus, the types and
are defined so that y ou explicitly control variable size. Two other types,
and , control pointer size.
With a little care, you will find that it is fairly simple to ensure that your pro-
grams 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 bi
UNIX and Linux programmers will find some interesting differences i n Windows.
For example, Windows
s are “opaque.” They are not integers allocated in
sequential order. Thus, the fact that
, , and 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
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 an
d OpenVMS programmers