On 11/28/2011 3:56 PM, Michael S. Zick wrote:
On Mon November 28 2011, Jussi Peltonen wrote:
Mike,
Did you read the original post? Why does not the blowfish sample work
on Windows XP?
Yup,
My guess is a similar problem -
not loading the *.dll version that you expected/intended to load
or not linking against the *.dll version that you expected/intended.
M$ and *nix systems use different library locating/loading
algorithms - I can't help you with sorting out your M$ problem.
Mike
Just for your information, here are the DLL reference rules on Windows
when not using .NET mechanisms:
1. Library version numbers are only part of the DLL name if you include it
yourself when designing the library, if so, the number must go before
".DLL",
as the system does not treat the version number specially.
2. When creating a DLL, the linker also emits a "stub" library listing the
exported functions and the bare (pathless) DLL file name. This has the
same file format as a static library and is passed to Microsoft's
"/usr/bin/ld"
when linking programs that refer to the DLL. "/usr/bin/ld" does not take
.DLL files as input. Circular DLL dependencies are fully supported.
3. The decision as to which DLL file name to search for a given function
is finalized by Microsoft's "/usr/bin/ld" at static link time, based on the
information in the "stub" library. Thus there is no risk of getting a
function from another indirectly loaded DLL like on UNIX.
4. At load time, Microsoft's "/lib/ld.so" looks at the DLL file names
embedded in Programs and DLLs (which are treated almost the
same) and searches for each one in the following prioritized list of
locations:
4.1 DLLs already loaded into the current process
4.2 A list of common system DLLs (the "KnownDLLs")
4.3 The directory containing the .EXE file of the process (not
the referring DLL).
4.4 The regular PATH specified in the environment
4.5 The current directory
4.6 Give up and refuse to load.
Thus if the OpenSSL DLLs on Windows had included the API version
in their file names, only DLLs with that API version would need to be
examined, but unfortunately, this is not the case.
5. There are ways to enumerate the DLLs loaded in a given process
(easy ways for your own process, hard ways for other processes),
so you can troubleshoot if you are using the expected DLL files.
This is routinely done by debuggers, so if the OP runs his program
under a debugger, he can simply open the appropriate debugger
window and get the path to the SSLeay32*.DLL or libeay32*.DLL
actually loaded.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
