¶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:
- Visual C++ 6.0 Service Pack 5 + Processor Pack, Visual Studio .NET 2003, or Visual Studio .NET 2005 Beta 1 (Express or Enterprise). VC6 is the official development platform for current versions.
- Up-to-date Platform SDK headers.
- The DirectX 9.0c or newer SDK.
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:
- An AMD Athlon 64, Athlon FX, or Opteron, or an Intel Xeon with 64-bit support. Bochs will not boot XP64 due to a missing local APIC. (I tried.)
- The Windows Server 2003 DDK, or Visual Studio .NET 2005 Beta 1 Enterprise Edition. Express does not have the AMD64 cross-compiler.
- Windows XP Version 2003 x64 Edition.
- Debugging tools for Windows, AMD64 version. This is only necessary since VC6 cannot debug 64-bit executables; you can forgo this if you have VS2005.
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:
- Windows 2000 or Windows XP. Don't use Windows 95/98/ME for development if you can help it.
- A source code control system. This makes it much easier to track any new releases I might create. I use Perforce in its default two-user, two-client mode; you can use CVS or whatever you like.
- If you are using VS.NET 2003, Joshua Jensen's Fast Solution Build plugin.
- The Info-Zip command line archiver (zip.exe).
- A sampling profiler. Intel VTune is the tool of choice here, but AMD CodeAnalyst is now a viable replacement. (Note that for sampling, you can use VTune on an Athlon or CodeAnalyst on a Pentium 4 without issues.)
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:
- Break some of the dependencies in the main VirtualDub project -- in particular, remove the Docs and helpfile dependencies.
- Remove buffer security checks (/GS) from all projects.
- Add for loop scope compliance (/Zc:forScope) and native wchar_t (/Zc:wchar_t) to all projects. If this breaks anything, let me know, as it is going to be the standard once I switch to VS.NET 2005.
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*http://msdl.microsoft.com/download/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.