What is VirtualDub?

VirtualDub is a video capture/processing utility for 32-bit and 64-bit Windows platforms (98/ME/NT4/2000/XP/Vista/7), licensed under the GNU General Public License (GPL).  It lacks the editing power of a general-purpose editor such as Adobe Premiere, but is streamlined for fast linear operations over video.  It has batch-processing capabilities for processing large numbers of files and can be extended with third-party video filters.  VirtualDub is mainly geared toward processing AVI files, although it can read (not write) MPEG-1 and also handle sets of BMP images.

I basically started VirtualDub in college to do some quick capture-and-encoding that I wanted done; from there it's basically grown into a more general utility that can trim and clean up video before exporting to tape or processing with another program.  I released it on the web and others found it useful, so I've been tinkering around with its code ever since.  If you have the time, please download and enjoy.

§ ¶Metro style apps and the Win32 API

It's been way too long since I posted, hasn't it? Time to change that.

There's been a bit of discussion about the difference between "desktop apps" and "Metro style apps" on Windows 8, particularly as it pertains to Windows RT (previously Windows on ARM), which currently isn't going to allow third party development of desktop apps. Part of the confusion comes from the fact that you can use native C++ code in a Metro style app. Native C++ doesn't mean you can just recompile an existing C++ app written on top of Win32, though, and there are lots of misconceptions about what this means for converting existing apps to Metro.

I haven't actually written a Metro app, but I have looked a bit at what's involved out of curiosity. Looking at the documentation and the requirements, I'm of the opinion that most C++ apps will require a major rework to conform to Metro app requirements. This is based on the restrictions to Win32 API usage that will require invasive changes to either the C++ code itself or the frameworks that the C++ code is based on. Nevertheless, it's useful to actually look at the API lists and get an idea of where the trouble spots are, which is what I'm going to do here. Think of this as a what-if exercise, kind of what would happen if someone at work just asked you for a wild guess at what would need to change to retarget Metro.

Of course, in order to do this we'd need some guidelines, so we're going to assume:

• That you actually want to use Windows and a Metro style app. Yeah, I know, definitely not always true... just pretend for the sake of this exercise, then.
• That the application is appropriate for Metro conversion and doesn't have obviously crazy Win32 usage. Sysinternals Process Explorer is not likely to be a good target app for conversion.
• That the UI is going to be rewritten from scratch, so that it actually suits Metro and a tablet. The entire Win32 UI subsystem is gone, so there's no point in wondering about that.
• That we're mainly talking about a C++ core that's reasonably well architected, i.e. has the Win32 API calls reasonably wrapped and is decently modular, so that if an API call has a direct replacement it isn't a big deal to swap it out. We're looking for stumbling blocks here, like a lack of equivalent functionality.
• That the resultant app will be written to properly conform to requirements and won't try to do things like subvert the API restrictions.
• That you're using Visual C++ and can easily interface to WinRT through C++/CX when needed. Code only compiles under GCC? Uh, sorry, that's a whole other set of problems that I can't cover here. I think it's possible to use WinRT entirely through COM APIs, but it's likely to, uh, build character.

Our main reference is going to be "Win32 and COM for Metro style apps" from MSDN:
http://msdn.microsoft.com/en-us/library/windows/apps/br205757.aspx

...which, as of this writing, is preliminary and subject to change of course. I'm just going to go down this list, as well as lookup APIs to see if they're marked as "desktop only" or "desktop and Metro apps", and see what that means for existing code.

So, with all of this in mind, what stumbling blocks that we might encounter?

§ ¶Bloat

I just downloaded the latest trackpoint/trackpad driver for a laptop for a reinstall, and ended up with this:

I don't mind a bit of expansion, but WTF... 59MB for a mouse driver??? That's almost as bloated as a printer driver.

I took a look at the expanded resources, and the big offender is that it includes the entire 43MB .NET Framework 4.0 Client Profile installer. Apparently it was worth dragging in the latest version of .NET in order to use WPF in the control panel, which, by the way, was already installed. On top of that, there are both 32-bit and 64-bit versions of executables that contain a ton of very large, uncompressed bitmap resources which presumably made up the bulk of the remaining 16MB of download. This took a while to download over a 1.5Mbps connection.

Is it too much to ask for just a little bit of attention to size?