Errors trying to include and link against library

[GoogleCodeExporter]

When I try to include HadesMem into a project and include it, I get the 
following error:

1>c:\programming\projects\hadesmem\include\common\hadescommon\ensurecleanup.hpp(
587): error C2664: 'UnregisterClassA' : cannot convert parameter 1 from 'const 
wchar_t *' to 'LPCSTR'

If I switch the line to:

UnregisterClass((LPCSTR)m_ClassName.c_str(), m_Instance);

It will try to link, but I'm running into another issue and getting this error:

1>main.obj : error LNK2019: unresolved external symbol "public: struct 
HINSTANCE__ * __thiscall Hades::Memory::Injector::InjectDll(class 
boost::filesystem2::basic_path<class std::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> >,struct 
boost::filesystem2::path_traits> const &,bool)const " 
(?InjectDll@Injector@Memory@Hades@@QBEPAUHINSTANCE__@@ABV?$basic_path@V?$basic_s
tring@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@Upath_traits@filesystem2@boo
st@@@filesystem2@boost@@_N@Z) referenced in function _main

I have linked against the following libaries, made sure their path was correct:

#pragma comment (lib, "libMemory.lib")
#pragma comment (lib, "libAsmJit.lib")
#pragma comment (lib, "libBeaEngine.lib")
#pragma comment (lib, "MMHelper.lib")
#pragma comment (lib, "psapi.lib")

Code snippet:

#include "Memory.hpp"

int main (int argc, char *argv) {

    Hades::Memory::MemoryMgr memory (findProcessId ("notepad.exe"));

    Hades::Memory::Injector test (memory);
    boost::filesystem::path dll ("C:\\Programming\\Projects\\Test\\Debug\\TestDLL.dll");
    test.InjectDll (dll);

    return 0;
}

I attached the Boost.Build log file. Any ideas?

Thanks, Sam

Original issue reported on code.google.com by brko...@gmail.com on 8 Feb 2011 at 10:53

Attachments:

• Build_MSVC100_Debug_IA32_first_build.txt

[GoogleCodeExporter]

Sounds like you're compiling your code as ANSI, whereas HadesMem currently only 
supports UTF-16. I suggest moving to wide strings, as this is what Microsoft 
recommend (with good reason). Using narrow strings limits you to working within 
the current code page, and severely cripples your I18n and L10n abilities. Not 
to mention, many new APIs don't even have an ANSI version available.

Tl;dr: If you're writing new software you should be using wide strings in your 
program (or UTF-8 internally then converting to UTF-16 for system calls). The 
narrow APIs are 'deprecated'.

Original comment by therapto...@gmail.com on 7 Mar 2011 at 9:06

• Changed state: WontFix