Fog Creek Software
Discussion Board




On WinMain and it's ilks

When I learned to program in C, I was told that every program began with an int main(...).
Then I began to peak at MFC apps and I found out that they began with int WINAPI WinMain(...) and I found that it had to be that way so we didn't end up with a console application.

Now, I was looking at an WTL application and found out that it began with int APIENTRY _tWinMain(...).

And so began the confusion. Can anyone explain?

Alardo
Wednesday, August 04, 2004

From tchar.h:


#ifdef  _UNICODE
#define _tWinMain  wWinMain
#else
#define _tWinMain  WinMain
#endif


wWinMain is the unicode version for WinMain.

_tWinMain expands to wWinMain if _UNICODE is defined, and to WinMain otherwise.

Rene

René Nyffenegger
Wednesday, August 04, 2004

I believe that I read somewhere, there is or was a main function (perhaps in at least Windows 3, so maybe things have changed) but it was part of the runtime library. 

Is it really something worth worrying too much about anyway? WinMain v main is a trivial issue next to the huge frameworks and API sets (e.g. Win32) everybody is using. Just do what the book says unless you really have some compelling reason to figure out what is going on under the hood.

S. Tanna
Wednesday, August 04, 2004

"main" is defined in the C standard and the C standard has nothing to do with Windows, Linux, or Mac GUI programming. Hence WinMain and other links to the GUI APIs are needed instead.

OS X makes things a little clearer by doing this...

int main(int argc, char *argv[]) {
    NSApplicationMain(argc, argv);
}

So that things are still routed through main before the GUI is initialized.

Justin
Wednesday, August 04, 2004

>> OS X makes things a little clearer

But a little less clear with the unending NS prefixes...

Alex
Wednesday, August 04, 2004

I agree, lack of namespace support sucks.

Justin
Wednesday, August 04, 2004

*  Recent Topics

*  Fog Creek Home