Hi, Aitor :)
Just touching on some of your ideas:
1 - I like the idea of being able to run apps for multiple other OSes, but
I think that ability should fall to a program running atop FreeDOS, not to
the FreeDOS kernel itself. That would be a very cool feature, but the
amount of code needed to add it to the kernel would probably be too large
for us to continue to be viable in the "tiny memory space" market. FreeDOS
should do one thing (be as DOS-like as possible, not only in its interface,
but in its memory footprint) and do it very, very well. It would be better
to make individual apps to serve as emulators for foreign apps than to have
this feature build in. And I guess, in a way, these emulators which run
atop FreeDOS to support PE EXEs, DLLs and console Windows apps would serve
as the VXD-like drivers which you specify, so my point may be moot here -
maybe we're both speaking about the same things, only using different
words. lol
I'd definitely stay away from switching modes back and forth between
protected (32-bit) mode and real (16-bit) mode constantly during the user's
session. This wastes valuable CPU cycles, and users running this new
version on older hardware will definitely feel the speed hit. We should
shift to protected mode as early as possible or feasible, after any kind of
setup we need to do in real mode, then try if at all possible to *stay* in
protected mode and never come out; this will allow for top-notch speeds. We
should design the new version as if we were just as limited in memory and
speed as we've always been.
2 - I'd say including Linux - or any other OS, for that matter - makes this
project pointless. We should make FreeDOS its own standalone OS, not
dependent on any other package, emulator or OS. This will give our users
the best possible experience and greatly simplify development and debugging
because we control all our own code. As you point out, we'd lose some (a
lot?) of the DOS flavor in going this route.
3 - While it would be great to be able to make a DOS from scratch based on
modern technology, I fear we'd lose too much in the way of compatibility
this way, and we don't want to do that. Just think of the possibilities,
though... :) lol
I think I agree with you on point number one. That seems to correlate with
my thoughts as the best (e.g. most compatible, flexible and powerful) way
to go.
------------------------------------------------------------------------------
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
