Message-ID: <3980802E.67991A7A@home.com>
From: Mark & Candice White <mhewii AT home DOT com>
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en,pdf
MIME-Version: 1.0
Newsgroups: comp.os.msdos.djgpp
Subject: Re: DXEs and other OSes
References: <000001bff63d$f661b660$fc9260cb AT morgoth> <397ef117 DOT sandmann AT clio DOT rice DOT edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 26
Date: Thu, 27 Jul 2000 18:33:44 GMT
NNTP-Posting-Host: 24.0.127.127
X-Complaints-To: abuse AT home DOT net
X-Trace: news1.rdc1.mi.home.com 964722824 24.0.127.127 (Thu, 27 Jul 2000 11:33:44 PDT)
NNTP-Posting-Date: Thu, 27 Jul 2000 11:33:44 PDT
Organization: @Home Network
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?

Charles Sandmann wrote:

>
> Building them is dependant on COFF based tools just because the builder and
> loader expect that.
>
> > Surely, though, the DXE mechanism involves nothing more than loading a piece
> > of machine code into memory and CALLing it.  Doesn't this mean that as long
> > as the instruction set doesn't change(*), a DXE will be binary portable?  (*
> > I actually expect the function calling mechanism, etc., would have to remain
> > the same, too.)
>
> Actually DXEs contain machine instructions, data, and address offset fixups.
> But all of that is handled with the internal load routine.

--
------------------------------------------
Mark & Candice White
System programming hobbyists.
http://members.home.net/mhewii/welcome.htm