Please help

[Norfleet]

Originally posted by Arryn:
If an app crashes and takes the OS with it, that's also an OS crash. A properly-written OS won't allow an app to corrupt the OS. Your wonky memory may not permit you to recall it, but DOS apps could very easily crash DOS.

Meh, you act as if Windoze applications don't regularly crash the entire computer as well. DOS, however, doesn't come with any perceptible loading time even on the crummiest computer. You turn it on, and it runs! For the reason, such features were not necessary.

I remember games like X-COM and Panzer General doing it, just to name two. If you think differently, then you're deluding yourself (or worse).

X-Com still crashes and takes out the entire computer at times, even in Windoze.

BTW, DOS, even running no apps, could crash too. Hard to do, but it was possible. All depended on the stability of what was loaded using the config.sys file. Then there's infamous DOSes like DOS 5.0 (fixed in 5.1 IIRC), 6.0 (fixed, sort of, in 6.01), and 6.2 (fixed in 6.22).

Not so. DOS, running nothing, sat there and blinked. It could do this for weeks. Months, years. Never crashing. Starting with Windoze 9x, that ended: Windoze can now crash even if left completely unmolested.

[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.

[Norfleet]

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.

[Cainehill]

Originally posted by Arryn:
[QBThe short answer as to what the big deal is today with needing a sophisticated installer can be summed up in two words: Windows Registry. The long answer involves *why* this is important, and an entire college-level course on the subject can be taught.
[/QB]

And even Microsoft has finally realized that the registry was a colossally bad idea; with the .Net compilers, the preferred install goes back to using something much more similar to the old .ini (or unix .cshrc) type files.

This is even for real applications. And _why_ did a game ever need to be put into the registry??? Install Solitaire, possibly destroy your computer because it updates the registry. Or because it updates the registry after you save a game, in order to update the Documents submenu for a recently used file.

Use of the Registry slowed down computer boot times, increased complexity, increased chances of catastrophic failure. Sure, _some_ things deserved to be in something like a registry - if a program handles a certain type of file, for instance.

But the options and settings for the program itself should never have been in the registry. 10 years later, Redmond's blunderers finally start to realize this.

[Mad_Lear]

Well, back to the original topic, did you try simple things like a cleanboot ( http://support.microsoft.com/default.aspx?kbid=310353 for XP- just make sure to hide those Microsoft services, and, just between you and me, leaving those ".ini" files alone might not be a bad idea; there are other equivalent articles for the other O/S's, of course, except for Win 2000) or disabling the antivi (make sure you are firewalled before trying either of those steps- the plain-jane XP firewall would do for a short haul like an attempted dom2 installation)?

Antivis, in particular, can cause all sorts of problems, especially if you have it configured to be restrictive- Norton Internet Security, for example, can change the permissions of certain key registry keys, so that user-initiated programs (or, for that matter, just cracking-open regedit and trying to edit certain keys) will fail. Also, the tried and true method of installing from a flat (copying the whole disk to a directory on drive 'c:' and running the installation from there) could weed out a wonky CD drive (new computers tend to get dropped/trampled/played ping-pong with in transet, so they often arrive as broken computers) or, alternatively, a CD so fancy and fast it outruns the installer.

Finally, if it's a new computer, make sure your manufactured didn't screw you with a "user friendly feature" like a pre-partitioned hard-drive with a 500 meg "c:\ drive" or a pre-made user account with limited permissions- I kid you not, I've seen companies sell computers with setups like these, thinking all the time that they are making things easier on the buyer.

I know most of this is pretty basic, especially considering how computer-literate most of this forum is, but I just had to bring it up, since 90% of the time, the basic stuff is the bread-and-butter of getting past most problems. I mean, no need to track down the specific problem .dll file or registry key, when you can just shut down most of the crude in the background with a cleanboot and take out the problem program/process purely through colatarol damage!

BTW, a spyware sweep with a good program (links to a few good ones can be found at www.microsoft.com/spyware ) might not hurt as well. Spyware are the devil- they aren't as mean as viruses, but they are often much more subtle, and put up just as much of a fight when you try to remove them...

Anyway, just a few simple suggestions from a less philosophical, more pratical perspective!

[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.)