Why did the Win64 team choose the LLP64 model?

Raymond Chen

January 31st, 20050 0

Over on Channel 9,member Beer28 wrote,“I can’t imagine there are too many problems with programsthat have type widths changed.”I got a good chuckle out of that and made a note to write upan entry on the Win64 data model.

The Win64 team selected the LLP64 data model,in which all integral types remain 32-bit values and onlypointers expand to 64-bit values.Why?

In addition to the reasons give on that web page, another reason isthat doing so avoids breaking persistence formats.For example, part of the header data for a bitmap file is definedby the following structure:

typedef struct tagBITMAPINFOHEADER {
        DWORD      biSize;
        LONG       biWidth;
        LONG       biHeight;
        WORD       biPlanes;
        WORD       biBitCount;
        DWORD      biCompression;
        DWORD      biSizeImage;
        LONG       biXPelsPerMeter;
        LONG       biYPelsPerMeter;
        DWORD      biClrUsed;
        DWORD      biClrImportant;
} BITMAPINFOHEADER, FAR *LPBITMAPINFOHEADER, *PBITMAPINFOHEADER;

If a LONG expanded from a 32-bit value to a 64-bit value,it would not be possible for a 64-bit program to use this structureto parse a bitmap file.

There are persistence formats other than files.In addition to the obvious things like RPC and DCOM,registry binary blobs and shared memory blocks can also be usedto transfer information between processes.If the source anddestination processes are different bitness, any change to theinteger sizes would result in a mismatch.

Notice that in these inter-process communication scenarios,we don’t have to worry as much about the effect of a changedpointer size. Nobody in their right mind would transfera pointer across processes: Separate address spaces mean thatthe pointer value is useless in any process other than the onethat generated it, so why share it?

Raymond Chen