I too would love to see a fully modern DOS.
My thoughts for features added in FreeDOS 2.0: The processor is shifted
into (and stays in, at least as much as possible) protected mode, providing
32-bit addressing. Memory therefore would become a flat 4GB RAM address
space, allowing for advanced features like preemptive multitasking with
protected memory.
While researching these features for addition to my GUI, I came up with an
approach which I think will maintain backwards compatibility. Each newly
spawned .EXE gets its own copy of the lower 1 meg of RAM upon entry,
complete with its own BIOS trap table, video RAM space and so on. This way
each application has everything it expects to have - all while running in
protected mode. The only downside is that each new app which gets run
(beyond the first one) takes up a whole 1 or 1.5 megs of RAM, but the
benefits far outweigh that small fact. For users who have limited RAM (and
therefore can't multitask anyway) the system behaves like it always has,
and those with an extra 32 megs sitting in their case just bought
themselves the power to run more apps. This way nothing has to change
compatibility-wise, and FreeDOS remains small, powerful and fast for those
who rely on it for these traits. For the power users, it has not just those
things but also the potential for much more.
Under this model, each app is isolated from all others and essentially
thinks it's the only one in the system. Inter-application communication is
still possible through a software interrupt for those newer apps which
expect it to be there, but the older ones remain blissfully ignorant. When
the app closes and control would normally return to command.com, the kernel
instead disposes of the RAM that app was using and continues running all
the others. Segment-offset addressing would still work as intended, but
maybe with a slight speed hit since that format would have to be remapped
to the actual load address of the app. The memory allocated to these apps
would use double-indirect addressing so that apps can be moved around in
memory while they execute, allowing the kernel to optimize memory usage as
needed.
The standard BIOS API would inevitably need to be rewritten in 32-bit clean
code. This would most likely be a complete custom rewrite of the usual BIOS
services with a set of "redirectors" for older programs which are nothing
more than simple dispatchers which resolve memory addresses and pass
control along to the 32-bit BIOS services. The speed hit incurred in doing
this would be slight compared to actually shifting back into real mode
every time you need to do something with 16-bit code, as it seems most DOS
extenders do. The key to speed is to keep the processor in protected mode
as much as possible.
So far as supporting modern hardware at the OS level, this is a non-issue
in my mind. Older DOS apps won't expect it to be there, and newer ones will
have some kind of driver framework at that point which they can rely on for
access. Like Marc said in his Novell letter, you can promise the world as
long as you leave hooks to add the world in later. We could implement some
kind of hardware table / driver model, but leave it up to future versions
to decide the intricacies of how these things would work. To me, that looks
like a great job for FreeDOS 3.0. :)
What we *absolutely should not do* is keep adding all manner of features to
the kernel. I'm looking at you, Linux. lol Seriously, though, our goal will
be to keep FreeDOS lightweight, fast and compact. We have what has to be
one of the tiniest kernels in existence, and we should keep it that way.
A simplification of this technique could be summarized as merely moving
some parts of a DOS extender into the kernel itself, but cleaning and
streamlining things along the way. Really the single worst thing about
doing this would be a modest increase in kernel size, but for all the
modern features FreeDOS would gain I'd say that's *well* worth it.
------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
