5 ms·

Nicer to work with? I can't think of any worse API in the entire world?

sirwhinesalot 2y ago
The various WinRT APIs are even worse. At least Win32 is "battle tested"
flohofwoe 2y ago
There are some higher level COM APIs which are not exactly great, but the core Win32 DLL APIs (kernel32, user32, gdi32) are quite good, also the DirectX APIs after ca 2002 (e.g. since D3D9) - because even though the DirectX APIs are built on top of COM, they are designed in a somewhat sane way (similar to how there are 'sane' and 'messy' C++ APIs). Especially UWP and its successors (I think it's called WinRT now?) are objectively terrible.
- OvbiousError 2y ago
  I've had to work with api functions like https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-enumchildwindows https://learn.microsoft.com/en-us/windows/win32/api/winuser/... and friends. It was by far the most unpleasant api I've ever worked with.
  - frabert 2y ago
    I think that particular pattern is a perfectly reasonable way to let the user ingest an arbitrarily long list of objects without having to do any preallocations -- or indeed, any allocations at all.
    - mananaysiempre 2y ago
      Yes, but the inversion of control is unpleasant to deal with—compare Find{First,Next}File which don’t require that.
      - wongarsu 2y ago
        Which is a pattern that also exists in the Win32 API, for example in the handle = CreateToolhelp32Snapshot(), Thread32First(handle, out), while Thread32Next(handle, out) API for iterating over a process's threads. I also find EnumChildWindows pretty wacky. It's not too bad to use, but it's a weird pattern and a pattern that Windows has also moved away from since XP. https://learn.microsoft.com/en-us/windows/win32/toolhelp/traversing-the-thread-list https://learn.microsoft.com/en-us/windows/win32/toolhelp/tra...
    - wruza 2y ago
      Because allocating well under a hundred handles is a biggest problem we have. WinAPI is awful to work with for reasons above anyone’s comprehension. It’s just legacy riding on legacy, with initial legacy made by someone 50% following stupid patterns from the previous 8/16 bit decade and 50% high on mushrooms. The first thing you do with WinAPI is abstracting it tf away from your face.
pjmlp 2y ago
X Windows and Motif, for example.
sumtechguy 2y ago
The 'win32' AOU calls are decent relative to themselves. If you understand their madness. For every positive call there is usually an anti call and a worker call. Open a handle, use the handle with its helper calls, close the handle. You must understand their 3 step pattern to all work. There are a few exceptions. But usually those are the sort of things where the system has given you a handle and you must deal with it with your calls to helper calls. In those cases usually the system handles the open/close part. Now you get into the COM/.NET/UWP stuff and the API gets a bit more fuzzy on that pattern. The win32 API is fairly consistent in its madness. So are the other API stacks they have come up with. But only in their own mad world. Also out of the documentation the older win32 docs are actually usually decently written and self consistent. The newer stuff not so much. If you have the displeasure of mixing APIs you are in for a rough ride as all of their calling semantics are different.
- deleted 2y ago
  [deleted]
marcosdumay 2y ago
So, you don't use the newer Windows APIs?
wruza 2y ago
Yeah, I like the smell of cbSize in the RegisterClassExA. Smells like… WNDCLASSEXA.lpfnWndProc. Nothing can beat WinAPI in nicety to work with, just look at this monstrosity: gtk_window_new(GTK_WINDOW_TOPLEVEL);
- sirwhinesalot 2y ago
  On the other hand GTK has been rewritten 3 times and each new version deprecates a bunch of stuff, making it an absolute nightmare for apps to migrate.
  - wruza 2y ago
    Why can’t they stick an app to a specific gtk version? They were fine with what they started it in, what is the reason to migrate? If the answer is ver++ anxiety, the problem is self-imposed (still better than using winapi).
    - sirwhinesalot 2y ago
      Needing new features like wayland support? Better DE integration? Distros removing old versions? What an odd question.
      - wruza 2y ago
        What exactly does “wayland support” do to an existing x11 app? How they managed to ship either the app or the wayland without mutual “support” before? What’s DE integration apart from tray and notifications? Why does an app need any DE integration beyond a tray icon? These questions are valid, not odd. Distros removing versions is a distro’s problem. Most gtk versions are installable on popular distros, afaiu. Anyway, I find most of these points are moot, because they mirror winapi. Gdi -> directx, fonts scaling, need for msvcrts and so on. Looks like an argument for the sake of argument. You can’t make a modern app with winapi either, it will be a blurry non-integrated win2k window like device manager or advanced properties. The difference is you can’t migrate them at all, even MS can not.

The various WinRT APIs are even worse. At least Win32 is "battle tested"

There are some higher level COM APIs which are not exactly great, but the core Win32 DLL APIs (kernel32, user32, gdi32) are quite good, also the DirectX APIs after ca 2002 (e.g. since D3D9) - because even though the DirectX APIs are built on top of COM, they are designed in a somewhat sane way (similar to how there are 'sane' and 'messy' C++ APIs). Especially UWP and its successors (I think it's called WinRT now?) are objectively terrible.

OvbiousError 2y ago
I've had to work with api functions like https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-enumchildwindows https://learn.microsoft.com/en-us/windows/win32/api/winuser/... and friends. It was by far the most unpleasant api I've ever worked with.
- frabert 2y ago
  I think that particular pattern is a perfectly reasonable way to let the user ingest an arbitrarily long list of objects without having to do any preallocations -- or indeed, any allocations at all.
  - mananaysiempre 2y ago
    Yes, but the inversion of control is unpleasant to deal with—compare Find{First,Next}File which don’t require that.
    - wongarsu 2y ago
      Which is a pattern that also exists in the Win32 API, for example in the handle = CreateToolhelp32Snapshot(), Thread32First(handle, out), while Thread32Next(handle, out) API for iterating over a process's threads. I also find EnumChildWindows pretty wacky. It's not too bad to use, but it's a weird pattern and a pattern that Windows has also moved away from since XP. https://learn.microsoft.com/en-us/windows/win32/toolhelp/traversing-the-thread-list https://learn.microsoft.com/en-us/windows/win32/toolhelp/tra...
  - wruza 2y ago
    Because allocating well under a hundred handles is a biggest problem we have. WinAPI is awful to work with for reasons above anyone’s comprehension. It’s just legacy riding on legacy, with initial legacy made by someone 50% following stupid patterns from the previous 8/16 bit decade and 50% high on mushrooms. The first thing you do with WinAPI is abstracting it tf away from your face.

pjmlp 2y ago

X Windows and Motif, for example.

sumtechguy 2y ago

The 'win32' AOU calls are decent relative to themselves. If you understand their madness. For every positive call there is usually an anti call and a worker call. Open a handle, use the handle with its helper calls, close the handle. You must understand their 3 step pattern to all work. There are a few exceptions. But usually those are the sort of things where the system has given you a handle and you must deal with it with your calls to helper calls. In those cases usually the system handles the open/close part. Now you get into the COM/.NET/UWP stuff and the API gets a bit more fuzzy on that pattern. The win32 API is fairly consistent in its madness. So are the other API stacks they have come up with. But only in their own mad world. Also out of the documentation the older win32 docs are actually usually decently written and self consistent. The newer stuff not so much. If you have the displeasure of mixing APIs you are in for a rough ride as all of their calling semantics are different.

deleted 2y ago
[deleted]

marcosdumay 2y ago

So, you don't use the newer Windows APIs?

wruza 2y ago

Yeah, I like the smell of cbSize in the RegisterClassExA. Smells like… WNDCLASSEXA.lpfnWndProc. Nothing can beat WinAPI in nicety to work with, just look at this monstrosity: gtk_window_new(GTK_WINDOW_TOPLEVEL);

sirwhinesalot 2y ago
On the other hand GTK has been rewritten 3 times and each new version deprecates a bunch of stuff, making it an absolute nightmare for apps to migrate.
- wruza 2y ago
  Why can’t they stick an app to a specific gtk version? They were fine with what they started it in, what is the reason to migrate? If the answer is ver++ anxiety, the problem is self-imposed (still better than using winapi).
  - sirwhinesalot 2y ago
    Needing new features like wayland support? Better DE integration? Distros removing old versions? What an odd question.
    - wruza 2y ago
      What exactly does “wayland support” do to an existing x11 app? How they managed to ship either the app or the wayland without mutual “support” before? What’s DE integration apart from tray and notifications? Why does an app need any DE integration beyond a tray icon? These questions are valid, not odd. Distros removing versions is a distro’s problem. Most gtk versions are installable on popular distros, afaiu. Anyway, I find most of these points are moot, because they mirror winapi. Gdi -> directx, fonts scaling, need for msvcrts and so on. Looks like an argument for the sake of argument. You can’t make a modern app with winapi either, it will be a blurry non-integrated win2k window like device manager or advanced properties. The difference is you can’t migrate them at all, even MS can not.