🚀 go-pugleaf

In article <1990Dec16.071745.19811@NCoast.ORG> ramsey@NCoast.ORG (Cedric Ramsey) writes:
>I am curious as to why DOS can't exceed the 640K barrior.

   As other posters have pointed out, it can. The problem is that the
upper 384K are reserved for other hardware. Depending on what additional
hardware is installed, it is sometimes possible to add more.

>Why not just rewrite DOS for a 32bit address space.

   The problem here is that DOS runs in what is called "real mode." Any
80x86 running in real mode is essentially reduced to being a fast
8086/88 with a few more instructions. The additional address lines are not 
available.
   In order to access the additional address lines (and hence the full
memory space), the chip must run in "protected mode." Protected mode is an
improvement over real mode in a variety of ways. In particular, it includes
hardware provisions for memory protection, virtual memory, etc.
   So what's the problem? DOS and DOS programs are written assuming a
certain arithmetic relationship between segments and offsets, namely that
an offset can be converted to a segment by shifting right four bits, and
that the "flat" 20-bit address is calculated as: the segment shifted left
four bits (in a 20-bit space so as not to lose the high four digits) and
then added to the offset. Thus, 0000:0402 is equal to 0040:0002. And 
0020:0202. And 0010:0302.
   This breaks down in protected mode, where the segment value is a handle
into a table of segment descriptors. Hence, most DOS executables will not
run in protected mode. Nor DOS itself, nor the BIOS in ROM that DOS relies
on. While there are presumably other problems, this one by itself is enough
to kill rewriting DOS very dead. It could be done, but why? None of the
programs would run, which would be the only point of doing it in the first
place. There are already plenty of more advanced *in*compatible OSes.

   Why were programs written this way? Well, the easy answer is: large
data objects. Multiple segments are not the problem. The handle is still a
16-bit value (to fit into the segment register) and far pointers would work
just as well with a handle in the segment word as with an actual segment.
The problem is single data objects larger than a segment. The easiest way
to access a large array is to fool around with the segment value as well as
the offset. If done "properly", the array would wind up in two or more
segments and the compiler (and executable) would have to go through strange
contortions to access an element, generate a pointer to that element, or,
even worse, do pointer arithmetic between two elements in the array.
Indeed, if the two elements are in different segments, the result is not
well-defined. Thus, in the interests of speed, simplicity, and sanity,
segment arithmetic was born and DOS was stuck in real mode forever.

-- 
James W. Birdsall      | amc-gw!jwbirdsa@uunet.uu.net | For it is the doom of
=======================| 71261.1731@compuserve.com    | men that they forget.
jwbirdsa@amc.com       | CompuServe: 71261,1731       |    --Merlin
uunet!amc-gw!jwbirdsa  | GEnie: J.BIRDSALL2           |======================