Microsoft Word 1.1 - Excavating 35 Years of Source Code
â—† Revised
Introduction
Microsoft Word is so familiar today that it is easy to regard it as simply another application installed on a modern computer. Look backwards through its history, however, and Word becomes something rather more interesting: a record of changing assumptions about computers, operating systems, memory, displays, printers and the way humans interact with software.
The first Microsoft Word appeared for DOS in 1983, descended from Microsoft's earlier Multi-Tool Word work and influenced by the graphical word-processing ideas Charles Simonyi had encountered at Xerox PARC. It arrived in a computing environment dominated by character displays, floppy disks, limited memory and keyboard-driven applications. Word nevertheless supported such comparatively ambitious ideas as style sheets, multiple windows, undo, proportional fonts and mouse input.
The more important architectural transition came later. Microsoft Word for Windows appeared in 1989, moving the application into Microsoft's graphical Windows environment. Word for Windows 1.1a followed in 1990. This is the branch of the Word family that is particularly interesting from a software-engineering perspective because its source code survived and, with Microsoft's permission, was released by the Computer History Museum in 2014 for historical and technical study.
The archive is not a reconstructed approximation of Word. It contains the historical source tree: 1,021 files arranged across 33 directories, including C source, x86 assembly language, build utilities, batch files and documentation. It provides an unusually complete opportunity to inspect how a substantial commercial Windows application was actually engineered at the beginning of the 1990s.
Then, in 2026, developer Justin Marshall — JMarshall23 — did something particularly useful with this archaeological material. Rather than merely getting the old executable to operate inside an emulator, he began adapting the historical source into a native Windows x64 application, replacing dependencies on 16-bit assembly, segmented memory and Win16 platform boundaries with modern equivalents.
That changes the nature of this article.
We are no longer simply looking at an old word processor. We can examine an evolving software system at several points in its lifecycle: its DOS ancestry, its transition to Windows, its preserved source code and, more than three decades later, an attempt to transplant that architecture onto a modern 64-bit Windows platform.
This is software archaeology with a working specimen.
Microsoft Word as a System
The original Microsoft Word for DOS was released in October 1983. From a modern perspective, the temptation is to judge it by its user interface. From a systems perspective, however, the more interesting question is what the program was being asked to achieve within the constraints of an early IBM-compatible PC.
A word processor is not merely a text editor. It must maintain an internal representation of a document, accept and interpret user commands, continually modify that representation, calculate formatting, manage files, communicate with printers and provide the user with some representation of the eventual printed result.
Doing all of this on machines measured in hundreds of kilobytes rather than gigabytes makes the engineering rather more visible.
Microsoft Word's early design incorporated features including style sheets, multiple document windows, footnotes, mail merge, undo and support for proportional fonts. Its developers also concentrated heavily on interactive display performance. The Computer History Museum's history of the source code records that Word reformatted the display as characters were entered — an important part of Microsoft's attempt to bring WYSIWYG-style document editing to ordinary personal computers.
The mouse is another revealing architectural clue. Word was developed at a time when mouse control was far from an assumed component of PC software. Supporting it meant that Word's designers were already treating the document as something the user could navigate spatially rather than simply as a stream of characters manipulated through keyboard commands.
Some of those ideas initially worked against Microsoft. WordPerfect remained the dominant DOS word processor, and early reviewers sometimes found Microsoft's approach unfamiliar. The Computer History Museum notes that a 1984 BYTE review praised Word's technical abilities while finding it frustrating to learn. In effect, Microsoft was introducing interaction conventions before much of its intended market had become accustomed to them.
The architecture makes considerably more sense when viewed as the beginning of a longer transition.
Microsoft Word for Windows arrived in late 1989. Instead of Word having to create much of its own interaction environment on top of DOS, Windows supplied an increasingly standard graphical platform: windows, menus, messages, fonts, device abstractions and graphical output.
Word was becoming part of an operating-system ecosystem.
That distinction matters when examining Word 1.x today. Word for DOS 1.1 and Word for Windows 1.1a are related historically, but they are not the same software product. The DOS material below illustrates where Microsoft's word processor began; the Windows 1.1a source tree shows where that architecture was heading.
Word 1.1 for DOS — Incremental Engineering
The Word 1.1 update for DOS is interesting precisely because many of its changes appear mundane.
Rather than representing a revolutionary redesign, the update shows a maturing application being adapted to the practical requirements of its installed environment.
The Merge facility expanded Word's usefulness for repetitive business correspondence. Printer support was broadened and the printer-driver format enhanced. Hercules Graphics Card support improved high-resolution monochrome operation. Running heads became easier to create, while page and division information was added to the status display.
There were also performance improvements to operations such as Transfer Save and Print Repaginate.
Seen as release notes, these are merely features. Seen from a systems-engineering perspective, they reveal the boundaries surrounding the application.
Word depended upon display hardware, printer capabilities, storage performance, available memory, input devices and the behaviour of DOS itself. The application could not assume that two users possessed equivalent computer systems.
Consequently, part of the Word architecture existed to isolate the application from this variability.
Printer description files are an especially good example. Rather than hard-coding every supported printer into the principal application, Word used .PRD files to describe output devices. That is recognisably the same engineering problem addressed today through device drivers, abstraction layers and interface contracts: separate the application's logical requirement — print this document — from the peculiarities of the hardware responsible for producing it.
Collector's Market
Original Microsoft Word for Windows 1.1 software and related material can still be found on the collectors' market, with individual items typically ranging from around $30 to several hundred dollars depending on condition, rarity and completeness. A loose disk, manual or upgrade component can be an inexpensive way to fill a gap in a collection, while complete boxed editions containing the original disks, documentation, inserts and packaging command considerably higher prices. For collectors, the attraction is therefore not necessarily finding the most expensive example, but identifying exactly what is missing from a collection and finding the right surviving piece to complete it.
What the Files Tell Us
The file structure of Word for DOS provides a surprisingly useful architectural diagram.
The application included WORD.COM as its startup program and MW.PGM as a principal program file. MW.HLP provided help information, while mouse support was supplied through files such as MOUSE.SYS, MOUSE.COM and MOUSE.LIB.
Printer behaviour was externalised through .PRD printer-description files, accompanied by CONVPRD.COM for working with those descriptions.
Word also generated operational data of its own. Backup copies used the .BAK extension, temporary editing information was written to .TMP files, and MW.INI retained user configuration for options including printing and window behaviour.
That is a small software ecosystem rather than a single executable.
Even the familiar .DOC extension becomes more interesting in this context. Word documents existed alongside .STY style sheets, .GLY glossary files and .BAK backups. The user's document was therefore only one object within a wider collection of persistent application state.
Storage constraints were also part of normal operation. A user working from floppy disks needed to understand which disk contained the program and which contained their documents. File names were constrained by DOS's eight-character name plus three-character extension convention.
These limitations may look primitive today, but they encouraged explicit separation of concerns. Program, configuration, document, style, backup and device information were recognisably different artefacts.
For software archaeology, these files are valuable because they reveal the operational architecture from the outside. We can infer something about the responsibilities of the system before reading a single line of its source code.
Surviving Executables: Word as an Artefact
Software preservation has an unusual problem that preservation of physical machines does not.
A computer can be placed in a museum and inspected even if it no longer operates. Software is more elusive. An executable without its required operating system, hardware assumptions, documentation and data formats can become effectively inert.
Fortunately, several early Word artefacts survive.
One is the pre-release Microsoft Word for DOS Beta Test Version X1.06, dated September 1983. It predates the official October 1983 release and appears to have been intended for evaluation or review. Internal information in MW.DAT identifies it as Beta Test Version X1.06.
Another is the Microsoft Word 1.00 demonstration disk distributed with PC World in 1983. Designed for an IBM PC running DOS with at least 128 KB of RAM, the demonstration version restricts functionality — including the ability to save documents — but provides a runnable representation of the early user experience.
These preserved binaries let us examine Word behaviourally.
The later preservation of the Word for Windows 1.1a source code gives us something considerably more powerful.
We can examine it structurally.
Opening the Source Code
In March 2014, Microsoft permitted the Computer History Museum to publish the source code of Microsoft Word for Windows 1.1a for non-commercial historical and technical study.
The preserved snapshot dates from January 1991. Its approximately 7 MB archive contains 1,021 files in 33 directories. Most of the application is written in C, accompanied by x86 assembly source, executable development tools, batch files and other supporting material.
Seven megabytes sounds almost comically small beside a modern development repository, but that comparison can be misleading. The significance of the archive is not its size. It is the density of assumptions embedded within it.
The code was written for a particular processor architecture, compiler environment, memory model and generation of Windows APIs.
A 16-bit Windows program lived in a world of segmented memory. Addresses, pointers and data structures were shaped by distinctions such as near and far memory. Assembly-language routines could exploit characteristics of the x86 processors of the period. Application code interacted with Win16 interfaces whose types and behaviours reflected the same environment.
These are not superficial dependencies that can necessarily be solved by changing a compiler target from 16 to 64 bits.
They are architectural assumptions.
This is where the source archive becomes particularly valuable to a systems engineer. The code is effectively a preserved model of the contract between an application and its 1990 execution environment.
And contracts can be analysed.
Justin Marshall's x64 Port — Software Archaeology Becomes Engineering
In August 2026, developer Justin Marshall (JMarshall23) demonstrated the next logical step: taking the preserved Word for Windows 1.1a source and making it operate as a native x64 Windows application.
This is an important distinction.
Running the original Word inside an emulator or virtual machine preserves the old application by recreating the environment it expects.
Marshall's project attacks the problem from the opposite direction.
Keep the application, change its assumptions about the environment.
His port retains the original Word source and resources while providing modern replacements for three particularly significant classes of historical dependency: 16-bit assembly routines, segmented-memory mechanisms and Win16 platform boundaries. The resulting program runs as native x64 Windows software rather than as the original binary hidden inside an emulated historical machine.
From a systems-engineering viewpoint, this is fascinating because it amounts to discovering the interfaces between the enduring application logic and the obsolete platform implementation.
Conceptually, the exercise looks something like this:
Historical Word logic → compatibility/replacement layer → modern Windows x64
Every successful replacement tells us something about the original architecture.
If an assembly routine can be replaced while the higher-level application continues to behave correctly, we have identified an implementation dependency rather than an essential application behaviour.
If segmented-memory handling can be removed or translated, we have separated a constraint imposed by the original execution platform from Word's underlying document-processing logic.
If a Win16 boundary can be replaced by a modern implementation without rewriting the whole application, we have effectively excavated an old interface contract and supplied it with a new endpoint.
That is why I find the project more interesting than simply seeing a 1990 application appear on a Windows 11 desktop.
It is an experiment in architectural survivability.
The build process reinforces this. There is no convenient modern installer containing a redistributed copy of Word. Users obtain the permitted historical source separately and build the port using a modern development environment including Visual Studio 2022, the Windows SDK, CMake and PowerShell. The restrictions are important because Microsoft's historical source remains copyrighted and was released through the Computer History Museum under terms permitting non-commercial use rather than unrestricted redistribution.
What Survived 35 Years?
Marshall's project raises a useful systems question:
How much of a software system is actually the software?
The processor changed from 16-bit x86 to x64. The memory model changed. The operating-system interfaces changed. Development tools changed. Display hardware changed beyond recognition. Storage capacities increased by orders of magnitude.
Yet enough of Word's application architecture survives that it can be made to operate again once obsolete dependencies are identified and substituted.
That suggests a distinction worth making when studying legacy systems.
Some parts of software encode business or application logic: what a paragraph is, what an editing operation does, how a document is represented, how commands alter state.
Other parts encode environmental assumptions: how memory is addressed, how a window is created, how an assembly routine communicates with the processor, or how an operating system exposes a service.
The passage of 35 years destroys the second category much faster than the first.
Marshall's port therefore provides an unusually tangible demonstration of technological obsolescence across decades. The original developers were not necessarily making poor engineering decisions when they relied upon segmented memory or Win16. They were designing correctly for the system that existed.
The debt appeared because the surrounding system disappeared.
This is an important lesson in software archaeology. Old code should not immediately be judged against modern conventions. First identify the constraints under which it was designed.
Only then does its architecture make sense.
Conclusion
Microsoft Word 1.x is more interesting today than when I first wrote this article in 2024.
Originally, I approached it primarily as an artefact of early personal computing: old manuals, floppy-disk images, unfamiliar file structures and an application that helped establish conventions we now take for granted.
The surviving source code and Justin Marshall's x64 port permit a different examination.
We can now follow the system across several technological strata.
The 1983 DOS versions show Microsoft constructing an unusually interactive word processor within the severe constraints of the early IBM PC. Word for Windows shows that application moving into a graphical operating-system architecture. The Computer History Museum's preserved 1.1a source allows us to inspect the engineering beneath that transition. Marshall's 2026 project then asks which parts of that engineering can survive when the original execution environment is removed.
The answer appears to be: surprisingly much.
That makes source-code preservation more than an exercise in nostalgia.
A binary preserves what a program did.
Documentation preserves how people were expected to use it.
Source code preserves how its designers thought the system should work.
And a successful port tests whether our interpretation of that design is correct.
For me, that is the most interesting aspect of Microsoft Word for Windows 1.1a. We have gone from possessing a software fossil to being able to perform experimental archaeology upon it.
Thirty-five years after the code was written, change the processor model, replace the obsolete interfaces, rebuild the machinery — and Word begins running again.
The artefact becomes a system once more.
Featured Product
Analogue Computer Series 001 T-Shirt
If digging through the architecture of Microsoft Word 1.1 reminds you that great technology deserves to be understood, preserved and occasionally brought back to life, the Analogue Computer Series 001 T-shirt celebrates that same engineering curiosity. It is for people who enjoy looking beneath the interface, exploring how earlier systems actually worked, and keeping the ideas of computing history alive rather than allowing them to disappear into the digital dark age.
Disclosure: this is a commercial product link to an external Zazzle store associated with philreichert.org. Purchases are handled by Zazzle.
Writer's Notes
What I find exceptional about this story is not simply that Microsoft Word 1.1 still exists. Plenty of old software survives as disk images, screenshots, manuals or binaries sitting quietly in an archive. What matters here is that people went further. They dug through Microsoft's historical material, worked through the legal terms surrounding the source release, and helped unlock a genuine piece of commercial software history so that historians, programmers and retrocomputing enthusiasts could study it properly.
That is an important distinction. Preserving an executable lets us see what the software did. Preserving the source code lets us examine how it was engineered, what assumptions its developers made, where the boundaries of the system sat, and how a substantial commercial application was structured for the hardware and operating systems of its day.
Then another generation of enthusiasts took that preserved source and started reworking it for modern hardware. That is the part I find especially satisfying. The code has not merely been placed behind glass. It has been examined, interpreted and made to live again in an environment its original developers could never have anticipated.
Is anyone seriously going to use Microsoft Word 1.1 for their day-to-day work in 2026? No. Of course not. That is not really the point.
The value is in preserving the experience and the technology. We can still see how the program behaves, study the engineering decisions behind it, understand the constraints under which it was built, and now even observe what has to change when software designed for a very different computing world is transplanted onto modern systems.
This is exactly why digital preservation matters to me. The digital dark age does not arrive because every old computer suddenly disappears. It arrives when the software, documentation, source code and technical context needed to understand those machines quietly become inaccessible.
In this case, that chain has been interrupted. The artefact was preserved, the source was opened for study, and enthusiasts have carried the engineering forward. Nobody needs to write their next report in Word 1.1 for the exercise to be worthwhile. The achievement is that we can still inspect it, learn from it and understand how this part of our computing heritage actually worked.
Reader Guide
The following material expands on the terminology, historical context, technical concepts, and related reading connected to this article.
Glossary
Some of the terms used in this article have specialised, historical or technical meanings. This glossary provides additional context for selected terms and ideas.
- WYSIWYG
- Abbreviation of "what you see is what you get": an interaction model where the on‑screen layout closely matches the printed output. Early word processors that attempted WYSIWYG needed proportional fonts, reflowing display logic and printer-aware formatting, which was technically ambitious on 1980s PCs with limited memory, character displays and primitive printer interfaces.
- Segmented memory
- A 16‑bit x86 memory model that divides addressable memory into named segments (code, data, stack) accessed via segment:offset pairs rather than a single flat address. It let early PCs address more than 64 KB in a constrained CPU mode but forced programmers to manage near/far pointers and segment arithmetic, creating application-level dependencies that are awkward to translate to modern flat 64‑bit address spaces.
- Win16
- The original 16‑bit Windows platform and API set used by early Windows applications, characterised by 16‑bit pointers, a particular message/event model and OS services designed for that era. Software compiled against Win16 relied on platform semantics and conventions that are not directly compatible with later 32‑/64‑bit Windows, so preserving or replacing Win16 boundaries is a central challenge when porting vintage Windows programs.
- x86 assembly
- Low‑level machine code written in the assembly language of Intel x86 processors, used for performance‑critical or hardware‑specific routines. Such assembly can exploit processor instructions and calling conventions unavailable in high‑level languages; when those routines are 16‑bit and tightly coupled to old CPU behaviour they must be reimplemented or emulated to run on modern x64 systems.
- Hercules Graphics Card
- An early PC graphics adapter that provided a high‑resolution monochrome display mode beyond the standard text modes of the time, commonly used to show finer detail in text and simple graphics. Software enabled for Hercules support could present denser, sharper output on monochrome monitors, so adding or improving support for it was a meaningful enhancement for users who wanted higher‑quality on‑screen rendering.
Frequently asked questions
Curious about something you’ve just read? These frequently asked questions explore some of the key ideas, details and questions surrounding the topic.
What advanced features did early Microsoft Word include for 1980s PCs?
Early Microsoft Word supported features uncommon on early IBM-compatible PCs such as style sheets, multiple document windows, footnotes, mail merge, undo, proportional fonts and mouse input, and it reformatted the display as characters were entered to approximate a WYSIWYG editing experience.
What is contained in the Word for Windows 1.1a source archive released for study?
The preserved snapshot dates from January 1991 and is roughly 7 MB containing 1,021 files across 33 directories, mostly C source with x86 assembly, build utilities, batch files and documentation, reflecting assumptions of a 16-bit Windows environment such as segmented memory and specific Win16 APIs.
What did Justin Marshall's x64 port accomplish and how was it done?
Marshall adapted the original Word for Windows 1.1a source to run natively on x64 Windows by replacing historical dependencies—notably 16-bit assembly routines, segmented-memory mechanisms and Win16 platform boundaries—while retaining the original source and resources and requiring users to build the port with modern tools like Visual Studio 2022, the Windows SDK, CMake and PowerShell.
What does the successful x64 port reveal about legacy software and technical debt?
The port demonstrates that much of an application's core logic can survive when environmental assumptions are substituted, showing a distinction between enduring application behavior and fragile platform-specific dependencies, and illustrating how technical debt accumulates when an execution environment disappears even if original engineering was appropriate for its time.
Related articles…
References
- Justin Marshall's Microsoft Word for Windows 1.1a, GitHub
- Microsoft Word for Windows 1.1a Source Code, Computer History Museum
Disclosure
This article is an independent historical and technical commentary and is not affiliated with or endorsed by Microsoft, the Computer History Museum, Justin Marshall or the Word for Windows 1.1a port project. Microsoft Word and related trademarks remain the property of their respective owners.