Mobile/WinCE LoadLibrary SearchPath Bug Notes
This page describes problems with loading DLLs within the WinCE Operating System.
Overview
In the Windows Operating Systems, there are two ways for a Dynamically Linked Library (DLL) to be loaded: implicitly and explicitly.
Implicit loading happens when a function inside another DLL is referenced in an application, and that application is linked using the DLL's Library (.LIB) file. The compiler sets special information into the executable (EXE or DLL) that references the external function inside the external DLL. When the executable is loaded by the operating system, that reference is resolved, and the external DLL is searched for, found, loaded, and function fix-ups are put into place.
Explicit loading happens when an executable (EXE or DLL again) calls the function LoadLibrary (or LoadLibraryEx - or any of the char/wchar variations of these functions).
In all Windows Desktops, if you load a DLL from an absolute path, then the desktop operating system will add that DLL's directory into the search path for that DLLs run-time envorinment.
In all Windows Desktops, you also have the ability to tell the operating system that you want it to look in an alternate set of places for any other associated DLLs which might be loaded by the DLL, by calling the function LoadLibraryEx. This is done by specifying a flag LOAD_WITH_ALTERED_SEARCH_PATH.
Suppose some application dynamically loaded the DLL "C:\Program Files\Mozilla FireFox 3\xul.dll", for example. In this example, if xul.dll loaded any other DLLs (say, "nspr4.dll"), then the operating system would know to look for nspr4.dll inside the directory "C:\Program Files\Mozilla FireFox 3\"
On a Windows Desktop, if you call LoadLibraryEx with the pathname of "C:\Program Files\Mozilla FireFox 3\xul.dll", and the function flag of LOAD_WITH_ALTERED_SEARCH_PATH, then the directory "C:\Program Files\Mozilla FireFox 3\" will also be searched for any DLLs implicitly (or explicitly) loaded by the xul.dll executable.
WinCE / Windows Mobile
UNFORTUNATELY, WinCE is a very old version of Windows (based upon Windows 3.1, actually), and the WinCE operating system does not support the LOAD_WITH_ALTERED_SEARCH_PATH flag. Instead, only the directory of the EXE which loads the xul.dll executable is searched for any implicitly or explicitly loaded DLLs.
Fennec is run from a directory above the xulrunner directory, which actually contains xul.dll and other DLLs needed by xul.dll
Even worse, other applications may want to also use the binary executables located in the xulrunner directory, and may depend upon the behavior of LOAD_WITH_ALTERED_SEARCH_PATH.
OPTIONS
This leaves us with a few choices:
(1) Move fennec.exe into the xulrunner directory, and change any associated relative pathnames to reflect that move.
(2) Move the needed xulrunner DLLs into the fennec.exe directory
(3) Move the xulrunner DLLs into the \Windows directory (a directory always defined to be in the default search path for executable DLLs and EXEs.
(4) Add the xulrunner directory into the "OEM-specified search path", allowing EVERY executable to find the executable files located in the xulrunner directory.
Information
PRO (1) - Very easy and quick to do
PRO (1) - No impact on non-fennec/non-xul-supported applications
CON (1) - Does not work well for a lot of different applications
PRO (2) - As easy to do
PRO (2) - No impact on non-fennec/non-xul-supported applications
CON (2) - Duplicates DLLs, could get version skew in the duplicated DLLs
CON (2) - Feels wrong, adjusting the xul "library" to accommodate a xul-supported application
PRO (3) - Very easy and quick to do
CON (3) - Overloads most device's storage, especially for debug builds of xulrunner and fennec.
CON (3) - Adds to already over-loaded \Windows directory
CON (4) - EVERY application running on handset now sees xul "library" executables. Potential dll clashing much higher.
CON (3) - Already takes many seconds to open a file browser on \Windows
PRO (4) - Easy and Quick to do
PRO (4) - No change required to existing directory structures
PRO (4) - Works for installations of other xul-supported apps
PRO (4) - Does not overload \Windows directory
PRO (4) - Allows for xul "library" to reside on storage card
CON (4) - Not easy for novice developers to do
CON (4) - Have to remove directory from search path when removing LAST xul-supported application.
CON (4) - EVERY application running on handset now sees xul "library" executables. Potential dll clashing much higher.
CON (4) - Requires soft reset before new search path takes effect
CON (4) - Could slightly increases time for app / dll loading (~5% or so)