From:	"Christopher Nelson" <paradox AT gye DOT satnet DOT net>
To:	<djgpp AT delorie DOT com>
Subject:	Re: Hello World and File size
Date:	Thu, 10 Jun 1999 17:03:06 -0600
Message-ID:	<01beb395$66e78320$LocalHost@thendren>
MIME-Version:	1.0
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 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.


Take Quake as an example.  It typically uses at LEAST 3mb for the surface
cache, another couple of megs for the light cache, plus as much memory as
you have for textures, and finally, of course, world files and models.  If
Quake were more than just a shoot-em-up, (say it had some strategic elements
to it that allowed you to "own" a part of the world, build stuff, etc. --
say you can also then go shoot-up the bad guys like a typical Quake game)
then it would probably require an entirely different interface for that
part.  If the interface were windowed, that could take up quite a good bit
of code space, plus it's data space, etc.  If the two were written as DLL's
, you could load what you needed, when you needed it, and then unload it
when it was done.

What I'm talking about is conserving your OWN memory space.  Sure we've got
big new hard drives and lots of RAM, but not everybody does.  And, a lot of
people who run DJGPP stuff run Windows in the background.  I don't have to
tell you how much memory that eats.

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

look at Windows.  How much junk is sitting around on your Windows machine
that you don't ever use, and never will?  How many DLL's that have zero use?
Okay, Now imagine that you've got tons and tons of DJGPP programs, each one
with it's own copy of the same stuff linked into it.  Imagine how many megs
would be free if they didn't?  As an example, look at Allegro.  Any decent
Allegro program uses probably 80% of the stuff in the library.  Most of my
programs that link into allegro are at least a meg.  Most of that is
Allegro.  I'm not complaining about Allegro, it's got a ton of useful stuff,
and the size is understandable.  My point is, that if all my progams could
share one copy of Allegro, I'd be saving at least 10-15 MB of space.  And
for me that's alot.

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

what about plugins?  that's one area that really shines with DLL's.  If you
want to write a plug-in with a static program, you've got to recompile it
every time you add one in.

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

My computer is a laptop, p120, 40mb RAM, 1 gig worth of HD.

800mb's of that is used by Windows stuff that I NEED.
Another 100mb's are free, but mostly occupied by swap files, and the temp
space I need for various stuff.  That means I have about 100mb free for my
development partition.  About 50mb of that is occupied by DJGPP -
C,C++,Objective C, and the sources for DJDEV202.  Plus, RHIDE, ZLIB, LIBPNG,
some threading libraries, GDB, ALLEGRO, and a couple other packages I can't
remember.  Then we get about 20-30mb occupied by MY programs and libraries,
plus docs, image files, textures, etc.

That leaves me with about 20mb free at any time.  Most of this is occupied
by zip files that I haven't been able to offload to my zip drive yet.  To
me, a savings of 10-20mb is substantial.

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

No, silly. I think that the stub loader does what it needs to do very well.
The only thing neccessary is a library to do the work.  The stub gets us
into protected mode, and from there we don't need it.  Once the program is
in protected mode it can load the libraries needed.  Granted, this takes a
bit more user cooperation than typical DLL systems, but any programmer who
can't type 'load_lib("allegro.lo");' shouldn't be a programmer.  The library
I have that does this is about 150k, so it's not really that much, compared
with the benefits.

And before you ask, no, you can't use dll functions from the application
loaded by the stub.  What happens is that the exe turns into kind of a big
stub loader, but that's okay because the library export's all the exe
symbols as a public library too.  So in essence, DOS loads the stub, the
stub loads your exe, and your exe loads the app.  Whatever libs are needed
can be autoloaded, or may be loaded before you run the app.

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

I wouldn't agree with that.  I think that they have more advantages,
ESPECIALLY for DJGPP, than disadvantages.  Especially if you are a little
bit intelligent about DLL management.  As was pointed out, DLLs aren't a bad
idea.  However, Window's implementation of them IS a bad idea.

    -={C}=-

- Raw text -