¶Compiling VirtualDub with Visual C++ 2005 Express
Microsoft finally shipped the long-awaited Visual Studio 2005 this week. Although most were simply wanting a service pack for Visual Studio .NET 2003 (or even a second one for VS2002), VS2005 does have a lot of cool improvements as well. The really good news, though is that Visual C++ 2005 Express Edition is available for free download for a year:
http://msdn.microsoft.com/vstudio/express/visualc/
As far as I can tell, no registration or activation is required. The Express edition does have some limitations: no 64-bit support, no source code control integration, no ATL/MFC, no Win32 resource editor, no macro assembler (MASM), and you must download and manually integrate the Platform SDK (using some ugly instructions in the help). However, it does come with the optimizing compiler, can generate 100% native executables, and does have the Threads pane that was taken out during beta 2. I highly recommend getting it, if for no other reason than that it has a very capable GUI debugger.
There are some minor changes that have to be made to the VirtualDub 1.6.11 sources to get it to compile under VC2005 Express.
Patching the VirtualDub source
Notes on the change:
- A few places refer to member functions with unqualified syntax, which must be changed to &class::member as indicated by the compiler error.
- Vector4 has a conversion constructor which is bogus and should refer to Vector3<T> instead of just Vector3.
- After importing the projects, buffer security checks (/GS) and run-time type information (RTTI, /GR) should be turned back off. Compliant for() scoping and wchar_t-as-native-type can be left on.
- _CRT_SECURE_NO_DEPRECATE and _SCL_SECURE_NO_DEPRECATE must be added to the preprocessor definitions to silence a boatload of annoying deprecation warnings. Sorry, Microsoft, but strlen() is not deprecated in Standard C++, and I am trying to minimize the amount of non-portable code I write.
- Several locations have to be updated to avoid taking the address of the first element of an empty vector, i.e. &vec[0]. None of the code in question is broken, as the referer is always a zero-iteration loop, but nevertheless it's invalid to take the address of the end of a vector, as opposed to arrays, where it is valid. VS2005's Standard Template Library (STL) uses checked iterators in debug builds by default, so it fires asserts when this occurs.
I've put together an archive that contains the necessary changes, along with a pre-converted set of project and solution files:
http://www.virtualdub.org/downloads/VirtualDub-1.6.11-VC2005.zip
Note that VirtualDub requires the Microsoft Macro Assembler (MASM) to build, so you must either have MASM 6.15 from the VC6 Processor Pack or MASM 7.0 from Visual Studio .NET to build 1.6.11 with VC2005 Express.
If you have VS2005 Professional or Enterprise then you can build with MASM 8, but the assembly language files have to be updated to fix syntax errors in MOVD and MOVQ instructions. The problem is that the new 8.0 assembler enforces an old rule that untyped memory references must use the same size between source and destination arguments, which breaks the following (very common) statements:
movd mm0, [ecx]
movd [ecx], mm0
movq xmm0, [ecx]
movq [ecx], xmm0
The statements must be updated to use explicit pointer types:
movd mm0, dword ptr [ecx]
movd dword ptr [ecx], mm0
movq xmm0, qword ptr [ecx]
movq qword ptr [ecx], xmm0
I'll probably fix these once I get a non-Express version of VS2005 and switch over to using it.
Evaluation of VC2005 Express RTM
The gradient toolbars are completely unnecessary. They look OK in normal use, but look nasty and take up valuable bandwidth over a remote desktop connection with reduced color depth. They're also a very odd choice of colors (3DFACE to WINDOW, when I checked in the beta).
VS2005's user interface feels snappier than that of VS2003, and I'm pleased to see that the keyboard shortcuts for VC++ have been restored to sane defaults, i.e. build is F7 and not Ctrl+Shift+B, project settings is Alt+F7, etc. The annoying "build failed — run stale version anyway?" dialog has thankfully been made optional.
Memory-wise, the IDE still takes a lot more memory, about 150MB for VirtualDub.sln vs. 50MB for VC6. This isn't any worse than VS2003, though, and Intellisense is a lot better in 2002-2005 than in 6.0; I can actually find enums and #defines.
The project format changed again, and there's no option to save to 7.1 format. Sigh.
You can now create property sheets that automatically apply settings to projects; sharing property sheets between projects allows you to change project settings across a solution instantly. They are attached using relative paths, so they can move with the project. This is a godsend for any shared code that requires changes to dependant projects, particularly for include and lib paths. Barring unforeseen annoyances, I forsee this to be a very popular option. One complaint is that it's a bit annoying to attach and unattach them to projects, especially if you only want to apply it for some configurations.
I like the movement by Microsoft towards greater standards compliance, and I can't complain about adding features that encourage secure code. However, I think that deprecating a ton of Standard C++ functions by default as being insecure even though (a) they're not deprecated in the C++ standard and (b) most aren't inherantly insecure, but only when used in an insecure manner, was a poor choice. Not all C string functions are gets(). It's really annoying to anyone who wants to write portable code. And frankly, I don't consider adding a NULL pointer check to be added security. We're in protected mode; it'll crash.
Managed C++'s new syntax looks much less underlineful. Maybe with a few more revisions I'll actually consider using it. I like the "for each" keyword, especially since it can be used with native STL and even custom classes, but I would have preferred typeof/decltype/auto support instead.
Lots of long overdue goodies added — variadic macros, __movsd(), and __restrict. Keep 'em coming.
The compiler hasn't crashed or munged my code yet. I'll try harder.
The help system seems slower, but supposedly there's been a lot of work put into improving the categorization. The real test will be when I get a version of VS2005 that has the Platform SDK preinstalled. I will be docking one point from the grade for every time I get Windows CE documentation, two points for each page on the .NET Framework, and five points for MAPI while looking up KERNEL32 calls.
The really awful bug introduced in the build system starting with Visual Studio .NET 2002 that caused delays of ~1 second per project during dependency checking has now been fixed; up-to-date projects are skipped almost instantly. I still maintain that this bug, which can add well over 30 seconds to a compile-run cycle in a large project, should have been considered recall-class and that Microsoft is obligated to patch it for both VS2002 and VS2003, but at least we won't have to suffer through it for VS2005. This means that Fast Solution Build — which unfortunately crashed on C# projects — is no longer essential.
Debug output speed is still very poor in VS2005, unfortunately. VS2002/2003 are an order of magnitude slower than VC6 at receiving debug output (OutputDebugString) from a debugged application; it's literally so bad that if debug output is being spammed you can watch the text scroll by and the IDE will be stuck processing it for several seconds after you issue the Stop (Shift+F5) command. The reason for the horrible slowness is that every debug message is sent as a separate call that has to be marshalled into the UI layer's single-threaded apartment (STA) by COM, and the UI updates the pane for every single line. VC6 cheated since it would drop chunks of debug output under high load, but the NT system debugger (NTSD) doesn't drop a single line and is just as fast as VC6 in this regard. You probably don't know why this is important unless you've tried debugging a 3D application and gotten boatloads of the useless warning:
Direct3D9: (WARN) :Can not render to a render target that is also used as a texture. A render target was detected as bound, but couldn't detect if texture was actually used in rendering.
...spammed into the Output pane. VS2005 is about one-third faster at receiving debug output, but still has a long way to go; the UI team sparsed the pane updates to kill the redraw overhead, but the significant marshaling overhead is still there. Oh well, I guess I'll be hot-patching WaitForDebugEvent() and ReadProcessMemory() on the debugger again.
Not that I've tried it on an industrial-strength program yet, but debugging native code in mixed-mode is sooooo much faster in VS2005 than in VS2003 it's not even funny. Mixed-mode allows you to debug a process that contains both managed and native code (I refused to call it "unmanaged") by effectively attaching both kinds of debuggers. The problem is that debugging native code in this mode in VS2003 is painfully slow; stepping between lines has a noticeable delay, and the already poor debug output speed drops to about three per second. In VS2005, stepping and output is almost instantaneous. I gave Microsoft a bit more slack on this one because it's a tougher problem than buffering debug output, and I'm glad to see that the situation has greatly improved.
Tracepoints, which are breakpoints that trigger a formatted message or a macro rather than a break in execution, are a lot more useful than they seem at first. It's nice that you don't have to recompile the code to insert a trace, but where they really come in handy is when you realize they can dump registers in the middle of raw assembly code! Manually inserting a trace call in the middle of an asm IDCT routine is not fun in comparison. I foresee lots of interesting uses for this.
The STL visualization is nice, especially since you can customize it. Although it's not advertised as such, it also bypasses an annoying restriction in regular AUTOEXP.DAT expressions, namely that you cannot reference more than one field in an expansion, which made expansions like std::vector<*>=size:{_M_last-_M_first} impossible.
Overall, I'm pleased so far. When I got my hands on the VS2002 beta, I thought, "man, this sucks, good thing it's a beta." Then we got VS2002 final and it still sucked. My initial experience with VS2005 has been pretty good so far, so I'm optimistic. And at least this time I can bitch on the Product Feedback site.