Newsgroups: comp.os.msdos.djgpp
Date: Mon, 15 Jul 1996 12:10:59 +0200 (MET DST)
From: Mark Habersack <grendel AT ananke DOT amu DOT edu DOT pl>
Reply-To: grendel AT ananke DOT amu DOT edu DOT pl
To: "Alaric B. Williams" <alaric AT abwillms DOT demon DOT co DOT uk>
cc: djgpp AT delorie DOT com
Subject: Re: a.out sections
In-Reply-To: <837279840.14708.0@abwillms.demon.co.uk>
Message-ID: <Pine.NEB.3.93.960715115844.22673A-100000@ananke.amu.edu.pl>
References: <Pine DOT NEB DOT 3 DOT 93 DOT 960712124109 DOT 16468B-100000 AT ananke DOT amu DOT edu DOT pl> <837279840 DOT 14708 DOT 0 AT abwillms DOT demon DOT co DOT uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sat, 13 Jul 1996, Alaric B. Williams wrote:

> With virtual memory, though, you sort of have that anyway; anything in
> your data sections will get loaded at startup, but if memory gets
> tight, it'll soon swap out if you don't use it much. It will come back
> into memory on demand. With VM like that, there's no need for any kind
> of overlay-like system.
That's right, but what I had in mind is creating, say, a multi-lingual
application with support for, let's assume, 5 languages. There would be some
fat error messages, hints, menu labels etc. Then loading it into memory at
once would clutter it while, in most cases, user selects the language only
once - the rest is being read into the memory and left there unused. It surely
puts some overhead on the program startup. Besides you cannot always count on
virtual memory. If one uses cwsdpmi running in ring 0, there is no such
memory. Another advantage of having separate "resource" section would be ease
of modification of all the stuff stored there.

> 
> Example: my game uses loads of data: samples, animations, images, AI
> brainmaps, you name it. They're all stored in compressed archive files
> on disk. At startup, the game loads all this into 'memory', which of
> course will be mostly swapped out (When it's finished, anyway. At the
> mo, we have less than 1 meg of data... that'll start to rise as our
> graphics god gets his arse into gear and renders some animations...)
> 
Right. In this case you *ALWAYS* have a chance that the data in memory will be
used - there's no possiblility a part of it will stay untouched. So it makes
sense loading it all together.

> This means that all that data is available on demand, pretty quickly,
> without the overhead of something like "void *load_resource(int
> number);".
But still we must keep in mind that there are people all over the world that
run our djgpp progs on machines with 2 or 4MB of RAM - and that's another
reason resources are a good solution. As to overhead, reading a resource into
memory would require (in the best case) two disk accesses and in the worst
case 3 - not that much.

Greetings, Mark

> I have become... Comfortably numb...
  ^^^^good song ;-)))

/*******************************/
/** So here I am once more... **************************************/
/** When you grown up and leave your playground, where you kissed **/
/** your Prince and found your Frog - remember the Jester that    **/
/** showed you tears, a Script for Tears... ************************/
/*********************************************/