Disclaimer: I've basically never looked at this project, other than a cursory glance a very long time ago.
Sounds like a function definition/body is given (with {}), when only a function prototype was expected.
void func(int param); // Prototype
void func(int param) {} // Definition
Note the semicolon versus the braces. I suspect some compilers (particularly older ones), may be more lax about checking if an imported function is defined internally.
Edit: On closer inspection, yes.
ODASL_API(int) wplInit(wplOptions *inf) { return 0; }
ODASL_API(void) wplExit() {}
ODASL_API(void) wplSetPalette(HPALETTE pal) {}
ODASL_API(int) wplGetSystemMetrics(int nIndex) { return 0; }
ODASL_API(BOOL) wplAdjustWindowRect(LPRECT lpRect, DWORD dwStyle, BOOL bMenu) { return 0; }
ODASL_API(HBITMAP) wplLoadResourceBitmap(HMODULE hModule, LPCTSTR lpName) { return NULL; }
ODASL_API(int) wplManualDialogSubclass(HWND dlg) { return 0; }
ODASL_API(void) wplEnable() {}
ODASL_API(void) wplDisable() {}
The import/export declaration is controlled in the header file starting at line 23:
#ifdef BUILDING_ODASL
#define ODASL_API(rt) __declspec(dllexport) rt __cdecl
#else
#define ODASL_API(rt) __declspec(dllimport) rt __cdecl
#endif // BUILDING_ODASL
This defaults to import mode, which is what you need. There are no guards in the .cpp file. This would seem to suggest that the .cpp file is NOT part of the main project. The header file is used to basically link the two parts together. Remove the odasl.cpp file from your project and try again.
Edit2: Just noticed a .cbp file, which is a CodeBlocks project file. The project was created a while back when CodeBlocks was the only free IDE we knew how to setup. That's probably why there are no other project files. It's just a text file. You can look at it to see what project settings it uses, and what source files it's meant to include. Check the <Unit> tags near the bottom to see which files are part of the project. Just make sure not to add any header files as if they were source code files. You do *not* compile header files, only include them from compiled modules (aka "source" files - .cpp).
Hi Hooman,
Thanks so much for your post. Sorry for not responding sooner.
There are no guards in the .cpp file. This would seem to suggest that the .cpp file is NOT part of the main project. The header file is used to basically link the two parts together. Remove the odasl.cpp file from your project and try again.....
Just make sure not to add any header files as if they were source code files. You do *not* compile header files, only include them from compiled modules (aka "source" files - .cpp).
Per your suggestions, I excluded the odasl.cpp file and all the header files from the project and tried to build it again. This eliminated the nine "definition of dllimport function not allowed" errors but unfortunately left me with the following new error:
.\OP2Script.rc(10) : fatal error RC1015: cannot open include file 'afxres.h'.
I searched my hard drive for afxres.h, and found that I don't have it, then wasted wasted considerably more time looking online for a copy of the file that I could download. The only one I could find was at koders.com (http://www.koders.com/c/fid533F9524B20EA8D5FD2C782017B543EDAFAF6711.aspx?s=afxwin.h) and it looks line some kind of dummy file, since it only contains the following three lines of code:
#ifndef AFXRES_H
#define AFXRES_H
#endif // AFXRES_H
.\OP2Script.rc(20) : error RC2144 : PRIMARY LANGUAGE ID not a number
.\OP2Script.rc(29) : error RC2135 : file not found: 907
Several places during my search I read that #include "windows.h" can be substituted for #include "afxres.h" when MFC or ATL support aren't required. So I tried that. Didn't work. Resulted in seventy-some "LNK2019: unresolved external symbol " errors!!! :( The other thing I gathered from my reading is that VC++ 2008 Express Edition doesn't have MFC or ATL support, so if either of those are required I may be screwed.
Note that I also modified the source a little to help with compiling. Some simple edits were paths in include directives. Another was the diffModifier variable was changed to an int, it was initialized to 10 times it's original values, and references to it had a "/10" added to it. That gets rid of the reliance on floating point (and extra runtime library support, which was causing link issues), and also removes the need for the pragma to disable the warnings. I believe the results should be the same, but I haven't done any runtime tests to verify. It's entirely possible I've changed behavior there due to rounding, or maybe an accidental order of operation change.
I've now had some time to test the "Plymouth Cold War" built from the project and source code that you were kind enough to place in the SVN last week. I appears that the changes you made affected at least one thing, because I played the normal level past mark 300 and the AI was still only sending single micro-lynx attack waves. When playing the original P.C.W. on normal, the AI's first starflare always seems to show up around mark 150. I suspect that the cause is in the following section; that "/10" might need to be added to the end of each of the "if" and "else if" conditions.
// Check the count and increase the AI strength as needed
if (saveData.aiCount == 10 * saveData.diffMultiplier)
{
// Starflare time
saveData.aiMassGrp.SetTargCount(curType, mapStarflare, 3 - saveData.diffMultiplier * 15 / 10);
}
else if (saveData.aiCount == 20 * saveData.diffMultiplier)
{
// Stickyfoam time
saveData.aiMassGrp.SetTargCount(curType, mapStickyfoam, 3 - saveData.diffMultiplier * 15 / 10);
}
else if (saveData.aiCount == 30 * saveData.diffMultiplier)
{
// EMP time
saveData.aiMassGrp.SetTargCount(curType, mapEMP, 3 - saveData.diffMultiplier * 15 / 10);
}
else if (saveData.aiCount == 45 * saveData.diffMultiplier)
{
// RPG time
saveData.aiMassGrp.SetTargCount(curType, mapRPG, 3 - saveData.diffMultiplier * 15 / 10);
}
else if (saveData.aiCount == 70 * saveData.diffMultiplier)
{
// ESG time
saveData.aiMassGrp.SetTargCount(curType, mapESG, 3 - saveData.diffMultiplier * 15 / 10);
}
else if (saveData.aiCount == 75 * saveData.diffMultiplier)
{
// Nova time
saveData.aiMassGrp.SetTargCount(curType, mapSupernova, 3 - saveData.diffMultiplier * 15 / 10);
}
If my guess is right, I suppose the AI will start producing starflares around mark 1500, but I'm not willing to play that long just to find out.
On the plus side, I learned enough tinkering around with your project that I was able to fix the project I'd created earlier (from BlackBox's original source), it compiled with no errors and when played the starflares show up right on time. So now I'm trying adjustments to that. When I have something that I think is worth playing, I'll start a new thread and upload the .dll so that anyone who's interested can try it.
Thank you again for all your help.