Brad Oliver
Civ3/4 Mac programmer
One of the most common niggles with Mac Civ4 has been that Aspyr has never released an SDK for the Mac, which precludes building mods that require new game DLLs.
We've done a lot of work recently on this particular issue and I'm here to say that there's good news and bad news.
The bad news is that it's considerably harder than we were expecting. The good news is that I think we've uncovered an interesting hack that can, in theory, allow it to work.
The bad news is that a certain upcoming game will use an unorthodox hack to support mod DLLs, but you probably won't notice unless you look closely.
The good news is that once we get DLLs working in true plug-in form, we'll be patching all the relevant Mac Civ4 titles to make it work right.
If you want the nitty-gritty, the issue we ran into was that Civ4's DLL exports C++ classes through the DLL interface. From a technical standpoint, it means that Win32 imports and exports the vtable for the class, and does some magic so that non-virtual methods exported from a DLL are present in the vtable (which would otherwise only contain virtual methods). This is sadly not so with gcc, so we had to do some experimenting.
We first discovered that making all methods in the exported classes explicitly virtual works for some cases, but falls down for operator methods (e.g. operator =, the copy constructor, etc). It also fails for cases when the mod DLL's class contains extra methods or members that the importing template in the main Civ4 app is not expecting.
Needless to say, we've gone back and forth on this a few times, but I think we have a solution that will finally work, although it hasn't been put to the full test yet. We've already frozen the code for a certain app (*cough*) so we're holding off on further experimenting until it hits the wild so as not to delay it any longer - thus the "unorthodox hack" I mentioned above. I hope you all understand and bear with us while we regain our footing on Mac Civ4 once again.
We've done a lot of work recently on this particular issue and I'm here to say that there's good news and bad news.
The bad news is that it's considerably harder than we were expecting. The good news is that I think we've uncovered an interesting hack that can, in theory, allow it to work.
The bad news is that a certain upcoming game will use an unorthodox hack to support mod DLLs, but you probably won't notice unless you look closely.
The good news is that once we get DLLs working in true plug-in form, we'll be patching all the relevant Mac Civ4 titles to make it work right.
If you want the nitty-gritty, the issue we ran into was that Civ4's DLL exports C++ classes through the DLL interface. From a technical standpoint, it means that Win32 imports and exports the vtable for the class, and does some magic so that non-virtual methods exported from a DLL are present in the vtable (which would otherwise only contain virtual methods). This is sadly not so with gcc, so we had to do some experimenting.
We first discovered that making all methods in the exported classes explicitly virtual works for some cases, but falls down for operator methods (e.g. operator =, the copy constructor, etc). It also fails for cases when the mod DLL's class contains extra methods or members that the importing template in the main Civ4 app is not expecting.
Needless to say, we've gone back and forth on this a few times, but I think we have a solution that will finally work, although it hasn't been put to the full test yet. We've already frozen the code for a certain app (*cough*) so we're holding off on further experimenting until it hits the wild so as not to delay it any longer - thus the "unorthodox hack" I mentioned above. I hope you all understand and bear with us while we regain our footing on Mac Civ4 once again.
