2 ms·

Non-COM: The function needs to be in your process. Unless you're committing deep heresy, it'll have to be written in the same language as the code you're writin

by nikanj 5y ago

Non-COM: The function needs to be in your process. Unless you're committing deep heresy, it'll have to be written in the same language as the code you're writing right now COM: The function can be in the same process. It can be in another process. That process might be written in a different language, or running on a different computer. The best we've come up with to actually mimic the COM feature set is doing HTTP. For some reason, a large subset of programmers seem to think "complex=slow", and truly believe that JSON is faster than binary-packed structures. The performance of COM is incredible. In-process servers are practically just as fast as calling native functions. Out-of-process servers are still plenty fast, because you don't have to go opening TCP sockets, doing HTTP request parsing, etc.

rossy 5y ago
> Unless you're committing deep heresy, it'll have to be written in the same language as the code you're writing right now Calling a C ABI function is deep heresy but calling a COM (subset of C++ ABI) function isn't? I bet more languages can do the former than the latter, since C functions like CreateFileW are required for file I/O in Windows. Maybe remoting makes COM worth it, but the vast majority of ordinary Windows APIs, the parent comment's GetOpenFileName/IFileDialog example included, don't need remoting or any of the other benefits of COM. I feel relieved every time I come across a Windows API implemented as a simple flat C API (like XInput!) instead of COM.
bigbizisverywyz 5y ago
>The performance of COM is incredible. Agreed, the performance of COM is pretty good in-process, and can even be extended to allow other applications to script your objects (via the IDispatch interface). So it's a pretty versatile technology, but it seems to be yesterdays' news after .net came out. To experience DCOM in your windows box now is pretty easy. Simply: Start -> Run -> 'mmc' File -> Add Remove Snapin Add 'component Services' And enjoy the spinning COM+ balls to see running COM servers. It's all still there.

by nikanj 5y ago

rossy 5y ago

> Unless you're committing deep heresy, it'll have to be written in the same language as the code you're writing right now Calling a C ABI function is deep heresy but calling a COM (subset of C++ ABI) function isn't? I bet more languages can do the former than the latter, since C functions like CreateFileW are required for file I/O in Windows. Maybe remoting makes COM worth it, but the vast majority of ordinary Windows APIs, the parent comment's GetOpenFileName/IFileDialog example included, don't need remoting or any of the other benefits of COM. I feel relieved every time I come across a Windows API implemented as a simple flat C API (like XInput!) instead of COM.

bigbizisverywyz 5y ago

>The performance of COM is incredible. Agreed, the performance of COM is pretty good in-process, and can even be extended to allow other applications to script your objects (via the IDispatch interface). So it's a pretty versatile technology, but it seems to be yesterdays' news after .net came out. To experience DCOM in your windows box now is pretty easy. Simply: Start -> Run -> 'mmc' File -> Add Remove Snapin Add 'component Services' And enjoy the spinning COM+ balls to see running COM servers. It's all still there.