Examining Windows 1.0 Hello.c

Re:Examining Windows 1.0 Hello.c by msla on Monday May 25, 2020 @08:00PM (#23306141)

Desktop Linux has all of that compatibility. Nothing fundamental has changed: You need the libraries, and if you have them, it works, just like in Windows.

[ Parent | on HN ]

Re:Examining Windows 1.0 Hello.c by asveikau on Monday May 25, 2020 @10:28PM (#23306909)

Are you aware that the original binary format of Linux was not ELF?

Then, the last time I tried to run a binary from the 90s, it required libc5, from the days before distros switched to glibc.

[ Parent | on HN ]

Re:Examining Windows 1.0 Hello.c by msla on Monday May 25, 2020 @11:10PM (#23307061)

> Are you aware that the original binary format of Linux was not ELF?

Yes, and having an a.out interpreter is just another dependency.

> Then, the last time I tried to run a binary from the 90s, it required libc5, from the days before distros switched to glibc.

It's a library. libc is versioned like everything else.

[ Parent | on HN ]

Re:Examining Windows 1.0 Hello.c by asveikau on Monday May 25, 2020 @11:46PM (#23307221)

Nobody is distributing that library anymore. Whereas an equivalently aged binary on Windows will load today without extra dependencies.

I would think that the kernel would have dropped binfmt_aout by now, but I just looked and it's still there. Wonder if any distros build it.

[ Parent | on HN ]

Re:Examining Windows 1.0 Hello.c by chungy on Tuesday May 26, 2020 @12:57AM (#23307562)

> Nobody is distributing that library anymore.

There exist plenty of archives of old Linux distributions. "Nobody" turns out to be quite a lot of people/servers.

> Whereas an equivalently aged binary on Windows will load today without extra dependencies.

I wouldn't go so far. The 64-bit port of Windows dropped support for all 16-bit applications, whereas they still run flawlessly through Wine.

[ Parent | on HN ]

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 ]