[HN Gopher] Scripting COM components in Haskell (1998) [pdf]
       ___________________________________________________________________
        
       Scripting COM components in Haskell (1998) [pdf]
        
       Author : todsacerdoti
       Score  : 39 points
       Date   : 2022-05-09 15:28 UTC (7 hours ago)
        
 (HTM) web link (cmpct.info)
 (TXT) w3m dump (cmpct.info)
        
       | mike_hearn wrote:
       | 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.
        
         | pjmlp wrote:
         | 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
        
           | mike_hearn wrote:
           | 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.
        
             | pjmlp wrote:
             | 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.
        
             | rsecora wrote:
             | 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
        
         | atombender wrote:
         | COM wasn't killed off, though. It's the main tech behind all
         | modern Windows APIs these days.
        
           | rsecora wrote:
           | Rigth, ms office apps are big COM application that can be
           | instantiated by other programs.
        
         | iso8859-1 wrote:
         | Dbus is cross-platform like COM and widely used on Linux.
        
       ___________________________________________________________________
       (page generated 2022-05-09 23:02 UTC)