delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2000/03/15/21:12:24

From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Newsgroups: comp.os.msdos.programmer,comp.os.msdos.djgpp
Subject: Re: Is DOS dead?
Date: Wed, 15 Mar 2000 10:41:50 +0200
Organization: NetVision Israel
Lines: 91
Message-ID: <Pine.SUN.3.91.1000315104128.17230G-100000@is>
References: <fmj8csoh6qqnpvrsdtlk83ec462s8a4sbe AT 4ax DOT com> <38C7D12E DOT 1E12 AT gmx DOT net> <i57gcsk294pgff526i9gihqsjmarlvhnv3 AT 4ax DOT com> <38CD09B3 DOT 7373 AT gmx DOT net> <Pine DOT SUN DOT 3 DOT 91 DOT 1000314094608 DOT 4527E-100000 AT is> <38CE19B2 DOT 69C7 AT gmx DOT net>
NNTP-Posting-Host: is.elta.co.il
Mime-Version: 1.0
X-Trace: news.netvision.net.il 953109872 2324 199.203.121.2 (15 Mar 2000 08:44:32 GMT)
X-Complaints-To: abuse AT netvision DOT net DOT il
NNTP-Posting-Date: 15 Mar 2000 08:44:32 GMT
X-Sender: eliz AT is
In-Reply-To: <38CE19B2.69C7@gmx.net>
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com
Errors-To: dj-admin AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

On Tue, 14 Mar 2000, Michael Tippach wrote:

> > > A way that would also work under NT is to make the
> > > IRQ 13 handler just set the EM bit in CR0 by trying both, DPMI function
> > > 0xE01 and direct writes to CR0.
> > 
> > I'm not sure I understand what problem does this solve.  Currently,
> > the EM bit is set by calling function 0E01h at startup.
> 
> Setting the EM bit TEMPORARILY from within the IRQ 0x13 interrupt
> handler to cause a single INT 0x7 upon the next FPU instruction.

And what if the next FPU instruction never comes, or comes too late?

> Once you are in the context of a DPMI exception handler, you can
> continue execution wherever you desire. IOW: as opposed to a hardware
> interrupt handler where that isn't possible, one can do a complete
> context switch from within an exception handler.

Exceptions are easier than interrupts, but it is still not trivial to
run arbitrary code from them.

> That is, BTW what DJGPP
> does when it receives the GPF or stack fault or whatever would be the
> outcome of the segment limit alteration thing.

Not before it does quite a bit of trickery to get things to their
normal state again.

> As soon as an IRQ is
> converted into a DPMI exception, the problem is essentially solved.

The problem is not solved until you eliminate the reason for the
exception; if you don't, you will get the same exception again when
the faulting instruction is restarted.  For fake exceptions triggered
by deliberately lowering the DS limit, this is easily done, since we
lowered the limit ourselves.  For real exceptions, it's not so easy.

> > CPL 3 environment for writing ``normal'' application programs.
> > Writing low-level stuff like OS kernels is not something DJGPP is
> > meant to be well suited for.
> 
> I meant a DPMI host that runs the client at ring 0 for convenience
> reasons. In a non- multitasking, non- VM- environment there is very
> little reason left to maintain all that ring switching overhead.

Why ``non-VM''?  DJGPP (and DPMI in general) does support VM.  (I'm
assuming that VM means Virtual Memory.)

> > > One possibility would be to conditionally alter the CS limit instead,
> > > _IF_ the DPMI host is CPL0 OR NTVDM (should work with both).
> > 
> > Not good.  CPL 0 and NT are among the least interesting DJGPP targets.
> 
> This discussion started with someone complaining about NTVDM screwing up
> DJGPP signal handling. 

The point is that it hardly makes sense to futz with CS just to fix
NT, which has a few other serious DJGPP- and DPMI-related bugs anyway.
You can see them listed in section 3.3 of the DJGPP FAQ list.

> it takes 3 more lines of assembly code to detect NT.

That's not really true, especially now that you need to distinguish
between NT and W2K.

> > > OR,
> > > one somewhat more memory intense, albeit pretty generic approach would
> > > be to let the interrupt handler make a copy of the code section
> > 
> > ALL of the code section?  That might be megabytes to move inside an
> > interrupt handler, right?
> 
> Very few applications contain megabytes of code. Initialized data is
> what makes applications fat.

The DJGPP setup makes CS and DS reference the same memory.  So you
don't always know where you code ends and the data begins (a program
could put code in some data variable in malloc'ed storage).

So you will end up moving the entire CS/DS segment, which frequently
*is* many megabytes.

> > Moving the code also makes debug support next to impossible (if you
> > want to debug programs which install signal handlers).
> 
> Different issue, admittedly.

Different, but important.  Without good debugging support, you don't
really have a sound development environment.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019