I was add to my program reference to dll and it's work good.
Declare Function adc11_get_driver_version Lib "C:\example.dll" () As Integer
but I want to write the specific location of the dll from file(config file) and replace the "C:\example.dll" by string
how can I do this?
thanks
Saar
I think you need to do dynamic PInvoke. One way to do this is using the LoadLibrary function to load the library before .Net tries to find it. You can find some sample code here.
If you leave out the location completely, it will load it based on the current directory of the application. If it's not there, then it looks in the PATH.
If you want to do something more complex, then you need to write the LoadLibrary and GetProcAddress calls yourself in your own proxy.
Some guidance here:
http://www.codeproject.com/KB/cs/dyninvok.aspx
Related
Is there any tool by the help I can find whether a function is declared in .dll file or not.
Actually I am stuck in a problem where compiler is saying that it could not find the definition of xyz method.
Please if anyone know how can I check this thing,please Share.
I want to test msxml6.dll
Thanks
I don't know this specific DLL but you can use decompiler as IlSpy (only if this is .Net dll) for reverse engineering the dll and check if the function is there.
Update
Now I see from the tags that this is C++ so decompiler won't help here.
I need to make some exe file to load my DLL at startup...
What is the easiest way to do it?
I need this exactly, no any injectors or starters.
I though about adding one more code section into exe, rewriting to there entry point logic and placing DLL loading code, then NOPing original entry point and calling my custom made entry point function. Will this work?
Are there any other easer ways?
I also thinking about changing one of system dll name in hex editor to name of my DLL. Will this work? If my dll then load that replaced system dll?
Any thoughts?
Adding it to the PE's import table should be enough. Woodman's lists a few tools which can do it:
http://www.woodmann.com/collaborative/tools/index.php/Category:Import_Editors
I disassemled a game's DLL and want to insert some code.
I need asm code to call another DLL in the current directory(I'm on Windows).
The background is, that I want to be able to execute custom code in my DLL,
but I can't load the DLL. So my idea was to load the DLL via modified game DLL.
There may be a function in the game which gives me the current directory path the DLL's are but I think I won't find it.
The calls you are looking for are LoadLibrary, which will search in a selection of places including the current directory for the DLL and then load it, then GetProcAddress.
If the DLL makes any other Win32 calls it is probably already linked against kernel32.dll, so that's all you need to do.
It is arguable as to whether modifying the DLL or using DLL injection is faster in terms of how long it takes to write the code since you're going to have to reverse engineer anyway, however, one advantage of pure DLL injection is that all existing code remains unmodified in terms of the installation, making these modifications easier to undo should the user wish to "unpatch" whatever you are doing.
Microsoft Detours comes with setdll.exe and withdll.exe, those utilities will let you start an exe with a custom dll file.
I am in the midst of evaluating the benefits of changing our program from 30+ statically linked libraries to 30+ dynamically linked libraries. We hope by changing to DLL, it will reduce the link time.
One immediate problem is the requirement to add __declspec in front of all the classes to create the lib file for other dlls to link. Is there a way to get around that? Is there a flag in the compiler to force a lib generation so to make all classes inside the DLL available for export? If not, is there any existing script/program that will do that? That will certainly make the switch from statically linked library to a dynamic one a lot easier. If not, what is the rationale behind __declspec? Why not an option to make all dll functions exportable?
Thank you.
Perhaps it's too late, but have you looked into using a DEF file?
There is one another way to solve your problem.
You just need to create one definition file(.def) and export all the methods or class you want to share.
U will also have to set :
Properties->Linker->Input->Module Definition File -> add name of your created .def file.
Now use run time dynamic linking:
In project where you want to call the exported methods use LoadLibrary to get handle of your Dll and call the required method using GetProcAddress.
I have the following declaration in a Module:
Private Declare Function gzopen Lib "ZLIB.DLL" (ByVal filePath As String, ByVal mode As String) As Long
The following code line in a function fails, with a 'File Not Found: ZLIB.DLL' error:
lGZFileHandle = gzopen(sPath, "rb")
I'm aware that ZLIB doesn't need to be registered. My question is, where does ZLIB.DLL need to live in order for my code to work? I also know that this code is working on another machine. Currently I have ZLIB.DLL in the same folder as the application exe.
UPDATE
To my relief, the code does work when compiled. But does not work whilst running in the IDE (it does on a different machine). I still have ZLIB.DLL in the application folder.
This means that the application path must be being checked for loading the DLL.
To get around this I have tried:
Private Declare Function SetDllDirectory Lib "Kernel32" Alias "SetDllDirectoryA" (ByVal path As String) As Long
and then in the function:
SetDllDirectory App.path
This seems to allow the DLL to load, but I then get a 'Bad DLL calling convention' error instead. The plot thickens.
SOLVED
The answer seems to be here: http://www.zlib.net/DLL_FAQ.txt. It's a case of RTFM I suppose.
So, bizzarely whilst in the IDE, the STD_CALL convention is in force, but once compiled the C style calling convention suffices. It still doesn't explain why it works on a different machine in the IDE. Ho hum.
Thanks all for pointing me in the right direction.
VB6 strayed a bit from the search protocol suggested by Ken (this link is the quick reference).
The usual problem is that the .exe path (search location #1 on the list) is not the path of your VB program, but rather the VB6 IDE. So putting the DLL in the location of your VB program is no good -- unless you change the 'Start In' location of your VB6 shortcut to point to that location.
Alternately, you can put the DLL in one of the other locations specified in my link.
When running through the Visual Studio IDE, all relative files need to be placed in the following folder:
C:\Program Files\Microsoft Visual Studio\VB98\
This is because the exe that is running while debugging resides in that folder. This will allow you to debug without changing any paths.
ZLib has to be in the standard DLL load search path. See the MSDN LoadLibrary documentation for specifics on the way DLLs are found and the order of the search for them.
Are you sure ZLIB doesn't have to be registered?
I suggest you register it and try again.
EDIT
Try putting the DLL in your System folder. I believe your program will check there for it.