What's the point in WinMain?

[dave2k]

Hi, ok i get the point when your making a gui, but apart from that, why don't people just use the no-thrills int main() ?

[philkr]

The reason is that int main() is for console applications. If you want to make an application with neither a GUI nor console output, you would use WinMain() and simply don't create a window. If you used a console app (int main) a blank console window would show up automatically. That's not what you would want, is it?

[dave2k]

you can usually set it to invisible under the compiler options..

[philkr]

But it will still be there and consume cpu and memory, though not very much I have to admit.
Asked the other way:
What is the point with int main()? OK, I get the point when making a console application. But please don't tell me that "int __stdcall WinMain(HINSTANCE hInstance, HINSTANCE, LPSTR lpCmdLine, int nShowCmd)" requires more typing than "int main(int argc, char[] argv)". That does not count as a reason for me.

[dave2k]

I was under the impression you had to initiallise loads of other stuff to use with it like, GetMessage loop, and the callback etc

[philkr]

I was under the impression you had to initiallise loads of other stuff to use with it like, GetMessage loop, and the callback etc

Ah, I see. You only have to use that stuff, if you want to make a window (for a GUI). I'll demonstrate that it is not needed in other cases:

Hello World application as Win32-app

#include <windows.h>

int __stdcall WinMain(HINSTANCE hInstance, HINSTANCE, LPSTR lpCmdLine, int nShowCmd)
{
  MessageBox(NULL, "Hello World", "Hello World app", MB_OK);
  return 0;
}

Hello World application as Win32-console app

#include <windows.h>

int main(int argc, char[] argv)
{
  MessageBox(NULL, "Hello World", "Hello World app", MB_OK);
  return 0;
}

[dave2k]

cheers for clearing that up

[NoHero]

Just an addition... never... never ever use an calling convention directly under Windows programming. There are Windows macros wrapping up the calling convention for specific needs. So the Winmain method should have WINAPI instead, because this macro might change internaly in the future, which will lead to an incompatibilty of those who use the calling convention correctly.

int WINAPI WinMain ( HINSTANCE hInst, HINSTANCE hPrevInst, LPSTR CmdLine, int ShowCmd )
{
   return 0;
}

[dave2k]

ah! I was guided incorrectly! bah.

[philkr]

ah! I was guided incorrectly! bah.

You should have read NoHero's post better.
Using __stdcall is not incorrect.
It may become incorrect in future versions of windows (vista?). Who knows? If you want to be on the safe side use WINAPI like NoHero suggested.

[dave2k]

only joking

[NoHero]

You should have read NoHero's post better.
Using __stdcall is not incorrect.
It may become incorrect in future versions of windows (vista?). Who knows? If you want to be on the safe side use WINAPI like NoHero suggested.

That was the same with the FORTRAN and PASCAL calling convention... Things can change and it's always better to be on the safe site. Of course it will work, but how long? . It's not only a fact of style or personal preferences.

BTW: You use MB_OK too instead of it's numerical value (0), this is exactly the same. And are you doing... A question of readability. That's exactly the same with WINAPI. If a function is marked __stdcall do the most people - who read your code - know that your function is WinAPI compatible? But will know it for sure when you use WINAPI instead.

[philkr]

BTW: You use MB_OK too instead of it's numerical value (0), this is exactly the same. And are you doing... A question of readability. That's exactly the same with WINAPI. If a function is marked __stdcall do the most people - who read your code - know that your function is WinAPI compatible? But will know it for sure when you use WINAPI instead.

Of course, you are right. A long time I didn't know what this WINAPI means until I looked it up in the header file and found out it is __stdcall. My failure was that I never thought that it might be changed some day.
I just think it is not good sometimes when you simply have #define replacements which don't show what they really are. I mean, it should have been WINAPICALLCONV or something else, but probably that would have been to long.

[Amn]

Actually neither 'WinMain' nor 'main' are entry-points into any Windows application. I dont seem to recall the name of the entry point symbol, but you can override it, if you want to jump start a smaller executable and initialise everything yourself (the STL, STD libraries, call constructors for global objects etc). I wouldnt recommend it though, first because under-the-hood system always changes, and because the 'WinMain' and 'main' wrap a hardware dependent functionality, like calling constructors on a x86 system is not the same as calling constructors on a AMD64 system, even though both can run Windows programs.

There are people providing their own startup code though, like TINYLIB thing from some Microsoft guy, who desperately needed to minimize the size of the executable.