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