I have code from BASS lib.
#ifndef BASSDEF
#define BASSDEF(f) WINAPI f
#else
#define NOBASSOVERLOADS
#endif
HSAMPLE BASSDEF(BASS_SampleLoad)(BOOL mem, const void *file, QWORD offset, DWORD length, DWORD max, DWORD flags);
I need redefine BASSDEF to call dlsym function. How can i do this?
Update:
I using this on Android NDK (Linux) i loaded bass module via function dlopen and i need to make all functions point (here is original header file of bass lib https://pastebin.com/Z2Ty9UsY ) to this loaded module via dlsym function. I need this to call all functions (from JNI inside bass.so) module easily.
Actually, BASSDEF is not a function. It's macro which is known at compile time. So let's unwrap it ourselves:
HSAMPLE WINAPI BASS_SampleLoad(BOOL mem, const void *file, QWORD offset, DWORD length, DWORD max, DWORD flags);
Whoa, just function declaration here. Now "WINAPI" is basicly __stdcall call convention (Microsoft-specific). But, looking to BASS header you provided one can find for non-WIN32 systems:
#define WINAPI
Basicly, under Linux it's just a placeholder which expands to nothing. Now function declaration looks like this:
HSAMPLE BASS_SampleLoad(BOOL mem, const void *file, QWORD offset, DWORD length, DWORD max, DWORD flags);
What's next? You would like to find this function in some shared library via dlsym?
I assume you wants something like this:
// Declare a function pointer in C++11 style
using BASS_SampleLoad_FuncPtr = std::add_pointer<decltype(BASS_SampleLoad)>::type;
// Open library you wants
void* soHandle = dlopen("your_lib_here.so", RTLD_LAZY);
// Error check!
if (nullptr == soHandle) {
// Fail here
}
// Finally, get pointe to function!
BASS_SampleLoad_FuncPtr BASS_SampleLoad = reinterpret_cast<BASS_SampleLoad_FuncPtr>(dlsym(soHandle, "BASS_SampleLoad"));
// Error check!
if (nullptr == BASS_SampleLoad) {
// Fail here
}
// Now only here it's safe to call "BASS_SampleLoad" with required params
auto sample = BASS_SampleLoad(...);
...
// Don't forget to close lib
dlclose(soHandle);
Please, NOTE!
Provided code is not tested and might contain errors. And, it's C++11 standard.
Also, for C++14 and higher replace 'std::add_pointer<...>::type' with 'std::add_pointer_t<...>'
P.S. this code valid because BASS is cross-platform library and all WinAPI-look-a-like stuff (WINAPI, QWORD, BOOL, DWORD, etc.) is defined for Linux in BASS header
Related
Feeling stupid here but why is this code giving me a syntax error in Visual
Studio when trying to compile it?
DetourAttach(&(PVOID&)true_create_file, create_file);
The compiler complains with (underlining the & after PVOID)
Error (active) E0018 expected a ')'
The code is literally copied from the Detours example page. I'm assuming it is because my containing file has a .c extension and is thus compiled as C by VS while the example has a .cpp extension and is compiled as C++.
I'm not entirely sure what's going on in this line with all the casting. Why doesn't the C compiler like it and how do I get it to compile this line?
Here's the complete listing of the code:
#include <Windows.h>
#include "detours.h"
#pragma comment(lib, "detours.lib")
static HANDLE(WINAPI *true_create_file) (LPCSTR file, DWORD access,
DWORD share, LPSECURITY_ATTRIBUTES sec, DWORD disp, DWORD flags,
HANDLE tmpl) = CreateFileA;
HANDLE WINAPI create_file(LPCSTR file, DWORD access, DWORD share,
LPSECURITY_ATTRIBUTES sec, DWORD disp, DWORD flags, HANDLE tmpl) {
}
int hook_create_file() {
DetourTransactionBegin();
DetourUpdateThread(GetCurrentThread());
/* syntax error */
DetourAttach(&(PVOID&)true_create_file, create_file);
DetourTransactionCommit();
}
PVOID is defined as
typedef void *PVOID;
The &(PVOID&) part: cast the parameter to a reference to a pointer to void first, and then taking the address of that. As comment point out, you compile it as C, but the reference operation do not exist in C. So the compiler recognizes "&" as taking address, but only ")" behind it, then get the expected a ')' error.
Since PVOID& doesn't make sense here, just to increase readability. You could use PVOIDinstead of PVOID& here:
DetourAttach(&(PVOID)true_create_file, create_file);
You could also get the DetourAttach function details from here.
I am trying to port a 32-bit dll (and application) to 64-bit and I have managed to build it without errors. When trying to load it with my 64-bit application I noticed that the exported function names differ. This is how I export the functions:
#ifdef __cplusplus
extern "C" {
#endif
__declspec(dllexport) long __stdcall Connect(char * name, long size);
#ifdef __cplusplus
}
#endif
In Dependency Walker the exported functions have the following format:
32-bit: _Connect#8
64-bit: Connect
In the application using the dll I explicitly load the dll (LoadLibrary is successful) but GetProcAddress fails for 64-bit because it cannot find a function with the provided name.
In our application I keep the function names as follows:
#define ConnectName "_Connect#8"
...
GetProcAddress(Dll, ConnectName);
So I was wondering if it is possible to export the same function names for both 32-bit and 64-bit dlls or is this a bad idea? Or do I need to do the following in my applications:
#if _WIN64
#define ConnectName "Connect"
#else
#define ConnectName "_Connect#8"
#endif
I appreciate any help.
An option you have to export function names without any decoration (independently from the particular calling convention you used in x86, __stdcall, __cdecl, or other) and with the same undecorated name in both x86 and x64 builds, is to export your DLL functions using DEF files.
E.g. you could add a .DEF file like this to your project:
LIBRARY YOURDLL
EXPORTS
Connect #1
AnotherFunction #2
... etc. ...
Repro Follows
Create an empty solution in Visual Studio (I used VS2013), and inside that create an empty Win32 console project (the test client) and an empty Win32 DLL project (the test DLL).
Add this NativeDll.def .DEF file in the DLL project:
LIBRARY NATIVEDLL
EXPORTS
SayHello #1
Add this NativeDll.cpp C++ source code in the DLL project:
///////////////////////////////////////////////////////////////////////////////
//
// NativeDll.cpp -- DLL Implementation Code
//
///////////////////////////////////////////////////////////////////////////////
#include <Windows.h>
#include <atldef.h>
#include <atlstr.h>
//
// Test function exported from the DLL
//
extern "C" HRESULT WINAPI SayHello(PCWSTR name)
{
//
// Check for null input string pointer
//
if (name == nullptr)
{
return E_POINTER;
}
try
{
//
// Build a greeting message and show it in a message box
//
CString message;
message.Format(L"Hello %s from the native DLL!", name);
MessageBox(nullptr, message, L"Native DLL Test", MB_OK);
// All right
return S_OK;
}
//
// Catch exceptions and convert them to HRESULT codes
//
catch (const CAtlException& ex)
{
return static_cast<HRESULT>(ex);
}
catch (...)
{
return E_FAIL;
}
}
Add this NativeClient.cpp C++ source code in the client test project:
///////////////////////////////////////////////////////////////////////////////
//
// NativeClient.cpp -- EXE Test Client Code
//
///////////////////////////////////////////////////////////////////////////////
#include <Windows.h>
//
// Prototype of the function to be loaded from the DLL
//
typedef HRESULT (WINAPI *SayHelloFuncPtr)(PCWSTR /* name */);
//
// Simple RAII wrapper on LoadLibrary()/FreeLibrary().
//
class ScopedDll
{
public:
//
// Load the DLL
//
ScopedDll(PCWSTR dllFilename) throw()
: m_hDll(LoadLibrary(dllFilename))
{
}
//
// Unload the DLL
//
~ScopedDll() throw()
{
if (m_hDll)
{
FreeLibrary(m_hDll);
}
}
//
// Was the DLL loaded successfully?
//
explicit operator bool() const throw()
{
return (m_hDll != nullptr);
}
//
// Get the DLL handle
//
HINSTANCE Get() const throw()
{
return m_hDll;
}
//
// *** IMPLEMENTATION ***
//
private:
//
// The wrapped raw DLL handle
//
HINSTANCE m_hDll;
//
// Ban copy
//
private:
ScopedDll(const ScopedDll&) = delete;
ScopedDll& operator=(const ScopedDll&) = delete;
};
//
// Display an error message box
//
inline void ErrorMessage(PCWSTR errorMessage) throw()
{
MessageBox(nullptr, errorMessage, L"*** ERROR ***", MB_OK | MB_ICONERROR);
}
//
// Test code calling the DLL function via LoadLibrary()/GetProcAddress()
//
int main()
{
//
// Return codes
//
static const int kExitOk = 0;
static const int kExitError = 1;
//
// Load the DLL with LoadLibrary().
//
// NOTE: FreeLibrary() automatically called thanks to RAII!
//
ScopedDll dll(L"NativeDll.dll");
if (!dll)
{
ErrorMessage(L"Can't load the DLL.");
return kExitError;
}
//
// Use GetProcAddress() to access the DLL test function.
// Note the *undecorated* "SayHello" function name!!
//
SayHelloFuncPtr pSayHello
= reinterpret_cast<SayHelloFuncPtr>(GetProcAddress(dll.Get(),
"SayHello"));
if (pSayHello == nullptr)
{
ErrorMessage(L"GetProcAddress() failed.");
return kExitError;
}
//
// Call the DLL test function
//
HRESULT hr = pSayHello(L"Connie");
if (FAILED(hr))
{
ErrorMessage(L"DLL function call returned failure HRESULT.");
return kExitError;
}
//
// All right
//
return kExitOk;
}
Build the whole solution (both the .EXE and the .DLL) and run the native .EXE client.
This is what I get on my computer:
It works without modifications and with the undecorated function name (just SayHello) on both x86 and x64 builds.
__stdcall is not supported (and is ignored) on x64. Quoting MSDN:
On ARM and x64 processors, __stdcall is accepted and ignored by the compiler; on ARM and x64 architectures, by convention, arguments are passed in registers when possible, and subsequent arguments are passed on the stack.
The calling convention on x64 is pretty much __fastcall.
Since the calling conventions and name decoration rules on x86 and x64 differ, you have to abstract this somehow. So your idea with #if _WIN64 goes in the right direction.
You can examine x86 calling conventions and your needs and perhaps devise a macro which could automate the name selection process.
As you can tell, in 64-bit Windows names are not decorated.
In 32-bit __cdecl and __stdcall symbols, the symbol name is prepended by an underscore. The trailing '#8' in the exported name for the 32-bit version of your example function is the number of bytes in the parameter list. It is there because you specified __stdcall. If you use the __cdecl calling convention (the default for C/C++ code), you won't get that. If you use __cdecl, it makes it much easier to wrap GetProcAddress() with something like:
#if _WIN64
#define DecorateSymbolName(s) s
#else
#define DecorateSymbolName(s) "_" ## s
#endif
then just call with
pfnConnect = GetProcAddress(hDLL, DecorateSymbolName("Connect"));
pfnOtherFunc = GetProcAddress(hDLL, DecorateSymbolName("OtherFunc"));
or something similar (error checking omitted in example).
To do this, remember to declare your exported functions as:
__declspec(dllexport) long __cdecl Connect(char * name, long size);
__declspec(dllexport) long __cdecl OtherFunc(int someValue);
In addition to being easier to maintain, if during development the signature of an exported function changes, you don't have to screw around with your #define wrappers.
Downside: if during development the number of bytes in a given function's parameter list changes, it will not be caught by the application importing the function because the changing the signature will not change the name. Personally, I don't think this is an issue because the 64-bit build would blow up under the same circumstances anyway as the names are not decorated. You just have to make sure your application is using the right version of the DLL.
If the user of the DLL is using C++, you can wrap things in a better way using C++ capabilities (wrap the entire explicitly-loaded library in a wrapper class, e.g.):
class MyDLLWrapper {
public:
MyDLLWrapper(const std::string& moduleName); // load library here
~MyDLLWrapper(); // free library here
FARPROC WINAPI getProcAddress(const std::string& symbolName) const {
return ::GetProcAddress(m_hModule, decorateSymbolName(symbolName));
}
// etc., etc.
private:
HMODULE m_hModule;
// etc.
// ...
};
There's actually a lot more you can do with a wrapper class like this, it's just an example.
On edit: since OP mentioned using PInvoke in the comments - if anyone decides to do this, do not forget to add CallingConvention = CallingConvention.Cdecl in the [DllImport] declaration when using PInvoke. __cdecl might be the default for unmanaged C/C++, but is not the default for managed code.
For Win32 build:
If you use __stdcall, you will get something like this (dumped with dumpbin /exports):
__declspec(dllexport) int __stdcall
->
ordinal hint RVA name
1 0 00001240 _F1#0 = _F1#0
2 1 0000124D _F2#0 = _F2#0
And you have to use GetProcAddress("_F1#0") to locate the function pointer.
If you use __cdecl, you will get something like this:
__declspec(dllexport) int __cdecl
->
ordinal hint RVA name
1 0 00001240 F1 = _F1
2 1 0000124D F2 = _F2
And you can use GetProcAddress("F1") to locate the function pointer.
BTW, if you add a XXX.def file to your Visual Studio project. One more link option will be silently added to your linker command line /DEF:"XXX.def" in the All Options window. And if you change your .def file name later for whatever reason, this link option doesn't change accordingly. You need to manually change the def file name in the project properties window.
I have an existing file on the computer and I was wondering if it is possible to know when it was made, Size of the file, and more properties on the file..
I tried to use in ifstream But there's the information I have on file
(I'm using Visual C++ 6.0,Cannot using Boost)
Look at function GetFileAttributesEx.
#include <windows.h>
WIN32_FILE_ATTRIBUTE_DATA fInfo;
GetFileAttributesEx("test.dat", GetFileExInfoStandard, &fInfo);
The WIN32_FILE_ATTRIBUTE_DATA contains a lot of the "common" file informations (size, creation/edit time, attributes).
Update: I just saw, that you're using Visual C++ 6. Since GetFileAttributesEx is supported since Windows XP it might not be available in your WIN API headers... You can use the function by dynamic linking. The following code does the same thing as the snippet from above:
/* clone definition of WIN32_FILE_ATTRIBUTE_DATA from WINAPI header */
typedef struct file_info_struct
{
DWORD dwFileAttributes;
FILETIME ftCreationTime;
FILETIME ftLastAccessTime;
FILETIME ftLastWriteTime;
DWORD nFileSizeHigh;
DWORD nFileSizeLow;
} FILE_INFO;
/* function pointer to GetFileAttributesEx */
typedef BOOL (WINAPI *GET_FILE_ATTRIBUTES_EX)(LPCWSTR lpFileName, int fInfoLevelId, LPVOID lpFileInformation);
HMODULE hLib;
GET_FILE_ATTRIBUTES_EX func;
FILE_INFO fInfo;
hLib = LoadLibrary("Kernel32.dll");
if (hLib != NULL)
{
func = (GET_FILE_ATTRIBUTES_EX)GetProcAddress(hLib, "GetFileAttributesExW");
if (func != NULL)
{
func("test.dat", 0, &fInfo);
}
FreeLibrary(hLib);
/*
** Don't call func after FreeLibrary !!!
** It should be ok since kernel32.dll is loaded by your application anyway but if
** you get a function pointer from a dll only loaded by LoadLibrary the function
** pointer is invalid once the library if freed.
*/
}
The size and creation data (and more) are available via FindFirstFile.
I am new to the DLL world. I have been given a Win32 DLL which has a lot of functions. Need to call these DLL functions from C++
I want to call CreateNewScanner which creates a new scanner object and get the results in C++.
Function mentioned in the DLL is:
BOOL CreateNewScanner(NewScanner *newScan);
and NewScanner is a struct, as below,
// Structure NewScanner is defined in "common.h" .
typedef struct{
BYTE host_no; // <- host_no =0
LONG time; // <- command timeout (in seconds)
BYTE status; // -> Host adapter status
HANDLE obj; // -> Object handle for the scanner
}NewScanner;
How will I call this function? Started with C++ and here is what I managed,
#include <iostream>
#include <windows.h>
using namespace std;
int main(){
HINSTANCE hInstance;
if(!(hInstance=LoadLibrary("WinScanner.dll"))){
cout << "could not load library" << endl;
}
/* get pointer to the function in the dll*/
FARPROC handle = GetProcAddress(HMODULE(hInstance), "CreateNewScanner");
if(!handle){
// Handle the error
FreeLibrary(hInstance);
return "-1";
}else{
// Call the function
//How to call here??
}
}
First of all, return "-1" is no good. You are expected to return an integer. So you surely mean return -1.
Now to the question. Instead of declaring the function pointer as FARPROC, it's easier to declare it as a function pointer type.
typedef BOOL (*CreateNewScannerProc)(NewScanner*);
Then call GetProcAddress like this:
HMODULE hlib = LoadLibrary(...);
// LoadLibrary returns HMODULE and not HINSTANCE
// check hlib for NULL
CreateNewScannerProc CreateNewScanner =
(CreateNewScannerProc) GetProcAddress(hlib, "CreateNewScanner");
if (CreateNewScanner == NULL)
// handle error
// now we can call the function
NewScanner newScan;
BOOL retval = CreateNewScanner(&newScan);
Having said all of that, usually a library will come with a header file (yours clearly does so you should include it) and a .lib file for load-time linking. Make sure that you pass the .lib file to your linker and you can simply do this:
#include "NameOfTheHeaderFileGoesHere.h"
....
NewScanner newScan;
BOOL retval = CreateNewScanner(&newScan);
No need to mess around with LoadLibrary, GetProcAddress and so on.
If you want to follow the LoadLibrary/GetProcAddress/FreeLibrary approach, consider the following "code path" (note that if you have the DLL public header file and the corresponding .lib file, just #include the public DLL header, and link with the .lib file, and just use the function whose prototype is defined in the DLL header as you would do with an ordinary C function called from C++ code).
Define a typedef for a pointer to the function exported from the DLL.
Note that the calling convention is specified (usually, Win32 DLLs with pure-C interfaces use __stdcall calling convention):
//
// Prototype of the DLL function, with *calling convention* specified
// (usually it's __stdcall for DLL with pure-C interface).
//
typedef BOOL (__stdcall *CreateNewScannerPtr)(NewScanner *);
Then you try loading the DLL using LoadLibrary:
//
// Try loading the DLL.
//
HMODULE hDll = LoadLibrary(L"WinScanner.dll"); // <--- Note the use of L"..." for Unicode
if (! hDll)
{
.... error
}
Note that the file name of the DLL is a Unicode string (note the L"..." decoration). In general, you should use Unicode in modern C++/Win32 code.
Then you can try getting the function pointer using GetProcAddress:
//
// Try getting the pointer to CreateNewScanner DLL function.
//
auto pCreateNewScanner = reinterpret_cast<CreateNewScannerPtr>
(
GetProcAddress
(
hDll, // DLL handle
"CreateNewScanner" // Function name
)
);
if (! pCreateNewScanner)
{
.... error
// Release the DLL
FreeLibrary(hDll);
// Avoid dangling references
hDll = nullptr;
}
Note that since you are using C++, it's better using C++-style casts (like reinterpret_cast<> in this case), instead of old C-style casts.
Moreover, since the type of the function pointer is specified in reinterpret_cast, it's useless to repeat it at the beginning of the statement, so the new C++11's keyword auto can be used.
You can use the returned function pointer to call the DLL function:
BOOL retCode = pCreateNewScanner( .... );
// Note: some other common prefix used in this case is "pfn"
// as "pointer to function" (e.g. pfnCreateNewScanner).
Once you have finished using the DLL, you can release it, calling FreeLibrary:
//
// Release the DLL
//
FreeLibrary(hDll);
hDll = nullptr;
In addition, note that you can use the C++ RAII pattern, and define a class with a destructor that automatically frees the DLL (this simplifies the code that manages the library loading/releasing parts).
e.g.
class RaiiDll
{
public:
// Load the DLL.
explicit RaiiDll(const std::wstring& filename) // may also provide an overload
// with (const wchar_t*)
{
m_hDll = ::LoadLibrary(filename.c_str());
if (! m_hDll)
{
// Error
throw std::runtime_error("Can't load the DLL - LoadLibrary() failed.");
// .... or use some other exception...
}
}
// Safely and automatically release the DLL.
~RaiiDll()
{
if (m_hDll)
{
::FreeLibrary(m_hDll);
m_hDll = nullptr;
}
}
// Get DLL module handle.
HMODULE Get() const
{
return m_hDll;
}
private:
HMODULE m_hDll; // DLL instance handle
//
// Ban copy (if compiler supports new C++11 =delete, use it)
//
private:
RaiiDll( RaiiDll & );
RaiiDll & operator=( RaiiDll & );
};
Then, in some code block, you can have:
{
// Load the library (throws on error).
RaiiDll scannerDll(L"WinScanner.dll");
// Get DLL function pointer
auto pCreateNewScanner = reinterpret_cast<CreateNewScannerPtr>(
GetProcAddress(scannerDll.Get(), "CreateNewScanner"));
if (! pCreateNewScanner)
{
.... error.
}
.... use the function
} // <--- DLL automatically released thanks to RaiiDll destructor!!!
Note how code is simplified thanks to automatic invocation of RaiiDll destrutor (and so of FreeLibrary), also in the error path case.
I need to port the inline assembler to be able to compile on x64.
I'm trying to get familiar with the x64 Intrinsics etc but I guess someone being into it could easily help me out.
void __stdcall Hook(P1, P2)
{
__asm pushad
static void* OriginalFunctionPointer =
GetProcAddress(GetModuleHandleA("Some.dll"), "[...]");
// [...]
__asm popad
__asm push (P2)
__asm push (P1)
__asm call (OriginalFunctionPointer)
}
seems you need a hooking library like this one(or this if you want a C++ API) along with a function proto, then no inline assembly is needed, in 32 or 64-bit mode. also, those pushad/popad's aren't needed when you are doing inline assembly.
typedef void (__stdcall*myfp)(int,int);
void __stdcall MyHook(int arg1, int arg2)
{
static myfp TheFP = (myfp)GetProcAddress(GetModuleHandleA("Some.dll"), "[...]");
//your extra code
TheFP(arg1,arg2);
}
of course the injection of this hook needs to take place somewhere else.
for hooking classes you need to account for the hidden this pointer (pDevice in this case):
#define D3D8FUNC(name,...) typedef HRESULT (__stdcall * name)(__VA_ARGS__)
D3D8FUNC(D3D8SetTexture,void* pDevice, DWORD dwStage, void* pTexture);
HRESULT __stdcall D3DSetTexture(void* pDevice, DWORD dwStage, void* pTexture)
{
LOG("[D3DSetTexture][0x%p] Device: 0x%p Stage: %u Texture: 0x%p\n",_ReturnAddress(),pDevice,dwStage,pTexture);
return Direct3D::gpfD3D8SetTexture(pDevice,dwStage,pTexture);
}
//in the init
Direct3D::gpfD3D8SetTexture = System::VirtualFunctionHook<Direct3D::D3D8SetTexture>(Direct3D::gpDevice,61,D3DSetTexture);