Hacker News Reader

Comment by bboygravity | Hacker News Reader

Nicer to work with?

I can't think of any worse API in the entire world?

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.

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.

I've had to work with api functions like 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.

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.

Yes, but the inversion of control is unpleasant to deal with—compare Find{First,Next}File which don’t require that.

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/tra...

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.

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

X Windows and Motif, for example.

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

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);

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.

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).

Needing new features like wayland support? Better DE integration? Distros removing old versions? What an odd question.

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.

All untrue from my perspective so I'm not sure which parallel universes we live in.

Reply on news.ycombinator.com