Comment by pjmlp
12 hours ago
Unfortunely Microsoft didn't invest heavily enough on COM tooling, it sucks in 2025 as much as in the 1990's.
12 hours ago
Unfortunely Microsoft didn't invest heavily enough on COM tooling, it sucks in 2025 as much as in the 1990's.
Sure, why would they? COM was rendered irrelevant by the move to the web. Microsoft lost out on the app serving side, and when they dropped the ball on ActiveX by not having proper UI design or sandboxing they lost out on the client too. Probably the primary use case outside of legacy OPC is IT departments writing PowerShell scripts or Office plugins (though those are JS based now too).
COM has been legacy tech for decades now. Even Microsoft's own security teams publish blog posts enthusiastically explaining how they found this strange ancient tech from some Windows archaeological dig site, lol. Maybe one day I'll be able to mint money by doing maintenance consulting for some old DCOM based systems, the sort of thing where knowing what an OXID resolver is can help and AI can't do it well because there's not enough example code on GitHub.
Because since Windows Vista all new APIs are COM based, Win32 C API is basically stuck on Windows XP view of the universe, with minor exceptions here and there.
Anyone that has to deal with Windows programming quickly discovers that COM is not the legacy people talk about on the Internet.
Sure I mean, obviously the Windows API is COM based and has been for a long time. My point is, why seriously invest in the Windows API at all? A lot of APIs are only really being used by the Chrome team at this point anyway, so the quality of the API hardly matters.
1 reply →