Collecting Opus
Opus is the codename given by Microsoft developers to Microsoft Word for Windows v1.1a. Let's compile it from source and see if we can run it!
1. Introduction
This article documents the process of getting the source code and turning it into a working Windows application. The compiler and development tools run on the MS-DOS operating system because in 1989 there were no development tools that would work on Windows.
Note: I will be referring to DOS frequently throughout this article. This designation refers to Microsoft MS-DOS, although most of the information also applies to IBM PC-DOS and most other flavors of DOS.
If you are new to using the DOS operating system, I recommend repeating my steps in a copy of Microsoft MS-DOS v6.22, the June 1994 version of DOS (the latest released version), which contains all the tools we need (I'll discuss the only exception below).
2. Background
The development of a word processor called Microsoft Word for DOS was started by Richard Brodie and others in 1982. Richard was hired from Xerox Parc because he was familiar with the then-futuristic Bravo word processor.
Word for DOS was first released in 1983 and bundled with one of the earliest versions of MS-DOS. It used graphics (primitive) and supported mouse operation, but the program itself received conflicting reviews.
Word v2.0 for DOS was released in 1985, it supported EGA graphics and had a spell checker.
Word v3.0 for DOS was released in 1986 and supported Hercules graphics and extended printer set.
Word v4.0 for DOS was released in 1987, it supported VGA graphics and had both text and graphics modes.
Word v5.0 for DOS and OS / 2 became a 16-bit application.
The 1989 update to Word v5.5 introduced Windows / Mac-style windows and menus and was the predecessor to Word for Windows, which was released the same year.
Development of the first WYSIWYG * text processor for Microsoft Windows was completed around 1988-1989, and this version is now available on the Computer History Museum (CHM) website.
* WYSIWYG = What You See Is What You Get
Read more about history and download the source code from the Museum of Computer History here:
https://computerhistory.org/blog/microsoft-word-for-windows-1-1a-source-code/
3. Can I compile this code?
Yes! But how? You can use a vintage PC or a relatively modern computer that can boot into legacy BIOS mode, or you can configure a hypervisor to run a virtual PC. All the necessary tools are in the source code dump from the link above. They all work in DOS, so let's figure out how this should work.
For the demonstration, I'll be using VMware Fusion on a Mac, but you can use any suitable legacy hardware or hypervisor that can run MS-DOS. After installing DOS, you need to check how much free memory you have. For this
it is necessary to understand in general terms how DOS "sees" the hardware. Since the compiler seems to require expanded memory, I will explain how this type of memory is accessed and how to configure DOS to make this memory available to the compiler.
In addition, the set of files is quite large (for a DOS application), so I recommend making your life easier by creating a CD-ROM image with the source files so that they can be copied to a DOS machine at once. However, device drivers are also required for the CD-ROM to work in DOS, so I'll cover that below as well.
The source code is interesting in that the proprietary compiler requires a computer with a processor of at least 386 and 4 MB of RAM. This surpasses the characteristics of many PCs of the time and would definitely be considered "high end", because then most computers had a maximum of 1 MB of RAM and only 640 KB of that were available for typical DOS applications. DOS itself occupies a decent amount of this volume, and applications use what is left. So how much memory does our car have? How to add more memory to her? More on this below.
4. History of Intel processors
The reason DOS requires memory management is closely related to the history of the processor that the OS was supposed to run on. Since many of the early programs were written in assembly language, the DOS operating system was very tightly integrated with the processor on which it ran. As a result, it inherited the limitations of these processors, and they imposed strange requirements, because each new generation of processors had to support the code base of all previous ones.
In 1979, 8-bit Intel 8086/8088 processors could address 1,024 KB, or 1 MB of RAM (8-bit data bus, 16-bit memory registers).
In 1982, a 16-bit Intel 80286 processor could address up to 16 MB of RAM (16-bit data bus, 24-bit address space *).
In 1985, 32-bit Intel 80386 (and later 486) could (theoretically) address up to 4096 MB, or 4 GB of RAM **
Modern 64-bit processors have 40-bit, 52-bit, and 64-bit addressable memory architectures. so they can support 1TB to 4PB of RAM!
Note *: A 24-bit address space is equivalent to 2 to the power of 24 × 1 byte = 16,777,216 bytes, or 16 MB.
Note **: 32-bit address space is 2 to the power of 32 x 1 byte = 4 294 967 296 bytes, or 4 GB, but in PCs with 386 processors, due to the limitations of motherboards and the huge cost of RAM at that time, it was usually set much less than 1 GB.
The history of DOS and Windows is replete with problems created by backward compatibility and memory management limitations that were influenced by the architecture of Intel's early processors.
5. DOS memory types
There are five areas of memory that are addressed by the DOS operating system. Each of these are addressed using one or two device drivers called in CONFIG.SYS at boot time. HIMEM.SYS provides access to Extended Memory, while EMM386.EXE provides access to Expanded Memory. Here is a brief description of these types of memory.
Conventional Memory : 0 to 640 KB (or 651,264 bytes) memory, also called Lower Memory Area (LMA)
Upper Memory Area : UMA is 640 KB to 1024 KB (1 MB) memory also called Upper Memory Blocks (UMB)
Extended Memory Specification : XMS are memory addresses from 1MB to 64MB, but this specification also describes UMA because DOS does not have access to UMA without support from HIMEM.SYS
Expanded Memory Specification : EMS uses the 64 KB page frame defined in Upper Memory to provide access to memory above 1 MB. DOS can use both XMS and EMS when the AUTO parameter is specified, or disable it if EMM386.EXE is loaded with the NOEMS parameter. EMM386 and other memory managers emulate expanded memory in the extended memory area - everything is completely clear and not a bit confusing!
High Memory Area : The HMA is 64 KB just above 1 MB that DOS can load itself into at boot time by using the DOS = HIGH parameter of the CONFIG.SYS file.
Conventional memory contains old-school DOS applications. They can only use 0-640KB of memory, and since DOS itself takes up some of that space, they can access less than 500KB of RAM at runtime. This often limits applications that run in so-called "real mode", in other words, 16-bit applications that are limited to conventional memory. Real mode is called this because the addressable memory application maps to real memory addresses.
This was only quite normal for a few years, and later 640KB became the limiting factor for more complex applications, i.e. games! More memory was required for newer Windows applications, so the Extended Memory Specification (XMS) was introduced. Memory above 1 MB became addressable by 16-bit programs. This specification appeared in 286 processors, which implemented protected mode to access memory above these DOS limits, but also supported access to main memory in real mode, switching between modes as needed.
6. Installing DOS
We can use real floppy disks and USB floppy drives, create floppy images from physical floppy disks, or download floppy images from sites like WinWorld.
A physical or virtual machine must have a minimum of 4 MB and a maximum of 32 MB of RAM, and a hard drive of no more than 512 MB with a single FAT16 partition. If the hard drive is physically larger than 512 MB, limit the first partition to the maximum size that your version of DOS can address. For compatibility reasons, limit this first partition to 512 MB or less.
If the machine has the minimum specifications described above, boot from the first DOS diskette. In versions higher than 5.0, the installer will start. Follow its instructions and select all defaults for now. In the next article, we will experiment with the installation options. If you have not seen the dialog with the installation proposal, then on the first floppy disk you can often find the INSTALL.EXE file or configure everything yourself by partitioning the hard disk manually. See the Making the Hard Drive Bootable section below.
7. Making the hard drive bootable
If in the previous step you booted from a floppy disk, but you do not yet have an accessible hard disk or the DOS copy does not contain an installer, then you can install it manually.
Run FDISK from the floppy disk and view the existing partition structure by selecting item 4 and pressing Enter.
If the partition exists, then it should be written that the FAT16 file system has up to 511 MB, and the status column should indicate that the partition is active (the symbol "A" in the Status column).
If this is not the case, then create a section; return to the main menu by pressing Escape.
Select item 1 and press Enter. Type 1 and press Enter again to create a new Primary Partition. The program will complain that it already has an existing section. If you are brave enough, you can delete it and create a new one, or just use the existing one.
After that go back to the main menu, select item 2 and make the new partition active, and then exit FDISK. On the DOS prompt, we need to format the disk to make this new partition readable, and we also brought the DOS boot system to disk with the "/ s" switch of the
formatcommand command. The "/ v" switch will ask for the name of the new volume.
format c: /s /vFollow the prompts and give the volume a valid 11 character name. This will create a boot disk, but create a DOS folder before rebooting
md C:\DOS... and then copy all files from the floppy disk to C: \ DOS ...
copy A:. C:\DOS\.Create standard CONFIG.SYS and AUTOEXEC.BAT before restarting. Don't have a file editor? No problem, enter the following commands to copy the text from the console into a file called config.sys:
C:
CD\
copy con CONFIG.SYS
files=30
buffers=10Then press Ctrl-Z to exit and save the output. These commands will copy the contents of the console (CON) to disk. We now have a CONFIG.SYS file located in the root directory of the C: drive.
Let's do the same to create the AUTOEXEC.BAT file:
copy con AUTOEXEC.BAT
@echo off
prompt $p$g
verAnd press Ctrl-Z. Great, now you can reboot.
8. Configuring DOS
Typically MS-DOS is configured with two files read by DOS at boot time (apart from COMMAND.COM itself). They are the following files (in the order in which they are accessed):
CONFIG.SYS contains a list of device drivers and configuration options loaded at boot time; it is located in the root directory of the boot disk.
AUTOEXEC.BAT starts after booting the machine and after loading device drivers into CONFIG.SYS. Both of these configuration files must be located in the root directory of the boot disk; A: when the system boots from a floppy disk, or C: for systems with a hard disk.
DOS may well boot without these files, but most applications add configuration options to them to make them work or to optimize their execution. Recent versions of DOS also attempt to configure themselves by making changes to these files during the installation process.
Running HIMEM.SYS at boot time is not enough, we need to configure EMM386.EXE or a third party Expanded Memory Manager. More on this later. The history of Intel processor architectures has to do with memory management, so we need to figure it out.
To configure extended memory access, we will edit C: \ CONFIG.SYS using the DOS editor:
\DOS\EDIT \CONFIG.SYSIf the file is not found, then simply save a new file under the name C: \ CONFIG.SYS. Add the
following text to the first line:
DEVICE=C:\DOS\HIMEM.SYSThere may be other entries in CONFIG.SYS, but add that to the first line. When finished, press Alt-F to go to the File menu and press S to save, then press Alt-F and X again to exit. Reboot, you should see a memory test and then the DOS command line: "C>".
Enter the MEM command on the command line to see how much memory is now available to DOS applications:
As you can see, DOS has only 571KB of conventional memory for applications, but almost 30MB of Extended Memory (XMS) and no Expanded Memory (EMS).
The reason is that I allocated 32 MB of RAM to this VM and the situation may be different on your hardware / VM.
It looks like we need access to Expanded Memory (EMS) to run the compiler, but how do we implement it? This is where EMM386.EXE comes in handy; this memory driver ships with later versions of DOS to support Microsoft Windows and other DOS applications that require a lot of memory, including some DOS games.
9. Memory management in DOS
If we load the memory management driver via CONFIG.SYS, we can see how much RAM it allocates. The config.sys file has the following two lines at the beginning. There may be other entries, but these first two lines must be at the beginning of the file and in that order.
DEVICE=C:\DOS\HIMEM.SYS
DEVICE=C:\DOS\EMM386.EXE
DOS=HIGH
FILES=30Reboot and run MEM again.
Comparing this screenshot with the previous one, we can see that the same main memory was found, but the maximum size of the program that we can run is now 612 KB (more than 571 KB), because we loaded DOS into upper memory with the DOS command = HIGH. We also emulated Expanded Memory (EMS) in the Extended Memory (XMS) range.
If we run the DOS MSD command, we get the following memory allocation scheme:
It shows the contiguous area of memory occupied by Expanded Memory. Each of the P characters stands for 1KB, so each line stands for 16KB of space that can be allocated. Borders that are not 16KB do not need to be distributed because they are not contiguous.
To compile Word, conventional memory and EMS were enough for me, but your free memory figures may be different depending on the version of DOS used and its configuration.
If you need more main and / or extended memory, then try using third party extended memory managers like QEMM, JEMM or UMBPCI, which use less main memory while still providing compatible extended memory.
Finishing the configuration
Some applications require temporary space for storing files, memory dump, etc., so let's create a directory for temporary files with the MD (make directory) command, and then use the SET command to point to the TEMP environment variable.
MD C:\TEMPThen we will make it set at boot time by adding it to autoexec.bat. Enter:
\DOS\EDIT \AUTOEXEC.BATAnd add the following to the end of the file:
SET TEMP=C:\TEMPPress Alt-F, S to save and Alt-F, X to exit the editor.
10. Compile OPUS
OPUS is the codename for Microsoft Word for Windows v1.1a. The source code provided contains C and assembly code, a proprietary compiler, linker, proprietary patching tools, developer notes, and documentation. These files contain everything you need to create a 16-bit executable file that can run on Windows v2.x, Windows v3.x, and OS / 2 v2.x without modification.
We need at least 612KB of main memory to compile this software, as well as at least 4MB of Expanded Memory, so you may need to study the DOS Configuration Guide to configure DOS for these conditions.
I created a guest in VMware Fusion with MS-DOS v6.22 as the guest operating system and also configured a DOS VDM under Windows XP; it all worked in both environments.
Stage 1: download
The source code is available on the Computer History Museum website:
https://computerhistory.org/blog/microsoft-word-for-windows-1-1a-source-code/
It will allow you to compile Microsoft Word v1.1a, but the linker often happens crashes unless you run op1.bat separately from the build folder. I have not yet figured out why this happens under DOS ... however under Windows XP we can emulate not only the DOS command line, but also extended and additional memory, and everything works! But how to do that?
Stage 2: unpack zip files
The host machine can run Windows, Linux or MacOS. I used a Mac, but it doesn't matter. Unpack the zip files and create a CD-ROM ISO image file containing all files.
See the ISO creation guide .
Stage 3: copy files
We transfer source code, compiler, linker and documentation to DOS machine / VM via CD-ROM.
The compiler must be run from the boot disk, so let's put it all in C: \ SRC. Since the amount of data is much larger than one or two floppy disks, I created a CD-ROM image that I mounted in the VM. If you have physical hardware, then you can do the same, or check the DOS Configuration Guide to learn how to access the CD-ROM from DOS, or through a physical disk, or through an ISO image file.
Stage 4: creating the BUILD folder
Note: some of these steps are taken from the comments on the Beta Archive forums ( https://www.betaarchive.com/forum/ ).
Let's create a new BUILD folder for each assembly and change fast.ini to point to this new assembly.
MD \SRC\OPUS\BUILD1Stage 5: changes to the compiler configuration
Before the application compiles, there are two files that need to be modified to suit your environment. I took most of these parameters from a post on the betaarchive forum . Go to the tools folder:
CD \SRC\OPUS\TOOLSBack up fast.ini
COPY FAST.INI FASTOLD.INIOpen FAST.INI as follows:
\DOS\EDIT \SRC\OPUS\TOOLS\FAST.INIThen change the content to look like this:
OPFL=+ls
NAM=WINWORD
EXE_DIR=C:\SRC\OPUS\PROGRAM
BUILD=C:\SRC\OPUS\BUILD1
OPUS=C:\SRC\OPUS
WORDTECH=C:\SRC\OPUS\WORDTECH
USER=Richard Lewis or Your Name
MMEM=
NOAPPLOADER=Save the file with Alt-F, S and exit with Alt-F, X.
Open mo1.bat so that it points to your folder structure, not the network drives that were listed in the source code:
\DOS\EDIT \SRC\OPUS\TOOLS\MO1.BATAnd change the following lines to match the file paths:
set PATH=C:\SRC\OPUS\TOOLS\tools\dos;C:\SRC\OPUS\TOOLS\tools
set LIB=C:\SRC\OPUS\TOOLS\lib
set INCLUDE=C:\SRC\OPUS\TOOLS;=C:\SRC\OPUS\TOOLS\wordtech;=C:\SRC\OPUS\TOOLS\lib;=C:\SRC\OPUS\TOOLS\asmChange all other paths to match your path, they may have drive names other than C :; so change them to start with = C: \ SRC \ OPUS \
Stage 6: compile!
Change the tools folder if you haven't already:
CD \SRC\OPUS\TOOLSCompile BUILD1 using the modified INI config file:
MAKEOPUS @FAST.ININo mistakes!? The object files will be placed in C: \ SRC \ OPUS \ BUILD1 and, if linking successfully, the EXE files will be located in C: \ SRC \ OPUS \ PROGRAM.
If you were compiling using DOS, then everything should look like this:
CSL Compiler - Successful Code Compilation and Patching
If you used XP (configuration instructions will be in the next post), then successful completion will look like this:
If memory errors occur, it is possible that there is not enough main or extended memory, you skipped the TEMP = assignment step in AUTOEXEC.BAT, or the FILES = assignment step in CONFIG.SYS, or there are syntax errors in FAST2.INI. Check these parameters again.
If you are unable to resolve memory errors, there are two solutions.
- Try to run mo1.bat from the BUILD folder. If that works, then the problem might be enough main memory but not enough contiguous extended memory.
- Try the same build process in DOS VDM under Windows XP - it looks like RAM is allocated correctly for each type of memory, however the resulting EXE cannot be run under Windows XP; it will run on a Windows v2 or v3 machine. See the Windows XP configuration Guide.
Note: after compilation, the mo1.bat file will reset the PATH environment variable and no longer include the DOS folder. This means that some DOS commands will no longer work if you do not provide the full path to the DOS folder for each command. Either add C: \ DOS to the PATH variable in the mo1.bat file, or simply reboot to restore the previous settings.
11. Launch Opus
In short, just copy all files from C: \ SRC \ OPUS \ PROGRAM to a Windows v2.x or v3.x machine, and then run WINWORD.EXE. That's all!
In the future, I will build a set of floppies that will do the correct installation based on this code, but for now this is enough for testing.
Under Windows 2.x the program should look like this
... and the same code running on Windows 3.x:
Advertising
Our company offers servers with pre-installed Windows . We do not save on hardware - only branded equipment and some of the best data centers in Russia and the EU. Hurry up to check.
