Old Game Source Code - Help Recompiling?

I have the full source code to a game that was in development in the early 2000s. It was released on Xbox, but I am certain that PC builds were generated for internal development and testing purposes. The Xbox executable is present with the source, but there is no Windows executable. For this reason, I'd like to recompile the source to build the Windows executable.

The game was written in C++ and compiled with a C++ 6 compiler. I don't have that compiler, nor do I have the version of Visual Studio that the code was developed with. The codebase is full of dsp files (VC++ 6 project files), but I don't see a dsw file anywhere (VC++ 6 solution file). The dsp files all have this version information in them:
# Microsoft Developer Studio Generated Build File, Format Version 60000

When I allow my modern version of Visual Studio to convert a project to a modern format (don't worry, I have the original untouched source archived), it doesn't seem organize things correctly for proper compilation, and even classes within the same namespace don't seem to see each other, causing tons of compilation errors.

I'm pretty unfamiliar with many of the nuances involved in compiling old code, so I'm wondering if anyone with experience could help me out here and offer some pointers.

Thanks in advance!

 

I would recommend trying to guesstimate/reproduce the original build environment as close as possible when starting out with sth like this. That means grabbing a copy of VS6 from somewhere. And maybe an XDK to go along with it (the Prototopia project might have them on offer, if not they're not that hard to find elsewhere), in case the code uses any headers from it even for Windows builds. You can always try and upgrade later.

The dsp files might be unused if e.g. makefiles (back then Microsoft was pushing "nmake"), or another build system altogether, was used. Batch files are always a good starting point too. Did you notice anything like that?

 

I think they were on Windows 2000 machines, using whatever was the contemporary version of Visual Studio at the time, compiling with a C++ 6 compiler.

There's surprisingly no makefiles, just a couple of batch files. MakeHelp.bat generates windows chm help files, a sort of automatic API generation, I suppose. Then there's postbuild.bat which has this description in the file:

Code:

rem $Header:
rem ----------------------------------------------------------------------
rem   PostBuild copies all files required to USE a LIB to a destination.
rem   It is currently one file for all usages: debug, release, master.
rem   Typical debug usage is: "PostBuild debug"

Pretty much everthing else is .c code files, .h header files, and .dsp project files.

 

No makefiles is a good thing - no using environment variables whose contents we'd have to totally guess. The postbuild batch does not help us get started, it gets run by VS after a successful build, usually to package an installer (well, probably not in this case unless it's a Live title :b), start a testing run or things like that. In this case, if the comment isn't lying, it seems like it'll package a library for distribution to other developers.

The windows version does in fact not matter all that much, just don't go trying to compile for a 64bit target. Feel free to stay on Win10 or whatever for now. Though it may be smart to work in a VM to not have VS version conflicts - your choice.

There is no "C++ 6", but the version string in the dsp(s) tells us they came from Visual Studio 6.0. VS6 came with compiler version - not language version - 12.00 (_MSC_VER == 1200), but don't let that confuse you, it doesn't matter here. The other two fitting the timeframe - ".NET" and ".NET 2003" - don't bring anything to the table that concers the XBOX, and in fact I' not even sure the XDK officially supports them (edit: seems like some later ones do). 6 is the safest bet.

The takeaway is:
- acquire Visual Studio 6
- acquire a copy of the XDK (or try without, but it's best to have it)
- set up both (maybe in a Win2k VM)
- try building one of the projects again

Would you feel comfortable sharing any of the build-related non-source-code files? That'd probably help us/me a lot in helping you.

Oh and in the meantime you could go looking for WinMain functions - the entry point for each Windows GUI app - somewhere in the code. We need at least one, maybe a few more if there's supporting apps like map editors. If they don't exist the odds of there being PC builds are a lot lower.

 

I would say the lack of makefiles is a bad thing, since they are easier to parse than whatever weird format the Microsoft used for its project files at any given time.

There was a 6.0 version of Visual C++. There was also a 6.0 version of Visual Studio (which probably supported Visual C++, to add to the confusion). Make sure you get your terminology right as it will change the approach a bit.

You do need to get as close to the original build environment as possible to begin with. This may mean firing up a VM and installing Windows 2000 with VS6. I am not a Windows (or Xbox) developer, but with my experience with Visual Studio I seem to recall you specified different targets using the GUI prior to build.

Now if you are sure, and I mean absolutely sure, that this project contains all the relevant source to build for multiple platforms, then you can probably get it to work. I ask because I always hear people say "console developers develop everything on PCs and then port" or whatever argument, which is generally untrue.

When we build cross-platform internally, we usually have separate codebases for core common functionality and another for platform implementations. We are pretty much Unix-only at work but we use makefiles and dynamic libraries to make this work. In your case there might be multiple subprojects within the top level project, or multiple discrete projects.

It is possible given an Xbox title that the two platforms were similar enough to get all the multi-platform stuff brought in with conditional compile flags, but either way this will be specified by selecting the appropriate target from your build environment. This will be wrapped up in the Visual Studio project file.

 

> I would say the lack of makefiles is a bad thing, since they are easier to parse than whatever weird format the Microsoft used for its project files at any given time.
Have you seen nmake's syntax? I've seen quite a few make dialects, and MS's is... not the one I would choose. And why would we try parsing project files ourselves? That's what we're installing VS for. Moot point though.

> There was a 6.0 version of Visual C++. There was also a 6.0 version of Visual Studio (which probably supported Visual C++, to add to the confusion). Make sure you get your terminology right as it will change the approach a bit.
Well, he's got Developer Studio Project files, should be obvious enough. Also, the XDKs are meant to integrate with Visual Studio, not Visual C++ (edit: actually, turns out earlier XDKs also support VC++6. What the heck, just go grab em all...)

 

Haha yes I have more experience with various versions of make, nmake, cmake, etc. We are using vanilla make right now on a Windows platform to automate an IDE-oriented build from a non-GNU compiler. I imagine you can automate the backend of VS in similar ways, however nonstandard.

With regard to Visual C++ 6.0: we were using Visual Studio to compile Visual C++ projects about a decade ago. Perhaps he has some specific version of a project file that precludes this from being a possibility, I don't know. As I said I haven't developed for an MS-platforms in a number of years. But it is important to understand that there is a difference as it is a subtle nomenclature issue that I have seen lead to lots of confusion in the past.

 

Alright, this is a lot to go on. Thank you both.

So my first steps will be to install Windows 2000 on a VM, install a copy of Visual Studio 6, and attempt to recompile. If needed, I'll also try getting the XDK version that was contemporary at the time.

I thought C++ had different versions over time, introducing new syntax or data structures that only the latest compilers understood. Confused on the difference between C++ and Visual C++.

99% sure there's windows support for this game... but this is a milestone deliverable to the publisher, so I suppose it's possible they only included source for the intended platform. We'll see!

 

It is a bit fuzzy to be honest, Visual C++ was the name of an IDE and compiler that implemented the C++ standard (it is technically just the compiler). It has also been used to refer to Microsoft's specific extensions to C++ that were not portable across targets.

The VC++ compiler is wrapped up in Visual Studio instead of being shipped with its own IDE now if I am not mistaken.

 

> vanilla make
You most likely mean "GNU make". Make sure you get your terminology right and no this is not "it's called GNU/Linux" bullshit, it's just that e.g. BSD make, also called as 'make', has yet another syntax...

> C++/VC++
There's been multiple revisions of the C++ language standard, but they're not "versioned" per se (as in, with a X.Y numbering scheme). We have the original ISO/IEC standard 14882, followed by revised ones nicknamed C++03, C++11 and C++14 (these also have their own ISO numbers: which are the "proper" designation).
"Visual C++ 6.0" is version 6.0 of the product named "Visual C++" by Microsoft, which just so happens to contain an implementation of the language specs mentioned above. You can have multiple "Visual C++"s implementing the same standard, but with, say, improved icon editors or stuff like that; the version number MS gave its product doesn't say jack about the C++ language version supported. In fact, some VStudios got updates that elevated their compilers to new C++ revisions, so you'd have the same VS version with support for multiple C++ versions. So actually you'd want to look at the versions of the underlying compiler(s) installed/used with whatever Visual Gizmo you're using... Confused yet? :b
TL;DR: C++ = just a language specification, Visual C++ = independently versioned implementation of the C++ language.

 

Hah well it actually isn't GNU make either if you want to be pedantic. But that has nothing to do with OP's question. I'm trying to make sure he doesn't go off down the wrong path on accident, not get into a pissing contest about nomenclature.

 

Fair enough.
Kao, regarding the XDK version, if you tell us the release date of your game, someone more knowledgeable about the XDK can chime in with a version number fitting that time. Let us know how it's going.

 

Thanks again, all. You're answering so many questions I had.

I'm in the process of obtaining a copy of Visual Studio 6 and Windows 2000. I'll try to have the VM set up and everything installed later today.

The documentation included with the milestone deliverable says the game was built using XDK version 3823. I think I have 3823, but I'll have to check. Actually, upon checking, I see that I only have 5849. Hopefully the XDK is not required to build a Windows executable.

 

Oh there's even documentation? Awesome.
A later XDK *should* be OK (I hope... even though they're pretty far apart...) so if it's required, I'd say try your 5849 anyways. After all a Windows build can't do much more than pull in a few headers (ie no library conflicts or similar)...

 

Alright, running Visual Studio 6 on Windows 2000, and about to try compiling. Hope this goes well. I see a comment referencing "//Windows-specific code" so I'm hopeful.

 

Hmm... Hitting a bit of trouble already.

I've basically got a file structure like this, with each directory containing a respective project file:

/core/
/core/math
/game/

The game project in /game/ fails to build because it can't find core.h from the /core/ directory.
The core project in /core/ fails to build because it can't find math.h from the /core/math/ directory.
The math project in /core/math/ fails to build because it can't find core.h from the /core/ directory.

So it's this kind of circular loop of dependencies, that I'm not sure how to resolve. There's no solution file which contains all of the project files. Should I build one manually? And even if I do, does that alone enable the different projects to see one another's files during the build process?

 

A workspace/solution file basically only a) groups various projects together in a conveniently navigatable bundle, and b) defines an order in which to (re-)build each project (project dependency tree). If there isn't at least a single project that's buildable by itself, just creating a workspace won't really bring you any further.

What do the settings for "include paths" look like on the three projects? Make sure the "core" directory is available to the "math" project and if that gets things going, work your way backwards through the other projects (also check the library paths while you're at it, that'll be necessary for linking later).
Or you could cheat and just copy the missing headers around for now, that should also get things working, at least up to the point where one projects wants to link against a library made from one of the others.

Btw, does the stuff in "Tools" work? That sounds like it would likely be standalone/self-contained. Just to make sure things are set up correctly in general.

 

Can't get the tools to go either, most trying to utilize math.h

Getting frustrated on this right now. I'll try coming back to it again later this evening.

Where am I able to define include paths for the projects? That sounds like the key.

 

The include path settings are somewhere in the project properties.

Is the math.h getting included as "math.h" (quotes) or <math.h> (pointy brackets)? If it's the latter, it's actually looking for a system header, not one from another project, meaning your dev env setup is somehow screwed up (system headers should always be available, no matter what).

 

The includes are in quotes, thankfully!

I think I found where to enter the include paths:


Can/should I be using relative pathing here from the project's directory, or absolute paths?


Edit: I think I'm making progress? When building the "core" project, I now get an error in math.h, which is kind of good because it at least means that it sees math.h and it trying to use it.

math.h has this line:

Code:

#include "math\\Base.h"

And that's producing this error:
"fatal error C1083: Cannot open include file: 'math\\Base.h': No such file or directory"

However, Base.h is right there in the "core/math" directory with math.h, so I don't know why it can't see it.