Comment by ndiddy

2 years ago

Win32 is straightforward and easy to use until you get to COM stuff: https://learn.microsoft.com/en-us/windows/win32/shell/common...

Yes, for COM programming you better switch to C++.

  • Even then, MFC and C++/CX were the only productive ways to use it from Microsoft SDKs.

    .NET isn't as convenient as VB 6 was, fully embracing COM as the VBX replacement model, technically introduced in VB5, but still some stuff was lacking.

    Then there is Delphi and C++ Builder.

    It beat me that having doubled down on COM since how Longhorn went down, and Windows team getting their way doing avoiding .NET to take over, they hardly managed to create nice tooling as the competition.

    Editing IDL files with a Notepad like experience, manually merging generated code, and a couple of frameworks that barely go beyond yet another way to do AddRef/Release/QueryInterface and aggregation.

    Meanwhile D-BUS, XPC and AIDL, provide much better dev experience.

    Pity that Borland products are kind of tainted due to mismanagement decisions, otherwise maybe fixing COM dev experience would already been seriously taken by VS team.

    Ah, nowadays WIL is probably the best approach when having only to consume COM.

    https://github.com/microsoft/wil

    • MFC's only COM support was support for ActiveX controls; it otherwise didn't do anything to help you with COM interaction. You may be thinking of ATL, which was specifically intended to help with COM.

      Source: worked professionally for years on an MFC-based app that communicated with an out-of-process COM server which we also wrote. The COM bits sucked.

      1 reply →