Fine, but I get the distinct impression you (and other people in your "camp") don't want anyone else to watch his content either, and that's why you're posting about it. You probably wouldn't do it if he was publicly supporting the legality of weed or gay marriage in his country?

64K of actual text content in a single node could be reached in some documents, but it's not that small, more than a chapter of a typical book.

What was always a problem for segmented memory was graphics, at least if you wanted higher resolution than 320x200 at 256 colors. But you could have a segment pointer to each row of pixels instead of an entire image, as long as it would still fit within 1 MB (16 MB in the 286 protected mode).

    9B5 BIST1  -> TMPD    0x0303         PASS2
    9B6 SIGMA  -> EDX
    9B7 BIST2  -> TMPE    TMPD           XOR
    9B8 SIGMA             0x3ddc0c2c     XOR
    9B9 SIGMA  -> EAX     BOOTUP_JUMP    JFPUOK

Also browsers by default using a blocklist from some company, and showing a giant scary warning and contacting their server when the user deliberately navigates to an URL that is on that list. That should be opt-in as well, rather than something that just happens and is considered acceptable.

Besides the blocking, being able to see at the click of a button what kind of crap most sites want to load is really eye opening. And they would do so completely silently if you're using a "normie" browser created or financially supported by the largest advertising company in the world.

Instead the mainstream gets "security features" like Safe Browsing, where it connects to a Google server every day without most people's consent or even knowledge, downloading a list of hashes of "bad stuff" to block. Like open source software to download videos from YouTube (yt-dlp), which it flags as malware. Of course the tinfoil hat conspiracy theory that it's also sending every URL you visit to their server isn't true -- only the ones that match a hash, "to check for false positives". It's easy to see how this mechanism could be abused to log who is visiting particular URLs of interest, without alerting the user to it happening. As far as I see it, you would just have to trust them when they super-double-pinky-swear they would never do this. And of course the TLAs wouldn't allow them to disclose it if something like this happened on their orders.

On the Z80 and 8086, the code can be made one byte shorter by taking advantage of adjust-after-subtraction, which the 8080 didn't have (and on 6502 worked differently):

    CP   10      / CMP  AL,10      ;set carry if valid decimal digit
    SBC  A,69H   / SBB  AL,69H     ;0..9 => 96h..9Fh (auxC=1), 10..15 => A1h..A6h (auxC=0)
    DAA          / DAS             ;subtract 66h if auxC set, 60h if clear

    cmp dword [rax], 'XAUT'
    jne .rxa_next
    cmp dword [rax+4], 'HORI'
    jne .rxa_next
    cmp word [rax+8], 'TY'
    jne .rxa_next
    cmp byte [rax+10], '='
    jne .rxa_next
    ; Found XAUTHORITY=path

This pattern is used everywhere for copying or comparing strings, this was just one example of it.

There's a state variable that's used to keep track of whether the input is text to be displayed or part of a control sequence. It's a full 64 bits, probably not because we need 18 quintillion states? Here's how it is evaluated:

    ; Dispatch based on state
    mov rcx, [vt_state]
    cmp rcx, VT_ESC
    je .vtp_esc
    cmp rcx, VT_CSI
    je .vtp_csi
    cmp rcx, VT_CSI_PARAM
    ...

This code is on the "slow" path, there's a faster one for 7-bit ASCII outside of control sequences, with a lengthy comment by Claude at the top on how it optimized this. Even this one starts with a bunch of conditionals though:

    cmp qword [vt_state], 0            ; VT_NORMAL == 0
    jne .vtp_loop_slow
    cmp dword [utf8_remaining], 0
    jne .vtp_loop_slow
    cmp byte [pending_wrap], 0
    jne .vtp_loop_slow

    mov rbx, [grid_cols]
    sub rbx, [cursor_col]              ; rbx = cells left on this row
    test rbx, rbx
    jle .vtp_loop_slow                 ; no room (or already past)

I freely confess that I'm a "Luddite", and was explicitly looking for bad (and obviously so) code, but this took me just a few minutes of scrolling through the nearly 20K lines in this file, so it should be somewhat representative of the whole.

That's been a feature since DOS 2.0, there was even an undocumented option AVAILDEV to make the prefix mandatory, instead of having device names present everywhere. But it broke the common trick used to detect if a directory exists ("if exist c:\some\path\nul").

Of course one could say that Windows 11 provides negative value, in which case running DOS 1.00 would also be better ;)

This may actually have been a bug not in the code, but in the assembler used to build it. The 8080 had mnemonics ROL and ROR that rotated through carry, and RLC/RRC (standing for "rotate circular", not "through carry"). Opposite meaning of the 8086 mnemonics! So I suspect this may have been switched up in the assembler, especially if it was running on an 8080 machine and developed by someone more familiar with its instruction set.

The STORE bug would have prevented using files over the size of 512 bytes, not just 64K. It's dividing by the sector size, and if DX was greater than that, it would have caused a "divide overflow" exception, since the result wouldn't fit in 16 bits.

(Also, by the Laws of Robotics you have to tell me if you're an LLM, or used one to generate this comment.)

EDIT: not an assembler bug, it seems. The printed listing shows that it produced the correct opcode for ROL (RCL would be D1 D1):

    0A28 8A 0E D4 1B           1353  MOV CL,[RELOC]
    0A2C D1 C1                 1354  ROL CX
    0A2E D1 C1                 1355  ROL CX
    0A30 88 0E D4 1B           1356  MOV [RELOC],CL

Early versions of Microsoft Flight Simulator included a handler for the divide exception, which adjusted the result to +/- "infinity" (for a 16-bit signed integer, 32767 or -32768). The rest of the code relied on this in order to work correctly, and it was more efficient to take advantage of the processor's microcode doing this check rather than coding it explicitly before every division.

So even if it doesn't make mathematical sense, being able to continue after this type of exception is a useful feature to have.

>(and if you ignore SIGSEGV, it is considered perfectly acceptable that your program spins in a SIGSEGV loop until you kill it.)

This, on the other hand, shouldn't ever be acceptable. If a fatal-by-default signal is just ignored, it should always terminate the process.

What Windows 9x didn't have was security. A program could interfere with these mechanisms, but usually only if it was designed to do that, not as a result of a random bug (if the entire machine crashed, it was usually because of a buggy driver).

Merely pointing out that where both operations were available, there seems to have been a preference to use SUB instead, with some continuity from early business-oriented mainframes, to the 360, to the PC.

It could have been added to x86, even as a group of single-byte opcodes with the register encoded in three bits (as with PUSH, POP, and INC/DEC outside of long mode). But the XOR idiom was already established on the 8080 by that point.

(There was another, now deleted, comment somewhere in this thread that mentioned IBM's preference for SUB. Source of that statement was Claude, but it seems very likely to be correct. The BIOS code I've checked myself, lots of 'SUB AX,AX', no XOR)

There's also the TEST instruction, which does a logical AND but without storing the result (like CMP does for SUB). This can be used to test specific bits.

Testing a single register for zero can be done in several ways, in addition to CMP with 0:

    TEST AX,AX
    AND  AX,AX
    OR   AX,AX
    INC  AX    followed by DEC AX (or the other way around)

Also any arithmetic operation sets those flags, so you may not even need an explicit test. MOV doesn't set flags however, at least on x86 -- it does on some other architectures.