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?

Wednesday, August 4, 2004

From tchar.h:

#ifdef  _UNICODE
#define _tWinMain  wWinMain
#define _tWinMain  WinMain

wWinMain is the unicode version for WinMain.

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


René Nyffenegger
Wednesday, August 4, 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 4, 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.

Wednesday, August 4, 2004

>> OS X makes things a little clearer

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

Wednesday, August 4, 2004

I agree, lack of namespace support sucks.

Wednesday, August 4, 2004

*  Recent Topics

*  Fog Creek Home