Hello!
Notes below.
BTW, Whatever happened to Japheth's pages?? Is server down? (see JEMM's
LSM for URL's).
Aitor
2015-01-01 19:31 GMT+01:00 Mercury Thirteen <[email protected]>:
> 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 don't want to give the impression that the main idea is to run other
kinds of executables. It is a nice addition, but my main interest is to run
DOS itself, and DOS applications, maintaining 100% compatibility.
The most wonderful stuff that could be done, in my opinion, goes along the
experiment that Schulman does in "Unauthorized Windows95", and that I'd
love to see somehow some day. IIRC:
- he wrote an example DOS program that requests memory via XMS. For me, XMS
(or a XMS manager) is as much a part of DOS as is, say, the redirector.
- he renamed "KRNL386.EXE" (the main Windows executable) to something else,
and copied COMMAND.COM into KRNL386.EXE
- then he ran "WIN /3", the program that runs the extender (VMM32.VXD) and
then uses "KRNL386.EXE" as shell, this is, COMMAND.
- he entered on a magic world of having pure MS-DOS inside a VMM.
Everything ran as MS-DOS does, but when he ran the example program, he
could allocate more XMS than the existing physical memory, and all that
because the underlying VMM32.VXD+VSD's were doing the virtual memory magic.
Pure MS-DOS, inside the most DOS-compatible VMM implementation that one can
get. The book also mentions that in some Windows versions, the extender was
called DOS386.EXE, instead of VMM32.VXD, quite meaningful. In my opinion,
DOS386.EXE is more an MS-DOS piece than a MS-Windows piece: Windows was
"merely" a fancy (and complex) GUI DOS application ran on top of DOS386,
that was also coded to run on top of NTOSKRNL.
One of the (IMHO) brightest (and latest) additions from Microsoft to
MS-DOS, that I suppose that was coded after EMM386.EXE.
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.
>
I don't see it as you do. First, I guess many FreeDOS users actually use it
on DOSEmu, or any other VMs, less on bare metal. It is the same FreeDOS in
both cases, and it has always been "out of the scope" of FreeDOS project:
in the latter case, FreeDOS relies on BIOS manufacturers. In the former, I
simply mean to "outsource" it to the Linux project ;) You never care how
to deal with multiple drivers in a 32/64 bit world: as long as DOSEmu
translates the Linux stuff into BIOS-compatible stuff, we are safe ;)
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.
>
What I dislike of the third approach, is that sooner or later, you will
have to standarise and tell how to "write drivers" for such a FreeDOS-32
project. The option (1) says: don't make it up, just write good old VxD's.
I don't know the internals of FreeDOS-32, but maybe (1) and (3) are not
exclusive from each other: I seem to remember that at some point, the
FreeDOS-32 guys did a 32-bit FAT driver. Perhaps that could be turned into
VFAT/VREDIR...
Cheers,
Aitor
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
