Stuff

Version 1.10.2 is now up on SourceForge, and adds a couple of features while fixing a number of regressions. One of the new features is that you can now relocate the program-relative files, like the job list and the crash dump location, to the user profile. Part of the reason I hadn't done this previously is that I've actually never released a version of VirtualDub that installed into Program Files -- it's always been a portable .zip release. Problem is, other people packaged it into installers that did a system-level installation instead of a user-local installation, or worse, users themselves copied it into Program Files. VirtualDub now supports operating in both modes and there are both UI and registry-level ways to switch to the user profile.

There are also a number of fixes in this release for filter issues that were introduced in 1.10.1. This was due to a big push I made in that version to hoist all internal filters up to current specs. Some of the filters in VirtualDub date back up to ten years, and you could tell by the source code in previous versions which filters were older because they were written procedurally, relied on assembly language routines with no C fallback, or just had generally nasty UI dialog code. I ended up rewriting a number of these filters either to enable them on x64 or to allow them to run on the latest filter API (unlike external filters, all internal filters are always on the latest API version, which caused problems). I unfortunately missed a few conversion problems in 1.10.1 which caused a few of the filters to break; these should now be fixed in 1.10.2.

A note on building the program: it can be a bit tricky to build VirtualDub due to the build configuration you need, and because there are some old docs on this website that I need to clean up (there's never enough time). Part of the problem is that I still use Visual Studio 2005 and a fairly old set of SDKs to build, because there are many backwards compatibility problems introduced by using newer compilers or SDKs. Long story short, the most likely build configuration change that people will try is to use VS2010, and if you try that, you will have more success with 1.10.x than with 1.9.x. The reason is that there are a ton of bugs in the VS8/9 project converter in VS2010 and the 1.10.x branch contains some mitigations for those problems.