Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!hao!boulder!sunybcs!rutgers!clyde!watmath!watdcsu!broehl
From: broehl@watdcsu.waterloo.edu (Bernie Roehl)
Newsgroups: comp.sys.ibm.pc
Subject: Re: 80286 Protected Mode (Re: Intel microchips / PS2s)
Message-ID: <3830@watdcsu.waterloo.edu>
Date: Fri, 11-Sep-87 09:42:39 EDT
Article-I.D.: watdcsu.3830
Posted: Fri Sep 11 09:42:39 1987
Date-Received: Sun, 13-Sep-87 06:35:21 EDT
References: <768@imsvax.UUCP> <1208@cartan.Berkeley.EDU>
Reply-To: broehl@watdcsu.waterloo.edu (Bernie Roehl)
Organization: U. of Waterloo, Ontario
Lines: 59

In article <1208@cartan.Berkeley.EDU> ballou@bosco.berkeley.edu (Kenneth R. Ballou) writes:
>
>	I claim that most software written for DOS should have no problem 
>executing in protected mode.

Unless I'm very mistaken, a *huge* number of programs won't run, and can't
easily be made to run, for reasons listed below.

>... any program which
>does not do bizarre pointer arithmetic (e.g., convert a segment/offset into
>an absolute 20-bit address) should work fine in protected mode.

It seems to me that any program that makes assumptions about certain
things being at absolute segment locations will fail.  As you pointed
out, this includes all full-screen editors, spreadsheets, graphics
programs, etc etc, since they all assume that loading 0xB800 or 0xB000
into a segment register will allow you to access the color or
monochrome display adapter memory directly.  It may be possible to get
around this by setting up the segment descriptors as you describe; but
wait, there's more!

Any program that "knows" about the BIOS data area at segment
0x0040, or the interrupt vector table at 0x0000, will also fail.  This
includes a *lot* more programs (most things that terminate and stay
resident do their interrupt trapping by reading and writing the vector
table, rather than by going through DOS calls.  They also look at (and
occasionally change) the contents of the bios data area).

Perhaps even more important is the fact that DOS itself will not run
in protected mode (it makes all manner of assumptions about what's where),
so anything that uses DOS for anything at all will not work.  (This
includes a *lot* of programs :-)  Yes, you could re-write DOS to run in
protected mode, as you suggest.  This is a lot of work..

Of course, the same thing applies to the rom bios; you'd have to re-write
that as well.

In short, the vast majority of *all* programs simply will not work in
protected mode.  To make them run you would have to re-write both DOS
and the rom bios. (Granted, you wouldn't have to actually burn new roms;
you could simply trap all rom bios calls and vector them to your own
routines.  Of course, you'd still have problems with some of the badly-
written tsr prorams that trap a vector, do their thing, and the JMP to
the absolute rom location that they "know" has the original handler).

>	Now, for a wild claim:  I claim that there is a reasonable scheme
>by which one can achieve *binary* compatibility, of a sort, for programs
>of type 1) or 2a) above.

I think what we're quibbling about is the word "reasonable".  I don't deny
that it can probably be done.

If you do it, you've got a hit on your hands.  (Actually, I've heard of a
company that's already re-written DOS; it's called "Wendin", and they're
supposed to be shipping soon.  You may want to run your idea past them;
as far as I know, they've coded in C so coming up with a protected-mode
version should be pretty easy).

Anyway, I think it's a fair amount of work no matter how you do it.