Use LIBCTINY.LIB to lose weight for EXE and DLL files

In October 1996 column I discussed a question about the size of an executable file. At that time, a simple Hello World program was about 32KB. After the visual c++® compiler has updated two versions, the file size problem has improved slightly, with the same program using the visual c++®6.0 compiler now has only 28KB. In that column, I used a small run-time library to create minimal executable programs. Although there are a lot of limitations, but in most of the procedures, they work very well. These limitations have been around for quite some time and I am determined to revise them. It also provides a little-known knowledge of how to further reduce the size of the program.

Dimensions of DLLs and EXE

Before we replace the runtime, we'll have to take a moment to see why the EXE and DLL are bigger than you think. Consider the following standard Hello World program:#include <stdio.h>
void main()
{
　　printf ("Hello World!\n" );
}

Compile and produce a map file using the following command: If CL does not execute correctly, perform \VC98\BIN\VCVARS32 first under the console. BAT)

Cl /O1 Hello.CPP /link /MAP

First, view. The MAP file (Figure1 shows a reduced version), judging from the address of Main (0001:00000000) and printf (0001:0000000c), you can infer that the main function has only OxC byte length. Looking at the last line of the file, __chkstk (0001:00003B10), you can estimate that the executable code has at least 0x3b10 bytes, where nearly 14KB of code sends Hello world to the screen.

Now, look again. Other rows in the MAP file. Some items are useful, for example, the __initstdio function supports printf to write output to a file, so this kind of support for Stdio library functions makes sense. Again, like strlen, it will be called by printf, so it is contained in the. It's not surprising in MAP.

However, let's look at other functions, such as __sbh_heap_init. It is the runtime's heap initializer, and Win32 's operating system provides some similar heapalloc functions to implement heap allocation. Although the C + + runtime's choice of Win32 heap functions may result in performance improvements, Visual C + + does not. So at last, a lot of unnecessary code is added to the executable file.

Some people don't mind the runtime implementing their own heap, but there are more unconvincing examples here. Look at the __crtmessageboxa function at the bottom of the map file, which allows the executable file to invoke the MessageBox API through the runtime rather than the USER32.dll. But for a simple Hello World program, it is hard to foresee whether to invoke MessageBox.

Let's look at one more example: function __crtlcmapstringa the string into a region conversion. Regional support is the responsibility of Microsoft, but it is not needed for most programs. So there is no need to spend overhead on zone conversions.

I can also continue to enumerate the things that are not necessary, but I've proven my point: A typical applet contains a lot of code that won't be used, and it doesn't add up to the size of the code for each piece of code, but adding them all together would be pretty impressive.

About the Run-time Library of C + + dynamic connections

The attentive reader may say, "matt! Why not use C + + dynamic-linked runtime libraries? ”。 I didn't use that in the past because the runtime naming of C + + dynamic links in Windows NT 4.0, Windows NT 3.51, is not uniform. Fortunately, things are changing now, and in most cases you can count on the MSVCRT on your machine. Dll.

Recompile your MSVCRT (translator Note: CL/O1/MD Hood.c/link/map), very good, executable file only 16KB. The important thing is that you move some unwanted code to MSVCRT. Dll. It's just that you have to boot a DLL more when the program starts. This DLL also contains support for similar zone conversions. If MSVCRT can meet your needs, use it as much as possible. But, I still believe in using a cut, static runtime is a good thing.

I don't know if I should do this, but by communicating with my readers, I believe I'm not alone and many friends like me want the code as small as possible. Modern general-purpose writable discs and fast network connections are not required to worry about code size. But the fastest Internet connection I have in my home is only 24Kbps. I hate wasting time downloading a bloated page.

As a principle of mine, I want the code to be as small as possible. I don't want to load any DLLs I don't need. Even if I could use a DLLs, I would delay loading. I have discussed deferred loading in past columns if you want to familiarize yourself with it. You can take a look at Under the Hood in the December 1998 issue of MSJ for starters