From: "Anthony.Appleyard" <MCLSSAA2 AT fs2 DOT mt DOT umist DOT ac DOT uk>
Organization:  Materials Science Centre
To: djgpp AT delorie DOT com
Date:          Thu, 19 Feb 1998 15:37:14 GMT
Subject:       overlaying
Reply-to: Anthony DOT Appleyard AT umist DOT ac DOT uk
Message-ID: <1573BE346B2@fs2.mt.umist.ac.uk>
Precedence: bulk

  "Curtis W. Moore" <cmoore AT 1st DOT net> wrote (Subject: DosDoom).

  Doom is a big game. That raises the subject again: what is the progress on
run-time overlaying for djgpp?, for when a big program has a big subroutine
that is called sometimes but not very often. If ABC.CC spawn()s XYZ.CC, ABC.CC
can send a fair amount of information to XYZ.CC as call parameters, but XYZ.CC
can only send back a 2-byte exit(x) value, except by the time-wasting process
of putting the information in a file. I thought of doing this:-
> ABC.CC reserves(_go32_dpmi_allocate_dos_memory() etc) some conventional
> memory, whose address it sends to XYZ.CC as hex chars as a call argument,
> and XYZ.CC can leave information in that area for ABC.CC to read.
  but I was told "no, ABC's conv mem is swopped out while XYZ.CC is running".
  Is there anywhere in conventional memory, say somewhere among DOS's junk,
any spare space where XYZ.CC could leave matter for ABC.CC to read?
  Perhaps XYZ.CC could write the matter to screen RAM and ABC.CC could read it
back from screen RAM. It would mean binary junk flashing on the screen, but I
would have to put up with that. I have used screen RAM as extra working space
in ancient times on a Commodore Pet.