Not really, there is plenty of seperation on NT, but because all of Windows' programs use Win32, its crashing trigger a BSOD.
NT itself can keep on running, but because of "political" (for lack of better term) reason, it BSOD.
Okay, NT employs layers for almost anything, btw.
You can read a file from disk without going through 3 layers at least, usually.
Explorer can be liken to kpanel, or whatever it's call.
It handle the desktop, the taskbar, tool bars (like quick launch), etc.
USER can be liken to windows manager, it handle (among other things) the windowing.
GDI is like X, I would argue that it's better, because it abstract the hardware details from you, but this is a subject for more debate.
The problem is with USER crashing, because it handle more than just windowing, it also handle the messaging for Win32. For detials, refer to Inside Windows 2000.
It is possible to not use the GUI, but having a GUI stub, which is how NT Embedded does it, IIRC.
Okay, first, drivers don't have to run in the kernel space.
They *can* run on ring 1/2, the reason that they don't is that some proccessors only have 2 levels of speration, so NT & Linux (no idea why 9x doesn't implements it, as it's as platform spesific as possible.) are forced to use 2 levels of speration, kernel (ring 0) & user (ring 3) because they are portable.
Second, ntoskrnl.exe & explorer.exe *do* run in seperate spaces. Explorer.exe run on ring 3, as a user level process.
(I wouldn't be surprised if notepad.exe would run at ring 0 on 9x, btw)
What you are referring to is USER & GDI, GDI is the graphic primitives, which actually translate the orders from the program to the hardware.
USER is where most of Win32 lives, it handle the GUI (higher abstraction than GDI), Windows Messaging, etc. [*]
Because of the way NT is designed, if USER crash, regardless of where USER lives, NT goes down as well.
Why? Because without USER, all the information that Win32 has goes south and dies.
This has adverse affects on any program that uses Win32 (99.999999999% of them does).
There is nothing I can compare this to in Linux, I believe, as Linux employs monolitic, rather than layered, model.
On Win9x, if USER goes down, there is nothing to "catch" the computer if USER goes kaboom.
* This is not a techincal explanation, but it should give you some understanding on how it works.
Third, I didn't say that Win9x is single task, I said that it's design was influence from the single-taskness of DOS.
Because one of the *major* design goals of Win9x was to stay compatible with DOS applications.
This made it impossible to implement real seperation of applications from the hardware, as many DOS applications did direct hardware calls.
Memory protection was also a problem.
The single user aspect of 9x kicks you in the balls when you want to talk about security & seperation of tasks.
It's just an extention of the problems caused by DOS compatability, though.
Forth, X does makes direct hardware calls, and as such, capable of making the machine hang.
It makes sense, bussiness wise, to drop support on the OS where they don't have a cost-effective relationship.
If a lot of their users used Linux, they would've certainly supported it, as it is, apperantly only a minority uses their product from Linux, so it's not cost effective to maintain support.
No, that isn't that much of a flaw as you present it.
Drivers *always* run in kernel space, both in NT/9x & Linux.
And *much* of the instability of windows can be traced to the fucked up design of 9x, which can be traced to the signle user/single task/no-protection-whatsoever-any-application-has- complete-control-on-the-box model of DOS.
I must say that EZCD 4&5 are POS.
I mean, there is a (cause BSOD!) bug from 4(!) that not only have not been fixed up until now, but is also present in 5(!!!).
I think that you can limit forking per user on Linux.
On NT, you can do something *like* it, by taking all the GDI objects to yourself.
IIRC, there is a (global) limit of 4000 GDI objects, and once you hit this limit, no application can create more GDI objects.
This require the use of two processes, btw, because a single proccess is limit to 3000 GDI objects/only/.
I agree, but you have forgot two things:
A> The OS can only protect itself from applications whose permissions are limited. (IE, as root, I can hose a Linux system, not matter how stable it is supposed to be).
B> Windows 9x is a single user OS, meaning that everything runs as root. We can spend a long time discussing how bad it is. But it was neccecary for backward compatability.
Win9x can't be blamed for its instability, it allows direct access to hardware, for crying out loud. What you *could* blame is Win9x design, which prevents the system from being stable.
MS did a wonderful job making it semi-stable, though. I mean, I can seat on a 9x machine and don't get a BSOD for an hour at a time, sometimes.:-D
Actually, MS' guidelines says that installer has to make certain that it doesn't replace newer DLLs with older ones. It also has a good mechanism to track DLL usage, so you know when you can safely delete a DLL.
Unfortantely, a lot of people ignored both recomendations, which cause the problem.
Although, I must say, I've not encountered such a problem on windows in a long time. Has something changed?
I agree that this is a good way to poll about the server OS.
But, as you said, if they didn't have a cross group survey, then it's pretty useless.
ISPs tend to use *nix deriatives, and office networks (file & print sharing, mainly) tend to be NT, frex.(Just the two most distinct groups that I could think of, don't flame me for this)
You could get a totally true, but meaningless statistic if you poll your target correctly.
Not really, there is plenty of seperation on NT, but because all of Windows' programs use Win32, its crashing trigger a BSOD.
NT itself can keep on running, but because of "political" (for lack of better term) reason, it BSOD.
Okay, NT employs layers for almost anything, btw.
You can read a file from disk without going through 3 layers at least, usually.
Explorer can be liken to kpanel, or whatever it's call.
It handle the desktop, the taskbar, tool bars (like quick launch), etc.
USER can be liken to windows manager, it handle (among other things) the windowing.
GDI is like X, I would argue that it's better, because it abstract the hardware details from you, but this is a subject for more debate.
The problem is with USER crashing, because it handle more than just windowing, it also handle the messaging for Win32. For detials, refer to Inside Windows 2000.
It is possible to not use the GUI, but having a GUI stub, which is how NT Embedded does it, IIRC.
--
Two witches watch two watches.
Um, any relation to my post?
--
Two witches watch two watches.
Sorry, but you can apply ACL to proccess, threads, whatever you want to.
--
Two witches watch two watches.
Okay, first, drivers don't have to run in the kernel space.
They *can* run on ring 1/2, the reason that they don't is that some proccessors only have 2 levels of speration, so NT & Linux (no idea why 9x doesn't implements it, as it's as platform spesific as possible.) are forced to use 2 levels of speration, kernel (ring 0) & user (ring 3) because they are portable.
Second, ntoskrnl.exe & explorer.exe *do* run in seperate spaces. Explorer.exe run on ring 3, as a user level process.
(I wouldn't be surprised if notepad.exe would run at ring 0 on 9x, btw)
What you are referring to is USER & GDI, GDI is the graphic primitives, which actually translate the orders from the program to the hardware.
USER is where most of Win32 lives, it handle the GUI (higher abstraction than GDI), Windows Messaging, etc. [*]
Because of the way NT is designed, if USER crash, regardless of where USER lives, NT goes down as well.
Why? Because without USER, all the information that Win32 has goes south and dies.
This has adverse affects on any program that uses Win32 (99.999999999% of them does).
There is nothing I can compare this to in Linux, I believe, as Linux employs monolitic, rather than layered, model.
On Win9x, if USER goes down, there is nothing to "catch" the computer if USER goes kaboom.
* This is not a techincal explanation, but it should give you some understanding on how it works.
Third, I didn't say that Win9x is single task, I said that it's design was influence from the single-taskness of DOS.
Because one of the *major* design goals of Win9x was to stay compatible with DOS applications.
This made it impossible to implement real seperation of applications from the hardware, as many DOS applications did direct hardware calls.
Memory protection was also a problem.
The single user aspect of 9x kicks you in the balls when you want to talk about security & seperation of tasks.
It's just an extention of the problems caused by DOS compatability, though.
Forth, X does makes direct hardware calls, and as such, capable of making the machine hang.
--
Two witches watch two watches.
It makes sense, bussiness wise, to drop support on the OS where they don't have a cost-effective relationship.
If a lot of their users used Linux, they would've certainly supported it, as it is, apperantly only a minority uses their product from Linux, so it's not cost effective to maintain support.
--
Two witches watch two watches.
Well, NIS to US-Dollars is roughly 4 to 1 (4.15 to be exact)
:-)
So you've about 1 dollar (0.96, to be exact)
I like being exact
--
Two witches watch two watches.
No, that isn't that much of a flaw as you present it.
- complete-control-on-the-box model of DOS.
Drivers *always* run in kernel space, both in NT/9x & Linux.
And *much* of the instability of windows can be traced to the fucked up design of 9x, which can be traced to the signle user/single task/no-protection-whatsoever-any-application-has
--
Two witches watch two watches.
The assumstion is that DLLs with the same name won't break backward compatability. :-)
This may not always be the case in reality, of course
--
Two witches watch two watches.
But that require an administrator privileges.
I must say that EZCD 4&5 are POS.
I mean, there is a (cause BSOD!) bug from 4(!) that not only have not been fixed up until now, but is also present in 5(!!!).
--
Two witches watch two watches.
I think that you can limit forking per user on Linux.
/only/.
On NT, you can do something *like* it, by taking all the GDI objects to yourself.
IIRC, there is a (global) limit of 4000 GDI objects, and once you hit this limit, no application can create more GDI objects.
This require the use of two processes, btw, because a single proccess is limit to 3000 GDI objects
You can also give stricter limitations.
--
Two witches watch two watches.
Some versions break backward compatability, which is the reason for the DLL Hell in the first place.
This is unlikely to change.
--
Two witches watch two watches.
And you would change your mind when you try to open several instances of the binary and find out that you've run out of RAM.
--
Two witches watch two watches.
I agree, but you have forgot two things: :-D
A> The OS can only protect itself from applications whose permissions are limited. (IE, as root, I can hose a Linux system, not matter how stable it is supposed to be).
B> Windows 9x is a single user OS, meaning that everything runs as root. We can spend a long time discussing how bad it is. But it was neccecary for backward compatability.
Win9x can't be blamed for its instability, it allows direct access to hardware, for crying out loud. What you *could* blame is Win9x design, which prevents the system from being stable.
MS did a wonderful job making it semi-stable, though. I mean, I can seat on a 9x machine and don't get a BSOD for an hour at a time, sometimes.
--
Two witches watch two watches.
I'm going to ignore most of the above, I can't agree with you, but I won't argue.
Most applications *can't* be uninstalled by deleting their directory.
You have registry keys, Dlls in Common Files, etc.
--
Two witches watch two watches.
Actually, MS' guidelines says that installer has to make certain that it doesn't replace newer DLLs with older ones. It also has a good mechanism to track DLL usage, so you know when you can safely delete a DLL.
Unfortantely, a lot of people ignored both recomendations, which cause the problem.
Although, I must say, I've not encountered such a problem on windows in a long time. Has something changed?
--
Two witches watch two watches.
I agree that this is a good way to poll about the server OS.
But, as you said, if they didn't have a cross group survey, then it's pretty useless.
ISPs tend to use *nix deriatives, and office networks (file & print sharing, mainly) tend to be NT, frex.(Just the two most distinct groups that I could think of, don't flame me for this)
You could get a totally true, but meaningless statistic if you poll your target correctly.
--
Two witches watch two watches.
How do you (try) to determain Linux market share?
Many Linux installations have not been bought, after all.
And while we are at the subject, how do you diffrenciate between Linux used as a desktop platform and as a server platform?
--
Two witches watch two watches.
I would like to note that a good IDE can really speed things up even for a good programmer, maybe it's worth it.
--
Two witches watch two watches.
Give some examples of ACLs being impossible to manage.
--
Two witches watch two watches.
Well, why not?
There is a RAD tool for it.
Visual Fortran. Get it here:
http://www.compaq.com/fortran/visual/index.html
--
Two witches watch two watches.
Even if you make it only 90% secure, then you are ensuring that a lot of people will not be able to hack you.
Since the number of truely talented hackers is small, that in itself reduce the chances of a break in.
--
Two witches watch two watches.
> encoding the clearance level and need-to-know requirements into the filesystem
You mean, like NTFS' ACL? Which NT had since forever?
Hell, NT can do it to any object whatsoever, not just files.
> Linux is the only OS extant they could have done this kind of work with.
No, they could've got any number of other OSes to do it for them.
Most Unixes has some sort of ACL capabilities, and I think that VMS has it as well.
--
Two witches watch two watches.
I'll bet you pennies to dollars that it doesn't have more functionality than Explorer.
--
Two witches watch two watches.
Microsoft support those, too.
What this guy needed to do is to *turn on* DAO.
It's off by default on Access 2000, but it's there.
As a note, DOS games written for 386 are working on XP, I think that MS knows a thing or two about backward compatability.
--
Two witches watch two watches.
Forgot to post as HTML.
Here the the GnuVB site:
http://www.multimania.com/sxpert/gnuvb/
Here is the chuckle inducing site:
http://asc.di.fct.unl.pt/~jml/mirror/vb.html
--
Two witches watch two watches.