Current version

v1.10.4 (stable)

Navigation

Main page
Archived news
Downloads
Documentation
   Capture
   Compiling
   Processing
   Crashes
Features
Filters
Plugin SDK
Knowledge base
Contact info
 
Other projects
   Altirra

Archives

Blog Archive

Why doesn't VirtualDub enable the new Windows XP visual style?

Sporadically, I get people emailing me .manifest files to enable the Windows XP look on buttons and sliders in VirtualDub's UI and ask me why I don't ship with them enabled.

Because it would break plugins and codecs.

Microsoft realized that it would be difficult to redo the look of the common controls without introducing compatibility issues, so in Windows XP they introduced side-by-side versions of the libraries. Version 5 of COMCTL32.DLL still sports the old look and is used by default; applications can opt-in to COMCTL32.DLL Version 6. The problem is that the most straightforward way of doing this is to use an application manifest, which in VirtualDub's case happily causes all DLL loaded in the process, including plugins and video codecs, to use the new visual style too... which could then break their configuration dialogs. If you think this is theoretical, it isn't. When I tried it, it took me about five seconds to spot the first problem in the main app alone: the mark-in/mark-out buttons don't display properly with V6.

Now, Microsoft's solution for this is to compile an application as "Isolation Aware," meaning that the application uses the common controls library in such a way that only it, and other DLLs can still use V5. In theory, enabling this would allow VirtualDub to use visual styles without affecting plugins. Yay! Problem is, it isn't clear how this feature affects down-level compatibility with Windows 98/ME/2000, and it it's implemented as a bunch of inlines in the header that have code like this:

    const BOOL fActivateActCtxSuccess = IsolationAwarePrivateT_SqbjaYRiRY || IsolationAwarePrivatenPgViNgRzlnPgpgk(&ulpCookie);

Just the thing I want to enable blindly in my app. Not. Thanks for obfuscating this, guys. I haven't had time to decipher this and look at all of the ramifications of enabling this, or to search for instances of dynamic linking with GetProcAddress() (which wouldn't work in this kind of scheme).

I think that in worst case I can use the activation context API to conditionally enable V6 and add an option to Preferences to toggle it, but to do that I'd definitely have to make all calls into COMCTL32 dynamic. Bleah.

Comments

This blog was originally open for comments when this entry was first posted, but was later closed and then removed due to spam and after a migration away from the original blog software. Unfortunately, it would have been a lot of work to reformat the comments to republish them. The author thanks everyone who posted comments and added to the discussion.