Why does the Win32-API have so many custom types?

Question

I'm new to the Win32 API and the many new types begin to confuse me.

Some functions take 1-2 ints and 3 UINTS as arguments.

• Why can't they just use ints? What are UINTS?

Then, there are those other types:

DWORD LPCWSTR LPBOOL 

• Again, I think the "primitive" C types would be enough - why introduce 100 new types?

This one was a pain: WCHAR*

I had to iterate through it and push_back every character to an std::string as there wasn't another way to convert it to one. Horrible.

• Why WCHAR? Why reinvent the wheel? They could have just used char* instead, or?

Answer 1

A coworker of mine would say "There is no problem that can't be solved (obfuscated?) by a level of indirection." In WIN32 you'll be dealing with WCHAR, UINT, etc. and you'll get used to it. You wont have to worry when you deploy that DLL which basic type a WCHAR or UNIT compiles to - it will "just work".

Best to read through some of the documentation to get used to it. Especially on the Wide char support (WCHAR, etc.). There's a nice definition on MSDN for WCHAR.

Answer 2

UINT is an unsigned integer. If a parameter value will not / cannot be negative, it makes sense to specify unsigned. LPCWSTR is a pointer to const wide char array, while WCHAR* is non-const.

You should probably compile your app for UNICODE when working with wide chars, or use a conversion routine to convert from narrow to wide.
http://msdn.microsoft.com/en-us/library/dd319072%28VS.85%29.aspx

http://msdn.microsoft.com/en-us/library/dd374083%28v=VS.85%29.aspx

Answer 3

Remember that the Windows API was first created back in the 1980's, and has had to support several different CPU architectures and compilers over the years. They've gone from single-user single-process standalone systems to networked multi-user multi-core security-conscious systems. They had to work around issues with 16-bit vs. 32-bit processors, and now 64-bit processors. They had to work around issues with pre-ANSI C compilers. They had to support C++ compilers in the early unstandardized times. They had to deal with segmented memory. They had to support internationalization before Unicode existed. They had to support some source-level compatibility with MS-DOS, with OS/2, and with Mac OS. They've had to run on several generations of Intel chips, and PowerPC, and MIPS, and Alpha. The same basic API is also used on mobile phones, handhelds, and many types of embedded systems.

Also, back in the 1980's, C was considered to be a high-level language (yes, really!) and many people considered it good form to use abstractions rather than just specifying everything as an int, a char, or a void *. Back when we didn't have IntelliSense and infotips and code browsers and online documentation and the like, such usage hints were very helpful.

Yes, it's a horrible mess, but that doesn't mean they did anything wrong.

Answer 4

UINTS are unsigned ints. An int value can either be positive or negative; an unsigned int (by definition) has no sign, and so is always nonnegative. This means that a UINT's range (the numbers it can represent) is different from (though equal in size to) a (signed) int's range.

Answer 5

Win32 actually has very few primitive types. What you're looking at is decades of built-up #defines and typedefs and Hungarian notation. Because there was so few types and little or no intellisense developers gave themselves "clues" as to what a particular type was actually supposed to do.

For example, there is no boolean type but there is an "aliased" representation of a integer that tells you that a particular variable is supposed to be treated as a boolean. Take a look at the contents of WinDef.h to see what i mean.

You can take a look here: http://msdn.microsoft.com/en-us/library/aa383751(VS.85).aspx for a peek at the veritable tip of the iceberg. For example, notice how HANDLE is the base typedef for every other object that is a "handle" to a windows object. Of course HANDLE is defined somewhere else as a primitive type.