←back to thread

304 points mooreds | 1 comments | | HN request time: 0s | source
Show context
Animats ◴[] No.42167811[source]
Because, when they did it right, in Windows NT 3.51, the users with legacy 16 bit applications screamed. There was a 16-bit DOS compatibility box, but it wasn't bug-compatible with DOS.

Microsoft underestimated the inertia of the applications market. NT 3.51 was fine if you used it as a pure 32-bit operating system. You could even configure it without DOS compatibility. Few did.

replies(3): >>42167845 #>>42168418 #>>42171920 #
Onavo ◴[] No.42167845[source]
Something the Unix world can certainly learn from.
replies(1): >>42168874 #
bigfatkitten ◴[] No.42168874[source]
Sun used to take binary compatibility very seriously. Solaris 8 (and perhaps later releases) still had a compatibility layer for SunOS 4.x binaries. Solaris 11 can still run Solaris 2.6 binaries.

Linux is another matter entirely, if your binaries run at all from one distribution release to the next you're doing well.

replies(3): >>42168999 #>>42172012 #>>42181685 #
cmrdporcupine ◴[] No.42172012{3}[source]
To be clear it is not binary formats themselves that change and cause incompatibility. ELF is ELF and hasn't appreciably changed. And it isn't even really kernel syscalls (though that isn't etched in stone, I don't get the impress it's changed that much). The problem is the libc or other shared libraries.

Seems like the way that this is "fixed" is by using containers. But it feels so...bloated.

replies(2): >>42173791 #>>42177496 #
bitwize ◴[] No.42173791{4}[source]
The solution that Windows provides for the problem -- WinSxS -- is, ultimately, no less bloated.
replies(1): >>42189518 #
1. int_19h ◴[] No.42189518{5}[source]
These days, Windows actually provides a single standard C runtime library in the OS with strong backwards compatibility guarantees, no WinSxS needed.