5 ms·

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 experi

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.

tempguy9999 7y 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-smile 7y 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).
mehrdadn 7y 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...
astrange 7y 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.
- inlined 7y 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.
  - astrange 7y 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.
    - inlined 7y ago
      But if you didn’t had the trick, CPU intensive runloop ticks could create lots of small objects that were put in the pool because they had a 0 refcount as a function returned the value. That’s why we had the ability to write our own pools.
deleted 7y ago
[deleted]

tempguy9999 7y 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-smile 7y 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).

mehrdadn 7y 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...

astrange 7y 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.

inlined 7y 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.
- astrange 7y 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.
  - inlined 7y ago
    But if you didn’t had the trick, CPU intensive runloop ticks could create lots of small objects that were put in the pool because they had a 0 refcount as a function returned the value. That’s why we had the ability to write our own pools.

deleted 7y ago

[deleted]