Scripting COM components in Haskell (1998) [pdf] | Hacker News Reader

Scripting COM components in Haskell (1998) [pdf]

cmpct.info

42 pointstodsacerdoti8 comments

COM was a pretty great tech at the time - nasty to program with but in terms of comprehensiveness of adoption, powerful cross-language interop and component marketplaces, the 90s were the place to be. Microsoft led by example and so lots of apps did expose their internals via COM objects.

For better or worse the shift to cross-platform development killed that all stuff off. The closest equivalent is now the JVM, but it requires everything to share a runtime whereas COM was much less imposing. Also the higher level nature of JVM bytecode makes it less attractive to build commercial components in it, whereas OCX controls were a working market of software components.

As mentioned by atombender, COM is the main Windows API in modern Windows.

After the Longhorn collapse, all major ideas that were originally implementated in .NET got redone in COM.

Eventually WinRT doubled down on it, and even if they messed up the whole execution, the main goal of Project Reunion is to bring them into regular Windows, now rebranded as WinUI 3.0/AppSDK.

Parallel to that, many .NET APIs on Windows are COM wrappers at their lowest layer.

Classical Win32 C like APIs, are effectively "stable" since Windows XP

Yes, COM lives on as WinRT and the way Microsoft expose their own APIs, but not many apps are using those APIs and even fewer are exposing their own APIs that way. It's not really clear how many people are writing COM objects outside the Windows team nowadays.

Excel, Word, PowerPoint are COM objects that can be scripted by any language (python, delphi, c++...).

It's a pleasure seeing a template word document being managed and compose by python and then sent to a printer to fill report.

   import win32com.client as win32 
   excel = win32.gencache.EnsureDispatch('Excel.Application') 
   excel.Visible = True

Apps written for Windows are definitely using them, even if using .NET Framework, unless their authors are targeting a Windows XP user experience.

And on Windows making a business out of selling components is still a thing.

Additionally any application that integrates into the OS for file viewers, userspace drivers, shell extensions, or any other OS extension point, needs to implement COM interfaces.

COM wasn't killed off, though. It's the main tech behind all modern Windows APIs these days.

Rigth, ms office apps are big COM application that can be instantiated by other programs.

Dbus is cross-platform like COM and widely used on Linux.

Reply on news.ycombinator.com