3 ms·
That's not even the full Win32/16 style. That first line should be: static LRESULT WINAPI MCIWndProc16(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
by jcoby 11y ago
That's not even the full Win32/16 style. That first line should be:
static LRESULT WINAPI MCIWndProc16(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
And even then MS couldn't decide whether to use message (MSG struct), Msg (SendMessage), uMsg (WindowProc) for the second variable name. Sometimes they would use hwnd as well. I remember it all being very, very confusing when I was learning to program because it was inconsistent in so many ways.
In a semi-related note, Raymond Chen's blog (1) is great for diving into the history of the Windows API and its many quirks and gotchas.
[1] https://blogs.msdn.microsoft.com/oldnewthing/ https://blogs.msdn.microsoft.com/oldnewthing/
- therein 11y agoOh my god, I had the same experience growing up. Whenever I moved into the Windows API territory as a kid, I got pushed away, and now in hindsight I know why. The data types used to communicate with the Windows API was ambiguous, sometimes interchangable and often were simply typedefs that I didn't know about. Terribly confusing to a child but now I understand the concept of backwards compatibility and why one would avoid breaking support.