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>
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

- Raw text -