Link errors with native coding

[Fulcrum]

Hi everyone,

I'm trying to build a small native anti-cheat system for cheats ACE doesn't detect,
but I've stumbled onto a problem.

My Visual Studio 2010 gives me linker errors when I'm trying to compile the dll.

Code: Select all

1>Main.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall UClass::UClass(enum ENativeConstructor,unsigned long,unsigned long,class UClass *,class UClass *,class FGuid,char const *,char const *,char const *,unsigned long,void (__cdecl*)(void *),void (__thiscall UObject::*)(void))" (__imp_??0UClass@@QAE@W4ENativeConstructor@@KKPAV0@1VFGuid@@PBD33KP6AXPAX@ZP8UObject@@AEXXZ@Z)
1>Main.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual int __thiscall UObject::ScriptConsoleExec(char const *,class FOutputDevice &,class UObject *)" (__imp_?ScriptConsoleExec@UObject@@UAEHPBDAAVFOutputDevice@@PAV1@@Z)
1>Main.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) void __cdecl appUnwindf(char const *,...)" (__imp_?appUnwindf@@YAXPBDZZ)
1>Main.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static char const * __cdecl UObject::StaticConfigName(void)" (__imp_?StaticConfigName@UObject@@SAPBDXZ)

When I look at the exports of Core.lib I see "appUnwindf@@YAXPBDZZ", not "__imp_?appUnwindf@@YAXPBDZZ".
Then when I change the definition of appUnwindf in one of the .h files, so I get "appUnwindf@@YAXPBDZZ", I still get the error.

My project files: http://speedy.sh/vmMMB/BTAC.zip

Thanks a ton if you can help me.

BTW:
I used "fixed" header files from http://kentie.net/article/d3d10drv/files/src/games.zip.
They're basically the official headers but fixed to work with visual studio.

[anth]

The official headers don't actually need any fixes (unless you're going to use multiple threads, in which case you have to patch out the intercepted memory allocation functions UEngine uses). Then about those exports: UEngine is written in C++ and as a result, all symbols which need to be visible to the outside (i.e. exported from the dll/lib file) are decorated. When a function name is decorated, the types of the function arguments are encoded into the name. As you can see here:

Code: Select all

C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC>undname ?appUnwindf@@YAXPBDZZ
Microsoft (R) C++ Name Undecorator
Copyright (C) Microsoft Corporation. All rights reserved.

Undecoration of :- "?appUnwindf@@YAXPBDZZ"
is :- "void __cdecl appUnwindf(char const *,...)"

The __imp__ prefix that is prepended to the name by the linker just indicates that the linker is trying to resolve information about a symbol that is not defined by the local compilation unit. Normally, this information can be found in the .lib files you're linking with. If you're seeing "unresolved external symbols", the linker is just telling you that none of the .lib files you're linking with export information about that specific symbol. In your case, you're not (or not properly) linking with Core.lib. Make sure that Core.lib is in your list of "Additional Dependencies" (Project Properties -> Configuration Properties -> Linker -> Input).

I'll send you a reply on ua.org with regards to the undetected cheats later.

[Fulcrum]

I already had Core.lib in my linker settings. When I leave it out I get 34 more link errors.

[anth]

Then you're seeing unicode issues. The compiler is somehow recognizing TCHARs as 1 byte chars.

[Fulcrum]

Yes you could be right.

I already had "UNICODE, _UNICODE,WIN32, WINDOWS, _WINDOWS" in my Linker>PreProcessor>Definitions.
I now tried to define them in my file using the #define directive and I am now getting different errors.
It looks like my compiler just discards the PreProcessor Definitions in Project Properties.
I'll try to solve the errors and report here again.

edit:
I fiddled around with the unicode settings and it finally worked.
I had to put "Treat wchar_t as built in type" to No in C++>Language.
Ty Anthrax.

[Feralidragon]

I had to put "Treat wchar_t as built in type" to No in C++>Language.

I am not a native coder (yet, unfortunately, gotta learn it sometime), so I am not aware of the problems that may occur.
But that "fix" is oddly familiar to me, I think that's actually the most common problem with newer visual studio versions relative compiling something for good old UT.

Anthrax, could you confirm this please, is this a common problem? Perhaps we should start a sticky dedicated to native coding with these common problems (I hate to be so powerless in helping these users since I don't know much about C++, about 6 years since I touched any of it and it was just do stuff in console, cin's and cout's rofl, so perhaps in these cases users could be directed to an already existing FAQ of some sort).

[Fulcrum]

Seems like a great idea.

Another thing I had to change:
In General properties you've got to change Character Set to Unicode.

[anth]

I had to put "Treat wchar_t as built in type" to No in C++>Language.

I am not a native coder (yet, unfortunately, gotta learn it sometime), so I am not aware of the problems that may occur.
But that "fix" is oddly familiar to me, I think that's actually the most common problem with newer visual studio versions relative compiling something for good old UT.

Anthrax, could you confirm this please, is this a common problem? Perhaps we should start a sticky dedicated to native coding with these common problems (I hate to be so powerless in helping these users since I don't know much about C++, about 6 years since I touched any of it and it was just do stuff in console, cin's and cout's rofl, so perhaps in these cases users could be directed to an already existing FAQ of some sort).

yes, it is one of the many common problems. I compiled a list of common problems a while back but it mostly consists of Linux/GCC specific problems. I'll see if I can find it when I get back home.