From: Michael Tippach <mtippach AT gmx DOT net>
Newsgroups: comp.os.msdos.programmer,comp.os.msdos.djgpp
Subject: Re: Is DOS dead?
Date: Thu, 16 Mar 2000 11:17:53 +0100
Organization: another problem of mine
Lines: 103
Message-ID: <38D0B4D1.380F@gmx.net>
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> <Pine DOT SUN DOT 3 DOT 91 DOT 1000315104128 DOT 17230G-100000 AT is> <38CF7CED DOT 505A AT gmx DOT net> <Pine DOT SUN DOT 3 DOT 91 DOT 1000315185511 DOT 20407P-100000 AT is>
NNTP-Posting-Host: wuschel.phoenix.com (134.122.90.115)
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-9
Content-Transfer-Encoding: 7bit
X-Trace: fu-berlin.de 953202120 4286912 134.122.90.115 (16 [12290])
X-Mailer: Mozilla 3.0 (Win95; I)
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Eli Zaretskii wrote:
> 
> On Wed, 15 Mar 2000, Michael Tippach wrote:
> 
> > > Not before it does quite a bit of trickery to get things to their
> > > normal state again.
> >
> > Cleaning up the artificial condition created to trigger the exception is
> > not what I call trickery but a necessary step.
> 
> ``Necessary'' does not contradict ``tricky''.  I said ``tricky'' because
> the code isn't easy to get right.  Clearly, a vanilla C code cannot run
> from the exception handler before it restores the normal execution
> environment.  So generating an exception is only half of the job,
> albeit an important half.

It is this half of the job where one is either moving outside of what is
covered by the spec or putting up with a compromise that still might not
always work.

Vanilla C code does not have to run from an exception handler, but we
can (within the spec) make an exception handler return to whatever piece
of vanilla C code we want to execute next.

> 
> > >  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.
> >
> > That is true. Though I fail to see the relevance for this as we were
> > always talking about deliberately causing exceptions in either case.
> 
> The relevance is that checking the limit against 4KB is much easier than
> to look at all the other possible causes of real exceptions.

You do not have to look. If an IRQ- style signal occurs, the IRQ handler
ideally would set a global variable associated to the signal and do
whatever it takes to generate ANY kind of exception as soon as possible.
It does not matter WHAT kind of exception as long as the exception
handler in question is checking for an unhandled signal and, for each
one detected, resetting whatever had been done to generate an exception
(not necessarily this one) and resetting that global variable that
indicated the signal.

Now, processing the signal would either end up in continuation of main
line code execution, in which case the exception would just happen again
if it was for a different reason, or (more likely) there would be a
branch in main line code execution in which case the exception, even if
it was for a different reason, would not be re-triggered. And this is
absolutely correct since the instruction which faulted after the signal
has occured should not have been executed at all in the first place.

Bottom line: It does not matter WHY you get an exception after a signal
condition occured, it is only important THAT you get ANY kind of
exception ASAP.

> 
> > Personally, I don't use DJGPP for I find the non- flat
> > memory model a bit offensive.
> 
> I rather find it defensive (pun intended).  It saves many a hacker from
> him/herself.

Personal taste cannot be argued about.

> 
> > > > 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.
> >
> > So does W2K return a different value than 0x3205 from function 0x3306?
> 
> No, it reports the same value, but behaves differently.

In how far does it behave differently? Could this different behaviour be
used to detect either version or is there no way to, by means of code,
inspect the differences without crashing the NTVDM on one system?

> 
> > Well, make it 5 lines of code instead of 3, in that case.
> 
> Please show us those 5 lines.  It will help DJGPP tremendously, since
> currently I cannot find any way of telling NT from W2K.

The statement above was a conditional one ("in that case"). Regardless
of the answer to my question above, I would propose the following:

For FPU exceptions:
- Use the EM bit method in all environments. This method simply is more
accurate

Other IRQ-ish signals:
- When in ring 3 and NOT under NT or Win2K, keep existing system
- When in ring 0 use CS limit alteration
  (more accurate than currently AND makes it work)
- When running under NT (any kind), use alias of DS in SS
  (less accurate than currently BUT makes it work)

Regards,

Michael Tippach