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

DoomPaint runs the actual Doom engine and loads the real shareware Doom1.wad, not a re-implementation or a video capture. It can reach up to 35 frames per second, matching the original game's tick rate of 35 Hz. The release includes sound and music as well (Engadget).

The mechanism is straightforward in concept and punishing in its implications for the clipboard. Every rendered frame is placed on the Windows clipboard, then pasted into MS Paint's canvas as a genuine document edit. The result is that MS Paint is not being used as a wrapper, a host window, or a rendering API target. 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 resources and instructions for getting the game running, along with a PLAN.md planning document that outlines the project's approach (Engadget, GitHub).

The "Can It Run Doom?" phenomenon has a long and varied history in the technology community, spanning ports to calculators, ATMs, pregnancy tests, and myriad other devices never intended for gaming. Gizmodo covered DoomPaint under exactly 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 typical Doom-on-unusual-platform port is not the technical difficulty alone. It is who built it and what it illustrates about the Windows desktop as a programmable surface. Russinovich occupies a role at Microsoft where deep systems-level understanding of Windows internals is a core professional asset. The choice to use the clipboard as the transport layer between a game engine and a bitmap editor is an exercise in creative abuse of the Windows messaging and clipboard APIs. Each frame must be serialized to a bitmap, placed on the clipboard, and pasted into an open Paint document as a document edit, all within the roughly 28-millisecond window that 35 fps allows. The fact that this pipeline holds together at the original game's native frame rate is the non-trivial 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 track record, well known to anyone who has worked in Windows systems administration, of building tools that probe and expose the internals of the operating system. DoomPaint operates in a similar spirit, though with a deliberately absurd objective.

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

There is a broader point worth flagging here that goes beyond the novelty. The Windows desktop environment, for all its surface-level polish and decades of layered UI 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 at a rate sufficient for real-time game rendering when paired with the right glue code. DoomPaint is an extreme case, but it illustrates 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.

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.