Make Apps for Linux

What language independent allocator? I'm unaware of any memory interfaces in programming languages that aren't specific to that language.

What would you use instead of malloc and free?

This what the "pressure-vessel" container from collabora (used by valve on dota2/cs2), is trying to solve... but now the issue is the container itself as it does _NOT_ follow fully the elf loading rules for all elf binaries and does ignore many configuration parameters of many software packages (data files location, pertinent environment variables, etc), basically presuming "ubuntu" to be there.

Basically, I have my vulkan driver requiring fstat from 2.33 but the "pressure-vessel" (sniper version), has a glibc 2.31, then it does parse partially my global elf loading configuration and the configuration of some packages to import that driver and all its dependencies... including my glibc elf loader... ooof! That level of convolution will have a very high price all over the board.

I have arguments often with one of "pressure-vessel" devs because of some shortcuts they took which do break my distro (which is really basic and very vanilla, but not "ubuntu"). It took weeks to get the fixes in (I guess all of them are in... until the glibc devs manage to do something which will wreak havock on "pressure-vessel"). Oh... that makes me think I need to warn them about that super new and recent ELF relocation type they will have to parse and detect in host drivers...

On my side, I am investigating some excrutiatingly simple modern file format which should help a lot fighting those issues, there will be technical trade-offs obviously (but would run-ish on "old" kernels anyway with elf "capsules" and an orthogonal runtime). Like json is for xml, but for elf/pe.

It seems only the linux ABI can be trusted... til Linus T. is able to hold the line.

That something that already exists may not be built in the way you are aiming for.

That other something might be led by a dickhead that you can't get along with, or a community that's not receptive to your suggestions or patches.

Social processes and blockages can lead to losing motivation to contribute. Not everyone is cut out to be this happy-go-lucky team player that has no personality.

As for myself, I'd rather start from scratch because 1) I'll control every variable, 2) I don't have to mess around with some existing social and tech infra, 3) I don't have to talk to anyone and convince them my ideas are good, 4) who wants to spend more time arguing or discussing than writing code?

The solodev experience is just better. You're not hamstrung by politics and social process. Being a team player has only led to misery for me.

What has ChatGPT got to do with it? We're talking about Unix style CLIs.

Windows standard C and C++ ABI is stable since 2017. So the last 3 releases of the Visual C Compiler and C runtime hasn't changed the ABI.

However Windows also has a lower level system API / ABI i.e. Win32 that's always stable all the way to Win 95. WinSXS sometimes helps for certain legacy apps too. This allows apps using different C libraries to work together. Win32 contains everything about the OS interface. Creating windows, drawing things, basic text, allocating pages from the OS, querying users, getting info about files is all stable. Win32 is the lower level of the C library. There is also a better separation of the functions in different DLLs. Win32 has multiple DLLs that has different jobs and they are mostly orthogonal. Kernel32 contains core almost system call stuff. Shell32 contains interactions with the OS shell i.e. creating windows, message boxes, triggering different UIs.

The surrounding libraries like DirectX / DirectPlay / DirectWrite that are also used by the games are also part of the system libs starting from 7. They are also stable.

On Linux world there is no separation of the system level libraries and normal user libraries. Glibc is just another library that one depends on. It contains the entire lower level interface to kernel, all the network stuff and POSIX user access stuff. It also contains a component that has no job in a C library: the dynamic executable loader. Unlike Windows on the Unix systems the C library is at the lowest level and Glibc being the default libc for Linux and making itself the default provider of the dynamic executable loader makes writing stable ABI almost impossible. Since other libraries depend on Glibc and executables depend on Glibc's dynamic loader everything is affected by the domino effect.