I had never heard of this pragma before, and seriously, I don't see why you need it.

From what I could gather, this lets you define a function to be called before main()?

Can't you do your processing at the beginning of the main function?

Alternatives I've read about were like:



or



But once again, why would you need that?

You have to build your own stub file. Here are a few links to get you started.

Creating Small Win32 Executables - Fast Builds
Reduce EXE and DLL Size with LIBCTINY.LIB
Techniques for reducing Executable size
Creating Self-Installing Packages

By declaring them static it makes them only available from within the file where main() is.

No problem.

xEricx's approach is quite a lot easier if all you want to do is to run some code before entering main. But if you want to take complete control over the actual startup function, you'll need to replace the stub. That can be quite a chore - setting up environment/argument variables, exception frames, floating point precision in some cases, and calling constructors and the like. It's a lot of work. Craft a small project - console or gui - with a main or WinMain that does nothing but return 0. Compile it and then disassemble the resulting exe. Actually, to make it easy to locate the main/WinMain function assign an easily recognizable value to an integer inside the function (eg. int x = 0xDEADBEEF; ). Search the disassembly for 0xDEADBEEF and work backwards and fowards from there to determine the start and end points of the main/WinMain function in the disassembly. All of the other code in the disassembly constitutes the stub (for the most part - there might be some data values in the stub that don't end up in the code). If you're gonna replace the stub, it helps to understand what the default stub does. And it also helps to remember that the stub varies from compiler to compiler, so what you learn about the stub used by one compiler doesn't necessarily hold for every compiler.

For VC you don't need a custom stub. Actually I'm not sure how a custom stub would be at all relevant.

All you need to do is to pass the /entry switch to the linker and give it the name of your startup function. Please note that doing this sort of thing is fairly serious mojo and you will be bypassing all the usual startup logic that needs to happen to (e.g.) get the C/C++ runtime libraries initialized properly and get the global state setup. You definitely shouldn't do that sort of thing unless you know exactly what you're getting into, have a very specific reason, and can't do it any other way.

Quote:Original post by Anon Mike
For VC you don't need a custom stub. Actually I'm not sure how a custom stub would be at all relevant.

All you need to do is to pass the /entry switch to the linker and give it the name of your startup function. Please note that doing this sort of thing is fairly serious mojo and you will be bypassing all the usual startup logic that needs to happen to (e.g.) get the C/C++ runtime libraries initialized properly and get the global state setup. You definitely shouldn't do that sort of thing unless you know exactly what you're getting into, have a very specific reason, and can't do it any other way.

The "serious mojo" that you describe amounts to the same thing as a custom stub.

We must be talking about different things with the word "stub". By stub I mean the DOS stub that every Win32 executable has embedded in it who's original purpose was to tell a DOS user that this app isn't actually a DOS app and that you need to be running Windows. This code doesn't even get touched by modern versions of Windows and has no effect on application startup.

It sounds like you are using "stub" to mean the C/C++ runtime initialization code. I've never heard that referred to as a stub before.