On Sat, Sep 12, 2020 at 8:39 PM Niccolo Medici <niccolomedici@gmail.com> wrote:
> Right. In the DOS days, if we wanted to provide an extension to some
> app, we'd write it as a TSR ("terminate and stay resident")
TSRs were more of system extensions rather than app extensions. In the
context of a Lua host, which wants to load a library, loading a
library as a TSR would be sub-optimal, because TSR will "stay
resident" even after the Lua host terminates.
Overlays seem more appropriate here, which is not to say that would be
very easy to do. The current specification of loading a "C library"
is: "[...] uses a dynamic link facility to link the application with
the library. Then it tries to find a C function inside the library to
be used as the loader. The name of this C function is the string
"luaopen_" concatenated with [...]". Neither "link" nor "find" was
part of the overlay functionality offered by MS-DOS. All it did was to
read an executable file from disk to a specified memory location and
fix relocations, but not "link" or "find" anything.
Interestingly, after some googling I found that a lot of what would be
required was already done in the "DosDLL" project [1]. It does use the
MS-DOS overlay functionality, and implements Windows-style
LoadLibrary() and GetProcAddress() functionality on top of it. So, in
principle, the "find" part is there. The "link" part, however, is
mostly not there, in the sense that the loaded library itself has no
access to the host's symbols, or any other dependency (which would not
be loaded automatically anyway). DosDLL was itself inspired by MikDLL
[2], which is also based on MD-DOS overlays, and which seems to
address the "link" problem somewhat better, but clearly still falling
short of doing everything that is meant by "a dynamic link facility to
link the application with the library".
Cheers,
V.
[1] http://www.kiezsoft.de/download/dosdll.zip
[2] https://www.hornet.org/code/utils/compiler/mikdll.zip
If we were to truly care enough to put the effort into it, we could compile the modules with thunks that could be patched-up at load time to access functions out of the main executable. That is, after all, more or less how DLLs work anyway. Transitive dependencies might still be an issue, of course, but given a 640KB memory limit there's only so far you can really practically go anyway.
Of course, if we were to talk about being practical, you'd be better off compiling the modules you want into the executable directly instead of dynamically loading them.
/s/ Adam
