Would this be completely crazy
-
Brandon Sharitt
Would this be completely crazy
I had a crazy idea, and I was wondering if it was really that crazy. As many of you might have noticed, there are many little groups springing up to create Windows clones that are based on FreeDOS. Manyof you may also agree that those would be just as unstable and insecure as Windows 95/98/ME. My question is, if you did it right would that be too crazy. If you accomplished this, not only would you provide an alternative to MS Windows, but you might also save DOS. You, might think there is no way to build a stable, secure, and modern Windows on top of DOS, but I do have a plan. In stead of just starting with the regular FreeDOS kernel, I would use FreeDOS32(The 32-bit protected mode FreeDOS kernel) as a base. After getting their DOS kernel, most people would begin work on the GUI and porting WINE, but that's one of the first mistakes. First you have to recognize that FreeDOS32 isn't complete even though it may run. First I would sure up the kernel to make sure it's fairly stable. Next, I would make it more secure, add nwere more advance features, and implement multitasking. After I have a stable, secure, 32-bit protected mode DOS operating system, then I would start working on the GUI. Most people want to just install SEAL, then get WINE working, but that's another mistake. First off, SEAL isn't designed for this type of thing and a new GUI will need to be developed. Also, WINE can't simply be ported, it will need to be rewritten, although it would be useful since it contains so much of the Win32 API. The API needs to be tightly integrated into the GUI, because unlike WINE and Linux, the Win32 will be your native API. After all this is doen, there should theoretically exist a ssecure and stable DOS based Windows. I am considering such an under taking, I just want some feed back first.
-
The Legend
RE:Would this be completely crazy
>On 2002-02-17 14:12:29, Brandon Sharitt wrote:
>I had a crazy idea, and I was wondering if it was really
>that crazy. As many of you might have noticed, there are many
>little groups springing up to create Windows clones that are
>based on FreeDOS.
Yes, I've seen those groups, but don't see the purpose for
Windows-Clones!
>Manyof you may also agree that those would be
>just as unstable and insecure as Windows 95/98/ME.
If you want to go as far and allow windows drivers
in your os, then it is going to be unstable. A lot
of Windows 9x's instability comes from bad design.
>My question is,
>if you did it right would that be too crazy. If you accomplished
>this, not only would you provide an alternative to MS Windows, but
>you might also save DOS. You, might think there is no way to build
>a stable, secure, and modern Windows on top of DOS, but I do have a plan.
>In stead of just starting with the regular FreeDOS kernel, I would use
>FreeDOS32(The 32-bit protected mode FreeDOS kernel) as a base. After
>getting their DOS kernel, most people would begin work on the GUI and
>porting WINE, but that's one of the first mistakes. First you have to
>recognize that FreeDOS32 isn't complete even though it may run. First
>I would sure up the kernel to make sure it's fairly stable. Next, I
>would make it more secure, add nwere more advance features, and implement
>multitasking.
Sorry, but DOS isn't as important for Windows 9x
as it has been for Windows 3.xx! It is basically
used for bootup, and Windows 9x is a large dos-extender,
but these programs invalidate the memory managment, apis
and the rest of dos.
>After I have a stable, secure, 32-bit protected mode DOS
>operating system, then I would start working on the GUI. Most people want
>to just install SEAL, then get WINE working, but that's another mistake.
>First off, SEAL isn't designed for this type of thing and a new GUI will
>need to be developed. Also, WINE can't simply be ported, it will need to
>be rewritten, although it would be useful since it contains so much of the
>Win32 API. The API needs to be tightly integrated into the GUI, because unlike
>WINE and Linux, the Win32 will be your native API. After all this is doen,
>there should theoretically exist a ssecure and stable DOS based Windows.
>I am considering such an under taking, I just want some feed back first.
Who wants to port WINE when he wants to write a Windowsclone???
WINE is a Windows-Emulator, in this case Win32 is your native API, just as you
have already pointed out!
The Legend
>I had a crazy idea, and I was wondering if it was really
>that crazy. As many of you might have noticed, there are many
>little groups springing up to create Windows clones that are
>based on FreeDOS.
Yes, I've seen those groups, but don't see the purpose for
Windows-Clones!
>Manyof you may also agree that those would be
>just as unstable and insecure as Windows 95/98/ME.
If you want to go as far and allow windows drivers
in your os, then it is going to be unstable. A lot
of Windows 9x's instability comes from bad design.
>My question is,
>if you did it right would that be too crazy. If you accomplished
>this, not only would you provide an alternative to MS Windows, but
>you might also save DOS. You, might think there is no way to build
>a stable, secure, and modern Windows on top of DOS, but I do have a plan.
>In stead of just starting with the regular FreeDOS kernel, I would use
>FreeDOS32(The 32-bit protected mode FreeDOS kernel) as a base. After
>getting their DOS kernel, most people would begin work on the GUI and
>porting WINE, but that's one of the first mistakes. First you have to
>recognize that FreeDOS32 isn't complete even though it may run. First
>I would sure up the kernel to make sure it's fairly stable. Next, I
>would make it more secure, add nwere more advance features, and implement
>multitasking.
Sorry, but DOS isn't as important for Windows 9x
as it has been for Windows 3.xx! It is basically
used for bootup, and Windows 9x is a large dos-extender,
but these programs invalidate the memory managment, apis
and the rest of dos.
>After I have a stable, secure, 32-bit protected mode DOS
>operating system, then I would start working on the GUI. Most people want
>to just install SEAL, then get WINE working, but that's another mistake.
>First off, SEAL isn't designed for this type of thing and a new GUI will
>need to be developed. Also, WINE can't simply be ported, it will need to
>be rewritten, although it would be useful since it contains so much of the
>Win32 API. The API needs to be tightly integrated into the GUI, because unlike
>WINE and Linux, the Win32 will be your native API. After all this is doen,
>there should theoretically exist a ssecure and stable DOS based Windows.
>I am considering such an under taking, I just want some feed back first.
Who wants to port WINE when he wants to write a Windowsclone???
WINE is a Windows-Emulator, in this case Win32 is your native API, just as you
have already pointed out!
The Legend
-
J. Weeks
RE:Would this be completely crazy
>On 2002-02-17 14:12:29, Brandon Sharitt wrote:
>I had a crazy idea, and I was wondering if it was really that crazy. As many of you might have noticed, there are many little groups springing up to create Windows clones that are based on FreeDOS.
No offense to any of these groups, but they're usually people that hate M$ because their friends do, think they can write an OS, but have no imagination, and end up writting copies of current OSs. Personally, I think you'd be better off writting something completely new and different. Hell, even M$ is starting to do so... XP's a new branch, not totally compatible with previous versions of 'doze.
>Many of you may also agree that those would be just as unstable and insecure as Windows 95/98/ME. My question is, if you did it right would that be too crazy. If you accomplished this, not only would you provide an alternative to MS Windows, but you might also save DOS.
Why would you want to save DOS!? DOS is archaic and disgusting. It served its purpose in the 80's... it's 2002. You want a text based system, fine... use Unix, not DOS.
>You, might think there is no way to build a stable, secure, and modern Windows on top of DOS, but I do have a plan. In stead of just starting with the regular FreeDOS kernel, I would use FreeDOS32(The 32-bit protected mode FreeDOS kernel) as a base.
Well, there's a good start, for sure. You 16-bit DOS apps'll have to be run in vm86 mode, of course.
>After getting their DOS kernel, most people would begin work on the GUI and porting WINE, but that's one of the first mistakes. First you have to recognize that FreeDOS32 isn't complete even though it may run. First I would sure up the kernel to make sure it's fairly stable. Next, I would make it more secure, add nwere more advance features, and implement multitasking.
That entire sentance is so incredibly vague. I'm not suggesting you can't do the above, but make sure you realize what that entails before actually starting it. God knows the world has too many "started" OS projects that'll never actually be finished because the programmer didn't plan well enough, or just couldn't do it!
>After I have a stable, secure, 32-bit protected mode DOS operating system, then I would start working on the GUI. Most people want to just install SEAL, then get WINE working, but that's another mistake. First off, SEAL isn't designed for this type of thing and a new GUI will need to be developed. Also, WINE can't simply be ported, it will need to be rewritten,
You'd think so... being a windoze emulator, and all. No one wants to have to _emulate_ their native binary format and library collection.
>although it would be useful since it contains so much of the Win32 API. The API needs to be tightly integrated into the GUI, because unlike WINE and Linux, the Win32 will be your native API. After all this is doen, there should theoretically exist a ssecure and stable DOS based Windows. I am considering such an under taking, I just want some feed back first.
The major problem here is that DOS _is not_ a 32-bit pmode OS. You can add those features to it, yes, but what if an application relies on those previous 16-bit interfaces?
The obvious answer is, provide both interfaces; well, there's a source of bugs, incompatibilities and instability.
And the Win32 API itself... I'm sure even _it_ relys of 16-bit DOS code. Remove it, and you'll have to rewrite those parts of the Win32 API to use your new 32-bit code (trivial, really... you'll have to do this no matter what), but again... what if something relies on those 16-bit proceedures to be in place.
My opinion; try it if you want, but you'd be _MUCH_ better off trying something entirely new and interesting. No one wants to see the same **** (and I do mean ****... we're talking about windows here
recycled over and over again. Instead, focus your thoughts from this project into writting a Win32 emulator for your new OS.
just my $0.02
Jeff
>I had a crazy idea, and I was wondering if it was really that crazy. As many of you might have noticed, there are many little groups springing up to create Windows clones that are based on FreeDOS.
No offense to any of these groups, but they're usually people that hate M$ because their friends do, think they can write an OS, but have no imagination, and end up writting copies of current OSs. Personally, I think you'd be better off writting something completely new and different. Hell, even M$ is starting to do so... XP's a new branch, not totally compatible with previous versions of 'doze.
>Many of you may also agree that those would be just as unstable and insecure as Windows 95/98/ME. My question is, if you did it right would that be too crazy. If you accomplished this, not only would you provide an alternative to MS Windows, but you might also save DOS.
Why would you want to save DOS!? DOS is archaic and disgusting. It served its purpose in the 80's... it's 2002. You want a text based system, fine... use Unix, not DOS.
>You, might think there is no way to build a stable, secure, and modern Windows on top of DOS, but I do have a plan. In stead of just starting with the regular FreeDOS kernel, I would use FreeDOS32(The 32-bit protected mode FreeDOS kernel) as a base.
Well, there's a good start, for sure. You 16-bit DOS apps'll have to be run in vm86 mode, of course.
>After getting their DOS kernel, most people would begin work on the GUI and porting WINE, but that's one of the first mistakes. First you have to recognize that FreeDOS32 isn't complete even though it may run. First I would sure up the kernel to make sure it's fairly stable. Next, I would make it more secure, add nwere more advance features, and implement multitasking.
That entire sentance is so incredibly vague. I'm not suggesting you can't do the above, but make sure you realize what that entails before actually starting it. God knows the world has too many "started" OS projects that'll never actually be finished because the programmer didn't plan well enough, or just couldn't do it!
>After I have a stable, secure, 32-bit protected mode DOS operating system, then I would start working on the GUI. Most people want to just install SEAL, then get WINE working, but that's another mistake. First off, SEAL isn't designed for this type of thing and a new GUI will need to be developed. Also, WINE can't simply be ported, it will need to be rewritten,
You'd think so... being a windoze emulator, and all. No one wants to have to _emulate_ their native binary format and library collection.
>although it would be useful since it contains so much of the Win32 API. The API needs to be tightly integrated into the GUI, because unlike WINE and Linux, the Win32 will be your native API. After all this is doen, there should theoretically exist a ssecure and stable DOS based Windows. I am considering such an under taking, I just want some feed back first.
The major problem here is that DOS _is not_ a 32-bit pmode OS. You can add those features to it, yes, but what if an application relies on those previous 16-bit interfaces?
The obvious answer is, provide both interfaces; well, there's a source of bugs, incompatibilities and instability.
And the Win32 API itself... I'm sure even _it_ relys of 16-bit DOS code. Remove it, and you'll have to rewrite those parts of the Win32 API to use your new 32-bit code (trivial, really... you'll have to do this no matter what), but again... what if something relies on those 16-bit proceedures to be in place.
My opinion; try it if you want, but you'd be _MUCH_ better off trying something entirely new and interesting. No one wants to see the same **** (and I do mean ****... we're talking about windows here
recycled over and over again. Instead, focus your thoughts from this project into writting a Win32 emulator for your new OS.just my $0.02
Jeff
-
Guest
RE:Would this be completely crazy
>On 2002-02-17 14:46:01, The Legend wrote:
>Sorry, but DOS isn't as important for Windows 9x
>as it has been for Windows 3.xx! It is basically
>used for bootup, and Windows 9x is a large dos-extender,
>but these programs invalidate the memory managment, apis
>and the rest of dos.
>
You're one of these greatly mistaken people who think that Winows 9X is beyond DOs a great deal, but it relies heaviliy on DOS. While it is just a big DOS extender, it is not in it self a seperate entitiy. There is no new Windows kernel, it uses the DOS kernel, although it does try to hid DOS as much as possible, and this is apartially why you can't use FreeDO or some other non-MS-DOS to boot windows, it's tied in too much. Any way you look at it Windows 95/98/ME is just newer versions of DOS that come iwth new GUIs, APIs, and slighly extended. If you have a version of Linux that only has the console, it's still Linux even if you add X-Windows, KDE, GNOME, and all that stuff. Even if it get's some new functionality, it's still Linux. The same is true for Windows 95/98/ME, it is still DOS, it is just extened, has a GUI, and a new API. The versions that are different are Windows NT/2000/XP, these don't have anything to do with DOS. My goal is to keep a DOS operating system around as a mainstream OS. If I wanted to merly clone Windows, I would work on ReactOS since it is based on an NT model. My first goal is to get a modern DOS out, then follow the path of MS-DOS, and create a GUI that utilizes the Windows API. While a side goal is to create a Windows compatible OS, it is maily geared toward creating a modern DOS based OS that lives beyond embeded systems. I think some of the earlier Unixes were 16-bit and maybe real mode, but today they've evolved into 32-bit protectd mode OS's with GUIs that brought in new APIs, and I think DOS should evolve in the same way.
>Who wants to port WINE when he wants to write a Windowsclone???
>WINE is a Windows-Emulator, in this case Win32 is your native API, just as you
>have already pointed out!
Yet another uneducated remark, if you visit the WINE site, I think you'll learn that WINE stands for WINE Is Not an Emulator. WINE implements the Windows API on Unix systems, it doesn't emulate it. If you would have read my post you would have seen that I said it was a bad idea to simply port WINE. WINE would be used to help implent the Windows API.
>Sorry, but DOS isn't as important for Windows 9x
>as it has been for Windows 3.xx! It is basically
>used for bootup, and Windows 9x is a large dos-extender,
>but these programs invalidate the memory managment, apis
>and the rest of dos.
>
You're one of these greatly mistaken people who think that Winows 9X is beyond DOs a great deal, but it relies heaviliy on DOS. While it is just a big DOS extender, it is not in it self a seperate entitiy. There is no new Windows kernel, it uses the DOS kernel, although it does try to hid DOS as much as possible, and this is apartially why you can't use FreeDO or some other non-MS-DOS to boot windows, it's tied in too much. Any way you look at it Windows 95/98/ME is just newer versions of DOS that come iwth new GUIs, APIs, and slighly extended. If you have a version of Linux that only has the console, it's still Linux even if you add X-Windows, KDE, GNOME, and all that stuff. Even if it get's some new functionality, it's still Linux. The same is true for Windows 95/98/ME, it is still DOS, it is just extened, has a GUI, and a new API. The versions that are different are Windows NT/2000/XP, these don't have anything to do with DOS. My goal is to keep a DOS operating system around as a mainstream OS. If I wanted to merly clone Windows, I would work on ReactOS since it is based on an NT model. My first goal is to get a modern DOS out, then follow the path of MS-DOS, and create a GUI that utilizes the Windows API. While a side goal is to create a Windows compatible OS, it is maily geared toward creating a modern DOS based OS that lives beyond embeded systems. I think some of the earlier Unixes were 16-bit and maybe real mode, but today they've evolved into 32-bit protectd mode OS's with GUIs that brought in new APIs, and I think DOS should evolve in the same way.
>Who wants to port WINE when he wants to write a Windowsclone???
>WINE is a Windows-Emulator, in this case Win32 is your native API, just as you
>have already pointed out!
Yet another uneducated remark, if you visit the WINE site, I think you'll learn that WINE stands for WINE Is Not an Emulator. WINE implements the Windows API on Unix systems, it doesn't emulate it. If you would have read my post you would have seen that I said it was a bad idea to simply port WINE. WINE would be used to help implent the Windows API.
-
Brandon Sharitt
RE:Would this be completely crazy
>On 2002-02-17 16:18:16, J. Weeks wrote:
>
>No offense to any of these groups, but they're >usually people that hate M$ because their friends >do, think they can write an OS, but have no >imagination, and end up writting copies of current >OSs. Personally, I think you'd be better off >writting something completely new and different. >Hell, even M$ is starting to do so... XP's a new >branch, not totally compatible with previous >versions of 'doze.
I agree with you about most of those groups, about hte only legimate one is really ReactOS. My plans are not for a real clone, but a work-alike, if that much. My plans are more in the area of a modern 32-bit, protected mode DOS based operating system, and since Windows 95/98/ME are just newer DOS versions with GUI and new APIs, it just seems right to implent those features in mine.
>
>Why would you want to save DOS!? DOS is archaic >and disgusting. It served its purpose in the >80's... it's 2002. You want a text based system, >fine... use Unix, not DOS.
>
I, like many others do like DOS, and I am planning to give DOS a major overhaul. If you don't like DOS don't use it. The same goes if you don't like Unix. When people say DOS is archaic, they are refering to the old DOSes with out GUIs or new APIs, but even Windows 95/98/ME are all DOSes. Mine will hopefully go beyond these.
>
>Well, there's a good start, for sure. You 16-bit >DOS apps'll have to be run in vm86 mode, of >course.
>
FreeDOS32 is working on something like this, and my work will likely be close with them.
>
>That entire sentance is so incredibly vague. I'm >not suggesting you can't do the above, but make >sure you realize what that entails before actually >starting it. God knows the world has too many >"started" OS projects that'll never actually be >finished because the programmer didn't plan well >enough, or just couldn't do it!
>
I know what I'm getiing into, and there are many resources out there to help me. Like I said before, FreeDOS32 is working on 32-bit protected mode, adn I belive there are projects out there implementing multitasking.
>
>You'd think so... being a windoze emulator, and >all. No one wants to have to _emulate_ their >native binary format and library collection.
>
Again, WINE Is Not an Emulator(I'm not yelling, that's what WINE stands for). WINE implements the Windows API on Unix systems, and contains large pieces of the Windows API, and could be used to implement it on other systems.
>
>The major problem here is that DOS _is not_ a >32-bit pmode OS. You can add those features to >it, yes, but what if an application relies on >those previous 16-bit interfaces?
>
>The obvious answer is, provide both interfaces; >well, there's a source of bugs, incompatibilities >and instability.
>
The FreeDOS32 working on allowing 16-bit real mode apps to run, but I don't think it will be to big of a problem, especially since it will run nativly in 32-bit protected mode and extend back to 16-bit real mode, unlike Windows and older DOSes which work the other way around.
>And the Win32 API itself... I'm sure even _it_ >relys of 16-bit DOS code. Remove it, and you'll >have to rewrite those parts of the Win32 API to >use your new 32-bit code (trivial, really... >you'll have to do this no matter what), but >again... what if something relies on those 16-bit >proceedures to be in place.
>
If all this was true, WINE wouldn't be possible. If the Windows API can be implemented on Unix, it should be able to exist on a close cousin to 16-bit DOS. Also, it also runs on newer 32-bit Windows NT/2000/XP systems, so it doesn't rely on strictly 16-bit stuff.
>My opinion; try it if you want, but you'd be >_MUCH_ better off trying something entirely new >and interesting. No one wants to see the same >**** (and I do mean ****... we're talking about >windows here recycled over and over again. >Instead, focus your thoughts from this project >into writting a Win32 emulator for your new OS.
>
If I wanted something completly different, ther are plently of opetions, I could just use Linux, but I like DOS, and if Windows was made right, I'd like it.
>
>No offense to any of these groups, but they're >usually people that hate M$ because their friends >do, think they can write an OS, but have no >imagination, and end up writting copies of current >OSs. Personally, I think you'd be better off >writting something completely new and different. >Hell, even M$ is starting to do so... XP's a new >branch, not totally compatible with previous >versions of 'doze.
I agree with you about most of those groups, about hte only legimate one is really ReactOS. My plans are not for a real clone, but a work-alike, if that much. My plans are more in the area of a modern 32-bit, protected mode DOS based operating system, and since Windows 95/98/ME are just newer DOS versions with GUI and new APIs, it just seems right to implent those features in mine.
>
>Why would you want to save DOS!? DOS is archaic >and disgusting. It served its purpose in the >80's... it's 2002. You want a text based system, >fine... use Unix, not DOS.
>
I, like many others do like DOS, and I am planning to give DOS a major overhaul. If you don't like DOS don't use it. The same goes if you don't like Unix. When people say DOS is archaic, they are refering to the old DOSes with out GUIs or new APIs, but even Windows 95/98/ME are all DOSes. Mine will hopefully go beyond these.
>
>Well, there's a good start, for sure. You 16-bit >DOS apps'll have to be run in vm86 mode, of >course.
>
FreeDOS32 is working on something like this, and my work will likely be close with them.
>
>That entire sentance is so incredibly vague. I'm >not suggesting you can't do the above, but make >sure you realize what that entails before actually >starting it. God knows the world has too many >"started" OS projects that'll never actually be >finished because the programmer didn't plan well >enough, or just couldn't do it!
>
I know what I'm getiing into, and there are many resources out there to help me. Like I said before, FreeDOS32 is working on 32-bit protected mode, adn I belive there are projects out there implementing multitasking.
>
>You'd think so... being a windoze emulator, and >all. No one wants to have to _emulate_ their >native binary format and library collection.
>
Again, WINE Is Not an Emulator(I'm not yelling, that's what WINE stands for). WINE implements the Windows API on Unix systems, and contains large pieces of the Windows API, and could be used to implement it on other systems.
>
>The major problem here is that DOS _is not_ a >32-bit pmode OS. You can add those features to >it, yes, but what if an application relies on >those previous 16-bit interfaces?
>
>The obvious answer is, provide both interfaces; >well, there's a source of bugs, incompatibilities >and instability.
>
The FreeDOS32 working on allowing 16-bit real mode apps to run, but I don't think it will be to big of a problem, especially since it will run nativly in 32-bit protected mode and extend back to 16-bit real mode, unlike Windows and older DOSes which work the other way around.
>And the Win32 API itself... I'm sure even _it_ >relys of 16-bit DOS code. Remove it, and you'll >have to rewrite those parts of the Win32 API to >use your new 32-bit code (trivial, really... >you'll have to do this no matter what), but >again... what if something relies on those 16-bit >proceedures to be in place.
>
If all this was true, WINE wouldn't be possible. If the Windows API can be implemented on Unix, it should be able to exist on a close cousin to 16-bit DOS. Also, it also runs on newer 32-bit Windows NT/2000/XP systems, so it doesn't rely on strictly 16-bit stuff.
>My opinion; try it if you want, but you'd be >_MUCH_ better off trying something entirely new >and interesting. No one wants to see the same >**** (and I do mean ****... we're talking about >windows here
recycled over and over again. >Instead, focus your thoughts from this project >into writting a Win32 emulator for your new OS.>
If I wanted something completly different, ther are plently of opetions, I could just use Linux, but I like DOS, and if Windows was made right, I'd like it.
-
J. Weeks
RE:Would this be completely crazy
>I agree with you about most of those groups, about hte only legimate one is really ReactOS. My plans are not for a real clone, but a work-alike, if that much. My plans are more in the area of a modern 32-bit, protected mode DOS based operating system, and since Windows 95/98/ME are just newer DOS versions with GUI and new APIs, it just seems right to implent those features in mine.
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
>I, like many others do like DOS, and I am planning to give DOS a major overhaul. If you don't like DOS don't use it. The same goes if you don't like Unix. When people say DOS is archaic, they are refering to the old DOSes with out GUIs or new APIs, but even Windows 95/98/ME are all DOSes. Mine will hopefully go beyond these.
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?
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.
>FreeDOS32 is working on something like this, and my work will likely be close with them.
Well, I know the quality of FreeDOS's work, and repect
that, I'm just weary...
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 know what I'm getiing into, and there are many resources out there to help me. Like I said before, FreeDOS32 is working on 32-bit protected mode, adn I belive there are projects out there implementing multitasking.
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...)
>Again, WINE Is Not an Emulator(I'm not yelling, that's what WINE stands for). WINE implements the Windows API on Unix systems, and contains large pieces of the Windows API, and could be used to implement it on other systems.
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.
>The FreeDOS32 working on allowing 16-bit real mode apps to run, but I don't think it will be to big of a problem, especially since it will run nativly in 32-bit protected mode and extend back to 16-bit real mode, unlike Windows and older DOSes which work the other way around.
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).
>If all this was true, WINE wouldn't be possible. If the Windows API can be implemented on Unix, it should be able to exist on a close cousin to 16-bit DOS. Also, it also runs on newer 32-bit Windows NT/2000/XP systems, so it doesn't rely on strictly 16-bit stuff.
I wasn't meaning to say it was impossible, just that
implementing another OS's API usually ends up being
very messy.
>If I wanted something completly different, ther are plently of opetions, I could just use Linux, but I like DOS, and if Windows was made right, I'd like it.
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.
Cheers,
Jeff
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
>I, like many others do like DOS, and I am planning to give DOS a major overhaul. If you don't like DOS don't use it. The same goes if you don't like Unix. When people say DOS is archaic, they are refering to the old DOSes with out GUIs or new APIs, but even Windows 95/98/ME are all DOSes. Mine will hopefully go beyond these.
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?
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.
>FreeDOS32 is working on something like this, and my work will likely be close with them.
Well, I know the quality of FreeDOS's work, and repect
that, I'm just weary...
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 know what I'm getiing into, and there are many resources out there to help me. Like I said before, FreeDOS32 is working on 32-bit protected mode, adn I belive there are projects out there implementing multitasking.
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...)
>Again, WINE Is Not an Emulator(I'm not yelling, that's what WINE stands for). WINE implements the Windows API on Unix systems, and contains large pieces of the Windows API, and could be used to implement it on other systems.
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.
>The FreeDOS32 working on allowing 16-bit real mode apps to run, but I don't think it will be to big of a problem, especially since it will run nativly in 32-bit protected mode and extend back to 16-bit real mode, unlike Windows and older DOSes which work the other way around.
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).
>If all this was true, WINE wouldn't be possible. If the Windows API can be implemented on Unix, it should be able to exist on a close cousin to 16-bit DOS. Also, it also runs on newer 32-bit Windows NT/2000/XP systems, so it doesn't rely on strictly 16-bit stuff.
I wasn't meaning to say it was impossible, just that
implementing another OS's API usually ends up being
very messy.
>If I wanted something completly different, ther are plently of opetions, I could just use Linux, but I like DOS, and if Windows was made right, I'd like it.
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.
Cheers,
Jeff
-
Brandon Sharitt
RE:Would this be completly crazy
>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.
>
>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.
-
Schol-R-LEA
RE:Would this be completely crazy
>On 2002-02-17 17:00:08, Anonymous wrote:
> There is no new Windows kernel, it uses the DOS
>kernel, although it does try to hid DOS as much
>as possible, and this is apartially why you
>can't use FreeDOS or some other non-MS-DOS to
>boot windows, it's tied in too much. Any way you
>look at it Windows 95/98/ME is just newer
>versions of DOS that come iwth new GUIs, APIs,
>and slighly extended.
As much as I despise sticking up for any of the
existing systems, I am afraid that I cannot let
this assertion pass, for two reasons:
1) It would be incorrect to state that MS-DOS had
a kernel, by the usual definition of the term.
DOS itself consisted of only two files, IO.SYS,
MSDOS.SYS (COMMAND.COM was solely a command
interpreter and program loader, and did not stay
resident while applications were running). The
services these provided were minimal; the only
actual DOS services (as opposed to BIOS services
or add-on drivers) were disk access, memory
allocation, and some text screen handling.
Second, DOS itself was not actively running while
applications were loaded; the services acted as a
sort of dynamic library, in effect. Finally, the
system enforced no policies and offered no
protection; it was possible, and frequently
necessary, to bypass DOS entirely, without so
much as a by-your-leave. This is why the Linux
comparison isn't valid; Linux, without KDE,
XFree86, or even BASH, is still a fully
functional OS, capable of running all it's
services (as all the embedded Linux systems
demonstrate); the same is not true of MS-DOS. It
is a *Disk* Operating System - a means to accdess
FAT-based files - no more and no less.
2) All of these qualities which are missing in
MS-DOS are in fact present in Windows 9x/ME,
much though it may seem otherwise. While Windows
does indeed build on (and boot from) DOS, in
operation it is fundementally different. There is
a true, actively running kernel that provides a
wide variety of services, is continuously active,
and at least makes some vague attempt to protect
processes and prevent programs from unauthorized
access to resources (OK, you can stop laughing
now... I said 'attempt', not 'succeed'). It also,
in case you aren't aware, *removed* some of the
support for DOS programs along the line; DOS 7 is
incomplete compared to its predecessors, with
some of the older functions excised and a handful
of utilities eliminated. MS has kept only such
support for DOS that they had to to keep users
from balking at upgrades, and has reduced it
still further with each version of Windows, such
that DOS 9 (Windows ME) is but a mere shadow of
its former self.
> There is no new Windows kernel, it uses the DOS
>kernel, although it does try to hid DOS as much
>as possible, and this is apartially why you
>can't use FreeDOS or some other non-MS-DOS to
>boot windows, it's tied in too much. Any way you
>look at it Windows 95/98/ME is just newer
>versions of DOS that come iwth new GUIs, APIs,
>and slighly extended.
As much as I despise sticking up for any of the
existing systems, I am afraid that I cannot let
this assertion pass, for two reasons:
1) It would be incorrect to state that MS-DOS had
a kernel, by the usual definition of the term.
DOS itself consisted of only two files, IO.SYS,
MSDOS.SYS (COMMAND.COM was solely a command
interpreter and program loader, and did not stay
resident while applications were running). The
services these provided were minimal; the only
actual DOS services (as opposed to BIOS services
or add-on drivers) were disk access, memory
allocation, and some text screen handling.
Second, DOS itself was not actively running while
applications were loaded; the services acted as a
sort of dynamic library, in effect. Finally, the
system enforced no policies and offered no
protection; it was possible, and frequently
necessary, to bypass DOS entirely, without so
much as a by-your-leave. This is why the Linux
comparison isn't valid; Linux, without KDE,
XFree86, or even BASH, is still a fully
functional OS, capable of running all it's
services (as all the embedded Linux systems
demonstrate); the same is not true of MS-DOS. It
is a *Disk* Operating System - a means to accdess
FAT-based files - no more and no less.
2) All of these qualities which are missing in
MS-DOS are in fact present in Windows 9x/ME,
much though it may seem otherwise. While Windows
does indeed build on (and boot from) DOS, in
operation it is fundementally different. There is
a true, actively running kernel that provides a
wide variety of services, is continuously active,
and at least makes some vague attempt to protect
processes and prevent programs from unauthorized
access to resources (OK, you can stop laughing
now... I said 'attempt', not 'succeed'). It also,
in case you aren't aware, *removed* some of the
support for DOS programs along the line; DOS 7 is
incomplete compared to its predecessors, with
some of the older functions excised and a handful
of utilities eliminated. MS has kept only such
support for DOS that they had to to keep users
from balking at upgrades, and has reduced it
still further with each version of Windows, such
that DOS 9 (Windows ME) is but a mere shadow of
its former self.
-
Brandon Sharitt
RE:Would this be completely crazy
>As much as I despise sticking up for any of the
>existing systems, I am afraid that I cannot let
>this assertion pass, for two reasons:
>
>1) It would be incorrect to state that MS-DOS had
>a kernel, by the usual definition of the term.
>DOS itself consisted of only two files, IO.SYS,
>MSDOS.SYS (COMMAND.COM was solely a command
>interpreter and program loader, and did not stay
>resident while applications were running). The
>services these provided were minimal; the only
>actual DOS services (as opposed to BIOS services
>or add-on drivers) were disk access, memory
>allocation, and some text screen handling.
>Second, DOS itself was not actively running while
>applications were loaded; the services acted as a
>sort of dynamic library, in effect. Finally, the
>system enforced no policies and offered no
>protection; it was possible, and frequently
>necessary, to bypass DOS entirely, without so
>much as a by-your-leave. This is why the Linux
>comparison isn't valid; Linux, without KDE,
>XFree86, or even BASH, is still a fully
>functional OS, capable of running all it's
>services (as all the embedded Linux systems
>demonstrate); the same is not true of MS-DOS.
DOS can run without Windows, you can even use an alternate command interpreter.
> It
>is a *Disk* Operating System - a means to accdess
>FAT-based files - no more and no less.
>
>2) All of these qualities which are missing in
>MS-DOS are in fact present in Windows 9x/ME,
>much though it may seem otherwise. While Windows
>does indeed build on (and boot from) DOS, in
>operation it is fundementally different. There is
>a true, actively running kernel that provides a
>wide variety of services, is continuously active,
>and at least makes some vague attempt to protect
>processes and prevent programs from unauthorized
>access to resources (OK, you can stop laughing
>now... I said 'attempt', not 'succeed'). It also,
>in case you aren't aware, *removed* some of the
>support for DOS programs along the line; DOS 7 is
>incomplete compared to its predecessors, with
>some of the older functions excised and a handful
>of utilities eliminated. MS has kept only such
>support for DOS that they had to to keep users
>from balking at upgrades, and has reduced it
>still further with each version of Windows, such
>that DOS 9 (Windows ME) is but a mere shadow of
>its former self.
I'm not just using MS-DOS as a model, there are other DOSes that do more. Some of them like FreeDOS have what the Linux crowd percieve as more of a kernel, but there are differnent ways of actually looking at the kernel. While DOS isn't a monolithic kernel like Linux, and the "kernel" doesn't do as much. Comparing Linux and DOS at the lowest levels is like when someone said the Windows had better security than Linux. While the overall security of Linux is probally better, they're not hte same things, and different judgements can be made.
As a little bit of a disclaimer, while I've been defending my ideas, I may have made this sound like a plan in the works. While I am seriously considering it, I may not actually do it. I'm stuck between creating a modern DOS, or going with some new radical untested design.
>existing systems, I am afraid that I cannot let
>this assertion pass, for two reasons:
>
>1) It would be incorrect to state that MS-DOS had
>a kernel, by the usual definition of the term.
>DOS itself consisted of only two files, IO.SYS,
>MSDOS.SYS (COMMAND.COM was solely a command
>interpreter and program loader, and did not stay
>resident while applications were running). The
>services these provided were minimal; the only
>actual DOS services (as opposed to BIOS services
>or add-on drivers) were disk access, memory
>allocation, and some text screen handling.
>Second, DOS itself was not actively running while
>applications were loaded; the services acted as a
>sort of dynamic library, in effect. Finally, the
>system enforced no policies and offered no
>protection; it was possible, and frequently
>necessary, to bypass DOS entirely, without so
>much as a by-your-leave. This is why the Linux
>comparison isn't valid; Linux, without KDE,
>XFree86, or even BASH, is still a fully
>functional OS, capable of running all it's
>services (as all the embedded Linux systems
>demonstrate); the same is not true of MS-DOS.
DOS can run without Windows, you can even use an alternate command interpreter.
> It
>is a *Disk* Operating System - a means to accdess
>FAT-based files - no more and no less.
>
>2) All of these qualities which are missing in
>MS-DOS are in fact present in Windows 9x/ME,
>much though it may seem otherwise. While Windows
>does indeed build on (and boot from) DOS, in
>operation it is fundementally different. There is
>a true, actively running kernel that provides a
>wide variety of services, is continuously active,
>and at least makes some vague attempt to protect
>processes and prevent programs from unauthorized
>access to resources (OK, you can stop laughing
>now... I said 'attempt', not 'succeed'). It also,
>in case you aren't aware, *removed* some of the
>support for DOS programs along the line; DOS 7 is
>incomplete compared to its predecessors, with
>some of the older functions excised and a handful
>of utilities eliminated. MS has kept only such
>support for DOS that they had to to keep users
>from balking at upgrades, and has reduced it
>still further with each version of Windows, such
>that DOS 9 (Windows ME) is but a mere shadow of
>its former self.
I'm not just using MS-DOS as a model, there are other DOSes that do more. Some of them like FreeDOS have what the Linux crowd percieve as more of a kernel, but there are differnent ways of actually looking at the kernel. While DOS isn't a monolithic kernel like Linux, and the "kernel" doesn't do as much. Comparing Linux and DOS at the lowest levels is like when someone said the Windows had better security than Linux. While the overall security of Linux is probally better, they're not hte same things, and different judgements can be made.
As a little bit of a disclaimer, while I've been defending my ideas, I may have made this sound like a plan in the works. While I am seriously considering it, I may not actually do it. I'm stuck between creating a modern DOS, or going with some new radical untested design.
-
Schol-R-LEA
RE:Would this be completely crazy
Before responding, I will offer a partial
retraction: in retrospect, I realize that I was
far too strident and snide in my statements. I
apologize for any perceived slight that may have
occurred as a result.
>On 2002-02-18 18:09:11, Brandon Sharitt wrote:
>> This is why the Linux
>>comparison isn't valid; Linux, without KDE,
>>XFree86, or even BASH, is still a fully
>>functional OS, capable of running all it's
>>services (as all the embedded Linux systems
>>demonstrate); the same is not true of MS-DOS.
>DOS can run without Windows, you can even use an >alternate command interpreter.
You miss my point, perhaps. A Linux kernel
without a user interface is still an active
system in it's own right. An MS-DOS system, with
no UI, won't run at all, while one that has
launched an application acts only on the behalf
of the application; it takes no action of its own.
>>2) All of these qualities which are missing in
>>MS-DOS are in fact present in Windows 9x/ME,
>>much though it may seem otherwise. While Windows
>>does indeed build on (and boot from) DOS, in
>>operation it is fundementally different. There is
>>a true, actively running kernel that provides a
>>wide variety of services, is continuously active,
>>and at least makes some vague attempt to protect
>>processes and prevent programs from unauthorized
>>access to resources (OK, you can stop laughing
>>now... I said 'attempt', not 'succeed'). It also,
>>in case you aren't aware, *removed* some of the
>>support for DOS programs along the line; DOS 7 is
>>incomplete compared to its predecessors, with
>>some of the older functions excised and a handful
>>of utilities eliminated. MS has kept only such
>>support for DOS that they had to to keep users
>>from balking at upgrades, and has reduced it
>>still further with each version of Windows, such
>>that DOS 9 (Windows ME) is but a mere shadow of
>>its former self.
>I'm not just using MS-DOS as a model, there are
>other DOSes that do more. Some of them like >
>FreeDOS have what the Linux crowd percieve as
>more of a kernel, but there are differnent ways
>of actually looking at the kernel. While DOS
>isn't a monolithic kernel like Linux, and the
>"kernel" doesn't do as much. Comparing Linux and
>DOS at the lowest levels is like when someone
>said the Windows had better security than Linux.
>While the overall security of Linux is probally
>better, they're not hte same things, and
>different judgements can be made.
>
I think part of the prooblem may be lie in the
word 'kernel'. I've had in mind a very specific
technical definition, which may not be quite
what you've been thinking of. A kernel OS design
is a particular approach to structuring the
system; it specifically calls for a distinction
between, and a separation of, user and system processes, enforced by memory protection; the
ability of the OS to preempt user processes
arbitrarily; and a defined interface between the
user ans system modes. At least, that is my understanding of the idea.
Kernel structure is at once both a simple and
flexible design principle, and kernel based
(read: Unix) OSes have come to dominate OS design
since the late 1970s. However, there are other methods of OS design, and MS-DOS, at least, was based on one of those (the homogenous monolithic
design, I believe it is called). CP/M, OS360, and
early editions of MacOS had somewhat similar
structures, despite their radically different
performance and UI characteristics. Conversely,
Mulitcs, VMS, and (argueably) Windows 2000, are based on the layered system, which is more complex (in certain ways) than a kernel.
The term kernel has largely come to mean 'the main part of any OS', but it also refers specifically to the kernel design. I hope this clarifies some of the things I've said.
I have no idea what kind of design FreeDOS use, so I can't comment on it.
retraction: in retrospect, I realize that I was
far too strident and snide in my statements. I
apologize for any perceived slight that may have
occurred as a result.
>On 2002-02-18 18:09:11, Brandon Sharitt wrote:
>> This is why the Linux
>>comparison isn't valid; Linux, without KDE,
>>XFree86, or even BASH, is still a fully
>>functional OS, capable of running all it's
>>services (as all the embedded Linux systems
>>demonstrate); the same is not true of MS-DOS.
>DOS can run without Windows, you can even use an >alternate command interpreter.
You miss my point, perhaps. A Linux kernel
without a user interface is still an active
system in it's own right. An MS-DOS system, with
no UI, won't run at all, while one that has
launched an application acts only on the behalf
of the application; it takes no action of its own.
>>2) All of these qualities which are missing in
>>MS-DOS are in fact present in Windows 9x/ME,
>>much though it may seem otherwise. While Windows
>>does indeed build on (and boot from) DOS, in
>>operation it is fundementally different. There is
>>a true, actively running kernel that provides a
>>wide variety of services, is continuously active,
>>and at least makes some vague attempt to protect
>>processes and prevent programs from unauthorized
>>access to resources (OK, you can stop laughing
>>now... I said 'attempt', not 'succeed'). It also,
>>in case you aren't aware, *removed* some of the
>>support for DOS programs along the line; DOS 7 is
>>incomplete compared to its predecessors, with
>>some of the older functions excised and a handful
>>of utilities eliminated. MS has kept only such
>>support for DOS that they had to to keep users
>>from balking at upgrades, and has reduced it
>>still further with each version of Windows, such
>>that DOS 9 (Windows ME) is but a mere shadow of
>>its former self.
>I'm not just using MS-DOS as a model, there are
>other DOSes that do more. Some of them like >
>FreeDOS have what the Linux crowd percieve as
>more of a kernel, but there are differnent ways
>of actually looking at the kernel. While DOS
>isn't a monolithic kernel like Linux, and the
>"kernel" doesn't do as much. Comparing Linux and
>DOS at the lowest levels is like when someone
>said the Windows had better security than Linux.
>While the overall security of Linux is probally
>better, they're not hte same things, and
>different judgements can be made.
>
I think part of the prooblem may be lie in the
word 'kernel'. I've had in mind a very specific
technical definition, which may not be quite
what you've been thinking of. A kernel OS design
is a particular approach to structuring the
system; it specifically calls for a distinction
between, and a separation of, user and system processes, enforced by memory protection; the
ability of the OS to preempt user processes
arbitrarily; and a defined interface between the
user ans system modes. At least, that is my understanding of the idea.
Kernel structure is at once both a simple and
flexible design principle, and kernel based
(read: Unix) OSes have come to dominate OS design
since the late 1970s. However, there are other methods of OS design, and MS-DOS, at least, was based on one of those (the homogenous monolithic
design, I believe it is called). CP/M, OS360, and
early editions of MacOS had somewhat similar
structures, despite their radically different
performance and UI characteristics. Conversely,
Mulitcs, VMS, and (argueably) Windows 2000, are based on the layered system, which is more complex (in certain ways) than a kernel.
The term kernel has largely come to mean 'the main part of any OS', but it also refers specifically to the kernel design. I hope this clarifies some of the things I've said.
I have no idea what kind of design FreeDOS use, so I can't comment on it.
-
Guest
RE:Would this be completely crazy
>Who wants to port WINE when he wants to write a Windowsclone???
>WINE is a Windows-Emulator, in this case Win32 is your native API, just as you
>have already pointed out!
Actually, no. WINE stands for "WINE Is Not an Emulator." It is an implementation of the windows API on linux and X windows. I would, however, agree that it would be exceedingly difficult to port wine to another OS, it is rather heavily tied to linux and X-Windows
>WINE is a Windows-Emulator, in this case Win32 is your native API, just as you
>have already pointed out!
Actually, no. WINE stands for "WINE Is Not an Emulator." It is an implementation of the windows API on linux and X windows. I would, however, agree that it would be exceedingly difficult to port wine to another OS, it is rather heavily tied to linux and X-Windows