HN Debrief

Multicore suppport for DOS is real – partly

  • Programming
  • Hardware
  • Operating Systems
  • Retrocomputing

The Vogons post is about a binary found on an old company DVD that starts extra x86 cores while DOS keeps running on the primary core. It is not DOS gaining scheduler, threads, or symmetric multiprocessing support. It is a program taking control of the hardware directly and using the second core as a helper that runs code without the normal DOS environment around it. Commenters converged on that distinction fast. DOS has no native concept of multicore and no built-in threading model, so any useful design has to look like tiny-kernel work inside an application. Shared memory is the obvious bridge. One core keeps handling DOS, BIOS, files, and anything interrupt-heavy. Other cores do compute work, poll ring buffers, and avoid touching services that assume a single CPU world. Several people noted that this is how low-level systems already work on x86 anyway. Bring up each CPU, communicate with shared memory or inter-processor interrupts, and serialize access to code that is not SMP-safe. That made the claim feel less magical and more like a clever proof that old software environments do not fully constrain modern hardware if you are willing to own the runtime yourself. The comments also filled in useful historical nuance. DOS was more structured than the usual joke suggests. It had a process model built around Program Segment Prefixes, parent-child execution, handle tracking, and terminate-and-stay-resident programs, even if it never offered preemptive multitasking or threads. People also pointed to modern demoscene releases that already exploit multiple cores under pure DOS, which makes this less of an isolated curiosity than a niche but established technique.

If you build on bare metal or in unusual legacy environments, multicore can be added below the OS line, but you inherit synchronization, memory sharing, and device access yourself. Treat this as an OS-kernel problem, not an application portability feature, and expect emulators to be a poor test target unless they expose APIC behavior correctly.

Discussion mood

Impressed and amused. Most people treated it as a technically elegant hack rather than true DOS multicore support, and the interest came from how far you can push bare-metal x86 once you stop expecting the OS to help.

Key insights

  1. 01

    Shared memory is the whole programming model

    Using extra cores under DOS means one CPU stays in the familiar single-core world while helper CPUs act like co-processors. The workable pattern is shared ring buffers, spin waiting, optional inter-processor interrupts, and strict rules that only one core touches DOS or BIOS state. That reframes the stunt as an SMP runtime bolted onto a single-tasking OS, not an extension of DOS services.

    If you ever try this on legacy or embedded x86, isolate system calls and device access to one core from day one. Design the rest of the program as message-passing workers with explicit ownership of memory and hardware.

      Attribution:
    • toast0 #1
    • kmeisthax #1
    • PaulHoule #1
  2. 02

    DOS did have a real process model

    Program Segment Prefixes gave DOS more structure than the usual 'single program only' caricature suggests. DOS tracked parent and child execution, file handles, and owned memory blocks, and terminate-and-stay-resident programs kept that process metadata alive after returning control. That matters because multicore hacks are landing in an OS that lacks scheduling, not in a total void.

    Do not confuse 'no multitasking' with 'no process abstraction' when reasoning about old systems. If you are reviving or interfacing with DOS software, PSP-era assumptions still shape memory ownership and program lifecycle.

      Attribution:
    • haileys #1
  3. 03

    The demoscene already proved the technique

    The strongest evidence that this is practical came from recent DOS demos, especially Pits and the 256-byte demo Mariana, both of which advertise multithreading across CPU cores while staying in pure DOS and avoiding DPMI in at least one case. That pushes the story from odd artifact to repeatable craft knowledge in a niche community that still squeezes modern hardware from ancient software targets.

    If you want implementation clues, study demoscene releases instead of waiting for formal documentation. They often contain the sharpest real-world examples of what low-level PC hardware can do outside mainstream operating systems.

      Attribution:
    • fao_ #1
    • HellMood #1

Against the grain

  1. 01

    Calling this DOS support is overstating it

    The cleaner framing is that DOS neither enables nor blocks the trick. Once you can wake secondary CPUs through the APIC, you can run code on them regardless of whether the host environment understands multiprocessing. From that angle, the headline risks crediting DOS for something the application and hardware are doing underneath it.

    Be precise when you describe low-level capability. Distinguish OS support from 'possible despite the OS' so engineers do not infer portability or safety that is not really there.

      Attribution:
    • userbinator #1

In plain english

APIC ↩
Advanced Programmable Interrupt Controller, the x86 hardware used to route interrupts and start or signal other CPU cores.
BIOS ↩
Basic Input/Output System, the low-level firmware that initializes a PC and exposes hardware settings before the operating system starts.
DoS ↩
Denial of service, an attack or overload that makes a system hard to use, used here metaphorically for overwhelming human reviewers.
DPMI ↩
DOS Protected Mode Interface, a standard that let DOS programs use protected mode features like more memory while still running under DOS.
SMP ↩
Symmetric Multiprocessing, the ability of an operating system to use multiple CPU cores or processors effectively.
x86 ↩
A major family of processor architectures used in most desktop and server CPUs.

Reference links

Demos and scene references

Source mirrors and code

Historical background