Microsoft Word 1.1a gets a native x64 port

A GitHub repository called msword provides a native Windows x64 port of Microsoft Word for Windows 1.1a, whose historical codename was Opus. The project builds the original Word source and resources together with modern replacements for the 16-bit assembly, segmented-memory, and Win16 platform boundaries that the original relied on. The result, per the project, is the original Word application and user experience running as a genuine 64-bit Windows executable: not an emulator, and not a reimplementation built on a modern editor control.
The port keeps the original C and resource files as the authoritative implementation and adds only the platform work needed to build and run that code safely on 64-bit Windows. Concretely, the original 16-bit x86 assembly entry points are translated to fixed-width C or C++, the segmented and double-indirect memory handles used by 16-bit Windows are mapped onto an x64-safe native runtime, and Win16-specific startup, messaging, graphics, file, and resource behavior is adapted to current Win32 APIs. The legacy assembly tree is still inventoried by the CMake build so it stays available as a historical reference, but none of it is compiled into the native targets; everything that ships is valid AMD64 code.
Building it requires 64-bit Windows, Visual Studio 2022 with the Desktop development with C++ workload, a Windows 10 or 11 SDK, CMake 3.25 or newer, and PowerShell. The documented path is to clone the repository, configure one of the included CMake presets (x64-debug or the optimized x64-release), build it, and run the resulting WORD1.exe; the generated solution can also be opened directly in Visual Studio 2022, using WORD1 as the startup project. A dedicated ctest suite, run from the repository root or from the src directory, covers the ported x64 runtime, the original Word data structures and command tables, process startup, and automated UI workflows including typing, selection, formatting, dialogs, and saving.
The README flags a licensing gap: the historical source files retain their original Microsoft and third-party copyright notices, and the repository does not currently include a top-level license file, so it tells anyone reusing the code to review applicable rights before redistributing the source or the binaries. The text gives no name or team behind the port, no date for when it was built or released, and makes no claim that it is feature-complete or production-ready beyond what the test suite covers.
Key facts
- The project builds the original Word for Windows 1.1a source and resources together with modern replacements for the 16-bit assembly, segmented-memory, and Win16 platform boundaries, producing the original application as a real 64-bit Windows executable rather than an emulator or a reimplementation on a modern editor control.
- Building it requires 64-bit Windows, Visual Studio 2022 with the Desktop development with C++ workload, a Windows 10 or 11 SDK, CMake 3.25 or newer, and PowerShell; the repository ships x64-debug and x64-release CMake presets.
- An automated ctest suite covers the ported x64 runtime, the original Word data structures and command tables, process startup, and UI workflows including typing, selection, formatting, dialogs, and saving.
- CMake still inventories the legacy 16-bit assembly tree but does not compile any of it into native targets, keeping the historical implementation as reference while ensuring every shipped binary is valid AMD64 code.
- The historical source keeps its original Microsoft and third-party copyright notices, and the repository currently has no top-level license file, so the README tells users to review applicable rights before redistributing source or binaries.
Why it matters
Most retro-software projects either emulate the original binary or rewrite the application from scratch on a modern toolkit. This one instead takes Word for Windows 1.1a's own C and resource files and carries them across the platform boundary that broke them: 16-bit x86 assembly entry points, segmented and double-indirect memory handles, and Win16 startup and messaging behavior are each translated or mapped onto x64-safe equivalents, while the original code and algorithms stay in place. That makes the repository a rare working, buildable reference for how an early Windows word processor was actually built internally, not just how it looked or behaved.
Who it affects
The audience is developers interested in software preservation and Windows internals: people who want to study or build early Word's actual source, and engineers curious about the concrete mechanics of moving 16-bit segmented-memory Windows code onto a native 64-bit runtime without emulation.
How to use it
Clone the msword repository, then from a PowerShell prompt in its src directory configure one of the included CMake presets, x64-debug or the optimized x64-release, and build it; the resulting WORD1.exe in the bin folder is the ported application. The generated solution can also be opened directly in Visual Studio 2022 with WORD1 as the startup project, and a specific target can be built with cmake --build --preset x64-debug --target WORD1. The full test suite runs via ctest from the repository root or the src directory, substituting Release for Debug for a release build.
How solid is it
The port is backed by a dedicated automated test suite that exercises the ported x64 runtime, the original Word data structures and command tables, process startup, and UI workflows such as typing, selection, formatting, dialogs, and saving. The project keeps the original C and resource files as the authoritative implementation and limits new code to the platform-boundary translation work; the legacy 16-bit assembly is still inventoried by CMake for reference even though it is no longer compiled. Beyond what the tests cover, the source makes no explicit claim about feature completeness or production readiness.
Risks and caveats
The repository does not currently include a top-level license file, while the historical source files still carry their original Microsoft and third-party copyright notices; the README itself says to review applicable rights before redistributing the source or binaries. The text also does not say who built the port, when it was started or released, or why Opus was Word for Windows 1.1a's historical codename.
“The result is the original Word application and user experience running as a 64-bit Windows executable. This is not an emulator or a reimplementation using a modern editor control.”
— project README, msword (GitHub)