: Errm, what's "Introl object file format"? You mean "Intel"? Well as86/ld86
: don't understand that. They use their very own format for *.o files.
The Introl object file format is a format from an older
hardware development system, named Introl. The name is documented
in Bruce Evan's source code to as86 and ld86. I have decoded this
format, and it of course has complete information for imported and
exported symbols, as well as all code with relocation information.
:
: > How does this fit with your ideas of DLL's on ELKS?
: This is all well and good but it doesn't appear to address the real problem
: with 16bit DLLs. The fact that you're limited to 64k of text/data.
Well, yes, all ELKS binaries are limited to 64k code and data. The cool
part about the design I'm proposing is that only the linked-to symbols
and their associated code gets loaded. This must still fit into 64k * 2,
just like a statically linked version of the same.
:
: ELF DLLs are very good, and work very well indeed. They even have
: facilities for hiding exported global symbols within the DLL so that
: they don't interfere with your program (eg you can have an int called
: "time" or define your own "tcgetattr" without problems)
the ELKS "Introl" DLL will allow this also
BUT you need
: enough space in your memory map to load the entire library; the current
: elks libc.a file is 80k. :-/
The difference between Introl and ELF format is that the latter
was developed for modern operating systems that use mmap() mechanisms
to map the binary into memory, and then page-fault in the code as required.
In the ELKS format, all run-time required DLLs are searched for import symbols
needed, and only the code segments with those symbols exported are read
into process space memory. No mmap() mechanism is used, the down side
is that the entire library may need to be read, but with code file sizes max'ing
64k and the library 80k, this is no big deal...
The other difference between ELF and Introl is that the relocation
info in ELF is in a separate section, which allows pure code sections to
be mmap()ed in without any reads, whereas Introl format encodes code,
data and relocatable info in the same section, and it must be read to decode it.
The COOL thing about what I'm proposing is that we COULD have
full-blown DLL's if we want, with complete automatic symbol resolution and minimal
overhead. Dlopen()/dlsym/dlclose could also be implmented, if desired, although
it poses a few more problems. We are still limited to the basic 64k segment
limititations, and no ELKS kernel mods are required.
Greg
