Is there a way to pass an object to another script? May be silly question but thought I would ask. Seems like it would lose its objectness. Wasn't sure about pipes but figured the same would occur.
Also, would one be able to use C# Multi-threading within a WinBatch script?
Thanks.
Jim
In order, nope and not likely.
Jim;
Curious - which particular objects?
SocketHandle from sAccept(). At least I assume it is considered an Object.
Jim
The 'SocketHandle' is as the name implies a handle. A handle is generally an index into a table and it is unlikely though not impossible that the index would have the same meaning in separate processes. It would depend to some extent on the underlying Windows socket implementation and/or luck.
It should be noted that it is not all that uncommon for system implemented handles to be usable across process. The most common example being the window handle. I don't believe that the WinSock extender obfuscates the handle in this case so the question of across process usability is dependent on the system implementation.
And this means what?...in the context of passing this handle to another script?
Jim
Quote from: JTaylor on March 15, 2015, 06:18:26 PM
And this means what?...in the context of passing this handle to another script?
Assuming that by 'different script', you mean a script running in separate a process as opposed to a script executing via a WinBatch 'Call' statement then it means I don't know whether or not the handle will be valid in a different script. The handle in question is provided by the system via the extender so its usefulness across processes depends on the system implementation and not the extender's. It is the case that some system provided handles are usable across processes and some are not. The previously mentioned window handle being the most obvious example of the former that clearly shows that system handles are sometimes shared among processes.
You should be able to devise a couple of simple test scripts to determine whether or not socket handles as returned by the 'sAccept' function are valid across processes.
Okay. Doesn't appear to work but may just be me. Not sure what you mean by "system implementation", that is, the way I configured something or the way Microsoft designed a particular version. Oh well, figured it wasn't an option anyway. Just thought I would ask as being able to process things faster would be useful. Maybe you all will get around to implementing mulit-threading one day soon :-)
Jim
In the context of the sentence "The handle in question is provided by the system via the extender so its usefulness across processes depends on the system implementation and not the extender's", "system implementation" means the operating system's implementation of the underlying functionality vs. the extender implementation. In other words, the operating system determines whether or not the handle is usable across processes and the extender does nothing to impact that usability one way or the other.
Okay. Thanks.
Jim