www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1996/08/16/07:45:43

Date: Fri, 16 Aug 1996 13:41:42 +0200 (MET DST)
From: Mark Habersack <grendel AT ananke DOT amu DOT edu DOT pl>
Reply-To: grendel AT ananke DOT amu DOT edu DOT pl
To: Elliott Oti <e DOT oti AT stud DOT warande DOT ruu DOT nl>
cc: djgpp AT delorie DOT com
Subject: Re: DJGPP's .exe's are TOO large
In-Reply-To: <3210B921.5CCE@stud.warande.ruu.nl>
Message-ID: <Pine.NEB.3.95.960816133628.4971A-100000@ananke.amu.edu.pl>
MIME-Version: 1.0

On Tue, 13 Aug 1996, Elliott Oti wrote:

>Alexander Lehmann wrote:
>> 
>> : 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
>> 
>
>Some standard functions are much larger than others:
>printf() smacks 30k extra. Use puts() instead if possible.
>Compiling with -ffast-math , -fomit-frame-pointer reduces 
                              ^^^^^speaking of this one. I read that this
switch causes WinXX to break down??? Well, I use it all the time and so far no
failures!! So have anyone of you had any problems of this nature with the
switch? And if so, in what environment (I checked Win3.11, Win95 & WinNT -
everything's OK)

>size too. (Of course, these switches carry their own attendant
>dangers).
>But really, the size problem isn't too bad. There's a bare minimum
>of around 50k for the extender code, but the PMODE 2.5 assembly
You mean the stuff that remains resident in memory, right?

>extender by Tran (Thomas Pytel), the best freeware assembly extender 
>around, also adds 30k extra to the .exe file. So much for the 
>compactness of assembler. 
>I think a lot of dead weight after that comes from certain standard
>C functions like printf(), and the error-handling associated
>with them. Trial and error should show which ones are the worst.
Checking up the sizes of .o modules in libc.a should do here...
But, hey! Hard disks are getting bigger and bigger today, so why so much noise
about the space? "Much ado for nothing".

Mark

/************************************************************/
/** Maybe it was infatuation or the thrill of a chase?   **/          
/** Maybe you were always beyond my reach and my heart **/
/**   was playing safe?                     ***********/ 
/** But was that love in your eyes I saw, **/
/**   or the reflection of mine?        **/
/** I'll never really know for sure,  **/
/** You never really gave me time!  **/
/** Won't you give me that time?  **/ 
/**          "Cindirella Search" **/
/********************************/
Visit my homepage: http://ananke.amu.edu.pl/~grendel

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019