Supplement To My Last Post #3 Possible Regarding Dll Hell
HOPE THIS HELPS SOME (& that it is NOT the cause of your instability), & FOR YOUR REFERNCE(S):
=================================================================
HOW DYNAMIC LINK LIBRARIES ARE SEARCHED FOR & CALLED RULES:
------------------------------------------------------------------------------------
"DLL HELL" may occur on Win32 OS when 2 of SAME named "Dynamic Link Libraries" (.dll extension, executable with no loader header that cant self initialize) exist on a system and are accessible to a program. Since same name it can cause a program to "grab hold" of wrong version build to init for call functions it uses from it!
Can be problem that causes crash in programs because program expects function it calls to return integer return from a function but latest build of DLL of same name sends back pointer data instead!
Microsoft overcame a great deal of "DLL Hell" using ActiveX controls (OLE Servers, which have .DLL extensions also), that have .OCX extensions too. These are "marshalled" (loaded) not by name, as is done with older .DLL file types using the LoadLibrary call, but via a thing called a "GUID" (Globally Unique Identifier).
This is a 32-bit UNIQUE generated number in the registry that summons the CORRECT build the calling program requires by internally checking the .ocx or .dll file being called for its internal version information (using the functions this program uses on Version checking no doubt, std. Win32 API call method).
Microsoft has also put in "Side-by-Side" loading in their newer Operating Systems (2000/XP/2003) which can load the older type DLLs technically by name but into RAM separately, where they can be accessed separately by programs (the program that calls and finds the one it loads) so no "collisions" occur.
This is a GOOD move, but still can be problematic if the program finds the wrong version build of the .DLL it is calling, first
Order of seeks used by Win32 Portable .exe files for finding DLLs to load -
NT based Os by default, use different approaches for 32-bit vs. 16-bit apps:
1.) For 32-bit apps, NT/2000/XP/2003 search for implicitly loaded DLLs at:
a. .exe location folder
b. Current folder
c. %SystemRoot%\SYSTEM32 folder
d. %SystemRoot% folder
e. %Path% environment variable
* BUT if a DLL is listed as a KnownDLLs here in registry:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager
As REG_SZ entry type & Value of DLL name w/out the extension + data value of DLLname w/ .DLL extension, then search order becomes:
aa. %SystemRoot%\SYSTEM32.
bb. .exe file folder.
cc. Current folder.
dd. %SystemRoot% folder.
ee. %Path%.
KnownDLLs are mapped at boot time. Rernaming or moving during a session has no effect.
You can alter this behavior by including the 8.3 DLL name in the ExcludeFromKnownDlls entry, a REG_MULTI_SZ value, & one per line in that comma delimited listing.
(This makes NT believe that the DLL is not listed in KnownDLLs.)
2.) For 16-bit apps, Windows NT uses KnownDLLs for both implicitly and explicitly load DLLs. The value is at:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\WOW.
Here in that key, KnownDLLs is a REG_SZ value that lists 8.3 DOS formatted DLL names, & is separated by spaces. Without a KnownDLLs entry, WOW searches:
a. The current directory.
b. The %SystemRoot% directory.
c. The %SystemRoot%\SYSTEM directory.
d. The %SystemRoot%\SYSTEM32 directory.
e. The .exe file directory.
f. The directories in your Path.
With a KnownDLLs entry, WOW only searches for them in the %SystemRoot%\SYSTEM32 directory.
3.) Windows 2000 Service Pack #3 (at least, & thus probably XP/2003 also) has instituted the SafeDllSearchMode Value Name, a REG_DWORD data type, at this hive key folder:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager
A value of 0 keeps the current search order, & a value of 1 makes Win2k & programs search for DLLs & programs in this order:
a. Their own folder first
b. %SystemRoot%\System32
c. %SystemRoot%
e. The current directory
f. The folders in your %PATH% environment variable.
All that said: IF you follow those rules and realze that SOMETIMES, multiple .DLL versions are required on your system where they are located so programs can call the CORRECT VERSION of a .dll build, you will be ok!
Sometimes programmers DO stash a .DLL file inside the folder where their .exe program is located for GOOD REASON:
It takes up more diskspace, but assures the program will find the correct version build of the .dll called FIRST, since 2/3 times (w/out registry hacks shown previously (defaults only)) it's the first place a program looks for .dll it is instancing.
MAIN POINT:
BUT, inside the code itself, this can be made to happen thru hardcoded paths!
(Ordinarily this is frowned upon, but not in this case (to avoid .dll hell is why)).
The program can call the LoadLibrary API function to look for a file @ a certain location or can declare it @ program startup to look for the DLL to load in a certain location also!
* Application Hardcode of DLL Location Example
Examples in Delphi code (form creation instancing, not LoadLibrary call stated above):
Function CopyFileW(lpExistingFileName

ointer;lpNewFileName

ointer;bFailIfExists:Boolean):Boolean;stdcall; external "kernel32.dll"
* Note the end, "kernel32.dll" doesnt have path in front of it like "C:\Windows\system32\kernel32.dll
That is NOT hardcoded above is why and uses the rules we stated.
* Hardcoded example used to avoid DLL hell:
Function CopyFileW(lpExistingFileName

ointer;lpNewFileName

ointer;bFailIfExists:Boolean):Boolean;stdcall; external "c:\myprogram folder\kernel32.dll"
=================================================================
APK