Hercules CTCI-W32

Visual C++ Project Build Instructions


As mentioned on the main page, the complete source code for each CTCI-W32 component is provided for downloading and building yourself. The programs were written in Microsoft Visual C++ using the Foundation Class (MFC) library (i.e. they're each an MFC project).

Unless you're familiar with Microsoft Visual C++ or MFC (or at least Windows SDK), you probably shouldn't be trying to build CTCI-W32 from source.

If you're at least familiar with Win32 API programming (i.e. Windows Platform SDK), then you might be okay. Just try to ignore all the strange MFC crap you see and you should be fine. :)

Assuming you're familiar with the Visual Studio VC++ Build environment, there are a couple of things you need to know about building the CTCI-W32 projects (and what you need to know depends on which version you're trying to build).

For the most up-to-date information regarding how to properly build CTCI-W32, please refer to the "README" provided as part of the source-code distribution.

The first thing you need to know is that except for FWPCUtil, each project is dependent on another.

If you're building the latest v3.2 version of CTCI-W32 then the Visual Studio 2005 Solution has already been pre-setup with all the needed inter-project dependencies such that all you should need to do is select whichever configuration you wish to build and click "Build All". To build all configurations and platforms, select "Batch Build" from the Build menu and click "Select All" followed by "Rebuild". Each prerequisite project will then be built in turn, automatically providing the needed input for each subsequent dependent project, such that when you're done you should end up with a complete CTCI-W32 package in the resulting 'bin', 'lib' and 'pdb' directories.

Otherwise if you're building an older version of CTCI-W32 (v2.1 or earlier) you'll need to build each dependent project in the correct order, manually providing the output of each into the other.

That is to say, the FishPack project can be built fine as-is, but in order to build the TunTap32 project, you will need to copy the FishPack.lib file created by the FishPack project to the corresponding Debug or Release directory of the TunTap32 project in order to build it. The same idea applies to tt32info except it needs the .lib files from both projects (FishPack.lib and TunTap32.lib). (The v3.1 Workspace projects are already setup to do all this for you automatically, but I didn't set that up in the older versions.)

Other than that, that's about it. As long as you have a relatively current set of Platform SDK header files installed on your system, you should be able to build the projects just fine. (Oh yeah: in case it's not painfully obvious at this point, you must use Microsoft's Visual C++ Developer Studio product to build the projects. The source is not generic C++ code; it's not portable, and probably won't compile at all with any other C++ compiler. Sorry.)

The only other thing I should probably mention is the v2.1 TunTap32 project workspace also contains a small sub-project with the very unoriginal name of "Test". It's a very Q&D ("Quick and Dirty") MFC SDI app that simply attempts to simulate a running "Herc". It spins off a thread that reads packets from the adapter and lets you 'ping' any IP address you want, and TRACEs the results to the debugger output window. (It doesn't display anything in its main window; all o/p is debug output via the TRACE macro.) After building it and before running it, you'll need to manually copy the FishPack and TunTap32 DLLs into its executable directory (Debug or Release).

Finally, for those that are interested, the AutoBuildCount.h header file is automatically updated whenever I build my projects by means of a simple Visual Basic 'addin' macro I wrote. All it does is rewrite the "AutoBuildCount.h" file in your project directory (or create it if it doesn't exist) each time you do a build or a build-all so you don't have to remember to manually do it. You still have to remember to manually increment the version numbers in your "version.h" header file yourself of course, but since at least the build count gets automatically incremented via the plugin, you're at least assured your product's "version" is unique each time you release it (if you design the handling of your product's versioning correctly of course, which I happen to do).

  "Fish"  (David B. Trout)

"Programming today is a race between
software engineers striving to build bigger
and better idiot-proof programs, and the
Universe trying to produce bigger and better
idiots. So far, the Universe is winning."

- Rich Cook