How do you preserve the IDE/toolchain over many years?

[RoGeorge]

The problem is that after a few years the toolchain used to develop the old project won't even open on the new PC.
How do you modify/recompile a project after many years?

• A laptop for each project? 
  Don't laugh, there was a dude working for the national power grid, and he had a double door heavy metal locker full of shelves, and all shelves were full of laptop bags, all nicely labeled. One laptop and its cables for each industrial equipment used in their installations. Those laptops were never updated, upgraded or connected online. TBH at first we all thought the dude was crazy, but it's the best and safest method I've seen so far, since industrial equipment tend to have a lifetime of many decades.
• Virtual machines?
• Docker?
• Something else?

[cdev]

This issue is an important one.

In theory virtual machines should all be able to present some standardized hardware profile somehow, having a standardized VM container HW platform would likely work for 9 out of 10 situations.

But the one laptop per project idea is a good one.

[coppice]

I don't think there is a single solution that will work for every circumstance. As well as the software tools, you need to keep the hardware tools, like JTAG interfaces, in a usable state. Most of that hardware is supplied without documentation to assist with repair, and without any commitment from the supplier to long term support. "Buy a new computer, and load the old stuff on it" doesn't work a lot of the time. The old code probably doesn't have drivers for the new hardware, and newer operating systems won't accept the old drivers for your hardware tools. It looks like Intel will soon remove real mode support from its CPUs, meaning lots of old stuff won't run. Virtual machines typically won't support the hardware tools you need. Its really a PITA trying to come up with a robust long term strategy that changing equipment won't derail.

Hanging on to one of the machines used for the original development work is a great strategy for the medium term, but when that dies of old age life gets hard.

[tggzzz]

Given that you probably need to survive:

• toolchain changes (e.g. compiler/IDE)
• your application's library changes (e.g. lib*.so)
• operating system changes (e.g. wayland/unity/XP/Win8)
• peripheral changes (e.g. floppys or parallel ports)
• generic hardware changes (e.g. PATA/SATA/intel/amd)
• specific hardware failures (e.g. PSU caps)

then a VM seems the least troublesome. But you need to assess the specific risks and have specific mitigations.

[nctnico]

This issue is an important one.

In theory virtual machines should all be able to present some standardized hardware profile somehow, having a standardized VM container HW platform would likely work for 9 out of 10 situations.

But the one laptop per project idea is a good one.

I disagree. Relying on old hardware means you'll find out it is broken when it is too late. IMHO a virtual machine is a good option but whatever method you choose you'll still need to test whether it works or not regulary. Especially if you are under a maintenance contract.

The specific programming hardware tggzzz mentions is a good one. If you need special dongles to program firmware then you are in even more danger. In my designs I always use microcontrollers which can be programmed using nothing more than a serial port. Even if serial ports go obsolete there will be tons of hardware out there which can do the job.

[Bruce Abbott]

The problem is that after a few years the toolchain used to develop the old project won't even open on the new PC.
How do you modify/recompile a project after many years?

You redesign the project to use available software and hardware. You do this because:-

1. You can tell your customers they have to 'upgrade' because their stuff is outdated and can no longer be supported. This keeps you in business.

2. Our economy would collapse if people didn't keep buying new stuff.

3. Others may want/need to reproduce your project, and they can't do that if it uses stuff they can't get.

[NorthGuy]

You're likely to encounter problems with IDE, but if you have command-line compilers/tools, you most likely still can run them from the command line on modern PC. So, I don't think there's anything special you need to do. Just strip the tools from their installers, move them to a fresh PC, make sure they can run and you're set.

Of course there's some obsolescence, such as all 16-bit binaries won't run on 64-bit Windows, but you always can come up with something (such virtual PC) to run them if you badly want to do it.

[tggzzz]

You're likely to encounter problems with IDE, but if you have command-line compilers/tools, you most likely still can run them from the command line on modern PC. So, I don't think there's anything special you need to do.

Some but not all C/C++ compilers change the code they generate with monotonous regularity; different optimisations become available, standard (and interpretation thereof) change, etc.

So you may be able to run compilers from the command line, but the code's behaviour may change. You can probably notice that in the middle of a project, but if there are a few years worth of compiler changes it may be more of a problem.

[NorthGuy]

So you may be able to run compilers from the command line, but the code's behaviour may change. You can probably notice that in the middle of a project, but if there are a few years worth of compiler changes it may be more of a problem.

No. If you don't constantly upgrade to newest versions, but keep using the same version of the compiler, then nothing will change.

[tggzzz]

So you may be able to run compilers from the command line, but the code's behaviour may change. You can probably notice that in the middle of a project, but if there are a few years worth of compiler changes it may be more of a problem.

No. If you don't constantly upgrade to newest versions, but keep using the same version of the compiler, then nothing will change.

True, but in practice that can be difficult to achieve, particularly if you have multiple projects with differing requirements. I've see a company really get its knickers in a twist like that.

And, of course, it is all the other components in the environment.

Keeping each project in its own VM has a certainty and simplicity.

[legacy]

A laptop per project for Windows; each laptop is also loaded with different rootfs for linux
and I also have to support an old RISC workstation with different rootfs, thus ...
... I had to buy a couple of workstations in order to be ready in case of failure

[NorthGuy]

Keeping each project in its own VM has a certainty and simplicity.

I remember I bought Connectix virtual machines. Few months later, Microsft bought Connectix and destroyed the product, so it became unusable. Old copies of Connectix didn't run on newer versions of Windows, so I eventually lost all my VMs.

Although I don't use it, I still can run command line version of Microsoft VC++ 3.1 which I bought ca 1995.

Less parts means more reliability.

[legacy]

p.s.
Keil MDK v5.18 vs keil MDK v5.20 the difference is NOT only the OS!
v5.18 runs on WindowsXP/32bit, starting from v5.20 you need Windows 64bit, i.e. Vista, Eight, Ten
but, under the professional version of MDK, trying to migrate projects is not so easy as it should be!

and there are also problems between v3.20 and v5.18 

The solution? Three different toolchains, installed in three different laptops;
this way no one is tempted to "import" a project to a different version of the toolchain.

Funny, ain't it? 

[legacy]

Keeping each project in its own VM has a certainty and simplicity.

This is the solution offered by WindRiver for the development of products based on VxWorks!
We got four pendrives of 32GByte each, and inside of each stick there was a (Oracle VirtualBox) VM.

Nice, simple, and useful! Everything was already configured and ready out of the box!
The backup was also simple and fast! (we cloned each pendrive for backup purposes)

[digsys]

The <=10 yrs plan may be fine for some, but I have huge amounts of hardware out there going 20+ yrs and even 30+ yrs
Very occasionally, I have to do updates ... it's not finding the hardware that's the problem, it's remembering HOW the FOOK I wrote the code !! :-)
I've had to resort to gumtree (ebay) on more than 1 occasion to find "old" laptops / hardware etc

[Kjelt]

VM indeed a good choice however more and more software these days needs a working online subscription.
Those will not be around or supported anymore ten years from now 

[tggzzz]

Keeping each project in its own VM has a certainty and simplicity.

I remember I bought Connectix virtual machines. Few months later, Microsft bought Connectix and destroyed the product, so it became unusable. Old copies of Connectix didn't run on newer versions of Windows, so I eventually lost all my VMs.

Although I don't use it, I still can run command line version of Microsoft VC++ 3.1 which I bought ca 1995.

Less parts means more reliability.

Microsoft has a history of that kind of thing. Remember Microsoft PlaysForSure (TM) music? Once they turned off their servers you could only continue to play it on the same processor+disc.

That and preventing me from reinstalling WinXP onto a replacement disc, and preventing me from buying Win7 to replace WinXP means that I doubt I will ever buy another MS operating system.

Arguably, in this context a VM is the single part, so that ought to be optimum w.r.t. "Less parts means more reliability".

But yes, the VM route is a risk - but is it more or less of a risk given all the failure use cases?

[tggzzz]

VM indeed a good choice however more and more software these days needs a working online subscription.
Those will not be around or supported anymore ten years from now 

Indeed.

Anyone remember Microsoft PlaysForSure (TM)? A singularly inapt name.

[digsys]

Anyone remember these days ? www.pbase.com/digsys/image/166678651/large    4pix
We had to buy an emulation kit for every processor - cost from $8,000 - $12,000 a kit. I had one for the TMS34010 graphics processor ..
THAT baby cost ~$18,000 !!! 30 yrs ago
Then some doofus decides to include all the debug hardware in the CPU / MPU itself !!! :-)  ahh memories
btw: anyone want these? FOC ... time to let history pass.

[cdev]

This is why the guy's strategy of keeping hardware capable of running all mission critical software in a working state makes sense.


At least until they make old books and computing hardware illegal.

Keeping each project in its own VM has a certainty and simplicity.

I remember I bought Connectix virtual machines. Few months later, Microsft bought Connectix and destroyed the product, so it became unusable. Old copies of Connectix didn't run on newer versions of Windows, so I eventually lost all my VMs.

Although I don't use it, I still can run command line version of Microsoft VC++ 3.1 which I bought ca 1995.

Less parts means more reliability.

[westfw]

Ideally, you keep your important products up-to-date with the latest tools.  My long-term "product" commitment at this point (in my post-retirement bliss) is maintaining the Arduino Optiboot Bootloader, and a substantial number of the patches I've applied in the last 7 years are of the "make sure this compiles (and fits) using the new x.x version of the compiler."

Keeping a set of mothballed laptops isn't an awful idea, assuming that they really include everything that you need.  Certainly for a major product, you can afford to spend $1000 ...)  (Or, you can do this as part of the normal age-out process for your computing gear.  Every time you buy a "new" laptop, you put all your "current" products on the old laptop and mothball it.)  (Alas, this ought to include external tools like programmers, as well.)  I have ... a bunch of ATtiny11s that are not supported by most current device programmers.  I have a programmer for them, but the host software relies on a PC bit-banging a "real" serial port.  And all sorts of device programmers that connect to parallel ports...)

VMs... I guess are nice, as long as you make sure that THEY keep running (which seems more difficult than keeping the product working, in some sense.)  I have ... PPC Mac Apps (and documents for them) that ran great on my G4, and then ran for years under PPC emulation on a x86 Mac.  And then x86 Macs stopped emulating PPC.  And there's that "parallel port device hardware" problem...  Could I have found a PPC VM when the x86s came out?  Probably.   When the x86s stopped supporting PPC apps? Maybe.   Now?  I dunno - I could be looking at VMing an older x86 MacOS that does support PPC...

The problem gets "different" in larger companies.   I'm sure it was someone's responsibility to make sure that entire build environments for all active branches continued to work, as the company transitioned from 680x0/HPUX build systems to Sparc/SunOS build systems to Sparc/Solaris to x86/Solaris to x86 Linux server farms, but I'm glad it wasn't mine!

[hendorog]

One approach is to check all of the (software) tools and libraries into version control along with the source code. The build process is fully automatic and grabs the code from version control, builds it and creates a deployable artifact.

Done right that allows full traceability, you can verify the configuration of the environment used to build something, and go back to a point in time and build the deployable artifact exactly as it was. 

Infrastructure as code takes it one step further and you to do the same thing with the OS and any platform level tools like an app server etc.  The binary blobs sit somewhere and a build script verifies them and then grabs the appropriate versions to build the server all automatically. The build script is checked into version control along with the code.

This was done for server based software, not EE/industrial stuff, but the principles are the same.

[nctnico]

Ideally, you keep your important products up-to-date with the latest tools.  My long-term "product" commitment at this point (in my post-retirement bliss) is maintaining the Arduino Optiboot Bootloader, and a substantial number of the patches I've applied in the last 7 years are of the "make sure this compiles (and fits) using the new x.x version of the compiler."

The problem with that is that you need to do a full test on each binary. On a complex product this can take at least a day and probably more due to stress tests which need to be done.

[technix]

Actually I don’t. I used to develop iOS apps, and Apple mandate the use of their latest tools to submit the apps (and that is why I am not moving fully to Swift on that front yet - still a moving target.) So I am used to the “minimum invariant and source dependencies” style.

The minimum invariant part must be truly invariant as way too many projects already depend on it. GNU C (the C language dialect as implemented by both GCC and LLVM/clang, not GCC the compiler itself) is an example as it is a hard dependency of Linux kernel and almost everything running on it. As is IEEE 1149 JTAG port for debug access.

Keeping the dependencies as source code means that compiler updates, as long as it don’t break the language itself (GNU C almost never breaks, Swift breaks frequently) I am not losing my dependencies.

[dgtl]

I'm doing mainly microcontroller and embedded linux development, on linux host machine. In both cases, the whole build is frozen to specific version of toolchain and libraries. All of the toolchains are installed to /opt and binaries symlinked to /usr/local/bin/arm-none-eabi__VERSION_HERE__-gcc etc. The build system of the project uses "CROSS=arm-none-eabi__VERSION_HERE__-" and this locks it to a specific compiler. For embedded linux, we use build everything from scratch principle - every release build is built fully from sources; the only pre-built piece is the bootloader blob, that does not change often. The build system references exact versions of source tarballs and a rebuild uses always same sources. The IDE is non-issue here, as it is just an editor; everything is built using Makefiles, no automatic generation used.
This works reasonably well. In the long run, things still break. For example, some pre-processing scrips of linux kernel build system do not work anymore on new machines due to some changes in perl language. We have a set of patches, that fix these kinds of behaviour where it is needed to rebuild old software.
The versions of all packages and toolchain are updated in major updates. Usually this takes quite a lot of manual work due to things breaking because of API changes etc.