Brandon Live!

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?

I’m pleased to announce that the second tool to join the BrandonTools.com collection is now available!  It’s a new Sidebar Gadget for those who want to see what the indexer is up to and to easily control its behavior.

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.

In this morning’s article, Windows: A Monopoly Shakes, Joe Wilcox paints a grim picture for Windows.  Apparently, about 90% of surveyed enterprises adopted Windows XP in 2007, and about 6.3% adopted Vista, mainly taking away from Windows 2000 adoptions.  I don’t know about yours, but my boots are shaking.

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.

Following up on the Windows Search 4.0 Preview release, I will be writing several posts about some of the new features and changes enabled by this release.  One such feature, and this first one I will dive into here, is the capability to remotely search the index of another Windows PC.

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.

Today we made available the WS 4.0 preview release for Windows XP, Vista, and Server 2003/2008.  You can read details about WS 4.0 at the following sites:

Vista Team Blog - Announcing the Windows Search 4.0 Preview

KB Article describing Windows Search 4.0 (with download links)

This release is mainly an update to the Windows Search indexer, and provides countless performance improvements, bug fixes, and reliability / recoverability features.

The XP/2003 version has been updated with more features previously exclusive to Vista - such as the ability to search remote indexes for network shares, and the ability to host Vista-style preview handlers in the preview pane.

WS4 also provides some cool new query capabilities for developers, which I will describe and give some examples of in future posts.

The most noticeable difference is probably how fast it is.  Those geniuses down the hallway in indexer land really pulled off some impressive feats with this release.

Since there are six different downloads depending on your OS, I’ll just refer you to the KB article for downloading the preview release.

Let us know what you think!

Let’s say you want to optimize your system by only indexing certain data.  For example, a reader recently e-mailed me and said “I only want to index my media files.”  Seems like a valid choice.  At first glance, it might seem like you could achieve this by telling Windows to only index files with extensions like .mp3 and .avi.  Ultimately, this is a very bad idea.

First, let me tell you why this is a bad idea.  Second, I’ll tell you the right way to achieve what you want.

Let’s begin by looking at how the Windows Vista shell and the indexer work together.

The indexer maintains a list of “start paths” - which are locations in the shell namespace that it cares about.  By default, it is set up to index the x:\Users directory - and thus all of the default Documents / Music / Pictures folders of all user accounts on the system.  When you install Outlook, it sets up a start path for your mail accounts.  OneNote sets one up for your OneNote data.  And so on.  This means that the indexer will try to index all items under that path*, and ignore everything else.

When you browse to a folder in Explorer, the shell asks the indexer if the current path is covered by the index.  If it is, Explorer will use the index exclusively for search / filter / grouping operations against that location.  It does not ask the index if it covers all the file types in that location.  It assumes the index is the authoritative source for information about that part of the namespace.

On the other hand, if the path is not covered by the index, Explorer walks the entire namespace starting at that location (so, the current folder and all subfolders) and enumerates every single item, performing all operations like filtering / sorting / grouping in-memory.  By default, it does not crack open any files being enumerated - so all filtering operations happen only against the basic properties like file name.  You can then click the “Search in File Contents” button (what some of us call the “try harder” button), and it will repeat the operation - stopping at every file and cracking it open with the appropriate IFilter and property handlers, doing essentially the same thing that happens when a file is indexed.  It loads the file, cracks it open, extracts all the properties and content, checks to see if it matches the current filter, and then decides whether or not to add that item to the view or ignore it.  If you change the filter, the whole process starts over again.  Needless to say, this is rather slow if you have to do it for more than a few files.  That’s why the “Search in File Contents” button is there, since in most unindexed locations (like C:\windows) you are probably only searching for a filename.

Armed with this information, let’s take another look at the original question.  Let’s say you go into the Advanced options for the indexer and tell it not to index .doc files at all.  Then you go save a new document called Something.doc inside of your Documents folder, which is still indexed.  The indexer will be notified that a new file was created there, but since you disabled indexing of that extension, it will ignore it.  Then when you go to your user folder or the Documents folder and search for “something” - you don’t find the document.  Even though it’s right there in the name.  The folder said “Hey, I’m indexed” and the file is not in the index, so as far as Explorer is concerned, it doesn’t exist.

A much better approach, if you really don’t care about indexing your .doc files, is to tell Windows not to index the Documents folder (or wherever you keep your .doc files).  That way it will fall back to slow GREP search when you look there, which will at least find what you’re looking for, albeit more slowly.

You can do this from the Indexing Options control panel, and it’s pretty easy to do.  Only want your music and videos indexed?  Then tell the indexer to only crawl the places where you store those files.  That it’s, mission accomplished.

The end result is the same.  The indexer isn’t doing any additional work, unless you mix .doc files and media files in the same folder.  And even then, at least you’ll be able to find them.

Another option available to you is to set certain extensions to “Index File Properties only.”  That way you’ll at least be able to find the item by its name.  Why would you want to do that?  I have no idea.  It’s not like indexing files incurs a significant overhead on any reasonably modern PC.  The option is mainly there because there are some file types the indexer can’t search inside.  So instead it indexes all the basic stuff that applies to every file (like name, date modified, and size).

* = It’s actually more complicated than that, as there can be nested inclusion/exclusion rules, files or folders excluded based on attributes, etc.  But that’s not particularly relevant to this discussion

Because I, and millions of others, will not be able to use them.  That’s because we use 64-bit versions of Windows.

You see, the Windows Sidebar uses Internet Explorer to host the HTML and script that make up a gadget.  On 64-bit versions of Windows, the Sidebar is a 64-bit process, and so it uses the 64-bit version of IE.

There is no Flash or Silverlight for the 64-bit version of IE.

About a week ago I encountered a gadget offering from MSNBC having to do with the presidential primary results.  I added it, only to find that the gadget’s UI was totally missing.  It didn’t take long to figure out they were hosting Flash.

I’m actually quite disappointed at the lack of 64-bit Silverlight support, as I believe it would be a compelling solution for gadget authors.  .NET already works great in gadget situations because it gets compiled at runtime for the appropriate platform - and thus works on both 32-bit and 64-bit versions of Vista.  I had hoped that since Silverlight is based on .NET that it would include similar write-once deploy-anywhere support, including 64-bit platforms.

I hope that is something they fix in the near future.

Update: Yes, you can install both Flash and Silverlight (1.0 and 2.0) on Vista x64 systems.  I assume that everybody knows that, but perhaps they do not.  The caveat, and point of this post, is that you are installing the 32-bit version of Flash / Silverlight, and thus it only works in 32-bit applications.  The default browser on 64-bit Windows is the 32-bit version of IE, so these plug-ins work fine for web browsing.  But they don’t work in the sidebar, or any 64-bit applications that host IE.

I’m a huge fan of the great work the IE team is doing for this release.  The first beta, targetted mainly at web developers, is now available.  In addition to excellent standards support, it includes some cool new user-facing features like “Web Slices,” Activities (XML driven extensions for doing things like mapping an address), automatic crash recovery, and more.

My favorite feature out of those?  The fact that IE now separates the tabs and the frame into separate processes.  This is part of Automatic Crash Recovery (link contains detailed explanation).  Here are some of the effects of this change that I have enjoyed:

1. When a web page / add-in (like Flash) crashes, you hardly even notice.  The tab(s) restart automatically and the only thing you notice is the little balloon telling you that IE just recovered a crashed web page.
2. Crash recovery saves form data whenever possible.
3. No longer do you need to launch links to trusted/intranet zones into a new window.  In IE7, this was necessary because the process has to start with a higher integrity level (Protected Mode: Off).  Now, because the frame is one process and the tabs are separate, you can have one tab with Protected Mode turned on, and one with it turned off, in the same window.
4. No more ieuser.exe needed, since the frame runs at normal IL and serves the purpose that ieuser.exe used to serve.

Click here for more information about IE 8 beta 1.

Freakin’ amazing.

I just got linked to this article via Neowin, about a guy who had an Xbox 360 for two years that had been signed by various Xbox, Bungie, and Rooster Teeth staff (and also had some cool custom artwork drawn on it).

He tried to arrange with the repair facility to have either the same console returned (after being repaired) or to have the case transferred to the replacement.  Of course he feared the worst, that he wouldn’t get the same console back.

Except that what happened did seem worse, as he got the same console back, but believes someone had wiped off all the signatures (with some smudges left that support this theory).

My first thought was not the same as most people’s, apparently.  If you look at the comments, they seem to all present theories like “Some jackass obviously stole his console and faked the smudges so he’d think it was gone forever.”

Come on people.  Why so cynical?  Remember the old adage, “Don’t attribute to malice that which can be adequately explained by stupidity.”  Or more appropriate, ignorance.

My theory?

Someone did their best to fulfill his wishes, and made sure he was set up to receive the same console back.  Things were looking good, until someone further down the line saw the console and assumed it was a refurb / repaired unit being sent to some random joe who sent in a different console.  They then decided in ignorance to “clean” the console according to their standard policy, removing any foreign markings that might not be welcomed by its new owner.

It’s just a theory, of course, but a plausible one I think.  One that doesn’t assume people are evil or that this was an act of malice, but simply an unfortunate mistake made out of ignorance.

I feel really bad for the guy, I know I’d be pissed in his place.  But at least it seems that Microsoft has contacted him personally.  I don’t know if they’ll be able to completely “fix” things, but I hope they’ll be able to do something for him - as whatever the explanation, the outcome really sucked.