3 ms·

I've found that the further back in time you go, the harder it is to run programs without encountering odd bugs, until you hit a certain inflection point where

I've found that the further back in time you go, the harder it is to run programs without encountering odd bugs, until you hit a certain inflection point where the systems are so old that they're relatively simple to emulate, and for popular systems we often have high-quality emulators that are capable of running the software reasonably well. For example, try running Diablo 2 (released in 2000!) on modern Windows, or modern macOS: it's not straightforward or bug-free, in my experience. It's reasonably good on Wine, ironically — because the Wine developers have built a really good emulation layer. I don't think it's (application) developer fads; how would that even make sense? Either the OS broke userland, or it didn't; if it didn't, then the same binary should run just as well today as it did then. If it did break userland, that's not the fault of application or framework developers.

jiggawatts 6y ago
I agree to a point, but there are harsh realities to this. To name just a few off the top of my head, where there is no choice in whether the userland changes or not: - Cipher suites and crypto protocols changing often end up "cutting off" older applications because they used an embedded SSL library that can't do TLS 1.2. This is required because vulnerabilities are discovered in older protocols and they must be turned off. - Changes in the CPU instruction sets. For example, it is not possible to run 16-bit Windows binaries in a 64-bit host OS, but there are no 32-bit supported versions of Windows. Even if the majority of the code is 32-bit, a tiny 16-bit component can be a showstopper. I had to support a large (20K concurrent user!) environment that ran a 16-bit DOS application. On Windows 2008 32-bit. In the year 2015. Really. - I've seen apps that just can't handle high performance CPUs or multiple hardware cores, simply because they were written in an 100MHz single-core era. I've seen all sorts of timing issues, deadlocks, etc. For example, one particular release of World of Warcraft simply couldn't patch the game on 4-core CPUs, because one task would race ahead, time out, and then deadlock the downloader utility. That persisted for about a year, because Blizzard thought it was "okay" to support only 99% of their userbase that had 2-core processors that were common at the time. - If you app has any external dependencies of any kind, its days are numbered. License servers. Update checkers. Content providers. Cloud services of any kind. Whatever. It's going to be turned off eventually, and the app will stop dead.
- wheybags 6y ago
  > there are no 32-bit supported versions of Windows Windows 10 has a supported 32 bit version EDIT: It support 16 bit apps too: https://www.groovypost.com/howto/enable-16-bit-application-support-windows-10/ https://www.groovypost.com/howto/enable-16-bit-application-s...
  - jiggawatts 6y ago
    But there's no server version with 32-bit support, but this application required server components not in the desktop edition.
- yuhong 6y ago
  Things like this is part of why for example Mozilla collect TLS telemetry in the first place. I think when they disabled TLS 1.0 and 1.1 they look for very low numbers as well. There is a Reddit thread where I mentioned this that used to have NSA conspiracy theories on this exact topic: https://old.reddit.com/r/firefox/comments/fmdlzp/tls_1011_support_will_be_reenabled/ https://old.reddit.com/r/firefox/comments/fmdlzp/tls_1011_su...
- int_19h 6y ago
  Lack of 16-bit DOS support in Win64 is a choice itself. It's not technically impossible, and there are third-party implementations of a 64-bit NTVDM (e.g. http://www.columbia.edu/~em36/ntvdmx64.html http://www.columbia.edu/~em36/ntvdmx64.html).
ascar 6y ago
> Either the OS broke userland, or it didn't; if it didn't, then the same binary should run just as well today as it did then. I think you're oversimplifing things here. There are many reasons why programs did run on the old OS, but no longer work on the new that are not "new OS broke userland". Some of these boil down to inaccurate or short-term assumptions of the developer. Not exactly userland, but this story [1] why old Windows versions crash on fast processors is an especially entertaining read. The sibling comment by jiggawatts provides good examples. [1] http://www.os2museum.com/wp/those-win9x-crashes-on-fast-machines/ http://www.os2museum.com/wp/those-win9x-crashes-on-fast-mach...
titzer 6y ago
One of my favorite quotes from The Prestige (2006): Alfred Borden : I had a similar trick in my act, and, uh... I used a double. Gerald Root: Mm, I see, very good. Borden: Well, it was, and then it went bad. What I didn't count on was that, when I incorporated this bloke into my act, he had complete power over me. Root : Complete power, you say? ------------ I think about this quote often when I think if dependencies.
- nestorD 6y ago
  As an aside, I have seen magicians arguing that the teleportation effect presented in the prestige would be terrible to do on stage because there is only one logical explanation (you used a double) and thus no mystery. Paradoxically, the fact that it is the only explanation is the thing that makes it a great effect in the Prestige...
int_19h 6y ago
There are old games that don't need emulation to run fine on modern OSes. Age of Wonders (1999) would be one example. For old software that's not games, it's actually more common than not, because the OS really didn't break the userland contract all that much - what it broke is various undocumented assumptions that software was relying on. Games tended to be the kind of software that did it the most, usually in the name of performance (and sometimes also DRM). Although if you unwind to before Windows XP, you also have to consider the Win9x/NT divide. Most games of that era were written for Win9x, and often relied on the liberties offered by the very lax process and memory management model. The transition from 9x to NT - which for most consumers happened via XP - was definitely a big userland breaking change for anything that didn't care about NT compatibility before. (That's why the sweet spot for back-compat is circa 2005 - XP was already well-established, so all new software was written with it in mind - but technologies used were still of the older variety that doesn't drastically change every two years.)

jiggawatts 6y ago

I agree to a point, but there are harsh realities to this. To name just a few off the top of my head, where there is no choice in whether the userland changes or not: - Cipher suites and crypto protocols changing often end up "cutting off" older applications because they used an embedded SSL library that can't do TLS 1.2. This is required because vulnerabilities are discovered in older protocols and they must be turned off. - Changes in the CPU instruction sets. For example, it is not possible to run 16-bit Windows binaries in a 64-bit host OS, but there are no 32-bit supported versions of Windows. Even if the majority of the code is 32-bit, a tiny 16-bit component can be a showstopper. I had to support a large (20K concurrent user!) environment that ran a 16-bit DOS application. On Windows 2008 32-bit. In the year 2015. Really. - I've seen apps that just can't handle high performance CPUs or multiple hardware cores, simply because they were written in an 100MHz single-core era. I've seen all sorts of timing issues, deadlocks, etc. For example, one particular release of World of Warcraft simply couldn't patch the game on 4-core CPUs, because one task would race ahead, time out, and then deadlock the downloader utility. That persisted for about a year, because Blizzard thought it was "okay" to support only 99% of their userbase that had 2-core processors that were common at the time. - If you app has any external dependencies of any kind, its days are numbered. License servers. Update checkers. Content providers. Cloud services of any kind. Whatever. It's going to be turned off eventually, and the app will stop dead.

wheybags 6y ago
> there are no 32-bit supported versions of Windows Windows 10 has a supported 32 bit version EDIT: It support 16 bit apps too: https://www.groovypost.com/howto/enable-16-bit-application-support-windows-10/ https://www.groovypost.com/howto/enable-16-bit-application-s...
- jiggawatts 6y ago
  But there's no server version with 32-bit support, but this application required server components not in the desktop edition.
yuhong 6y ago
Things like this is part of why for example Mozilla collect TLS telemetry in the first place. I think when they disabled TLS 1.0 and 1.1 they look for very low numbers as well. There is a Reddit thread where I mentioned this that used to have NSA conspiracy theories on this exact topic: https://old.reddit.com/r/firefox/comments/fmdlzp/tls_1011_support_will_be_reenabled/ https://old.reddit.com/r/firefox/comments/fmdlzp/tls_1011_su...
int_19h 6y ago
Lack of 16-bit DOS support in Win64 is a choice itself. It's not technically impossible, and there are third-party implementations of a 64-bit NTVDM (e.g. http://www.columbia.edu/~em36/ntvdmx64.html http://www.columbia.edu/~em36/ntvdmx64.html).

ascar 6y ago

> Either the OS broke userland, or it didn't; if it didn't, then the same binary should run just as well today as it did then. I think you're oversimplifing things here. There are many reasons why programs did run on the old OS, but no longer work on the new that are not "new OS broke userland". Some of these boil down to inaccurate or short-term assumptions of the developer. Not exactly userland, but this story [1] why old Windows versions crash on fast processors is an especially entertaining read. The sibling comment by jiggawatts provides good examples. [1] http://www.os2museum.com/wp/those-win9x-crashes-on-fast-machines/ http://www.os2museum.com/wp/those-win9x-crashes-on-fast-mach...

titzer 6y ago

One of my favorite quotes from The Prestige (2006): Alfred Borden : I had a similar trick in my act, and, uh... I used a double. Gerald Root: Mm, I see, very good. Borden: Well, it was, and then it went bad. What I didn't count on was that, when I incorporated this bloke into my act, he had complete power over me. Root : Complete power, you say? ------------ I think about this quote often when I think if dependencies.

nestorD 6y ago
As an aside, I have seen magicians arguing that the teleportation effect presented in the prestige would be terrible to do on stage because there is only one logical explanation (you used a double) and thus no mystery. Paradoxically, the fact that it is the only explanation is the thing that makes it a great effect in the Prestige...

int_19h 6y ago

There are old games that don't need emulation to run fine on modern OSes. Age of Wonders (1999) would be one example. For old software that's not games, it's actually more common than not, because the OS really didn't break the userland contract all that much - what it broke is various undocumented assumptions that software was relying on. Games tended to be the kind of software that did it the most, usually in the name of performance (and sometimes also DRM). Although if you unwind to before Windows XP, you also have to consider the Win9x/NT divide. Most games of that era were written for Win9x, and often relied on the liberties offered by the very lax process and memory management model. The transition from 9x to NT - which for most consumers happened via XP - was definitely a big userland breaking change for anything that didn't care about NT compatibility before. (That's why the sweet spot for back-compat is circa 2005 - XP was already well-established, so all new software was written with it in mind - but technologies used were still of the older variety that doesn't drastically change every two years.)