Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!gatech!mcnc!rti!bcw
From: bcw@rti.rti.org (Bruce Wright)
Newsgroups: comp.os.msdos.programmer
Subject: Re: Teaching and Old Dog New Tricks
Summary: MS-DOS address space
Message-ID: <1990Dec29.194735.13016@rti.rti.org>
Date: 29 Dec 90 19:47:35 GMT
References: <1990Dec16.071745.19811@NCoast.ORG> <4701@umbc3.UMBC.EDU> <826@fnx.UUCP>
Distribution: usa
Organization: Research Triangle Institute, RTP, NC
Lines: 50

In article <826@fnx.UUCP>, del@fnx.UUCP (Dag Erik Lindberg) writes:
> ---------
> Different answer here: Why the 640k address space?  I've seen people
> beat around the bush on this one, but here is the bottom line.  The
> question was: Why can't 286 and greater computers have a bigger address
> space and have upward compatibility with old MSDOS?
> 
> The answer is:  Because the video screen, BIOS, and disk controller (etc)
> are smack dab in the middle of the address space if you try to extend past
> approximately 700k.  MSDOS is not designed to deal with a non-linear
> address space, it could never live with a big hole there.  Imagine
> loading up 400k of TSR's and then trying to run a 400k program.  Where
> would you put it?  How would you tell the application that any code it
> wanted to execute after the first 240k is actually located out beyond
> the 1024k region?

The first part of this article was pretty good, but I think this is
not very accurate.

MS-DOS can certainly deal with more than 640K of memory (consider the
DEC Rainbow, which can have up to 896K of real memory), and I don't
see any reason it would have to be contiguous (though that would be
the most useful, since there is no page mapping to deal with
fragmentation - but you could always allocate several noncontiguous
segments just fine, it's just a bit of a pain).  MS-DOS actually
does have a memory allocation list, so it can deal with noncontiguous
segments (just not very effectively, if you aren't careful then memory
fragmentation may cause out-of-memory problems even if the total
amount of free memory is sufficient).

The real issue (if you'll pardon the pun :-) is that too many programs
are aware that they are running in a 20-bit address space, doing
segment arithmetic of one sort or another.  Therefore, they are not
able to run in an environment where the segment arithmetic doesn't
work they way that they expect.  Even if the programmer didn't
explicitly do segment arithmetic, many compilers or subroutine
libraries do, and that's all that's needed to keep it from working.

>  (In case you didn't know, with one megabyte of memory,
> the first 640k are mapped from 0-640k, then the remaining 384k start
> at 1024k, or 1Meg.  In between 640k and 1024k are all the BIOS and
> memory mapped I/O stuff of the PC compatibles.)

This is a common configuration, but it isn't the only one.  Some
clones use some of the upper 384K as a shadow RAM for the BIOS, or 
even put it up at the top of the address space (16M-384K on a 286)
instead of at 1024K.  (I think the latter is sort of silly, but
it does exist).

						Bruce C. Wright