The linked post examines a mysterious binary found on a company DVD that can boot DOS on one core and run custom code on another. That sounds bigger than it is. Nobody thinks MS-DOS secretly had a symmetric multiprocessing design waiting to be rediscovered. The practical takeaway is that x86 lets you wake secondary cores through hardware facilities like the APIC, and a DOS program can use that if it stays close enough to the metal.
If you control the whole machine, old single-user software stacks can still exploit modern hardware, but you are effectively writing kernel code and taking full responsibility for coordination, safety, and I/O boundaries.
Curious and impressed, with a strong insistence on precision. People liked the hack, but most pushed back on calling it "DOS multicore support" because DOS provides almost none of the machinery that phrase implies.
01 The workable model is simple and brutal.
Keep DOS on core 0, run custom code on another core, and communicate through shared memory with ring buffers and homemade synchronization. That only works cleanly if secondary cores never call DOS or BIOS services directly. The comparison to early Linux's giant kernel lock is useful here. You could serialize all DOS access behind one lock, but then your multicore story collapses into a narrow offload model rather than general parallel execution.
You can get parallelism under DOS, but only by treating DOS as a single-threaded service boundary. The second core is an accelerator, not a peer in an OS-managed runtime.
02 DOS had more process structure than the casual "no processes" claim suggests.
PSPs tracked per-program state, DOS could spawn child programs and wait for them, and memory blocks and file handles were tied back to the owning program. Terminate-and-stay-resident kept that state alive after exit, and early Windows reused the same PSP model for task management. That does not make DOS multicore-capable, but it does change the picture from "nothing there" to "single-tasking process model with real ownership semantics."
DOS was primitive, not structureless. It had process bookkeeping, just nothing close to kernel-managed threading or multiprocessing.
03 The demoscene has already turned this from theory into shipped software.
"Pits" and the 256-byte demo "Mariana" both advertise multicore use under pure DOS, Full HD output, and no drivers or DPMI. That is a stronger proof point than the mystery binary because it shows repeatable techniques in tiny, performance-obsessed codebases where every assumption gets stress-tested.
If you want evidence that multicore DOS code is practical, look at modern demoscene releases. They prove the hardware path is real and usable by expert programmers.
01 Calling this "support" smuggles in too much credit for DOS itself.
The hard part is waking secondary cores through the APIC, and that can be done from a very low-level environment regardless of whether DOS is present. Once DPMI or protected mode enters the picture, the more accurate description is that you are standing on OS-like machinery outside classic DOS rather than extending DOS on its own terms.
The headline oversells DOS's role. The real enabler is x86 hardware control, not an overlooked DOS capability.
02 There is a historical argument that Microsoft already learned how ugly this problem gets.
A commenter pointed to the abandoned multitasking MS-DOS 4.x effort as a reminder that bolting real task management onto DOS was not a small extension. Even if the current hack works, that history suggests why DOS never evolved into a general multiprocessing environment.
Making DOS truly multitasking was hard enough to fail commercially. That is a clue about the ceiling of these hacks.