I have a program that uses gdi+.
This program consist in a main exe file and some dll plugins. Dll are loaded during program initialization (when the exe creates the main

window).
The exe imports only 2 functions from gdiplus.dll :
GdiplusStartup
GdiplusShutdown
The dll instead imports many functions.

Since I want to create other programs that use gdi+, I want to copy gdiplus.dll in a directory shared by all my programs.
When I start the exe file I will do this:
1) invoke LoadLibrary("gdiplus.dll") to check whether I'm on Xp.
2) If thw function fails I call LoadLibrary with full path to my shared gdiplus.dll
3) invoke GetProcAddress to get address of GdiplusStartup and GdiplusShutdown

I can use GetProcAddress because is easy and I have only 2 functions to load.
But I can't/don't want to use this method with the dll, because the dll is written in c++ (my project is mixed c++ / asm) and I use classes to call gdi+ methods.
How can I tell the loader where it can find the gdiplus.dll, since it isn't in the library search path?
Maybe I can use dealy loading but I don't know how it works.
I need something that can work on any os (win95, 98, nt, 2k, ....)
Posted on 2004-04-04 04:12:19 by greenant
Doesn't GDI+ redistributable have some installer that throws GDI+ into shared system folders?

Anyway, delay-load DLLs are nice, but they don't offer you very much flexibility - like trapping errors. So they're mostly useful as a load-time optimization for system DLLs, or other DLLs that you are sure will always be there.

If I recall correctly, the linker uses a static library for some of the thunk code - so you should be able to write your own. I'm at a friend's place right now though, so I can't check, sorry.
Posted on 2004-04-04 04:33:26 by f0dder
Just use SetEnvironmentVariable to add your shared directory to the search path. It will only be there as long as your process is open. The search path for DLLs includes and folders in the PATH environment variable.
Posted on 2004-04-04 04:35:01 by donkey
Doh, donkey - that's so simple that I would never have thought of it :D - and sounds like a pretty clean and efficient method. :alright: :stupid:

Still worth using delay-load though, if the GDI+ functionality isn't used right away, as it will give the illusion of faster program loading.

Only problem with the PATH variable approach is that the system dir is searched before path, so there could be potential DLL version clashes.


Too bad SetDllDirectory is only available from XP SP1 and forward :(
Posted on 2004-04-04 04:47:55 by f0dder
dokey: I will try your method
f0dder: gdiplus.dll doens't have an Installer an I don't want to copy it in the system directory because it might conflict with existing dll. I use msi to install my program and gdi+ dll
Posted on 2004-04-04 04:55:22 by greenant
Only problem with the PATH variable approach is that the system dir is searched before path, so there could be potential DLL version clashes.


But that is exactly what he wants, the existing copy in System32 if it's there if not he wants his own copy. Seems like the best solution and everything is automatic.

Greenant, you can use a bootstrap to start your program if the DLL path has to be set before it starts, just set up the environment and pass it in CreateProcess.
Posted on 2004-04-04 04:58:12 by donkey
This is the order of LoadLibrary


    [*]The directory from which the application loaded.
    [*]The current directory.
    [*]The system directory. Use the GetSystemDirectory function to get the path of this directory.
    [*]The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
    [*]The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
    [*]The directories that are listed in the PATH environment variable.


    I can put my shared folder at the top of the PATH variable
Posted on 2004-04-04 04:59:30 by greenant
Ah, ok greenant, I thought it had a redistributable. Indeed you should never drop files into the system directory yourself - first there are the obvious problems with cluttering and possibly overwriting existing DLLs, but there's also issues like requiring administrator privileges on NT systems.

To ensure *your* DLL is loaded, you could write a wrapper around LoadLibrary, which saves currenty working directory, sets working directory to where your DLL is located, and restores working directory after calling LoadLibrary. This is somewhat of a hack though, would've been nice if SetDllDirectory had existed since day one.
Posted on 2004-04-04 04:59:57 by f0dder
I don't use LoadLibrary to load the gdiplus.dll from the dll. I the loader that load the dll into my memory
Posted on 2004-04-04 07:30:48 by greenant
In XP, gdiplus.dll is not located in the system32 directory.
In fact, my machine has two copies (probably different versions), each in a subdirectory of C:\WINNT\WinSxS.

I suspect it's not a simple DLL (it may be a COM module).
Posted on 2004-04-07 21:38:45 by tenkey
Hi :)

gdiplus.dll doens't have an Installer an I don't want to copy it in the system directory because it might conflict with existing dll. I use msi to install my program and gdi+ dll

Actually it does have an installer, and you can download it from Microsoft. (In fact, I don't know if it's legal to redistribute it without the installer, or at least without it's licence).

http://www.asmcommunity.net/board/index.php?topic=17743
Posted on 2004-04-10 10:23:24 by QvasiModo