Small Windows Executables
Chris Dragan

It looks like we have a chain reaction, since this article is a reaction to SunmaN's article from Hugi#20 about 4K intros for Win32, which also was a reaction to a reaction. *grin*

Usually we face the fact that our Win32 programs are enormous. Today it is not a problem to write a small 4096-byte "Hello, world!" program for Win32; which may surprise many Visual Basic programmers. However, 4096 bytes for a program that doesn't do anything is TOO MUCH !

Tools won't help, that available.
There's no linker that is able
to make an executable
with a size that's reasonable.

This little "poem" illustrates one thing, known from the very beginning: when you want to have something done good - do it yourself.

To create a small windows executable, we first have to learn the Windows executable format, which is know as Portable Executable (PE). Naturally, the portability of this format is questionable. We don't have too many resources:

- The description of the PE format, released before the first Win32, contains some useful information, though it is not sufficient. You can find it at wotsit.org.

- A very well known file named winnt.h, distributed with every C(++) compiler for Win32, contains the structures found in the PE headers, with a minimal description. Just use your favourite editor's search command and look for text "image format".

- Also the issue #2 of Assembly Journal (asmjournal.freeservers.com) contains an interesting article about a tiny PE executable.

Having these three resources we are able to create our own executable that will be very small. The article in asmjournal shows a Win32 console program that prints its command line. The program has only 192 bytes!!!! Unfortunately this is only possible under WinNT4. The app works under Win2K, but since it calls some kernel routines by their fixed WinNT4-specific addresses, it crashes.

So here we notice once again that WinNT is a very different OS from the so-called consumer Windows. WinNT is much less restrictive than Win9x, concerning the executables. Nevertheless we want to create small executables that will work with Win9x, too!

Choosing an assembler

At this point we choose an assembler - it will be NASM (the Netwide Assembler). This assembler allows us to hand-code a PE header with a minimal effort, using only one directive and no linker.

If you haven't used NASM, it is worth to know that it has two (and ONLY two) uncomfortable limitations. The following 32-bit code:

    	jmp	here
    here:	add	ecx, 5

...it assembles to these bytes:

    E9 00 00 00 00   	   jmp	   +00000000h
    81 C1 05 00 00 00	   add	   ecx, 00000005h

To make NASM behave kindly, we have to code:

    	jmp	short here
    here:	add	ecx, byte 5

...and then we get:

    EB 00   		   jmp	   +00h
    83 C1 05		   add	   ecx, +05h

As a side note, NASM has multiple advantages:

- it is free,

- it is simple as it has very, very few directives,

- it has a powerful preprocessor, not found in any other assembler,

- it provides you with total control over your code,

- it is extremely portable - you can use your code on any x86 OS.

But we aren't here to talk about NASM pros and cons... *grin*

First things first

How a PE executable works? A PE executable, further referred to as PE, consists of headers and sections. Headers contain data for the executable loader, and sections contain the actual program.

In the file, the sections of a PE are aligned. This means that each section starts at an address divisible by a number which is the base of the alignment, and also each section has a size divisible by that number. If it happens that a section is too short, i.e. its size is not aligned, it is simply padded with zeroes to the alignment boundary. For example if the required alignment is 32, and our section has only 24 bytes, additional 8 zeroes are added to the end of the section. The same goes for the headers: if the headers in our PE are too short, they are zero padded to the alignment boundary, so that the first section that follows them is aligned.

The docs say that all sections have to be aligned, but practice shows that the last section in a PE doesn't have to have aligned size - therefore file size doesn't have to be aligned.

Win9x requires that file alignment be 512 bytes (200h). This means that all the headers together occupy no less than 512 bytes, or a multiple of 512, and also every section, but the last one, occupies a multiple of 512 bytes. And here we have the first difference between WinNT and Win9x: WinNT doesn't have this restriction.

PE sections contain miscellaneous things. They may contain code, data, imports (references to functions imported from other DLLs), exports, resources, symbol tables, etc. No matter what the docs say and how the available linkers behave, it is not required that these entities reside in separate sections. For example, one can put code and data into one section. One can even put everything into one section - and this is what we want to do. As you may easily guess, doing this we gain a few bytes otherwise lost on file alignment.

Somewhere in the PE headers (later about where exactly) there is a number that tells where the PE will be loaded. A PE can be either a program or a DLL library (a DLL can be a library with routines, fonts, drivers, etc.). For DLLs this load address is only a proposed location - the system can load a DLL at a different location. But executables are (almost) always loaded at this address. And for executables this address is usually 400000h (4MB); using a different address than 400000h we risk our program being loaded not at the address we want. This fixed nature of a program's load address shows another difference between programs and DLLs - DLLs need additional relocation tables that will enable the system to relocate DLL code to a different location than the one specified, and executables usually don't have the relocations.

I am not going to explain the mysteries of 32-bit flat addressing mode here, but it is enough to know that each program has its own address space in this mode; as you are likely to know Win32 uses flat mode. A program calls multiple routines that reside in DLLs. These DLLs are mapped to the program's address space, and each DLL has a unique location - hence the need for relocating DLLs, while the program can have a fixed load address. Each module has a unique module handle, which sometimes needs to be passed to system functions, like CreateWindowEx() for example. As a matter of fact, this module handle is module load address; programs needlessly call the GetModuleHandle() routine, which always returns their load address, which is usually 400000h. Hence another optimisation for us: we won't ever need to import and call the GetModuleHandle() function.

PEs aren't loaded linearly. The headers are loaded exactly at the load address, but sections are further relocated. When being loaded, sections are expanded and aligned to a greater value than file alignment. This is called section alignment. The following table presents a set of entities residing in an example PE, and how they get relocated.

WhatIn FileIn Memory
PositionSizePosition (RVA)Size

Headers

0

200h 0 1000h

Section 1

200h

600h 1000h 1000h

Section 2

800h

0 2000h 7000h

Section 3

800h

121h 9000h 1000h

Again, the section size in the file is aligned to File Alignment, while its size in memory after being loaded is aligned to Section Alignment. In the above example a PE contains 3 sections: first that has some stuff and is padded to 600h bytes (the actual section size can be 500h for instance), second that is empty, at least in the file, and third that has 121h bytes - alignment not required. Assuming a default section alignment of 1000h, the first section is expanded to 1000h bytes - 0A00h zeroes are added to its end to fulfill the alignment requirements, the second section is expanded to 7000h bytes and the last section to 1000h. Now we notice that section sizes in memory are actually bigger than section sizes in file, and this is a nice way of allocating non-temporal memory.

Win9x requires that the section alignment be no less than 1000h. Of course both file alignment and section alignment have to be powers of two. Almost all programs use the default alignment values - 200h and 1000h, respectively. I wouldn't recommend using any other values than these; who knows what Microsofters will devise in the future?

It is a must to use subsequent section addresses, i.e. to allocate sections in memory in the order they were in the file. Not sticking to this rule may produce undesirable results.

You are probably wondering what the RVA means that is found in our small example and why the headers are loaded at RVA=0? RVA means Relative Virtual Address, and it is an offset relative to Image Base - the address at which our file is loaded. So if Image Base is 400000h, the headers are loaded at 400000h and the first section from our example at 401000h.

What makes us headerache

The time has come to reveal the structure of PE headers - the aim of this article. Hopefully having understood how PE files are loaded and what they consist of, we can learn that all addresses in the headers and in the load-time portions of sections (e.g. import tables) are relative to image base, i.e. they are RVAs. All addresses in code and data of a PE are non-relative, i.e. fixed, unless they are relocated - provided that a PE contains relocation tables.

Each PE has the following headers, in exactly that order:

- DOS stub,

- PE header,

- optional header,

- section headers.

If there aren't any weird things in a PE, it has some padding after the headers, and then the sections come.

The DOS stub is a small DOS executable that usually displays some annoying message when the user tries to run the program in DOS. This stub is not required to exist, only the MZ header must be there. The MZ header must consist of two bytes 'M' and 'Z' at offset 0, and a 32-bit number at offset 3Ch, so our entire MZ header has 64 (40h) bytes. The other bytes within the MZ header are not important - they can have any value. The 32-bit number that ends the MZ header is a file-relative offset to the PE header.

The PE header should be located in file at an address divisible by 8 (must be 8-byte aligned). It can actually begin within the DOS header, using up the unused bytes, but it is better to place it after the MZ header, i.e. at offset 40h. We will take advantage of the extra spare bytes in the MZ header at a later time.

The PE header contains a bunch of numbers:

Size Value Description
dword 'PE' PE magic number identifying the PE header
word 14Ch Machine for which this executable is (14Ch is 386)
word 1 Number of sections - in our case it will be only one
dword ? Time stamp - this can be any value
dword ? Pointer to symbol table - we won't use any symbol tables
dword 0 Number of symbol tables - zero in our case
word X Size of optional header
word 10Fh Characteristics - bitflags (10Fh is 32-bit executable)

The ? values are unimportant - let's set them to 0. The size of the optional header that comes right after the PE header have been marked as X - we will put appropriate expression in the source file there, so the size of the optional header will be figured out at compile time. We will also do similar things later on.

The optional header, which is in fact NOT optional, contains more information, specific to our executable:

Size Value Description
word 10Bh Optional header magic number
word ? Linker version - we don't care
dword ? Size of code - we could give it some real value
dword ? Size of data
dword ? Size of uninitialized data - this is usually 0
dword X Program entry point
dword X Base of code
dword X Base of data
dword 400000h Image base - this is where our PE is loaded
dword 1000h Section alignment - we agree on 1000h
dword 200h File alignment - phew!
dword 4 OS version - better leave it 4.00
dword 0 Image version - huh?
dword 4 Subsystem version
dword ? Win32 version
dword X Image size IN MEMORY
dword X Size of all headers - file offset of first section
dword ? Checksum
word 2 Subsystem (2 is Win32 GUI)
word ? DLL characteristics - we have an executable, not a DLL
dword 100000h Stack size
dword 1000h Stack commit
dword 100000h Heap size
dword 1000h Heap commit
dword 0 Loader flags
dword 16 Number of directories
32 dwords - Directories follow

A lot of stuff! All meaningful addresses are of course RVAs. The entry point is the RVA at which our program will start. Base of code and base of data aren't too important, but we can set them to some valid values. The stack and heap sizes have to be set to some useful values. Stacks are always thread-specific, and in our case each stack will have an initial size of 1000h bytes, and limits of 100000h bytes. Heaps usually aren't used, but we can (or must) sacrifice 4KB of memory.

The table of directories found in the executable is a real pain in the a. Each entry of this table consists of two dwords - a pointer (RVA) to a directory, residing somewhere in some section, and the size of that directory. The second directory is the imports directory, and this is what we want to have. We aren't interested in any other directories, so we set all of their corresponding entries in the table to 0s - if you want to learn more about them, refer to the PE document from wotsit.org, or to winnt.h. In our case there could be only two table entries, as the second of them points to our beloved import directory. For WinNT it is OK to have only two entries, but Win9x requires 16, and that's why we don't like it.

With the end of the table of directories the optional header ends. After it we find section headers. The number of section headers is in the PE header existing before the optional header. Each section header has the following structure:

Size Value Description
qword ? ASCII section name - can be anything you want
dword X Size in memory
dword X RVAddress in memory (in our case it will be 1000h)
dword X Size in file
dword X Offset in file
dword ? Pointer to relocations - we won't have any
dword ? Pointer to line numbers - debug info, anyone ?
word 0 Number of relocations
word 0 Number of line number entries
dword 0E0000060hFlags

There are many available flag values (from winnt.h):

CodeDescription (section contains...)
00000020h Code
00000040h Data
00000080h Uninitialized data - this is fiction!!!
01000000h Extended relocations
02000000h Section can be discarded
04000000h Section is not cacheable
08000000h Section is not pageable
10000000h Section is shareable
20000000h Section is executable
40000000h Section is readable
80000000h Section is writable

There are even more flags, but many of those presented here as most of those other are unimportant. For example if we choose our section to be readable but not writable, we still will be able to write to it, even under WinNT.

Before we seriously go into coding, we yet have to learn how an import table looks. An import table consists of a set of entries, each of which corresponds to some DLL from which we import functions. Each import table entry has the following structure:

Size Value Description
dword X RVA of original thunk
dword ? Time stamp
dword ? Forwarder chain (what???)
dword X RVA of ASCIIZ DLL name
dword X RVA of replaced thunk

The last entry in an import table is zero-filled, indicating the end of the import table. The so-called thunk is a zero-terminated array of dword pointers to imported function names. The replaced thunk is filled by the PE loader with actual pointers to imported routines. The original thunk remains untouched, but unlike most of linkers, we can supply the same RVA for both replaced and original thunk, thus including only one thunk per imported DLL. The entries of each thunk point to ASCIIZ function names preceded by a word value called "hint". This was originally meant to serve as an alternate method of importing functions by indices instead of names, but it doesn't work anyway, so we can set the hints to 0, and use them as ASCIIZ function name terminators. Note that all function names should be word aligned. Also, it is obvious but worth to mention once again, that the entries of a thunk are RVAs to hints, and those hints are followed by actual imported function names.

Tips and tricks

As indicated above, we want to create only one single section in our PE, so we won't lose any bytes on file alignment (i.e. alignment of sections within the file). Needless to say that we don't care about any export tables, resources, symbol tables and other weird things that can reside in a PE. Unfortunately we meet two serious Win9x limitations: we must use file alignment 200h, what makes our headers occupy 512 bytes, and what's more we have to include 16 directories, 14 of which are unused - unnecessary loss of 14*8=112 bytes. As the headers are loaded into memory at the image base, we can fill their unused parts with useful data, such us imported function names, for example. The spare places we get, after getting rid of DOS stub and leaving only 64-byte MZ header, are the unused parts of this MZ header (58 bytes) plus the padding bytes after section headers (160 bytes).

The code

The program we want to create will be a skeleton for a 4K intro. Of course it would be even better to make a simple compressor for our code, but this is rather a topic for Dario Phong.

In C, the program would look like follows:

    WNDCLASS WindowClass; // = { ... };

    void main() // NOT WinMain()
    {
       RegisterClass( &WindowClass );
       HWND hWnd = CreateWindowEx( 0, &ClassName, &ClassName,
    		  WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, 0,
    		  CW_USEDEFAULT, 0, 0, 0, 0x400000, 0 );
       ShowWindow( hWnd );
       UpdateWindow( hWnd );
       LPDIRECTDRAW lpDD;
       DirectDrawCreate( 0, &lpDD, 0 );
       lpDD->Vtbl->SetCooperativeLevel( lpDD, hWnd,
    		  DDSCL_EXCLUSIVE | DDSCL_FULLSCREEN );
       if ( lpDD->Vtbl->SetDisplayMode( lpDD, 640, 480, 32 ) )
          for (;;) {
    	 WaitMessage(); // Replace this with your frame rendering
    	 MSG msg;
    	 if ( ! PeekMessage( &msg, 0, 0, 0, PM_REMOVE ) )
    	    continue;
    	 if ( msg.message == WM_QUIT )
    	    break;
    	 DefWindowProc( msg.hwnd, msg.message,
    			msg.wParam, msg.lParam );
          }
       lpDD->Vtbl->Release( lpDD );
    }

    LRESULT CALLBACK WndProc ( HWND hwnd, UINT uMsg,
    			   WPARAM wParam, LPARAM lParam )
    {
       if ( uMsg != WM_DESTROY )
          goto DefWindowProc;
       PostQuitMessage( 0 );
    }

This is a minimal program that switches into 640x480x32bpp mode and remains in it until the user presses Alt+F4. Note that I didn't include any surface-creation code here; creating a primary ddsurface is a must if one wants to display anything. We could also add some code for handling the Esc key to the main() function, like:

       if ( msg.message == WM_KEYDOWN &&
    	msg.wParam == VK_ESCAPE )
          CloseWindow( msg.hwnd );

We actually can afford importing one more function, since we put the import strings in the PE header's padding areas. You may take a different approach on your own, but consider that the import function names are needed only at load time, and we actually don't know what happens with the headers while the program runs.

Implementation

Whether you know or don't, the Win32 logic assumes that all significant calls through the system leave registers ebx, esi, edi and ebp untouched. This concerns not only imported routines we call, but also callbacks supplied by us, such as WndProc(). The result is always returned in eax or in eax:edx pair, and eax, ecx and edx may be destroyed. Win32 standard calling convention is stdcall (reverse order of pushed arguments, arguments removed by the calee); an exception is function wsprintf which has C calling convention, since it has a variable amount of arguments.

Many standard Win32 functions are in two versions: ANSI and UNICODE. This concerns mainly routines that obtain some strings, for example CreateWindowEx. The actual names of this function are CreateWindowExA for ANSI and CreateWindowExW for UNICODE. The UNICODE version is rare and exists only on some versions of WinNT, nevertheless CreateWindowExA is the valid name we will use. (Note that actually there is no CreateWindow function, as it is re-defined to CreateWindowExA/W in winuser.h.)

DirectX and other COM-style calls are also simple. It is enough to notice the difference between calling them from C++ and C:

    lpDD->SetDisplayMode( 640, 480, 32 ); // In C++
    lpDD->Vtbl->SetDisplayMode( lpDD, 640, 480, 32 ); // In C

Since Vtbl is located at offset 0, the latter has an alternate syntax:

    (*lpDD)->SetDisplayMode( lpDD, 640, 480, 32 );

And this is exactly what we are doing in assembly.

For the purpose of our example skeleton, we use registers for storing common values, like 0 or hWnd. We also keep a pointer to MSG structure in a register. Because the thunks will lie near this structure, we will also use addresses of imported function pointers relative to it, gaining three bytes on each call to an imported routine.

In case you want to create a hardware accelerated 4KB intro: it is possible to do this with OpenGL, but you probably wouldn't do much effects, since the import tables would take many precious bytes. A better approach is to use Direct3D - you do not need any extra imports than the ones used in our example, and all calls to Direct3D are done through COM.

Final words

There isn't much to say. The source of the example you should find in the bonus pack. Have fun coding small proggies, and I hope this article helped you in that matter.

Chris Dragan