Using VC 7 to Build For AutoCAD 2000/2002


With the advent of AutoCAD 2004 and Visual Studio .NET (aka Visual Studio 2002), ObjectARX programmers are again faced with the task of moving from an older version of a compiler (VC6) to a newer version (VC7). Rather than maintain two versions of compilers and two versions of projects for supporting both AutoCAD 2000/2002 and the new AutoCAD 2004, it makes sense to use only the newest IDE to support *all* target AutoCAD platforms.

You can easily add build configurations in to your project VC7 so that the same project builds ObjectARX modules for both AutoCAD 2000/2002, and AutoCAD 2004, but the trick is to force VC7 to build your AutoCAD 2000/2002 target with the correct headers and libraries. In addition, you have to make sure your source code compiles correctly with both old and new ObjectARX SDK versions. This will likely require some conditional compilation if your code uses parts of the SDK that have been modified in ObjectARX 2004.

Following are some tips for successfully building ObjectARX 2000/2002 projects in VC7.

error LNK2019: unresolved external symbol ___security_cookie referenced in...
error LNK2019: unresolved external symbol @__security_check_cookie@4 referenced in...

* The current Microsoft Platform SDK now includes a separate library that provides implementations for these functions. Just link to bufferoverflowu.lib to resolve them correctly, with no need to turn off this new compiler feature (see KB894573).  

error LNK2001: unresolved external symbol __ftol2

Resolve this error by placing the following in one of your .cpp files (StdAfx.cpp, for example):

#if (_MSC_VER >= 1300) && (_MSC_VER < 1400) && (WINVER < 0x0500)
//VC7 or 7.1, building with pre-VC7 runtime libraries
extern "C" long _ftol( double ); //defined by VC6 C libs
extern "C" long _ftol2( double dblSource ) { return _ftol( dblSource ); }

error LNK2001: unresolved external symbol ___delayLoadHelper2@8
error LNK2001: unresolved external symbol ___delayLoadHelper2@8

These errors are caused by a change in the delay load helper function in VC7, that was in turn the result of a change in the delay load import descriptor that the linker embeds inside the image file. Microsoft renamed the function to prevent the possibility of the new format produced by the VC7 linker being linked with the old helper function (that expects the old format). Unfortunately, AutoCAD's [brain dead] module validity testing chokes on the new delay load import descriptor format.

The solution to this problem is twofold: first make the linker happy by linking to the new VC7 delayimp.lib; second, postprocess the linker-created .arx module to hide the delay load import descriptor so AutoCAD can't choke on it.

  1. The first part of the solution involves renaming the VC6 delayimp.lib file* so VC7 doesn't find that one, and uses it's own version instead. The file is located in VC98\Lib. I renamed mine to VC6.delayimp.lib.
    * Arnold Eibel sent me an email with a better solution: instead of renaming the VC6 delayimp.lib, just specify an explicit path to the correct file to use. Arnold's suggestion is to use "$(VcInstallDir)lib\delayimp.lib", thus making the path portable to future versions of VC.
  2. The second part of the solution is not as difficult as it sounds. I made a command line utility to remove the delay load import directory from the file. This won't affect the file's operation at all, but it will prevent PE file viewers (such as Dependency Walker) from being aware of the delay loaded dependencies. Simply download the utility (96k) and place it somewhere in your VC7 support path (i.e. VC7\Bin) or better yet put it in its own folder and add the new folder to the path for executables in VC7 global options. Next, add a post build step to run the conversion utility on the target module. Do this in settings for Build Events->Post-Build Event, and add this to the 'Command Line' setting:
    HideDelayLoadImports.exe "$(TargetPath)"

These are the problems I have encountered so far in my conversion process. As I encounter new problems, I will add my solutions to this list of tips. If you have additions or comments, please don't hesitate to contact me via email (but please understand that sometimes I can't reply to every email I receive).