I can probably claim to be the inventor of 64 and 32 byte competitions back in my demoscene days.
I was organizer of a small demo party called 0a000h. 4k intro competitions were quite common, 256 bytes happened sometimes, I think we were the first to go even lower. We had some impressive results especially in the 64b.
We also did fast-size-coding competitions. We showed a simple effect and then asked people to come up with the smallest way to replicate that within a couple of hours.
There is also this (unfortunately discontinued) competition series, with a lot more tiny programs to examine and maybe even challenge yourself against:
Tiny assembler programs tend to abuse arcane x86 instructions that have one or two byte encodings, but aren't practical for real use (and compilers don't emit them). Add some binary format tricks on top.
A little bit of assembly writing (and more importantly, reading) should be a part of a good CS curriculum but these tiny programs aren't a good place to start.
It's not Windows but MS-DOS, which allows for pure binary executables (COM format) that are nothing but instructions. Thus even a single-byte file is executable (C3, RET - i.e. exit immediately.)
AFAIK Linux has a higher minimum size, as the ELF header alone has to be at least 45 bytes:
Would it run 16 bit code under x64 Linux (w/o any translation / emulation)? As Windows can't do it (only x32 versions can), thus wondering, if this is a CPU limitation.
I was organizer of a small demo party called 0a000h. 4k intro competitions were quite common, 256 bytes happened sometimes, I think we were the first to go even lower. We had some impressive results especially in the 64b.
We also did fast-size-coding competitions. We showed a simple effect and then asked people to come up with the smallest way to replicate that within a couple of hours.
Results are all linked on the webpage: https://www.0a000h.de/
Most of them should run in dosbox, unfortunately some make problems.