Mail Archives: djgpp/2000/07/26/15:30:31
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 -