Can’t Select Multiple Files in Windows Vista

Today I was trying to copy files in Windows Explorer and ran into a rather nasty little bug. Explorer wouldn’t let me select multiple files. I couldn’t Shift+Click to select a range or Ctrl+Click to select individual files. Keyboard shortcuts didn’t work, and the Edit | Select All menu option was disabled.

This appears to be a bug in Windows Explorer, although I’ve seen conflicting information. Microsoft’s knowledge base article about the problem says, “This problem occurs because certain applications add a key to the registry. The key prevents you from selecting multiple items in Windows Explorer.” Their recommended solution is to reset the view. That didn’t work for me.

The solution I found requires editing the registry. You have to start RegEdit and navigate to HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell, and delete the BagMRU and Bags registry keys. Before you do that, you should close all Windows Explorer windows. If you’re uncomfortable fiddling with the registry, it’s probably a good idea to set a system restore point before you start.

I don’t have the time (or the inclination, truth to be told) to dig in and figure out what Bags and BagMRU do. It seems odd, though, that “certain applications” would be able to cause this behavior, unless they were malicious–deliberately trying to cause grief. Is this a bug in the Vista version of Windows Explorer?

SciFi Classics

SciFi Classics
One of my friends presented me with a completely unexpected Christmas gift: a 12-DVD set called SciFi Classics. If you believe the hype on the box, this is “An instant library of some of the greatest science fiction features.” We’re talking quality films such as Mesa of Lost Women, Santa Claus Conquers the Martians, Teenagers From Outer Space, Voyage to the Planet of Prehistoric Women, and that enduring classic, The Wild Women of Wongo.

I don’t know who decided that these B-grade movies were “classics,” but I won’t quibble about a little artistic license in the name of marketing. I will say, however, that I only vaguely recognize a few of the titles. Most I can’t recall ever hearing of, although I probably watched at least half of them on late night TV when I was in school. Reading the brief synopses of the movies tickled a few brain cells, but I couldn’t say for sure that I’d actually seen any of them.

I can hardly wait to start viewing them, though. The synopses are so enticing. Consider, for example, that enduring favorite, She Gods of Shark Reef:

Filmed in Hawaii, this tale features an escaped prisoner and his brother who become shipwrecked on an island paradise. The land is filled with delectable native women who fill their time enacting strange rituals, and diving into the ocean for pearls. When one of the women is selected by her peers to be sacrificed to the sharks, the good brother who has fallen for her charms, rescues her and they escape to civilization. The convict brother stays behind and attempts to steal the pearls, instead becoming the designated sacrifice.

The movie has everything: a good guy, a bad guy, a tropical paradise full of “delectable native women,” undoubtedly a lot of T&A shots what with the pearl diving and all, love, loss, strange rituals, and a happy (at least somewhat) ending.

How about They Came From Beyond Space:

Based on the science fiction novel “The Gods Hate Kansas” [and we all know how great that book was], the story focuses on a group of unlucky aliens who have crashed their spaceship on the moon. They attempt to use mind control to coerce a team of scientists from Earth to make the necessary repairs. However, one of the scientists has a steel plate in his head and is immune to their efforts.

Ah, the old steel plate in the head. That’ll foil ’em every time.

This collection has everything you’ve come to expect from B-grade science fiction movies: convoluted plots, mad scientists, spaceships, evil aliens, planet-killing meteors, lost planets filled with beautiful women, monsters with a taste for virgin sacrifices, and teenagers who see the danger and save the day despite the interference of unbelieving adults. All in all it looks like three days or more of continuous science fiction fun.

Anybody wanna join me as I lie on the couch in front of the TV and let the brains leak out my ears? I’ll supply the popcorn.

Source control and formatting standards

Things get so much more complicated when your development team grows larger than one person. Not only coordinating the efforts of two or more people, but also agreeing on data structures and naming conventions, designing interfaces so that you insulate developers as much as possible from others’ work, and a whole host of other problems. A source code control system relieves a large part of the worry, although you should be using source code control as soon as your development team grows larger than zero people. I won’t belabor that point here, as it’s the subject for a rather long post in itself.

One of the many things programmers like to argue about is code formatting. This topic is right up there with the discussion of the best language and best text editor. And as is the case with those topics in which each programmer has his own opinion that is unquestionably right, each programmer has his own code formatting style that is The One True Way. Anybody who does things differently is, at best, suspect.

But most development shops impose code formatting standards along with naming conventions. Why? In order to reduce confusion when somebody other than the code’s original author works on it. Without a code formatting standard, confusion arises in several ways.

The format of the code tells you things about it. For example, indentation implies a compound statement. In many languages (the C-derived languages), an opening brace begins a compound statement, which is normally indented. As creatures of habit, when we see indentation we expect to see an opening brace. And vice-versa. If the brace is not where we expect it, or the indentation is different than we’re accustomed to, then our brains have to adjust. This adjustment takes longer than you might expect. For example, consider these three blocks of code, each of which does the same thing, but are formatted slightly differently:

if (someValue == 0) {

if (someValue == 0)

if (someValue == 0)

Each of those styles has its adherents and detractors, and objectively each is as valid as the other. But two of them make my brain hurt.

Most programmers these days use editors that perform some level of automatic formatting when you enter new code. If my editor is configured to create things in the One True Way, the result of editing a file that was created with one of the heretical formatting techniques is a complete mess.

Absent imposed coding standards, there are four possible solutions to the problem, none of which is satisfactory:

  1. Just ignore the problem. Believe me when I say that you don’t want to do this. Few things are as confusing as working on a single file that has inconsistent formatting.
  2. Disable the automatic formatting features of the editor. This is possible, but makes you much less productive. The automatic formatting features save a lot of time, especially when you’re refactoring code, as it prevents you from having to manually indent or unindent code to make sure that the braces match up.
  3. Reconfigure your editor to match the coding style of whichever file you’re currently working on. This is problematic because programmers often (probably most often) are working on multiple files at the same time. No editor that I know of will allow you to specify the configuration on a per-file basis. (On a file type basis, yes. But not per file.)
  4. Instruct the editor to reformat code to your style whenever you open a file. Although this sounds like a good idea to begin with, it’s disastrous when source control is involved which, as I pointed out above, should be for every project. Source control typically saves the deltas–changes between two versions of a file–rather than saving the entire file every time it’s modified. This is a huge space savings, and also allows you to view the history to see the specific changes between two versions. If you reformat the entire file, then the source control system will assume that (almost) every line changed. The result is that your source control database will be orders of magnitude larger than it has to be, and the significant changes between versions will be lost in the reformatting noise.

There is one other option that is not currently available, but should be. If the source control system (or a filter in front of the source control system) could normalize a file–convert it to a standard form–then the fourth option above would be possible. You could get a file from source control in whatever the normalized form is, open it in your editor and reformat to your heart’s content. When you saved the file and checked it in, the source control system would reformat it to the common form and store only the deltas. This allows each programmer to view and edit code in whatever format he is most comfortable with, but also allows the source control system to be efficient and effective.

I realize that I’m waving my hand over some implementation detail, particularly the many filters that would be required to format different kinds of files. But nothing here sounds terribly difficult with today’s tools. Has this been done? If not, why?

Update, 2012/04/18

I gave this idea quite a bit of thought after writing the blog entry, and finally decided that it’s not a good idea. There are some interesting issues involved in creating the tools that would be needed, but I don’t think those are insurmountable. The bigger problem is one of debugging. Imagine this scenario.

  1. You get a bug report from a tester. Part of that bug report says that the program crashed on line 263.
  2. You get the source code that the test version was built from.
  3. Your development environment re-formats the code to your desired style.
  4. Line 263 in your source file is not the same as line 263 in the source repository.

Sure, you could use an external tool to view the code in its canonical format, thereby ensuring that line 263 is where it’s supposed to be. But why? And what are you going to do when there are many different files and line numbers involved?

I came to the conclusion that all of the code in a project should use one and only one¬†indentation style. If the developers can’t agree on that, then it should be imposed from above. The truth is that it takes about two days to become accustomed to a new indentation standard. Save your creativity for things that really matter.


This morning I was sitting in my office, listening to music and banging away on the keyboard like a good little programmer, when I heard a very loud BANG. The first time I heard that–a couple of weeks ago–I was running the dishwasher and thought something in there had made the noise. It wasn’t until one of the other guys came in a few hours later that I found it was a soda can that had exploded in the refrigerator.

So I knew what the sound was when I heard it this morning. What surprised me was how the can exploded. This is the first time I’ve seen the top blown off of a can. Every other exploded soda can I’ve seen had a split on the side somewhere. This one is intact except for the cleanly-removed top. Oh, and the bottom is bulging.

When the last can exploded, we adjusted the refrigerator’s temperature in an attempt to prevent this from happening again. Apparently that’s not good enough. It appears that the freezer vents into the refrigerator, and there’s a spot just below that vent (back, center, top shelf) that gets the benefit of that cold air. So much benefit, in fact, that it’ll freeze a can of Coke Zero.

New rule: no drinks on the top shelf.

Note: No, I’m not the Coke Zero drinker. I prefer the real thing.

Can I really ignore that warning?

When you build 64-bit .NET applications with Visual Studio, the Assembly Linker issues warning messages of the form:

Assembly mscorlib.dll targets a different processor.

It will issue that warning for each of the .NET runtime assemblies that your project references. The warning occurs because the linker checks the 32-bit runtime assemblies for type information, and since you’re building a 64-bit assembly, there’s a mismatch. The documentation says that it’s safe to ignore this warning because all of the .NET assemblies are guaranteed to have the same external interface, regardless of the CPU for which they are compiled. Specifically, the documentation says:

All x86-specific common language runtime (CLR) assemblies have 64-bit counterparts (every CLR assembly will exist on all platforms). Therefore, you can safely ignore CS1607 for CLR assemblies.

And that does appear to be the case. There is no conflict when you run the application.

I contend, however, that this is a bug in the tool. Why? Because it is a spurious warning that I can’t safely eliminate. And why can’t I safely eliminate it? I’m so glad you asked.

I can eliminate the warning. All I have to do is go into the project properties and add ‘1607’ to the list of warnings I want disabled. Goodbye, warning. But doing that eliminates all occurrences of the warning in the project. If I just happen to have a conflict within my own solution (i.e. trying to link my 64-bit project with a 32-bit assembly that I created), I won’t see the warning. And I’ll get a rude shock when I deploy and try to run the resulting application.

In addition, Visual Studio 2008 will issue the same warning number (CS1607) if the AssemblyVersionInfo attribute in your AssemblyInfo.cs file is not in the recommended format. That in itself is a spurious warning in my opinion, and one that I’d love to disable. Except that if I disable it, I also disable the processor mismatch warning.

You might wonder why I even worry about it, if the warnings are ignorable. There are two reasons. First, when a solution I’m building in Visual Studio issues warnings, I have to examine each warning to make sure that I can safely ignore it. Some of my solutions have more than 20 different projects–tools and dependent assemblies. If each one issues a warning about every referenced CLR assembly targeting a different processor, I have almost 50 warnings to wade through for each build. The risk of missing a real warning in that mess of useless messages is very high.

More importantly, we’re trying to put together an automated build system. In automated builds, warnings should be treated as errors. Otherwise you have to write some kind of post-processing filter that can examine the tool output to determine whether the warnings are meaningful. Doing so introduces yet another uncertainty into the process: the correctness of the post-processing tool and any configuration file that controls it.

So I’m left with no good solution. Whether I enable or disable the the spurious warnings, there’s a very real possibility of missing an important warning. I could understand this bug existing in Visual Studio 2005, but the development team has had more than two years to work out a solution. There is no excuse for the bug remaining in Visual Studio 2008 and the latest version of the .NET tools. Rather than fixing it, they made the problem worse by overloading the warning number. That’s unforgivable.

Some useful utilities

I’ve run across a few utilities lately that I thought others might also find useful.

ISO Recorder is a very handy way to create CDs or DVDs from ISO files. No frills: just a Windows shell extension that works. Right-click on a .ISO file, select the drive you want to burn it to, and go. I would complain about Windows lacking this feature natively, but I think I’d rather have the simple right-click-go interface of ISO Recorder than whatever overly complicated interface the Windows design team would come up with.

I’ve mentioned Info-ZIP before. They have the best command line Zip and Unzip tools that I know of. I went to the site the other day, looking to install the tools on my new Vista system, and found that they now have 64-bit versions. Now if only we could get past the 4 gigabyte limitation.

Speaking of compression, I’ve been seeing a lot of bzipped stuff for some reason lately. Unfortunately, bzip and bunzip aren’t included in the Subsystem for UNIX-based Applications tools and utilities. You can download Bzip2 and other utilities for Windows from the GnuWin32 project.

We’re using Subversion for version control here. That could be the subject for a post by itself. If you’re using Subversion on a Windows client, don’t even bother with installing the command line tools. Rather, download and install TortoiseSVN. It’s a Windows shell extension that lets you work with your version control system visually rather than futzing with the command line. It’s nicely polished, and the new version works well with Windows Vista.

Most open source or free software sites will give the MD5 hash of the files that are available for download. The md5 utility is a standard component of most Linux distributions, but Windows doesn’t include such thing out of the box. MD5sums is a handy thing to have. You can operate it from the command line, or drag files from Explorer onto the .exe. Nicely done.

Vista Subsystem for UNIX-based Applications

The Enterprise and Ultimate editions of Windows Vista include a component called Subsystem for UNIX-based Applications, or SUA. This subsystem is also available in Windows Server 2003 R2, and will be available in Windows Server 2008 (Longhorn). SUA by itself is just a Windows component that provides platform services for UNIX_based applications. You get UNIX tools and an SDK from a separate download.

SUA is the new version of Windows Services for UNIX (SFU), which is available as a separate download for Windows 2000, Windows Server 2003, and Windows XP (except Home edition). Also see the SFU blog. According to Wikipedia, SFU has a long history.

To install SUA in Windows Vista, go to to Control Panel | Programs and Features, and click on the “Turn Windows features on or off” link. Be patient. It takes a minute or two for Windows to populate a list box of all the available features. Once you see the list, scroll down to “Subsystem for UNIX-based Applications,” and check that box. Press OK after you’ve selected any other features you want to turn on or off.

I don’t know why, but it takes a very long time for Windows to install or configure the Subsystem for Unix Applications. That progress bar stays at zero for at least 10 minutes, and then grows in small leaps. Even after it looks “done,” it keeps thrashing the disk. I didn’t start a timer when I began the installation, but I know took over 30 minutes.

It’s probably a good idea to restart your system after installing SUA. The install didn’t say that I should, but a Microsoft knowledge base article describes problems with programs not responding if you don’t restart after installation. You should also visit Windows Update to obtain any critical updates for SUA. People in the U.S. almost certainly need the update that deals with Daylight Savings Time.

As far as I can tell, just enabling SUA doesn’t actually give you anything useful. I guess it gives you the ability to run UNIX-based apps (that have been recompiled to work with SUA), but you have to download and install the Utilities and SDK for Subsystem for UNIX-based Applications in order to get the common UNIX utilities. Be sure to get the right file for your OS and processor. There are separate versions for Windows Vista and Server 2003 R2, also differentiated among x86, amd64, and IA64.

I have it all installed, and will be experimenting with it over the next few days. More once I’ve had time to figure things out.



A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.