Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!husc6!bu-cs!mirror!prism!rob
From: rob@prism.TMC.COM
Newsgroups: comp.sys.ibm.pc
Subject: Re: PC graphics Drivers
Message-ID: <206900145@prism>
Date: 9 Dec 89 18:36:00 GMT
References: <2973@plains.UUCP>
Lines: 45
Nf-ID: #R:plains.UUCP:-297300:prism:206900145:000:2200
Nf-From: prism.TMC.COM!rob    Dec  9 13:36:00 1989



>Does anyone know how to set up a system of "drivers" or overlay type files 
>in turbo c?  Something like borland uses?

>As far as I can tell, I could simply compile each routine, remove all
>non-pertinent information to the execution, and save it.  And then,
>allocate memory, load that modified .OBJ file, and execute it.  But
>if the routine uses EXTERNAL references, then I'm stuck because of the
>dynamic memory problems.  Is there anyway to avoid this or, at the
>least, could someone point me towards a reference on the format of
>.OBJ files so that I could find out how external references are 
>fixed.  

   I successfully did something like this a while ago. My memory's fuzzy
on the details, but the method was basically this:

   I compiled each 'driver' to a standalone .EXE file. Each driver had
within it, a table which contained the addresses of all the routines in the 
driver. 

   The 'host' program would load the driver into memory using the DOS
load overlay function (a subfunction of the load and execute function).
It would then make a call to the driver's entry point. The driver would
do whatever initialization it needed and return a pointer to its table of 
routines. The host program could then call these routines as needed, and
even unload the driver when it was done.

   The information needed to make this work (like the driver's entry
point and the amount of memory it needs) is contained in the .EXE 
header, so you need to know the layout of that. Most DOS programmer's 
guides have this information. 

   If the driver uses DOS for disk IO or memory allocation, you may also 
need to update the DOS Current PSP flag when you call the driver. The 
mechanics of doing this aren't well documented, but aren't really difficult 
either.

   This sounds messy, but it wasn't that hard to do; as I remember, it
took only week or two to set up. My feeling is that it's a simpler method
than attempting to modify and execute .OBJ files. It does, however,
require that your driver be compilable to a standalone .EXE file. If
your drivers currently make heavy use of globals in the calling program
(which will no longer be there to link with) you may need to modify
them.