3 ms·

It's been a reality on Windows for over 20 years, though. COM has made it possible to write applications on Windows and integrate with pretty much anything in i

It's been a reality on Windows for over 20 years, though. COM has made it possible to write applications on Windows and integrate with pretty much anything in it in any language with COM bindings. Glad to see Rust is now one more such language.

Kipters 6y ago
WinRT is actually built on COM, Rust/WinRT uses it under the hood
badsectoracula 6y ago
Yeah though... pretty much any natively compiled language and many interpreted/VM-based languages can use the C ABI in any modern plaform anyway, so what COM provides isn't so much the ability to use the same API from many languages but a dynamic object oriented approach for doing so. After all it isn't like you can't use the Win32 API directly from Rust - or any other language, e.g. Python.
- kevingadd 6y ago
  The type libraries are a big part of why it's so successful - you can take a typelib and auto-generate bindings, or manually generate your own bindings based on what you see. If you look at the typelibs for a given GUID, you are almost guaranteed that the API will match once you get a pointer back from a QueryInterface call (sometimes people are naughty). This is nice because you can compile all that in so the QueryInterface call is the only dynamic part of it - everything else at runtime is just regular calls through a vtable. The rigid nature of it means you can also reverse-engineer compiled code to figure out the shape of a given interface's vtable even without a typelib (I've done that a couple times). This is why you were able to manipulate COM objects from VBScript and JScript even though they were dynamic languages, and in fact VBScript could define new COM objects on the fly and then expose new methods and properties through a COM interface called IDispatch. It's all just vtables once you do your initial setup. IIRC there was a Windows version of Python for a while that had built-in support for COM interop in both directions - you could define IDispatch-based COM objects in Python and implement interfaces while consuming COM libraries using their typelibs.
  - badsectoracula 6y ago
    I wouldn't call it successful, COM is mainly used by Microsoft and pretty much nobody else uses it unless they want to interface with Microsoft's products (Office, etc). In any case, yes, this is what i meant with the dynamic part. But the comment i replied to wrote that it made "possible to write applications on Windows and integrate with pretty much anything in it in any language with COM bindings", which - as i wrote - doesn't need COM.
oaiey 6y ago
Well, just before it was selected stuff. Now it is the xml parser element node. That is a bit more than before. And the tooling changed like hell.
DeathArrow 6y ago
That's true. But developing apps for Windows seems like a small niche now. And if you don't use C#, you are in a world of pain with MFC and Win32. C++ developers asked for a nice GUI framework for ages.

Kipters 6y ago

WinRT is actually built on COM, Rust/WinRT uses it under the hood

badsectoracula 6y ago

Yeah though... pretty much any natively compiled language and many interpreted/VM-based languages can use the C ABI in any modern plaform anyway, so what COM provides isn't so much the ability to use the same API from many languages but a dynamic object oriented approach for doing so. After all it isn't like you can't use the Win32 API directly from Rust - or any other language, e.g. Python.

kevingadd 6y ago
The type libraries are a big part of why it's so successful - you can take a typelib and auto-generate bindings, or manually generate your own bindings based on what you see. If you look at the typelibs for a given GUID, you are almost guaranteed that the API will match once you get a pointer back from a QueryInterface call (sometimes people are naughty). This is nice because you can compile all that in so the QueryInterface call is the only dynamic part of it - everything else at runtime is just regular calls through a vtable. The rigid nature of it means you can also reverse-engineer compiled code to figure out the shape of a given interface's vtable even without a typelib (I've done that a couple times). This is why you were able to manipulate COM objects from VBScript and JScript even though they were dynamic languages, and in fact VBScript could define new COM objects on the fly and then expose new methods and properties through a COM interface called IDispatch. It's all just vtables once you do your initial setup. IIRC there was a Windows version of Python for a while that had built-in support for COM interop in both directions - you could define IDispatch-based COM objects in Python and implement interfaces while consuming COM libraries using their typelibs.
- badsectoracula 6y ago
  I wouldn't call it successful, COM is mainly used by Microsoft and pretty much nobody else uses it unless they want to interface with Microsoft's products (Office, etc). In any case, yes, this is what i meant with the dynamic part. But the comment i replied to wrote that it made "possible to write applications on Windows and integrate with pretty much anything in it in any language with COM bindings", which - as i wrote - doesn't need COM.

oaiey 6y ago

Well, just before it was selected stuff. Now it is the xml parser element node. That is a bit more than before. And the tooling changed like hell.

DeathArrow 6y ago

That's true. But developing apps for Windows seems like a small niche now. And if you don't use C#, you are in a world of pain with MFC and Win32. C++ developers asked for a nice GUI framework for ages.