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.
As much as I hated developing with COM, the application interoperability and OLE automation is a form 90s tech utopianism that I miss.
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...
That was about five years ago. :/
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)