FlightGear MSVC6 Build - Jan, 2005

FG-MSVC6 - FG-MSVC7 - UFO - ATLAS ( 1 - 2 - 3 ) - OTHERS - Favourites - Home

A Microsoft Visual Studio Build, Versions 6 - a personal overview - in XP SP2 - here for some images

Contained below -
My Directory, Folder structure ...
PLIB Build ...
SimGear and and zlib, Build ...
AL (OpenAL) Build ...
FlightGear Build ...

If you have purchased, either directly, or through a subscription, and installed Microsoft Visual Studio 6 (MSVS), or later, and, with it, the Microsoft Visual C/C++ [msdn.microsoft.com/visualc] (Note a), here written as MSVC6,then compiling FlightGear can be fun ;=)) You have to know a bit about MSVC6, like which are its project files, especially the DSW and DSP files, and how to add paths for headers and libraries ... but all is quite easy to master ...

Of course, this overview represents my current personal 'environment', and is not meant to detract from other source README files, and documentation. Many things can be done many ways ... It is the result of several years of downloading, compiling, and running FlightGear, and many of its 'offshoots' - is that the right word? - so my chosen structure WORKS for me ...

Below are my sources and data folders, or directory structure, and then a run through each of the sources, commenting on errors, warnings, problems ... encountered, and suggested 'fixes', some reasoning, culminating in building, and running FlightGear in the IDE ...

It must be understood that this is 'living' open source, under a GPL [www.gnu.org/copyleft/gpl.html] licence, thus continues to change and evolve, almost daily. You do not have to do it this way, and perhaps other structures might even 'improve' the experience. You would just need to 'adjust' the various header include, and library include paths to accomplish the same result - a compile, link, and run of FlightGear ... This overview uses MSVC6, but naturally, many things apply to the later .NET version 7 ...

My simple approach is to start everything from a root name, like C:\FG<something>. For example, for this overview, I did the downloads to a FGCVS folder, then copied it all to a FG09 folder, where I do the compiles. which I shall simply call 'root' hereafter. Compiling in the copy keeps my CVS download from 'stopping' the next compile ... but more importantly, I can review what has been changed, where I sometimes use a lovely tool I purchased, call 'Beyond Compare', but that is further down the track .

Here is my 'root', FG09 in this instance, folder list, split into essential, and add-ins -
***[essential]***
PLIB
SimGear
FlightGear\data
FlightGear\source
AL\openal
***[add-ins...]***
TerraGear
wxWidgets
fltk-2.0.x
fgrun
fgsd
Atlas
blender

As indicated, not all the above 'sources' will be required immediately, but as you get further into FlightGear, the others will also interest you. The first five(5) are the ones needed to run FlightGear, and go FLYING soonest ... a short cut to the skies ...

I use the command line version of CVS [https://www.cvshome.org] (Note i), for the source download, because that is what most of the development board postings will use, talk about, whenever that topic is touched, but you can also use the windows GUI version, WINCVS [www.wincvs.org], which I have not yet tried ;=(( ... The first CVS down load is the most difficult, so I build batch files. The most important is one that sets the environment variable, CVSROOT, local, in that command prompt window, as follows -

C:\FGCVS>type setroot.bat
Set HOMEPATH=\FGCVS
Set CVSROOT=C:%HOMEPATH%

Copy the 2 set lines to the clipboard, and open you 'favourite' editor - I use notepad.exe for simple things like this - and save it as setroot.bat in your chosen CVS root folder. Remember, if you use notepad, to make sure you select 'All Files' in the 'type' selection, otherwise it will add the .txt extent, every time ...

You could also add them to your command prompt environment - Control Panel, Performance and Maintenance, System Properties, Advanced tab, Environment Variables... XP seems to have solved the 'out of environment memory' that bugged earlier windows releases ... but, to me, this lacks 'flexibility' ...

This setroot is invoked from each of my download batch files. Below is the contents of loadfg.bat (Note ii), which you can likewise copy to the clip board, and save as loadfg.bat in your chosen CVS download folder. You will note this loads FlightGear data and source, SimGear, and PLIB. I usually create similar batch files for each of the others, as needed, so following that is the fourth source, loadal.bat (Note iii).

After the initial CVS download, updates are a 'snap' ... In the command prompt, navigate to your CVS root folder, run setroot batch file, change into each directory, like PLIB, and run the 'simple' command -
root\PLIB> cvs up -dP
and watch the magic work. Usually, it runs quickly though the source tree, update only what has 'changed', so it is 'fast', unless the source includes some new 'big' files ... Of course, being a batch file 'fan', I put it all in a batch file, so I just type 'updfg', and it all gets done ...

It is also possible to download the various tar.gz, and/or sometimes, the zip, 'sources', which is the only choice if no CVS resource access is offered ... While zip is natively handled in XP, you will need a tool, or tools, for tar.gz, for the zlib-1.1.4.tar.gz, kindly included in the SimGear CVS download ... WinZip [www.winzip.com] (Note iv) is a well known choice, another is Stuffit [www.stuffit.com] (Note v), both 'cost' clams ... I found a WIN32 gzip.exe, on the web, but no such luck with a tar.exe WIN32 binary ;=(( ...

Note: By the time you read this, the version numbers, or CVS instructions, may have changed. You should go to each of the source sites directly, and check out the CURRENT CVS instructions ... and update the batch files ...

Assuming you have the first set of sources on your local disk system, now to do the individual builds ...

PLIB Build

Open MSVC, click File, Open Workspace ... navigate to plib.dsw, in root\PLIB folder .. and open ... you could build each library separately, or can change the active project to plib ... select, and right click on plib files, then select Set As Active Project ... You could just click Build, or Build All, but it is a good idea to get familiar which what type of static libraries you are building ... You can choose several options, but you MUST be consistent with each of the sources ...

You can open Project, Settings ..., and then select each project in turn, (except plib files ;=(() and check out, at least the following :-
1. Under the C/C++ tab, select the Code Generation category, and ensure 'Debug Multithreaded' is the selected as the 'use run-time library:' option, and just 'Multithreaded' if Win32 Release configuration is selected.
2. Under the category of Precompiled Header, ensure 'Not using precompiled headers' is selected. This is not usually the default in PLIB, so I select 'All Configuration', and check the Not ...
3. Under 'Preprocessor', check the 'Additional include directories'. You will need to get familiar with setting this in many of the sources ...

You are now ready for F7 (Build) ... I generally find CVS of PLIB to compiles well ... it trundles through each of the static libraries, and copies them, and their header(s) to the root\PLIB folder, a nice touch ... A quite common warning is C4305, truncation of double to float. The MSVC6 compiler defaults to using double precision throughout the compile, so naturally assumes a truncation of a double to a float may not be what the programmer intended, hence the warning ;=)) PLIB also names the DEBUG libraries using an '_d' in the name, which is quite a convenient convention.

When done, you should have a bunch of headers, and static libraries in root\PLIB, that were not there before ... this is success ... moving on ...

SimGear and zlib Build

If you are into 'brevity', then here is a readme.msvc.txt, that 'summarises' the following ...

There are two initial steps I do before opening MSVC6
1. Extract/Expand/Decompress the zlib-1.1.4.tar.gz found in root\SimGear\source\src-libs, inplace, as it were ... This will create a zlib-1.1.4 source folder.
2. Copy, or rename, the file simgear_config.h.vc5 in source\simgear to simgear_config.h. Some attempts have been made to 'automate' this step, but, it is something you should get used to ... it happens a bit like this in several sources ...

On loading the SimGear.dsw project, you may be asked for the path to mklib.dsp. This is now not used, so you can click cancel, but you need to navigate to zlib.dsp, it is in root\SimGear\source\src-libs ... select it, and click ok, so that you end up with two projects, SimGear and Zlib ... They can be done in any order - they are not inter-dependant ...

One of the more, sometimes frustrating, actions is getting the INCLUDE paths correct. Partly from the fact that altering the projects settings, category Preprocessor, Additional Include directories: usually forces a re-build of all previous source files ... hint: Selecting the 'troublesome' file, and compiling it alone - Ctrl+F7 - until you get the paths right ... eases the way a little ...

Another hint is to initially 'ignore' all warnings on the first compile ... you can make time later to get into these ... I simply do a second F7 (Build), and then start looking at the 'errors' first ... using F4 positions you in the 'offending' source, at the 'error' line ... when you get the static WIN32 SimGear.lib built, then you can do a Clean, and this time check out the warnings, and see what you think ;=))

While the following describes 'problems' and 'MSVC6 fixes' in this source, they may have been 'fixed', moved, or changed, by the time you read this. They are intended to represent 'typical' cross platform source development 'hiccups' ... Remember, if the programmer did his/her fantastic job in unix, or a 'unix' emulation environment (cygwin [www.cygwin.com]or mingw32 [www.mingw.org]), or even a later version of MSVC, here, I lump all these together as a 'unix environment', and here 'unix' means *nix, then it compiles 'perfectly' for them, and they may have worked hard to get it that way ... they may not 'understand' what difficulty you are rabbiting on about ...

Some math definitions, seemingly always available in the 'unix environment', give some grief in our MSVC6 environment. For example, I had to add -
#ifndef M_LN2
#define M_LN2 0.69314718055994530942
#endif // #ifndef M_LN2

to fastmath.cxx ... not sure now where I got the value, but I certainly hope it is right ...

Two others are M_PI, and M_E. If you ever download and install the cygwin or mingw32 environment(s), then they will drop in some additional header file, and these may become 'visible' ... TaxiDraw and TerraGear sources, among others, give the following definition ... which I use ...

#ifndef M_PI
#define M_PI 3.14159265358979323846 /* pi */
#endif /* M_PI */

#ifndef M_E
#define M_E 2.7182818284590452354
#endif /* M_E */

which I drop into the top of mathlib.c, after all other includes ... Take care when dropping such definitions into a header file *.h, *.hpp, *.hxx. As you may know MSVC6 does not fully update its 'External Dependencies' until you have successfully compile the project, thus you often have to explicitly 'Save' (Ctrl+S) the modified header, before doing the build again (F7) ... it is very 'scary' to see the same error appear, that you thought you had just fixed ;=((

In the source search tool I use a custom find in set of '*.c;*.h;*.cpp;*.hpp;*.cxx;*.hxx', since none of the canned set quite match this specification ...

Another common error, at least in MSVC6, is error C2374: 'i' : redefinition; multiple initialisation, although I understand this has been solved in version 7, MS .Net initiative. An example from mat.cxx -
for (unsigned int i = 0; i < textures.size(); i++) {
string tname = textures[i]->getStringValue();
... } ...
for (unsigned int i = 0; i < object_group_nodes.size(); i++)
object_groups.push_back(new SGMatModelGroup(object_group_nodes[i]));

Simply, version 6 did not consider a for(;;){ } statement as a new, separate context. It is an annoying item, since several of the main developers use it frequently. Understand that all function variables, no matter in which 'context' they appear, must be put in the same stack frame, in the prologue of the function, by the compiler, leads me to 'like' declaring all local variables at the top of the function ... it also makes the compilers life easier, so my 'solution' to the above is as follows -

unsigned int i;
for (i = 0; i < textures.size(); i++) {
string tname = textures[i]->getStringValue();
... } ...
for (i = 0; i < object_group_nodes.size(); i++)
object_groups.push_back(new SGMatModelGroup(object_group_nodes[i]));

But there are always many ways to skin a cat, not that I would ever 'skin a cat'! You could just put context braces around the 2nd 'for' loop, like -

{
for (unsigned int i = 0; i < object_group_nodes.size(); i++)
object_groups.push_back(new SGMatModelGroup(object_group_nodes[i]));
}

But, while this quietens the compiler, it adds complexity for the next human reader, so I only use this in certain cases ... another would be to change the 2nd to ii, if it is not used too frequently in the loop function, but that 'feels' like you are changing the code, which you do NOT want to do ...

The use of std namespace templates sometimes leads to error C2653: 'map<class std:: ...>' is not a class or namespace name, when clearly it IS. This error will then often lead to multiple C2065: undeclared identifier, and C2146: syntax. error. These all come from the compiler not finding a definition for 'map'. Why, it is in std?

As you would see clearly in the text of the error message, every std template starts with std::, so a simple 'fix' would be to add that in front of 'map' ... thus this fix has to be done to each 'map' declaration ... depends on number of 'changes' ... You must check that the 'declaration', as follows, has been added -
using namespace std;
at, or near the top of the file, but as you will learn, in this beautiful, cross platform world of FlightGear, there is a 'preferred' way to do this ... have a look in the file simgear\compiler.h, in the _MSC_VER section, to understand more ... but after you have found -
#include <map>, and
SG_USING_STD(map);

by browsing through the headers included, then we hit another annoying bug in MSVC6, and again I think it has been fixed in version 7, and that is the compiler will not 'recognise' the iterator, if it is all done in one line ;=(( This can be 'easily' fixed, by adding 'std::' to the declartion ... that is std::map<... like ... Another, more complicated, perhaps, way would be to use a 'typedef' statement, then use that type-defined variable ...

An example from modellib.cxx. It contains/contained the line -

map<string, ssgBase *>::iterator it = _table.begin();

Remember, this can often be 'fixed' by (a) just adding 'std::' in front of 'map' ... (b) adding the line 'using namespace std;', near the top ... (c) maybe consider upgrading your compiler ... or (d) as a last desperate attempt, 'modify' the code, with care not to break it, to a coding form the version 6 of the compiler will be happy with ... this is not necessarily recommended, but here are some 'samples' -

typedef map<string, ssgBase *> SSG_MAP;
SSG_MAP::iterator it = _table.begin();

Annoying for sure, since it seems just about every other platform compiler has no problems with the original single line, and it is simply not 'fair' to ask the majority of a community, to adopt such a separation convention, so just get used to doing it, or use another compiler, or buy and upgrade your compiler, if it is available ;=))

And this same bug exists for the const_iterator, so in personality.cxx I defined these two -
typedef map<SGPersonalityBranch::Key,double> KEYD_MAP;
typedef map<SGPersonalityBranch::Key,int> KEYI_MAP;

Then I replace lines like -
//map<Key,double>::const_iterator it = _doubleValues.find( Key( anim, var_id, var_num ) ); with
KEYD_MAP::const_iterator it = _doubleValues.find( Key( anim, var_id, var_num ) );
and
//map<Key,int>::const_iterator it = _intValues.find( Key( anim, var_id, var_num ) ); with
KEYI_MAP::const_iterator it = _intValues.find( Key( anim, var_id, var_num ) );

One annoying warning is C4786: '?_blah@blah@blah@@2@...' ... truncated to 256, since the actual warning is so many lines long, and none of them are in the file where the 'warning' starts ... It does give you insight as to how the compiler generates unique namespace, class, function names. It uses lots of '?', and '@' characters, but if read carefully you can sort of 'see' the intent to ensure global uniqueness. It is dowsed in <simgear/compiler.h>, by -
#pragma warning( disable:4786 ), but if the template/class was declared in an earlier header, then it was emitted 'before' this 'turn-off' was read, so it remains ...

An example is in SkyArchive.cpp in Lib_sgclouds3d, where <simgear/compiler.h> is/was not included. Here I could drop the simple line -
#include <simgear/compiler.h>
in front of the following includes ...
#include <plib/ul.h>
#include "SkyArchive.hpp"

As stated, the main problem with the warning, it is more difficult that usual to get to source files with this warning using F4, which 'works' perfectly for just about every other warning, or error. While the source file name is given immediately before the giant warning, it is not 'clickable', 'selectable' ... maybe this has been addressed in later versions ...

So finding and opening the source is a bit of a task ... you sort of have to 'know' SkyArchive.cpp is in the Lib_sgclouds3d, and expand that tree, to open it ... of course, you can work it out if you do a -
root\SimGear> dir SkyArchive.cpp /s ...

This shows you that it resides in the folder source\simgear\scene\sky\clouds3d ... and there is a Lib_sgclouds3d, so this is a good place to start ... From the brief README.MSVC file, you can see the DSP file has been created using a script - which does not seem to be part of the source, although the am2dsp.cfg is given - that is, it is not with MSVC. Since this is a single static library, it would be better if the generated DSP file put all the source files under SimGear - Source Files, with no sub-directories given ... but I do not have the pl script to fix, or suggest a fix, for this ...

As a matter of interest, I usually right click on SimGear files, and add compiler.h and constants.h to the file list, so I can get to them with a single click ;=)) They are two very useful files ...

Another of the 'iterator' compiler bug is in obj.cxx. Adding -
typedef list<Leaf>  LIST_LEAF;
allowed me to quickly do -
       //list<Leaf>::iterator li = leaf_list.begin();
       LIST_LEAF::iterator li = leaf_list.begin();

As stated, this can continue to occur, even if the above examples have been 'adjusted', since it 'works' in other 'sensible' compiler ;=((

At this time, another error C2374: 'i' : redefinition; multiple initialisation, occurs in vasi.hxx. In this instance the 'MSVC6 fix' is to delete the 'int' ... like -
           //for ( int i = 0; i < 18; ++i ) {
           for ( i = 0; i < 18; ++i ) {
and
           //for ( int i = 18; i < 36; ++i ) {
           for ( i = 18; i < 36; ++i ) {

As stated, this is to make you aware that your compiler 'of choice' - tongue-in-cheek - is not perfect. You now know there are other compiler choices that do NOT have this problems, so in all cross platform efforts, you have to get used to this one ;=(( I, personally, will try to continue 'testing', read 'maybe', with my trusty MSVC6 ... it does what is requires, in a great IDE GUI environment, with lots of easily addressed 'features' ... (I now mainly compile using MSVC7 .NET 2003)

Perhaps another 'bug' in MSVC6 is error C2248: cannot access protected. An example is in texture.cxx. In this case the 'MSVC6 fix' is to move the 'protected:' label to after the structure, and put 'public:' in front of the structure. Again, since this does not cause a problem in other compilers, do not expect it to be fixed the next time you update from CVS ;=(( We, using MSVC6, are a 'minority', and must be prepared to adjust the source each time ... but you get used to it ... and the final FlightGear experience of 'virtual flying' is worth it, IMHO ...

The 'iterator' bug, error C2653: popped up again in subsystem_mgr.cxx, but it was a simple job to drop in -
typedef map<string,SGSubsystem *> MAPS_SGSP;
then provide the 'MSVC6 fix' of -
   // map<string,SGSubsystem *>::iterator s =_subsystem_map.find(name);
   MAPS_SGSP::iterator s =_subsystem_map.find(name);

And after this 'change' I was pleased to see the wonderful lines ;=))

Creating library...
SimGear.lib - 0 error(s), 0 warning(s)

Of course, the zero (0), warning only applies to the last part of the compile. If I do a Rebuild All, the results are a little different -
SimGear.lib - 0 error(s), 25 warning(s)

While some warnings look serious, like say -
warning C4715: 'logbuf::overflow' : not all control paths return a value - eek,
but looking at logstream.hxx should convince you that it does what the programmer intended, and the compiler is just being noisy. In some sources, you will come across a comment line like -
  return; // just to keep the compiler happy

And a C4018: ... sign/unsigned mismatch, is here and there ... like the lines -
       unsigned int i, hash = 5831;
       for(i=0; i<r.ref.ptr.str->len; i++)
from hash.c. MSVC6 must, perhaps errantly, sees the defined ->len property as an int, and a quick squint at nasal.h indicates perhaps it should, but such warnings can be 'quietened' by putting an over-ride, like i < (unsigned int)r.ref.ptr.str->len ... but, usually it is not worth the effort, unless you really feel determined to track down, and eliminate every warning ...

I have already mentioned C4244: double to float, possible loss warning, and there is the related C4761: integral size mismatch ... and there are a few C4101: ... unreferenced local variable ... I usually ignore these. They only, perhaps fractionally bloat the stack usage ... But it is quite common in the frenzy of development. As a programmer, you have worked hard to get a function to work as expected, desired, tried a few things before you got it right ... it is a bit much to ask that exhausted programmer to now go back and do more tidying up than is really necessary ;=))

Warning C4800: 'int' : forcing to bool, is due to the choices made by the respective compiler developers. In most compilers 'bool' is defined as a byte (8-bits), while an 'int' is defined as the current size of an Intel, or equivalent cpu, register, namely 32-bits. It seems to me the MSVC6 compiler is complaining that before it returns the EAX register value as an 'int', it must mask off the upper 24-bits, to just return a 'bool' value. Why they add the words '(performance warning)' is beyond me. The fact that such register masking is one of the faster instructions, so it can hardly have any effect on 'performance' seems to have escaped the attention of the MSVC6 team ... ;=((

There may be other warning not mentioned here ... report them 'quietly' to the development board, if you have any doubt ... or turn down the 'warning' level of the compiler ...

SimGear is done ... have both a Debug and a Release configuration available ... moving on ...

Zlib Build

It is time to select Zlib files, right click, and set it as the Active Project ... if you have already done a check of the Project Settings ... then give F7 (Build) a try ... I have mostly found zlib a breeeze ;=)) I may have started compiling the Debug version, then, it may be now that I will go back and compile the Release version ... When successfully completed a simple -

root\SimGear>dir *.lib /s
should yield four static libraries, like -
Directory of root\SimGear\source\Debug
08/01/2005 05:20 PM       15,997,658 SimGear.lib
Directory of root\SimGear\source\Release
08/01/2005 06:21 PM        4,513,578 SimGear.lib
Directory of root\SimGear\source\src-libs\zlib-1.1.4\Debug
08/01/2005 06:29 PM          184,586 zlib.lib
Directory of root\SimGear\source\src-libs\zlib-1.1.4\Release
08/01/2005 06:29 PM           88,214 zlib.lib
    Total Files Listed:
              4 File(s)    20,784,036 bytes

In our MSVC6 IDE environment, they, these static WIN32 libraries, can now be considered 'installed', but you will read, in make files and on the development board a LOT about 'installation' of libraries ... Yes, you could copy them to a common place, a place where your LIB environment variables points, but that has advantages, and disadvantages ... for me, the main disadvantage, is how to separate the debug from the release version, since they have the same name.

You can give then different names, like PLIB has chosen to do, but that is more effort in the IDE ... Why not leave them exactly where they were created? ... It makes it easier if you have to come back later for some modification ... there is no 'extra' step after the compile and link ...

SimGear and zlib done ... moving on ...

AL(openAL) Build

When you open an existing project, and navigate to AL\openal\win folder, and load OpenAL.dsw workplace, you will see it consists of 6 projects ... there is no 'combined' build, like there is in PLIB, SimGear ... so you could set each as active, and build each ... or, like me, you can choose Build, Batch Build, check them all, and build all ... simple ...

But before you start, make sure you check the Project Settings ... especially Code Generation. Use a consistent selection - As mentioned I choose Debug Mutithreaded for Win32 Debug, and Multithreaded for Win32 Release ... This choice will severely 'bite' you later, when you are getting towards the end ... if you do not take care now ...

This batch build process should produce -
root\AL>dir *.lib /s
Directory of root\AL\openal\win\Alc\Debug
09/01/2005 03:42 AM           85,548 ALc.lib
Directory of root\AL\openal\win\Alu\Debug
09/01/2005 03:42 AM           33,130 ALu.lib
Directory of root\AL\openal\win\ALUT\Debug
09/01/2005 03:42 AM           23,228 ALut.lib
Directory of root\AL\openal\win\OpenAL32\Debug
09/01/2005 03:42 AM           15,842 wrap_oal.lib
Directory of root\AL\openal\win\Router\Debug
09/01/2005 03:42 AM           15,518 OpenAL32.lib

and a similar set for, Release folder ...

AND Finally ...

FlightGear Build.

Take a breath. If you have come this far, you are well on the way ... If you want to read a 'brief', less than 500 words, then try readme.msvc.fg.txt, or onwards for a more 'rambling' approach ...

Just like SimGear, there is an important configuration file that must be copied, or renamed. Copy, or rename, the config.h-msvc6.in file in root\FlightGear\source\src\Include to config.h, and open it in an editor, either MSVC, or just notepad.exe ... This is where you set the version, and other things ... You will read lots about configuration, auto-configuration, etc, but none of this applies to our MSVC6 environment ...

You may note, when you load config.h, that it can be more than a year old ... That is because our MSVC6 environment has a considerable 'fixed' base, set up when you installed MSVS/MSVC. These important paths are shown in Tools, Options ... Directories tab, show directories for include and libraries. And this is easily extended on a simple project-by-project, or even a file-by-file basis. As I understand it, the 'unix environment' build starts with a configuration utilities, which reads make files, and more or less checks what has been 'installed', and varies the build according to what has been found ...

Since our main base core environment was set up on installation of MSVC6, thus we only have to have concern about how to link up with lots of other, external, headers and libraries, as needed, on the fly. We should be able to download them to any location, compile them at any location, and compile and link with them, at will ...

If you use a method that copies the end product(s) (headers and libraries), outside the 'root' folder of the source, either to a 'system' include path, or a 'global' environment include path, then you lose some control of where the 'compiler' and/or 'linker' is/are looking ... for these 'external' items ...

You already know all about checking the various Project Settings, and you have DONE at least the three (3) little checks mentioned, so, lets fly - hit F7 (Build). FlightGear is an active project, growing, changing, so it is very difficult to keep the FlightGear.dsp file in sync with the development, changing, CVS source. I can not cover all possible type of error you may encounter, but here are a few ...

My first F7 key causes a dialog to advise that a file, FGTurbine.cpp, is 'duplicated' - the actual error message 'burbles' about object files of the same name, and the project can not be built. That's easy, just remove one instance of the file from the 'file list' ... F7 again ... The next is a 'missing' header include file ...

Fatal error C1083: Cannot open include file ... you should be used to this one by now. One of the impossible task is to in any way keep the extra include directories fully correct. My first error was 'can not open plib/ul.h ... ' Ok, need an include path to PLIB, just '..\..\..\..' if you have followed my suggest directory structure, else you are on your own ... ;=))

Sometimes I try fixing what is there ... sometimes I delete it all, and start again ... my current Project Settings, C/C++ tab, category: Preprocessor, Additional Include Directories: line is :-
..\..,..\..\Simgear\source,.\src,.\src\include,..\..\SimGear\source\src-libs\zlib-1.1.4,..\..\AL\openal\include

Onwards, F7 (Build)...

It is not long before an error C2374: 'i' : redefinition pops up ... it is two for() loops in AIMgr.cxx. Here I chose to declare - int i; - just above the first for(), and delete the word 'int' from in front of the 'i' ... and onwards ... again in tower.cxx - add at top of function tower_plane_rec_list_iterator twrItr;, then delete 'tower_plane_rec_list_iterator' from in front of th 'i' ... and onwards ... again hud_rwy.cxx ... remember, I am only putting these here to make it easy to understand what you may run into on your first compile ... by that time either the source may have had a 'MSVC6 fix', or is completely changed ...

menubar.cxx produced a great error C2653, C2065, C2146 combination, which was 'solved' by -
    vector<FGBinding *> vFGBp;
   typedef map<string,vFGBp> msvFGBp;
   //map<string,vector<FGBinding*> >::iterator it;
   msvFGBp::iterator it;

I can only hope this helps you 'get-the-drift' - Remember, you have choices - upgrade to later compiler version, or download and use cygwin, mingw32 environment(s), which, from all that I have read, 'simulates' the 'unix' distribution environment - but one thing not to expect is a source fix for these ... again, mostly, a programmer has enough difficulty writing 'meaningful' code, without having to interrupt the train of thought to also get the code in 'perfect' cross-platform form, on an old model compiler ...

Just see the 'pattern' ... you will see I have sort of developed my own pseudo name made up from the definition ... maybe I could develop a macro, or code converter, that did this semi-automatically ... add -
typedef map<string,FGDialog *> msFGDp; then
  //map<string,FGDialog *>::iterator iter = _active_dialogs.begin(); becomes
   msFGDp::iterator iter = _active_dialogs.begin();
in new_gui.cxx ... and on ...

FGJSBBase.h presents an interesting error C2065: 'max' : undeclared identifier ... A quick search of the MSDN Library, which I hope you were able to install, along with MSVS ... makes the following comment -
<quote>
Microsoft-Specific:
To avoid conflicts with min and max in WINDEF.H, use _MIN and _MAX instead. These macros evaluate to _cpp_min and _cpp_max, respectively.
END Microsoft-Specific
</quote>

Quite some time ago I had built a macro to surround a selected line with #ifdef _MSC_VER ... #else ... #endif set, thus creation of the fix in this header takes 'seconds' to get ...
#ifdef _MSC_VER
   return fabs(a - b) <= eps*_MAX(fabs(a), fabs(b));
#else // !#ifdef _MSC_VER
   return fabs(a - b) <= eps*max(fabs(a), fabs(b));
#endif // #ifdef _MSC_VER y/n

You can see I work 'hard' to make certain 'persistent' 'MSVC6 fix' items EASY to 'fix', transiently ;=)) I can only repeat, I feel the FlightGear flight experience is worth the 'effort' ... but wait. It can not be 'effort' if you enjoy it, can it? To use my macro, just open Macro ... and drop the GetCompSwitch and AddCompSwitch contents (Note vi), given below, into Mymacros.dsm file -

I then link the AddCompSwitch macro to the tool bar, under a selected icon ... so the fix becomes - select, click macro button, change first 'max' to '_MAX' ... and press F7 (build), to get on with it ... just seconds ...

options.cxx provides another immediate example of using this macro on the 'trouble' line, this time an error C2078: too many initializers -
#ifdef _MSC_VER
  char levels[][20] = {"alpha","beta","early-production","production",0};
#else // !#ifdef _MSC_VER
const char levels[][20]= {"alpha","beta","early-production","production",0};
#endif // #ifdef _MSC_VER y/n

So MSVC6 accepts it if you do not add the 'const' ... To me, adding 'const' to such a table only helps the compile 'know' that its contents should not be changed during the life of the application ... but if you, as the coder, developer, programmer of the code, 'know' that you should not, and do not, alter your own compare list ... this table is constructed on the stack, so can not be altered by any 'external' to the function 'forces' ... also it seems 'strange' to end it with a zero, (0), and then loop using 1 less than the size ... but it is also clear this is probably destined to be 'created' from an xml script ... so it is maybe 'work-in-progress', more so than all code is ;=))

And I find no 'MSVC6 fix' for the next error C2667: 'sort' : none of 2 overload have a best conversion, and error C2668: 'sort' : ambiguous call to overloaded function! So I have to resort to altering the code ... not that I like it ... very last resort ... after all else failed ... but in this case, it is a list of aircraft output to the console, and it seems a small price to pay to retaining my MSVC6 compile, to simply remove the code .-
#ifndef _MSC_VER
   sort(aircraft.begin(), aircraft.end());
#endif // #ifdef _MSC_VER y/n
viewer.cxx(145) : error C2374: 'j' : redefinition; multiple initialization, is again a simple 'MSVC6 fix' ...

modelmgr.cxx has another error C2065: 'iterator' : undeclared, MSVC6 fix by -
typedef vector<FGModelMgr::Instance *> vIp;
and, then the 'fix'
void FGModelMgr::remove_instance (Instance * instance) {
   //vector<Instance *>::iterator it;
   vIp::iterator it;  

aicarrier.cxx gets -
   typedef list<string> ls;
   //list<string>::const_iterator it;
   ls::const_iterator it;

A second error in AICarrier.cxx is masked by a large number of warning C4786: debug truncation to 256, so I simply add -
#ifdef _MSC_VER
#pragma warning( disable:4786 )
#endif // #ifdef _MSC_VER
at the top of the file ...

This file also provided a 'new', for me ;=(( warning, I had not seen before ... namely warning C4541: 'dynamic_cast' used on polymorphic type 'class ssgBase' with /GR-; unpredictable behavior may result ... wow, what a description to be given out by the compiler development group!

Again, if you are really hell bent on remove all warnings, then I note MSVC6 will absolutely accept the normal recasting of one pointer to another, namely -
#ifdef _MSC_VER
         FGAICarrierHardware* ch = (FGAICarrierHardware *) ud;
#else // !#ifdef _MSC_VER
         FGAICarrierHardware* ch = dynamic_cast<FGAICarrierHardware*>(ud);
#endif // #ifdef _MSC_VER y/n
but maybe the dynamic_cast is 'required' by other compilers? And if you really want to 'keep' the dynamic_cast, then the MSDN Help says -
<quote>
You did not enable run-time type information and tried to use a feature that requires run-time type information support. Recompile with the /GR switch.
For more information, see the Enable Run-Time Type Information (/GR) compiler option.
</quote>

That is, Project, Settings, select file, C/C++ tab, and check the RTTI option ... and the warning C4541 'evaporates' ... I personally would not enable it for the whole project ... Why do you really want to add runtime code to compare the passed stack parameter type is suitable to be reallocated to another type, especially when all they are, are pointers? What's in a pointer, or 2, I say ...

This is fun, isn't it?. The next in replay.cxx, error C2955: 'list' : use of class template requires template argument list, is also new to me - double wow, what will they think of next? ;=)) It always seems to me, that if I can read the functions argument set, and 'understand' what is being done, then SO SHOULD THE COMPILER ;=((

I do not particularly like the 'MSVC6 fix' I have applied, namely -
#ifdef _MSC_VER
static void interpolate( double time, const replay_list_type & l ) {
   // sanity checking
   if ( l.size() == 0 ) { // handle empty list return;
   } else if ( l.size() == 1 ) { // handle list size == 1
       update_fdm( l[0] ); return;
   }
     ... etc - each occurrence of 'list' replaced with 'l' ...  until ...
    FGReplayData result = interpolate( time, l[mid], l[mid+1] );
   update_fdm( result );
}
#else // !#ifdef _MSC_VER

This is one of the relatively 'few' time I have seen MSVC6 mess up, get confused, over a stack passed parameter ... over zillions of miles of code ... but there is a first time for everything! I certainly do not like this kind of 'fix', since it is too easy to also 'break' the intent of the original code ... but I will do almost anything to get FLYING ;=))

Schedule.cxx provided another example of needing to move the inclusion of <simgear/compiler.h> up ahead of all other includes, even to be able to centre on the error the compiler reports ... It turned out to be a repeat of the sort<bgn,end>; failure mentioned above. I do not have a simple excuse, like above, but to get FLYING, I have commented them out with -
#ifndef _MSC_VER
sort(flights.begin(), flights.end());
#endif // #ifndef _MSC_VER  

Sometimes you have to be RUTHLESS ... does the end justify the means? ...

But after this 'fix', I am rewarded with ... NEARLY THERE ... of course, there are a 'few' link errors -
Debug/FlightGear.exe : fatal error LNK1120: 572 unresolved externals
Error executing link.exe.
FlightGear.exe - 3994 error(s), 1 warning(s)

The nearly four thousand errors actually take nearly a minute to complete in the build list window ;=((

But the compile has completed ... only linking objects remain ... It is certainly time to put the 'bubbly' on ice ... now all we have to do is correct the link library list, and/or the paths to the include libraries ...

The Link.

The link list of 'libraries' can be quite long, and is 'confused' by the considerable number of what might be called 'system' libraries, as well as a long list of we have just compiled, 'external' libraries ... even the considerable 'default' list of system libraries has to be added to run all the 'features' of FlightGear, as well as 'external' PLIB, SimGear, zlib, and AL static libraries.

With more experience you can 'look' at the nearly 4000 'unresolved', and 'see' what additional system libraries, but first, to get rid of some of the 'frequent' things ... in this instance, this first link, sgdMakeCoordMat4() occurred first, and I now 'know' this is in PLIB, so we open Project, Settings ..., and select the Link tab, category: Input ... there are two items here you must now work on - 'Object/library modules:', and 'Additional library path:' ...

I note the library module list is presently -
kernel32.lib user32.lib winspool.lib comdlg32.lib gdi32.lib shell32.lib wsock32.lib

Doing a simple dir root\PLIB\*.lib will show a list of PLIB Debug static objects of -

fnt_d.lib, js_d.lib, net_d.lib, psl_d.lib, puAux_d.lib, pui_d.lib, pw_d.lib, sg_d.lib, sl_d.lib, ssg_d.lib, ssgAux_d.lib, ul_d.lib, and a similar Release set, without the '_d' ...

You could add them one at a time, and try a new link, and see if there is a reduction in the link unresolved ... so I add, to the 'Win32 - Debug' configuration, sg_d.lib and ul_d.lib ... and add ..\..\PLIB as an 'Additional library path:' - this action is 'equivalent' to what can be read as 'Installing PLIB' ... You have given this project, FlightGear 'access' to all the PLIB object code ...

Although this next link still takes a minute or so to list the 3,709 errors -
Debug/FlightGear.exe : fatal error LNK1120: 543 unresolved externals
I have 'lost' nearly 300 errors, and some 30 unresolved items ... success, in a way ;=))

If you have ever written a makefile, to run with nmake, or the NT cousin, build, then another way is to read the appropriate source makefile.am. In this case, this is the makefile.am in the folder source/src/MAIN ... in there is the desired 'help', in the line -
            -lplibpu -lplibfnt -lplibjs -lplibnet -lplibssg -lplibsg -lplibul \

This tells me to try pu, fnt, js, net, ssg, and sg and ul which I have already included above ... so back into Project, Settings, Link tab, and in Debug I put -
pu_d.lib fnt_d.lib js_d.lib net_d.lib ssg_d.lib
and try another link, F7, ... but get an error ... pu_d.lib can not be found ... in the PLIB list above, I note there is puAux_d.lib and pui_d.lib, which, when added, brings the unresolved down to 320, 2,805 errors ... moving along the right path ...

Of course, I should include the simgear.lib, and a path to the debug of ..\..\SimGear\source\Debug ... This is how you can keep the same library name, but choose to link with the appropriate Debug or Release version ... Again, in the 'unix' talk, you will always read the word 'install' ... as mentioned, the fact that the external static library can be used from exactly where it was created means adjustments, fixes, changes, ... in the external library are very easy to effect ... load project, make change, compile, link ... and the new library is ready for use.

After the next link, I am down to a mere 34 unresolved externals, 65 errors ... I hope the 'bubbly' has had time to chill ... it should not have much more time before the first flight ;=)) Of course, the 'bubbly' is for AFTER the first flight ;=))

The first link error, shown by F4, gives me a clue ... missing is __imp__alGetError ... in simgear.lib(xmlsound.obj) ... and note the 'fancy' __imp__ in front of the function ... this indicates that the library is associated with a Dynamic Link Library (DLL) ... DLL's are nearly the same as 'static' libraries, except that it complicates the binary (executable) distribution ... If your use DLL(s), then they must be 'shipped' with the FlightGear.exe file ... If you can achieve a link with only static libraries, then the resultant EXE is the only 'distribution' item, required no 'Windows Installer', and can be run from 'anywhere' ...

In this case the particular function is found in win/openAL32.lib/dll, so I add it ... and do not forget the additional path, like ..\..\AL\openal\win\Router\Debug, or Release ... I also 'know' I need to add Alut.lib, and a path to it, like ..\..\AL\openal\win\ALut\Debug, (and Release) ... F7 again ...

The next link exposes __imp__RegCloseKey@4, and that I know is in a 'system' library/DLL ... With the cursor on RegCloseKey, in jsWindows.cxx, F1, invokes MSDN help, for the function, and reading down the specs. reveals Advapi32.lib, so add it ... I usually put these system item before the other external libraries, but not too sure is matters too much ... At the same time I note the unresolved, unmistakable, zlib functions ... so I add zlib.lib and an additional path like -
..\..\SimGear\source\src-libs\zlib-1.1.4\Debug, and Release for configuration 'Win32 - Release' ...

I am rewarded with the ultimate - Linking...
FlightGear.exe - 0 error(s), 0 warning(s)

Of course the zero warnings is not a fact ... but I choose not to go into that for now ... I just want to get FLYING ... That is I want to run the application ...

Running FlightGear.exe from within the MSVS IDE.

Of course, now that the link is complete, I can just press F5 (run), to start the FlightGear.exe application, but there is one more large chunk of 'source' that must be 'pointed to' ... That is the FlightGear data, an 'integral' part of the application ... There are a number of ways to achieve this, but the simplest is to select Project, Settings ... then the Debug tab ... and add, in 'Program Arguments, the following -
--fg-root=groot\FlightGear\data

The root being where ever you copied the CVS data download, or it can be direct pointed at the CVS download folder ... In the same dialog, I usually also set the working directory to where the exe is, without the Debug or Release on the end ... a 'global' user, or 'system' environment variable of FG_ROOT can also be set up ...

YOU ARE READY TO FLY ;=)) Just push F5 (run), and hopefully, sit back, and admire your work ... loading, initialising ... a CONSOLE window will open, but you may not see much in here initially ... after at least the good part of a minute, a 640x480 window should open, and the great 'flash' image presented ...

If the applications aborts, with a 'missing' glut32.dll message, then you have to download, at least the binary release of GLUT [www.xmission.com/~nate/glut.html] ... or you can download, and compile the source ... you should be good at this by now ;=)) ... and copy the results appropriately, as enumerated in the README-Win32.txt ... 

If the application still 'aborts', it may be necessary to set the debug information output 'higher' ... bootstrap.cxx, is where the only 'Main entry point' exists, namely - int main ( int argc, char **argv ) {
and it can be seen it calls fgMainInit(...) in main.cxx. This is where the SG_LOG() 'function' defaults to SG_ALERT, which means you should only see 'catastrophic' problems in the CONSOLE output ... of which I hope you have none ... You can alter this default line - ie // set default log levels
   sglog().setLogLevels(SG_ALL, SG_ALERT );
to say SG_INFO, or even the quite 'noisy' SG_DEBUG ... and then you will see lots of information flashing by on the CONSOLE screen ... or you can add a command line --log-level=<level>, like 'info', command ...

My 'preferred' method to set such options is to create a system.fgfsrc file in the root\FlightGear\data folder ... below (Note vii) is a sample of one of my 'test' files ... The order of precedence for options is the command line, .fgfsrc file, in users 'HOME' directory, if you have one, system.fgfsrc in groot\FlightGear\data, FG_ROOT, after reading preferences.xml, an XML property list ... so lots, lots of OPTIONS ;=))

Copy it to the clipboard, and write the file to groot/FlightGear/data folder, and get ready for a thrilling experience ... Most of the time, when the cockpit is displayed, the 'aircraft' is usually already moving ... quickly bump the throttle, and set it to zero on the joystick, and pull back a bit at the same time ... otherwise, sometimes I find the 'aircraft' is moving by the time the image appears, and I am far from the 'start' point ... sometimes I even do a menu File, Reset, to get things back to the start ...

I have found that such 'experimental' aircraft, like the 'ufo' fdm, set above, seem to pick up 'residual' values from the 'controls' in the property tree, thus it sort of sometimes hits the scene 'running' ... Since this ufo fdm has no 'intersection' with the earth logic, that is 'crash logic'. it can 'fly' underground ... try climbing a bit, and swinging around on takeoff, and push open full throttle, which results in just short of 4000 knots, which gets you downtown San Francisco in 'seconds' ...

Try climb high, and flying along ... watch the 'tiles' being loaded as you rush forward ... you can get a sense of how FlightGear does it ... the tile manager is reaching out, in front of you, and looking for, and loading tiles ... with the options I have set, the scene does not have a 'lot' of 'realism', but it is 'artificially' created after all, so this 'suits' me ...

As has been reported on the development board for some time now, even setting --disable-sound above, you will still hear airport markers go off, here and there, so I often hit the 'mute' button before launching FlightGear, if it is late at night, and I do not want to disturb the whole neighbourhood ;=((

Switch the options, parameters around, experiment with different aircraft ... it seems these are 'better' loaded using a command line option ... it appears this system.fgfsrc file is loaded, and parsed too late in the process ... to get rid of the 'big' panel in front of your nose, add --aircraft=ufo to the command line argument ...

Get into the keyboard ... Esc is exit ... Ctrl+C shows the 'hotspots' on the panel, 'v' changes the view point from default cockpit, to chase, to tower, to etc ... and back ... try it 'slowly', one by one, until you 'see' the cycle ... There are just so many things to 'enjoy' ;=))

Download, and 'install' more scenery of the world ... get you 'favourite' area ... mine is obviously Sydney, but a lot of work needs to be done on this scenery ... where is our bridge, opera hose, and things? We have some 'very distinctive' building to be modelled ...

Summery:

Is all this 'too difficult'? No. Does it take some 'dedication' to get through to the flying end? Yes. But, really, if programming, coding, is not really your thing, then try directly download the runtime binaries - that is, the WIN32 executables, and the root\FlightGear\data folder ... You can literally be flying along in minutes ...

Can more be done to make the MSVC6 build easier? Yes, and this is being done, slowly ... we need more WIN32 developers, using MSVC, whatever version ... I have not said much about MSVC version 7, the .NET initiative ... but lots of what has been said here applies to using it as well ...

Do not hesitate ... now is the time to start the downloads ...

Looking forward to your input, and contribution to this fantastic application, FlightGear ... thank you much-ly to all those who contribute ...

Geoff R. McLane
January, 2005

FG-MSVC6 - FG-MSVC7 - UFO - ATLAS ( 1 - 2 - 3 ) - OTHERS - Favourites - Home

EOF - Appendix:  

Note a: MSVC6

I have been purchasing, upgrading, and using Microsoft Visual Studio since it first release in Windows 3.1 (16-bits). What an 'innovation' it was at the time. Colour coded code, searches across all the project files, with MSDN Library, easy F1 context sensitive help, integrated editor, with popup sensi-code help, compiler, linker, library manager, ... and lots more ... it is an Integrated Development Environment (IDE), that makes programming easier...

As the 'switch' to 32-bits arrived, they separated the 16-bit version, and ceased upgrades. It has been a 'great' tool for me ... Around 2002, Microsoft headed on their .NET initiative - managed code - and I remember reading the lament of one powerful programmer, something like - "how could they bring out a 'version' that could not use the thousands of miles of good code that I have written in the past!".

One could say that sometimes 'innovation', development, evolution, change ... can cause massive loss of what has been done previously. This certainly occurred when code went from the 20-bit addressing, in the 16-bit CPU, to the 32-bit machine. You could 'try' to modify the code, but that was not always successful ;=(( But, while I am sure MS would claim 'innovation', it feels more like a 'proprietary' move ...

To their credit, somewhere through the years, MS started to realise how important it was to promulgate their 'tool', which embodied their idea of how it should all be, and Visual Studio came 'free' with your Library, or higher, MSDN Subscription. You can presently download their NET Studio Beta 2005 for free. I have done this, but have not tried it on FlightGear yet ...

There is no doubt, as some stage, I will have to bite-the-bullet, and give up my trust MSVC6, but 2005 is NOT the year for that ... I think it has a good few years left yet ...

return Note a

Note i): CVS

CVS [https://ccvs.cvshome.org/] I use 'stable' version  1.11.17, June 2004 

return Note i

Note ii): Sample Download Batch File

Contents of loadfg.bat

@REM ***************************
@REM Fresh set of CVS source
@set TEMP1=FlightGear
@set TEMP2=SimGear
@set TEMP3=PLIB

@REM Establish Folders
@if EXIST %TEMP1%\null goto GotDir1
@if EXIST %TEMP1%\. goto GotDir1
@echo Not found %TEMP1% ... making directory ...
md %TEMP1%
:GotDir1
@if EXIST %TEMP2%\null goto GotDir2
@if EXIST %TEMP2%\. goto GotDir2
@echo Not found %TEMP2% ... making directory ...
md %TEMP2%
:GotDir2
@if EXIST %TEMP3%\null goto GotDir3
@if EXIST %TEMP3%\. goto GotDir3
@echo Not found %TEMP3% ... making directory ...
md %TEMP3%
:GotDir3
@if "%CVSROOT%." == "." goto SetROOT
@goto GotROOT

:SetROOT
call setroot
@echo Hopefully SET CVSROOT=%CVSROOT% ...
@echo Run again ...
@goto End

:GotROOT
@if "%1." == "." goto Use
@if "%1." == "1." goto LISRC
@if "%1." == "2." goto LOSRC
@if "%1." == "3." goto LIDAT
@if "%1." == "4." goto LODAT
@if "%1." == "5." goto LISG
@if "%1." == "6." goto LOSG
@if "%1." == "7." goto LIPL
@if "%1." == "8." goto LOPL
@echo **** INVALID COMMAND ****
@goto Use

@REM source
:LISRC
cd %TEMP1%
@echo CVS passwd: guest
cvs -d :pserver:cvsguest@cvs.flightgear.org:/var/cvs/FlightGear-0.9 login
cd ..
@goto End  

:LOSRC
cd %TEMP1%
cvs -d :pserver:cvsguest@cvs.flightgear.org:/var/cvs/FlightGear-0.9 co source
cd ..
@goto End  

@REM data
:LIDAT
cd %TEMP1%
@echo CVS passwd: guest
cvs -d :pserver:cvsguest@cvs.flightgear.org:/var/cvs/FlightGear-0.9 login
@goto End  

:LODAT
cd %TEMP1%
cvs -d :pserver:cvsguest@cvs.flightgear.org:/var/cvs/FlightGear-0.9 co data
cd ..
@goto End  

:LISG
cd %TEMP2%
@echo CVS passwd: guest
cvs -d :pserver:cvsguest@cvs.simgear.org:/var/cvs/SimGear-0.3 login
cd ..
@goto End  

:LOSG
cd %TEMP2%
cvs -d :pserver:cvsguest@cvs.simgear.org:/var/cvs/SimGear-0.3 co source
cd ..
@goto End  

:LIPL
cd %TEMP3%
@echo PWD is just ENTER key ...
cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/plib login
cd ..
@goto End  

:LOPL
@REM cd %TEMP3%
cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/plib co plib
@REM cd ..
@goto End  

:Use
@echo 1 = login to source. pwd=guest
@echo cvs -d :pserver:cvsguest@cvs.flightgear.org:/var/cvs/FlightGear-0.9 login
@echo 2 = fetch source
@echo cvs -d :pserver:cvsguest@cvs.flightgear.org:/var/cvs/FlightGear-0.9 co source
@echo 3 = login to data. pwd=guest
@echo cvs -d :pserver:cvsguest@cvs.flightgear.org:/var/cvs/FlightGear-0.9 login
@echo 4 = fetch data
@echo cvs -d :pserver:cvsguest@cvs.flightgear.org:/var/cvs/FlightGear-0.9 co data
@echo 5 = SG LOGIN
@echo cvs -d :pserver:cvsguest@cvs.simgear.org:/var/cvs/SimGear-0.3 login
@echo 6 = SG LOAD
@echo cvs -d :pserver:cvsguest@cvs.simgear.org:/var/cvs/SimGear-0.3 co source
@echo 7 = PLIB LOGIN
@echo cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/plib login
@echo 8 = PLIB LOAD
@echo cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/plib co source
@goto End  

:End
@REM ***************************  

return Note ii

Note iii): Load AL Sample

Contents of loadal.bat

@echo Load OpenAL ...
if EXIST AL goto gotAL
@echo Create a folder called AL ...
@goto End  

:gotAL
@echo (use password "guest")
@echo 1 = cvs -d:pserver:guest@opensource.creative.com:/usr/local/cvs-repository login
@echo 2 = cvs -d:pserver:guest@opensource.creative.com:/usr/local/cvs-repository co openal
@if "%CVSROOT%." == "." goto SETROOT
@if "%1." == "1." goto LOGIN
@if "%1." == "2." goto LOAD
@echo Use command 1 or 2 ...
@goto End  

:LOGIN
@echo (use password "guest")
cd AL
cvs -d:pserver:guest@opensource.creative.com:/usr/local/cvs-repository login
cd ..
@goto End  

:LOAD
cd AL
cvs -d:pserver:guest@opensource.creative.com:/usr/local/cvs-repository co openal
cd ..
@goto End  

:SETROOT
@if NOT EXIST setroot.bat goto NOSET
call setroot
@if "%CVSROOT%." == "." goto NOROOT
@echo Run again ...
@goto End

:NOSET
@echo Can not find setroot.bat?.
@goto End  

:NOROOT
@echo CVSROOT must be set in the environment ...
@goto End  

:End  

return Note iii

Note iv): WINZIP

I use WinZip 9 SR-1 (6224) - 1991-2004 - which cost about US$30

It is the Command Line interface offered with it that keeps me using WinZip ... It is great for backing up sources. Of course, as the price of hard disk media continues to fall, this becomes less of a need, especially when you throw in the CD-ROM 'collecting' and 'burning' as a 'native' part of Windwos XP. ;=))

return Note iv

Note v):STUFFIT

It seems Stuffit Delux 8.5 costs about A$55.50

Note: If you want to install BOTH WinZip *AND* Stuffit, take some care. They have a lot of 'common' ground, and it can become a bit of a 'fight' over file type 'associations' ...

On the other hand, the Stuffit UI is more 'compatible' with a unix style ... if you want that.

return Note v

Note vi): MSVC MACRO

Add the Function and the Sub below to Mymacros.dsm, or whatever you may have renamed it ... :-

Function GetCompSwitch( sBlk )
 Dim sNBlk
 Dim iLen
 sNBlk = ""
 iLen = Len(sBlk)
 If (iLen > 0) Then
   sNBlk = "#ifdef _MSC_VER" + vbCrLf
   sNBlk = sNBlk + sBlk
   sNBlk = sNBlk + "#else // !#ifdef _MSC_VER" + vbCrLf
   sNBlk = sNBlk + sBlk
   sNBlk = sNBlk + "#endif // #ifdef _MSC_VER y/n" + vbCrLf
 End If
 GetCompSwitch = sNBlk
End Function

Sub AddCompSwitch()
 'DESCRIPTION: Convert selected to two lines, switched
 Dim sBlk, sNBlk
 sBlk = ActiveDocument.Selection
 sNBlk = GetCompSwitch(sBlk)
 If (Len(sNBlk) > 0) Then
  ActiveDocument.Selection = sNBlk
 End If
End Sub

return Note vi

Note vii): FGFS OPTIONS

Copy to clipboard, and save as system.fgfsrc file in groot\FlightGear\data

# system.fgfsrc
# set TIME
--timeofday=noon
###--altitude=1000

# set aircraft/FDM to run
###--fdm=magic
--fdm=ufo
###--fdm=jsb
###--aircraft=ufo
###--aircraft=paraglider-jsbsim
###--fdm=para
###later --aircraft=dhc2F
###--prop:/sim/panel/path=Aircraft/c172/Panels/c172-panel.xml
--prop:/sim/hud/draw-fps=true
# set airport - KSFO default
###--airport-id=25U
###--airport-id=YSSY
###--airport-id=YSDU

# log-level order = debug info warn alert
--log-level=info
#--log-level=debug

--enable-hud

# in metres
###--visibility=32000
--visibility=64000

--control=joystick
#--disable-random-objects
--disable-panel
#--disable-ai-models
--disable-clouds
### no-no ??--disable-clouds3d
--disable-skyblend
--fog-disable
--visibility=64000
--disable-sound

# EOF

 

return Note vii

to top of page

FG-MSVC6 - FG-MSVC7 - UFO - ATLAS ( 1 - 2 - 3 ) - OTHERS - Favourites - Home

References: From Pablo...
 MinGW http://www.mingw.org
 Eclipse http://www.eclipse.org
 Visual C++ Toolkit http://msdn.microsoft.com/visualc/vctoolkit2003/