rock_nog wrote:Wow, that just sounds like the epitome of bad design. Who on Earth would design software specifically so that it could not be removed (aside from virus and malware programmers)? I mean, if something goes wrong, you'll have to reinstall the whole OS. That's just absurd!
There's two things at work here.
First, it's IE 8 beta 2. There is risk involved with running beta software. Between the final beta and the RTM, there is tons of testing that is done in an attempt to catch oddball scenarios like this and address them. The beta phase is the phase in which you are telling your customers, "We have implemented all of the features and fixed all known bugs. Please evaluate this software and tell us about any bugs you find." In other words, "There are bugs, but the 30 of us can't find them as easily as the 100,000 of you." In other words, "This has no guarantee and could completely bork your machine. Take precaution."
I blame Google and several other companies for screwing up the public perception of what a beta really is; Gmail's been "beta" since the day they released it. They probably have some stupid reason that sounds like, "Oh, Gmail is under continuous development and the beta status reflects this!" but that's bull. That means you have a release candidate (the working version of Gmail) and a beta (the version under development).
So, to read this headline as it really is, it should be, "John Q. Public amazed that pre-release version of software not meant for widespread public distribution has bugs." Sorry John, you are ignorant of the software development process and you shouldn't have downloaded a beta.
Now, on to the other point:
Wow, that just sounds like the epitome of bad design. Who on Earth would design software specifically so that it could not be removed (aside from virus and malware programmers)? I mean, if something goes wrong, you'll have to reinstall the whole OS. That's just absurd!
It's probably not their fault, and if you have a little understanding of how Windows Installer works you could see how this can happen. Unfortunately, I do have a little bit of knowledge.
Go have a look at some directories on your system. C:\Windows is the first one we'll talk about. How many directories that match the pattern $NTUninstall.*$ are there, how big are they? This is the information that Windows Installer saves so that it can uninstall a Windows Update. If you dig around in them, you'll find a ton of DLLs and system files. What's happening here is when you install an update, the system first determines what system files will be replaced, then it backs up the file to one of these places. Finally, the new system file is saved over the old one. If you uninstall the update, Windows Installer will try to replace the current system file with this backed-up copy. You'd think that Windows Installer would be smart enough to notice that the file was updated after this update and not replace it. You'd be wrong. There's two choices it can make in this scenario, both of them bad:
- Decide you are saying, "This update broke something; make my system like it was before this update was installed." In this case, the proper response is to replace the system file with the backup.
- Don't think about anything; leave the current file alone.
Think about these two options for a moment. I can give you a doomsday "Your machine is broken" scenario for both of them. Let's look at the first case (replace the current file) and why Windows Installer might pick it. Let's say you install a hotfix that trashes your networking; you need to get your old behavior back, and replacing the DLL with the backup will do this. Now, let's look at the doomsday scenario. You install a hotfix that replaces XYZ.dll with a new version. Later, you install a 2nd hotfix that adds new things on top of the first hotfix's XYZ.dll, so it gets replaced again. Now, you realize that hotfix 1 broke things, so you go about uninstalling it. Oops! Now hotfix 2 is expecting XYZ.dll to be a different version than it really is! You broke the system!
Let's look at the other option ("Leave my files alone!"😉 in the same scenario. You install an update that trashes your networking. You uninstall the update, Windows Installer sees that XYZ.dll hasn't been updated, so it replaces the backup and you're back to normal. Now let's look at the doomsday scenario. Hotfix 1 installs XYZ.dll version 2. Hotfix 2 installs XYZ.dll version 3. You trace problems to hotfix 1, so you uninstall it. Windows Installer leaves XYZ.dll version 3, since it's newer than the one that was installed. Oops! Since this is version 3, it contains version 2, so you'll still have the problem. Even worse, when you uninstall hotfix 2, it backed up XYZ.dll version 2, which is not what you want! You broke the system!
In many cases, Windows Installer can identify dependency problems like this and sort out that you must uninstall things in a specific order. This is in RTM software; it requires the installer developer to do a good bit of work to make it happen, and basically consists of identifying every other installation package that can cause a problem. The only way to find these problems is to test, which is something a beta is meant for. In the end, the developer has to make the choice as to which of the two behaviors to follow. This bug is probably the result of the default behavior being wrong in this special case.
So, you install IE8 Beta 1 because you don't realize what beta means. Then, you install XP SP3, which updates a ton of system DLLs. Then, you upgrade to IE8 Beta 2, which updates the same system DLLs again; however unbeknownst to you, some of these DLLs were built at a time when SP3 wasn't finalized, so they are basically in an SP 2.5 state. Now you have a version conflict: uninstalling IE 8 puts things in a state SP3 can't handle because it thinks its SP 2.5 version of the DLL is older than the backup so it doesn't replace it. Oops! These DLLs don't work with vanilla SP3 so your systme is borked. What if you uninstall SP3 instead? You go back to the SP2 versions of the files that don't work with IE8 b2, and your system is borked.
Wait for the release of the product to get indignant. If you don't have full system backups ready to deploy, you shouldn't be touching beta software.