display.sys / turbo3 / nansi / ms- and freedos / crashing DPMI16BI

Hi, display.sys is - if you ask me - only interesting for setting the
local time/date format (like 10. Dez. 2002 versus 12/10/2002) and for
loading specific charsets into your video hardware. You are right, most
programs use the video RAM directly, or the BIOS. Or the DOS text
printing functions. NANSI.sys allows you to use ANSI strings with the
DOS text output, but NANSI itself writes to the video RAM directly,
which is faster than using the BIOS. Without NANSI, FreeDOS uses the
BIOS TTY function. MS DOS uses the BIOS move cursor and print char
functions (those are the ones that TURBO3 speeds up by re-implementing
them as direct writing to the video RAM).
So TURBO3 only speeds up MS DOS, not FreeDOS. NANSI speeds up either
DOS, and TURBO3 will not improve speed further when NANSI is loaded.
To configure the colors and "lines on screen" and so on, you can use
ANSI strings or directly the BIOS (or write to video RAM, but the effect
may only be temporary then), or for some of this things, MODE.
                                            these!

This mail is an reply to George asking about his Turbo C++ 3.0 IDE
problems (the Turbo C++ 3.0 IDE is a DPMI16BI protected mode program:
Bart says, those are generally troublesome with FreeDOS. For example,
I do know that they crash whenever you have any BITDISK or TDSK RAMDISK
installed, even when you do not attempt to use the RAMDISK explicitly!).

> So, if you say it's some memory problem, then why don't I get some kind 
> of general protection fault or segmentation fault?  How is it that it 
> gets so screwed up I can't even Ctrl+Alt+Del even?  It seems like the 
> worst real mode problem - the kernel, bios, and/or video ram gets 
> written over and all mixed up( like me :-(    ).

DOS is no protected mode operating system. It does not handle the usual
"general protection fault" (Linux would say "segmentation fault") but
will just crash when such a fault occurs. FreeDOS does handle some
easier to handle conditions (division by zero, illegal opcode), I think,
and then terminates the offending program if possible (otherwise, it
crashes). But programs are supposed to handle division by zero errors
themselves anyway...

DOS is no multitasking operating system either: When it crashes or hangs,
the keyboard will no longer react. Real (mode) life is simple but hard.

When you run a DOS program, the kernel and BIOS will stop until the
program (or something triggered by an interrupt, for example timer or
keyboard) asks them to do something. When a program fails to ever ask
anything and unfortunately has timer/keyboard interrupts screwed up as
well, the whole system will crash/hang, because the only task - your
program - has crashed. When a program correctly terminates, the calling
process (for example the shell) will get back control. But normally, no
two processes can share control - singletasking, plain and simple.

When you use protected mode (an EMM386 driver, some protected mode driver
to add multitasking to DOS, sometimes an protected mode DOS program itself),
and multitasking is enabled as well (ALWAYS the case when the protected mode
driver or program wants to use DOS or wants to be a driver for DOS, because
DOS cannot run in a normal protected mode task and so a second, v86 mode,
task must exist), then the protected mode task may be able to handle errors
caused by the v86 task (by DOS, that is) or in the protected mode task
itself: You get the popular "general protection fault" message then, and
are hopefully thrown back into real mode DOS. But sometimes, you only get a
message and have to reboot after reading it. Or handling the error fails, and
you crash just as hard as in real mode (kind of a "kernel panic" of the
protected mode driver / DOS extender ;-)).

Eric