> shipping all dependencies (e.g. shipping a container image) gives perfect binary compatibility on Linux
That doesn’t work for GUI programs which use a hardware 3D GPU. Linux doesn’t have a universally available GPU API: some systems have GL, some have GLES, some have Vulkan, all 3 come in multiple versions of limited compatibility, and optional features many of them are vendor specific.
In contrast, it’s impossible to run modern Windows without working Direct3D 11.0 because dwm.exe desktop compositor requires it. If a software consumes Direct3D 11.0 and doesn’t require any optional features (for example, FP64 math support in shaders is an optional feature, but sticking to the required set of features is not very limiting in practice unless you need to support very old GPUs which don’t implement feature level 11.0), will run on any modern Windows. Surprisingly, it will also run on Linux systems which support Wine: without Vulkan-capable GPU will be slow but should still work due to Lavapipe, which is a Linux equivalent of microsoft’s WARP they use on Windows computers without hardware 3D GPU.
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.
> 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.
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.
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.
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.
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.
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.
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.
> 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.
> 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.
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).
Question, from an application developer's perspective: What is the implication in regards to cross-platform Vulkan applications? I.e., my 3D applications all use Vulkan, and they compile and just work on both Windows, and Ubuntu. Does this mean that on other or older distros, they might not work?
I don’t think the support depends on distros much, I think the main variable is hardware. If you have a desktop PC bought in the last ~5 years the support should be OK, for the hardware older than that the support is not guaranteed. GeForce GT 730 (launched in 2014) doesn’t support Vulkan, Intel only supports Vulkan on Windows starting from Skylake launched in 2015.
Then there’re quality issues. If you search internets for “Windows Vulkan issue” you’ll find many end users with crashing games, game developers with crashing game engines https://github.com/godotengine/godot/issues/100807 recommendations to update drivers or disable some Vulkan layers in registry, etc.
On Windows, Vulkan is simply not as reliable as D3D. The reasons include market share, D3D being a requirement to render the desktop, D3D runtime being a part of the OS supported by Microsoft (Vulkan relies solely on GPU vendors), and D3D being older (first version of VK spec released in 2016, D3D11 is from 2009).
Another thing, on Linux, the situation with Vulkan support is less than ideal for mobile and embedded systems. Some embedded ARM SoCs only support GLES 3.1 (which BTW is not too far from D3D 11.0 feature-wise) but not Vulkan.
Agree overall. Just want to point out that Vulkan works on Intel Haswell. I have a 2013 MacBook Air and a 2013 Mac Pro that both have Haswell. Linux kernel 6.14 actually includes an Haswell Vulkan update from Intel themselves.
> Does this mean that on other or older distros, they might not work
Yep exactly. While Vulkan API is well defined and mostly stable, there is no guarantee in Linux implementation will also be stable. Moreover Khronos graphics APIs only deal with the stuff after you allocated a buffer and did all the handshakes with the OS and GPU drivers. On Linux none of those have API / ABI / runtime configuration stability guarantees. Basically it works until only one of the libraries in the chain breaks the compatibility.
This is BS. Vulkan buffers are allocated with Vulkan functions. Window system integration is also provided by window-system specific Vulkan extensions just like it was with WGL/GLX/EGL etc. These are all well defined and stable.
That depends how you build you program and what other dependencies you pull in. But as far as Vulkan is concerned your program should run on any distro that is as least as new as the one you build on (talking about ABI, runtime requirements depend on hardware but don't depend on the system you build on).
This is FUD. There isn't a single real desktop Linux distribution without OpenGL support. The basic OpenGL API hasn't changed ever, it's just been extended. It has even more backwards compatibility than Direct3D. Sure you can deliberately build a distro with only Vulkan or GLES (a mobile API) if you want to be an ass but the same goes for Windows. Same for X11 - Xlib works everywhere even any Wayland-only distribution that gives a single crap about running binary distributed software.
Now GUI toolkits are more of an issue. That's annoying for some programs, many others do their own thing anyway.
That doesn’t work for GUI programs which use a hardware 3D GPU. Linux doesn’t have a universally available GPU API: some systems have GL, some have GLES, some have Vulkan, all 3 come in multiple versions of limited compatibility, and optional features many of them are vendor specific.
In contrast, it’s impossible to run modern Windows without working Direct3D 11.0 because dwm.exe desktop compositor requires it. If a software consumes Direct3D 11.0 and doesn’t require any optional features (for example, FP64 math support in shaders is an optional feature, but sticking to the required set of features is not very limiting in practice unless you need to support very old GPUs which don’t implement feature level 11.0), will run on any modern Windows. Surprisingly, it will also run on Linux systems which support Wine: without Vulkan-capable GPU will be slow but should still work due to Lavapipe, which is a Linux equivalent of microsoft’s WARP they use on Windows computers without hardware 3D GPU.