On one hand, all these mini interpreters and compilers are cool. I have a soft spot for extensible systems. On the other hand, all these things are a huge security problem. When every subsystem and data format is carrying around its own Turing complete bytecode and JIT, they all need to be secure and bug free for the system to be secure and bug free. And that far more code surface to keep clean.
I ran EForth under the Subleq from Howe R.J at https://github.com/howerj/muxleq (the subleq one) first at QuickJS (trivial tasks, almost a 1:1 map from the C code, made in a hurry) and under... jsinterp.py from the infamous yt-dlp but using arrays instead of printing functions. But... if yt-dlp's "mini-JS" implements some captcha input functions... you can add I/O with ease and run EForth with what they call (not me) a "Not totally functional interpreter".
Not totally... until people there run the 110 rule program, Conway's Life, Subleq+EForth...
These little VMs in applications are everywhere. Apple Mach-O binaries have built in opcodes for binding and rebasing symbols interpreted by (numerous) little VMs in dyld:
Their use is less common now since the introduction of the mach-o load command LC_DYLD_CHAINED_FIXUPS, but these opcodes still have to be supported for older binaries. Also, some popular compilers including Zig still emit these opcodes for LC_DYLD_INFO and LC_DYLD_INFO_ONLY.
Busicom 141 PF calculator (1971). This was a product built on the Intel 4004 processor. It was not programmed using Intel 4004 machine langauge directly, but using a more powerful machine language for which the 4004 ran an intepreter included in the image.
All regular expressions are deterministic final automata https://en.wikipedia.org/wiki/Deterministic_finite_automaton (finally, a use for my CS course); the extent to which that counts as a virtual machine varies. Some of the regex syntaxes extend it in ways which don't fit in a DFA and do count as a VM; Perl-compatible RE used to be popular (e.g. in Exim).
It's easier to construct NFAs directly from regular expression definitions (rather than DFAs) because implementing the choice operator is easier. We can convert from NFA to DFA with worst-case exponential blowup.
Interesting. Not that surprising that it works like this. But isn't it a little surprising that things like regexes, printf syntax and other DSLs aren't mostly handled and parsed at compile time in 2026?
Kind of language-dependent since regexes are normally specified as strings and most languages are pretty weak at "run this code at compile time". One of the things Rust users are fond of.
I have also built a C# source generator myself (XML parser generator), but the developer experience is a bit of a hill to climb compared to what it could be.
I've got subleq+eforth (https://github.com/howerj/muxleq) running in JS
which is dead simple to do. No input but I could output
ASCII mapping values to an array.
possibly because yt-dlp updates rapidly and would simply switch to the correct fingerprint, but Google-approved clients use many different and uncontrollable fingerprints (as they use OS TLS facilities for example).
References for the Quake virtual machines:
Quake 1 had QuakeC: [1] https://en.wikipedia.org/wiki/QuakeC [2] Hello world in QuakeC - https://www.leonrische.me/pages/quakec_bytecode_hello_world....
Quake 2 moved to native binaries.
Quake 3 had a new VM that enabled compiling regular C using LCC: [1] https://fabiensanglard.net/quake3/qvm.php [2] Spec - https://www.icculus.org/~phaethon/q3mc/q3vm_specs.html
On one hand, all these mini interpreters and compilers are cool. I have a soft spot for extensible systems. On the other hand, all these things are a huge security problem. When every subsystem and data format is carrying around its own Turing complete bytecode and JIT, they all need to be secure and bug free for the system to be secure and bug free. And that far more code surface to keep clean.
Maybe they can compile the bytecode to the x86 subset in this paper, and check if it is secure using their tool:
https://dl.acm.org/doi/pdf/10.1145/2254064.2254111
SBus peripherals use the Forth language in their PROMs to initialize themselves[1].
[1] https://docs.oracle.com/cd/E19957-01/802-3239-10/sbusandfc.h...
Good call! (Whether it's a directly threaded, indirectly threaded, subroutine threaded, token threaded, Huffman threaded, or string threaded call.)
https://news.ycombinator.com/item?id=38689282
I ran EForth under the Subleq from Howe R.J at https://github.com/howerj/muxleq (the subleq one) first at QuickJS (trivial tasks, almost a 1:1 map from the C code, made in a hurry) and under... jsinterp.py from the infamous yt-dlp but using arrays instead of printing functions. But... if yt-dlp's "mini-JS" implements some captcha input functions... you can add I/O with ease and run EForth with what they call (not me) a "Not totally functional interpreter".
Not totally... until people there run the 110 rule program, Conway's Life, Subleq+EForth...
1 reply →
Some other examples:
- ACPI configuration for power management and platform stuff [1]
- Bitcoin transactions [2]
- TrueType fonts [3]
[1] https://wiki.osdev.org/AML
[2] https://en.bitcoin.it/wiki/Script
[3] https://learn.microsoft.com/en-us/typography/opentype/spec/t...
Since ACPI was mentioned, let's not forget about EFI!
https://uefi.org/specs/UEFI/2.10/22_EFI_Byte_Code_Virtual_Ma...
How about the infamous iOS hack with a VM implemented in a JBIG2 PDF? https://projectzero.google/2021/12/a-deep-dive-into-nso-zero...
These little VMs in applications are everywhere. Apple Mach-O binaries have built in opcodes for binding and rebasing symbols interpreted by (numerous) little VMs in dyld:
https://github.com/apple-oss-distributions/dyld/blob/e9da5ae...
https://github.com/apple-oss-distributions/dyld/blob/e9da5ae...
Their use is less common now since the introduction of the mach-o load command LC_DYLD_CHAINED_FIXUPS, but these opcodes still have to be supported for older binaries. Also, some popular compilers including Zig still emit these opcodes for LC_DYLD_INFO and LC_DYLD_INFO_ONLY.
Busicom 141 PF calculator (1971). This was a product built on the Intel 4004 processor. It was not programmed using Intel 4004 machine langauge directly, but using a more powerful machine language for which the 4004 ran an intepreter included in the image.
The Python pickle format is a bytecode [1], although not a Turing-complete one, I think.
[1] https://formats.kaitai.io/python_pickle/
Quake had it’s own vm also
There is one in golang regular expressions https://swtch.com/~rsc/regexp/regexp2.html
I guess that is why you say re.Compile.
That goes back to Ken Thompson's NFA regex interpreter from 1968 [1], [2], [3]. Note: that whole regex series by Russ Cox [4] is great.
[1] https://dl.acm.org/doi/10.1145/363347.363387 -- Programming Techniques: Regular expression search algorithm
[2] https://swtch.com/~rsc/regexp/regexp1.html -- Regular Expression Matching Can Be Simple And Fast
[3] https://swtch.com/~rsc/regexp/regexp2.html -- Regular Expression Matching: the Virtual Machine Approach
[4] https://swtch.com/~rsc/regexp/ -- Implementing Regular Expressions
I second the Russ Cox recommendation. I read that ages ago and that was what made me realise some theory could actually be useful in practice.
All regular expressions are deterministic final automata https://en.wikipedia.org/wiki/Deterministic_finite_automaton (finally, a use for my CS course); the extent to which that counts as a virtual machine varies. Some of the regex syntaxes extend it in ways which don't fit in a DFA and do count as a VM; Perl-compatible RE used to be popular (e.g. in Exim).
It's easier to construct NFAs directly from regular expression definitions (rather than DFAs) because implementing the choice operator is easier. We can convert from NFA to DFA with worst-case exponential blowup.
Inded:
https://wiki.xxiivv.com/site/rewriting.html
Interesting. Not that surprising that it works like this. But isn't it a little surprising that things like regexes, printf syntax and other DSLs aren't mostly handled and parsed at compile time in 2026?
Kind of language-dependent since regexes are normally specified as strings and most languages are pretty weak at "run this code at compile time". One of the things Rust users are fond of.
C# is in the middle on this one, where specific features get compile-time support and regex is one of them: https://www.devleader.ca/2026/05/03/c-regex-performance-gene...
I have also built a C# source generator myself (XML parser generator), but the developer experience is a bit of a hill to climb compared to what it could be.
Another World (Out of this world) game had its own bytecode [1]
[1] https://github.com/fabiensanglard/Another-World-Bytecode-Int...
RarVM was used in a previous version of the format, newest RAR has removed it, and RarV5 doesn't have a VM.
This list is entirely incomplete without mentioning Java Card.
There is a tiny Java Bytecode VM in an insanely large list of places, you can find some of them here:
https://github.com/crocs-muni/javacard-curated-list https://en.wikipedia.org/wiki/Java_Card
TikTok shipping XOR cipher'd bytecode & interp is right up there: https://news.ycombinator.com/item?id=34109771
VM for obfuscation is a whole thing. Denuvo has a particularly complicated one https://connorjaydunn.github.io/blog/posts/denuvo-analysis/
Other game examples using VMs not for obfuscation: Z-machine and SCUMM-VM.
yt-dlp's jsinterp.py
https://jxself.org/compiling-the-trap.shtml
I've got subleq+eforth (https://github.com/howerj/muxleq) running in JS which is dead simple to do. No input but I could output ASCII mapping values to an array.
https://esolangs.org/wiki/Subleq
So, yes. yt-dlp runs propietary Youtube JS code defying the original purpose.
Why youtube does not use tls fingerprint to block ytdlp?
possibly because yt-dlp updates rapidly and would simply switch to the correct fingerprint, but Google-approved clients use many different and uncontrollable fingerprints (as they use OS TLS facilities for example).
Hopefully, an iota of decency.
[flagged]