From: "Charles Sandmann" 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.