>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