>On 2002-02-17 19:24:55, J. Weeks wrote:
>
>Are you going to utilize the Win32 API, though?
>Or provide it, but utilize your own API mostly.
>
>I only ask, 'cuz the Win32 is fairly... rusty
>
Initially, I'll implement the DOS and Windows API, other improvments will come later. I would like to introduce a new clean, and easy to program API similar to that new one in OSX, which I hear is good. SO even though DOS and Windows API's wil be there there willl probally be a new one too. yOu have to under stand that I'm not simply cloning DOS and Windows, I am creating a modern DOS based OS that will be compatible with DOS and Windows since those are parts of the DOS family.
>
>Win 95/98/ME are based on DOS... but I wouldn't call them DOS.
>When I say archaic, I'm mostly refering to the "standards"
>is uses (FAT, for example). These things are pretty
>archaic by todays standards.
>
>Do you plan on using newer versions of components
>like these?
>
While I may use FAT, it will be FAT32, but it won't be as closed minded as MS-DOS, I plan on supporting other filesystems. In the end the default native file system will probally be a FAT so it can just replace others DOSes or Windows, but I may leave the Windows open for allowing others like EXT2/3 for those who want it.
>Also, do you plan on updating the CLI? DOS would be
>a lot more effective, and acceptable, if it were to
>incorporate things like command line completion, and
>a much more powerful scripting language.
>
I may update the command line to a point giving it a little more Unix-like power, although I won't adapt the full Unix synax.
>
>Well, I know the quality of FreeDOS's work, and repect
>that, I'm just weary...
>
The actual FreeDOS team has done a good job in making a DOS that would be powerful in the golden age of DOS, but I am going well beyond their work and beyon the work of the FreeDOS32 team.
>Creating a OS centered around a CLI is a great idea.
>CLI's are incredibly effective, and can speed up
>many tasks. But DOS is an old CLI
>
I'll admit that since Microsoft did control the direction of DOS for the most part it didn't grow the way it should have, but that's what I'm here for. My goal it to give DOS a head to toe makeover and turn it into a modern operating system, while still preserving the things that made DOS good and easy to learn.
>
>True. Multitasking legacy DOS applications is a lot
>more difficult then applications that were built
>for it, though (assuming you are planning on
>multitasking old DOS apps as well...)
>
It will handle old DOS apps about the same way as Windows does. Window kind of simulate a real mode environment for them and they usually work just fine. THe only problems that Windows has with DOS apps is the really old ones that really need to be in real mode, and like Windows, my DOS will be able to go to 116-bit real mode. Most likely this will be accomplished similar to how Windows does, it will boot down into real mode DOS, and in my case it will boot down to regular 16-bit FreeDOS.
>
>Yes, I realize, but as you said, it's an implementation
>on Unix systems. In order to utilize WINE, you'll
>either have to rewrite all Unix specific parts (which
>is (theoretically) exactly 50%) or create another
>immediatary software level... libraries intending
>to implement unix features used by wine, to implement
>the Win32 API.
>
>Just sayin', it could get messy.
>
I know this, mainly I'll just use WINE to guide me through the Windows API parts that don't rely on Unix, and this is the capacity that ReactOS uses WINE I think.
>
>Win95/98/ME applications (and the OS itself) _do_ run natively in protected mode.
>They may call older 16-bit DOS functions, but the
>majority of it has been rewritten for pmode (granted,
>not well).
>
I know that they do run in protected mode, but it's still very similar to how some protected mode DOS applications switch to 32-bit protected mode when run, and in this case Windows is that program. When Windows is running your computer is in 32-bit protected mode, and I know that. What I'm saying is that it would be better is if DOS itself was in 32-bit protected mode, and that would help out in the area of stability. The way Windows is set up is that the 16-bit real mode DOS that can run otehr 16-bit real mode apps, but it loads the Windows program which puts your computer in 32-bit protected mode. This is kind of an upside down pyramid, 16-bit then 32-bit. In my model the base DOS layer is 32-bit protected mode, and it can accomidate 16-bit apps by scaling down, instead of going up. having a 32-bit OS running 16-bit apps is more stable that having a 16-bit OS loading a 32-bit app.
>
>I wasn't meaning to say it was impossible, just that
>implementing another OS's API usually ends up being
>very messy.
>
It probally will be quite a chalenge, but I think it is possible.
>
>Fair enough. Well, give it a go, then, for sure.
>I think I'm still a little bit flakey on some of the
>internals of how you're going to do this, and
>how you'll differ from how M$ has done it, but
>if you can pull it off, then it will, indeed, be
>impressive.
>
Hopefully I can pull it off and show MS how they should have done Windows 95. This is less about the Windows clone, but more or less about how a modern DOS should be done, not like Windows 95/98/ME. While they were fine up to 3.x, it was time for a new DOS in '95. Basically what I'm trying to say is that DOS is back from the dead with a vengence.