I am not really a specialist in this topic, so please excuse possible hiccups in formulating the question. We are running two programs under Windows, Zemax and Matlab, where Matlab controls Zemax via .NET COM interface. (The fact that it’s Zemax is not critical for this question, it’s just to be specific.) The Matlab code looks like this:
import System.Reflection.*;
NET.addAssembly('C:Program FilesZemax OpticStudio 16ZOS-APILibrariesZOSAPI_NetHelper.dll');
NET.addAssembly(AssemblyName('ZOSAPI_Interfaces'));
NET.addAssembly(AssemblyName('ZOSAPI'));
TheConnection = ZOSAPI.ZOSAPI_Connection();
app = TheConnection.CreateNewApplication();
...
If Matlab and Zemax are both installed on the same Windows machine, this just works. I wonder: is it possible to run such control between two machines? So that Matlab is running on one, and Zemax on another one. If yes, I make it more complex: Can Matlab running on a Linux machine control Zemax running on a Windows machine?
Or is COM strictly limited to a single Windows machine?
Advertisement
Answer
I know very little about Mathlab, and nothing about Zemax, but I’ll give you the general COM explanation.
I’m going to assume that Zemax runs in its own process and that the .NET COM server is a helper to talk to this process. If Zemax is an in-process library with a COM-enabled .NET interface, then your problems multiply.
As Alex K. mentioned, COM per-se supports use of objects across machines. Activation of COM objects across process and across machines is collectively called “DCOM” (Distributed COM). DCOM provides all the plumbing to make it possible to almost transparently access COM objects from anywhere. It can even connect to objects implemented in DLLs on another machine (with the help of an intermediary host process to hold onto the DLL on the remote server). However, things are not that simple. Not every COM object is usable across machines. If the server object (Zemax) is not designed with this scenario in mind, what you ask might range from painful to impossible.
You have to check the documentation of Zemax to see whether this is supported. And you might have to verify that the license allows it (they might have a clause that specifies that every machine using it as a client must have its own license).
There are several reason why a COM object might be unusable across machines, For example:
Some COM servers may be intrinsically machine-bound to their COM clients for reasons foreign to COM/DCOM. Maybe the interface is designed to pass machine-specific resources like local file paths, security tokens or perhaps kernel handles. If the COM object is in-process (implemented entirely in a DLL), depending on what it does, it might even be process-bound – or worse – thread-bound to the COM client.
The COM server might depend on custom “proxy/stubs” (helper code that bridges between the client and COM server) that rely on both the client and server being on the same machine (this is not likely to be the case here because the COM helper is a .NET assembly. .NET doesn’t like custom proxy/stubs).
Interfaces might be designed with local access in mind and become mindboglingly, excruciatingly, inconceivably slow when network latency enters the mix.
The COM server might be intrinsically intolerant to client disconnection. For an in-process COM object (one implemented entirely in a DLL) you can usually assume that the client lives and dies with the server. An inter-process COM object (one implemented on a process separate from the client’s) should be ready to recover sensibly if the client process crashes unexpectedly. But a COM object running across the network must basically be ready for the network connection to die, like, right now.
Finally, you still have to invoke it. Either the client program has to explicitly support cross-machine object activation (not sure if Mathlab does), or you’re going to have to tweak by hand the registry entries for Zemax on the Mathlab machine to make “remote activation on this specific machine” the default.
And you’re going to have to get the .NET library (or more generally, the COM type library) in place on the Mathlab server to begin with, because COM needs to know about the interfaces and the classes, so it can pass data between the client and the server machine. The easiest way might be to install Zemax on the Mathlab machine, even if you don’t run it there.
For the last part of the question: I know nothing about current support for COM in Linux. Once upon a time (20 years ago?) there were some semi-experimental 3rd-party products that enabled limited COM support in UNIX, but I don’t think there is anything like that anymore. In any case, it is extremely unlikely that Mathlab for Linux supports COM, so I don’t see how that would be possible.