Archive your build chain - the version of the compiler, linker, libraries, and any other tools that you use to produce the executable. Archive the version of the OS they run on, too.
Just keep bootable OS drive image for every project (set of projects) which builds offline. Make sure to also download platform docs, dependency sources, manuals - git clone, javadocs, ruby ri/rdoc so on. Even keep IDE set up there.
I keep that habit currently by separating work with virtual machines. Storage is cheap and I can come back to my project tomorrow or in 2050 with amd64 emulator. It is also easy to backup or archive it - just rsync the image to NAS or burn it on DVD.
> Just keep bootable OS drive image for every project (set of projects) which builds offline.
Those images don't stay bootable, for different reasons:
* Media changes - Try booting from your tape, or your floppy disk set.
* Unsupported new hardware - Remember how your Linux boot partition needed to be at the beginning of the HDD? Or how Windows setup would not recognize SATA drives unless you added drivers from a special floppy disk?
* It boots, then gets stuck or goes blank on you - display driver issues being a common cause of this.
You are right. Solution: keep your boots simple and documented. Try them from time to time too.
I assume some common formats do not change, but it is good to keep some side-notes how to run the thing and what hardware to emulate.
I use Linux because it is open source and boots with broadest hardware range possible - I am sure it will run on emulator of 2010-most popular PC platform in few decades.
As an alternative to archiving the build chain, consider documenting a reproducible build from widely used components.
The risk is that the components of the reproducible build may no longer be available 50 years from now. But rolling your own archival is not bulletproof either, for the same reasons that untested backups aren't bulletproof.
