From:	"Charles Sandmann" <sandmann AT clio DOT rice DOT edu>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: DXEs and other OSes
Date:	Thu, 27 Jul 2000 21:23:36
Organization:	Aspen Technology, Inc.
Lines:	21
Message-ID:	<3980a858.sandmann@clio.rice.edu>
References:	<000001bff63d$f661b660$fc9260cb AT morgoth> <397ef117 DOT sandmann AT clio DOT rice DOT edu> <3980802E DOT 67991A7A AT home DOT com>
NNTP-Posting-Host:	dcloan.hou.aspentech.com
X-Trace:	selma.aspentech.com 964752374 3430 10.32.115.107 (28 Jul 2000 02:46:14 GMT)
X-Complaints-To:	postmaster AT aspentech DOT com
NNTP-Posting-Date:	28 Jul 2000 02:46:14 GMT
X-NewsEditor:	ED-1.5.8
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

> So if you make a wrapper for the system and lib calls, you could implement
> a loader that reflected those calls to the host OS, in both systems. Then
> your DXE file would run in its own environment but under both OSs?

This was my original plan for a DXE based DLL.  For all undefined references,
there would be a table of jump addresses which would be filled in by the loader
which refered back to it's own image.  That DXE call wrapper would be created
using a program to examine the DXE and generate a "stub" which contained all
the undefined references (in the right order), so it would be easy for the
loader to do the fixups at run time.  You could then compile the generated
stub and put it into a library.

This was going to be my plan to generate tiny DJGPP images which called some
external LIBC DXEs as an option - so you could just replace the libraries 
when a new release came out.  There were some problems with DXE nesting and
cross references, and static variables, but they looked like they could be 
solved.

Then there was the plan to make these dual format Win32 console and DJGPP
extended apps ... but time is expensive and the need disappeared...  It might
have happened if it had not rained 18" in 6 hours in May of 1995 in Lousiana.

- Raw text -