←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 #
1. account42 ◴[] No.42181685[source]
> Linux is another matter entirely, if your binaries run at all from one distribution release to the next you're doing well.

Linux binary compatibility is actually pretty good. As is glibc's an that of many other low level system libraries. The problem is only programs that depend on other random installed libraries that don't make any compatibility guarantees instead of shipping their own versions. That approach is also not going to lead to great future compatibility in Windows either. The only difference is that on Windows the base system labrary set is bigger while on Linux it is more limited to what you can't provide yourself.