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! :-)