Xref: news2.mv.net comp.os.msdos.djgpp:1335 From: Charles Sandmann 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.