Message-ID: <32432BD4.1ABE@spy.isp.nsc.ru>
Date: Fri, 20 Sep 1996 16:42:12 -0700
From: Ryzhenkov Ilya <ilya AT spy DOT isp DOT nsc DOT ru>
Organization: ISPh SB RAS
MIME-Version: 1.0
To: djgpp AT delorie DOT com
Subject: Loadable Modules
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Greetings !

Ok guys, thanks for your response !
First, i'll post overview of RE's. 
I'm sorry, but copyrights of answers was not preserved ;))

========================== Overview =================================
It's something we all dream of. We would try and find the time to
write it for DJGPP if we understood the COFF format.
Well, according to Leathal, we have the COFF format right in front of 
us. We only must ask him to type it in for us ;-)

The following are some ideas on how to resolve external references on
run-time :

1. Use debug info :
   You'd need to put some level of debug info in the executables, so as
   to find them symbols.

2. Use runtime linker
   Change the stub to be a "runtime linker",
   such that we just link in standard .o and .a files. Unresolved
   references point to the NULL minefield, in case they get called before
   being resolved.

Opinion : 
It's better to load runtime linker as a simpler module at runtime.

Opinion : 
You would need a special stub.  The new stub goes
into protected mode in the usual way, then checks to see if the loader 
is already present and either invokes it with the
appropriate parameters to load the rest of the program, or loads it 
from somewhere on the path, much the same as the stub does for cwsdpmi.

Stuff proposed :
There should be the power to query a module's symbols and access
them numerically . Thus, we can do things like printer drivers as well.

==================== End of Overview ==================================
So we have to choose the way to implement loading scheme.
Now I'd like to get HIGHLY ARGUMENTED opinions on the above ways
and (may be) another ideas of how to do it.

I see the following needs for now :
1. We must either use .o & .a files as modules or in some tricky way instruct   

   linker not to generate "unresolved reference" error and process them 
   in some way.
2. We need COFF executable format as well as .o and .a formats
3. We need an idea of API.
4. We need an idea of how to create module dependencies.
   i.e. LPT driver must be loaded before Printer driver, so if i ask
   to load hpdj520.drv (HP DeskJet520 Printer driver) and LPT.drv is not
   loaded yet, kernel must first load LPT.drv and then hpdj520.drv. Clear?

I have following questions :
1. Does go32 sources available from anywhere ?
2. What is the startup sequence of djgpp-compiled program ?
   I mean, the sequence of calling constructors of static and global objects,
   calling main and other stuff.
3. Can you imagine DJGPP operating system on the top of DOS ? ;-)

							Sincerely yours, Ilya

-----------------------------------------------------------------------------
mailto://ilya AT spy DOT isp DOT nsc DOT ru                            http://spy.isp.nsc.ru
on IRC (EFNet) as "Orangy" usually on #mirc #novosibirsk or somewhere else ;)