Xref: news2.mv.net comp.os.msdos.djgpp:7202 From: lehmann AT mathematik DOT th-darmstadt DOT de (Alexander Lehmann) Newsgroups: comp.os.msdos.djgpp Subject: Re: DJGPP's .exe's are TOO large Date: 13 Aug 1996 13:50:30 GMT Organization: Technische Hochschule Darmstadt Lines: 35 Message-ID: <4uq176$1ndo@rs18.hrz.th-darmstadt.de> References: <4uk6qr$795 AT utdallas DOT edu> <4upl1g$r23 AT wnnews1 DOT netlink DOT net DOT nz> NNTP-Posting-Host: fb0409.mathematik.th-darmstadt.de To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Steve Piner wrote: : In article , : Mark Habersack wrote: : : On 11 Aug 1996 lafitte AT utdallas DOT edu wrote: : : : : > The program : : : >main() { : : > : : >} : : >compiles to something like 30 or 40k! What gives. : ...[Stuff about startup code snipped] : : If you're making little apps then better stick to real mode and TC++ or : : something similar. If you really want to create small 32-bit apps and the : : executables are too big for you - get djp, it will save about 60% of the : : space occupied by an unpacked executable. : Another little trick is to strip your Coff files. Gcc adds some : rudimentary debug info even when compiling without the '-g' option. : If you compile to Coff - 'gcc -o foo ...' - rather than exe - : 'gcc -o foo.exe ...' - then you can strip the resulting binary and use : stubify to turn it into a much smaller exe. Or you can strip the COFF binary and recreate a new .exe with coff2exe (or if you have only the .exe first exe2coff, strip and then coff2exe). This works even with executables that are acidentally distributed unstripped (jpeg386 did that at one point, I think). bye, Alexander -- Alexander Lehmann, | "On the Internet, alex AT hal DOT rhein-main DOT de (plain, MIME, NeXT) | nobody knows lehmann AT mathematik DOT th-darmstadt DOT de (plain) | you're a dog."