Author Topic: How do you preserve the IDE/toolchain over many years?  (Read 2490 times)

0 Members and 1 Guest are viewing this topic.

Offline RoGeorge

  • Frequent Contributor
  • **
  • Posts: 579
  • Country: ro
How do you preserve the IDE/toolchain over many years?
« on: December 06, 2017, 03:19:46 AM »
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?  :o
    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?

 
The following users thanked this post: cdev

Offline cdev

  • Super Contributor
  • ***
  • Posts: 2778
  • Country: 00
  • Friend
Re: How do you preserve the IDE/toolchain over many years?
« Reply #1 on: December 06, 2017, 03:29:36 AM »
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.
"What the large print giveth, the small print taketh away."
 

Offline coppice

  • Super Contributor
  • ***
  • Posts: 2868
  • Country: gb
Re: How do you preserve the IDE/toolchain over many years?
« Reply #2 on: December 06, 2017, 03:30:35 AM »
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.
« Last Edit: December 06, 2017, 03:32:54 AM by coppice »
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 5923
  • Country: gb
    • Having fun doing more, with less
Re: How do you preserve the IDE/toolchain over many years?
« Reply #3 on: December 06, 2017, 03:37:53 AM »
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.
There are lies, damned lies, statistics - and ADC/DAC specs.
Gliding aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 12992
  • Country: nl
    • NCT Developments
Re: How do you preserve the IDE/toolchain over many years?
« Reply #4 on: December 06, 2017, 04:00:55 AM »
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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Online Bruce Abbott

  • Frequent Contributor
  • **
  • Posts: 533
  • Country: nz
    • Bruce Abbott's R/C Models and Electronics
Re: How do you preserve the IDE/toolchain over many years?
« Reply #5 on: December 06, 2017, 05:20:37 AM »
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.



 
The following users thanked this post: Jeroen3

Online blueskull

  • Supporter
  • ****
  • Posts: 7804
  • Country: cn
  • Power Electronics PhD Candidate
Re: How do you preserve the IDE/toolchain over many years?
« Reply #6 on: December 06, 2017, 05:30:40 AM »
If a chip doesn't have support from wither GCC (or SDCC, etc.) or a big brand commercial IDE (CCES, Keil, CCS) with LTS, then I'm not touching it.
Also, I expect a project to have a lifecycle of <=10 years -- even if MCUs don't get obsolete, some other parts, such as regulators or OPAMPs, will.
Unlike LM1117/LM78xx, those fancy, niche TPS7xxxx/MIC5xxx LDOs in SON2*2 package can be obsolete at any time.
SIGSEGV is inevitable if you try to talk more than you know. If I say gibberish, keep in mind that my license plate is SIGSEGV.
 

Online NorthGuy

  • Frequent Contributor
  • **
  • Posts: 518
  • Country: ca
Re: How do you preserve the IDE/toolchain over many years?
« Reply #7 on: December 06, 2017, 06:00:52 AM »
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.
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 5923
  • Country: gb
    • Having fun doing more, with less
Re: How do you preserve the IDE/toolchain over many years?
« Reply #8 on: December 06, 2017, 07:13:19 AM »
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.
There are lies, damned lies, statistics - and ADC/DAC specs.
Gliding aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Online NorthGuy

  • Frequent Contributor
  • **
  • Posts: 518
  • Country: ca
Re: How do you preserve the IDE/toolchain over many years?
« Reply #9 on: December 06, 2017, 08:13:21 AM »
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.
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 5923
  • Country: gb
    • Having fun doing more, with less
Re: How do you preserve the IDE/toolchain over many years?
« Reply #10 on: December 06, 2017, 08:37:31 AM »
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.
« Last Edit: December 06, 2017, 08:41:38 AM by tggzzz »
There are lies, damned lies, statistics - and ADC/DAC specs.
Gliding aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 
The following users thanked this post: 3db

Offline legacy

  • Super Contributor
  • ***
  • Posts: 2631
Re: How do you preserve the IDE/toolchain over many years?
« Reply #11 on: December 06, 2017, 09:25:17 AM »
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 :palm:
 

Online NorthGuy

  • Frequent Contributor
  • **
  • Posts: 518
  • Country: ca
Re: How do you preserve the IDE/toolchain over many years?
« Reply #12 on: December 06, 2017, 09:32:37 AM »
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.
 
The following users thanked this post: Someone

Offline legacy

  • Super Contributor
  • ***
  • Posts: 2631
Re: How do you preserve the IDE/toolchain over many years?
« Reply #13 on: December 06, 2017, 09:33:59 AM »
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  :palm: :palm: :palm:

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?  :D
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 2631
Re: How do you preserve the IDE/toolchain over many years?
« Reply #14 on: December 06, 2017, 09:43:54 AM »
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)
 

Offline digsys

  • Supporter
  • ****
  • Posts: 1553
  • Country: au
    • DIGSYS
Re: How do you preserve the IDE/toolchain over many years?
« Reply #15 on: December 06, 2017, 09:53:21 AM »
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
Hello <tap> <tap> .. is this thing on?
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 3969
  • Country: nl
Re: How do you preserve the IDE/toolchain over many years?
« Reply #16 on: December 06, 2017, 09:56:29 AM »
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  :(
 
The following users thanked this post: cdev

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 5923
  • Country: gb
    • Having fun doing more, with less
Re: How do you preserve the IDE/toolchain over many years?
« Reply #17 on: December 06, 2017, 10:41:52 AM »
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?
There are lies, damned lies, statistics - and ADC/DAC specs.
Gliding aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 5923
  • Country: gb
    • Having fun doing more, with less
Re: How do you preserve the IDE/toolchain over many years?
« Reply #18 on: December 06, 2017, 10:43:55 AM »
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.
There are lies, damned lies, statistics - and ADC/DAC specs.
Gliding aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline digsys

  • Supporter
  • ****
  • Posts: 1553
  • Country: au
    • DIGSYS
Re: How do you preserve the IDE/toolchain over many years?
« Reply #19 on: December 06, 2017, 10:44:19 AM »
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.
Hello <tap> <tap> .. is this thing on?
 

Offline cdev

  • Super Contributor
  • ***
  • Posts: 2778
  • Country: 00
  • Friend
Re: How do you preserve the IDE/toolchain over many years?
« Reply #20 on: December 06, 2017, 11:02:12 AM »
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.
"What the large print giveth, the small print taketh away."
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 2355
  • Country: us
Re: How do you preserve the IDE/toolchain over many years?
« Reply #21 on: December 06, 2017, 12:35:56 PM »
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!
 

Offline hendorog

  • Frequent Contributor
  • **
  • Posts: 879
  • Country: nz
Re: How do you preserve the IDE/toolchain over many years?
« Reply #22 on: December 06, 2017, 01:04:52 PM »
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.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 12992
  • Country: nl
    • NCT Developments
Re: How do you preserve the IDE/toolchain over many years?
« Reply #23 on: December 06, 2017, 07:23:51 PM »
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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Online technix

  • Super Contributor
  • ***
  • Posts: 2077
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: How do you preserve the IDE/toolchain over many years?
« Reply #24 on: December 06, 2017, 07:59:33 PM »
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.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf