The common "solution" to use GetProcAddress
with C++ is "extern "C", but that breaks overloading. Name mangling allows multiple functions to co-exist, as long as their signature differs. But is there a way to find these mangled names for GetProcAddress
?
相关问题
- Inheritance impossible in Windows Runtime Componen
- how to call a C++ dll from C# windows application
- how to get running process information in java?
- efficiently calling unmanaged method taking unmana
- Is TWebBrowser dependant on IE version?
相关文章
- 如何让cmd.exe 执行 UNICODE 文本格式的批处理?
- 怎么把Windows开机按钮通过修改注册表指向我自己的程序
- Warning : HTML 1300 Navigation occured?
- Bundling the Windows Mono runtime with an applicat
- Windows 8.1 How to fix this obsolete code?
- CosmosDB emulator can't start since port is al
- How to print to stdout from Python script with .py
- Determine if an executable (or library) is 32 -or
The VC++ compiler knows its own name mangling scheme, so why not use that? Inside
template<typename T> T GetProcAddress(HMODULE h, const char* name)
, the macro__FUNCDNAME__
contains the mangled name ofGetProcAddress
. That includes theT
part. So, insideGetProcAddress<void(*)(int)
, we have a substring with the mangled name ofvoid(*)(int)
. From that, we can trivially derive the mangled name ofvoid foo(int);
This code relies on the VC++ macro
__FUNCDNAME__
.For MinGW you'd need to base this on.__PRETTY_FUNCTION__
insteadUse
dumpbin /exports 'file.dll'
to get the decorated / undecorated name of all the symbols.It's impossible to do it just by using
GetProcAddress
. However, one way to do it would be to enumerate all the exported functions for that particular module, and do a pattern matching to find all the mangled names.More specifically, refer to this answer here. The only change you will need to make would be to pass in
TRUE
forMappedAsImage
parameter and the return value ofGetModuleHandle
forBase
parameter toImageDirectoryEntryToData
function call.