EXE sizes

DOS specific questions.
dodicat
Posts: 7983
Joined: Jan 10, 2006 20:30
Location: Scotland

Re: EXE sizes

Post by dodicat »

the tiny c compiler is 1536 bytes for:

Code: Select all

 
int main(void)
{
    printf("HELLO\n");
    system("Pause");
}
http://bellard.org/tcc/

It includes tiny_impdef to view the functions inside a dll (.def file).
angros47
Posts: 2323
Joined: Jun 21, 2005 19:04

Re: EXE sizes

Post by angros47 »

With MBASIC, the program

Code: Select all

print "Hello World"
compiles to a .com file of 203 bytes (it's not misspelled: bytes, not kilobytes!)
DOS386
Posts: 798
Joined: Jul 02, 2005 20:55

Re: EXE sizes

Post by DOS386 »

6ar453v3n wrote:If I write a "hello world" program for DOS, about how many bytes would the executable be?
16-bit ASM: cca 20 Octet's
16-bit HLL: cca 1 KiO to 10 KiO
32-bit HLL: cca 30 KiO to 300 KiO
Quack-64: cca 10 MiO (YES it runs in DOS http://www.bttr-software.de/forum/board ... hp?id=8785)

This had been discussed already 1'000'000'000'000 times:

- http://www.freebasic.net/wiki/wikka.php ... DOS#item24
- http://freebasic.net/forum/viewtopic.php?t=11757 (2008-Jul)
- http://www.bttr-software.de/forum/board ... p?id=13629

Q: Why are DGJPP FPC FBC executables bloated?

A: Because the compiler toolset (actually the linker) adds much garbage to your code:

- DOS extender or loader of it and startup code
- exception handling
- commandline globalization
- source level Linux emulation (DGJPP and derivatives)
- C library (except FPC)
- PASCAL library (only FPC)
- NTVDM + NTLFN garbage
- FPU initialization and emulation, even if your code does not have a single float variable or operation
- calendar
- list of outdated junk DOS kernels
- debug stuff
- empty areas ("alignment optimization")
- QB compatibility + FB dialect stuff (only FBC)
- TP/BP and Delphi compatibility stuff (only FPC)
...
(and much more)

Q: Can it be made better?

A: YES, but nobody cares.

Q: Can I reduce the size of my EXE's without changing the compiler?

A: YES, slightly, see link above.

Q: Should I pack my executables with UPX?

A: There is no final correct answer. Be aware that UPX doesn't remove any bloat, it just compresses existing one, and adds the decompression stub (in fact extra bloat). This had been discussed already 1'000'000'000'000 times:
- http://www.xaver.me/drdoswiki/index.php ... ress#toc20
- http://wiki.freepascal.org/Size_Matters
Last edited by DOS386 on Oct 27, 2014 7:21, edited 4 times in total.
marcov
Posts: 3462
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Re: EXE sizes

Post by marcov »

FPC has legacy too with TP (1 version, only TP/BP7) and Delphi (but various versions)
Aaronm82
Posts: 25
Joined: Sep 19, 2014 23:29

Re: EXE sizes

Post by Aaronm82 »

I reduced the .EXE filesize of my programs by nearly 50% using "32Lite" or "UPX" for DOS.

Nobody has mentioned that in this thread, so I thought I would throw that out there for anybody reading it. Yes, the FBC produced .exe files are gigantic, but this will at least make a dent in reducing their size.

See this link for available DOS exe compressors.

http://reimagery.com/fsfd/arc2.htm#exepck


UPX for DOS, and 32lite seem to work fine for compressing FBC exe's.

LZexe works good for plain old QuickBasic 4.5 exe's.
marcov
Posts: 3462
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Re: EXE sizes

Post by marcov »

Packers are well known. But they have their own problems, like that there are buggy versions, they generate increasing amounts of antivirus false positives.

In theory they also start slower(*) and frustrate the VM, though I doubt the latter matters much with current memory sizes (and with DOS, where the VM system doesn't memory map binaries). OTOH, EXE size matters even less with current SSD and HD sizes :-)

I usually prefer to simply distribute with an installer or .zip (or BZ2 if you want to make it tight) for transfer, and run uncompressed, but properly stripped and smartlinked (--gc-section) binaries. Most of the reported UPX gains simply strip debug info that can also be stripped by other means.

(*) While not that important on current systems, slower starting might be important for stuff like make, as and other files called umpteen times during the buildprocess.
Post Reply