Mail Archives: djgpp/1999/06/10/12:21:08
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 -