Windows System Programming Third Edition

GETTING READY FOR WIN64

11

• “

” 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

progra

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

nary compatibility

issues.

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