Hacker News Reader

Comment by boznz | Hacker News Reader

On one particular project from 1995 where the hardware was very cost optimised, the C program compiled to 1800 bytes which meant we could save nearly a dollar by buying micro-controllers with 2KB flash rather than 4KB flash. We manufactured 20,000 units with this cheaper chip. 2 years down the line we needed a simple code change to increase the UART baud rate to the host, a change that should have resulted in the same sized binary, but instead increased it to 2300 bytes due to a newer C compiler. We ended up tweaking the assembly file and running an assembler, then praying there would be no more changes!

I have always over specified the micro-controllers a little from that point, and kept a copy of the original dev environment, luckily all my projects are now EOL as I am retired.

View on HN

Could also just edit the old binary directly in a pinch?

One of my best rescue jobs involved doing this in 1999, yes that 1999. The client had shuttered their development department years before but was expecting to continue happily supporting and selling their simple enough alarm system products indefinitely. Testing revealed that come 2000 the alarms would just fire continually. Whoops. Fortunately there was one dev PC they'd decided to keep and not touch. Found the offending .c code and the corresponding offending machine code after some disassembly. A little bit of creative assembly language was required to squeeze an extra check in but really no big deal and the day was saved. I remember the client manager being ridiculously happy and grateful.

Whilst I disapprove of your use of the word "just", which I am strongly of the opinion should be banned in engineering circles...

I have done something similar, albeit in a different context, to fix the behaviour of a poorly performing SQL query embedded in a binary for which the source code was not easily available (as in: it turned out that the version in source control wasn't the version running in production and it would have been quite a lot of work to reverse engineer the production version and retrofit its changes back to the source - and, yes, this is as bad as you think it is).

When I initially suggesting monkey patching the binary there was all manner of screaming and objections from my colleagues but they were eventually forced to concede that it was the pragmatic and sensible thing to do.

> it turned out that the version in source control wasn't the version running in production and it would have been quite a lot of work to reverse engineer the production version

When I started at my work, a previous software dev with practices more like a mechanic than a software dev didn't use tags and all binaries deployed to production were always the default version 1.0.0.0 of the C# project templates in Visual Studio. To make matters worse, variants of the software were just copy pasted in CVS with their core code checked in as binaries and not their original C# projects. Fun times finding out what actually ran on production, and patching anything in it!

"luckily all my projects are now EOL as I am retired."

I doubt that everything you ever worked on is end-of-life. Some of it is still out there...

Correct, I have thousands of tank temperature controllers still out there, still working fine where the End Of Life was 3 years ago. EOL just means support for spares and software updates cannot be guaranteed past that point, and is mainly tied to the EOL of the specific micro-controller used.

It's end-of-life.

If it it still running out there, it's runningin zombie state.

Better have kept those environments.

Reply on news.ycombinator.com