From:	"Charles Sandmann" <sandmann AT clio DOT rice DOT edu>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: RE: DXEs and other OSes
Date:	Wed, 26 Jul 2000 14: 9:27
Organization:	Aspen Technology, Inc.
Lines:	20
Message-ID:	<397ef117.sandmann@clio.rice.edu>
References:	<000001bff63d$f661b660$fc9260cb AT morgoth>
NNTP-Posting-Host:	dcloan.hou.aspentech.com
X-Trace:	selma.aspentech.com 964638860 18817 10.32.115.107 (26 Jul 2000 19:14:20 GMT)
X-Complaints-To:	postmaster AT aspentech DOT com
NNTP-Posting-Date:	26 Jul 2000 19:14:20 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

> A quick test in Linux resulted in a program that will correctly load and
> execute the DXE test file compiled by DJGPP.  Of course this was an
> extremely simple case...

But it does show that DXEs are operating system independent if their contents
are.  That was my original intent when I designed them, but I never had a 
chance to test it.

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.

- Raw text -