[SDK] Using Microsoft Visual C++ 2005 Express Edition

[Pilotis]

Kalimakhus

I bow to thee.

I've been struggling with all this for a week. "DLL Hell !"

Now my re-compiled BTS dll is running vanilla BTS. It feels like an achievement !

One miniscule step for a normal person - one giant leap for a duh-brain !!

O.K. Lie down in a darkened room for a few minutes then Mod-Mod-Mod !! See y'all on the couch !!!

Kalimakhus - thank you!

 

[Jean Elcard]

A new file named CvGameInterface.cpp was added by the 3.17 patch for BtS. If you want to succeed in building the new 3.17 DLL with your Visual Studio Express 2005/2008 you'll have to modify your old MakeFile. If you want to save some time, take my MakeFile (already modified and attached).

Don't forget to repeat step 6 of the tutorial: Changing the paths to your installation of the Microsoft Platform SDK and the Visual C++ Toolkit in the makefile.

 

[Refar]

Thanks for the new file

 

[macfanatic867]

I tried this last night after reinstalling BTS and didn't look at the patch version when I updated after the install. I could not figure out why it wouldn't work until I realized 3.17 was actually new.

Thanks Elcard for posting the updated makefile to make things easier!

 

[Chazcon]

Heh good to see the Civ 4 modding community is still alive. I keep telling myself I'm coming back but honestly, I'm deep into The Lord of the Rings Online, and if I haven't even launched a single game of Civ in two years, well...

 

[Metal Alloy Man]

Help!

I keep getting this error and my makefile is the latest so it should be fine.

------ Build started: Project: CvGameCoreDLL, Configuration: Release Win32 ------
Performing Makefile project actions
Microsoft (R) Program Maintenance Utility Version 9.00.21022.08
Copyright (C) Microsoft Corporation. All rights reserved.
NMAKE : fatal error U1073: don't know how to make 'CvArea.cpp'
Stop.
Project : error PRJ0019: A tool returned an error code from "Performing Makefile project actions"
Build log was saved at "file://c:\Documents and Settings\Administrator\My Documents\Brians Projects\CvGameCoreDLL\Release\BuildLog.htm"
CvGameCoreDLL - 2 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

 

[Kalimakhus]

The error you get means that nmake can't find the file CvArea.cpp. Make sure the file is in CvGameCoreDLL folder. You may somehow missed up the files!!

 

[Metal Alloy Man]

Now I get this error!

Performing Makefile project actions
Microsoft (R) Program Maintenance Utility Version 9.00.21022.08
Copyright (C) Microsoft Corporation. All rights reserved.
NMAKE : fatal error U1073: don't know how to make 'Final_Release'
Stop.
Project : error PRJ0019: A tool returned an error code from "Performing Makefile project actions"
Build log was saved at "file://c:\Documents and Settings\Administrator\My Documents\Brians Projects\CvGameCoreDLL\Release\BuildLog.htm"
CvGameCoreDLL - 2 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

 

[jdog5000]

You shouldn't be making "Final_Release" if you followed the directions in this thread, it should be called just "Final" ... read and follow the directions more carefully.

 

[Metal Alloy Man]

Ooops, sorry I'm going to try again now.

 

[Kalimakhus]

The original instructions uses Final_Release. I've been using this up till now without problems. What makefile you use? It seems that somehow it doesn't have a Final_Release target.

Edit: Also it is so strange that you get such error after having the one you mentioned before. The previous issue meant that your build process was fine but a source file is missing. This one means that a target is missing!!. Do you use the same makefile?

 

[glider1]

I have followed the instructions on page 1 of this thread and am using the makefile kindly supplied by Jean Elcard above. I am now successfully compiling BTS 3.17 using Visual C++ 2008 which is good and thanks to everyone on this forum for getting me this far.

However I want to debug that is the aim. This has been achieved so far:
1) I have attached the debugger to the process (BTS 3.17 running in the background at the main screen with the "Revolutions mod" loaded top right). This process would be the Beyond the Sword executable loaded into memory (I guess).

2) The "process" is already linked to the DLL in the "Revolutions mod" assets directory? This DLL I have compiled myself successfully as a Final Release DLL and copied into the Revolutions mod assets directory prior to the launch of the process and the debugging session.

These are the conceptual difficulties I am experiencing in my head:
1) What DLL is the debugger actually attached into? I ask this because as soon as I try to set a break point in the source, the debugger reports that "The breakpoint will not be hit because the symbols have not been loaded". No matter what I do, the symbol does not get loaded.

2) Can you point the debugger to any DLL location of your choice and can that DLL exist in the original build location? My intuition is telling me that in theory what I would like to do is compile a DLL straight into the asset directory and get the debugger to launch "Beyond the Sword" itself so that the link to the DLL is logically established ("in my mind only!?)

3) Curiously, although the debugger is a "attached" to a process that is already running, the output log shows that the debugger is launching a whole new process. However the process is never seen in reality (that I can make out). What is going on. That "new" process seems to be linked to the mod DLL but not the debugger DLL?

So thank you everyone so far, but for the moment I am scratching myself and thinking about eating a piece of cheese instead of getting any debugging done.

Cheers.

 

[Kalimakhus]

1 - You started BTS and loaded the mod that has your DLL in its assets folder. You attached the debugger to the BTS.exe process. Yes, the debugger is attached to your DLL no doubt about that.

2 - Attaching to a running process is technically different from starting a process under the debugger control. However for all practical uses such difference is not a real concern. You can perform all debugging actions provided that the binary (exe, or dll) supports them. The idea of building the DLL straight into the assets folder...etc. is irrelevant. You don't need to do such thing. Keep in mind that a process is controlled by an exe file you can't either start or attach to a DLL. The DLL must be loaded by an exe and you can only attach to the process started by that exe.

Now, the debugger can perform specific tasks depending on how much debugging info is available within the binary file. The symbols mentioned are this debugging info. The error you get means that there is not enough info to support setting break points. In other words the debugger can't map the machine code that is executed to the actual point of code so it can't know when the execution will hit your breakpoint.

I still recommend that you use a build target other than Final_Release to do debugging. To do so you just need to replace Final_Release wherever it is mentioned with Debug. You will also need to modify the Makefile a little. Namely for BTS3.17 you will need to add the additional two cpp files (one for plain BTS and another for 3.17) to the debug build targets.

Edit: I've just looked into the Makefile posted by Jean Elcard and you don't actually need to modify it as it seems to have all the needed targets. All you need to do is to build the debug target rather than the Final_Release target. To do so just change the commandlines you set in the properties dialog for NMake so for example it is nmake Debug rather than nmake Final_Release in the "Build Command line". The resulting DLL will be larger in size and supposedly it will run slower but it should have enough debugging info for breakpoints to work and for inspecting variables values as well.

 

[glider1]

@Kalimakhus
Thanks for clearing up the concept problem in my head

The reality is:
1) The final release build does create a PDB symbol database for the CvGameCoreDLL.dll which indicates that there are symbols being generated even if they cannot be loaded when a break point is set.

2) When you attach to the process, so long as the timestamp is correct for the DLL, the debug symbols for CvGameCoreDLL.dll get loaded. No other symbol database files get loaded.

3) If you try to create a Debug build, there is a mistake in the debug target compiler options in the makefile. There is no option /O0 and it should be /EHsc not EHsc. The Debug build will compile with /O2 /EHsc

4) However the Debug build does not link. There's probably a link option that is not right but not sure yet. Errors spitted out during linking are for example:
CvUnit.obj : error LNK2019: unresolved external symbol "__declspec(dllimport)

The questions are:
1) Do you need a symbol database file (pdb) corresponding to each cpp source file or is there just one big symbol database file for CvGameCoreDLL?

If the former is true, then Final Release is not sufficient for debugging because there is only one pdb database file generated for CvGameCoreDLL. If the latter is true, then Final Release should be good enough to do basic debugging.

2) Why does the debug build in the makefile not link while the Final Release build does link perfectly? There must be some fault in the linking options for the debug build. What would be handy would be to see the make file of a Visual Studio 2003 person not a 2008 person like myself.

Thanks for you help so far! If you are short on time, spare yourself anymore analysis. I am obviously confused and that is the reality.

Cheers.

 

[Kalimakhus]

1- there is only one pdb file for a DLL or an EXE file.
2- I can't know why a debug build doesn't work properly. AFAIK the original makefile prepared by Chazcon was created by VS 2003. In visual studio you can create a Makefile out of a VS project. The DLL sources come with a VS project for VS2003 this project was used to create the makefile. It is supposed that any build configuration in the makefile should compile and link successfully. I think that at least some have worked on the SDK in VS2003 those can tell us if they tried configurations other than Final_Release. I also don't know how Jean Elcard prepared his new Makefile for 3.17.

The creation of a pdb file means that at least some debug info was created for the DLL whether this info is enough for setting breakpoints depends on the debug options when compiling files. There are several levels of debug infos from minimum to maximum.

 

[glider1]

@Kalimakhus
Once again thankyou. Gradually step by step it's becoming clearer. There is only one PDB debug symbol database for the DLL and that is being constructed so I am getting close....

I think the problem is this:
On page one of this forum, there were three additional libraries required to compile CivGameCoreDLL. However to compile and debug CivCameCoreDLL you need at least one more library file. All of the partner libraries for debugging end in a "d". Unfortunately I don't think page one libraries are sufficient for debugging.....

I believe what is happening is this:
1) Compile and link with the /MD option uses MSVCPRT.LIB (non-debug compile lib)
2) Compile and link with the /MDd option uses MSVCPRTD.LIB (debug equivalent compile lib)

Without this extra file, and possibly others, I am screwed for debugging I think. Basically all I need for debugging is the library names ending in "d" which are the equivalents to all the libraries on page 1 of this forum.

Perhaps if someone has the time, they could upload the file from their VC 2003 directory:
C:\Program Files\Microsoft Visual C++ 2003\lib\*d.lib

Cheers.

 

[ocitalis]

Im in almost exactly the same boat as glider1. Anyone gotten vs2008 debugging?

 

[glider1]

@Ocitalis
If vs2005 express (free) works with debugging out of the box, and someone can confirm that, I'd be prepared to waste another 100MB of my current ISP plan and revert to that. However I don't think we need to because all that is required is a few small libraries....(I hope).
Cheers.

 

[jdog5000]

Can you attach VS2008 to Civ4 using the Final built DLL and do debugging on the Final build? It won't give you everything in terms of debugging but it's very useful.

I didn't have the build Debug build option working in 2005 either though I think some have gotten it working. (Now using VS2003 full)

 

[glider1]

Can you attach VS2008 to Civ4 using the Final built DLL and do debugging on the Final build?

No luck Jdog. As per a couple of posts above this one, the problem appears to be that not all the 2003 libraries required for debugging have been included on page one of this forum. The three libraries supplied there are fine for compiling but there are more libraries needed for debugging. Particularly any library *d.lib in the VC 2003 lib directory. The "d" signifies for debugging. The exact required files are:

1) Compile and link with the /MDd option uses MSVCPRTD.LIB (debug equivalent compile lib)

However that library is not supplied on page one of this forum. In fact there may even be more files needed which is why it would be nice to basically just zip up the entire 2003 lib directory and upload, or just the files *d.lib in the VC 2003 directory.

It is a bit sad that debugging is not possible yet on VC 2005/2008 for us people who want to work on civ without buying VC 2003 on ebay or via dubious means.

Any help would be appreciated for us debugging fanatics.
Cheers.