Mark Russinovich, CTO of Microsoft Azure, has released DoomPaint, a project that runs the original shareware version of Doom using Microsoft Paint as the display. The source code and instructions are available on GitHub in the repository markrussinovich/DoomPaint (Engadget, Tom's Hardware).

DoomPaint runs the real Doom engine and loads the actual shareware Doom1.wad file, not a re-creation or a recorded video. It reaches up to 35 frames per second, which matches the original game's internal tick rate of 35 Hz. Sound and music are included as well (Engadget).

The approach is simple in concept but punishing for the Windows clipboard. Every rendered frame is copied to the clipboard, then pasted into MS Paint's canvas as a genuine document edit. Paint is not acting as a host window or a rendering target for a graphics API. It is receiving frame data through the clipboard and displaying it as a pasted image, frame after frame, at up to 35 fps. The GitHub repository includes setup instructions and a PLAN.md file that outlines the development approach (Engadget, GitHub).

The "Can It Run Doom?" phenomenon has a long history in the technology community, with ports appearing on calculators, ATMs, pregnancy tests, and many other devices never designed for gaming. Gizmodo covered DoomPaint under that banner on August 3 (Gizmodo). Tom's Hardware published its coverage on August 2 under the headline "Microsoft Paint used as a monitor to run Doom at up to 35 fps" (Tom's Hardware). Engadget confirmed the details on August 4 (Engadget).

What sets DoomPaint apart from the usual Doom-on-unusual-platform port is not just the technical difficulty. It is who built it and what it shows about the Windows desktop as a programmable surface. Russinovich holds a role at Microsoft where deep knowledge of Windows internals is a core professional skill. Using the clipboard as the transport layer between a game engine and a bitmap editor is a creative abuse of the Windows messaging and clipboard APIs. Each frame must be converted to a bitmap, placed on the clipboard, and pasted into an open Paint document, all within roughly 28 milliseconds, which is the time budget that 35 fps allows. That this pipeline holds together at the original game's native frame rate is the genuinely hard part.

The PLAN.md document in the repository suggests the project was developed with a structured approach rather than as a throwaway experiment. Russinovich has a long track record, familiar to anyone who has worked in Windows systems administration, of building tools that probe and expose the operating system's internals. DoomPaint operates in a similar spirit, though with a deliberately absurd goal.

For developers interested in the specifics, the GitHub repository at markrussinovich/DoomPaint contains the full source code, the PLAN.md planning document, and setup instructions for running Doom through MS Paint (GitHub).

The broader context here goes beyond the novelty. The Windows desktop environment, for all its surface polish and decades of layered interface frameworks, remains deeply programmable at the messaging level. The clipboard, a mechanism designed in the early 1990s for moving text and images between applications, can be driven fast enough for real-time game rendering when paired with the right glue code. DoomPaint is an extreme case, but it shows that the boundary between applications on Windows is more permeable than the isolated-window model suggests. For security professionals, the fact that an external process can push bitmap data into an open Paint canvas at 35 fps via the clipboard is a reminder that the clipboard remains a shared, unsandboxed inter-process communication channel, meaning any application can read from or write to it without restriction.

DoomPaint does not change how anyone will use MS Paint, and it will not reshape gaming. But it is a precise, working demonstration that the seams between Windows applications are still wide open for anyone willing to look for them.