Current version

v1.10.4 (stable)


Main page
Archived news
Plugin SDK
Knowledge base
Contact info
Other projects


Blog Archive

How to compile VirtualDub

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.

Okay, now for the tips:

To review what is required:

You must have the following to compile VirtualDub:

Do not install Visual C++ 6.0 Service Pack 6, as it will render you unable to install the Processor Pack.

You must also have the following to build the AMD64 build:

The farther you deviate from the recommended environment, the less I will be able to help. If you ask me how to compile the application using mingw while running Linux and targetting winelib, the only response you will likely get is "WTF?".

It is also strongly suggested that you have the following:

1.6.0 build errors:

You will get a couple of build errors if you try to compile VirtualDub 1.6.0 with VS.NET 2003. One is an error in a_stretchblt_point.asm due to a change in the macro assembler between 6.15 and 7.10. Add the following line to fix the error:

        assume  fs:_DATA

The second error is due to a workaround in vdstl.h for the non-standard std::reverse_iterator definition in older versions of the Dinkumware library that ship with Visual C++ 6.0. Since I use the VC6 libraries to compile the AMD64 version with the DDK, the conditional bracket in that area is incorrect for .NET 2003, whose C++ library declares reverse iterators properly with a single argument. Change it as follows:

-  #if defined(_MSC_VER) && (_MSC_VER < 1400...
+ #if defined(_MSC_VER) && (_MSC_VER < 1310...

Another error you might encounter:

sourceVideoDisplayDriverDX9.cpp(32) : fatal error C1083: Cannot open include file: 'd3d9.h': No such file or directory

You do not have the DirectX 9.0c SDK installed and in your path. (DX9 is required because it is the first version with sane Direct3D setup and 9.0c is the only version with AMD64 support.) The include paths must be added to Options/Directories (VC6) or VC++ Directories (VS.NET) in the Visual C++ IDE, and the IDE restarted.

Toolchain errors

Note: If you are using 1.6.0 and are encountering compile problems, set VirtualDub as the active project, and force stdafx.cpp to compile by itself. It contains a couple of checks for common toolchain setup errors and will bomb with a description of any necessary missing component.

'ml' is not recognized as an internal or external command,
operable program or batch file.

This means that you do not have the Microsoft Macro Assembler (MASM) installed. Since MASM (ml.exe) ships with all supported compiler versions, this means you either have Visual C++ 6.0 without the Processor Pack installed (which is not supported), or you have your paths screwed up.

Assembling: and
MASM : fatal error A1000: cannot open file : and
Project : error PRJ0019: A tool returned an error code from "Performing Custom Build Step"

I can't figure out why people would place their source code under the default home folders, but this error can be fixed by some slight adjustments to quoting in the custom build rules for the .asm files. The rule for the x86 files should look like this:

ml /c /coff /nologo /Zi /Fo"$(IntDir)$(InputName).obj" "$(InputPath)"

Another common error:

sourcefileasync.cpp(233) : error C2065: 'INVALID_SET_FILE_POINTER' : undeclared identifier

Your Platform SDK headers are out of date and must be updated from the Microsoft website. This is required for Visual C++ 6.0 since it ships with ancient Win32 headers; VS.NET 2003's headers might be new enough, but I haven't checked. VS.NET 2005 Enterprise Edition Beta 1 definitely has new enough headers.

'p4' is not recognized as an internal or external command, operable program or batch file.

If the verinc utility cannot write to either version.bin or version2.bin, it assumes that it is checked into source code control and will ask for permission to check it out. Saying Yes will cause verinc to attempt to use p4.exe to check these files out from the resident Perforce depot. If you do not have Perforce or do not have the command-line utility in your path, this will fail. Simply check it out manually using your SCC of choice or strip the read-only flag.

'zip' is not recognized as an internal or external command, operable program or batch file.

You will probably get this error if the helpfile project attempts to invoke Info-Zip to build the help archive, and it is not available in your path. Simply disconnect the helpfile project as a dependency of the main project to bypass this problem.

Notes for importing the DSP projects into Visual Studio .NET

VirtualDub does not ship with .vcproj files, so you must import the VC6 .dsp files to create them. There are a couple of defaults that should be changed after import:

Additional development environment tips

There is a batch file in the root called release.bat that automatically handles compiling and packaging final releases. It requires the Windows NT/2000/XP command interpreter to run. Run it with /? for help.

Build, run, and experiment with the debug build first. It runs at an acceptable speed and has a bunch of debug checks and asserts that are not in the release version.

Enable the Output Window in the debugger. This is where the VDDEBUG() macro outputs and you will get some helpful output in debug builds. The debug version will also dump any memory leaks, along with their allocation address and vtable type, to the output window on shutdown.

In VC6, check "screen reader compatible menus" in Tools > Options > Workspace to get rid of the dockable menu, and check "Load COFF and exports" under the Debugger tab so you have some clue where you are in system headers. Do not attempt to hook up system symbols as this will cause the debugger to leak a tremendous amount of memory per debugging session.

In Visual Studio .NET 2003, under Options > Environment > Projects and Solutions, uncheck "Track Active Item in Solution Explorer" to keep the file tree from going nuts, and check "Only build startup projects and dependencies on Run" to reduce the amount of rebuilding. Set the symbol path for the project to the Microsoft symbol server -- for instance, to download and cache system symbols to c:symbols, use SRV*c:/symbols* as the path. This will pull down up-to-date symbols for system DLLs from Microsoft, including prototype and frame pointer omission (FPO) info for more reliable stack unwinds. Finally, when working with code, get in the habit of asking the IDE to compile the current file before attempting a full build (with VC++ keys, Ctrl+F7 before F5/F7). This will cut down cycle time when your file is unlikely to compile cleanly.


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.