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 :) In fact, I think you 
know me well enough to know that, unless I believed the literal statements in 
the Intel documentation, I would not be asking about this at all. And I think 
you also know me well enough to know that I am not going to take anyone's 
word for anything, particularly if it contradicts the manufacturer's 
documentation, not even from someone whose opinions and abilities I highly 
respect, like yours.. 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 :)
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, as it was rather a lot of fun digging into the 
inner depths of the damn beast to try to figure out what this or that data 
field represented. (And, to the lurker who has been flinging wild accusations 
around to me in netmail, I suggest you read the "credits" section in the file 
"INTERRUP.1ST" distributed with Ralf Brown's INT list before making any more 
such accusations.)
 >> If this is at all possible, then why do we need
 >> DPMI? Why was it invented in teh first place? All you'd have
 >> to do in DOS is switch to protected mode....
 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 huge 
segments. That would be sheer delight to play around in (of course, removing 
those mem limitations would also take a lot of the fun out of it :).. if DOS 
had been reworked to use flat real mode, there would be no need for DPMI or 
XMS at all. 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).
 EB>>> If you carefully read the note in step 3... 
 EB>>> EB>>> it's certainly clear what will happen if one were to
 EB>>> leave some segment descriptors "large."
 >> 
 >> No, it is not clear, not at all...
Yes, the code does clarify matters. Like I said, the documentation is not 
clear to me; the code is :)
 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?
(One can of course perform many variations on the same theme; this is merely 
a very simple, albeit seemingly do-nothing, example.)
--- FleetStreet 1.21 NR
---------------