>At 04:45 PM 8/1/96 -0400, Shirley A MacLaughlin wrote:
>>Question:  How can these applications (RNS and TCPMAN) co-exist?
 
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
 
If you keep each application's winsock.dll in it's own working directory, then
you will always be loading the correct one.  If you have several apps that
need to use your lan-based winsock, but only a few that need the dial-up based
winsock, put the lan one in the path, and keep the dial-up one in the
directory with the dial-up app.
 
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
Compuserve and others got so pissed off at Microsoft for "anti-competitive
practices".  Because win95 revives its own winsock.dll even when the MS tcp/ip
stack is not installed, other vendors tcp stacks appear broken.
 
>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.
 
>Well it looks good on paper, but I've never seen anyone do it.  RNS and
>TCPMAN, in this case, are not applications but alternative transports.  Your
>actual application, like Reflection 1 needs to be 'smart' enough to search
>for multiple TCP/IPs.
 
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.
 
>If your problem was merely getting Dial-up TCP/IP, then you could use the
>Reflection Serial component of RNS 5.  Then again, I've had little success
>with that and since it is SLIP, not PPP, I've not pursued it.
 
Actually, the current shipping version is 5.1, and it has integrated SLIP and
PPP clients.
 
Thanks for listening,
Jeff
 
Jeff Kauffman                                email: [log in to unmask]
Technical Support                            phone: 206-217-7000
WRQ - Makers of Reflection Software            fax: 206-213-8038
Seattle, WA, USA