Mark Process for x86 to Use Skype API or Topaz SigPlus API

If you happen to be integrating your Windows app with Skype's COM bridge, or with Topaz' SigPlus API for their biometric digitizing signature pads, those libraries won't play nice if loaded from an x64 process.

The easy fix -- assuming you don't have dependencies that mean you need x64 -- is to create a build configuration for your main app that specifies a target platform of x86 (instead of "Any CPU"). The resulting app will run in WoW (the 32-bit shim for 64-bit Windows) and works fine with these libraries.

The hard fix would appear to be using IPC to coordinate two different processes: your main app in x64, and a proxy/helper 32-bit process running in WoW that works these DLLs for you.

Those Little Shape Widgets in VS2008 Require Deployment

The Visual Studio 2008 SP1 control palette has a few "shape" widgets -- Rectangle, Oval, Line ... which come from a "Visual Basic PowerPack" library: Microsoft.VisualBasic.PowerPacks.Vs.dll

If you use these, you need to deploy the library manually with your application. That is, an up-to-date .Net 3.5+ machine will not have the library available globally, and Visual Studio will not mark this DLL to be copied into your output folder.

I haven't checked to see whether the VS Installer project will determine the dependency and include it -- I'm guessing it will. But if you are doing xcopy deploy, or just testing, you will need to bring this library along.

There is also an earlier version of this same library, that shipped on VS2008 but will not work (it is missing some components that were added to the namespace later). So if you need to build against the current version (e.g. if you are working on code that uses the shape components), make sure you update to VS2008 SP1, which updates this library.

Windows 7 and AVG == Unhappy CPU Usage

The title pretty much says it all.

Backstory is that I ran Windows 7 in a VM without any anti-virus while doing some evaluation, and I was impressed by how sparing it was of resources.

Then I installed the RC on my (underpowered old) laptop, figuring it would be a good replacement for Server 2003 (which is resource efficient but not exactly designed for laptops).

The RC used somewhat more memory -- it appears to be able to adjust its memory footprint depending on the host hardware, which is cool -- and a ton more CPU.

The CPU usage was suspicious because it's rare to find software that consistently pins a CPU with actual work, and because the usage was high priority -- coming from kernel space or a library tied tightly to kernel hooks. It was also suspicious because Microsoft plans to sell a version of 7 on netbooks, which are even more underpowered than my two-year-old bargain-o-matic laptop.

Turns out AVG, generally a fine anti-virus product, struggles with Windows 7 and often insists on every available CPU cycle, while the end user sits there wondering why context menus won't even open anymore.

After a bit of Googling, I removed AVG and installed Avast, and 7 is screaming along on the laptop now.

Note the retroactive Windows 7 hardware subsidy: this laptop was discontinued by the manufacturer in '07 because it shipped with Vista Basic but proved so slow as to be completely unusable in that configuration. The new OS basically injects value into the old machine.