in-page jumps: preamble -|- folders -|- build -|- runtime -|- debugging -|- downloads -|- quick start -|- missing items -|- postscript -|- end
2007-04-23 - Having SUCCESSFULLY built and flown FlightGear using MSVC8, and FAILED using MSVC6, it seemed time to try MSVC7 again ;=)) That is Microsoft Development Environment 2003, Version 7.1.6030. This is the original Microsoft Visual C++ .NET, with Microsoft Visual Studio .NET 2003 Service Pack 1 (KB918007) applied, and the Platform SDK installed, herein referred to as MSVC7.
Read the postscript for a strange FAILURE of the MSVC7 compiler. After I separated the SimGear and FlightGear projects, and did all the work in setting them up separately, and compiling the Debug configuration, I decided to give my MSVC7 single solution ANOTHER try, and GOT NO FREEZE on the Debug configuration build. Many mysteries ;=)) So now I am back on track to produce a single solution files containing all 24 projects. Unfortunately the release version still aborts, with a simple message 'Unknown exception in the main loop. Aborting...', but at least I now have the Debug version to try ... on with the FULL story ...
FlightGear depends on a considerable number of other 'libraries', which must be downloaded, and built first, then FG source and base data. Where possible, I tend to use the CVS (or SVN) development sources. And I tend to use the COMMAND LINE versions of these tools, since this facilitates the construction of a single batch file to update all the sources at one time.
CVS - Concurrent Versions System - I have zipped (MD5: 58a6ae5eb66eb1641e441f9e86d5a791) my client version 1.11.17, Copyright (c) 1989-2004 Brian Berliner, david d `zoo' zuhn, Jeff Polk, and other authors. CVS may be copied and used only under the terms of the GNU General Public License. At - http://ftp.gnu.org/non-gnu/cvs/binary/stable/x86-woe/ - later versions can be found, up to cvs-1-11-22.zip 10-Jun-2006 ... There are also several GUI version available, but I have never tried these, and have heard reports that they are quite difficult to set up.
SVN - Subversion - This is available from - http://subversion.tigris.org/ - I downloaded svn-1.4.0-setup.exe which does a nice windows setup, including automatically adding a path to the svn.exe, so it was all easy. I note there is a later svn-1.4.3-setup.exe, or you can download one of the zip files, and do your own setup. You may have to right mouse click, and use 'Save Target As...' to download these files in windows.
The link were valid at the time of this pages creation. In no particular order these are :- openal, freeglut, PLIB, OpenSceneGraph, OpenThreads, zlib, simgear, pthreads (optional), and flightgear source and base data -
With all the above sources, (and data) downloaded, you are ready to begin a build, first of the dependant libraries, and then FlightGear itself ...
I place all these source in a single folder I call FGCVS ... This is a view of the subdirectories in that folder. Note it contains a lot more than just the above mentioned source, but none of these additional items are specifically needed for FG ... It should also be noted I have unpacked zlib into to same folder, even though it is not a CVS/SVN source ...
You need to emulate this folder structure if you want to use the setup and compile tools given at the end of this page.
For various reasons, including the fact that today big hard disk prices are very reasonable, I never build in the above, what I call 'updateable' folders. I first XCOPY the required sources to a new work folder. To make all this EASY I have a batch file, SETUPFG.BAT, to create a new set of folder, in a chosen 'work' folder, and copy the required sources into place. This batch file is included in the vc7sln01.zip given below. After this setupfg.bat has run, I have a simpler set of WORK folders, in my case in a root folder G:\FG\MSVC7, containing the desired sources :-
The first folder, 'bin', is where all the final binary runtime items will reside. The 'data' is a full copy of the base FG data folder. In here I can also download, and add additional scenery, and additional aircraft models, etc. The 'fgfs' is the make, or build folder, where the single fgfs.sln resides.
In this case I am using MSVC7 - each component, and finally FG could be loaded individually, and built separately, naturally some before others, but I have created a single solution file, fgfs/fgfs.sln, and set of 24 MSVC7 project files, that includes all the required components, set to compile first, then finally FlightGear. Due to the changing sources, this is always a work-in-progress. Quite frequently files have to be added or delete from certain projects, and invariably, since this is nearly all ongoing development source, sometimes code fixes have to be made.
To try to ease some of the 'pain' of this latter item, any modified sources are also included in vc7sln01.zip, in vc7chg01.zip. But you should first try the build WITHOUT these modified files. Sometimes, hopefully by the time you are using this, the relevant fixes have made it into the particular CSV/SVN development source. All that should be required is to unpack vc7sln01.zip into your chosen 'work' folder, allowing an overwrite of the existing project files.
As well as the modified source zip file, unpacking the vc7sln01.zip will also add a vc7cfg01.zip to the 'work' folder. This must also be unpacked, using the folder names ... Load fgfs\fgfs.sln file in MSVC7, select either 'Debug' or 'Release' configuration and build ... Sometimes many other 'configurations' are listed, BUT ONLY 'Debug' and 'Release' have been fully tested. Using any other configuration, and you are on your own ;=))
It is a GOOD IDEA to CHECK Menu -> Build -> Configuration Manager to ENSURE the Active Solution Configuration: Debug or Release, that each project has the correct 'Configuration' selected. For Debug, each should read Debug, except perhaps zlib, which should read 'LIB Debug'. Likewise when Release is selected, they should all be Release, except perhaps zlib, which should read 'LIB Release'. I may have corrected this somewhat by the time you receive the solution set.
For example, in building from a previous to develop the next, I have found that sometimes I have to delete files, and/or tp add files, and in one case, changed source folder (ac3d to ac) in the OSG ... this is particularly in OS, simgear and flightgear which are very active projects ... these type of ongoing changes are inevitable ... it would be nice if I could automate a way, but that would be quite involved, perhaps impossible ;=() It would involve writing a unix/linux type makefile interpreter, but, for example, OSG used GNUmakefile, while simgear and flightgear use makefile.am ...
This build, with MSVC7, is using the runtime library 'Multithreaded DLL' (/MD), and 'Multithreaded Debug DLL' (/MDd) respectively! When you create a new project in MSVC7 this is the default, but many prerequisite projects use /MT-/MTd, perhaps some with /ML-/MLd. It is VERY IMPORTANT that the runtime of the prerequisites and the final FlightGear build all use the SAME runtime, or else there will be 'conflicts' in the LINK.
Also, as previous, I had to make some minor code changes in Router\alc.cpp ...
1. I had to un-define HAVE_VISTA_HEADERS, since I don't have these installed ...
#ifndef __MINGW32__ #define _CRT_SECURE_NO_DEPRECATE // get rid of sprintf security warnings on VS2005 #undef HAVE_VISTA_HEADERS #endif
2. And a little later, change -
#ifndef __MINGW32__
to#if !(defined (__MINGW32__) || defined (_MSC_VER))
This second change is NOT required, if you have the file <atlconv.h> available, and is thus NOT included in the change ZIP. I have posted this to the OpenAL development board in the hope they will eventually change it in CVS ...
When the final link is successful, run UPD.BAT - this can be run with a 'D' parameter - like> upd d to also copy the debug versions to the 'bin' folder. In the 'bin' folder there is also an OpenAL folder. In this folder is another UPD.BAT, to copy the sound DLL shared libraries to your system folder, hard coded as C:\WINDOWS\System32. If your windows is installed in other than this folder, then this upd.bat will need to be adjusted. If you already have these sound DLL shared library files installed, then it will refuse to do anything until these are deleted ...
Now you are ready to run flightgear. There is a number of batch files, in rfgbats02.zip, which expands to the 'bin/bats' folder, to provide some initial scenarios. rfg.bat is the simplest with a content of :-
cd .. FlightGear --fg-root=..\data --fog-disable --timeofday=noon --prop:/sim/rendering/fps-display=true cd bats
You will note a number have 'noai' in their name. This is because I get a CRASH after about 5-10 minutes if I do not disable AI planes, but you might have more luck ;=)) You will note each uses ..\data as the path to the base data and scenery. If you did not copy the base data during setupfg then this will have to be adjusted to where you have installed at least the base data, and/or additional scenery ...
Linking... Build log was saved at "file://g:\FG\MSVC7\FlightGear\Release\BuildLog.htm" FlightGear - 0 error(s), 3152 warning(s) ---------------------- Done ---------------------- Build: 24 succeeded, 0 failed, 0 skipped
Of course, in the above link, I am IGNORING the 3152 warnings!!! Hopefully NOT at my peril ;=)) Maybe one of them caused the Release version of FlightGear.exe to CRASH on loading??? What a LOT OF EFFORT maybe for naught ;=().
Debugging is never particularly easy. It requires considerable patience, a little understanding of Intel machine code, and some DLL setup steps. Normally the MSVC built-in debugger can be started from Menu -> Debug -> Start (F5), while on the Debug configuration, but in this case, FlightGear depends on a number of DLL Shared Libraries, thus without setup you will get dialogs like -
As it states, it is unable to locate a component, in this case osgd.dll. I have written an upddbg.bat batch file, to copy the necessary 'components' into the SAME folder as FlightGear.EXE - namely COPY osgd.dll, osgDBd.dll, osgdb_acd.dll, osgdb_rgbd.dll, osgUtild.dll, OpenThreadsWin32d.dll, and pthreadVC2.dll TO the folder FlightGear/Debug/., then the debug load should proceed.
Next is to decide where to set a break point. The actual OS entry point is in bootstrap.cxx, at -
// Main entry point; catch any exceptions that have made it this far. int main ( int argc, char **argv ) {
But, after setting up an exception block, it calls fgMainInit(argc,argv), which is in main.cxx. But at the end of this function is passes off control to fgOSMainLoop(), in fg_os.cxx, which in turn calls glutMainLoop(), from which is NEVER returns!
Control returns regularly to fgIdleFunction(), back in main.cxx, where it tumbles down an giant if based on the idle_state variable, until it reaches the value of 1000, when control is again shifted to the fgMainLoop() callback, in main.cxx, which does the updates for each time loop, including determining the frame rate. I have sometimes put a trap in each of the idle_state if actions to trace a particular difficult 'startup' bug.
However, in this case, the last message output to the console was the message in this exception block, but setting a break point here is too late - the exception has fired, and I want to see what caused the exception. To learn more, I run FG with the command line -
FlightGear --fg-root=..\data --log-level=debug
I even have a batch file, rfglogdbg.bat, in bin/bats to redirect the console output to a file, because it can be quite long, and may scroll off the console screen. Running this batch file, and viewing templog2.txt at the end shows me that the last four console outputs are -
press-cockpit-button release-cockpit-button Initializing scenery subsystem Unknown exception in the main loop. Aborting...
This mean I can set a break point at the point where 'Initializing scenery subsystem' is output. One of the beauties of using a single solution file, is that the search for this phrase will be across the entire solution. So a 'find' shows -
Find all "Initializing scenery subsystem", Subfolders, Find Results 1, Current Project: ..\FlightGear\FlightGear.vcproj, "*.*" G:\FG\MSVC7\FlightGear\src\Scenery\scenery.cxx(71): SG_LOG( SG_TERRAIN, SG_INFO, "Initializing scenery subsystem"); Total found: 1 Matching files: 1 Total files searched: 815
So I set a debug trap (a break point) in this code -
// Scenery Management system FGScenery::FGScenery() : center(0, 0, 0) { SG_LOG( SG_TERRAIN, SG_INFO, "Initializing scenery subsystem" ); }
This should happen before the exception, and I can carefully trace onwards from here. The debug load takes a LONG TIME. This is partly because all memory is allocated, set to a pattern, with a trailer to watch for over runs, and of course all the symbols need to be loaded, so the 'reading airport & navigation data' load step seems to take forever ...
Also, while the modern debugger is quite good, always remember to SAVE any important work before starting the debugger - if something goes wrong with the debugging process rarely the machine can be FROZEN! And I usually exit most other applications to give the most memory to the debugger ...
But as expected, I reach the trap in FGScenery initialization. Tracing onwards, I find the exception occurs in -
globals->get_scenery()->init();
so I carefully trace into here ... then I find it is in -
scene_graph->addChild( terrain_branch.get() );
I find the exception occurs in the code in Group.cpp -
if (child->getNumChildrenWithOccluderNodes()>0 || dynamic_cast<osg::OccluderNode*>(child)) {
The TRACE STACK, one instruction BEFORE the exception shows -
msvcr71d.dll!FindCompleteObject(void * * inptr=0x07ea89e8) + 0x17 msvcr71d.dll!__RTDynamicCast(void * inptr=0x07ea89e8, long VfDelta=0, void * SrcType=0x1022d808, void *TargetType=0x1022e374, int isReference=0) + 0x43 osgd.dll!osg::Group::insertChild(unsigned int index=0, osg::Node * child=0x07ea89e8) Line 135 + 0x23 osgd.dll!osg::Group::addChild(osg::Node * child=0x07ea89e8) Line 70 C++ FlightGear.exe!FGScenery::init() Line 88 + 0x30 FlightGear.exe!fgIdleFunction() Line 730 + 0x24 FlightGear.exe!GLUTidle() Line 122 + 0x11 FlightGear.exe!glutMainLoop() Line 1510 + 0x8 FlightGear.exe!fgOSMainLoop() Line 155 FlightGear.exe!fgMainInit(int argc=2, char * * argv=0x018e60c0) Line 1034 FlightGear.exe!main(int argc=2, char * * argv=0x018e60c0) Line 209 + 0xd
The errant code - well not really - but the code that causes the exception -
FindCompleteObject: 00357810 push ebp 00357811 mov ebp,esp 00357813 sub esp,8 00357816 mov eax,dword ptr [inptr] 00357819 mov ecx,dword ptr [eax] 0035781B mov edx,dword ptr [ecx-4] 0035781E mov dword ptr [pCompleteLocator],edx 00357821 mov eax,dword ptr [pCompleteLocator] 00357824 mov ecx,dword ptr [inptr] 00357827 sub ecx,dword ptr [eax+4]
At that moment, EAX, loaded from [pCompleteLocator], which was set from EDX being loaded from [inptr] pointer - 4, is ZERO, and the EXCEPTION is to load ECX from [EAX+4]. As I suspected, the many, many WARNINGS about dynamic_cast have come back to bite me ;=()
The WARNINGS were ALL of the FORM -
g:\FG\MSVC7\OpenSceneGraph\include\osg\Switch(36) : warning C4541: 'dynamic_cast' used on polymorphic type 'osg::Object' with /GR-; unpredictable behavior may result
WOW, this turned out to be AS SIMPLE AS switching 'Enabling Run-Time Type Info' ( FlightGear -> Property Pages -> Configuration Properties -> C/C++ -> Language ) to 'Yes' (/GR). I note this is the DEFAULT in MSVC8!
Setting it to YES (/GR) in the Debug configuration REMOVED all 'warning C4541' from the build, but maybe I have to apply it to ALL projects, both configurations, at least those of OSG, or including OSG, which is where they all emanate from.
HA! The projects 'Core osg', 'Core osgBD', 'Core osgUtil', 'OpenThreads', 'osgPlugin ac3d', and 'osgPlugin rgb' ALREADY HAVE THIS OPTION SET TO YES (/GR)!!! This should mean only changing simgear and flightgear to YES also ... Re-compiling and linking the Release GETS ME FLYING ;=))
For some idiot reason the keyboard does not work, but the mouse and joystick do, so I take the default Cessna off, slewing left across the grass, and successfully get it into the AIR without hitting anything. ;=))
THE MORAL OF THE STORY -
DO NOT BLITHELY IGNORE _ALL_ COMPILER WARNINGS ;=))
Must look into why the English keyboard FAILED to register in PLIB, but the CRASH SEEMS GONE, so this was a quite successful initial debug session. Of course, I also re-build the Debug version to make sure my VERY STRANGE MSVC7 failure has not returned, and ready to debug why the KEYBOARD FAILS ...
But in general NOW QUITE HAPPY ;=))
1. fgvc7rt01.zip - Set of WIN32 runtime binaries - MD5 = aeb0442bb17e1e46673ad22adcbd6c24 - contents
Length Size Ratio Date Time Name ------ ----- ----- ---- ---- ---- 3588096 1440235 60% 25/04/2007 17:50 bin\FlightGear.exe 28672 6560 78% 23/04/2007 19:29 bin\OpenThreadsWin32.dll 1286144 444847 66% 23/04/2007 19:36 bin\osg.dll 253952 86614 66% 23/04/2007 19:40 bin\osgDB.dll 122880 44161 65% 23/04/2007 19:43 bin\osgdb_ac.dll 18432 7142 62% 23/04/2007 19:43 bin\osgdb_rgb.dll 782336 291433 63% 23/04/2007 19:39 bin\osgUtil.dll 52736 21440 60% 24/04/2007 13:26 bin\pthreadVC2.dll ------- ------- --- ------- 6133248 2342432 62% 8
2. vc7sln01.zip - Set of MSVC7 build files - MD5 = 96ee6a4869e85d5a331a5cf2aace34eb - contents
Length Size Ratio Date Time Name ------ ----- ----- ---- ---- ---- 3690 1715 54% 26/04/2007 15:02 README.fgfs.txt 55790 3768 94% 23/04/2007 18:25 fgfs\fgfs.sln 3881 962 76% 24/04/2007 13:15 OpenAL\OpenAL-Windows\Alc\ALc.vcproj 3881 962 76% 24/04/2007 13:15 OpenAL\OpenAL-Windows\Alu\ALu.vcproj 169483 4533 98% 22/04/2007 13:38 OpenSceneGraph\VisualStudio\osg\osg.vcproj 34816 2114 94% 22/04/2007 13:38 OpenSceneGraph\VisualStudio\osgDB\osgDB.vcproj 50582 2432 96% 22/04/2007 13:38 OpenSceneGraph\VisualStudio\osgUtil\osgUtil.vcproj 262292 9066 97% 25/04/2007 17:34 FlightGear\FlightGear.vcproj 12097 1432 89% 24/04/2007 13:15 OpenAL\OpenAL-Windows\OpenAL32\OpenAL32.vcproj 13134 1595 88% 22/04/2007 13:38 OpenThreads\win32_src\OpenThreads.vcproj 7545 1294 83% 24/04/2007 13:15 OpenAL\OpenAL-Windows\Router\Router.vcproj 69745 2752 97% 25/04/2007 17:34 SimGear\source\SimGear.vcproj 5005 974 81% 24/04/2007 13:15 PLIB\src\fnt\fnt.vcproj 16894 1317 93% 24/04/2007 13:15 freeglut\freeglut_static.vcproj 6910 994 86% 24/04/2007 13:15 PLIB\src\js\js.vcproj 7138 1070 86% 24/04/2007 13:15 PLIB\src\net\net.vcproj 12560 1662 87% 22/04/2007 13:38 OpenSceneGraph\VisualStudio\osgPlugins\ac3d\ac3d.vcproj 10012 1585 85% 22/04/2007 13:38 OpenSceneGraph\VisualStudio\osgPlugins\rgb\rgb.vcproj 5753 1243 79% 22/04/2007 13:38 pthreads\pthread.vcproj 11146 1142 90% 24/04/2007 13:15 PLIB\src\puAux\puAux.vcproj 16416 1268 93% 24/04/2007 13:15 PLIB\src\pui\pui.vcproj 5939 978 84% 24/04/2007 13:15 PLIB\src\sg\sg.vcproj 45323 1653 97% 24/04/2007 13:15 PLIB\src\ssg\ssg.vcproj 6019 970 84% 24/04/2007 13:15 PLIB\src\util\ul.vcproj 45185 2378 95% 22/04/2007 13:38 zlib-1.2.3\projects\visualc6\zlib.vcproj 12834 1494 89% 24/04/2007 12:00 OpenAL\alut\admin\VisualStudio6\alut\alut.vcproj 4073 4073 0% 20/04/2007 15:27 rfgbats02.zip 3174 3174 0% 22/04/2007 13:59 vc7cfg01.zip 13304 13304 0% 22/04/2007 13:54 vc7chg01.zip 4226 1426 67% 21/04/2007 11:20 setupfg.bat 1568 583 63% 19/03/2007 15:13 upd.bat 2084 607 71% 25/04/2007 11:26 upddbg.bat 2170 523 76% 26/04/2007 15:07 zipall.bat 47 45 5% 26/04/2007 14:16 zipbats.bat 46 45 3% 26/04/2007 14:14 zipcfg.bat 46 45 3% 26/04/2007 14:51 zipchg.bat 42 42 0% 26/04/2007 14:06 ziprt.bat 46 45 3% 26/04/2007 14:04 zipsln.bat 100 68 32% 26/04/2007 14:14 cfglist.txt 38 38 0% 26/04/2007 14:52 chglist.txt 892 294 68% 26/04/2007 14:01 slnlist.txt ------- ------- --- ------- 925926 75665 92% 41
Or you can go directly to the zip download page on the server that houses these zips ... or to my specific download page ... (MD5 (rfgbats02.zip) = d56c665199a141a5cb80e024288f7414) is a set of updated (2007-04-20) batch files, for the bin/bats folder.
This is a somewhat abbreviated version ;=))
If this is your first run, you may have to 'Unblock' the net communications -
This will depend on your security settings, although, unless you have specifically enables some 'net' actions, flightgear does not really use this channel. I think this dialog occurs when 'socket' library is initialized in PLIB, and not only when a socket is specifically opened.
As some examples of the command line options, you could also download the fgvc8rt04.zip and extract all the BATCH files into the bin/bats folder, or directly download some updated (20070420) batch files, (MD5 (rfgbats02.zip) = d56c665199a141a5cb80e024288f7414), and extract them , using the folder names ...
Since this is NOT an automated build system, and many of the projects are very active, the VCPROJ files can become out-of-date very quickly. This is usually evidenced by the fact that there are 'missing files' during the build, or 'unresolved externals' during the final link. This usually means that the source file list, for that particular project, has changed since the build system was last updated.
Aside from the quite drastic cvs 'backtracking' - that is do a cvs update using an Apr 21, 2007 date - not tried nor recommended - the only thing that can be done about the 'missing files' is to delete them from the particular project, and continue with the build. The 'unresolved externals' usually means that some NEW file, or files, has/have been added, and now that file, or files, must be added to particular project of the build system.
NOTE: These particular fixes have been done, but are left here as some 'samples' of the type of 'fixes' that are sometimes required.
Example 1: missing file
encoder.cxx c1xx : fatal error C1083: Cannot open source file: '.\src\Instrumentation\encoder.cxx': No such file or directory
I just deleted this files from the FlightGear project, and continued the build.
Example 2: unresolved external
Linking... altimeter.obj : error LNK2019: unresolved external symbol "public: __thiscall FGAtmoCache::~FGAtmoCache(void)" (??1FGAtmoCache@@QAE@XZ) referenced in function "public: __thiscall FGAltimeter::~FGAltimeter(void)" (??1FGAltimeter@@QAE@XZ)
How to FIND the missing file? Using grep, or a grep-like tool you can search for the source (in *.c, *.cxx, *.cpp files) that contains 'FGAtmoCache'. In this case it showed up in FlightGear/src/Environment/atmosphere.cxx, which must then be added to the FlightGear project.
Example 3: unresolved external
Linking... NasalSys.obj : error LNK2019: unresolved external symbol _naInit_utf8 referenced in function "public: virtual void __thiscall FGNasalSys::init(void)" (?init@FGNasalSys@@UAEXXZ)
Again, searching the SimGear source for 'naInit_utf8', it is found in SimGear/simgear/nasal/utf8lib.c, thus this file is added to the SimGear project.
Example 4: unresolved external
Linking... NasalSys.obj : error LNK2019: unresolved external symbol _naInit_thread referenced in function "public: virtual void __thiscall FGNasalSys::init(void)" (?init@FGNasalSys@@UAEXXZ)
Searching the SimGear source this time, for ' naInit_thread', it is found in SimGear/simgear/nasal/threadlib.c, thus this file is added to the SimGear project. And that does the trick.
Notice, I tend to work on the missing items 1 by 1, since sometimes the inclusion of a new file may require other new files to be added. Also I try to add it specifically to the appropriate 'project' ... you can verify, at least for simgear and flightgear the full set of source files, by carefully reading all the makefile.am files ...
2007-04-23 UGH! While I was able to do the complete Release compile, MSVC7 failed (STALLED) on the Debug configuration compile. Microsoft site notes this PROBLEM with MSVC NET 2003, but provides a HOT FIX only to paying customers. My MSVC7 came through a MSDN subscription I had at the time, but I am NOT eligible for any free support calls! Further, when I ran the runtime release FlightGear EXE, it CRASHED, without warning during the load.
2007-04-24 - Of course the FAILURE is using a SINGLE solution file for the 24 projects. Separating SimGear and FlightGear out of the single solution, and compiling them SEPARATELY, in Debug, works fine. BUT THIS MASSIVELY DEFEATS THE PURPOSE OF A SINGLE SOLUTION.
In a 'single' solution, MSVC7 takes care of all the library includes in the link, by virtue of the dependency settings. But when separated out like this, you MUST include every additional library, and a PATH to that library. REAL HARD WORK. BAH!
BUT, after all that 'hard work' I decide to try MSVC7 again using my single solution, with 24 projects, AND THIS TIME IT WORKED. I have no idea what is going on here??? I now can NOT find the MS KB article again on this 'multiple project freeze', so MAYBE it was just a figment of my imagination ;=)) Return to continue ...
Happy SIM flying ...
Geoff R. McLane
date: 20070423