4 ms·

20 years ago I knew COM inside out and it was great, it was really powerful way to integrate your own code with the big applications Excel, ASP, IE. Its a great

20 years ago I knew COM inside out and it was great, it was really powerful way to integrate your own code with the big applications Excel, ASP, IE. Its a great way to do SOLID programming long before it became fashionable. It also did things like let you build components in a single threaded language and use from a multi thread process - stuff people still can't do today. I know MS technology was never popular in SV, but people never even looked at it, which to me is weird when developers spend a lot of time investigating other languages and frameworks. Anyway its mostly dead now I guess, except for these random archaeological digs.

marcus_holmes 6y ago
Same. I miss how awesome COM was too. DCOM was a couple of orders of magnitude more fiddly to get working. But amazing once it worked. Create an object on another server, call its methods, side effects happen on that server, results are returned to your process. When I was learning Go the similarity between COM interfaces and Go interfaces really helped me grok them quicker.
- pjmlp 6y ago
  It still is, powering all major Windows APIs since Vista.
  - marcus_holmes 6y ago
    yeah, but I don't write desktop apps any more, so it's not something I use any more.
- cesarb 6y ago
  DCOM was also amazing, in how much surface area it exposed to the network. Random COM objects which were never intended to be called remotely, and were poorly secured, could be exposed by accident. So in the infamous Windows XP SP2 (not a major release of the operating system, but a mere service pack), DCOM got locked down hard. If you have a legitimate use for DCOM (like an OPC-DA server), you have to toggle several obscure settings to make it work again (see https://www-bd.fnal.gov/controls/opc/Using_OPC_via_DCOM_with_XP_SP2_v1.10.pdf https://www-bd.fnal.gov/controls/opc/Using_OPC_via_DCOM_with... for a fourteen-page tutorial).
  - marcus_holmes 6y ago
    yeah, MS had a hard time with security around then. Lots of stuff that was open had to be locked down.
- barrkel 6y ago
  I like to compare HTTP / REST / HATEOAS with DCOM, conceptually. DCOM was deeply misguided as a model for distributed programming. When you look at an actually functioning system, you realize that network transparency at the programming level is possibly the worst thing you can do. Can you imagine how web pages would work under a DCOM model?
pjmlp 6y ago
COM is quite alive, after Longhorn's project failure, all those .NET ideas got re-implemented as COM and all major Windows APIs since Vista have been introduced as COM based APIs. WinRT/UWP is just COM improved to support generics and .NET types. It is pretty much alive despite not being popular in SV, and it is also how iDevices drivers work actually.
- mschaef 6y ago
  > .NET ideas got re-implemented as COM I know where you're coming from, given Longhorn's original history as an effort to implement part of Windows on .Net, but it's still interesting to see it cast this way. Without getting too deep into the gory details, COM was originally the implementation technology for OLE 2.0, with the CLR being a combination of efforts to replace COM and compete with Java/JVM. (At least partially in response to the Sun lawsuit over Microsoft's attempts to extend Java directly.)
  - pjmlp 6y ago
    Sure it is interesting to see it this way, WinRT is what COM would have been if it wasn't the idea to turn around and make use of Java instead (via J++), see the Ext-VOS project and the history of F# for the juicy details. Hence why many .NET configuration flags still have COM prefix to this day. Also check the C++/COM Hilo project released for Vista, and updated for Windows 7 release
    - derefr 6y ago
      I feel like I just got a long-implicit joke: “what’s the sequel to COM? NET!” (And presumably, if Microsoft ever did it all over again, we’d get ORG.)
zvrba 6y ago
And I like how you only have to know the library/class/interface guid. No header files, nothing to link, the compiler figures out and infers everything. Type libraries make it possible to use the same component in a language-independent manner; bindings are generated automatically from TLB data. > Anyway its mostly dead now I guess, except for these random archaeological digs. Far from dead. All new windows stuff is built on top of extended COM.
pcwalton 6y ago
You still definitely need to know COM to write Windows apps. I had to learn a lot of COM in the last five years. Granted, the Windows desktop isn't exactly a growth market nowadays. (Note that all the apps I've worked on are cross-platform and aren't Windows-specific, so COM use is limited to implementations of the platform abstraction layer.)

marcus_holmes 6y ago

Same. I miss how awesome COM was too. DCOM was a couple of orders of magnitude more fiddly to get working. But amazing once it worked. Create an object on another server, call its methods, side effects happen on that server, results are returned to your process. When I was learning Go the similarity between COM interfaces and Go interfaces really helped me grok them quicker.

pjmlp 6y ago
It still is, powering all major Windows APIs since Vista.
- marcus_holmes 6y ago
  yeah, but I don't write desktop apps any more, so it's not something I use any more.
cesarb 6y ago
DCOM was also amazing, in how much surface area it exposed to the network. Random COM objects which were never intended to be called remotely, and were poorly secured, could be exposed by accident. So in the infamous Windows XP SP2 (not a major release of the operating system, but a mere service pack), DCOM got locked down hard. If you have a legitimate use for DCOM (like an OPC-DA server), you have to toggle several obscure settings to make it work again (see https://www-bd.fnal.gov/controls/opc/Using_OPC_via_DCOM_with_XP_SP2_v1.10.pdf https://www-bd.fnal.gov/controls/opc/Using_OPC_via_DCOM_with... for a fourteen-page tutorial).
- marcus_holmes 6y ago
  yeah, MS had a hard time with security around then. Lots of stuff that was open had to be locked down.
barrkel 6y ago
I like to compare HTTP / REST / HATEOAS with DCOM, conceptually. DCOM was deeply misguided as a model for distributed programming. When you look at an actually functioning system, you realize that network transparency at the programming level is possibly the worst thing you can do. Can you imagine how web pages would work under a DCOM model?

pjmlp 6y ago

COM is quite alive, after Longhorn's project failure, all those .NET ideas got re-implemented as COM and all major Windows APIs since Vista have been introduced as COM based APIs. WinRT/UWP is just COM improved to support generics and .NET types. It is pretty much alive despite not being popular in SV, and it is also how iDevices drivers work actually.

mschaef 6y ago
> .NET ideas got re-implemented as COM I know where you're coming from, given Longhorn's original history as an effort to implement part of Windows on .Net, but it's still interesting to see it cast this way. Without getting too deep into the gory details, COM was originally the implementation technology for OLE 2.0, with the CLR being a combination of efforts to replace COM and compete with Java/JVM. (At least partially in response to the Sun lawsuit over Microsoft's attempts to extend Java directly.)
- pjmlp 6y ago
  Sure it is interesting to see it this way, WinRT is what COM would have been if it wasn't the idea to turn around and make use of Java instead (via J++), see the Ext-VOS project and the history of F# for the juicy details. Hence why many .NET configuration flags still have COM prefix to this day. Also check the C++/COM Hilo project released for Vista, and updated for Windows 7 release
  - derefr 6y ago
    I feel like I just got a long-implicit joke: “what’s the sequel to COM? NET!” (And presumably, if Microsoft ever did it all over again, we’d get ORG.)

zvrba 6y ago

And I like how you only have to know the library/class/interface guid. No header files, nothing to link, the compiler figures out and infers everything. Type libraries make it possible to use the same component in a language-independent manner; bindings are generated automatically from TLB data. > Anyway its mostly dead now I guess, except for these random archaeological digs. Far from dead. All new windows stuff is built on top of extended COM.

pcwalton 6y ago

You still definitely need to know COM to write Windows apps. I had to learn a lot of COM in the last five years. Granted, the Windows desktop isn't exactly a growth market nowadays. (Note that all the apps I've worked on are cross-platform and aren't Windows-specific, so COM use is limited to implementations of the platform abstraction layer.)