Windows Data Types… why so redundant/undescriptive?

Question

Could someone please exactly why the following typedefs/#defines have been defined? What value do they have, compared to the originals?

<         


        

Answer 1

Most of these redundant names exist primarily for two reasons:

• they're historical types preserved for backward compatibility
• they're different names for the same type that arose from different teams of developers (it can be surprisingly difficult for teams to remain consistent across such a huge project as Windows)

---

typedef char CHAR;

The signedness of char can vary across platforms and compilers, so that's one reason. The original developers might have also kept this open for future changes in character encodings, but of course this is no longer relevant since we use TCHAR now for that purpose.

---

typedef unsigned __int64 DWORD64; //A 64-bit "double"-word?!

During the move to 64-bit, they probably discovered that some of their DWORD arguments really needed to be 64 bits long, and they probably renamed it DWORD64 so that existing users of those APIs weren't confused.

---

typedef void *PVOID;              //Why not just say void*?
typedef void *LPVOID;             //What?!

This one dates back to the 16-bit days, when there were regular "near" pointers which were 16-bit and "far" pointers that were 32-bit. The L prefix on types stands for "long" or "far", which is meaningless now, but back in those days, these were probably defined like this:

typedef void near *PVOID;
typedef void far *LPVOID;

---

Update: As for FLOAT, UINT and ULONG, these are just examples of "more abstraction is good", in view of future changes. Keep in mind that Windows also runs on platforms other than x86 -- you could think of an architecture where floating-point numbers were represented in a non-standard format and the API functions were optimized to make use of this representation. This could then be in conflict with C's float data type.