undefined | Better HN

0 pointsc-smile6y ago0 comments

I have quite opposite opinion backed by real life experience.

As an author of Sciter Engine that works on Windows, MacOS and Linux/GTK I have first hand experience working with all three API sets.

Windows API is the most logical, complete and stable API among all others.

It has everything that you really need to create performant and manageable UI.

MacOS is good but less good. It uses reference counting (which is not bad by itself) but in very strange manner. Name of the function determines need of [obj retain] / [obj release] and not all names that they use are consistent in that respect. Yet Apple changes API quite frequently and dramatically.

GTK, while is built on top of quite reliable Glib foundation is a mess to be honest. You have GtkWindow and GdkWindow, you have gtk_window_resize(), gtk_window_set_default_size() and 6 more functions that should allow to set size of the window but they may or may not work in particular situations.

0 comments

mehrdadn6y ago

> GTK, while is built on top of quite reliable Glib foundation is a mess to be honest. You have GtkWindow and GdkWindow, you have gtk_window_resize(), gtk_window_set_default_size() and 6 more functions that should allow to set size of the window but they may or may not work in particular situations.

You know, even as a guy who loves Windows, this example makes my head explode. We have MoveWindow, SetWindowPos, SetWindowPlacement, DeferWindowPos, ShowWindow, ShowWindowAsync etc. all of which overlap in functionality. Similarly SetActiveWindow and SetForegroundWindow, etc...

tempguy99996y ago

IIRC there were three different kinds of handles, the documentation was a crock, the api did minimal checking, it was horrible. Fast maybe, but delphi succeeded so well because it hid all the awfulness. MS just didn't get it for years.

c-smileOP6y ago

Yes, there are problems but if to compare with others...

Windows is so popular just because of stability and completeness of its API. And that is non-disputable I think. Quite few simple and flexible abstractions (handles, WndProc, messages, etc).

astrange6y ago

macOS has had automatic retain counting for the last decade. You have to remember your weak/strong for cycles but that's all.

It's preferable over garbage collection because there are no unexpected pauses/memory scans and it's deterministic.

inlined6y ago

RE pauses, that’s only due to the system-injected calls to autoReleaseReturnValue and retainReturnValue which work in tandem to do assembly call stack analysis and set an extra register to keep return values out of the release pool. This allows pool runs to happen frequently enough with few objects in them and have smooth latency.

astrange6y ago

The autorelease optimization actually regularly breaks, because not even the compiler engineers remember it exists, and it relies on libraries tall-calling -autorelease which they also forget to do.

Even without it, there isn't a pausing problem because you can clear the pool at the end of the runloop tick, when the app is idle anyway.

1 more reply

j / k navigate · click thread line to collapse

0 pointsc-smile6y ago0 comments

I have quite opposite opinion backed by real life experience.

As an author of Sciter Engine that works on Windows, MacOS and Linux/GTK I have first hand experience working with all three API sets.

Windows API is the most logical, complete and stable API among all others.

It has everything that you really need to create performant and manageable UI.

0 comments

mehrdadn6y ago

tempguy99996y ago

c-smileOP6y ago

Yes, there are problems but if to compare with others...

Windows is so popular just because of stability and completeness of its API. And that is non-disputable I think. Quite few simple and flexible abstractions (handles, WndProc, messages, etc).

astrange6y ago

macOS has had automatic retain counting for the last decade. You have to remember your weak/strong for cycles but that's all.

It's preferable over garbage collection because there are no unexpected pauses/memory scans and it's deterministic.

inlined6y ago

astrange6y ago

The autorelease optimization actually regularly breaks, because not even the compiler engineers remember it exists, and it relies on libraries tall-calling -autorelease which they also forget to do.

Even without it, there isn't a pausing problem because you can clear the pool at the end of the runloop tick, when the app is idle anyway.

1 more reply

j / k navigate · click thread line to collapse