Amazing. I've never been anywhere that lost their source code. Would love to know how it happens.
1. Contractor relationship gone sour, turned out they had withheld source code from us. This lead to a dispute regarding the code ownership. Meanwhile we were running the corresponding binaries in the wild. We ended up reverse engineering the missing parts.
2. Source code is centrally managed on a server, hard disk failure, restore not working or backups wholly missing, don't remember. This was the pre-git era, probably Visual SourceSafe, which was entirely centralized.
For me personally, let's just say I feasted my eyes and learned a lot. But I wager that there is still a lot of companies vulnerable in very similar ways today.
There were version control software around in the 70’s but I do not think that the adoption rate was very high. I think it’s reasonable to assume that they didn’t use it in this case.
> The Programmer's Workbench has proven to be very popular with both management and programmers, and is now used by almost all software projects at the author's installation.
The followup paper https://dl.acm.org/doi/10.1145/800283.811111 at https://dl.acm.org/doi/pdf/10.1145/800283.811111 comments:
> SCCS is used extensively within Bell Laboratories. For example, at one installation more than 3 million lines of source code are controlled with sccs. These 3 million lines represent 5000 files and the work of approximately 500 programmers. Additionally, sccs is used at many installations outside the Bell System.
So, SCCS runs under Unix. The software package we are talking about here is Ericsson JZA715, written mostly in Pascal with a bit of PDP-11 assembler, running under RSX-11M, it was first put into operation in Oslo in 1979. I don't know what development platform Ericsson was using, but I doubt it was Unix, seems far more likely to have been RSX-11. What version control systems would Ericsson have been using on RSX-11 in the 1970s? I doubt it was SCCS – could it have been something else? Anything? RSX-11 has a versioned file system, could they have just used that? Or did people build more advanced version control systems layered on top of that base?
The original version was for OS/MVT and implemented in SNOBOL4 using the SPITBOL compiler. https://apps.dtic.mil/sti/pdfs/ADA084326.pdf says that SNOBOL4 was available for the RSX-11D by 1979.
I have no clue what Ericcson was using. My inference from the literature is that apparently when software developers have access to a version control system, they used it, even back in the 1970s.
FWIW, I regard versioned file systems as a form of version control.
I did come across https://books.google.com/books?id=Gf4YAQAAIAAJ&pg=PA89&dq=%2... from 1978 ("Software Designers Workbench", Paul A. Scheffer, Martin Marietta Aerospace
> One of the more innovative of recent software engineering activities is the concept of a Programmer's Workbench (PWB)
(PWB is the term for the product which included SCCS.)
> A simple generalization of the PWB concept results in the idea of a total software engineering facility, i.e., a Designer's Workbench (DWV) ...
> Using a PDP 11/70 architecture base, and system software which includes RSX-11M and the UNIX operating systems, standard PWB tools, and INGRES data base capabilities ...
Since it looks like UNIX supported the RSX-11M in 1978, why couldn't Ericsson be using Unix on an RSX-11M at the same time in Norway?
When I worked on RSX-11M, and later VMS, we did not rely on SCCS because it had no added value. We relied on the file versioning provided by the file system and rarely kept more than one old version around because disk space was always at a premium. Changes to production code required filling out a paper form and passing it to the test department, who would submit the appropriate batch job to rebuild everything, then copy your changed files into the production directories after the tests pass. It was just like modern CI systems, except for the fact that it was mostly manual and a build-and-test cycle was at least 2 days.
...which was then presumably lost/reformatted some time after said dev left (quit? laid off? fired?)
Unable to build said source code, a subsequent developer added a python script to postprocess the output of said binary for their own needs. A hack, but it worked.
Then I got my hands on it. Well, I needed data that was discarded by the binary, so hacking on the python script was a non-starter. Instead, I reverse engineered what the binary was doing by stubbing out enough of the source code to get it building - then compared hex dumps of the outputs and tweaked said source code until my modified source code gave the same output as the checked-in binaries. Then I got rid of the python script by moving the logic into the binary's source code, where it really belonged. Then I made my own changes.
Didn't bother setting up CI though. Was porting a project in a heavily compressed (<1 month!) timeframe, and nobody else needed to touch said binary, and the codebase wasn't going to be used for any future projects (it was pretty terrible, and much time had been spent creating a much better codebase for future projects.) I at least made sure I checked everything in, though!
I have heard this many times, especially for the "single use executable for a specific use case". Many years later, it had made its way into production code and is on its 10th iteration.
Does Ericsson still have the source code for a PDP-11 software package they sold in the 1970s? Maybe they do, maybe they don't.
Did they ever even ask Ericsson for the source? Possibly, they may have thought that modifying PDP-11 software was too hard–people with skills in doing it are hard to find these days, it is unlikely to be written in C, probably either assembly or some obscure language few have heard of–so even if Ericsson still had the source and was happy to hand it over (free of charge or for a reasonable fee), they might not have thought it worth their while to acquire it, and hence never have asked Ericsson for it.
EDIT: Actually, turns out JZA715 is mostly written in Pascal (so not that obscure a language after all) with some modules in PDP-11 assembly – see page 18 of http://srsv.org.au/wp-content/uploads/2017/02/S-38-1-Jan.pdf – the software ran under RSX-11M
It's no wonder everything is emulated/old/never-replaced.
Edit: Apparently it did eventually get replaced https://news.ycombinator.com/item?id=29158255
Edit: Also worth pointing out that formal verification was likely not a component of building the original software, and it likely has bugs it's kept since inception. Updating the API to a language more conducive to formal verification might be an option that improves safety over the legacy system
Edit: Apparently they did replace it all eventually