4 ms·

The WIN32 API is somewhat ugly. I hate how all types are capitalized and their short abbreviations in arguments are sometimes weird. I hate how they have their

The WIN32 API is somewhat ugly. I hate how all types are capitalized and their short abbreviations in arguments are sometimes weird. I hate how they have their own version of lots of standard C types that you have to be careful about (they weren't standard at the time, to be fair). But it's quite straightforward and easy to use. Any language that has FFI can call into it and build GUI apps, I've made a windowed Hello World in PHP with it. And it has been that way for 30+ years at this point. It's quite remarkable, really!

dgellow 3y ago
Also, UTF-16 (or WTF-16 as defined by https://simonsapin.github.io/wtf-8/#wtf-16 https://simonsapin.github.io/wtf-8/#wtf-16)
QuercusMax 3y ago
I remember ages ago when I was about 12, I got a copy of Turbo C++ for Windows 3.1 for my birthday. (I had only written in Basic before, and wanted to learn a "real" programming language. My dad was a Fortran programming physicist, and had heard that C++ was what everyone was using then-a-days.) I mostly wrote simple console programs, and it came with the Borland ObjectWindows library with a fun GUI builder, but there was a section in the manual talking about how to write directly using the Windows API. I didn't really understand any of what I was reading, but I typed in the whole basic sample complete with HWNDs and all that nonsense. I can't remember if I could even get it to compile, but the idea of an event-loop was beyond my comprehension as a 12yo. I'm sure if I went back it would make a lot more sense to me, but back in 1994 it seemed like dark magic, especially compared to the much simpler and more understandable OWL components.
deleted 3y ago
[deleted]
ndiddy 3y ago
Win32 is straightforward and easy to use until you get to COM stuff: https://learn.microsoft.com/en-us/windows/win32/shell/common-file-dialog#sample-usage https://learn.microsoft.com/en-us/windows/win32/shell/common...
- Koshkin 3y ago
  Yes, for COM programming you better switch to C++.
  - pjmlp 3y ago
    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 https://github.com/microsoft/wil
    - electroly 3y ago
      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.
      - pjmlp 3y ago
        ActiveX is just a brand name for a set of COM interfaces. Just like nowadays WinRT is just having IInspectable alongside IUnknown, shipping .NET metadata file instead of a TLB and having an application identity. MFC can pretty well do regular COM, and those macros are much developer friendly than the ATL template junk with multiple inheritance and IDL files without any kind of Visual Studio editing tooling support. COM sucks no matter what when using Microsoft tools, for whatever reason Microsoft isn't able to deliver as good development experience for COM, as third parties, even though they push it everywhere. For decades I expected them to finally catch up to Borland or Qt, C++/CX seemed to finally be it, but no, the "ATL rulez!" folks in Redmond had their way.

dgellow 3y ago

Also, UTF-16 (or WTF-16 as defined by https://simonsapin.github.io/wtf-8/#wtf-16 https://simonsapin.github.io/wtf-8/#wtf-16)

QuercusMax 3y ago

I remember ages ago when I was about 12, I got a copy of Turbo C++ for Windows 3.1 for my birthday. (I had only written in Basic before, and wanted to learn a "real" programming language. My dad was a Fortran programming physicist, and had heard that C++ was what everyone was using then-a-days.) I mostly wrote simple console programs, and it came with the Borland ObjectWindows library with a fun GUI builder, but there was a section in the manual talking about how to write directly using the Windows API. I didn't really understand any of what I was reading, but I typed in the whole basic sample complete with HWNDs and all that nonsense. I can't remember if I could even get it to compile, but the idea of an event-loop was beyond my comprehension as a 12yo. I'm sure if I went back it would make a lot more sense to me, but back in 1994 it seemed like dark magic, especially compared to the much simpler and more understandable OWL components.

deleted 3y ago

[deleted]

ndiddy 3y ago

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

Koshkin 3y ago
Yes, for COM programming you better switch to C++.
- pjmlp 3y ago
  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 https://github.com/microsoft/wil
  - electroly 3y ago
    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.
    - pjmlp 3y ago
      ActiveX is just a brand name for a set of COM interfaces. Just like nowadays WinRT is just having IInspectable alongside IUnknown, shipping .NET metadata file instead of a TLB and having an application identity. MFC can pretty well do regular COM, and those macros are much developer friendly than the ATL template junk with multiple inheritance and IDL files without any kind of Visual Studio editing tooling support. COM sucks no matter what when using Microsoft tools, for whatever reason Microsoft isn't able to deliver as good development experience for COM, as third parties, even though they push it everywhere. For decades I expected them to finally catch up to Borland or Qt, C++/CX seemed to finally be it, but no, the "ATL rulez!" folks in Redmond had their way.