From: Ed Beroset 
Subject: Re: flat real mode
Darryl Gregorash wrote:
> 
> Replying to a message of Ed Beroset  to All:
> 
>  >> Have you actually done this?
> 
>  EB> Yes, of course.  More to the point -- have you actually done
>  EB> this?
> 
> That's not to the point at all, Ed.. you know me better than that, I think; 
if
> I had done it, I wouldn't be asking you about it :) 
That's exactly why I thought it was the point.  ;-)
> I never accepted any statements to the effect that "it is intuitively 
obvious"
> from Mathematics professors, I am not going to accept them from you :)
That, IMHO, is exactly as it should be!  There's all the more reason you
should test this stuff out on your own machine so that you can tinker
with it yourself.
> But there is another reason why I am asking these questions: since my
> departure from 80XXX 3 years ago, I have switched to a full OS/2
> installation.. "true" DOS isn't even installed here anywhere anymore 
anyone
> want an unused copy of NovellDOS 7.0? :) I rather regret not keeping a 
"pure"
> DOS system functioning here, 
FWIW, TASM, the code I posted last time, a small editor and DEBUG will
all coexist nicely on a single bootable floppy.  :-)
>  EB> DPMI allows one to run protected mode code -- flat real mode
>  EB> does not. They solve different problems.
> 
> Ahh, that is not the point I was trying to make; think of DOS with such 
uge
> segments. That would be sheer delight to play around in (of course, 
emoving
> those mem limitations would also take a lot of the fun out of it :).. if 
OS
> had been reworked to use flat real mode, there would be no need for DPMI or
> XMS at all. 
That's probably true in the practical sense, but part of the utility of
protected mode is the protection mechanisms for which it is named.  
> Designing a multi-tasker in such an environment would be a very
> interesting exercise (perhaps this is what Caldera has done; I believe I 
have
> seen a claim from them that OpenDOS does do multi-tasking).
Unfortunately, without the benefit of the protection of protected mode,
every minor bug can be potentially lethal to the entire system.  A write
to an uninitialized pointer, buried somewhere in a user's text editor
program, could overwrite literally anything.  While it's probably
possible to write a flat-mode multi-tasker, it's unlikely anyone would
want to these days.
> Yes, the code does clarify matters. Like I said, the documentation is not
> clear to me; the code is :)
Good!  In that case, I'm glad I posted it.
> 
>  EB> ;-----------------------------------------------------------
>  EB>                ORG 100h
>  EB> start:         call flatmode      ; go into flat real mode (fs reg 
only)
> 
> Just one question here; suppose you do this after this call to flatmode:
> 
> mov DX,FS
> mov FS,DX
> 
> Does FS still have the 4G seg limit, or does the very fact of performing a 
MOV
> instruction with the segreg as the destination destroy that, replacing it 
with
> a 64K limit? I believe Intel says that is the case with CS, but is it also
> true for other segregs?
Good question.  No, it's not true for the other regs (and I have my
doubts about whether it's true for CS).  In the sample I posted, if you
load the FS register with any value after the return from flatmode, it
will change the base address but not the limit.  In the particular
experiment you propose, what will happen is that DX will get the value
08h (since that was the selector used), and then FS will get 08h.  Even
though it was already 08h, the reload in real mode will cause the base
address to be changed in exactly the way you'd expect for any other real
mode segment register load, i.e. 80h will be effectively added to any
FS-relative address.  
Other questions and answers, possibly to whet your appetite:
Q:  If I change the DPL of the 4G selector to something other than 0,
can I still use it in real mode?
A:  Yes.  Although the DPL remains set (one can verify this by going
back into protected mode and checking), that protection mechanism is
turned off in real mode.
Q:  If the GDTR remains after a return from protected mode, does the
IDTR also?
A:  Yes.  For example, you could change the base of the IDT to, say,
80000h, copy the contents of the interrupt vector table there, and
return to real mode.  You will find that you can zero out the old IVT
with impunity.  (I once toyed with this as a possible anti-virus
mechanism.)
Q:  What if I clear the W bit of the 4G data descriptor to make it
read-only?
A:  Interestingly enough, that protection mechanism is apparently still
turned on after a return to real mode, so a write to that segment will
trigger an exception.  Reads still work just fine.
Ed
-!-
---
---------------