Mail Archives: opendos/1997/05/18/00:45:42
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.
- Raw text -