Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!munnari.oz.au!ariel!ucsvc.ucs.unimelb.edu.au!wehi.dn.mu.oz!baxter_a
From: baxter_a@wehi.dn.mu.oz
Newsgroups: comp.sys.amiga.programmer
Subject: Re: DOS Overlays
Message-ID: <1991Jun28.225136.24641@wehi.dn.mu.oz>
Date: 28 Jun 91 22:51:36 GMT
References: <6124@walking.pub.uu.oz.au>
Organization: Walter & Eliza Hall Institute
Lines: 40

In article <6124@walking.pub.uu.oz.au>, david@walking.pub.uu.oz.au (David Le Blanc) writes:
> 
> The other day, I decided to have a look at overlays. I have found out
> the following.
> 
> 1) When Blink creates overlays, it generates an 'overlay' table, and
>    and 'overlay' hunk for the loader.
....> 
> 2) When your program is loaded, you find that the ROOT overlay is
>    in memory (and all your data) and an overlay table. Your load file
....> 
> 3) You can load in more chunks of your program via calls to 'Seek' 
>    since you know the address of the File Handle, and the overlay 

>    This code here says LoadSeg(NULL,#1,FileHandle)(d1,d2,d3).
> 
>    I would assume that #1 is a pointer to the loaders hunk tables 
>    for relocation purposes (Nice of it to leave it lying around :)
> 
>    Can anyone explain WHY's, and maybe describe the unknowns #1 and #2?
>    Why is #2 never accessed? (I would probably know when I understand
>    what it points to..)
> 
>    Does WB2.0 have a direct call you can make to 'LoadSegFromFileHandle()'
>    (in the same way it has OpenLock() and its ilk)
> 
>    Any pointers to GOOD documentation about all this would be greatly 
>    appreciated!
> 
> Thanks Everybody!
>    David


While I can't follow your disassembly, I have had much trouble with the SAS/C
 overlay manager, and SAS/C have offered to send my a pre-beta of
one that is supposed to work properly. I have not received the replacement 
Blink, so I can't comment on it. Sounds like you should enquire. The
Sydney people are quite helpful.

Regards Alan