TeX was developed on DECsystem-10/20 machines (36-bit words, your choice of byte size). The various operating systems (Tops20, Sail/Waits, ITS) were superior to Unix in a few ways, one of which was that when a process was suspended (think control-Z, or even control-C) you could issue the built-in shell SAVE command that would save the entire state of the suspended process into a new executable, data segment as well as code. So, on these systems, you could run TeX, have it load a bunch of macros and such, and then SAVE the result as a real, pre-configured executable for the world to run. Easy-peasy.
This was true for the original TeX78 written in Sail, as well as the ultimate TeX82 written in Knuth's WEB macro language on top of Pascal (that nowadays typically gets transpiled to C). Other programs did similar stuff; the feature was in the OS way before TeX started.
(Gory detail: Actually, TeX went a little further, to free up all possible address space for the final executable: The version that could initialize various hash tables and hyphenation trie tables could dump (nee serialize) a binary file of the resulting data structures; then a slimmed-down version that didn't have that code would read the binary info back in to recreate the initial data structure state, and that's what you'd SAVE the production executable from.)
For the unix-y versions of TeX, there was effort made to mimic this sort of thing in user-land with "undump", but admirable as it was, it was a hack, I'm told. These days, everything is so fast, it's not clear that this feature would be worth it anyway.
I really wish that would be possible. I sometimes suspend things, but I would really be able to store them to disk. Sure sometimes you can suspend the whole OS to disk, but that's worse and also doesn't scale. You can't suspend to disk, boot normally, suspend a second time, boot into the first, etc.
I don't think undump is a hack except to the extent the whole thing is a hack. Linux shoves a lot of stuff to userspace that other operating systems put in kernel space; this is just another one of them.
The program loader is not magic - it just reads a list of things to mmap and then mmaps them. If you write a thing that writes a list of what's mmapped and call it the unloader... fine?
Hey, DVI was my suggestion and initial implementation; Knuth's comments in the TeX source code acknowledge this, and they mention plenty more people than Frank Liang who made significant contributions to TeX82: Leo Guibas, Michael Plass, Lyle Ramshaw, Robert Sedgewick, Luis Trabb Pardo, Howard Trickey, Doug Wyatt, and Ignacio Zabala.
Also, Nixie Tubes were absolutely not “tiny.” Typically, they were about the same size as a vacuum tube you’d find in the back of your radio or TV. They were universally used on electronic equipment; less so on consumer devices.
Not so about the Linotype. Back in 1980, I personally ran the Alphatype CRS phototypesetter (bought by DEK for the purpose), in the basement of Margaret Jacks Hall, that produced the entire camera-ready copy of The Art Of Computer Programming, Volume II, Second Edition. The DVI files and Computer Modern fonts were created by the early, Sail-language, 36-bit versions of TeX and Metafont that were later redesigned and implemented to be more cross-platform. Knuth rewrote the firmware that resided on the Alphatype (in 8080 assembly language), and I wrote the code that translated from DVI and drove it from the DEC20 mainframe over a serial line (trickier than it sounds; see our joint paper "Optimal prepaging and font caching" ACM TOPLAS Vol 7 Issue 1).
One point concerning Metafont and Computer Modern (and TeX): A key overall goal of the whole kit and caboodle is that a document written in TeX and using the default fonts would produce exactly the same output on all capable computers and output devices, indefinitely into the future, with the same line breaks, page breaks, character shapes, etc. And in fact TeX files from over half a century ago still produce pixel-perfect results.
This requirement meant that the default fonts had to be portable between printers and typesetters with various resolutions (and other optical filtering attributes). There was simply no other way at the time to accomplish this than using a tool like Metafont to author a home-grown font family like Computer Modern (and even then it was a bit of a hope and a prayer).
And don't even get me started on how 5pt super-super-scripts aren't just 10pt characters scaled down by half, contrary to how post-hot-lead typesetters operated, and not fully addressed commercially until decades later.
thanks for the pointer, were you one of the two students tasked with writing the program during DEK's stay in China? As you mention the problem of smaller fonts it seems font hinting was an invention of the nineties, how did you solve it?
Nope, that would be Michael Plass (thesis title: "Optimal pagination techniques for automatic typesetting systems," though his line-breaking work is what showed up in TeX) and Frank Liang ("Word Hy-phen-a-tion by Com-put-er"). I wasn't there yet.
Metafont users can specify point size, boldness, slant, and whatever other parameters they choose (plus device-specific info like resolution) that can then be used in the simultaneous equations that determine the coordinates of critical points and shapes of pens used to draw the characters. So, for the smaller-font issue, the width of the pen may be a non-linear function of the font point size; ditto for the x-height, etc. In Metafont, it's the responsibility of the font designer / coder to handle it all; there's no automated algorithmic monkeying with the pixels other than what you write. This all becomes much clearer with a perusal of The METAFONTbook.
Kind of astonishing that they managed to retain the institutional / folk knowledge to be able to create a new vacuum tube product, never mind the machinery and inputs to manufacture them.
There have been multiple companies coming back to try to make small batches of vacuum tubes.
It’s not a mysterious process that depends on arcane knowledge. It does require some tooling and process refinement, but the only real obstacle is getting enough demand to pay off the investment in tooling and process refinement.
It's basically the same process as making an incandescent lightbulb. Which is why vacuum tubes took off in the first place. It's more parts and more metal working, for sure. But really it's shaping and dealing with thin films and a vacuum chamber.
In the 90s China bought the whole Mullard factory and shipped it over from England.
If you buy cheap Chinese valves, you're buying Mullard ones which seem to be made to a higher standard than they ever managed in the 80s. Any two random EL34s out of the box will be a closer match than the crazy expensive "super matched pairs" that we used to buy.
Do you have some more info on this? Background, do they still exist? Where is the factory? I visited one older tube factory in China but it was converted to an art/consumption district.
I did some assembly programming on the Fairchild F8 mentioned in the prequel article. Quaintest feature: Doing a “long” jump (more than 127 bytes away) would cause the accumulator register to be clobbered. Presumably, there was nowhere else to store the high (low?) order address byte routing things around to the PC register. This was also a problem for the debugger (in ROM on the development system), since continuing from a breakpoint necessitated a long jump, so it couldn’t restore the accumulator. So, the debugger would just simulate instructions until it hit a jump, which it could then jump to. Or something like that. Fairchild provided a listing of the source to the debugger / emulator, and the line that simulated messing up the accumulator during single-stepping was commented “The F8 Touch!” It made an impression 50 years ago.
Burbank Airport used to get recognizable celebrities to record the canned public announcements in their own style. I seem to recall Joan Rivers, Henny Youngman, Jerry Seinfeld, etc. It took some of the edge off while you waited around, at least for a bit. Don't know if this continues.
Relatedly, there's a steganographic opportunity to hide info in machine code by using "XOR rax,rax" for a "zero" and "SUB rax,rax" for a "one" in your executable. Shouldn't be too hard to add a compiler feature to allow you to specify the string you want encoded into its output.
You can do better. X86 has both "op [mem], reg" and "op reg, [mem]" variants of most instructions, where "[mem]" can be a register too. So you have two ways to encode "xor eax, eax", differing by which of the operands is in the "possible memory operand" slot, the source or the destination.
This one would be a fun challenge in a ctf, or maybe more appropriate for a puzzle hunt – most people would look at the dissassembly and not at the actual bytes and completely miss the binary encoding
That could be a style metric, too. Time spent reversing MS-DOS viruses in my youth showed me assembler programmers very clearly have styles to their code. It's too weak for definitive attribution but it was interesting to see "rhymes" between, for example, the viruses written by The Dark Avenger.
reply