Replying to my own comment:
On Sun, Jan 29, 2023 at 3:28 PM Jim Hall <jh...@freedos.org> wrote:
>[..]
> Sifting through the several conversation threads on this, I think the
> only project that would really be worth "Google Summer of Code" is a
> "loader" to boot FreeDOS on new machines.
[..]
This reminds me of a thought experiment I described several years ago.
Might have been part of a conference Q+A.
The thought experiment starts with: What might have happened if
Microsoft had decided to keep "DOS" and not go the "Windows" route? A
command line operating system, but one that takes advantage of newer
hardware features?
I think Microsoft would have had to find a way around the obvious
limitations in DOS, inherent in an operating system from 1981. With
more powerful CPUs, more memory, and networking, you need a more
powerful operating system. Let's call it "newDOS" and it is otherwise
a "DOS" operating system: command line in text mode. New programs use
a "newDOS" API, like any regular operating system. This "newDOS" also
needs to provide multitasking, and a better memory model (flat memory,
large address space, etc). "newDOS" also needs to provide a built-in
network stack, so you don't have to keep loading drivers and
configuring each application separately to talk to the network.
But to make these changes, you have a problem with running any legacy
16-bit DOS applications. These legacy programs expect to have direct
control of the hardware. Backwards compatibility is a Big Deal to
Microsoft, so they would have found a way to run them.
In this thought experiment, I imagine the "newDOS" with a kind of
"shim" that would run 16-bit DOS applications. Let's call the shim
"dos16" so it's clear. It's easy enough for the "newDOS" command
interpreter to discover if a program has, say, the "MZ" signature of a
16-bit DOS EXE. If the program you're trying to run is an MZ program,
the shell runs it inside "dos16" that makes the classic app think that
it's running on a 16-bit DOS with a BIOS, with 80x25 color text and
VGA 640x480 graphics.
It's easy enough to write a "dos16" host program that supports most
legacy DOS business applications like Lotus 1-2-3 and WordPerfect.
It's also not too hard to support many DOS games (harder if you want
SB16 and PC speaker emulation). It's much harder to support disk
utility programs and other programs that access the hardware directly
- but these are not likely to be useful in a "newDOS" system, so take
the easy route as "version 1." ("Version 1" of anything Microsoft
produced at the time was known to be incomplete anyway.) Build the
other support into "version 2" and later as needed.
Avoid loading a kernel in the "dos16" shim, it just runs the app.
There's no CONFIG.SYS and no AUTOEXEC.BAT. The shim uses environment
variables from the parent "newDOS" to set the environment for the
legacy 16-bit app.
So let's say you run Lotus 1-2-3 on "newDOS" like this:
newDOS:> 123
Then the "newDOS" detects a legacy DOS application, and instead runs
something like "dos16 123" behind the scenes. And the "dos16" is the
shim I described.
But if this sounds familiar, it's because this sort of exists today,
although it's not exactly as I've described it here. Think of Linux
(running in runlevel3) as the "newDOS" operating system and command
line environment, with a shim for classic DOS programs. The shim isn't
quite DOSBox, because DOSBox boots its own DOS kernel so you get a
partial DOS environment that legacy DOS games can run in. The
specifics are very different in this "shim" thought experiment, but
the general idea is the same. My thought experiment is probably closer
to DOSEmu's DEXE.
This is just a thought experiment of an alternative path that could
have been taken, if things had gone differently. But it would have
needed to start in the late 1980s. (And anyway, I happen to like Linux
for modern programs, and FreeDOS in a VM for classic DOS programs.
That works great for me.)
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
