slimCODE

A new version of slimKEYS is now available. Though the list of new features is slim, it took me more than just a few hours to get through translation of the interface to French, and to finally make slimVOLUME support 64-bit Vista systems.

In the first case, it was a long and tedious job of moving every string to a resource file, translate each one, localize each form and repeat the translation for each label. It was simply long, and boring.

In the second case, I had a problem. Taking apart the numerous p-invokes throughout the code (but mostly in slimSIZE), slimKEYS is a fully managed C#-made application, except for one tiny portion of code used by slimVOLUME. The slimCODE.slimVOLUME.Vista.dll file is a mixed assembly made in C++. Normally, .NET applications don't have to care about the address space size. 32-bit or 64-bit systems don't matter, as long as the CLR implementation on both platforms is equivalent, and that your p-invoke signatures are correct. But in the case of slimKEYS, when the 64-bit implementation of the CLR was trying to load this mixed assembly, it caused a load error. An unmanaged 32-bit application can run flawlessly on 64-bit systems, but a 32-bit DLL cannot get loaded in a 64-bit CLR domain.

Usually, unmanaged applications that wish to natively support both 32-bit and 64-bit systems offer two packages, each built exclusively for each platform. But that's totally against the logic behind managed applications. At least that's what I thought. It was easy for me to build two versions of my C++ DLL, but how could I use them from a single managed application? How could I keep offering a single and consistent package?

After investigating, asking questions without getting precise answers and doing some trial and error, I chose a solution that isn't guaranteed, but seems to work well. My C++ DLL implemented a single class, called VistaVolumeControlsBridge. The managed plug-in declared a base class named VolumeControls, with two derivatives VistaVolumeControls and WmmVolumeControls. So there was already a level of indirection, where the VistaVolumeControls class was instantiated based on the platform, and using an instance of VistaVolumeControlsBridge under the hood. What I did is create a 64-bit version of the C++ DLL which implemented class Vista64VolumeControlsBridge, and its Vista64VolumeControls counterpart on the managed side. Now, the decision between creating a WmmVolumeControls or a VistaVolumeControls based on Environment.OSVersion had become a three dancers decision that looks like this:

      if( Environment.OSVersion.Version.Major >= 6 )
      {
        if( IntPtr.Size == 8 )
        {
          m_volumeControls = new Vista64VolumeControls();
        }
        else
        {
          m_volumeControls = new VistaVolumeControls();
        }
      }
      else
      {
        m_volumeControls = new WmmVolumeControls();
      }

Since VistaVolumeControls and Vista64VolumeControls are themselves managed classes, this doesn't seem to trigger loading of the 64-bit type on 32-bit systems by the JIT, and vice-versa. I could not find any reference if I could assume that a type that is never instantiated will never require its containing assembly from being loaded. But I'm ready to take the risk, and wait for your feedback if it breaks.

Another neat feature with slimVOLUME on Vista is that you can now change which playback device's volume you are controlling. I also wanted to change the default playback device with a hotkey, but Microsoft doesn't want this to happen. They think device manufacturers would abuse of such an API to make their hardware stay always as the default device. And I'm not making this up, I read it on their forums (here, here, here and here), and asked Larry Osterman myself:

We've gone around and around on this one, and while at some level it would be nice to allow developers the ability to change the default audio device, there is no way that we can. The problem is that audio vendors would abuse the functionality to attempt to force THEIR hardware to be default device even if the user didn't want it to be (we've seen evidence of vendors doing this in the past).

We used to say something at Xceed about those situations: Two wrongs don't make a right! This is a very good example. Creating a problem to avoid another one. I really think it was a stupid decision. Changing the output device on Vista requires 4 steps:

1. Right-click the speaker tray icon.
   
2. Click "Playback Devices".
   
3. Right-click the device.
   
4. Click "Set as Default Device".

Failed.

I'd be really happy to see an API for this in Windows 7. But if there are hackers reading this, can someone tell me what is called under that "Set as Default Device"? The API already exists, it's just not documented.