Raymond Chen recently wrote about the WOW64 system that Windows uses to virtualize file system and registry access for 32-bit applications running on a 64-bit version of the OS. In the comments, some began discussing the fact that Windows puts 64-bit binaries in the “System32″ directory, and puts the 32-bit versions in a directory called “SysWow64″ to which 32-bit applications get redirected. It does seem odd, I’ll grant you that.
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.
About a week ago we posted an entry to the Windows 7 Engineering Team Blog about Windows Desktop Search, describing the motivation behind indexing files and what investments we’re making in that area of the system. It’s a good read so check it out if you haven’t already.
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.
I updated my Windows Search indexer gadget with a couple of fixes. If you run the gadget, you may want to update in order to fix issues with the play and fast-forward (“index now”) buttons not properly reflecting the state of the indexer back-off feature after clicking one of them.
Also, if you like the gadget, please go to the Gadget Gallery page and give it a good rating 
These may have been kind of cute or clever in the past, misleading as they were. But now they’re just plain obnoxious.
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.
A couple months ago I posted about an article by some guy at Business Week, that made all sorts of rubbish claims about Windows and OS X.
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.
When I first posted about the WS4 release on Neowin a few members had a response that I had never expected. Some examples:
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:
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.
Windows Search 4.0 was released this afternoon. This release focuses on performance and reliability improvements. Here are some highlights:
This release also adds the following Vista / Server 2008 features to Windows XP / Server 2003 systems:
Read the KB article here for more details and complete feature list.
Download Links
Vista users - don’t forget to grab the indexer status gadget!
The key to getting Explorer to do your dirty work lies in the IShellDispatch2 interface. Particular, the ShellExecute method.
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.
Some people seem to think that calling ShellExecute or ShellExecuteEx and passing the path to an executable will have the effect of telling the shell to launch an application for you. However, that’s not quite what happens. These functions simply allow your application to take an action (like launching a process) in the manner the shell typically would (for instance, recreating the behavior of using the Run box).
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:
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.
Gary Morgenthaler of Business Week is the latest in a series of tech journalists to really disappoint me. Why? Just look at his latest rubbish posted on Business Week’s website today.
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?
[powered by WordPress.]
Hi. I'm Brandon. I work on the Explorer for Windows 7 at Microsoft. This is my blog.
| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| « Jun | ||||||
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | 31 | ||
The views expressed within my blog are my own - and are not in any way indicative of those of the company I work for, Microsoft, or it's employees. No warranties or other guarantees will be offered as to the quality of the opinions or anything else offered here.
