On Tue, 5 Aug 1997, B. Nagel wrote:
> > To simplify things, could we compromise by saying that when a library is
> > used, the entire thing is loaded, but also that up to 256 entry points may
> > be specified?
>
> Okay, I guess that works.
Good. I thought of another example: Suppose a library contained
fonts--maybe a roman, italic, and bold version of the same font. In that
case there would be three "entry points" into the library.
> > .dw ProgLen ; number of bytes to load into _asm_exec_ram
>
> I dont think this is necessary, because a shell should be smart enough
> to figure this out on its own.
Maybe it's not _necessary_, but it's a good idea. Think about how easy it
would be to put this into BC, then put the start address into AHL and
start looping. Besides that, since there's no fixed location for the
import table (etc), and since there's no need to waste memory in
_asm_exec_ram by loading the import table, this provides a good way for
the programmer to control exactly what gets loaded. Here's an example:
A86Prog:
blah
foo
smee
grep
ret
Imports:
sfasfaf
yiyuiyuu
bnmbnmbn
If the loader automatically loads everything from A86Prog on, then there
would be space wasted by the import table.
Additionally, knowing the length of the code segment would put a check on
write-back (so that the import table is not overwritten, for example).
*** I think I need to emphasize the difference between a shell and the
loader. In the scheme I envision, a shell would be essentially the same
as your AShell is now. All it would do is find programs, display their
titles and icons, and call Asm() or A86() to run them. A86() would be our
plug-in loader that would take care of library fixups, data write-back,
and anything else we think of that belongs in the loader.
> > AsmStart: ; program run when invoked via Asm( )
> > ; This could print an informative error message,
> > ; actually do something useful, or just return..
> > ret
>
> I was thinking, if a prog used libraries, it could simply replace nop
> with ret.
But this way is much more versatile, and 4 bytes is not that much to pay
for the flexibility this method offers.
>
> > The title string consists of a length byte, the text bytes, and a null byte.
>
> the length byte isnt necessary, and AShell didnt find it necessary.
Really? Is there a function that... oh yeah, there is. Never mind. I
was confused for a while.
>
> Your import table is perfect :)
>
Great! I tried to make it compact and easy to process. Does anyone else
see any problems with the import table?
> > .dw LibLen ; number of bytes to load
> > .dw pStartAddr ; pointer to first address to load (.org 0)
>
> These are needed either, since libraries cant executed.
>
Those aren't for execution. Those are for loading BC and AHL and looping
to stuff the library's code into _asm_exec_ram. Like I said before, we
shouldn't count on the "code" being everyting between the tables and EOV
(end of var).
Does anyone else have any comments? Once again, the page is
http://www.cis.ohio-state.edu/~eble/libform.html
--------
Dan Eble (mailto:eble@cis.ohio-state.edu)
(http://www.cis.ohio-state.edu/~eble)