A goat emoji is four bytes in UTF-8: F0 9F 90 90. Feed those bytes to an Intel 8088 and the processor reads LOCK, LAHF, NOP, NOP. The picture disappears. A valid instruction stream remains.
That collision sent the developer behind the MartyPC emulator into a cursed little engineering project: a DOS .COM program composed entirely of displayable emoji. The first version occupies 141 bytes, prints HELLO into CGA text memory, and relies on undocumented 8088 instruction aliases. A larger 1,092-byte version reconstructs and runs a VGA demo.
The technical stunt is excellent. The reproduction failures are better. People copying the same visible emoji from Blogspot, Firefox, Vim, and other surfaces received different bytes. Variation selectors appeared. A text editor added a newline. One file grew from 141 to 142 bytes. The glyph still looked right while the executable stopped being the same program.
the goat contains two interpretations
Most modern emoji use Unicode code points represented by multi-byte UTF-8 sequences. Many begin with F0 9F. On the original 8088, F0 is the LOCK prefix and 9F is LAHF, which copies status flags into part of the AX register. Later bytes can become arithmetic, register exchange, string operations, immediate values, or unfinished instructions that consume bytes from the next emoji.
The author catalogued useful specimens as an “Emojissembly” reference. A cow increments a destination pointer through SCASB. A camel writes a byte through STOSB. A crying cat opens a MOV DI, imm16 instruction and consumes the next emoji’s leading bytes as the immediate value. Sequences with dangling instruction tails become gadgets whose boundaries cross visible characters.
This works because neither UTF-8 nor the 8088 knows what the other layer means. UTF-8 promises a reversible encoding of code points into bytes. The processor consumes bytes as opcodes and operands. Their accidental overlap creates a weird machine inside ordinary text.
every layer can preserve a different truth
Unicode Technical Standard 51 defines emoji as characters and sequences, including fully qualified, minimally qualified, and unqualified forms. The current test data makes the distinction concrete. A smiling face can appear as 263A FE0F in fully qualified emoji presentation or 263A without the presentation selector. A human sees the same basic face. A byte interpreter sees an extra three UTF-8 bytes when FE0F is present.
That gap turned distribution into the hard part. In the Hacker News thread, one reader copied the program through Firefox on Wayland into Vim and missed the expected checksum. Another reproduced the checksum after removing an inserted newline. The author reported that Blogspot and Mastodon could add variation selectors, and directed readers to the disassembler link as the cleaner byte source.
The failure has a familiar shape. Rich-text systems optimize for visual intent. They may normalize, qualify, segment, wrap, or decorate text while preserving what users perceive as the same glyph. Source code, signed messages, hashes, binary payloads, and preservation artifacts need exact code points or exact bytes. A clipboard built for communication becomes an unreliable binary transport.
a text pipeline becomes part of the trusted machine
The program’s dependency chain reaches far outside the emulator. The source website, HTML parser, browser DOM, font and shaping stack, clipboard, editor, encoding choice, newline policy, file writer, and CPU model all participate. Several can preserve the picture while changing the executable.
That makes the artifact a compact test for false equivalence. “Same text” can mean same appearance, same grapheme clusters, same code points, canonically equivalent code points, or identical encoded bytes. Those meanings usually coexist peacefully because prose tolerates small representational changes. Machine-readable artifacts do not.
The problem already matters in less theatrical systems. Build tools hash source bytes. Package managers verify archives. Git identifies objects by serialized content. Cryptographic signatures bind messages to a representation. Security filters inspect one decoding layer while a later interpreter may consume another. Executable emoji turns the ambiguity into something visible enough to laugh at, then precise enough to fail a checksum.
The old EICAR antivirus test string and tiny printable-ASCII DOS programs exploited a similar overlap: characters legible to people could also form executable bytes. Emoji raises the difficulty because one apparent symbol can contain several code points, presentation selectors, or joiners, and because modern interfaces feel entitled to help.
preservation starts below the glyph
A screenshot preserves the joke. A copied emoji sequence may preserve the sentence. Neither necessarily preserves the artifact.
The author supplied expected byte counts, checksums, disassembly links, emulator requirements, and instruction traces. Those details turn a visual curiosity into reproducible software. They also expose where reproducibility ends. If a publishing platform rewrites the sequence, the canonical object has to live somewhere that treats the bytes as bytes.
This is the larger systems-culture lesson. Interfaces teach people to trust what they can see. Computers keep executing representations below the visible layer. When those representations matter, custody needs hashes, raw files, explicit encodings, and tools that refuse to “improve” the payload.
The goat is still a goat on screen. Deep underneath, it is waiting to copy the flags register.