Win32 Is the Only Stable ABI on Linux

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • WorkOS - The modern identity platform for B2B SaaS
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • SaaSHub - Software Alternatives and Reviews
  • dom-examples

    Code examples that accompany various MDN DOM and Web API documentation pages

  • ROM

    ROM 2.4b6 (by DikuMUDOmnibus)

    Here is some game from '93. Compile it yourself (with some trivial changes).

    https://github.com/DikuMUDOmnibus/ROM

    Trivial !

    But if you still have some obiections then let's wait ~27 years and then talk about games developed on Linux / *nix.

  • WorkOS

    The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.

  • crater

    Run experiments across parts of the Rust ecosystem! (by rust-lang)

    You cut out a key word:

    > Linux is really hurt here by the total lack of any unit testing or UI scripting standards.

    > standards

    I've been very impressed reading how the Rust developers handle this. They have a tool called crater[1], which runs regression tests for the compiler against all Rust code ever released on crates.io or GitHub. Every front-facing change that is even slightly risky must pass a crater run.

    https://github.com/rust-lang/crater

    Surely Microsoft has internal tools for Windows that do the same thing: run a battery of tests across popular apps and make sure nothing in the OS breaks any user apps.

    Where's the similar test harness for Linux you can run that tests hundreds of popular apps across Wayland/X11 and Gnome/KDE/XFCE and makes sure everything still works?

  • dogtail

    > But to drive real world apps through a standard set of user interactions, you really need UI level tests and tools that make UI scripting easy. Windows has tons of these like AutoHotKey, but there is (or was, it's been some years since I looked) a lack of this sort of thing for Linux due to the proliferation of toolkits.

    This made me remember a tool that was quite popular in the Red Hat/GNOME community in 2006-2007 or so:

    https://gitlab.com/dogtail/dogtail

    I wonder if it every got any traction?

  • caniuse

    Raw browser/feature support data from caniuse.com

    If web browsers had any kind of stable interface we wouldn't have: https://caniuse.com/, polyfils, vendor CSS prefixes and the rest of crutches. WASM isn't binary. But that's all irrelevant when we talk about ABI.

    ABI is specifically binary interface between binary modules. For example: my hello_world binary and glibc or glibc and linux kernel or some binary and libsqlite3.

  • steam-runtime

    A runtime environment for Steam applications

    FWIW, these days Valve tries to solve same problems with their steam runtime[0][1]. Still doesn't seem easy, but looks like almost workable solution.

        [0] https://github.com/ValveSoftware/steam-runtime

  • cosmopolitan

    build-once run-anywhere c library

    I don't think Cosmopolitan as it currently exists would do it because the difficulty in making graphics cross-platform [0]. Maybe Cosmopolitan circa 2032?

    [0]: https://github.com/jart/cosmopolitan/issues/35#issuecomment-....

  • InfluxDB

    Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

  • Clp

    COIN-OR Linear Programming Solver

    If you want to compile a large fraction of C/C++ code, just take a distro and rebuild it from scratch--Debian actually does this reasonably frequently. All of the distros have to somehow solve the problem of figuring out how to compile and install everything they package, although some are better at letting you change the build environment for testing than others. (From what I understand, Debian and Nix are the best bets here.)

    But what that doesn't solve is making sure that the resulting builds actually works. Cargo, for Rust, makes running some form of tests relatively easy, and Rust is new enough that virtually every published package is going to contain some amount of unit tests. But for random open-source packages? Not really. Pick a random numerics library--for something like an linear programming solver, this is the most comprehensive automated test suite I've seen: https://github.com/coin-or/Clp/tree/master/test

  • liblinux

    Discontinued Linux system calls.

    > Now, do I think it would make total sense for syscall wrappers and NSS to be split into their own libs (or dbus interfaces maybe) with stable ABIs to enable other libc's, absolutely!

    I worked on this a few years ago: liblinux.

    https://github.com/matheusmoreira/liblinux

    I'm not developing it anymore though because I found out the Linux kernel itself has a superior nolibc library:

    https://github.com/torvalds/linux/tree/master/tools/include/...

    It used to be a single header but it looks like they've recently organized it into a proper project!

    I wonder if it will become some kind of official kernel library at some point. I asked Greg Kroah-Hartman about this and he mentioned there was once a klibc:

    https://old.reddit.com/r/linux/comments/fx5e4v/im_greg_kroah...

    > This is something the BSD's got absolutely right.

    BSDs, every other operating system really, force us to use the bundled C libraries and the C ABI. I think Linux's approach is better. It has a language-agnostic system call binary interface: it's just a simple calling convention and the system call instruction.

    The right place for system call support is the compiler. We should have system_call keywords that cause it to emit code in the aforementioned calling convention. With this single keyword, it's possible to do program literally anything on Linux. Wrappers for every specific system call should be part of every language's standard library with language-specific types and semantics.

  • linux

    Linux kernel source tree

    > Now, do I think it would make total sense for syscall wrappers and NSS to be split into their own libs (or dbus interfaces maybe) with stable ABIs to enable other libc's, absolutely!

    I worked on this a few years ago: liblinux.

    https://github.com/matheusmoreira/liblinux

    I'm not developing it anymore though because I found out the Linux kernel itself has a superior nolibc library:

    https://github.com/torvalds/linux/tree/master/tools/include/...

    It used to be a single header but it looks like they've recently organized it into a proper project!

    I wonder if it will become some kind of official kernel library at some point. I asked Greg Kroah-Hartman about this and he mentioned there was once a klibc:

    https://old.reddit.com/r/linux/comments/fx5e4v/im_greg_kroah...

    > This is something the BSD's got absolutely right.

    BSDs, every other operating system really, force us to use the bundled C libraries and the C ABI. I think Linux's approach is better. It has a language-agnostic system call binary interface: it's just a simple calling convention and the system call instruction.

    The right place for system call support is the compiler. We should have system_call keywords that cause it to emit code in the aforementioned calling convention. With this single keyword, it's possible to do program literally anything on Linux. Wrappers for every specific system call should be part of every language's standard library with language-specific types and semantics.

  • glibc_version_header

    Build portable Linux binaries without using an ancient distro

    If what you're doing works for you, great, but in case it stops working at some point (or if for some reason you need to build on a current-gen distro version), you could also consider using this:

    https://github.com/wheybags/glibc_version_header

    It's a set of autogenerated headers that use symbol aliasing to allow you to build against your current version of glibc, but link to the proper older versioned symbols such that it will run on whatever oldest version of glibc you select.

  • libpst

    library for reading Microsoft Outlook PST files

  • AppImageKit

    Package desktop applications as AppImages that run on common Linux-based operating systems, such as RHEL, CentOS, openSUSE, SLED, Ubuntu, Fedora, debian and derivatives. Join #AppImage on irc.libera.chat

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts