delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1999/06/10/12:21:08

Date: Thu, 10 Jun 1999 19:18:42 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Christopher Nelson <paradox AT gye DOT satnet DOT net>
cc: djgpp AT delorie DOT com
Subject: Re: Hello World and File size
In-Reply-To: <01beb2e6$f6451fa0$LocalHost@thendren>
Message-ID: <Pine.SUN.3.91.990610190142.20445E-100000@is>
MIME-Version: 1.0
Reply-To: djgpp AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

On Wed, 9 Jun 1999, Christopher Nelson wrote:

>     The first is that, many programs have several facets, and each facet may
> be very different from the others.  Oftentimes you may only use one facet of
> the program at a time, especially if, as you point out, you are running in
> DOS which is single tasking.  However, all the code for this must always be
> in memory at all times: whether it is in virtual memory or in RAM, it still
> occupies space in memory, thus duplicating it's space: one copy on disk, and
> another somewhere in memory.

That's true, but I fail to realize why should a DOS program bother to 
conserve RAM.  At any given time, there's only one active program in 
memory (well, except of nested invocation, but how many times does that 
happen?).  There are TSRs, of course, but these occupy conventional 
memory with only marginal use of extended and expanded memory.

Given that only one program is using memory at any given time, why should 
I go to a great length of using DLLs just to conserve memory that is all 
mine to begin with?  With whom would I share all the memory I'll free if 
I use DLLs?

>     The second is the need for many programs to be quite polymorphic.
> Consider a game that has several different rendering methods availiable to
> it for various hardware optimizations.  Were the program to carry each
> separate rendering package all linked into itself statically, it would be a
> waste of user disk space.

With today's disks, this is IMHO a non-issue.  The largest programs I 
ever saw are 2000 times smaller than the disks you are offered today by 
every PC dealer.  90% of programs are 20,000 times smaller than the disk 
size, even unstripped.

> The larger issue, though, is that the libraries
> may be written so that they can be used transparently by the game.  One for
> OpenGL, one for VooDoo, one for pure software, etc.  If in the future
> another rendering package becomes availiable for the game, then only a DLL
> need be downloaded: versus the full core program's executable.

This is nice in theory, but in practice never works.  By the time a new 
rendering package is available, the other libraries change so much that 
you have to recompile anyway.

>     Perhaps on a new computer with a huge disk and tons of RAM, these
> problems seem somewhat trivial, but those of us who spend a lot of time on
> their laptops, or those who have older computers with small disks and less
> RAM definitely benefit from the modularness that DLL's provide.

Define ``small disk'' and ``less RAM''.  I have just upgraded my home 
machine from 800MB of disk space to 8GB.  I don't remember having any 
problems with the old disks, although I have gobs of DJGPP programs, all 
of them with their own copy of libc.a.  The upgrade was mainly so (blush) 
I could install Windows 9X without deleting too much stuff, and so I 
could install some large games for my kids.

> Since we know exactly what's in a COFF file, all we
> have to do to turn a COFF object into a library is load it up, and store
> it's symbol information in memory.  Then, the next time we go to load an
> application, we can just browse the info and link it in, perform the
> relocations, etc.

So you suggest, in effect, that the DJGPP stub loader will have to know 
about DLLs and perform the duties that DOS cannot do, right?  How much 
will that bloat the stub?

Nobody says that DLLs don't have any benefits.  The issue is that they 
have more disadvantages than advantages, especially for the DJGPP 
environment.

- Raw text -


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