to multitask DOS apps which use direct hardware access,
you have to use vm8086 mode of the 386 and newer CPUs.
Many apps have this problem, only few use only the DOS
kernel to access hardware. Many at least also use BIOS.
You could wrap something around kernel and BIOS to keep
track of multiple states, so multiple apps could run in
multitasking style, putting only one at a time at the
screen, keyboard and mouse.
The multitasker of DR DOS is, as far as I remember, in
most part a feature of their DR-EMM386. It is not open
source, only the sources of kernel and some core parts
are open, although not under a totally open license.
I assume that Desqview is also closely linked to some
high end version of EMM386, probably QEMM386. Both the
QEMM386 and Desqview were quite complex - and non-free.
MS DOS for a while also came with task swapping, part
of their DOSSHELL, but that would not really multitask:
It could just freeze a task, let you run something else
and later continue the task, simply speaking. For that,
it probably took a snapshot of RAM and hardware state,
probably including for example EGA/VGA graphics...
DJGPP is not linked to multitasking, it is simply a DOS
version of the GNU C compiler, creating 32 bit DOS apps
which can use gigabytes of RAM, if you have so much. It
uses a C library which relies on DPMI for DOS extender
services, for example CWSDPMI. Other DOS extenders give
more complex services, while for example even Windows
already gives built-in DPMI support for apps in the DOS
window of windows. Of course you could run several tasks
with a suitable DPMI. Some are really cool, eg. DPMIONE.
However, a problem is still to trap hardware access and
keep separate states for separate apps. Similar to the
multiple virtual terminals in Linux, you could say, but
in Linux, apps almost always are limited to using kernel
calls instead of direct hardware access, which makes it
easier to tame them for multitasking. Same for Windows.
I think some old SuSE Linux versions, 5.x or 6.x, came
with some X server for DOS. No matter whether this was
X.org or XFree86, the main purpose was to show graphical
Linux apps running elsewhere on a PC which runs DOS. To
also run the apps on DOS, you again need multitasking.
Drivers and compatibility would indeed be a problem with
a multitasking DOS, but on the other hand, you can still
let a single tasking kernel with single tasking drivers
serve multiple tasks, as long as you have a wrapper which
makes sure that all kernel calls arrive nicely one after
another. If necessary, you can also swap around some RAM
with apps (and kernel state information!) to have a more
realistic amount of DOS memory free and not run out of
that after the third task ;-). The 386enh mode of WfW311
and Windows 3.x does something similar. The problems in
running this mode in FreeDOS show that it is not trivial
to swap all relevant kernel state info when cycling from
one task to the next. Actually WfW311 is almost useless
outside 386enh mode because many drivers rely on it. Bad,
as WfW311 is the best known variant of Windows for DOS.
You could have a look at FreeDOS-32, which tries to take
advantage of 386 protected mode features in the kernel,
although I do not know how far they work on multitasking.
I think they do have something like a built-in DPMI, or
DOS4GW / DOS32A, based on the assumption that many newer
DOS games and DOS apps rely on DOS extenders and that it
can help with performance (although not much) to have a
kernel which runs in the same task as the "DOS extender".
You could also have a look at Triple DOS / TriDOS, which
is some extension for any DOS to let you swap tasks in a
manual way. Stability is so-so and whether things can be
task swapped for you of course depends on whether all the
drivers that your apps use are wrapped by the task swapper.
Talking about a Linux API in DOS - given that there is a
GNU C for DOS with a very Linux style C library (of course
using DOS, not a Linux, as the actual backend) you could
say that this already exists anyway :-)
Not that it would really help you with X and GUI, though...
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
Freedos-user mailing list