Adion
You didn't exactly confirm it, but does the library require a .dll ?
If so, it probably works in the debugger since it sets the working directory to the folder with the .dll, but when launching virtualdj normally the working directory will be the folder with virtualdj.exe (normally in program files)
To check this you could try to copy the dll next to virtualdj.exe in program files.
To work around this, you could try delay loading of the dll:
https://learn.microsoft.com/en-us/cpp/build/reference/delay-delay-load-import-settings?view=msvc-170
And then use LoadLibrary before calling any of the dll functions with the correct path (in the virtualdj plugins folder)
If so, it probably works in the debugger since it sets the working directory to the folder with the .dll, but when launching virtualdj normally the working directory will be the folder with virtualdj.exe (normally in program files)
To check this you could try to copy the dll next to virtualdj.exe in program files.
To work around this, you could try delay loading of the dll:
https://learn.microsoft.com/en-us/cpp/build/reference/delay-delay-load-import-settings?view=msvc-170
And then use LoadLibrary before calling any of the dll functions with the correct path (in the virtualdj plugins folder)
geposted Thu 11 Jan 24 @ 3:57 am
Ah yes in the debugger I set the working directory to the plugins folder where I have copied the DLL. I will look at delayed loading as an option.
geposted Thu 11 Jan 24 @ 7:00 pm
I may need to think of a workaround as using LoadLibrary will give me function addresses but the lib file that is linked in does this internally.
geposted Fri 12 Jan 24 @ 1:04 pm
Adion
If you use delayload, then the dll is not loaded until needed.
So this should allow you to use LoadLibrary with the correct path.
After that, since the dll is already in memory, the mapping from dll to function addresses should be done correctly by the native functions.
An alternative is indeed to get rid of the .lib entirely, and use LoadLibrary in combination with GetProcAddress, but this can be a bit more involved since you need to look up the exported function names and create function pointers for all these functions.
So this should allow you to use LoadLibrary with the correct path.
After that, since the dll is already in memory, the mapping from dll to function addresses should be done correctly by the native functions.
An alternative is indeed to get rid of the .lib entirely, and use LoadLibrary in combination with GetProcAddress, but this can be a bit more involved since you need to look up the exported function names and create function pointers for all these functions.
geposted Fri 12 Jan 24 @ 2:12 pm
Ok now I understand.
geposted Fri 12 Jan 24 @ 7:49 pm