3 ms·

I think don’t worry too much about trying to avoid it. Think 5-10 years ahead max, rather than 20. In 20-30 years there’s a good chance that what you’ve writte

I think don’t worry too much about trying to avoid it. Think 5-10 years ahead max, rather than 20. In 20-30 years there’s a good chance that what you’ve written will be obsolete regardless - even if programs from 1995 ran perfectly on modern systems they’d have very few users because of changing tastes. A word processor wouldn’t have networked collaborative editing (fine for GRRM though), an image editor wouldn’t have PNG support, and they wouldn’t be optimised for modern hardware (who would foresee 4K screens and GPUs back then - who knows how we’ll use computers in 2055). There are also always containers if the system needs those old versions.

whizzter 1y ago
2005 is already 25 years ago, and what the author is hinting at is the difference in difficulty between keeping 1980s software running vs keeping 2005 software running is momentous. 1980s NES software is "easy" as in emulating a CPU and the associated hardware (naturally there are corner cases in emulation timing that makes it a lot harder, but it's still a limited system). I used to make demos as mentioned in the article, the ones I did for DOS probably all work under DosBox. My early Windows demos on the other hand relied on a "bad" way of doing things with early DirectDraw versions that mimicked how we did things under DOS (ie, write to the framebuffer ourselves). For whatever reason the changes in Vista to the display driver model has made all of them impossible to run in fullscreen (luckily I wrote a GDI variant for windowed mode that still makes it possible to run). Even worse is some stuff we handle at an enterprise customer, Crystal Reports was even endorsed by Microsoft and AFAIK included in Visual Studio installs. Nowadays abandoned by MS and almost by it's owner (SAP), we've tried to maintain an customized printing applications for a customer, relying on obscure DLL's (and even worse the SAP installer builder for some early 2000s install technology that hardly works with modern Visual Studio). Both these examples depend on libraries being installed in a full system, sure one could containerize needed ones but looking at the problem with an archivist eyes, building custom Windows containers for thousands of pieces of software isn't going to be pretty (or even feasible in a legal sense both with copyright and activation systems). Now you could complain about closed source software, but much of a tad more obscure *nix software has a tendency to exhibit a huge part of "works on my machine" mentality, configure scripts and Docker weren't invented in a vacuum.
- saurik 1y ago
  > 2005 is already 25 years ago o_O
  - pvtmert 1y ago
    a confirmed time-traveller :)
  - whizzter 1y ago
    Brainfart, the DDraw based demos I wrote about were made from 1999 to 2002 so around 25 years ago but then wrote 2005 because iirc the enterprise stuff I also mentioned were probably made around then. Regardless, it's all of the win2k-XP era vintage before Mac's and phones started gaining marketshare and developing with deep Windows integrations was a totally rational choice.

whizzter 1y ago

2005 is already 25 years ago, and what the author is hinting at is the difference in difficulty between keeping 1980s software running vs keeping 2005 software running is momentous. 1980s NES software is "easy" as in emulating a CPU and the associated hardware (naturally there are corner cases in emulation timing that makes it a lot harder, but it's still a limited system). I used to make demos as mentioned in the article, the ones I did for DOS probably all work under DosBox. My early Windows demos on the other hand relied on a "bad" way of doing things with early DirectDraw versions that mimicked how we did things under DOS (ie, write to the framebuffer ourselves). For whatever reason the changes in Vista to the display driver model has made all of them impossible to run in fullscreen (luckily I wrote a GDI variant for windowed mode that still makes it possible to run). Even worse is some stuff we handle at an enterprise customer, Crystal Reports was even endorsed by Microsoft and AFAIK included in Visual Studio installs. Nowadays abandoned by MS and almost by it's owner (SAP), we've tried to maintain an customized printing applications for a customer, relying on obscure DLL's (and even worse the SAP installer builder for some early 2000s install technology that hardly works with modern Visual Studio). Both these examples depend on libraries being installed in a full system, sure one could containerize needed ones but looking at the problem with an archivist eyes, building custom Windows containers for thousands of pieces of software isn't going to be pretty (or even feasible in a legal sense both with copyright and activation systems). Now you could complain about closed source software, but much of a tad more obscure *nix software has a tendency to exhibit a huge part of "works on my machine" mentality, configure scripts and Docker weren't invented in a vacuum.

saurik 1y ago
> 2005 is already 25 years ago o_O
- pvtmert 1y ago
  a confirmed time-traveller :)
- whizzter 1y ago
  Brainfart, the DDraw based demos I wrote about were made from 1999 to 2002 so around 25 years ago but then wrote 2005 because iirc the enterprise stuff I also mentioned were probably made around then. Regardless, it's all of the win2k-XP era vintage before Mac's and phones started gaining marketshare and developing with deep Windows integrations was a totally rational choice.