Hanselman: That's cool. Tell me why Explorer seems to lock up particularly when it's enumerating drives; I open up the little plus, it goes off, and then suddenly, oop, sorry, your CD - I don't know what's wrong with your CD, your kid put a sandwich in it, and I can't show the next drive.

Chen: The sandwich in the CD - that was me actually, I would say. And part of it is that the shell is heavily based on COM, specifically apartment model COM, and one of the advantages of apartment model COM is that everything happens on a single thread in COM. Make sure that your objects - in fact, you have to observe the rule that your objects are on the thread they are created on, which makes it very easy to implement your objects. The downside of this is that it's kind of stuck to a thread. We're kind of stuck with this design because that's what we have had since Windows 95; there are thousands upon thousands of shell extensions out there that are relying on Apartment threading - and pull incredibly evil tricks that break down if we ever put them on some other thread. We're stuck putting a lot of things on the UI thread. We've been working to move things off but - and in Windows Vista - in fact in Windows XP as I recall, at least Folder Enumeration was done in the background. I can't remember whether Tree Expansion was done in the background or not, but I definitely remember that back in the old days when the address bar was just a drive's combo box, that when you click that, it took time to spin up all the drives to get the icons and the volume information because that is clearly pending upon an action; you click the button, the dropdown has to drop down, and if it drops down, it has to have stuff in it. You are kind of stuck on that one but...

Hanselman: Does it have to have stuff out? Can it say, I'm working on it? For example, I know that Mark Versonowitch did a big thing on his blog recently - when he is a domain user and he is not on the domain, Explorer hangs for 11 seconds while someone tries to figure out what his real name is, so they can go and say, see users, domain, my name, Mark Versonowitch - his name/My Documents, and when he is off the domain, he is not connected; he has no network connection. It hangs, realizes he is not on the network, 11 seconds later it goes, see users Mark R, the actual folder name.

Chen: Part of the problem with that, it goes back to the behavior changes and the function design upfront is that, somebody calls, they give me the name for this thing and you have to give him an answer. As the function was originally designed, the guy asks you, what's the name for this folder and you give him an answer, and if you decide to add a new answer called, "'I don't know" it would take too long or...

Hanselman: Try a little later...

Chen: This might take a while; you should do this on a background thread. Then all the people who don't know about this behavior will just start getting back empty strings.

Hanselman: If the assumption is that I have a limited number of milliseconds before I have to get this dropdown back to the user, and if UI responsiveness is the number one priority, forgetting for a moment about the inconvenience or just procedure calls in general, in the sense that they have to have a well-known return type. If you can't get this back to me in 300 milliseconds, then just stop, bail and I'll never talk to you again. I'll make something like the default answer.

Chen: Of course that requires you to be able to predict the future; will this call to get username take more than 300 milliseconds?

Hanselman: This is the Heisenberg Uncertainty Principle of dropdown lists?

Chen: No, it's more like life would be a lot easier if we had time machines.

Hanselman: It would.

Chen: And there are plenty of things I would change.

Hanselman: Like what?

Chen: I don't know, because on the other hand I might accidentally destroy myself, it's kind of a...

Hanselman: You would probably kill your own grandfather.

Chen: Yeah, accidentally, I would sneeze and create this horrific epidemic or something.

Hanselman: Going back - so thinking about time machines for a second, everyone thought and by everyone, within the context of this room, that would be me, thought that all the icons in Vista would be vectors - and I think I thought that either someone said it, or they said they will be scalable - and I had a flashback to Prodigy and I said, "Oh, awesome - vectors, those are great. I hear those are doing good things." I just assumed there would be some slider bar somewhere and I would just gleefully slide it back and forth with my giant icons getting bigger and smaller and bigger and smaller. In fact in Vista, the icon formats got to be quite a package.

Chen: The icon format has actually not changed too much and I think we may have changed it too much even then. The icon format has been stable since the beginning of Windows.

Hanselman: I could put a 1024 x 1024 icon in an icon format?

Chen: Up until Windows Vista, when we added PNG icons, that was the first incompatible change to the icon format. Through Windows XP, you could take those icons and whack them on a Windows 1.0 machine and be able to come up with icons.

Hanselman: The icon format, it's a bag of icons. You can have as many icons as you want in ICO.

Chen: It's an icon directory and then there is a header that describes how many images there are, what their sizes are and their color depth; and all of that has remained the same up through Windows XP, then Windows 2003. Windows Vista, we took a chance on adding a new icon format and in fact our first attempt was to follow how the original icon format was meant to be with a header and then the bits and have a different...

Hanselman: Could you put different bits in there?

Chen: We were actually going to set that because in that info header there is a Compression Type field. We put png in the Compression Type field, and it turns out that created a lot of compatibility problems.

Hanselman: Probably the third-party vendors, bit map libraries looked at that info and they said, oh...

Chen: There was a very popular icon-editing tool that when faced with icons that had Compression Type of png just exploded. It turns out that that's not something we sort of enjoy.

Hanselman: You just changed the format

Chen: We had to go back in and redo the format a little. I guess the problem was that the way we originally put ping support in, it looked too much like an old-fashioned icon; and that tricked these programs into thinking that, "Oh, I know it; I know what I'm doing." In fact the solution to compatibility was ironically to make things slightly less compatible and get these programs to sort of panic and back out before they got into too much trouble.

We actually designed the format so it didn't follow the intended expansion design of the icon format. It's somewhat sad.