Date: Sun, 18 May 1997 00:39:48 -0400 (EDT) From: Pierre Phaneuf Reply-To: pierre AT tycho DOT com To: JP Morris cc: opendos AT delorie DOT com Subject: Re: 32 bit dos In-Reply-To: <19970517130350.16074.qmail@dns01.ops.usa.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On 17 May 1997, JP Morris wrote: > >The main reasons for a 32 bit dos are: > > > > 1.) faster memory transfers. > > 2.) more memory available to programs. > > Please remember that 32 bit and 'more memory' are NOT synonymous, until > last month I was quite happy to use DPMI/16, which gave me all the > memory I could eat, as well as the familiar seg:offset memory model. I > habitually designed my data structures around the 64k limit, easy > really. > > Even my assembler code worked after a simple recompilation. In > addition, it also works on 286 processors, albeit with a limit of 16mb > on those systems. But then DOS/4GW has a 16mb limit AFAIK. DOS/4G has a 4GB limit. And the segmented memory model is what I personally hate most about the Intel x86 serie of CPU. Anything beyond mode 13h busts the 64k limit. A simple SVGA mode like 640x480x256 requires much more than that and has to use bank switching, which slows thing down to a crawl. With a 32 bit flat memory model, you alloc 512k and use that as a linear frame buffer. And I did more than once a program (I do my commercial DOS programming with Borland Pascal 7.0, with 16 bit DPMI target) that busted the 16MB limit trying to sort a big file. With 32 bit protected mode, I got 16MB RAM and allocate swap memory as much as I need. 4GB is both bigger than 64KB, 640KB and bigger than 16MB. > Grooh yes.. my 32-bit compiler doesn't have interrupt handling > facilities! I have to use some wierd code that Ethan Brodsky lent me. > Generates a thunk that calls 'nowhereland', an empty 48-bit pointer that > is filled in later to point to the int handler. > > The only reason I changed was to use SVGA, I couldn't find a quick way > to do this in 16-bit code. The 32-bit program is slower and less > stable. It also dies under NT and win95 dos boxes, but that's 'cause of > the wierd 32RTM extender. This is because 32-bit programming *isn't* supposed to use interrupts and *IS* going to be slow, as each interrupt calls has to switch to real mode, process the interrupt, then switch back to protected mode. Those mode switch are about as slow as an operation goes on an Intel. Porting from 16-bit to 32-bit isn't simple nor straightforward. But since most of the things we do in 16-bit are kludges to make do with the crap we have, programming *directly* to 32-bit IS easier than programming for 16-bit. If you know how that is. You have to learn that, just as well as you learned not to go beyond 64KB per data structure, not go over 640KB total memory, how to use the interrupts, etc... > So the moral is to remember that the 286 has a protected mode as well. And it doesn't help much. What is *really* cool with the 32-bit protected mode of the 386 is that you get hardware context-switching almost for free! That means ultra-smooth multitasking... This is how Linux does its context-switches on the i386 architecture. And also, most people willing to do multitasking with their machines can easily break the 16MB barrier of the 286 with normal usage. Remember that Netscape for example is 12MB by itself! I guess most DOS programs will be "thinner" than that, but still, I doubt you'd be able to run dBase IV 2.0 with WordPerfect 6.0 for DOS both with some big enough files loaded... > It wouldn't work with Real Flat programs, Ultima 7, and my demo > collection. When we get a 32-bit DOS, we'll also need an emergency > backdoor into REAL-MODE, so that V86-allergic programs can be run. Those will be able to use the 16-bit kernel with no problem... Keeping both the 32-bit protected mode kernel and the 16-bit real mode one shouldn't be a problem, using (in a transparent to the user way) a loader similar to LOADLIN to load the 32-bit kernel... > >Sort of like the Rhapsody needs a MacOS box.. [never mind Rhapsody is > > What's Rhapsody? I thought it was a composition package on the Arc way > back.. obviously there is another one. Rhapsody is the new Macintosh operating system (not yet released)... Pierre Phaneuf "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense." - Edsger W. Dijkstra.