From: "Christopher Nelson" <paradox AT gye DOT satnet DOT net>
To: <djgpp AT delorie DOT com>
Subject: Re: Hello World and File size
Date: Wed, 9 Jun 1999 20:14:25 -0600
Message-ID: <01beb2e6$f6451fa0$LocalHost@thendren>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.71.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3
Reply-To: djgpp AT delorie DOT com


>The other question is of runtime efficiency. Similar issues apply
>here to with the executable size: if you only have one program
>in use at a time, the DLL approach wastes memory. Since DOS is
>a single-tasking system, dynamic linking won't provide much
>benefit here. The big win is in cases like a recursive make,
>if you could have make, gcc, cc1, cpp, etc, all sharing a single
>runtime, but that needs serious support from the OS. Windows
>can share a single copy of the DLL code between multiple programs,
>and Linux goes even further by doing copy-on-write, which allows
>you to share readonly data as well, but this sort of thing would
>be an absolute nightmare to implement from inside a DOS program
>(I'm not even sure whether DPMI is flexible enough for it to
>even be possible).


There are a couple of large issues that you didn't mention, which bear some
thought in line with DLL's.

    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.  With a properly written DLL system, this
duplication need only persist while the code is actively needed.

    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.  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.

    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.

    And to address the final parts, the OS doesn't really need to be too
terribly involved in the dynamic link process.  In fact, it can know nothing
about it and be perfectly happy.  This does preclude full multitasking and
DLL's, for those operating systems which support it, but taking DOS as an
example, it is rather trivial to build DLL's into DJGPP.

    The Operating System is more of an obstacle than a help when dealing
with DJGPP, since you have to load in real-mode, go into protected, and
perform various things in both stages, etc.  Once the program is in
protected mode it is happy, and still has access to all the important DOS
stuff that is needed.  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.  Granted, this is overhead, but even without pre-emptive
threading, an intelligently designed, message-based system could easily
allow you to cooperatively run multiple "programs" at the same "time."  The
benefits of this are many, and allow each facet to be loaded when needed,
and unloaded when not.  This can be especially important for a game that has
different "parts" in it, because the last thing you want is for the DPMI to
swap your textures to disk, but you still want to be able to maintain the
flexibility of the game.

    I suppose that the ultimate decision should depend on the specific needs
of the application, and what makes the most sense.

        -={C}=-