COM has always felt like one of those "OOP and architecture astronautism gone off the deep end" technologies. A ton of boilerplate and indirection to do very little, with the associated bloat at both development and runtime. All the times I've used it, it was not because I wanted to, but because I was forced to.
The point is that all those function calls aren't necessary, nor could the majority of them ever fail. Assigning to a field in a structure doesn't fail nor result in a function call.
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.
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.
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.
I remember reading Don Box's book, he had a clear and reasonable sounding justification for every part of COM. The trouble was when you put it all together it was a nightmare to work with. I'm still doubtful anybody really understands all of it.
To some extent .Net is an acknowledgement of that, if COM hadn't been so difficult we wouldn't have got .Net.
Comments
COM has always felt like one of those "OOP and architecture astronautism gone off the deep end" technologies. A ton of boilerplate and indirection to do very little, with the associated bloat at both development and runtime. All the times I've used it, it was not because I wanted to, but because I was forced to.
Here's a fun contrast/example:
https://docs.microsoft.com/en-us/windows/win32/dlgbox/using-...
https://docs.microsoft.com/en-us/windows/win32/shell/common-...
Non-COM: fill in a structure and call a function.
COM: make a dozen (doubly-)indirect function calls.
#2 is horrid, but could be solved by inverted if conditions and a single “cleanup:” label with goto:
Or:
The point is that all those function calls aren't necessary, nor could the majority of them ever fail. Assigning to a field in a structure doesn't fail nor result in a function call.
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.
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.
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.
I remember reading Don Box's book, he had a clear and reasonable sounding justification for every part of COM. The trouble was when you put it all together it was a nightmare to work with. I'm still doubtful anybody really understands all of it.
To some extent .Net is an acknowledgement of that, if COM hadn't been so difficult we wouldn't have got .Net.
lol #1 ... looks straightforward
... #2 brain shuts off instantly