Please be patient in reading this, its a difficult problem to describe - TX.
Also, chances are this is a W2K socket bug, but it manifests itself only when VNC is running. I have a small test harness app that use a little VB out-of-process ActiveX exe component that wraps the Microsoft Winsock control (MSWINSCK.OCX). VNC is installed as a service and is started and all is well. Under W2K SP 2 or 3, if the VNC services is just listening, then my app runs fine. If a remote VNC connection is established first (either the viewer or the browser), then when my app starts it fails (i'll get into the details of the failure shortly). If my app runs first, and then a remote VNC connection is established all is fine. Under NT4 SP 6a - no problems, app runs fine regardless of when a VNC remote session is established. I've tested this with both WinVNC 3.3.3r9 and RealVNC 3.3.6. The nature of the failure is as follows. Under W2K, with an active VNC connection established, when my app runs it instantiates a copy of the ActiveX wrapper object (which loads an instance of the MSWINSCK control), to this point all is okay. The app then instantiates a second instance of the ActiveX wrapper object, this works, however the previous instantiation disappears. Attempting to access the first object generates a "Run-time error '462': The remote server machine does not exist or is unavailable" however accessing the second instance works fine. >From what I can tell is, ONLY under W2K, if VNC accepts a connection before my object instantiates a copy of itself VNC forces the component to only support a single instance of itself (how and why I don't know, its my just observations) -- if no connection exists prior to the object instantiating, or if connections are established after the first instance of my component, everything is fine and multiple instances of the socket wrapper can exist. As long as one instance exists prior to a connection, after a connection I can create/delete as many instances as I want. Furthermore, the exact same set of code running under NT4 works fine, which to points to a fundamental difference in how Microsoft manages the ActiveX component, specifically when VNC and MSWINSCK both try to use the socket layer. (And yes, there is no port conflicts, the problem occurs before I even try to trigger a listen or connect method of the MSWINSCK control.) If anyone is interested in tackling the problem or just in reproducing it let me know, I'll gladly zip up and email you the socket component and test app. I've been pulling what little hair I have left out for days on this, any insight would be greatly appreciated. Thanks, J.R. _______________________________________________ VNC-List mailing list [EMAIL PROTECTED] http://www.realvnc.com/mailman/listinfo/vnc-list
