And the 0 and 8. And this was used by some copy-protection to try to prevent reverse engineering. Back then real debuggers (by "real debugger" I mean not just "debugging in your head": but an actual, although very minimal, debugger) were very simplistic too, and so you'd read everything line by line, keeping in your head what the program was doing, was the register contained, what subroutines would do etc. And then you'd have "tricks" by the copy protection where that line with a '0' you just analyzed a few commands before would turn, sneakily, into a '8' (maybe by a function or a side effect of a command etc.).
And when we'd spot it we'd be: "Wait dude, did you notice how sneaky it is, this actually turns the 0 into an 8, so the next this execute, everything shall be corrupt" (or something like that).
And so debuggers got enhanced: for example if anything on screen got modified, the modified value would flash than stay in green. Stuff like that.
Our tools were much more basic.
But then we learned to eat 68x00 and x86 opcodes for breakfast.
It slowed work down a lot but was totally fine - the bank was paying us tons of money hourly.
Hope the tape recorder works to save my work every hour or so. Switch on my Epson fx80 to dump hard copy.
Simpler, happier times.
I sat at a non-internet-connected terminal in the back of the TechED room and typed examples from the book into a very simple editor. Sometimes they compiled and worked. Sometimes they did not work despite being to all appearances character for character the same as the book, and I was often left with no idea why.
It was not an entirely unfamiliar experience. I had a Mattel Aquarius as a young child and spent countless hours typing games in from the back of the manual before attempting to save them to cassette.
nubinetwork•48m ago
pjmlp•33m ago