ballou@oreo (Kenneth R. Ballou) (09/01/87)
Organization: In article <768@imsvax.UUCP> paul@imsvax.UUCP (Paul Knight) writes: > > The following is from my buddy Ted Holden, now with HT >Enterprises, concerning the recent INTEL/MOTOROLA/PS2 >discussions. The views expressed do not necessarily coincide >with mine and in no way represent IMS. > > OS2/, one of the main selling points of the PS2 is turning >out to be a case study in vapor-ware. Absolutely agreed. > Basically, protected mode >on the 286 chip is an abortion and should be avoided. Absolutely disagreed. > Since the >286 uses registers in altogether different manners going from >real to protected mode, you would end up giving up the entire DOS >software world even if they could get it to work, which is >unlikely. Well, hold on here. I want to take a strong exception to this claim. The only registers the 80286 uses differently in protected mode are the segment registers CS, DS, ES, and SS. *All* other registers function in exactly the same way. (Moreover, contrary to a myth that was floating around some time ago, all instructions which do not in any way involve loading a segment register with a new value take exactly the same number of clock cycles in real and protected mode.) I claim that most software written for DOS should have no problem executing in protected mode. As far as I can see, the only assumptions that would cause any difficulty are: 1) "Segment registers contain the high 16 bits of a 20-bit physical address of the beginning of a segment." 2) "I am at liberty to poke around in any physical memory address I please." Of course, #1 gets one in trouble because segment registers in protected mode contain indices into global/local descriptor tables. Why #2 leads to trouble in protected mode should be clear. Therefore, 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. In particular, the usual use of segments (load their base address into a segment register, then refer to items within that segment) works just fine, provided one changes "base address" to "descriptor". More specifically, the code generated by the Microsoft C compiler should be perfectly acceptable (even huge model code, since the code generated is identical to that produced by the XENIX C compiler, and since both rely on a library procedure to do the address calculation). Note, however, that some of the library routines might need to be rewritten; however, this does not affect source code compatibility. I seem to recall with the discussion of Windows a classification scheme for DOS programs. I believe that there were several categories: 1) well behaved programs 2) ill behaved programs, subdivided into: 2a) programs which are ill behaved only because they address video memory directly 2b) other ill behaved programs. (Of course, the actual scheme was probably finer than this, but this will do for now.) Certainly well behaved programs will have no difficulty with source compatibility. Strictly speaking, ill behaved programs should fail. However, it would be quite easy for the operating system to set up descriptors 0xA000, 0xA800, 0xB000, and 0xB800 to refer to video memory and to be accessible at all privilege levels, thereby allowing such programs to continue addressing video memory directly. 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. In all fairness, I have not tried this scheme myself, since doing so requires that I first write most of a protected-mode DOS. I am convinced that on paper this scheme would work. ------------------------- Kenneth R. Ballou ballou@bosco.berkeley.edu
broehl@watdcsu.waterloo.edu (Bernie Roehl) (09/11/87)
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.