At 05:53 PM 10/1/96 GMT, Jeff Kauffman wrote:
[...]
>The best way to get these applications to co-exist is to take advantage of the
>windows dll search order, which is:
>
>1. working directory
>2. \windows
>3. \windows\system
>4. path
 
This is the default order for statically bound DLLs (loaded at program
load/bind time), or dynamically bound DLLS without pathnames.
[snip...]
 
>In article <[log in to unmask]>,
>   Jim Wowchuk <[log in to unmask]> wrote:
>>Theoretically, a Winsock application can allow for multiple different
>>Winsocks libraries to be present (in different subdirectories) and to access
>>the appropriate one.
>
>A winsock application simply tells windows to load "winsock.dll".  Windows
>uses the above search order and either finds one and loads it, or doesn't and
>reports an error.  The application layer does not know, and should not care,
>who's winsock it loaded.  The application is simply looking for an api to
>tcp/ip, and once it finds one, it will try to use it.  Again, this is why
[snip...]
 
While the above is true when DLLs are statically bound to a program, the
same is not necessarily true for dynamically bound DLLs without pathnames.
 
>
>>To quote the spec, "Nothing in the specification
>>should be interpreted as restricting multiple Windows Sockets DLLs from
>>being present and used concurrently by one or more Windows Sockets
>>applications.".
>
>I don't understand how this could be true.  Since the application is making a
>windows api call saying "load winsock.dll".  This call first checks to see if
>this dll is already loaded, and if so, uses it.  If not, it searches for it in
>the above order.  It would be impossible to have two winsock.dll's loaded,
>just as it would be impossible to have two ctl3d.dll's loaded.
 
Yes and no! %) Instead of statically binding the DLL to the program, you can
instead use the windows api call "LoadLibrary(Path + LibFileName)".  The
regular library search sequence ONLY IF NO PATH IS INCLUDED WITH THE
FILENAME.  Otherwise it looks for the library only in the specific library.
 
Thus if I execute a LoadLibrary("WINSOCK.DLL") while in the working
directory of \TEMP, then it will search \TEMP, \WINDOWS, \WINDOWS\SYSTEM and
all the directories described by the PATH variable.  If instead I execute a
LoadLibrary("\CSERVE\WINSOCK.DLL") then it will search for WINSOCK.DLL only
in the Compuserve directory \CSERVE.
 
Given that a WINSOCK.DLL may be statically bound to any number of other
DLLs, and that Windows will search the standard search sequence, it would be
best if the specific DLL you are dynamically loading is found in the PATH
variable!  *AND* you need to hope that such statically bound libraries are
not found in the standard search path.
 
So to the earlier statement: yes I can load two different WINSOCK.DLLS, but
no I can not have them both loaded at the same time!
 
It is possible to load (then unload) the different WINSOCK.DLLs using the
LoadLibrary call.  Unfortunately, such providence is not perfect (complete).
But no, If they have the same MODULE name, then that overrides everything.
Thus if two programs have a module name of WINSOCK (and by definition of the
'LIBRARY module definition statement' the module name and the filename,
without extension, *MUST* be the same) then only the one will be loaded.
 
A smart program could load a library, execute a WSAStartup() and check
descriptions and status information, then if not correct execute a
WSACleanup() and unload it.  Then the program could look for another using
the PATH, a .INI file or any other means it chooses.  You might want to
check that the module isn't already loaded though before continuing.
 
Still the technique can be useful to see that your program loads the correct
WINSOCK necessary for your application or reports the conflict.
 
[...]
>But that would defeat the whole purpose of the windows sockets spec.  This is
>the way it used to work in the days of dos-based tsr tcp/ip stacks.  Each one
>had a different, sometimes proprietary api, and the application could only
>talk to it if it knew explicitly about that vendor's tcp stack.  The beauty of
>the winsock spec is that any app written to winsock is supposed to work over
>any winsock-compliant tcp stack.
 
True, but not every winsock-compliant tcp stack works with every link -
especially between ethernet, serial and X.25.  So it *may* be desirable to
have such a feature.  If Compuserve knew what Microsoft were going to do in
Win95, then their problems with it may have been avoided.  (Or they simply
could have kept the library with the program, identified the application
instance location and specifically named the library.
 
Cheers.
----
Jim "seMPEr" Wowchuk
Vanguard Computer Services     Internet:    [log in to unmask]
 _--_|\                        Compu$erve:  100036,106
/      \                       Post:        PO Box 18, North Ryde, NSW 2113
\.--.__/ <---Sydney NSW        Phone:       +61 (2) 888-9688
      v      Australia         Fax:         +61 (2) 888-3056