[arghwhat]

Note that this also underlines that the post's premise of Windows having a simple stable ABI - win32 sure is stable, but that's not what applications are coded against anymore.

Sure, you can run a 20 year old app, but that is not the same as a current app still working in 20 years, or even 5.

[Const-me]

> that's not what applications are coded against anymore

Not sure I follow. Sure, most modern programs are not using old-school WinAPI with GDI, but the stuff they added later is also rather stable. For example, the Chromium-based browser I’m looking at uses Direct3D 11 for graphics. It implements a few abstraction layers on top (ANGLE, Skia) but these are parts of the browser not the OS.

I view all that modern stuff like Direct3D, Direct2D, DirectWrite, Media Foundation as simply newer parts of the WinAPI. Pretty sure Microsoft will continue to support them for long time. For example, they can’t even deprecate the 23 years old DirectX 9 because still widely used, e.g. current version of Microsoft’s own WPF GUI framework relies on Direct3D 9 for graphics.

[LeFantome]

I agree. On Linux (and Mac really), new APIs replace old ones and old binaries stop working.

On Windows, new layers are applied over the old. There is DirectX 9-12. New binaries may use 12 but the ones still using 9 are perfectly happy. Things like .NET work the same. You can have multiple apps installed relying on different .NET versions.

[int_19h]

It's not necessarily the same code, though. But COM is nice for a stable ABI like that - so long as you consistently version your interfaces, the apps can just QueryInterface for the old one they need and know that it's there, even if it's just a thin wrapper around the new stuff.

[account42]

You can still use OpenGL 1.0 and Xlib-like-it's-1999 on modern Linux distributions.

[arghwhat]

These are however the same on Linux - mesa may change, but what the app uses is OpenGL and GLX. A more modern app might use EGL instead of GLX, or have switched to Vulkan, but that doesn't break old code.

You can also run an old mesa from the time the app was built if it supports your newer hardware, but I'd rather consider that to be part of the platform the same way you'd consider the DirectX libraries to be part of windows.

[Const-me]

> These are however the same on Linux .. that doesn't break old code

An example from another comment: https://news.ycombinator.com/item?id=43519949

[arghwhat]

Apologies, but "I heard that..." is not an example.

[Const-me]

The phrase you quoted is not from the comment I linked; you’ve quoted from a response. Here’s the comment I have linked above:

> I have flatpaks from several years ago that no longer work (Krita) due to some GL issues.

That’s an example of Linux GPU APIs being unstable in practice, and container images not helping to fix that.

[arghwhat]

Ah apologies, you're right - I was tired and read things wrong.

But I suspect "GL issues" (i.e., GL API stability) is being mixed together with e.g. mesa issues if mesa is being bundled inside the app/in a "flatpak SDK" instead of being treated as a system library akin to what you would do with DirectX.

Mesa contains your graphics driver and window system integrations, so when the system changes so must mesa change - but the ABI exposed to clients does not change, other than new features being added.

[account42]

It more likely is an example of immature container images causing issues.

I'm running Loki game binaries just fine today btw.

[okanat]

Win32 is quite extensive for an OS API. It covers the space from low-level stuff like syscalls and page allocation and all the way up to localization, simple media access and GUI. So everything from glibc, libsystemd, libpam to libalsa and egl on Linux side. And it is all stable.

Microsoft also provides quite good stability for DirectX and other extension APIs. You can still run old .Net apps without issues as long as they didn't pull a Hyrum's Law on you and depended on apparent behavior.

[arghwhat]

Sure, win32 contains GUI bits, but modern apps do not use those GUI bits.

OpenGL and Vulkan ABIs are also stable on Linux, provided by mesa. The post is pretty focused on the simplicity of win32 though, which is what I'm refuting as being as relevant today for new apps.

> As long as they didn't pull a Hyrum's Law on you

It is guaranteed that they "pull a Hyrum's Law", the question is just what apparent behavior they relied on.

[CRConrad]

> Sure, win32 contains GUI bits, but modern apps do not use those GUI bits.

Which is probably why so many "modern apps" look just like "modern" Web pages running on the desktop... i.e, why so many "modern apps" suck. They freaking should use those GUI bits.

[dwattttt]

> Note that this also underlines that the post's premise of Windows having a simple stable ABI - win32 sure is stable, but that's not what applications are coded against anymore.

It's true, but this touches on another point they made: what apps code to is other dynamically linked libraries. The kind that wine (or other host environments) can provide, without needing to mess with the kernel.

[account42]

That's what apps are supposed to code to. When it comes to games and especially anti-cheat that's not always the case though and so Wine does have to handle direct system calls, which needs support from the kernel (at least to not be unusably slow).