MSDN supplied a 64-bit copy of Windows 7 “Ultimate”, and a key for it. When I created a virtual machine for it, VMware Fusion obligingly recognized the downloaded ISO file and installed it for me with no further instruction on my part. After the obligatory round of updates and reboots, I settled down to figure out how to use it.

In any new Windows OS, I have to figure out how to change a few things immediately. The “don’t show hidden files” option has to come off, and especially the “hide extensions on known files types” option — I’m a big boy, I can stand seeing file extensions and files that Microsoft thinks are too dangerous or scary for delicate eyes. I do not want it to automatically reboot if it crashes — I want to see that it has crashed, and any diagnostics that it produces, before I (manually!) reboot it. And turn off those damned animations, I don’t care about them and you’re running in a virtual machine so don’t waste the CPU cycles.

Since Microsoft always moves the settings around between versions, I had to poke around awhile to find them, and I got a good look at the OS as I did so. And I have to say, I’m impressed. The user interface is a lot better than it was before — easier to use, easier to navigate around, and it mostly stays out of your way until you need it. The system is pretty responsive, something that you couldn’t always say about earlier incarnations. It’s using roughly half of the one gigabyte of memory that VMware Fusion allocated to it, leaving half a gigabyte of memory for programs to use without swapping. Even the security stuff didn’t cause me much trouble, I just had to tell it that it was okay to run programs from a network drive without panicking and warning me about them each time.

But it wasn’t until I installed Visual Studio that I really saw the biggest difference. All of my programs compiled 33% to 50% faster! I’d anticipated that the compiler would be a little faster under a 64-bit operating system, despite the fact that it’s only a 32-bit program itself, but that’s a lot more than I’d expected!

All told, it was one of the most painless Windows installs I’ve ever done, and it didn’t take me too long to decide that this was going to be my new development VM. I did run into one minor but baffling glitch, which I still haven’t determined the cause of (could be Windows 7, could be Visual Studio 2005, might even be something else entirely), but I found a work-around for it, so everything is working fine now.

I’m still not going to use Windows for anything Internet-related, only for games and software development. Linux is a lot safer on the ‘net at present. But for the foreseeable future, when I use Windows, I’ll definitely be using Windows 7.

To fully understand this, you have to know where I was coming from. I learned to program in the early-to-mid eighties, and never even heard of a VCS until about 1998, when I picked up a copy of Visual C++ 6.0. I couldn’t see much use for it — I was archiving a zip-file copy of the source code for my software at every version release, and it seemed to me that VCS did the exact same thing.

At that point, I viewed the “working copy” of the source code as sacred. I’d quickly learned that whenever I made a change to it, I had to be able to reverse it if it didn’t work out, so for small changes, old code was just commented out and left there — that, and the zipped-up backups, were my VCS. It made for some messy code, because I rarely went back to remove the old commented-out stuff, but it worked.

When I sold my earlier software company in 2003 and went to work for the new company for a while, I was shocked at just how casually developers at the new company treated source code. They made changes to it willy-nilly, without leaving the old code intact! What if they screwed something up? The five-minute introduction to CVS that I got explained how to check in and check out source code, but nothing about the big picture of how or why to use it. To me, it was still just a glorified backup program.

Fast forward to a few weeks ago, when I started making some extreme source code changes to a large twelve-year-old project. That’s when I started really learning how to use version control.

The first lesson: the working copy is temporary. The sacred version of the source code is the one in the version-controlled repository, and if you’re using it properly, you can always fall back on it if your changes have introduced problems. You can also use it on multiple machines if necessary, with no problems, the source of a future compile-speed-related blog entry.

There’s a corollary to this: check in early, check in often. Make small and focused changes, get them working, and check them in as soon as they’re done. That way, if a change introduces a bug, you can easily locate the exact source-code alterations that caused it. And if all else fails, you can easily throw it away and revert to the last checked-in copy without losing valuable work. If I’d known this a few weeks ago, and practiced it, I could have saved several days of debugging huge check-ins when they later turned out to have problems.

And finally, if you have to make large, sweeping changes that must all be completed before you can see whether they’ll work, make a separate branch until it’s finished. Then you can keep checking in the smaller changes as they’re completed, even though they haven’t been tested, and all the check-ins on the main branch are known to always contain good working copies of the program. With a modern version-control system like Git, you can easily merge the branch into the main code once it’s done.

Now that I see the big picture, VCSs make a lot of sense. I’ll be using mine a lot more in the future, and quite differently.

My only stated goal in starting Geek Drivel was to give interested friends and family, and anyone who stumbled onto it, the questionable benefit of my experience. My unstated goal was to give myself an outlet for expression. I think I’ve achieved both, and I know I’ve reached a few other people during that time… or at least, I hope that a few of those page-hits I’ve been getting all these years weren’t just automated spambots.

I considered shutting it down, as a successfully completed project, but I think there’s still more that I can contribute on occasion. And of course, I like to store interesting data on it for my own future reference. So I’ll keep it going, for now. Maybe I’ll revisit that decision after the next thousand posts.

Doom, despair, and agony on me!
Deep dark depression, excessive misery!
If it weren’t for bad luck, I’d have no luck at all.
Doom, despair, and agony on me!
— Recurring skit from the TV show Hee Haw

This sounds like a great idea. But I have to wonder about it.

I know a woman, a friend of ours, with totally abysmal luck. She suffers minor — and very odd — disasters on a regular basis. And it’s not from anything she does — they’re just random events that could happen to anyone, but that happen to her with far more regularity than mere chance would allow for. On a related note, she loves to complain about her life, and these little visits from the misery fairy seem to give her plenty of fodder. It’s an open question whether the complaints come from the bad luck, or the bad luck comes from the complaints.

On the other hand, I know one person who could fall into a sewer truck and discover a gold nugget, and I can’t attribute that to any particular perspective on his part.

I also know people who technology hates — they get near a watch and it starts gaining time, and woe betide them if they try to use a computer. And others (like myself) who technology adores, and whose mere presence often fixes wonky machines.

It’s enough to make you seriously consider that there might be an element of truth to The Matrix, that the entire universe is nothing but a simulation that we’re all in. Which gives rise to some interesting philosophy, and might explain quite a bit, when you think about it.

Several of the sub-projects had monolithic header files that each source code file was including; I broke these up and set each source code file to only include the ones that it was actually using. That helped some, because fewer source code files had to be compiled most of the time, but it wasn’t enough.

Several of the sub-projects shared many source code files, and the same settings. The shared files were being compiled separately for each subproject, which was inefficient. I gathered all the common source code files into several static libraries, which eliminated the redundant compiles. Again, it helped, but not enough.

Finally, we get to the subject of precompiled headers.

I never had much use for precompiled headers. They never seemed to do much to reduce my compile times… in fact, they seemed to increase my compile times, which is why I had them turned off in all of these projects. But I found a page that explained the proper use of them (hint: MSVC’s default setup doesn’t use them right).

In a nutshell:

• Create a single header file (I’ll call it precompiled.h here) which #includes only those header files that never (or almost never) change — windows.h, stdio.h, the STL library, the Boost library, etcetera. Add it to your project.
• Create a source code file (I’ll call it precompiled.cpp, to go along with precompiled.h) that contains nothing but one line, #include "precompiled.h". Add it to your project too.
• Add #include "precompiled.h" as the very first non-comment line in all source code files in the project. This is vital, because MSVC will ignore anything before it.
• Set the entire project to use (not create!) precompiled headers, and set the PrecompiledHdrs.cpp file to create them.

The result: the compiles (after the precompiled.cpp file, when it needs compiling, which is seldom) are now ludicrously fast — at least ten times as fast as they were without precompiled headers! I assume most of that speed increase comes from the fact that I use a lot of stuff from the Boost library, but precompiled headers should help a lot even if you’re only using the raw Windows API functions (windows.h is huge, and pulls in a bunch of other header files too).

So compiles are now blazingly fast. Not as fast as I’d get on a good desktop machine (or even this one running on bare metal instead of virtualized), but much, much more tolerable.

My productivity on that project has soared. With those three changes combined, a compile usually takes less than a minute now, so I can try over fifty times more compiles in a day. I find myself a lot more willing to experiment with the project too, now that I know I’m not going to have to wait so long for the results. All in all, it was well worth the effort.

A Muslim, a Christian, and a crazy guy walk into a room. The one thing you can know for sure is that at least two out of three of them organize their lives around things that aren’t real. And that’s the best case scenario. Atheists would say all three have some explaining to do. And atheists are the minority, which is the very definition of abnormal.

Hm… is computer software “real”?