Wow, haven't heard about COM/DCOM for over twenty years (though i had some flashbacks, when starting with gRPC).
I remember they had an evangelist named Don Box, i think he even had a tattoo on his body that had to do with COM; Now wikipedia says that he worked at microsoft until last year, i wonder what he is doing now. https://en.wikipedia.org/wiki/Don_Box
I mean, if one would tattoo some software architecture, then one would have to change the tattoo every ten years, as the subject inevitably becomes obsolete; bother!
well, almost everything becomes obsolete, with the exception of Unix; that fact could serve as an indication for the alien origin of this operating system ;-)
Another flashback from working with Windows: the MSDN CDs had the best documentation that i ever saw; no one comes even close...
Except COM isn't obsolete and since Vista is the main delivery mechanism for native APIs on Windows, UWP is basically COM with TLB replaced by .NET metadata and some ABI improvements.
You mean remoteing, then WCF, now replaced by gRPC.
However the RPC stuff you are thinking about is DCOM.
COM by itself is an OOP ABI, for dynamic libraries that can either be consumed in-proc, or out of process for safety reasons and easier cross language interoperability.
I think that DCOM can be used for communication between threads, when used in-proc with the appartment model, if memory serves me well. However in this case they are sending windows messages between the communicating threads, i think that this mechanism isn't very lightweight, as opposed to how it was advertised back then.
DCOM is for networking it should never be used in-proc, other than for the coincidence that client and server were installed on the same computer, which then begs the question why not just use COM out-of-proc anyway.
Or are you mixing it up with the workarond that allows out-of-proc COM to be configured as DCOM, which kind of works, but opens a can of worms, given that the original COM isn't network aware?
yes, was referring to DCOM being used to marshall calls between appartments, within the same process. (because gRPC is better for out of process call, on grounds of better portability between systems)
Comments
Wow, haven't heard about COM/DCOM for over twenty years (though i had some flashbacks, when starting with gRPC). I remember they had an evangelist named Don Box, i think he even had a tattoo on his body that had to do with COM; Now wikipedia says that he worked at microsoft until last year, i wonder what he is doing now. https://en.wikipedia.org/wiki/Don_Box
I mean, if one would tattoo some software architecture, then one would have to change the tattoo every ten years, as the subject inevitably becomes obsolete; bother!
well, almost everything becomes obsolete, with the exception of Unix; that fact could serve as an indication for the alien origin of this operating system ;-)
Another flashback from working with Windows: the MSDN CDs had the best documentation that i ever saw; no one comes even close...
Except COM isn't obsolete and since Vista is the main delivery mechanism for native APIs on Windows, UWP is basically COM with TLB replaced by .NET metadata and some ABI improvements.
But .NET isn't relying on COM as an RPC mechanism, isn't it? They had something else, last time that i checked.
I think that one would be better off with gRPC, if one isn't a windows only shop, and if one is working with some kind of mixed deployment.
You mean remoteing, then WCF, now replaced by gRPC.
However the RPC stuff you are thinking about is DCOM.
COM by itself is an OOP ABI, for dynamic libraries that can either be consumed in-proc, or out of process for safety reasons and easier cross language interoperability.
I think that DCOM can be used for communication between threads, when used in-proc with the appartment model, if memory serves me well. However in this case they are sending windows messages between the communicating threads, i think that this mechanism isn't very lightweight, as opposed to how it was advertised back then.
DCOM is for networking it should never be used in-proc, other than for the coincidence that client and server were installed on the same computer, which then begs the question why not just use COM out-of-proc anyway.
Or are you mixing it up with the workarond that allows out-of-proc COM to be configured as DCOM, which kind of works, but opens a can of worms, given that the original COM isn't network aware?
yes, was referring to DCOM being used to marshall calls between appartments, within the same process. (because gRPC is better for out of process call, on grounds of better portability between systems)