[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).