If Vista had gotten the reception it actually deserved, and become a brand worth keeping, it seems highly likely that the name would have been retained. And Microsoft knows it, which is why internally, Windows 7 is only version 6.1. Sure, the company has made specious claims that this is to avoid breaking applications with bad version checks, but the logic doesn’t really hold; many of those applications are just as broken by “6″ as they would be by “7,” and if that were such a concern then the minor version wouldn’t change either.

This might make sense to a lay person on a cursory reading, but as usual with software development, reality is full of subtle but important complexities. 

Pop quiz

Consider the following rather common version checking mistake:

// Our app is designed for XP (5.1) and later
if (majorVersion >= 5 && minorVersion >= 1)
{
    // Succeed
}
else
{
    // Fail
}

Given the returned version values from Windows XP (reports 5.1), Windows Vista (reports 6.0), and Windows 7 (reports 6.1) – which OSes will this program succeed on?

One commentor wrote:

“Maybe it’s finally time for MS to stop catering to bad ignorant developers that skip on reading the documentation? I suppose that’s what big A did.”

This, of course, is making an assumption that the design had anything to do with ignorant developers or developers not following some documentation.

But think about it… exactly which documentation would they not be following? I mean, if a developer built a 32-bit application that hardcoded windows\system32 – then clearly they wouldn’t have a problem if the 32-bit binaries were left in that directory. Their 32-bit application would continue to find the binaries its looking for just as before. On the other hand, if they’re going through the trouble to recompile their application for 64-bit, they could probably handle fixing that little issue along the way, right?

So it stands to reason that the decision was made on a different basis. Let’s see, if it wasn’t to support existing 32-bit apps, and it wasn’t for apps that are recompiled as 64-bit, then who would this arrangement benefit?

Well, I wasn’t around when WOW64 came about, but I have a theory. There’s another little kind of “program” out there that isn’t really 32-bit or 64-bit, in fact is isn’t even compiled at all. They aren’t sold on store shelves, but there are millions of them, often vital to the businesses and developers who use them.

They’re called scripts, and the chosen WOW64 model keeps most of them chugging along quite happily.

This afternoon we made a follow-up post addressing some of the suggestions, comments, and concerns that showed up in the comments to the original entry.

If you have more feedback, please keep it coming.  I and others will try to respond in the comments over there, or in future follow-ups.

Also, if you like the gadget, please go to the Gadget Gallery page and give it a good rating

Download Indexer Status Gadget on Live Gallery

When I bought my new car last year there was a car salesman at one dealership who only seemed concerned with what other options I was looking at.  He tried to tell me that I shouldn’t buy an Audi because they’re unreliable.  And so were BMWs.  His friend had one and a wheel fell off.  The engines “explode” sometimes he said. 

And you know what?  Maybe he really did have a friend who had a wheel fall off somehow, maybe he left a dealership or a mechanic and they’d forgotten to properly reattach one of them.  I know he didn’t like it when I mentioned I’d heard a similar story years ago from a friend with the brand of car he was trying to sell me.  I also know there were a tiny handful of people who did have problems with the old BMW M3 engines breaking on them (“exploding” being a technically correct, but incredibly misleading characterization).  Years ago I saw a website devoted entirely to people who’d experienced the problem.  There were about 60 of them, who all posted various pictured of their damaged engines for all to see.

There’s also a site like that for TTs.  And one for Mercedes SLs.

The thing is, he was never going to convince me that Audis were “unreliable” since I’d already owned 3 of them – each of which worked magnificently, and the ownership experience was always a great one.  Of course, I never miss any scheduled maintenance and always have any warning lights checked out immediately, which I’m sure greatly reduced the chances I’d have a problem.  He told me, “Well you must be lucky.”  I nearly told him to shove it.

What I really wanted to know when I went there was why I should buy the car he was trying to sell me.  Not why the other ones I told him I liked were bad choices.  It’s strange, but John Hodgeman is starting to remind me of that guy, which is funny because he plays the role of the PC.  But he’s really the only one of the two that even talks in the ads anymore, and he’s always going on about problems “he” has running Vista that I have never seen on any of my machines.

Just like that salesman, these ads are having the opposite of the intended effect on me.  You see, I’m planning to buy a new laptop in the next month or two.  I was waiting to hear what Apple is going to release.  But Dell’s recent announcements have had me start to seriously consider their new machines, like the new Latitude models – and I’ve seen some really nice lightweight Lenovo models recently as well.  So I’ve been torn… do I replace my trusty Macbook with another Mac?  Or do I save money and get a better system from Dell or Lenovo?

Watching these latest Mac ads is actually pushing me even more toward the latter.

Not to be outdone, Randall Stross at the NY times decided he could use some TechMeme love and wrote basically the same piece.

He says of Windows:

Painfully visible are the inherent design deficiencies of a foundation that was never intended to support such weight.

Yet he fails to mention what any of these deficiencies might be.

He then says the the best solution to any problems with Windows is to “start over.”  You know, because that worked so well for Intel when they tried it.

Stross has a point when he says that the time between XP and Vista was too long.  He probably even has a point when he says that Vista doesn’t look like a product that was in development for 6 years.

Guess what?  It wasn’t.  You see, back in 2001 the Windows division at Microsoft came up with the hair-brained idea to change pretty much everything, as Stross is suggesting now.  Only he’s too late, and Microsoft has already learned that throwing out everything you know about Windows and rocketing into a brave new managed-code-centric world just doesn’t work all that well.

Stross also uses some funny math and says that Vista is the equivalent of Windows “version 12.”  It’s as if he’s trying to say that somewhere under the pretty UI, the core of Windows hasn’t really changed since Windows 1.0.

Of course that couldn’t be further from the truth.  Windows NT was a completely new OS.  Windows 2000 was nearly a complete rewrite of that.  Server 2003 and XP SP2 saw more major changes under the hood, as did Vista itself.

That is to say, this isn’t your older brother’s Windows (“grandfather” didn’t quite seem appropriate given the time scale).

Even then, I’m still not sure why anyone thinks this “start over” idea has any basis in reality.  Do you really think it would only take a couple of years to write an entirely new OS with all the capabilities of Windows Vista? 

Stross also repeats the dubious claim that Windows is too “monolithic.”  With its NT microkernel, layered and massively componentized architecture, and hardware portability – he can’t be talking about the same Windows that is sold today.

Nobody’s OS is perfect and I’ll gladly accept that Windows has its flaws.  But if you want to get on someone’s back about being monolithic and having a hairy, crufty architecture – perhaps you should direct your attention elsewhere.  But at least Linux doesn’t have bugs or security holes, right?

Lastly, Stross and others seem to be under the mistaken impression that Microsoft is somehow unable to change the existing Windows codebase.  These guys present two options:

1) Build stuff on top of the last version of Windows.

2) Start over.

Why pretend that these are the only two options?  Especially when historically Microsoft has always chosen door number 3:

Take what you have and make it better.
Replace the parts that need replacing.
Don’t break something without a good reason.

Windam – I wonder why this would be released for Vista since search is already a well integrated feature to begin with.
Is it just because(optional)?

Maudit - Pardon my ignorance, but what the difference between Windows Search 4.0 and the one in Vista ultimate sp1, does it streamline into windows ?

A similar question was asked on Channel 9.

The answer is quite simple:

• Windows Vista includes “Windows Search 3.0″
• Windows Search 4 is an upgraded version of the indexer built-in to Vista.
• This release does not change the User Interface, it looks exactly the same.  The improvements are around responsiveness, resource usage, reliability, API support, etc.

A good analogy here might be DirectX.  Windows XP shipped with DirectX 8.1.  When DirectX 9 was released for XP, it didn’t change the way anything looked or behaved, but it made your system better.  You may apply a similar understanding to WS4.

• Faster queries, often several times faster
• Faster indexing / reduced resource usage
• Support for EFS (encrypted folders)
• Support for indexing delegate mailboxes
• Fixes for all the top reported Watson crashes / errors
• New group policy options

This release also adds the following Vista / Server 2008 features to Windows XP / Server 2003 systems:

• Remote query support (using the server’s indexed when querying a network share)
• Support for Vista-style preview handlers (Office 2007 documents, etc)

Read the KB article here for more details and complete feature list.

Download Links

Vista / 2008                    32-bit    |    64-bit

XP                                   32-bit    |    64-bit

2003 / WHS                    32-bit    |    64-bit

Vista users – don’t forget to grab the indexer status gadget!

IShellDispatch2 is one of the shell automation objects used to support scripting languages.  However, that doesn’t mean you have to use VBScript to gain some value from it.  In this case, IShellDispatch2::ShellExecute is exactly what we want, because it wraps the normal ShellExecute call but runs it from the context of the object implementing the interface – in this case, we want the IShellDispatch2 associated with the desktop shell.

Knowing this is only half the battle, though.  The next trick is to figure out just how to get to the right IShellDispatch2 object (the one for the desktop shell instance of Explorer.exe).

Fortunately, one of our architects, Chris Guzak (seen on C9 here), was able to point me in the right direction and connect up all the dots.

Our hunt begins with the IShellWindows interface, which can be used not only to reliably find the HWND for the desktop shell window, but also to get an IDispatch interface for it:

IShellWindows *psw;
    HRESULT hr = CoCreateInstance(CLSID_ShellWindows, NULL, CLSCTX_LOCAL_SERVER, IID_PPV_ARGS(&psw));
    if (SUCCEEDED(hr))
    {
        HWND hwnd;
        IDispatch* pdisp;
        VARIANT vEmpty = {}; // VT_EMPTY
        if (S_OK == psw->FindWindowSW(&vEmpty, &vEmpty, SWC_DESKTOP, (long*)&hwnd, SWFO_NEEDDISPATCH, &pdisp))
        {

Next, we need the IShellBrowser interface, and we get that by querying for IServiceProvider and asking the SID_STopLevelBrowser service for an IShellBrowser interface.  And from there we can get the IShellView.

IShellBrowser *psb;

hr = IUnknown_QueryService(pdisp, SID_STopLevelBrowser, IID_PPV_ARGS(&psb));
if (SUCCEEDED(hr))
{
    IShellView *psv;
    hr = psb->QueryActiveShellView(&psv);

From there we need to get to that IShellDispatch2 interface that started this whole adventure. 

IDispatch *pdispBackground;
HRESULT hr = psv->GetItemObject(SVGIO_BACKGROUND, IID_PPV_ARGS(&pdispBackground));
if (SUCCEEDED(hr))
{
    IShellFolderViewDual *psfvd;
    hr = pdispBackground->QueryInterface(IID_PPV_ARGS(&psfvd));
    if (SUCCEEDED(hr))
    {
        IDispatch *pdisp;
        hr = psfvd->get_Application(&pdisp);
        if (SUCCEEDED(hr))
        {
             IShellDispatch2 *psd;
             hr = pdisp->QueryInterface(IID_PPV_ARGS(&psd));

At this point you should be able to figure out where to go from here.

If that’s not easy enough, watch out for Part 3 of this series in the next day or two.  It will contain a sample and describe how the Start++ installer makes use of it.

What’s the difference?  Well, child processes inherit several things from their parents.  They inherit processor affinity, for example.  Most important these days, it seems, is the fact that processes inherit Integrity Level from the process that started them.  That is, except in the case of elevation from medium to high IL (the operation that causes the UAC dialog to appear).

So let’s say you write an installer, and you want to run the application installed at the end of the installation process.  Or heck, maybe you just want to call the application once with a special “/setup” parameter that tells it to do something you couldn’t do from your chosen setup utility.

Where do problems begin?  Well, installers typically run with admin rights.  When your installer launches your application as a convenience to the user, it’s now running with admin rights.  The primary concern here isn’t even the security implications of running at high IL.  After all, the next time your program starts it will run at its normal privilege level.

The problem is that your program is now running in a manner you may not have accounted for when writing it.  For example, users won’t be able to drag-and-drop anything to your application from normal processes.  If your program interacts with other non-admin processes, you may face other problems.  My own Start++ application faced this problem, as it needs to inject a small amount of code into Explorer.exe and then communicate with that code to coordinate its magic.  It can’t do this when running as an admin.

The recent 0.8.x release of Start++ solved this issue, and Start++ now runs immediately after install, in the proper non-admin context.  This is accomplished by having Explorer launch the application on the installer’s behalf. 

Others have addressed this problem in the past.  However, the proposed solutions always seem to take one of these forms:

1. Write an invoker process that runs with non-admin privileges, starts the elevated installer, and then runs your app at the end.
2. Use the task scheduler to launch the app.
3. Inject some code into Explorer and launch from there.

I don’t like #1 because it’s cumbersome and limits how you can name your installer.

#2 also seems cumbersome to me, and is a bit hacky.

#3 is totally hacky, and not something I trust people to do without accidentally destabilizing Explorer (there’s a reason the code Start++ injects into Explorer is incredibly tiny and very carefully crafted).  It can also introduce complications when dealing with multiple target platforms (x86 versus x64).  For example, the CodeProject sample linked to above doesn’t even restrict its WH_CALLWNDPROCRET hook to the thread that it’s targetting.  That means this hook code is immediately going to be loaded by every process on the desktop with a window.  Yuck.

Fortunately, there is a better way.

In Part 2, I describe a better way to get Explorer to run code for you, without having to inject anything into Explorer or use cumbersome workarounds like those described above.

Consider the following paragraph and tell me that bias and sensationalism haven’t taken over tech “journalism.”

With last year’s arrival of Vista, Windows has swollen to 1 billion bytes (a gigabyte) or more of software code. The “Mach” kernel of the Mac OS X, however, requires less than 1 million bytes (a megabyte) of data in its smallest configuration, expanding modestly with the sophistication of the application.

So the iPhone kernel is smaller than all of Vista and its included applications.  Sound the alarm, get the president on the line, this is huge news.

What Gary forgets is that the CPU of my Dell workstation is hundreds if not thousands of times smaller than an entire Mac Pro.  I think, advantage Dell.

Of course I’m joking, these comparisons are absurd.  Yet in the very next sentence Gary piles on the bull crap.

This bloating has saddled Vista users with increased costs and poor performance on average computers.

If you look at Apple’s own website, they state that Leopard requires 9GB of available disk space to install.  Not surprisingly, this is almost exactly the same amount of space required for Windows Vista.  But how can that be?  Windows is bloated!  OS X is not!  We know these things, and working backward from this knowledge we can’t possibly come to the conclusion that they’re both just about the same size.  So why bother with the facts at all when you can work backward from what you want to be true?

The facts, in fact, are even worse for Gary’s argument than you might think.  You see, while Leopard and Vista require about the same amount of disk space to install to, one of them does have a far larger kernel image than the other.

The more portly of which is by far OS X.  I just rebooted my Macbook into Leopard to see just how large the kernel was.  The Mach kernel alone, which is only part of the OS X kernel, is 10MB in size.

So how big is the 64-bit Vista kernel on my desktop machine?  4.5MB

But this is hardly a fair comparison.  After all, that’s the size of a 64-bit Windows kernel.  We can’t reasonably compare it to a 32-bit Mac OS kernel (there is no 64-bit Mac OS kernel at the time of this writing).  So what about the 32-bit Vista one?  That weighs in at a massive 3.4MB.

Alright, the sensationalist “journalists” have won me over.  Come on NT guys, 3.4MB?  In 2008?  What’s with all the bloat?

Click here for details.

Note that the screenshot depicts the gadget running on WS4.  The "index now" button is not available on versions prior to Windows Search 4.

Neat. 

Is anybody really surprised?  Enterprise IT isn’t exactly a new thing, and this isn’t the first time Windows has shipped.  These guys refresh their PCs in cycles.  Lots of all-Windows 2000 shops who never started rolling over to XP are now beginning their early rounds of rolling out Vista boxes.  They’re in more of a hurry, since Windows 2000 is pretty ancient.  So much so that it originates from a time when we appended “2000″ after product names and thought it sounded cool and futuristic.

The Windows XP guys sticking with it through 2007 doesn’t shock me.  Most of the XP-based enterprises I’m familiar with are in the pilot stages for moving to Vista.  Lots of them have been working closely with Microsoft to make sure that updates like SP1 and Windows Search 4.0 address their deployment issues.  This is just how it goes.

Some number will even decide to “skip” Vista.  I’m sure it’s not a prospect Microsoft likes to acknowledge, but just look at how many companies held onto Windows 2000.  Throughout the entire (long) lifetime of XP!

Joe says that Windows adoption on the whole declined 3.7 percent over the course of the year (98.6% in January to 94.9% in December).  I have no idea what that means.  Is there some comparison to the year before that might put those numbers in context?  Or are we saying that all months of the year are equal?  Did anyone consider that the impending release of Vista SP1 might have led some Windows-based companies to hold off purchasing for a few months?

I don’t mean to belittle the apparent gains made by the Apple and Linux camps in the last three months of 2007.  I just think it’s silly to make a big deal about three months of “decline” for Windows in light of those other factors.  Joe says that “Vista is in real trouble.”

And yet it looks like last year more companies bought Vista machines than Macs and Linux PCs combined.  I’d say that’s pretty darn good for an OS that was released at the beginning of the year.

Well, that’s my take anyway.

This features isn’t entirely new.  Windows Vista shipped nearly a year and a half ago with the ability to query the index of another Vista machine when searching file shares.  The same capability extends to and from Windows Server 2008.

Windows Search 4.0 brings this capability to Windows XP machines, as well as Server 2003 – and perhaps more importantly, Windows Home Server.

So how does it work?  First let’s take a look at how the user sees it.  Let’s say I have a folder on Machine A called “Cool Stuff” that I want to share out.  One simple way to do that is to browse to the folder in Explorer, select it, and click “Share.”

You’ll then get a friendly dialog that asks you who you’d like to share with.

“Everyone” is a simple answer for information you want to be accessible to everyone.  Select it from the drop-down and click “Add” to add Everyone to the list of people the folder is shared with.

What else do I have to do on Machine A?  Nothing!  Windows Search 4.0 will automatically index any folders you share out, on both XP and Vista.

On Machine B, you simply navigate to the share as you normally would.  That could mean typing a UNC like \\MachineA\Cool Stuff\ or it could mean using a mapped drive, redirected User folders, the Network browser, etc.  Once there, just type a query in the Search box (or on XP, click the “Search” button to bring up the Search Pane) and you’re off!

Unfortunately I don’t have any XP machines to get a screenshot from, but I’ll try to add one soon.