About the Windows API my little humble opinion

I've been confused about the naming and usage of Windows APIs, but after some practice I looked back at Windows programming and got some ideas about Windows APIs.

1. Windows is closed-source first, so some of the Windows API calls might look weird due to security, or possible reasons such as a human-designed vulnerability.

For example, Windows will use a handle to represent the resource, many times there will be a handle, then pass the handle to the API, and then release the handle, personally feel this method a bit troublesome ...

Well, in fact, the C function of the fopen this kind of operation is to call the fclose itself, is it inevitable?

There are many Windows callback functions, entry functions, API functions and so on with WINAPI and callback, and other keywords, these functions are mainly used to communicate with the Windows kernel, they are defined as stdcall, which is a function calling convention, refer to here,

I think it's just to communicate with Windows. So the rules for a set of function calls are defined, so that any function that would interact with Windows would add WINAPI such as a modifier keyword?

2.windows is compatible, so there may be some things in the API during the update process design ideas may change,

or some new API design ideas will be different from the previous (this may I want to learn more about the example, I just think that it is impossible to blindly compatible, it should be improved).

However, while some things are improving, there may be some misleading historical omissions in order to be compatible with older versions of the program.

For example, wparam and lparam in message processing, citing a section of the explanation of the Windows programming Code:

The third and fourth parameters of WndProc are defined as wparam and lparam, respectively,

The source of these names has a historical background: When Windows is still a 16-bit system, the third parameter of WndProc is defined as a word,

This is a 16-bit unsigned short (unsigned) integer, and the fourth parameter is defined as a long,

This is a 32-bit signed long integer, resulting in text "param" preceded by the prefix "w" and "l".

Of course, in 32-bit Windows, WPARAM is defined as a uint, and lparam is defined as a long (which is the long Integer in C),

Therefore, both parameters of the Windows message processing program are 32-bit values. This may be a little strange,

Because the Word data type is still defined as a 16-bit unsigned integer in Windows98, the "w" before "param" is somewhat misused.

There is the parameter with P,LP, and then quote an explanation:

Here is a hint of the data type and Hungarian notation: the LPFN of the word "long pointer to function".

(In the Win32 API, there is no difference between long and short indicators (or proximity indicators). This is just a relic of the 16-bit Windows. ）

3. In order to be simple and alias, for the sake of explicit alias redefinition,

For example, it would use UINT to represent unsigned int, which I think might have something to do with not having auto-complete functionality before, and programmers would rather have a few lines of text so they define some abbreviations.

4. With regard to the Hungarian nomenclature, the Windows API parameter names are used in the Hungarian nomenclature. Some API function names are also possible with parameter types.

For example, SetWindowLong and setwindowlongptr, because I think the function name with the parameter type is a bit unaccustomed, the initial contact is not known to add a long to indicate what, so I think these names are very awkward.

Temporary personal contact Some feel a bit magical point is mainly above, if there is further experience, may continue to write down.

Windows always feels weird .... At the same time this is just some of my humble opinion, may also be revised later, can not be used as a reference, so to more in-depth and more accurate explanation, please find giant to go ....

About the Windows API my little humble opinion