Maybe you should not be a noob, and use linux instead!

LOL! ;-)

"but then again forthrightness has never been one of Microsoft's shortcomings"... I'd say IT IS one of their shortcomings... It seems internal emails are the only time we get the truth out of Microsoft.

Linux has its fair share of compatibility issues as well, and as this blog has pointed out before, certain areas (such as hardware suspend) are still very messy. The underlying truth is that operating systems are hard to write, and a huge development team and widespread industry support (as Microsoft and Linux can both claim these days, to varying degrees) does not guarantee device compatibility and stability.

Randall hints at the difference: Microsoft plays mum and hopes nobody complains loudly enough to cost them, whereas Linux developers lay the bugs out publicly while they work to fix them.

Ah yes, device driver UI.

In days gone by, we ran a service that communicated with the device driver and the service handled the UI. That's not allowed anymore. Services can't do UI. So, how do we get around that. You can't guarantee that you can get an exe started from registry run entries so you have to do something else...

Your service waits for a logon and INJECTS AN EXECUTABLE into the logon session. What user context is this going to run in? It depends on which process you steal a token from. Admin if you use winlogon.exe. Perhaps you find explorer.exe and actually get the user's token and run as the logged on user. The executable then communicates with the driver and does the UI.

Now what will developers do to get something out quickly. Are they going to add some kind of RPC or COM interface to their service and have the executable call it or are they going to shunt their admin level code from the service into the executable and run the executable as admin?

If they do the second, the service isolation has achieved absolutely nothing. In fact some operations (installing mirror drivers for example) require admin access in the console session. It simply cannot be done from a service any more. So now we have a plethora of 'helper' executables that get run in admin contexts. More secure? I doubt it.

Kinda like the system device drivers CD's that a certain cow brand computer that shipped with a virus on the CD. I called their tech support who said they knew about the virus but would not replace all of the CD's and only the people like myself who called them would get a new set shipped to them. I told tech support that we had 15 of their new computers but the tech support would only ship my company one set of cd's unless I called 14 more times and requested replacement cd's. That lack of support showed me how worthless any warranty was from this company and I have never purchased a cow brand computer since 1996 and never will.

These noobs that recommend Linux to you don't read your blog much, eh?

Sad, but the driver fiasco and late OS changes that broke what was supposed to work seems like a cruel trick by Microsoft. Make a late release break stuff you don't want to support, let the third parties take the heat, and you get plausible deniability for renigging on a promise to support 'legacy' drivers. Manufacturers, having been blindsided, waffle on new drivers untul the smoke clears. 6 months later, everyone who jumped on board has already replaced those old printers, video cards, and wireless adapters. Problems solved. Terrible.

By doing things like this, Microsoft killed their credibility over Windows Server 2008, We are now very skeptical about integrating it anytime soon, even if it's supposed to be a near perfect product (yeah right).

there credibility and anything new they put out is shuned not only by the IT and hardcore community but also by the gaming community.
i belong to a quite sizeable group at my high school composed of seniors and juniors and we all agree that a computer needs at least 4 hard drives
linux
windows XP
a storage drive
and the smallest a vista drive
this way u can seperate good ol' linux and XP from that crapy vista
we use vista sherly for DX10 games. and now were regreting it with the relece of games like crysis that put too much into looks over quality of gameplay!
so as far as vista goes
skrew taht side of microsoft and there "special" mail

Many good points in Randall's article.

However I would take issue with one statement:

"... Microsoft's vaunted backwards compatibility ...".

I trust that this was meant to be taken at face value, and not cynically. If so, then Microsoft does not have a very good track record of backwards compatibility. It is not a big deal for them and never particularly was.

I have some significant background in large systems by IBM. Now THERE's a company, and a product set, that truly values backwards compatibility. The lengths they go to are astounding when you investigate the matter.

IBM does such a good job that applications often don't progress very quickly, just because they don't have to. Interfaces, functions and features have amazingly long lifetimes, often measured in decades.

Contrast this with Microsoft's driver model. DOS's driver model was different than 3.x, requiring total rewrites. It changed again with 9.x, NT 3.x, NT 4, W2k, XP, and Vista. Total rewrites each time. Now 64-bit drivers are required for 64-bit OS instances, even for non-critical peripheral drivers. Total rewrites again!

Take a look at Microsoft's data access model. Let's see, there was DDE, OLE, COM, COM+, ADO, DAO, .Net Data, MDAC, and I'm pretty sure I've missed a few others besides. Each one was the Next Big Thing.

So even though Microsoft supported 9x OS's alongside NT OS's for a long time, and one big reason was backwards compatibility, MS gets poor marks overall on the compatibility front from me. The end result is a lot of hassle and meaningless changes from the customer perspective.