Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!crdgw1!uunet!pilchuck!dataio!fnx!nazgul!bright
From: bright@nazgul.UUCP (Walter Bright)
Newsgroups: comp.os.msdos.programmer
Subject: Re: Overlay usage...
Message-ID: <290@nazgul.UUCP>
Date: 28 Mar 91 15:30:41 GMT
References: <31248@usc>
Reply-To: bright@nazgul.UUCP (Walter Bright)
Distribution: usa
Organization: Zortech, Seattle
Lines: 29

In article <31248@usc> jlowrey@skat.usc.edu (John 'Fritz' Lowrey) writes:
/	The theory behind overlays and their implementation using the 
/linker is not difficult.  What I would like to know is:

I'll try to answer your questions as they apply to Zortech's VCM virtual
overlay system.

/	1:  Once the overlay module is no longer needed, is the memory
/		allocated to it freed to the data segment?

Yes. In fact, when a new overlay needs to be loaded, the VCM module actually
does call malloc. When malloc runs out of space, it calls VCM to try and
discard overlays until the malloc succeeds.

No separate swap buffer needs to be created for VCM.

/	2:  In a related question, I assume procedures from one overlay
/		module may call those in anther (which seems fairly 
/		inefficient, but logical), how is the memory for these
/		overlay functions dealt with?

Yes, overlays may call each other in any way, including through function
pointers and through the virtual function table (for C++). Only one
overlay at a time *needs* to be resident, that is the one that is currently
executing. Other overlays are shuffled around as needed by malloc.

The complete source code to the VCM management routines is provided with
the Zortech Developer's Edition. For more information, call Zortech at
800-848-8408.