slimCODE commUNITY

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.

I had an agreement. I gave my word. In order to win the book, I had to make a critique of it. I read it. I took notes. I enjoyed many topics, considering the book as a very good read for someone like me who's starting with web development and ASP.NET. But the critique never came.

With my current time employment, it fell very low in my priorities. It could wait. Then I realized why it wasn't a priority: it isn't a great book. I would have written much earlier would I have been excited about it. On the other hand, I would have written earlier too if I thought it was that bad. It's average.

The problem is, I have no idea who that book is intended for. What I initially though was a reference book for average ASP.NET developers, then transformed, while reading it, into a "one read" book for new ASP.NET developers who don't want to hit dead ends, and finally upon completion and working on a critique ended up in my mind as a clumsy agglomeration of unequal articles. And don't put to much importance on words like "clumsy" or "unequal", as the real keyword here is "article". In the real world, I only put forth a single suggestion coming from that book. Does this mean the rest is useless? Not at all, it's just not relevant for me right now.

I have to agree with Jeff, or at least agree with its questioning. Books like "The ASP.NET 2.0 Anthology: 101 Essential Tips, Tricks & Hacks" aren't meant for paper. We should be able to find those articles quickly and easily, when needed or reading them as they come, from our main working tool: the computer. They're articles.

Can't stop thinking that Jeff's initial thoughts on stackoverflow.com came from working on that book, as almost everything in that book would fit very well on that upcoming site.

Best of luck, Jeff, and thanks again for the book.

I'm getting crazy. Totally. I'm now convinced aliens kidnapped me in my sleep and changed my Vista installation.

This morning, I tried to open a Command Prompt as administrator. I pressed Win-Z, typed "cmd", pressed Ctrl-Enter to get to the slimKEYS extended options, made sure the verb was "runas" and pressed Enter to launch the app as admin... But nothing. No UAC prompt, no Command Prompt, nothing.

So I pressed the Win key, typed "Command" to highlight "Command Prompt" in Vista's start menu, pressed the context menu key, and selected "Run as administrator"... Nothing more. I could hear my fish breath.

I went back to slimKEYS and tried launching "Notepad2" (my Notepad replacement) as admin, and it worked. I tried Windows' own Notepad, and it failed. Hun? Tried again with the Vista start menu, failed too.

I decided to try checking the "run this program as an administrator" option and see what happened, but something I'd never seen before prevented me of doing so:

"Compatibility modes cannot be set on this program because it is part of this version of Windows". What? When did that "new feature" (!) appeared? I have ran Command Prompt and Notepad as admin in the past, I know this is new. But since when? And how the hell am I suppose to run a Command Prompt as admin now? What did I do to enable that counter-productive and stupid feature? Did I mess with something or did a Windows Update change that behavior?

I tried looking for answers on the net, but either I'm not using the correct keywords, or it's a new problem nobody had before.

What is happening to my Vista?

With Scott's Visual Studio's theme rundown, I'm getting requests for my VS Settings file for my older example. I can't give you the exact same colors, as I've tweaked them a little. Fear not, the look is almost the same, but I did change the font. Here's the rationale: With a bigger LCD screen, I do benefit from ClearType. Then ProggySquare becomes useless, since it's a fixed size (12) bitmap font. That's why I switched back to Lucida Console. I don't have the slashed or dotted zero, but it doesn't seem to bother me. I do like Consolas, except for that weird "g". And the ClearType effect is not as great as with Lucida Console, probably because I tweaked it with their Verdana example, I don't know.

But when working on my 15" laptop, Lucida Console and Consolas just don't cut it for me. ProggySquare becomes way better! I don't have TrueBright on my Dell laptop. Maybe that's why I need a crisp font without anti-aliasing effects... go figure.

So here's the latest screenshot on my desktop:

And that's how it looks on my laptop:

And finally, you can download my VSSETTINGS file with the Lucida Console font.

I just updated the web site and slimKEYS package for the newly released version 1.2.8069... 8069 you say? What's that? It's my new version numbering. Well, not that new, I stole the idea from Xceed, but it's partly my fault anyway if they use such a number. I even have a Vista widget, err, gadget displaying the current day's version number:

I've decided to use a version number I can change every day, so I can release alpha and beta versions of slimKEYS that have their own version number. No more beta 1, 2, 3...

I really hope the new slimSMOKE plug-in finds some lovers, as I've grown to depend on it myself. I always know which window has the focus. Look at my current desktop:

There are many other improvements, I'll let you check for yourself. This new release also coincides with a price increase. It was absurd for me to continue selling slimKEYS lifetime licenses for only 10$. It's now 20$, but it's the last 20$ you'll spend on slimKEYS. And if you don't think it's worth 20 bucks, I hope you'll take the time to write me and tell me what I need to change. I'm listening!

The second beta of slimKEYS 1.1.3 is now available for download. With this last beta before the release, I urgently need Vista testers. If you look at the list of changes, you can see a few pending or new Vista features.

slimVOLUME

Two main things have changed with the slimVOLUME plug-in. First, the window display was redone completely, to use a true transparent window. The previous version copied an image of what was underneath the volume window, and drew on that image. Less than beautiful when you happened to Alt-Tab while the volume was still displayed or when the content was changing (ex: watching a video or movie). If you play games not in full screen mode, this new display will also work correctly. The "label style" is not implemented yet, so you'll get TV-like bars in both settings.

The second big change is the use of the new Vista API for changing the main volume control. The previous version did not work on Vista, since all it did was change the volume of the sounds slimKEYS played... which is none! This needs to be tested more thoroughly by Vista users. For example, there is one known issue: if you change the output device, for example by plugging-in your USB headset, slimVOLUME won't notice, and will continue to change the previous device's volume. That will be fixed in the official release, I'm just waiting for some final information.

So, mandate #1: Test slimVOLUME on Vista.

slimSIZE

If you are using slimSIZE on Vista, you already know it cannot move windows that belong to either isolated or elevated applications. Maybe you did not know what was the reason it could not move all windows. Now you know! This a Vista security feature. Applications like Internet Explorer 7, run in a special isolated mode, which prevents it from accessing all Windows features, and as a side effect, prevents other applications from accessing the IE7 process as much as they'd like. Other example, if you are a Visual Studio .NET 2005 user under Vista, you must be running it as administrator. Such applications and their windows cannot be the target of window APIs either.

Fortunately, this Vista security feature can be "safely" circumvented. The recipe isn't obvious, but it works (except*). If your application embeds a specially crafted manifest that includes a "uiAccess=true" entry, is digitally signed, and runs from the "Program Files" folder, it can target windows that belong to isolated or elevated processes. If it does not run from the "Program Files" folder, it can still target isolated applications, but not elevated ones.

(*): With Microsoft, it could not be that easy. This miracle recipe is giving me one small headache: When slimKEYS is started from a StartUp shortcut (as it's the case almost 100% of the time), launching URLs takes an eternity when either FireFox or Opera is your default browser**. If launching other applications, those apps become sluggish and slow. At least, that's what I am experiencing on my machine. I made a small WinForms application with a similar manifest, strong name and digital signature, and a simple button that calls System.Diagnostics.Process.Start with an URL. If that application is started from a StartUp shortcut, clicking on the button takes 10 seconds for FireFox to open, and more than 2 minutes for Opera to open. But the same application, launched from the Windows Explorer, works perfectly, as does slimKEYS. If I remove the manifest, the problem also disappears (but you can't target isolated or elevated apps anymore).

I have posted on the MSDN forums and Microsoft newsgroups, but I am getting no answer. That's where more testers are required. If I can get more information about this, I'll be able to challenge MS better. If I get enough feedback, I may also choose to spend money on opening an MS support case. For the moment, I officially can't since I'm using an OEM license of Vista, and I'm not an MSDN subscriber.

Mandate #2: Tell me if slimSEARCH or slimLAUNCH.Delicious are slow to open web pages.

Mandate #3: Tell me if applications open from slimLAUNCH look more sluggish or slower than usual, or if they happen to open web addresses themselves, cause the same problem as mandate #2.

(**): I'll give a free slimKEYS license to the first person who can explain within a week from now why there is no delay when Internet Explorer 7 is your default browser. I'll give the answer later.

slimLAUNCH

A limited implementation of verb support is now available in slimLAUNCH. If you browse for an application or document to open, and press Ctrl-Enter to open the extended launch options, you will see a new "Verb" field at the bottom. Default verbs for the selected application are available in the drop-down list, and you can type in the verb of your choice. For example, typing "runas" will open that application as administrator. The last verb is remembered, but only used when pressing Ctrl-Enter.

Mandate #4: Test a few verbs, test the "runas" verb, give comments about how this can be improved.

slimSMOKE

The rest of the changes are fixes or featurettes, except for the new slimSMOKE plug-in. I'm using that plug-in full-time now, and have been enjoining it a lot. But I'm still waiting for other users' feedback. This second beta can also highlight not only the active window, but also all top-level windows which belong to the same process. Here are a few screenshots of (a part of) my desktop with slimSMOKE active. You can see the active application much easily.

You think you could like this? Mandate #5: Test slimSMOKE and give me your impressions!

I did it again. It's not the first time. I created something that looks very interesting, but I have yet to decide if it's useful in the first place. I called it slimSMOKE, and you probably guessed by its name that it's a slimKEYS plug-in.

Does it happen often you work on your computer and start typing just to realize the active application is not the one you thought? It can get you in trouble if what you type has some matching actions in that other application. slimSMOKE dims inactive applications*, so the active window jumps out of the crowd.

My initial feeling working with slimSMOKE is "cool", but I need feedback. If you like to test beta software, go get beta 1.1.3 and tell me your thoughts. The color, opacity and refresh rate are all configurable. You can toggle slimSMOKE on and off by pressing Win-M.

If you try this new beta version on Vista, you'll also get the chance of testing Vista support for slimVOLUME (finally). I'll have more to say about this later, I have someone to thank about this, but he doesn't know.

Have fun!

* (Actually, it dims everything except the active application. This means the desktop is also dimmed. I could have dimmed only top-level windows, but this extra processing is making slimSMOKE use too much resources for my taste, and the desktop itself can be "selected".)