[WMCoolmon]

I've moved all of the MSVC 7 project files to the MSVC 2003 folder, updated them, and committed them to CVS. You should be able to simply check out the project and compile right out of the box, assuming you have the Speech API installed, and have added the lib and include paths to MSVC 2003.

Speech API setup
Tools->Options->Projects->VC++ Directories, look for "Include files" and "Library files" in the pulldown boxes, and click the magical directory icon to add the appropriate directories.

If you installed everything to the default directories, "C:\Program Files\Microsoft Speech SDK 5.1\Lib\i386" will be the library files directory. "C:\Program Files\Microsoft Speech SDK 5.1\Include" will be the include files directory.

Notable changes:

• Libraries built by the project do _not_ use _d to denote debug builds (eg luabuiltind.lib, libjpeg_d.lib). Instead their folder location denotes what they are; this is so that the same field can be used across all configurations for the 8 some combinations of settings.
• Program executes by default go to C:\Program Files\Freespace2. Since we're moving the pilot files to the standardized directory, I think it would be a good idea to do the same for the program directory.
• All intermediate stuff is stored in "$(ConfigurationName)/Intermediate/", including precompiled header files, as opposed to the default of "Profile". Precompiled headers, program databases, etc use <ProjectName>.* for their filenames.
• Removed alut.lib and used OGG debug libraries for debug configurations.
• All configurations run with -window command line when you run the EXE from VC++.

Stuff that I didn't take care of:

• FRED2 does not have all the various configurations. I don't plan on using most of them; if somebody else wants them, they are free to add the other 5 in. :p These are P4Release, InfP4Release, InfRelease, InfDebug, InfP4Debug.
• I didn't touch wxFRED. Every time I've tried to get wxWidgets running, it's been a PITA, and I don't plan on developing from wxFRED2. However, I have the feeling that it'll need the same changes as above.
• The OGG debug libraries expect a "vc70.pdb" and spit out a number of warnings. There isn't any way to fix this, AFAIK, without recompiling them with proper .pdb names and including them in CVS.

[Bobboau]

what about 2005 though?

[WMCoolmon]

2005 can probably update from these project files and compile out of the box, too. I don't have 2005 though, so I can't test the theory to see if it actually works.

[Backslash]

Thank you WMCoolmon!  This saved me loads of time after a system upgrade. 

Confirmed, 2005 had no problems converting the project files.  Much better than what I was doing before.

[Bobboau]

"WINVER not defined. Defaulting to 0x0502 (Windows Server 2003)"?

and there are a bunch of warnings about type conversions the ones that looked most serious were things like 'int to ubyte' when ubyte was a 'flags' variable (in bmp_man)

[Backslash]

Heh, oops, correction... when I said 'no problems' I meant 'no problems with my current code tree'.  On trying to enable text-to-speech and Direct3D again, a bunch of errors crop up... but that's probably just some include things I need to track down.

Another problem: the openal/include/*.h files are all in Mac format, which is fine for 2003 but for some stupid reason 2005 complains about it.   Is it all right if I convert them to Unix format?  You'll hate the commit log but it'll end up compatible with everyone...

[taylor]

Another problem: the openal/include/*.h files are all in Mac format, which is fine for 2003 but for some stupid reason 2005 complains about it.   Is it all right if I convert them to Unix format?

Mac format is Unix format.  There is an older Mac format, but it's used the Unix EOL char for years now.  If it's wrong then it is likely due to a client side issue rather than because it's wrong in CVS.

[WMCoolmon]

"WINVER not defined. Defaulting to 0x0502 (Windows Server 2003)"?

and there are a bunch of warnings about type conversions the ones that looked most serious were things like 'int to ubyte' when ubyte was a 'flags' variable (in bmp_man)

Yeah I remember those. I started to try and fix them, but stopped when I realized that I wasn't sure if I could get away with it without breaking anything.