🚀 go-pugleaf

In article <DDt701.DC3@hr.ns.nl>, Illya Vaes  <ivaes@hr.ns.nl> wrote:
>You have the facts right but the conclusions wrong.
>IBM specified the place to put those adapters (BTW after Intel specifying the
>8080 to start at 1M, not 0), but MS-DOS (and thus MS) is to blame that any
>memory between and beyond those adapters aren't accessible (the between-part
>finally changed in DOS 5, *provided* you had a 386 or better).
>Look at it this way: on the *same* PC, with the *same* adapters, OS/2, NT, SCO
>Unix, Linux etc. all are able to address all available RAM. Only DOS can't.
>Now ask yourself again: is it the hardware (specification) or the software?

But DOS was developed for machines that could only address 1MB.  That
DOS wasn't made portable/scalable to a 32 bit architecture is a software
problem, sure. DOS's system call interfaces are over-specified, in that
they dicate low-level assembly language details, such as what registers
pointers are passed in.

>>In any case, the 640K "barrier" isn't a problem anymore, since operating
>>systems can simply map virtual memory pages around the I/O areas. Everyone
>>in Linuxland sees a flat address space, with the kernel mapped somewhere
>>in the the upper GB, protected from user processes by a segment limit.
>
>And now you notice it yourself, contradicting yourself.

No I'm not. Because the barrier was real in the days of the 808x machines.
In 8086 compatibility mode, the 386 still can't address more than a meg.

>The ability to map *virtual* memory pages around the I/O areas implies that
>the OS software can *physically* address all available RAM, whether or not it
>is below the adapters (640K) or not. Only DOS misses this capability, and it
>is just because it was designed that way. No runtime allocating of memory
>structures and such. It's called 'assumptions'.

DOS certainly does have memory allocation system calls. The problem is that
these are specified right down at the machine language level as returning
20-bit addresses as segment/offset pairs. There are not portable C wrappers
for these raw calls as there are in UNIX. Many other kludges are specified
too---like poking around DOS internals to discover what state it is in,
it's non-reentrance, etc.

Other systems have migrated smoothly from 16 to 32 bit. XINU was developed
on an 16-bit DEC LSI-11 microcomputer, yet runs on Sun3's and 386 machines
with few modifications, involving the context switching assembly code,
startup code and device drivers. That's because all of its kernel interfaces
are specified as abstracted C calls. You couldn't write code to poke around
in XINU's internal data structures, since these could easily be re-shuffled
around when new variables and code is introduced to the kernel.

>Most assumptions turn out to be wrong (I wonder if there's a lesson to be
>learnt here about the assumed de-facto market dominance of a certain just-
>released product????).

Heh.
-- 
Finger c2a192@keats.ugrad.cs.ubc.ca for PGP public key. Or contact
one of the public key servers -- the key id is 0xD3C7995D.