Stuff

I get a fairly decent trickle of questions on the forums and by email on how to compile VirtualDub. The workspace is fairly complex and can be tricky to compile if you are not a professional Win32 programmer, so I'm going to provide a few tips on how to fix the most common compile errors.

Note that my build environment is rather complex -- I have four compiler versions (Visual C++ 6.0 SP5+PP, Visual Studio .NET 2003, Visual Studio .NET 2005 beta 1, and the Windows 2003 DDK compiler), two machines (laptop and desktop), and source code control (Perforce). Don't be surprised if you see something in the build process that doesn't work out of the box; you will need to hack the project a little bit to get it to compile.

PC controllers, frankly, suck; for some reason, most of them are
designed to have the contact pads on the diagonals of the D-pad, so
it's impossible to get clean hits to the four cardinal directions. In a
Final Fantasy-style RPG this is death because instead of selecting
Magic you end up selecting Row and moving your white mage to the front.
I decided to build an Xbox-to-PC adapter after my friend Alec told me
that it's just a straight wire-up. I knew that the Xbox controller was
based on USB, but I was under the impression that it drew too much
power to be connected to a normal PC port, which is not the case.

I spent far too much time yesterday playing Treasure of the Rudras (Rudora no Hihou), so I'm trying to do something else today. I think Riza's boss battle music is my new choice for top SNES music, though.

VirtualDub 1.6, like 1.5, is an extensive rewrite of the internals. 1.5 focused on the bottom-level framework for the program, mainly lifting out a few of the subsystems, and most notably OS-level helpers, into static libraries. The changes in 1.6, besides the AMD64 and VS2005 compatibility changes, are focused a layer up, at the application library level. This means that more of the 1.6 changes (besides bugfixes) are visible to the user.

VirtualDub 1.6.0 is out the door, and besides being the first experimental release in a while, it has a major new feature: it is the first version to have a native 64-bit (AMD64) build. This build is pretty raw, is missing a bunch of features and optimizations, and doesn't do much yet that really shows "the power of 64-bit." (It's even compiled with a prerelease compiler, the DDK compiler. VS2005 beta 1 doesn't have a "go-live" license.) Nevertheless, it is a true AMD64 release, for those of you who must have a native release.

It took me about three days to get this release out the door, once I'd committed to absolutely nothing but showstopper bugs. It took me about two dozen tries to get it right, and each try is about 10 minutes to do a full rebuild (to make sure the final builds are correct and match source). Well, the AMD64 build is broken. Okay, we'll fix that. The crash handler bombs. Fixed that. Now the crash handler doesn't bomb, but it doesn't report DLLs properly. Fixed that. Oops, broke x86. Try again. Seems good... nope, UI is broken returning from capture mode. Fix that, try again... oh, frameserver's busted too. Okay, try AGAIN, one more time... about dialog says 1.5.10. ARRGH. Fix that, check it into Perforce, compile one last time.... Change log has a build number two below actual value.

Screw it, I'm not doing another build to fix that. Ship it.

I have no doubt that I left something stupid in the build, but considering the number of low-level changes in this build, some amount of breakage is to be expected. If you spot regressions, report them to me so I can fix them for 1.6.1. Please don't email me just to complain that your pet feature didn't make it in, though; I had to draw the line at some point.

I was typing a long, thorough explanation in Pivot for this part explaining all of the new features in VirtualDub 1.6.0, but I'm very angry because Internet Explorer ate it. I'll retype it later.

I ran into an annoying problem yesterday while rewriting some of VirtualDub's assembly language routines for AMD64.

Take this innocuous looking routine, for instance:

.code
trap proc public
sub rsp, 256
int 3
add rsp, 256
trap endp
end

It just fires the application crash handler with a breakpoint exception. Well, actually, not quite. What it actually does is terminate the application. The reason has to do with the way exception handling works on AMD64 Windows.