4 ms·

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 af

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.

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.