Please help

[alexti]

Originally posted by Arryn:
What M$ OS are you running now? And if it's XP Pro, what app(s) have you found that can take out the OS when the app crashes? I'm sincerely curious as I've yet to find one.

Well, Visual Studio from the same MS does it just fine. Just try take a breath while debugging some system wide hook. That nasty breakpoint-in-template multiplying bug in VC is also quite efficient. While OS can survive one or 2 deaths of VC, after a dozen or so it apparently runs out of its lives.

Generally, while NT/2000/XP are somewhat more stable (than DOS/Win95+), my development computer can rarely survive for more a week without a reboot. Even without working with system hooks or drivers (not that I actually work on drivers).

[Arryn]

Originally posted by Norfleet:

quote:

---

Originally posted by Arryn:
What M$ OS are you running now? And if it's XP Pro, what app(s) have you found that can take out the OS when the app crashes? I'm sincerely curious as I've yet to find one.

I mentioned X-Com, of course, although there are several other cases of a program crashing, immediately setting off a BSOD and taking out the rest of the operating system with it. I've had this happen in GalCiv also, and several others whose names elude me at this moment.

---

You didn't answer re: what OS you use. I can't get X-COM to work under XP Pro. But it doesn't take the OS out. At least not on my machine. Different hardware (and drivers) behave differently (an obvious statement that's not always obvious to everyone), so my eXPerience may not be typical. OTOH, I go out of my way to cherry-pick hardware components to make a stable machine. (Tom's Hardware helps a lot with this.)

[Arryn]

Originally posted by Cainehill:
Use of the Registry slowed down computer boot times

Not significantly, if you have modern HDDs and MBs. Running XP on a very old system, at the minimum spec, is another matter. (The worst culptit, though, isn't the Registry but all the device drivers that must be loaded.) My XP Pro system boots to the desktop in well under a minute, a helluva lot faster than my Win9x box that has a far smaller Registry.

increased complexity, increased chances of catastrophic failure.

Only if the programmer doesn't fully understand what's s/he's doing. Which, alas, is the case for 90%+ of all applications since most dev shops don't have people on staff that are experts at OS internals, or even if they do, they aren't the ones writing the install code.

[Graeme Dice]

Originally posted by alexti:
While OS can survive one or 2 deaths of VC, after a dozen or so it apparently runs out of its lives.

Well, if you're writing low-level software, then it's possible to crash just about any OS. Try making an I/O thread that runs at a higher priority than the kernel in *nix based systems for example.

[Arryn]

Originally posted by alexti:
Well, Visual Studio from the same MS does it just fine. Just try take a breath while debugging some system wide hook. That nasty breakpoint-in-template multiplying bug in VC is also quite efficient. While OS can survive one or 2 deaths of VC, after a dozen or so it apparently runs out of its lives.

Generally, while NT/2000/XP are somewhat more stable (than DOS/Win95+), my development computer can rarely survive for more a week without a reboot. Even without working with system hooks or drivers (not that I actually work on drivers).

The culprit is that M$, in their infinite (lack of) wisdom, never coded the OS (any of them) to make proper use of the Intel multi-ringed processor security architecture. The Windows OS kernel is not fully isolated from the rest of the OS, running in Ring 0 as it should. Windows' kernel and low-level device drivers are intermeshed and both run at the same processor priority/security ring (unlike linux). XP is better than 9x in that at least the apps themselves (not the device .dlls the apps may call) run in a different ring and thus are insulated from the rest of the OS. But even in XP, apps that have bad drivers can take the OS with them since the driver code runs alongside the kernel code.

MSVS interfaces with the OS at low levels, especially the debugger (something MS tells devs not to do with their own code, but MS is big on breaking their own "rules"), and thus can readily corrupt the kernel code. I've never crashed XP using VS, but I don't work on drivers either. I was too hasty in saying that I didn't know of any apps that crashed XP Pro, since I'd forgotten that VS has the capability to do so when used certain ways. Thanks for the reminder. (OTOH, in my defense, when I mentioned apps, I was thinking of end-user apps such as games and "productivity" apps.)

[Esben Mose Hansen]

Arryn: I like linux as much as the next man, but linux is only a little better than windows with regard to what runs at ring 0/1. In fact, all kernel modules run in the same ring as the kernel itself: it is monolithic. BSD is the same. If you want a microkernel, which does not exhibit this problem, you want HURD or other exoteric kernels. Last time I heard, (true) microkernels have a 20% performance hit (according to Tannenbaum as far as I recall)

Graeme Dice: It is getting difficult to crash a modern, hardened linux system. E.g, fork-bombs doesn't work anymore. The trick you mention I do not understand. The kernel has no thread or process as such; so I don't understand how you can determine or exceed it's prioty?

[Sheap]

As far as what runs in what ring, it isn't really that big a deal. First, most modern CPUs have only 2 rings, so if your OS is intended either for platform independence or targeted at a 2-ring CPU, you don't have a choice. This is pretty much everybody except Windows. Secondly, one of the reasons many CPU designs have only 2 rings, is because having extra rings isn't really all that useful. As evidence you can look at free Unix type systems, and note their great stability, yet they all run in 2 rings only. What should they be doing that they aren't, and how much real-world improvement would it give?