Thread by @isotopp

@b0rk I am Kris, and I am 53 now.

I learned programming on a Commodore 64 in 1983. My first real programming language (because C64 isn't one) was 6502 assembler, forwards and backwards.

@b0rk Backwards means you stare at a hex dump and see code.

At the age of 16, reversing code and writing code were basically the same to me. I could think what I wanted to do, and type hex into a monitor, even if using an assembler with macros would be faster and easier.

@b0rk In 1986, I upgraded to an Amiga with a 68000 CPU. This required an Assembler, and I also learned C. But using 'cc -S' would be pretty normal, as C compilers at that time did write pretty abysmal code quite often.

@b0rk This only changed with Turbo-C on the Atari, which with -O2 produces code that I would count as vaguely human level.

Copy protections and obfuscations do not work very well. On the Atari I had to look into en.wikipedia.org/wiki/Calamus_(…, because a friend lost all her fonts in the ...

@b0rk ... upgrade from Atari ST to TT. They were bound to a program serial number, which changed for her in the upgrade.

Looking into Calamus at the machine level, evading their debug protection and analyzing the serial number mechanism were the work of a Sunday afternoon.

@b0rk That is likely less time they used to create this system.

Even later, in 2012, I could use this knowledge, which has been dormant for two decades, to reverse Android files (Ingress, in this case), decode protocols,

@b0rk and help with the reimplementation of a client in node.js, with some nifty scripting features.

And in 2018, again, I used this in blog.koehntopp.info/2018/06/18/web… to learn things about stuff IT staff installed on my work Mac.

@b0rk Being familiar with a box at the machine level is a skill that is not being taught much these days, but it gives you access to the full stack from the ground up to the heights of abstractions available today, and it makes you a vastly superior root cause finder and debugger.

@b0rk I have been thinking about this some more.

One book that changed a lot of perspective for me was amazon.com/-/de/dp/013201… (The Design of the UNIX Operating System).

It discusses the V7 source code, and also gives a LOT of background information about the how and why.

@b0rk Having read that, and today having the V7 source open in gitlab (we had to make illegal copies back then) helps a lot to understand simple concepts expressed simply.

You can then open the Linux source, and see the scaled out and evolved version of the same thing.

@b0rk I wrote about this in blog.koehntopp.info/2018/11/29/but….

That is, I am using the V7 source to explain how file writes happen to be atomic in V7, and how that later became a Posix requirement.

@b0rk amazon.com/Programming-80… (Archive.org: archive.org/details/progra…)
"Programming the 80386", Patrick Gelsinger, John Crawford

I learned the 80386 assembler from Gelsinger, who made the CPU while the first Linux versions came into my reach (December 1991, SLS)

@b0rk I have been following the machine initialization, setting up protected mode, leaving real mode, reading BIOS data, and then starting "init" using this book and my C knowledge.

I know how an operating system really starts. Does that help me? No, not immediately.

@b0rk But I do know what the terms page fault, swapping, paging, scheduler, task switch, interrupt handler and so on really mean, and what goes on at the machine level when I speak about this.

Again, this makes me a vastly superior debugger.

@b0rk I read agner.org/optimize/ and understand what goes on here. I can read Spectre and using Agner Fog, understand what breaks and how.

@b0rk I can use godbolt.org and find it insanely useful.

@b0rk I read github.com/dspinellis/uni… and had a laugh.

This github.com/dspinellis/uni… is actual C code, by Stephen R Bourne, who hated the C language. This is where your shell comes from.

@b0rk I think the biggest benefit of having been at the lowest level of the machine is that you actually see what makes the kernel load and the cursor blinks.

You learn, in your gut, that every single thing that happens in the box is explainable, there is code that does this.

@b0rk There is no magic anywhere, there is only another layer in the entire stack that you haven't explored yet.

But that's no obstacle, you have been at the lowest layer, and seen how the sausage was made. There can't possibly be stuff in this that you can't understand or instrument.