I only have 32-bit Windows installed, so I cannot verify this myself.
If I understand correctly, the DWORD used in various places in the Microsoft API is in reference to the original 16-bit word, and has nothing to do with the current hardware architecture?
So DWORD which seems to be 32 bits, will remain 32 bits even when I eventually compile and link my app to run in 64-bit Windows? Or will DWORD become 128 bits wide?
On
Oh God, here comes another reasonable question... :)
It's always 32 bits, since a "word" is considered to be 16 bits in x86. Programs would break if the size changed.
If you need a native-size DWORD, try DWORD_PTR.
(Don't ask what the difference between DWORD_PTR, ULONG_PTR, UINT_PTR, and size_t is; I have no idea what Microsoft was thinking when it invented the first three...)
On
DWORD is always 32 bits (unsigned). QWORD is always 64 bits (unsigned). Then there are the DWORD32 and a DWORD64 that are 32 and 64 bits. Don't ask me why are they there :-)
http://msdn.microsoft.com/en-us/library/cc230318(v=PROT.10).aspx
http://msdn.microsoft.com/en-us/library/cc230362(v=PROT.10).aspx
and in general
http://msdn.microsoft.com/en-us/library/cc230309(v=PROT.10).aspx
On
I would even go further than x86 arch. and say in general, a WORD may be considered to be 16 bits. The hierarchy traditionally has been BYTE (8 bits), WORD (16 BITS), and so a DWORD (if D is taken to be a double wide WORD) would be 32 bits. This doesn't necessarily have anything to do with a particular platform or language, a BYTE has been 8 bits and a WORD has been 16 bits going back to the old 8 bit computer days, even before the x86 arch. existed
The only thing that changes size between 32 and 64 are pointers. So DWORD stays 32 bits wide.
Some things are not immediately obviously pointers, e.g. HANDLE, LPARAM, WPARAM. But these three change width as they actually hold pointers.