www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1996/02/22/22:09:20

Xref: news2.mv.net comp.os.msdos.djgpp:1335
From: Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Why bigger exe size with LIBGRX+BCC2GRX v2.0?
Date: Mon, 19 Feb 1996 14:08:36 CST
Organization: Rice University, Houston, Texas
Lines: 19
Message-ID: <3128d8c4.sandmann@clio.rice.edu>
References: <4g3mp0$qit AT usenet DOT srv DOT cis DOT pitt DOT edu>
Reply-To: sandmann AT clio DOT rice DOT edu
NNTP-Posting-Host: clio.rice.edu
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

> I don't know if this is due to djgpp v2.0, or due to its graphics libraries.
> I'm wondering why I have much bigger exe size with v2.0 than v1.x.

It may be a little of both.  With GRX 2.0, all of the bank switching must
be done in the code, so it's more complicated.  All of the regular V2 DJGPP
extender stuff is in libc now (instead of GO32) so there is a size increase
there also.  There were also LOTS of new features and functionality added
which increased the code size.  For example, the typical "hello" program
in V1.x was a 10K a.out, 18K stubified, 85K bound w/GO32.  In V2.x without
size optimizing functions, it is a 30K a.out, 32k stubified (good on DPMI
systems) and 57K with CWSDPMI imbedded (always standalone).

You say "wow, how did the a.out size jump from 10K to 30K?" - doing a link
map quickly answers the question.  There is now exception handling, 
command line parsing, environment variable handling, FPU detection and
emulator loading, etc, much of which used to live in GO32.

There are also compiler differences (I have seen 2.7.2 make code 50% bigger
and 50% smaller than 2.6.3) which may explain some of your much larger changes.

- Raw text -


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