Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!portal!cup.portal.com!Isaac_K_Rabinovitch
From: Isaac_K_Rabinovitch@cup.portal.com
Newsgroups: comp.sys.ibm.pc
Subject: Breaking the 640K Barrier
Message-ID: <1816@cup.portal.com>
Date: Sun, 6-Dec-87 13:20:16 EST
Article-I.D.: cup.1816
Posted: Sun Dec  6 13:20:16 1987
Date-Received: Sat, 12-Dec-87 12:23:20 EST
References: <164300022@uiucdcsb> <1094@ucsfcca.ucsf.edu> <1189@homxb.UUCP> <1098@ucsfcca.ucsf.edu>
Organization: The Portal System (TM)
Lines: 47
XPortal-User-Id: 1.1001.1472


simrin@mis.ucsf.edu (Steve Simrin) writes:
->In article <1189@homxb.UUCP> mr@homxb.UUCP (mark) writes:
->>
->>I suspect that DOS 3.4 will fix the 640K [screwup]. (not 3.3)
->>
->
->I don't think so. Breaking the 640k barrier is one of the 2 big
->features of OS/2 (multitasking being the other). If they fix DOS, it will
->cut the sales of OS/2 significantly.

I'd suggest a less cold-blooded motive:  any such change to DOS for the
80286 would render a lot of 8088/6 applications programs nonfunctional.
That's the big problem with DOS:  so much is done by individual application
programs that ought to be done in system software.  Aside from the immoral
duplication of effort, this means that you can't do some improvements
in the system software without obsoleting a lot of application software.
Modularity! as Woody Allen used to say.

Incidentally, there are programs that can use AT Extended memory.  I own two.

The first is Framework II, which comes with various driver modules for
"Extened Memory" on AT Extended Memory (which they call "memory past 640K on
the motherboard), Expanded Memory, or disk.  I've tried out two of these
(I don't have Expanded Memory) and the drivers are painfully inefficient
and won't run if you start FW with less than 1/2 meg of normal memory
available, but they do come in handy when you run just over FW's normal
memory limits.  I suspect these drivers would work very well if rewritten
by someone who knew paging algorithms; but this is probably not worth doing,
given FW's marginal usability.
 
The second is TI's implementation of the Scheme language.  I'm not very
good at this kind of programming yet, but I get the impression TI Scheme's
use of Extended Memory is pretty robust.  Not terribly suprising that
a LISP implementor would be good at memory managment!
 
What would save the day:  somebody writing a generic Extended Memory driver
and selling it to various application programmers for inclusion in their
products.  Such a driver could even be made to work on XTs, paging to disk
instead of memory.  But I suppose that with all the focus on Expanded Memory
schemes, this is unlikely to happen.  I'll probably get Expanded Memory
myself, especially if I go to a multitasking system (like DesqView) that
uses it.

Isaac Rabinovitch
Disclaimer:  Just because I think you're wrong, doesn't
             mean I don't think you're a fun person!
:-)