From: Hans-Bernhard Broeker Newsgroups: comp.os.msdos.djgpp Subject: Re: DPMI Date: 9 May 2001 10:57:32 GMT Organization: Aachen University of Technology (RWTH) Lines: 42 Message-ID: <9db7qs$ir2$1@nets3.rz.RWTH-Aachen.DE> References: <000801c0d7ee$f0f8cf40$0c4011d4 AT telekabel DOT at> NNTP-Posting-Host: acp3bf.physik.rwth-aachen.de X-Trace: nets3.rz.RWTH-Aachen.DE 989405852 19298 137.226.32.75 (9 May 2001 10:57:32 GMT) X-Complaints-To: abuse AT rwth-aachen DOT de NNTP-Posting-Date: 9 May 2001 10:57:32 GMT Originator: broeker@ To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Brian Chance wrote: [Could you try to hit your key from time to time? The whole paragraph below came here as a single long line, which is a lot longer than recommended by netiquette...] > I realize that Djgpp links its output natively to load the DPMI > server for protected mode compatibility. Is it possible to produce > files which are independant of DPMI with Djgpp? Not really. You'ld have to effectively rewrite the most central parts of the whole DJGPP project (the startup code and C library). I'd hesitate to call the resulting compilation toolchain DJGPP, still. It'd be a bit like RSXNTDJ: using DJGPP only as a host for the tools, but not as their target platform --- i.e. a cross-compiler. > For instance, if i were to write an external file to enable > Protected mode and build the sufficient descriptor tables, would i > be able to produce a flat-mode binary file from Djgpp and cram these > files together? Notice that there's a *lot* more to DPMI than just pushing an executable image into high memory, setting up pmode and executing it. You seem to have forgotten what the "D" in DPMI says: DOS. I.e. it's also an interface between the DPMI client and the underlying DOS. You'ld have to imitate all that, too. In the end, you'ld be reinventing a DPMI server, or creating your own libc with interfaces to DOS. > The reason for this being simply that I don't like the dependancy > features of the DPMI interface and these virtual DOS features. Those dependancies and features exist for good reasons, which you seem not to have grasped, yet. To give just one important example: multitasking OS'es providing DOS runtime environments are a fact of life, these days. Much of the seemingly complicated issues of DPMI are necessary to cope with exactly that type of setup. In fact, that's what DPMI was invented for --- in the context of Windows, the predecessors like VCPI simply couldn't work any longer. -- Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de) Even if all the snow were burnt, ashes would remain.