DLL Hell

Look up LoadLibrary()/FreeLibrary().

Ok, i will... though.... that would mean abandoning my current method of statically linking to the DLLs, is the way your suggesting the only way?
thanks
-Dan

No, each has its place.

You static link to a DLL when you know its going to be there and you need to rely on its existence. This is done in MSVC++.NET by specifying one project as a dependency of another, or by setting the linker import libraries.

You dynamic link to a DLL (using LoadLibrary()) when you:
a. might need it and don't want to load it unless necessary
b. don't know whether it exists

Plug-in systems must be implemented with dynamic linking because you don't know how many plug-ins to load. By the same token, often applications are built with several DLLs that are statically linked. One DLL might contain a custom window class, another might contain a message router for sockets, etc.

Edit: on my app I have it set up like this:
OpenIM.exe - just an entry point that loads Core.dll

Core.dll - loads plugins (also called components)and does minimal system bookkeeping (preferences, event routing, password storage)

System.dll - Win32 message reactor implementation that turns messages into functors. Components statically link to this.

Components/ContactList.dll - statically linked to Core.dll for the base class implementations. Dynamically linked BY Core.dll

If you're wondering why I don't have the executable contain everything, its mostly because executables exporting classes and functions is supposedly considered bad form.

[edited by - antareus on April 26, 2004 1:09:43 AM]

I should ask how you set a dependancy then... because this is indeed what i need to do, its not a plugin system...
edit: oh, and sorry about the n00bishness... im new to programming (well... almost a year now, but still, theres a lot i dont know because i havent needed it untill now)

[edited by - Ademan555 on April 26, 2004 1:08:53 AM]

Right click on a project and click "Project Dependencies." The build order is changed to reflect it.

If you are programming Windows I suggest you always go to msdn.microsoft.com Everything...and I mean everything you need is there. To dynamically load a dll that is not in your normal search path use:

BOOL SetDllDirectory(
LPCTSTR lpPathName
);

This is under the Platform SDK: DLLs, Processes, and Threads section. Check it out. This section also tells you the default search paths that Microsoft takes when searching for a dll. Good luck!

quote:

---

Original post by ArmitageIII87
BOOL SetDllDirectory(
LPCTSTR lpPathName
);

---

Be careful. Read further down:

quote:

---

Client: Included in Windows XP SP1.

---

I think older versions of Windows get a nice message box that says "failed to SetDllDirectory in module kernel32.dll" or something to that effect, which is Greek to most users.

Hmmm.... unfortunately its still giving me a "Cannot Find GfxEngine.dll" messagebox when i start the program... im running in debug mode... all required DLLs are part of the same project as the exe... and their projects have been set as dependancies of the exe.... but it still doesnt like it...it compiles fine.. but wehen it runs it gives me the above error... this mean i need to change my working directory? or what?

oh and by the way thanks for working on this with me
-Dan

Since you are statically linking, they will need to be in the system DLL *search* paths. At least I think so -- most of my DLL knowledge is gleaned from experience and MSDN. Put the DLLs alongside the executable so they can be found, because that is the first location they are searched.

Dynamic linking lets you put them pretty much wherever.

Edit 2: I see whats wrong. When you are building solutions that use DLLs, you will want to set the output directory of all the projects to be some folder so you don't have to copy them each time. Some people use Bin, I use one called "Builds" with separate folders for Debug and Release. The setting is located under Project Properties (right click on Project).

[edited by - antareus on April 26, 2004 1:24:11 AM]

[edited by - antareus on April 26, 2004 1:27:31 AM]

So theres no way to specify other "search paths" ?
-Dan

Specifying another searchpath would not be logical since you need to ship the dll with you program. Common practice is to have the dll's in the same directory as the exe.

if your dir structure is this:

/GfxDll/proj.vcproj & /Debug
/Launcer/proj.vcproj & /Debug
/solution.sln

Just add a
/runtime
directory to a common root directory(probebly in the same directory as the .sln)and set it so that both working directory and output directory for your dll builds and the exe.

[edited by - peter_b on April 26, 2004 1:46:25 AM]

[edited by - peter_b on April 26, 2004 1:47:19 AM]

Sure I''ll agree that it is "common" practice to put dll''s in the same directory as the executable, but at my current job (www.accelchip.com)...we don''t. Doesn''t make since to in our case...we know what path our dll''s are in..set the path and voila...loading dll''s in a different directory than our exe. Anywho...yes I knew about the WinXP caveat as well. Why would you program to support 98, 98, Me....I''d be curious as to how many people are still running the legacy OS''s.

Ademan555...I''d be more than happy to take a look at your code for ya and point you in the right direction. Post it here or we can work something out where you can email me. If you''re interested. No worries if you want to figure it out on your own.

Sorry for the late reply, i have school today... so i hadta sleep, but, i dont think ill be using that function... im trying to target as many machines as possible, even back to windows 95 (though i doubt anyone with a computer from then has a dx9.0 capable video card, though i do know one person lol)
Personally i was hoping there was a way t ostatically link, because they are game dll''s rather than extensions, or system dll''s... Besides, I have no idea how to work with anything dynamically linked, (i mean a DLL loaded with a function at runtime) but im sure msdn can explain that to me, thanks all.
-Dan

There is a way to statically link DLLs and it was mentioned in this this thread. Apps shouldn''t be spewing DLLs into random folders, I consider it extremely rude.