From:	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
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 <Nborman AT chello DOT at> wrote:

[Could you try to hit your <Enter> 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.

- Raw text -