I've noticed that MSVC6's compiler throws in 80-something functions pretty much related to handling runtime errors, and debugging. How would I get rid of this? That's probably what accounts for a blank executable's 28 KB filesize. (a blank vb6 program compiled to native code takes up 16 kb)
Also, how would I get rid of the "This program cannot be run in DOS mode" string without corrupting the DOS header? It just takes up space and nothing else (it's the string which is displayed upon attempting to run it in DOS mode). I'm pretty sure that the PE, COFF, and optional PE header with 3 40-byte section headers, imports, and the code itself shouldn't take up more then 6 kb.

MSVBVM60.dll is 694.7 kb. MSVC statically links to MSVCRT, whereas VB6 dynamically links to MSVBVM.

1. Read up on PE file format
2. Try writing a .com program rather than a .exe.

[quote author=Banana fanna fo fanna link=topic=17174.msg174863#msg174863 date=1195173809]
2. Try writing a .com program rather than a .exe.
[/quote]

Aren't .com programs 16 bit only?


I tried a few things:
#pragma optimize("gsy",on)
#pragma comment(linker,"/RELEASE")
#pragma comment(linker,"/FILEALIGN:0x200")
#pragma comment(linker,"/opt:nowin98")
#pragma comment(linker,"/ALIGN:4096")
seem to shrink the filesize by 6 bytes.

#pragma comment(linker,"/merge:.rdata=.data")
#pragma comment(linker,"/merge:.text=.data")
#pragma comment(linker,"/merge:.reloc=.data")
#pragma comment(linker,"/ignore:4078")
however, increases it to 47 bytes in total.

I also tried removing unneeded libs from the "object/library modules", however this has no effect. I've seen people make 3kb sized exeutables from MSVC6, how do I do the same?

EDIT 2 **
Woot, it seems that by playing around with the linking settings a little more i was able to get the filesize down to 4 kb, does anyone know how to get rid of that padding that evens it out to 4 kb?

Did you set it with the pragma align directive?

[quote author=MyndFyre[vL] link=topic=17174.msg174869#msg174869 date=1195193972]
Did you set it with the pragma align directive?
[/quote]
d'oh. I feel kind of stupid now. I guess we all have those moments.

EDIT***
Grrr. It's no use. The compiler only accepts alignment in powers of 2, and even worse, it seems as if no matter how much lower I put it, it always comes out with a greater end filesize then with 4096. It seems like the lowest I can get it to is 3.00 kb without any code (oh well), where the most I can theoretically save is about 756 bytes. I guess it's not worth it.

[quote author=brew link=topic=17174.msg174864#msg174864 date=1195174421]
#pragma comment(linker,"/opt:nowin98")
seem to shrink the filesize by 6 bytes.
[/quote]

If nothing else bars Win9x, I don't see that as worth 6 bytes.

[quote author=Joe[x86] link=topic=17174.msg174880#msg174880 date=1195298851]
[quote author=brew link=topic=17174.msg174864#msg174864 date=1195174421]
#pragma comment(linker,"/opt:nowin98")
seem to shrink the filesize by 6 bytes.
[/quote]

If nothing else bars Win9x, I don't see that as worth 6 bytes.

[/quote]
This is incorrect. Win9x can still run these executables perfectly, just slower.
From MSDN:
[quote]
WIN98 | NOWIN98
WIN98 and NOWIN98 control the section alignment in the final image. For Windows 98 applications, it is optimal to align sections on a 4K boundary to improve load time (allows Windows 98 memory manager to cache executable images with a minimum of wasted space). This is on by default in the linker, so you need to specify /OPT:NOWIN98 to get a trimmed-down (but slower on Windows 98) version of the application.

WIN98 is on by default. WIN98 is not on when:

/ALIGN is used.

/MACHINE does not target x86.

/SUBSYSTEM specifies something other than WINDOWS or CONSOLE.

/OPT:WIN98 is not enabled by default for images that would grow (according to the average growth equations, below) by more than 25 percent. In other words, /OPT:WIN98 would not be enabled for smaller images. You should enable /OPT:WIN98 explicitly to ensure that you are not affected by this tuning. Specify /OPT:NOWIN98 to get a smaller (but slower on Windows 98) version of your application.

The enhancements in Windows 98 only work when the sections in a portable executable image begin on a page boundary. The /OPT:WIN98 option performs the necessary file alignment.

If you are building components that run only on Windows NT or Windows 2000, you should use /OPT:NOWIN98.

This change does not impact loading of images or the working set of the process. The only impact is to the on-disk size.

The following helps you compute the average growth of an image using /OPT:WIN98:

The average wasted space for 4096-byte file alignment can be characterized by: count-of-sections-in-image * 4096/2

The average wasted space for the current 512-byte file alignment is: count-of-sections-in-image * 512/2

The growth is therefore:

count-of-bytes-Growth = count-of-sections-in-image * (4096/2 - 512/2)

or, simplified,

count-of-bytes-Growth = count-of-sections-in-image * 1792

However, this does not take into account the fact that the image header must be padded to the section alignment. Since the header is always 512 byes or less, the extra growth is a constant of 4096 - 512, or 3584.

average count-of-bytes-Growth = count-of-sections-in-image * 1792 + 3584

maximum count-of-bytes-Growth = count-of-sections-in-image * (4096 - 512 + 3584

To get the count of sections, use the DUMPBIN tool on an executable file. The summary will give you a list of sections in that image. Typically, you will see from 3 to 5 sections added to that value.

The only time you should not use /OPT:WIN98 is when your portable executable image is very small. Even if an image is slated for downloads, the wasted space is zero-filled and compresses well.
[/quote]