WinMain is a C function, not a C++ function, which means it cannot be overloaded.
And it was defined in the days before C supported the const keyword.
ANSI C (1989) has a const keyword, the earlier Kernighan and Ritchie (K&R) version of C++ did not. And Windows 1.0 was released in 1985, which is when I suppose WinMain was defined. So there would have been no const to use at the time.
But why the signature wasn't tightened up later, I do not know.
Why is there still a need for a handle to previous instances? With 32 and 64 bit versions of Windows the prevInstance parameter is always zero (or NULL), it was useful only for 16-bit Windows. When was the last time you used 16-bit Windows?
A lot of the Windows API is legacy coding that was added onto instead of changed. At times the decisions MS made don't make logical sense, but that is what we have to deal with.
At least MS made the command-line parameter character coding, ANSI or Unicode, compiling "agnostic."
It is easy to fault MS for a lot of things, but this really isn’t one of them.
First, MS made functional tools that worked in multiple languages before the current perfect standard way we all thing things should be done now. That took a lot of time and investment.
Second, MS takes great pains to make old code continue to work. You can pull out the sources for old 16-bit applications and still compile and use them!
Third, there is a cost-benefit ratio to making language changes. This is something very, very low on the list of things that need to be “fixed”. Use the API functions to get and parse the command line instead.