why dont winmain parse a constant string?

hi,
when i create a win32 project i use this main function:
 
int WINAPI WinMain(HINSTANCE instance, HINSTANCE prevInstance, LPTSTR command, int cmdShow);


and i get no errors when i compile, and everything works fine.

but i was wondering:
shouldn't the LPTSTR be a const? so LPCTSTR ? since its not ever going to change?

I tried changing my code to that:
 
int WINAPI WinMain(HINSTANCE instance, HINSTANCE prevInstance, LPCTSTR command, int cmdShow);


but the result was the following error:
WinMain: function cannot be overloaded


so i guess you aren't allowed to do that?
how come? wouldn't it make more sense?
Last edited on
so i guess you aren't allowed to do that?
No, you have to follow the MS convention.

how come? wouldn't it make more sense?
Well you have ask MS why they didn't make it const.
Well...

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.

Andy
Last edited on
closed account (E0p9LyTq)
shouldn't the LPTSTR be a const?

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.

Hope this makes sense.
Topic archived. No new replies allowed.