Archived Forum Post

Index of archived forum posts


ChilkatSocket won't work from a network drive

Sep 27 '13 at 11:10

I need to make a TCP/IP connection to a remote server, and I have made a test program just to connect and make a simple string transfer.

I works fine when I run it from the pc’s C drive, but if I run it from a mapped network drive it doesn’t (I get no answer when trying to connect). My application is placed on a file server’s directory like I:MyApplicationProgramsTest.exe.

I have run SocketActiveX-9.4.1-win32.msi, and it installs nicely in C:Programs and it works even without registration.

To make my application run from the network drive, I have tried regsvr32 on all the dll’s. I have even tried to copy the dll’s to C:WindowsSystem32 and to I:MyApplicationPrograms and repeated the regsvr32. It won’t work.

Did I miss something? Any suggestions?

Sincerely, Jørgen Münster, Denmark


It's probably related to the fact that a network drive is seen as an untrusted source -- meaning that EXE's and DLL's on a non-local drive are somewhat equivalent to something that you might download. I suspect the solution is to make the network drive fully trusted by the Windows OS. I'm not a systems admin, so I don't have explicit instructions for that..

Also, an ActiveX would need to be registered. If somehow you found that it wasn't necessary, then my guess is that it was already registered. ActiveX registration (regsvr32) shouldn't be a big mysterious thing. In a nutshell, it's just a way to instantiate an ActiveX object by name. Rather than passing the path to the DLL where the object's implementation is contained, a program simply calls CreateObject (or the equivalent depending on programming language) using a name, such as "Chilkat.Zip". The Windows registry is consulted to locate the path to the DLL where that object is contained, and that DLL is then dynamically linked into the calling process (assuming it hasn't already been loaded and dynamically linked in.) All of the pitfalls and problems associated with ActiveX registration have to do with:

1) Permissions access to insert and/or modify records in the registry.

2) Understanding that there are 2 entirely separate Windows registries on a 64-bit Windows OS -- a 32-bit registry and 64-bit registry. A 64-bit DLL must be registered to the 64-bit registry (using the 64-bit regsvr32) and a 32-bit DLL must be registered to the 32-bit registry (using the 32-bit regsvr32).

3) The location where the DLL resides could cause trust issues -- preventing it from being loaded -- such as from a network drive.

4) The ActiveX DLL is deleted or moved to a different directory after registration, and thus the registry records point to a path where the DLL does not exist.