[BTS] The Easiest Way to Compile a New DLL

[Akka]

Hoping that this thread is still alive... ^^

I (think I have) followed the process :
- Installed the Civ4 SDK.
- Grabbed the zip with the project file.
- Opened the project in VS2022 (is this version compatible ?).
- Set the errors to "build only".

But I have a long list of errors in several .h files about "unsigned int should be preceded by ';' ", "missing storage-class or type specifiers" or "redefinition; different storage class" and the like.
It also tells me that the "C:\Program Files (x86)\Civ4SDK\Microsoft Visual C++ Toolkit 2003\bin\cl.exe"' : return code '0x2' ", which IIRC means he doesn't find the file, but I can confirm that the file is indeed located here :

Do you have any idea what is happening ?

 

[Nightinggale]

- Opened the project in VS2022 (is this version compatible ?).

The makefile should take care of compiling using VS2003 as that is the only one, which works properly (let's ignore the recent talk elsewhere about hacking in support for other compilers. That's advanced and might not work at all). What you use to call the makefile is up to you. It can be any version of VC or even cmd.exe. It's just a question of calling the right command line.

But I have a long list of errors in several .h files about "unsigned int should be preceded by ';' ", "missing storage-class or type specifiers" or "redefinition; different storage class" and the like.
It also tells me that the "C:\Program Files (x86)\Civ4SDK\Microsoft Visual C++ Toolkit 2003\bin\cl.exe"' : return code '0x2' ", which IIRC means he doesn't find the file, but I can confirm that the file is indeed located here :

Without the full error message I can't really tell what is going on. Usually the interesting error is the first error and I kind of suspect you didn't include that one.

 

[Akka]

The makefile should take care of compiling using VS2003 as that is the only one, which works properly (let's ignore the recent talk elsewhere about hacking in support for other compilers. That's advanced and might not work at all). What you use to call the makefile is up to you. It can be any version of VC or even cmd.exe. It's just a question of calling the right command line.

Well, I'll take your word for it. I don't really know what the makefile is for (I guess it's some sort of build instructions about which compiler to use and where to put the dll at the end ?), so if I don't have to tinker with it, so much the better.

Without the full error message I can't really tell what is going on. Usually the interesting error is the first error and I kind of suspect you didn't include that one.

The first error is the one about "unsigned int should be preceded by ';' " :

The fact it's giving a basic syntax error on a file that I suppose is an official MS one, lead me to think it's perhaps a case of obsolete formatting (after all, we're working with files from 2003 in a 2022 IDE).


Edit : okay, after installing VS2010 and building the project through it, I can say with some measure of certainty that it's, in fact, a compatibility problem. Annoying but at least there is a workaround.

 

[Nightinggale]

Well, I'll take your word for it. I don't really know what the makefile is for (I guess it's some sort of build instructions about which compiler to use and where to put the dll at the end ?), so if I don't have to tinker with it, so much the better.

A makefile is indeed a build script. It details which compiler to call for which file and with which arguments.

The fact it's giving a basic syntax error on a file that I suppose is an official MS one, lead me to think it's perhaps a case of obsolete formatting (after all, we're working with files from 2003 in a 2022 IDE).

That is only an issue for intellisense (the red lines in the code). The actual compiler should be the 2003 one. However you include MSVC\14.32.31326\include\sal.h, which is NOT the 2003 version. Somehow you ended up mixing compiler versions. Even if you get it to compile, you will end up with compatibility issues with the exe file. No idea how you ended up that way. You should rely on VC7.1 only and nothing in the 2022 folder.

 

[Akka]

A makefile is indeed a build script. It details which compiler to call for which file and with which arguments.

At least now I know a bit more about it ^^

That is only an issue for intellisense (the red lines in the code).

As you can see, I was in "build only" error display, so it's not about Intellisense.

The actual compiler should be the 2003 one. However you include MSVC\14.32.31326\include\sal.h, which is NOT the 2003 version. Somehow you ended up mixing compiler versions. Even if you get it to compile, you will end up with compatibility issues with the exe file. No idea how you ended up that way. You should rely on VC7.1 only and nothing in the 2022 folder.

I simply installed the SDK provided in the OP, unzipped the project and opened the sln file with VS2022.
I suppose that VS2022 just rely on some more modern compiler and isn't configured to use an older one.

I then installed VS2010 through the ISO in the OP too, and I could compile and debug the files I wanted while running Civ4, so I guess that VS2010 does something different about compilers. I admit that I was happy enough to have it works that I didn't really looked further ^^

 

[DarkLunaPhantom]

That is only an issue for intellisense (the red lines in the code). The actual compiler should be the 2003 one. However you include MSVC\14.32.31326\include\sal.h, which is NOT the 2003 version. Somehow you ended up mixing compiler versions. Even if you get it to compile, you will end up with compatibility issues with the exe file. No idea how you ended up that way. You should rely on VC7.1 only and nothing in the 2022 folder.

I then installed VS2010 through the ISO in the OP too, and I could compile and debug the files I wanted while running Civ4, so I guess that VS2010 does something different about compilers. I admit that I was happy enough to have it works that I didn't really looked further ^^

AFAIK, there is no sal.h in VS2003 (VC7.1) and that's why you also need a later version to provide that file. VS2010 (VC10) sal.h seems to be compatible and I think that is what everybody is using.

 

[aw11]

If it helps you, I was able to compile the dll by doing the following on Windows 11:

1. Download and install Visual Studio 2022 Community version
2. Extract the deps.7z from earlier in this thread to a folder [FOLDER]
3. Open CvGameCoreDLL.2012.sln in Visual Studio 2022 Community version
4. In Makefile.settings.mk, adapt the following paths
   • TOOLKIT=\[(FOLDER\]\Microsoft Visual C++ Toolkit 2003
   • PSDK=\[(FOLDER\]\Microsoft Platform SDK
5. Execute build for Release

 

[Leoreth]

Some clarification on Visual Studio, because it is quite confusing and surprised me initially as well. You need to have Visual Studio 2010 installed on your system to compile the DLL. Other versions of VS might also work, but I have not verified that. VS2010 is known to work, that is why it is included in the setup guide.

However (and that might not be obvious) you do not need to use VS2010 as your IDE to edit the code and run the makefile. I am using a more recent release and I recommend doing so because it seems in recent years VS has come much closer to what a state of the art IDE should do (like navigating from references to definitions etc...). So far I have had no problems opening the included solution file even with newer versions.

There might be incorrect warnings or even errors reported by the IDE, as Nightinggale mentions, but since it is not who eventually compiles the code you do not have to worry about it. As long as the compile step succeeds you are all good - I would rely instead on the compile output to see accurate error messages and warnings you'd want to address in your code.

 

[Nightinggale]

You need to have Visual Studio 2010 installed on your system to compile the DLL.

Fastdep.exe requires Microsoft Visual C++ 2010 Service Pack 1. A number of people have reported that they can compile with no installed Visual Studio at all as long as they have this service pack and the 2003 compiler. Interestingly it just needs access to the 2003 compiler files. They don't actually need to be installed. We The People and Caveman2Cosmos (and possibly others) have custom makefiles and/or setups to use the compiler in a local folder.

Personally I do not have MSVC 2010 installed at this moment. I do have 2017 and is planning on upgrading to 2022 eventually.

The real question isn't how the compiler setup can be made to work because there are many ways to do so. The question is what is the best advice for people, who can't get it to work. In other words a guide is good, but it should be known that diverting from the guide isn't automatically wrong.

AFAIK, there is no sal.h in VS2003 (VC7.1) and that's why you also need a later version to provide that file. VS2010 (VC10) sal.h seems to be compatible

The thing is, if there is no sal.h in 2003, then the 2003 compiler should be able to compile without it. Mixing versions of the compiler if any of the versions is older than 2015 can easily result in memory allocation weirdness at runtime, which in turn can result in random crashes and just plain strange behavior. Mixing Multiple Visual Studio Versions in a Program is Evil. It's not mandatory to understand this explanation just to do some modding, but that doesn't change the fact that this is a potential pitfall.

 

[DarkLunaPhantom]

The thing is, if there is no sal.h in 2003, then the 2003 compiler should be able to compile without it. Mixing versions of the compiler if any of the versions is older than 2015 can easily result in memory allocation weirdness at runtime, which in turn can result in random crashes and just plain strange behavior. Mixing Multiple Visual Studio Versions in a Program is Evil. It's not mandatory to understand this explanation just to do some modding, but that doesn't change the fact that this is a potential pitfall.

You are correct that there should be sal.h in VS2003 as some other VS2003 header includes it, but you don't get sal.h if you use Windows SDK and Visual C++ 2003 toolkit installer from the OP.

Then whatever VS version you are using will try to find missing sal.h elsewhere. People following instructions in the OP will also install VS2010 and likely end up using that sal.h. As you said, this is less than ideal.

 

[Basilmoyh]

It took me about 8-10 hours of attempts to get everything working and the DLL to build.

Though, I've tested the game out, and starting a new game, it sort bugs just after giving you access to the map and I have to press 'Escape' in order to gain control of my units. From then on, it seems to work without issue.

Edit: Oh I think this may be caused by me merging my personal custom mod with buffy, and buffy already had a CvGameCoreDLL.dll...

 

[f1rpo]

Oh I think this may be caused by me merging my personal custom mod with buffy, and buffy already had a CvGameCoreDLL.dll...

Yes, that would probably result in all sorts of user interface issues. The BUFFY DLL isn't open-source iirc; I guess for security reasons (integrity of the Hall of Fame features), but merging with BULL should be just as good. Maybe the non-DLL assets of BUFFY can be just used with the DLL from BULL if Enabled is set to False in Assets\Config\BUFFY.xml and if the correct optional features are enabled when compiling your BULL(-based) DLL, probably MOD_GWARM and MOD_SENTRY. The BUFFY DLL seems to be compiled with those two. Well, maybe more prudent to ditch BUFFY entirely and only use BULL assets. I'm looking at a WinMerge comparison between the two mods; the differences outside the DLL are minor, but there are a few.

 

[Basilmoyh]

Yes, that would probably result in all sorts of user interface issues. The BUFFY DLL isn't open-source iirc; I guess for security reasons (integrity of the Hall of Fame features), but merging with BULL should be just as good. Maybe the non-DLL assets of BUFFY can be just used with the DLL from BULL if Enabled is set to False in Assets\Config\BUFFY.xml and if the correct optional features are enabled when compiling your BULL(-based) DLL, probably MOD_GWARM and MOD_SENTRY. The BUFFY DLL seems to be compiled with those two. Well, maybe more prudent to ditch BUFFY entirely and only use BULL assets. I'm looking at a WinMerge comparison between the two mods; the differences outside the DLL are minor, but there are a few.

I only use Buffy for Bull so this seems an option. But I searched for Bull source code but couldn't find any either.

 

[f1rpo]

I only use Buffy for Bull so this seems an option. But I searched for Bull source code but couldn't find any either.

It's hosted on SourceForge: latest (revision r221)
The DLL source along with the Makefile is in the SDK folder. That's version 1.3, which was never officially released. BAT is based on that version, as is my own BULL fork Taurus. BUFFY probably is based on BULL 1.2 (r185).

 

[Gingerbread Man]

Thanks for this - after struggling with the other guides out there, the guide here got me going pretty much straight away. The old guides obviously got us to this point, but they had a lot of broken links and a general old-school developer experience.

Anybody out there managed to follow these instructions, but then be able to build/debug from VSCode?

I'm happy installing VC++ Express 2010 to get the build pipeline going, but it'd be nice to work in an IDE that's free/modern. If not, happy to put up with what I've got going for now

 

[Nightinggale]

Anybody out there managed to follow these instructions, but then be able to build/debug from VSCode?

If you look in CvGameCoreDLL.vcxproj, you will see code like this:

<NMakeBuildCommandLine>set TARGET=Debug
nmake source_list /NOLOGO
nmake fastdep /NOLOGO
nmake dll  /NOLOGO</NMakeBuildCommandLine>

You can compile by running those commands even in cmd.exe or a bat file. If you want VSCode, make compile targets, which compiles using those commands and it should work. MSVC 2010 is not actually used while compiling other than the runtime is needed to run fastdep.exe so you can pretty much use whatever IDE you want. It's an open question how well it will work with the debugger, but there is only one way to figure that out, trial and error (or a lot of document reading) so go ahead.

 

[Basilmoyh]

I've had an itch to revisit building the SDK again.

I got the Bull source code, but the events all broke. Seems all $/Assets/Config/EventSigns.xml is using "CvRandomEventInterface" which is not in the source (https://sourceforge.net/p/civ4bull/code/185/tree/trunk/SDK/).

I tried using the Better BAT AI source code (which would be even better to play with) (https://sourceforge.net/projects/civ4betterbatai/files/). But, even without any code changes, the game crashes all the time. Even if I Copy the BBATAI mod, and rebuild the DLL from the supposed same source code.

 

[f1rpo]

So, you install, let's say, Better BAT AI 2.1 (the ZIP or installer from SourceForge) and it runs without apparent problems. And you also download the BBATAI 2.1 Source.zip, compile a DLL from that and replace the DLL in the Assets folder of Better BAT AI 2.1 with the new DLL. And then crashes to the desktop occur. Well, I haven't tried it myself. It's conceivable that the sources aren't entirely up to date with the assets or vice versa. The last-modified dates on SourceForge are Dec 2013 for the installer, Jan 2014 for the sources; that sounds reasonable. The ZIP release: May 2015. I would still guess that it contains the exact same assets as the installer, but the timing is less reassuring. One can always try debugging the crashes to find out more.

EventSigns: I think the intention is to add applyLandmarkFromEvent – as defined in EventSigns.py – to the original (BtS) CvRandomEventInterface module. And to do so only at runtime, without including a replacement for CvRandomEventInterface.py in the mod. And then the

<PythonCallback>applyLandmarkFromEvent</PythonCallback>

elements in BULL's Civ4EventInfos.xml are supposed to call CvRandomEventInterface.applyLandmarkFromEvent. I assume that this can work. Seems to be a non-BULL feature, i.e. not dependent on any DLL change.

edit: typo

 

[Basilmoyh]

Hmmm. I thought that error with the Events might've been a lost cause. But I remerged my personal modifications in the Assets with the Better BUG AI and I think that may've fixed the event problem. It no longer says it can't read those python files upon loading a map. So a success, may be? We'll see after a few games with Events.

The Better BAT AI might be a lost cause though. I know it kind of screws up the videos with the rebuilt SDK. Like starting a new map, it plays the '2K launcher' video (weird). And a game I was playing crashed on the turn I built the Colossus. in subsequent tests, the game was crashing all the time, even on starting new maps.

Actually, the Events issue was a caused by me after all. I had made a minor change to one of the events, editing the python in Notepad++ and it turns out didn't like that the indentation was 4 spaces instead of a tab.

 

[f1rpo]

starting a new map, it plays the '2K launcher' video (weird).

OK ...
I think you'd need to simplify the problem as much as possible. E.g. "this is the first issue that occurs with the recompiled DLL, it goes away as soon as I swap the original DLL back in." And they're both (source and release) supposedly version 2.1 from late 2013 to early 2014. Though the video issue does sound daunting to work with. Maybe with runtime assertions enabled in the DLL (Assert or Debug build configuration), something more mundane would crop up already when loading the mod or prior to the unsolicited video playback in a new game.