Examining Windows 1.0 Hello.c

Re:Examining Windows 1.0 Hello.c by NCommander on Monday May 25, 2020 @09:56PM (#23306740)

No, not really. You can get chroots to run on a command kernel but ABI changes happen without soversion bumps which stupidly complicate matters. Godhelp you if your application tries to use weird ALSA or even worse, OSS features.

I've been down that road, there's nothing good to say about it.

[ Parent | on HN ]

Re:Examining Windows 1.0 Hello.c by msla on Wednesday May 27, 2020 @02:04PM (#23327275)

I have plenty of experience which says otherwise, both for Windows breaking compatibility and Linux keeping it.

[ Parent | on HN ]

Re:Examining Windows 1.0 Hello.c by megameter on Monday May 25, 2020 @10:51PM (#23306993)

The actual form of backwards compatibility in Linux is "gcc still builds the C and bash still runs the shell script".

Which is nice in that most every distro carries around a gazillion packages of obscure old code that still builds, but it also means that binaries are heavily disrespected, and the development environment is and forever remains centered around the GNU toolchain.

[ Parent | on HN ]

Re:Examining Windows 1.0 Hello.c by asveikau on Tuesday May 26, 2020 @12:51AM (#23307533)

> Godhelp you if your application tries to use weird ALSA or even worse, OSS features.

What's a weird ALSA or OSS feature? What do you expect in its place?

OSS as an API was really dead simple. open, ioctl, read or write... That interface is still working fine on FreeBSD.

There is an OSS to ALSA compatibility driver.

I'm sure whatever you're expecting (pulseaudio? yech.) can fake being an ALSA device enough to fool anyone.

[ Parent | on HN ]