wWinMain and wmain??
d2003xx
I'm curious that why the two functions wWinMain and wmain don't show
up in the documents in PlatformSDK? Are they VC++'s extensions or
something special??
Tim Robinson
extensions to C/C++. They don't show up in the Platform SDK because they're
not part of any API; you have to write them yourself. They should be listed
in the compiler docs.
--
Tim Robinson (MVP, Windows SDK)
http://www.themobius.co.uk/
"d2003xx" <d20...@hotmail.com> wrote in message
news:3dd5593c.03090...@posting.google.com...
Alf P. Steinbach
>wmain is part of the C and C++ languages.
That is incorrect; only "main" is part of the C and C++ languages.
"wMain" is part of the Visual C++ dialect, though.
What you call "Microsoft's extensions to C/C++" below.
>wWinMain is one of Microsoft's
>extensions to C/C++. They don't show up in the Platform SDK
>because they're not part of any API;
>you have to write them yourself. They should be listed
>in the compiler docs.
Note that there's not a sharp dividing line between the Windows API
and the Visual C++ compiler. Especially with regard to SEH exception
handling, where some functions listed as API functions are in reality
Visual C++ compiler intrinsics. Ah, well...
Jordi Vilar
Both wWinMain and wmain are functions to be implemented by the
application. From the Win32 view point neither wWinMain nor wmain (nor
also neither WinMain nor main) really exists: all images (exe or dll)
have a single entry point. This entry point is usually handled by the
C runtime, and finally fall back to your program entry point. It
depends on the run time how to route the loader-view entry point to
your application' entry point. If you use a Unicode version of the
runtime it calls the Unicode counterpart. Only main is defined by the
standard C/C++, but this is the entrypoint for the application used
for the ANSI/CONSOLE version of the runtime in the Microsoft
compiler/libraries.
The REAL entrypoint is specified as a linker option. For exes, the
entry point has no parameters, and MUST never return. A minimalist
implementation for this entry point may be this single line:
ExitProcess(WinMain(GetModuleHandle(NULL), NULL, GetCommandLine(),
SW_SHOW);
Of course this is not well suited for real applications: it doesn't
handle constructors nor destructors for global objects in C++, doesn't
initialize the runtime nor the floating point package, atexit
handlers, and so on... it also doesn't set the show flag according the
STARTUPINFO structure retrieved using GetStartupInfo(). Also the
CONSOLE crt startup should parse the command line and chop in
argc/argv and then call main().
I suggest you look at the runtime source files distributed with the
development environment, the files are called crt0.c and so (they are
several files for exes and dlls). You can also look at the article
from the MSDN "Under the hood: Reduce EXE and DLL Size with
LIBCTINY.LIB" from Matt Pietrek. It shows how the runtime initializes
all its stuff and finally calls your application entrypoint.
I hope this helps in understanding the "magic" of a process
initialization. I'm sorry if too dense or out of scope.
Jordi Vilar
d20...@hotmail.com (d2003xx) wrote in message news:<3dd5593c.03090...@posting.google.com>...