Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> There are not multiple "native toolkits" on Windows or macOS.

This is just not true on Windows. What is native Windows these days? Win32? WPF? WinUI? Even if your view is that Win32 is the one true native toolkit, MS alone produces multiple abstractions over Win32 like Windows Forms or MFC.



Even when I was programming on Windows in the mid 200x’s there were 9 or 10 ways to represent a “string” depending on which framework you were using and you had to convert between them depending on the API you needed to call.

https://learn.microsoft.com/en-us/cpp/text/how-to-convert-be...


Honestly, if someone produced a book that said how to write win32 applications in a way portable enough that current distributions of wine would not have to do any special work to make them work, I would very strongly consider that option.


My definition works like this:

is there an API layer on which (a) everything else is based and (b) people sometimes use directly for app development?

  macOS: Cocoa/Quartz - yes and yes

  windows: win32 - yes and yes

  linux: X Window - yes, no (though of course Wayland is changing the "yes" a bit)
       GTK, Qt, WxWidgets, FLTK etc - no, yes


But that's my point, WPF (the Vista-7 era primary toolkit), is not based on Win32. Neither is WinUI (the 8-11 era primary toolkit) calling Win32 or WPF.

Win32 is mostly used for legacy apps, you'll find some random usages still like pre-Win11 notepad or the services configuration menu.

WPF is the primary UI framework of Windows Vista/7 and still the framework which the majority of the OS is in for Windows 8/8.1. It doesn't call Win32, it implements its own widgets, something that would most often be exposed in differences in high-dpi support. These do generally try to align with the Win32 widgets from that Windows version visually, but there's plenty of discrepencies.

WinUI is the new framework which isn't even shipped with the OS as of the latest versions, but even if you're using the built in verison it's not calling Win32 widgets or WPF widgets, it's once again implemented a new set. The lower level APIs share some similarities with WPF as it basically started as a fork of WPF modified to implement Windows 8 UI patterns, but neither WinUI or WPF are implemented in terms of the other.


Thank you for a brief update on the situation on Windows. I didn't know all that, and now I know a bit of it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: