I have a dll say "A.dll" which exports a function "int foo()". I have another dll say "B.dll" which consumes A.dll and uses the function foo() and also exports some other functions. Is it possible to export the function "int foo()" (imported from A.dll) from B.dll so that it can be consumed in a third dll "C.dll".
I want to know whether it is possible or not, I dont want workarounds like making A.dll available to the third dll. Also, I am not concerned if this is a bad design or not.
Thanks very much for your patience to read this through.
Kapil.
As soon as A.dll exports one function, this function will be available to any application (like B.dll uses it). C.dll will also be capable to import the exported functions from A.dll. Additionally, you might take the so called "Export Forwarding" (see URL) mechanism which enables one to export functions from B.dll and implemented these in A.dll (like \system32\sfc.dll exports functions that are forwarded to \system32\sfc_os.dll)
Related
This is about DLL injection.
Let's say P.exe depends on A.dll, B.dll and C.dll (implicit linking), they're private modules of P.exe.
Now I use CreateProcess with CREATE_SUSPENDED flag to launch P.exe, after that I use CreateRemoteThread to call LoadLibrary in target process to load Inject.dll, and in the same way call an initialize function of Inject.dll to do real work (things you can't do in DLLMain).
It works. But I found that calling to LoadLibrary makes A.dll, B.dll and C.dll load too - not just Inject.dll. From the Output of Visual Studio, they even load before Inject.dll, this is not what I want. You know, Inject.dll does not depend on any third-party DLLs, in fact it just depends on kernel32.dll and user32.dll.
In this case, how to load only Inject.dll ?
i have a compiled dll library but i have no documentation about it. There is a way to get the public interface of a dll (at least function names, params numbers and type).
Thanks
You would have to decompile it and analyze each function, its calling convention, parametrs count, parameters meaning (unless it comes with some PDB, but I doubt it), I've done something like this before, it's complicated work, but it can be done.
In order to retrieve the public symbols (functions and variables) exported by a Dynamic-Link Library, one can use the well-known dependency walker. Parameters and Types are only available when the associated PDB file is available (which does not seems to be your case).
You could use the OLEViewer that comes with Visual Studio to view the TypeLib of the DLL if it is a COM library. This would give you the information you need.
I have a dynamic library A.dll which consumes a static library B.lib containing a function "int foo()". When I use dumpbin (on win32, vs2010) to view the symbols in dll - foo is not visible - Is that expected? or is it Microsoft specific? I tested this on linux and that is not the case on linux.
Thanks very much for your patience to read this through.
Kapil.
Yes, this is expected. As far as the imported symbols are concerned, using dumpbin, you can see the so called Import Address Table and the Import Name Table which both (typically) exist as soon as at least one function is imported by an application (in your case A.dll). Since your application imports one function from a STATIC library (in your case B.lib), NO entry exist in the imports tables mentioned above for the functions used from B.lib. Once a library is STATICALLY linked to an application, its body (code) is part of the application. As well as the functions of your application are not visible using dumpbin, the functions of the static library are not visible to dumpbin!
I have already added delay loading to my project, using the instructions in
http://msdn.microsoft.com/en-us/library/151kt790.aspx
In the "delayhlp.cpp" (a sample implementation of the DLL load helper) __HrLoadAllImportsForDll, I saw that the writer avoids using any Standard C Library (MSVCRT) functions. Do I need to do the same in my handler function, which will be called by the sample DLL load helper?
I think the writer's reason is that someone might try to delay-load MSVCRT itself. I'm not going to do this. Will it then be safe for me to use MSVCRT functions?
Background Info. The reason for delay-loading the 3rd party DLL is because there is a function signature change between two versions, and I need to run my program using either version. I then provide a simple wrapper function to adapt the DLL's function signature to the one needed. This function is registered by the Delay-Load Handler (__pfnDliFailureHook2), when GetProcAddress fails.
Some testing. I added a breakpoint at the beginning of my handler function. I found that when the breakpoint is hit, the msvcrt.dll and msvcr90d.dll etc are already loaded (from Visual Studio's Modules pane). Does it mean that I can call CRT functions safely?
// Check to see if it is the DLL we want to load.
// Intentionally case sensitive to avoid complication of using the CRT
// for those that don't use the CRT...the user can replace this with
// a variant of a case insenstive comparison routine.
//
That's the more relevant comment, for those that don't use the CRT. You won't have a problem, the CRT is always loaded by the startup code.
It can be used to run arbitary Dynamic Link Library in windows,
how can it possibly know the entry point of an arbitary dll?
The answer depends on how much details you need. Basically, it comes down to this:
A DLL can optionally specify an entry-point function. If present, the system calls the entry-point function whenever a process or thread loads or unloads the DLL.
[...] If you are providing your own entry-point, see the DllMain function. The name DllMain is a placeholder for a user-defined function. You must specify the actual name you use when you build your DLL.
(Taken from the MSDN article Dynamic-Link Library Entry-Point Function.)
So basically, the entry point can be specified inside the DLL, and the operating system's DLL loader knows how to look this up.
The IMAGE_OPTIONAL_HEADER (part of the portable executable's header on Windows machines) contains an RVA of the AddressOfEntryPoint that is called by programs looking for an entry point to call (e.g., the loader).
More information on the IMAGE_OPTIONAL_HEADER can be found here. And this paper is good for just general PE knowledge.
What do you mean by "run a DLL"? DLLs aren't normal programs, they are just a collection of functions. The entry point itself usually doesn't do much apart from initializing stuff required by other functions in the DLL. The entry point is automatically called when the DLL is loaded (you can use LoadLibrary to do this).
If you want to call a specific function after loading the DLL, you can use GetProcAddress to get a pointer to the function you want.