4 ms·

Ironically these instant starting NT applications were often using COM. As much as I hated developing with COM, the application interoperability and OLE automa

by atchoo 3y ago

Ironically these instant starting NT applications were often using COM. As much as I hated developing with COM, the application interoperability and OLE automation is a form 90s tech utopianism that I miss.

TeMPOraL 3y ago
Indeed. On one project, I actually shifted quite recently from working on old-school, pre-Windows XP, DCOM-based protocols, to interfacing with REST APIs. Let me tell you this: compared to OpenAPI tooling, DCOM is a paradise. I have no first clue how anyone does anything with OpenAPI. Just about every tool I tried to turn OpenAPI specs into C or C++ code, or documentation, is horribly broken. And this isn't me "holding it wrong" - in each case, I found GitHub issues about those same failures, submitted months or years ago, and still open, on supposedly widely-used and actively maintained projects...
- nycdotnet 3y ago
  same with C#
- kbenson 3y ago
  I too was once very excited that OpenAPI specs I had access to would save me untold hours in implementing an API for a service since I could pass them through a generator, only to find once I tried everything seemed somewhat broken or the important time saving bits just weren't quite ready yet. That was about five years ago. :/
cmgbhm 3y ago
I think of the OLE demos every time I shove a google sheet into a google doc and realize it’s only a one way sync.
desi_ninja 3y ago
WinRT is COM under the covers
immibis 3y ago
In some ways COM is pretty optimized. An intra-thread COM call is just a virtual function call - no extra overhead. Otherwise it's a virtual function call to a proxy function that knows exactly how to serialize the parameters for IPC.
- benibela 3y ago
  >An intra-thread COM call is just a virtual function call - no extra overhead. There was a time when a virtual function call was a lot of overhead Even having a VMT is overhead. Sometimes the COM interface is implemented as actual interface, where the implementing class is derived from another class and the interface. (in C++ the interface is just another class with multiple inheritance, but other languages have designed interfaces). Then the class even needs to have two VMTs. Multiple VMTs have even more overhead. And with multiple VMTs, it is not just a method call. In the functions, this always points to the first VMT. But when a function from the VMT is called, the pointer points to that VMT. So the compiler creates a wrapper function, that adjusts this and calls the actual function. when methods from the later VMTs are called , this points (non-virtual thunk)

by atchoo 3y ago

TeMPOraL 3y ago

Indeed. On one project, I actually shifted quite recently from working on old-school, pre-Windows XP, DCOM-based protocols, to interfacing with REST APIs. Let me tell you this: compared to OpenAPI tooling, DCOM is a paradise. I have no first clue how anyone does anything with OpenAPI. Just about every tool I tried to turn OpenAPI specs into C or C++ code, or documentation, is horribly broken. And this isn't me "holding it wrong" - in each case, I found GitHub issues about those same failures, submitted months or years ago, and still open, on supposedly widely-used and actively maintained projects...

nycdotnet 3y ago
same with C#
kbenson 3y ago
I too was once very excited that OpenAPI specs I had access to would save me untold hours in implementing an API for a service since I could pass them through a generator, only to find once I tried everything seemed somewhat broken or the important time saving bits just weren't quite ready yet. That was about five years ago. :/

cmgbhm 3y ago

I think of the OLE demos every time I shove a google sheet into a google doc and realize it’s only a one way sync.

desi_ninja 3y ago

WinRT is COM under the covers

immibis 3y ago

In some ways COM is pretty optimized. An intra-thread COM call is just a virtual function call - no extra overhead. Otherwise it's a virtual function call to a proxy function that knows exactly how to serialize the parameters for IPC.

benibela 3y ago
>An intra-thread COM call is just a virtual function call - no extra overhead. There was a time when a virtual function call was a lot of overhead Even having a VMT is overhead. Sometimes the COM interface is implemented as actual interface, where the implementing class is derived from another class and the interface. (in C++ the interface is just another class with multiple inheritance, but other languages have designed interfaces). Then the class even needs to have two VMTs. Multiple VMTs have even more overhead. And with multiple VMTs, it is not just a method call. In the functions, this always points to the first VMT. But when a function from the VMT is called, the pointer points to that VMT. So the compiler creates a wrapper function, that adjusts this and calls the actual function. when methods from the later VMTs are called , this points (non-virtual thunk)