Link to home
Start Free TrialLog in
Avatar of foxvision
foxvision

asked on

Directories and Dlls...

I have an application which has A.EXE and B.DLL in C:\MyApp\ directory. In subdirectory C:\MyApp\Sub1\ I have C.DLL and D.DLL. When A.EXE is executed, it is loaded with B.DLL as well because A.EXE is statically linked with B.DLL.

When user click a button in A.EXE, A.EXE will dynamically call C.DLL in C:\MyApp\Sub1\. C.DLL will change the current directory to C:\MyApp\Sub2\, a new directory, using ChDir(), after that, C.DLL will dynamically call D.DLL. D.DLL is statically linked with B.DLL as well which is located in C:\MyApp\.

D.DLL cannot be loaded and gives me an error saying 'A required .DLL file, B.DLL, was not found.'.

A.EXE uses CreateProcess() to call C.DLL and B.DLL is already in the memory, why can't D.DLL be loaded? Any solution to this?

I've tried this, before C.DLL calls D.DLL, it changes the directory back to C:\MyApp\, then D.DLL can be loaded.

But what I don't understand is that, how do I make D.DLL understand that B.DLL has already in the memory?

Phew...a long one...
Avatar of Madshi
Madshi

First of all: Why do you use CreateProcess('d.dll') instead of LoadLibrary('d.dll')?

However, if you use something like this:
CreateProcess(extractFilePath(ParamStr(0))+'Sub1\c.dll');
or LoadLibrary(extractFilePath(ParamStr(0))+'Sub1\c.dll');
and the same for d.dll, everything should by fine.

Regards, Madshi.
Avatar of foxvision

ASKER

Sorry, Madshi.

I temporarily reject your answer as I've made a mistake. C.DLL is C.EXE and C.EXE is loading D.DLL using LoadLibrary.

Are the answer is still the same?
I think so. Please just try it and tell me if it works. But I'm quite sure about that...

Regards, Madshi.
Maybe im not understanding fully , but you can just put all your Dll's in the Windows/System directory, and access them from there...
I hate it when all programs put their dlls into the system directory. That makes sense only when a lot of applications are using the same dll, though in such a situation there are often version problems. And if the dlls are only used by one program, it doesn't make much sense to put them into the system directory. The user who looks in the system directory sees 10.000 dlls and does not know which dll belongs to which program. It's terrible. So IMHO it is much much better to put your private dlls in your private directory!

Regards, Madshi.
Yes, Wrath, I agree what Madshi said. We have tried putting them in the SYSTEM directory in the first time and they work for us. The fact is, we don't want this, as this application is installed onto the server and we don't want only 1 or 2 files to be put into the workstations only to have a problem of updating thses files later.

Madshi, please give me a few days more to try out your solution. Thanks.
Well thats fine.. no problem,, The question was waiting on an answer and I answered the question, with an answer that worked, For some people using the systems directory is not a problem, I did not see anywhere in your question stating you did not want to use the system directory.. I apologize, im thought I was helping , dont take this as an attack, just stating my case for this situation :)
Hi Wrath, you don't need to apologize. Your suggestion works, though IMHO it's not the best one...    :-)

Regards, Madshi.
Madshi, I didn't want the path to be hard coded, is it possible? If not possible, please repost your previous answer so that I can give you the point.
ASKER CERTIFIED SOLUTION
Avatar of Madshi
Madshi

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial