I've spent some time this evening profiling a Python ap­pli­ca­tion on Windows, trying to find out why it was so much slower than on Mac or Linux. The ap­pli­ca­tion is an in-house build tool which reads a number of config files, then writes some output files.

Using the Run­SnakeRun Python profile viewer on Windows, two things im­me­di­ate­ly leapt out at me: we were running os.stat a lot and file.close was really expensive.

A quick test convinced me that we were stat-ing the same files over and over. It was a com­bi­na­tion of explicit checks and implicit code, like os.walk calling os.path.isdir. I wrote a little cache that memoizes the results, which brought …continue.

I've been running the 64-bit version of Windows 7 RC since June. It's been quite painless on the whole.

One wrinkle that I ran into was with some batchfiles which launch ap­pli­ca­tions in %Pro­gram­Files% (normally C:\Program Files). Due to the magic WOW64 redirector, 32-bit ap­pli­ca­tions are actually installed into %Pro­gram­Files(x86)%—normally C:\Program Files (x86)—instead of %Pro­gram­Files%. This is trans­par­ent to the 32-bit ap­pli­ca­tions, which think they're running in %Pro­gram­Files% (C:\Program Files).

However, the cmd.exe shell is 64-bit (unless you make a special effort to run the 32-bit cmd.exe in SysWOW64), so batchfiles see the 64-bit %Pro­gram­Files% which contains 64-bit ap­pli­ca­tions.

Hence, a batchfile that launches an installed 32-bit ap­pli­ca­tion on Win64 must use %Pro­gram­Files(x86)%, not %Pro­gram­Files%.

It sounds …continue.

I mentioned three weeks ago that I had just repaved my work dev box and installed the 64-bit version of the Windows 7 RC. Nine or ten years after I first ported parts of IIS to Win64, I am finally running my main desktop on 64-bit Windows. With one exception, it's been painless. Programs have just worked, devices have just worked. There are relatively few native x64 ap­pli­ca­tions, but for the most part it doesn't matter. The cases where it does matter—e.g., shell extensions such as Tor­tois­eSVN—are available as 64-bit binaries.

I briefly flirted with using the 64-bit build of Python, but realized that I would have to recompile several eggs as …continue.

I complained a week ago about my display driver going berserk. I blamed Windows Update, since it happened within hours of a pile of updates being installed. I upgraded to the latest beta NVidia drivers on Monday and it helped for a while, but by Wednesday, it was almost as bad again as it had been last Friday. It was in­fu­ri­at­ing and I was both en­ter­tain­ing and alarming my neighbors with my cursing.

Today was the last day of a very busy sprint for me and at last I had the time to dig into it. I opened up the case and took a look at both video cards—I …continue.

This morning, the video adapters on my Vista dev box were resetting 2–3 times per minute.

After a pile of Windows Updates landed on my machine at 3am yesterday, it would oc­ca­sion­al­ly freeze solid for a few seconds. Once in a while, all the monitors would go black briefly, then restore. Each time, I would see a status update pop up from the system tray, "Display driver nvlddmkm stopped responding and has suc­cess­ful­ly recovered."

This was irritating enough that I downloaded the latest NVidia drivers this morning, 185.85_desk­top_win­vis­ta_32bit_eng­lish_whql.exe. That really screwed me. The video adapters started resetting 2–3 times per minute, rendering the machine almost unusable. I have two video adapters, NVidia GeForce …continue.

I updated the Win64 binaries of Vim at vim-win3264 from Vim 7.2.000 to 7.2.182.

I'm amazed that the original binaries were downloaded over 11,000 times since last August.

I ported Vim to Win64 but I don't have a convenient Win64 system to test it on.

I decided to install the Win64 build of the Windows 7 RC on VirtualBox, which has supported 64-bit guest operating systems since version 2.0.

It worked without problems on my MacBook Pro. I used Vir­tu­al­Box's Virtual Media Manager to mount the Windows 7 ISO and installed from that. See also the handy guide. (Why does Windows 7 offer a choice of upgrading from a previous version of Windows on a virgin disk?) After completing the in­stal­la­tion of the operating system, I installed the Guest Additions for mouse pointer in­te­gra­tion and other goodies.

As always with VirtualBox …continue.

After I started running Linux and then Mac OS X, in addition to Windows, I started on a quest to find the universal filesystem. I had multiboot systems and external drives where I wanted to to be able to read and write disks under multiple operating systems.

The obvious choice is FAT32, the ubiquitous, lowest-common de­nom­i­na­tor filesystem. FAT32 is supported out-of-the-box by all major operating systems, digital cameras, and PDAs, so that's a huge advantage. FAT32 also has major short­com­ings:

• Maximum file size is 4GB. I have ISOs, MPEGs, and other large files exceeding this limit.
• Frag­men­ta­tion happens too easily.
• Timestamps: accurate only to 2-second resolution. No notion of timezones or UTC.
• Journaling: …continue.

I mentioned in my post on re­Struc­tured­Text that I use a little command-line tool, pbcopy, to pipe the output into the clipboard. I finally found a similar tool for Linux, xsel.

• Mac: pbcopy (UTF-8 aware, unlike the built-in version of pbcopy) copies its input to the pasteboard (Mac name for the clipboard); pbpaste writes the pasteboard to stdout.
• Linux: xsel gets and sets the X selection.
• Windows: winclip reads and writes the clipboard in a variety of formats. Use -m for UTF-8 text. The winclip binary is available as part of the outwit package.

At work, I've been ex­per­i­ment­ing with the big three Dis­trib­uted Version Control Systems, Git, Mercurial, and Bazaar, on Windows over the last ten days.

Pavel and Eric have been singing the praises of Git and git-svn on their Mac and Linux boxes re­spec­tive­ly for the last few months. Git allows them to check in small changes locally without perturbing the build. The ease of branching and merging allows them to work in more than one branch at a time at a lower cost than Subversion did. Most of our dev team continue to work in Subversion on Windows boxes. git-svn allows Pavel and Eric to easily in­ter­op­er­ate with the Subversion server. Pavel …continue.