I don't have time to document all of this, so my post will be a summary.
The many failures of my new Vista system have been a huge (perhaps unforgivable) impediment to work (software development). To this point, we have approximately 17 hours with 2 Microsoft Visual Studio technicians, their manager (who, at the urging of said two technicians, and after conducting a responsible interview with myself, conscientiously escalated this well documented and *studied* issue to higher eschelons of support), a top system diagnosis technician (6 3/4 hrs yesterday -- he went home last night at 10:45 Toronto time, unfinished), and several other Microsoft support personnel. Two other Microsoft personnel wanted ***to charge me*** to report these many Vista faults (while of course we can understand how costly *it would* be for Microsoft to be *responsible* for the costs it inflicts on its market). Two of these some 17 hours were spent with three to four Microsoft technicians in conference, and approximately half of these 17 hours have been spent not only on the telephone clear across the country, but in shared desktop sessions where the several technicians involved have witnessed for hours on end, the behavior and consequences we have documented to be associated with SearchIndexer.exe. (In other words, the reported effects have been *thoroughly* demonstrated to Microsoft.) The chronology of problems we have collected over that time, demonstrates diverse process failures, largely (because this was the work we were doing) having to do with software installation, downloading updates, and installing updates.
I have collected data on many other related issues; and there are further unrelated issues, which are now further compounding the problems we already have. My Vista experience therefore can be summarized as absolutely disgraceful, obstructive dysfunctionality.
On top of this there is such a prolific number of "little things" (which amount to big things, as we routinely encounter them again and again) which Microsoft can never get right. What am I talking about? Hideous, stupid things. For instance, my Task Bar is 7 rows high, comprising 150 shortcuts in 10 separate toolbars. Obviously, a person will enable Auto-hide for such a configuration. So, for almost 7 hours yesterday, we're to invoke Run... procmon, regedit, cmd, msdt... on and on... and the real care by which this operating system is engineered (and these faults are never fixed) is *most* (and constantly) evident in the utterly stupid concept of invoking the Run dialog *behind* the Task Bar. Yep, click run, or Windows+r (with the Task Bar raised), and you'll never even see the Run dialog you just intended to access. No. You have to move the Task Bar out of the way each time; and you have to come back to background of the Task Bar to play the Microsoft game in this intentionally unuser-friendly dialog. This isn't exactly a standard worthy of the arrogance I will address in just a bit.
Just a few other issues: Change an icon for a tool on the Task Bar and it may *or may not* be refreshed to the tool; Rename a directory and the old folder and name may still be drawn where they were, with the new folder *name* being displayed on a new folder location -- with the obvious further ramification that you can't access the graphically displayed old folder and name... and you even have to wade through a redundant error dialog which documents *their* screwup if you dare click that erroneous representation of the former folder; Right-click a shortcut on your Task Bar and click Properties -- and you lose the intended dialog behind the Task Bar, just like the Run dialog.
Just simple things that anyone and everyone who has a right to call their self a software engineer should *always* get right.
The question is, what makes these people deaf to *years* of pleas and submitted flaws?
So, Jon, I appreciate the tests you are doing, but I forewarn you that *use* is going to be your real Pandora's box. Just for instance:
Because Microsoft provides no way ("obstructs"???) to bring mail forward from *the data* (a running hard drive from a system broken by the MS mup.sys infinite boot loop flaw), I have permanently moved my mail to Thunderbird. I start up this morning, open Thunderbird, and it starts to download approximately 30 emails. OK, so there goes SearchIndexer.exe again, and after about 30 seconds I click my stop watch. While this is happening, there is extremely slow response to other processes. I try to drag one of the new mails to a "Microsoft" folder, and it doesn't land there for a whole minute (similar to the extra time it takes to open Photoshop when SearchIndexer is busy). Five minutes of SearchIndexer.exe later I notice that a number of my hundreds of new manually built mail rules (because Microsoft *obstructs* bringing them forward from data) are not correctly executed. Hmmm. After SearchIndexer is finally finished, I apply the rules to the InBox and sure enough they are all correctly applied. Now, please note that well after startup I haven't noticed this *particular* manifestation of the competing processes -- the mail rules have always been correctly executed. But then, ask yourself what is the sanctity/reliability of the thread competition *handling* (by the OS), if Thunderbird's processes are *always* otherwise executed perfectly?
That's not a stupid question, and it *is* rhetorical.
These are just *some* of the things which are going on. What else?
Well, yesterday a Microsoft technician was attempting to perform regular diagnostic processes important to gathering evidence for systems engineers. We waded through masses of laughable of documentation in a shared session, and reach a point where the system is required to reboot to honor the changes. "Software engineers" of course "might" consider this too a flaw... but what happens next? Ostensibly, to successfully execute the reboot so that it will not break the shared session, the technician has to initiate the reboot. Everything on my system worked fine to that point, except when SearchIndexer competition precluded. So what happens? A new form of blue screen of death tells us startup has failed and Windows is going to diagnose the problem. OK, so Vista reports a $$%$@# of problems it is going "to repair." Really? No option to cancel or ignore. Vista reports it will run CheckDisk... and it tells a few other lies... the screen is blinking back and forth between this an that -- then finally, no diagnosis, no repair... only a few seconds into a process it tells us could take hours, all of a sudden (surprise), I'm at the password dialog for login.
Hmmm. So is everything fine?
Absolutely not. Things are such a $%@$%@$ mess now we have no idea yet how to restore the system without rebuilding it (and negating *days* I have in setting up my software -- which process of course I am going to have to go through again). We don't even know if we'll get my software development environment back on the system -- although, one would think, what with the indexing process being completed, the SearchIndexer thread competition which existed should not be a further problem. But...???
What are some of the further problems?
Well, just for starters, we try to open Internet Explorer (necessary nowadays only for Microsoft sites), and what happens? It *starts* to open, instantly closes, and presents us (still, *always*) with five successive dialogs which apprise us that a "navcancl" file "from ie...something.dll" cannot be opened. Well... research soon shows that evidently this yet another well known Vista issue... and so we go into the diagnostic and repair processes for this issue.
The only problem you see, is that at one point of this process we have to open the Users interface in Control Panel to do some simple verification of password data... and, (guess what?) ummm... we next are shown that Users *can no longer be opened*.
Well, "that's real good," right?
Actually, you can probably begin to understand now why this technician and I spent 6 3/4 hours on my system just yesterday.
Here are just *some* of the consequences:
I ***RELY*** on FireFox! But the Internet Explorer ***WE NOW CAN NEVER OPEN*** (it always closes and notifies you of the navcancl issue VISTA WILL NOT ALLOW US TO FIX) ***IS NOW PERMANENTLY SET AS THE DEFAULT BROWSER****. NO LINK I CLICK IN AN EMAIL FOR INSTANCE WILL EVER OPEN. YOU HAVE TO COPY THE LINK *SOURCE*, OPEN FIREFOX (THE ONLY OPERATIONAL BROWSER STANDING), AND LABORIOUSLY PASTE EACH LINK IN. And whatever way there might be to fix IE now, we do not yet know. We both decided to sleep on it. More research has to be done -- and were MORE, giant steps backward. "Where do YOU want to go today?"
You get the picture. I'm so frustrated right now I can't possibly tell you. All this is a giant leap backward from the worst of the Windows 3.x days; and about the only thing Microsoft can do right now, is to offer ME the job of assuring all these kinds of things get fixed. Believe me, nothing like this would even *be build* under my watch.
Instead, we have resistance from the systems engineer people. They want us *to reproduce* issues they readily know exist -- when several Microsoft technicians have *already* witnessed said events for hours on end, and when they were (and will be) produced by installing Microsoft software ***AT DAYS OF EXPENSE***!
Here is ONE THING which is wrong with this picture:
ANYONE who designs an *operating system* thread which *can* (and *does*) consume 95% of CPU and IO resources for *any* sustained period (more than a few seconds) *has committed a fatal (and rudimentary) design flaw from the very outset. But OBVIOUSLY, without any need to reproduce *anything*, the very fact the thread *can* consume so much of resources is therefore the issue -- and one which has to be fixed.
If this person (or these persons) worked for me, the rules of design would have forbid them to implement such an ill conceived philosophy. In fact, I wouldn't let them dedicate 25% of resources to such a thread; and here is why:
What you *really* need to do is dedicate UP TO 25% of resources to a certain *class* of OS thread. Why? Developer A has the selfish approach of whoever wrote SearchIndexer, and grabs the limit of the rule we subject them to ("25%"). Developer B does as well. So do C and D, and we're using 100% of resources.
The obligatory approach is to share only so much of system resources so that *other* competing process *can* succeed -- and that's the whole issue here: people *refusing* to do right the job they should (already) know is done wrong. When you hear it from a customer who can't use their system, you have really blown it.
There IS a way to build software without flaws. Many of us have been doing it for many years. If those well known principles are not enforced as a standard, this is the result. Moreover, this far inferior result is produced at far greater cost, because everyone in the development process suffers the consequences of the poor work. But shipping this to the consumer, and particularly as a glorious advancement, asking customers to pay to report flaws they and Microsoft technicians have well documented... is worthy of no more than a class action suit.
If Microsoft paid me for what they have already cost me *in this "one incident"* (playing by *their* rules), they couldn't hope to make it back for the next few centuries.
And yet, we have a broken system... and we're only hoping to gather evidence with broken tools... hoping to convince "engineers" their code has a problem which WAS obvious from the outset.