Comment by recursive
5 days ago
You might have been hearing some of that hate from me. I definitely don't understand COM, but I've had to use it once or twice. It's pretty far outside what I normally work on, which is all high-level garbage collected languages. I don't know if that's even the right dimension to distinguish it. I couldn't figure out how to use COM or what it's purpose was.
The task was some automated jobs doing MS word automation. This all happened about 20 years ago. I never did figure out how to get it to stop leaking memory after a couple days of searching. I think I just had the process restart periodically.
Compared to what I was accustomed to COM seemed weird and just unnecessarily difficult to work with. I was a lot less experienced then, but I haven't touched COM since. I still don't know what the intent of COM is or where it's documented, and nor have I tried to figure it out. But it's colored my impression of COM ever since.
I think there may be a lot of people like me. They had to do some COM thing because it was the only way to accomplish a task, and just didn't understand. They randomly poked it until it kind of worked, and swore never to touch it again.
> I still don't know what the intent of COM is
COM is an ABI (application binary interface). You have two programs, compiled in different languages with different memory management strategies, potentially years apart. You want them to communicate. You either
-1 use a Foreign Function Interface (FFI) provided to those languages -2 serialize/deserialize data and send it over some channel like a socket
(2) is how the internet works so we've taken to doing it that way for many different systems, even if they don't need it. (1) is how operating systems work and how the kernel and other subsystems are exposed to user space.
The problem with FFI is that it's pretty barebones. You can move bytes and call functions, but there's no standard way of composing those bytes and function calls into higher level constructs like you use in OOP languages.
COM is a standard for defining that FFI layer using OOP patterns. Programs export objects which have well defined interfaces. There's a root interface all objects implement called "Unknown", and you can find out if an object supports another interface by calling `queryInterface()` with the id of a desired interface (all interfaces have a globally unique ID). You can make sure the object doesn't lose its data out of nowhere by calling `addRef()` to bump its reference count, and `release()` to decrement it (thus removing any ambiguity over memory management, for the most part - see TFA for an example where that fails).
> where it's documented
https://learn.microsoft.com/en-us/windows/win32/com/the-comp...
> You have two programs, compiled in different languages with different memory management strategies, potentially years ap
Sometimes they are even the same language. Windows has a few problems that I haven't seen in the Unix world, such as: each DLL potentially having an incompatible implementation of malloc, where allocating using malloc(3) in one DLL then freeing it with free(3) in another being a crash.
> where allocating using malloc(3) in one DLL then freeing it with free(3) in another being a crash.
This can still happen all the time on UNIX systems. glibc's malloc implementation is a fine general purpose allocator, but there's plenty of times where you want to bring in tcmalloc, jemalloc, etc. Of course, you hope that various libraries will resolve to your implementation of choice when the linker wires everything up, but they can opt not to just as easily.
3 replies →
Because C standard library isn't part of the OS.
Outside UNIX, the C standard library is a responsibility of the C compiler vendor, not the OS.
Nowadays Windows might seem the odd one, however 30 years ago the operating system was more diverse.
You will also find similar issues on dynamic libraries in mainframes/micros from IBM and Unisys, still being sold.
1 reply →
> I couldn't figure out how to use COM or what it's purpose was.
A shorter version than the other reply:
COM allows you to have a reference counted object with callable virtual methods. You can also ask for different virtual methods at runtime (QueryInterface).
Some of the use cases include: maybe those methods are implemented in a completely different programming language that you are using, for example I think one of the historical ones is JavaScript or vbscript interacting with C++. It standardizes the virtual calls in such a way that you can throw in such an abstraction. And since reference counting happens via a virtual call, memory allocation is also up to the callee. Another historical use case is to have the calls be handled in a different process.