PCjs provides a variety of archived software:
- IBM PC Applications
- Challenger 1P Applications
- DEC PDP-10 Tapes and Diagnostics
- DEC PDP-11 Tapes and Diagnostics
You can also browse our collection of archived disks:
IBM PC Application Demos
Below are selected PCx86 demos of classic IBM PC applications. In many cases, we’ve had to create our own “Demo Disks”, because copies of the original distribution disks are difficult to find, and in some cases (e.g., Executive Suite), the original disks were copy-protected, so we’ve been forced to use a “cracked” copy of the software instead.
A list of all the software available to PCx86 machines can be found in the IBM PC Disk Library.
- 1-2-3 Release 1A
- Adventures in Math v1.00
- SuperCalc2 v1.00
- SuperCalc3 v1.00
- Zork II
- Zork III
Software Application Manifests
In the PCjs Project, every complete software package is stored in its own folder, either as a set of individual files (under /apps) or as a set of disk images (under /disks), along with a manifest.xml file that describes the software. The manifest format is still being developed, but at a minimum, it should contain the following information about the software:
- Type (eg, Application, Game, OS, Diagnostic, Utility, etc)
- Category (eg, Productivity, Text Adventure, BASIC Compiler, etc)
- Company (eg, IBM, Microsoft, etc)
- Creation Date (of first version)
- Release Date (of this version, if different from creation date)
- Creator(s) (of first version)
- Author(s) (of this version, if different from creator(s))
- Contributors(s) (names of additional contributor(s) to this version)
- Publisher (name of publisher, if different from company)
- License (with link to current software license, if any)
- Machine (reference to PCjs machine.xml file capable of loading/running the software)
- Disk(s) (one or more entries describing sets of files and/or disk images)
The distinctions made by Type and Category are a bit arbitrary and likely to change. For now, Type is merely a reflection of how we initially filed the original disks, while Category provides more detail.
<manifest> <title>VisiCalc</title> <version>VC-176Y2-IBM-TEST</version> <type>Application</type> <category>Productivity</category> <company>Software Arts</company> <author href="http://www.bricklin.com/history/sai.htm">Dan Bricklin</author> <author href="http://www.frankston.com/public/?name=ImplementingVisiCalc">Bob Frankston</author> <releaseDate>December 16, 1981</releaseDate> <license href="http://www.bricklin.com/history/vclicense.htm">Lotus Development</license> <machine href="/devices/pcx86/machine/5150/mda/64kb/machine.xml" state="/apps/pcx86/1981/visicalc/state.json"/> <disk id="disk01" chs="40:1:8" dir="archive/visicalc.81" href="/apps/pcx86/1981/visicalc/VISICALC1981.json" md5="5b77efdfb86aa747edb49811db75021d" md5json="b1a45cb769cf04daa259263a92bacf16"> <name>VisiCalc (1981)</name> <file size="27520" time="1981-12-16 23:00:00" attr="0x20" md5="28997dfedb2440c6054d8be835be8634">VC.COM</file> <link href="http://www.bricklin.com/history/vclicense.htm">VisiCalc License</link> </disk> </manifest>
Since this manifest also contains a <machine> entry, the default manifest stylesheet will automatically load and launch the associated PCjs machine. The machine will boot or resume according to its own <computer> settings, unless the manifest overrides the machine’s default state with its own state setting; eg:
<machine href="/devices/pcx86/machine/5150/mda/64kb/machine.xml" state="/apps/pcx86/1981/visicalc/state.json"/>
The machine.xml file, in turn, refers to a sample set of disk images, one of which is:
<manifest ref="/apps/pcx86/1981/visicalc/manifest.xml" disk="*"/>
which refers to the <disk> entry in the VisiCalc manifest – which brings us full circle.
Since that <disk> entry is just a reference to a folder, PCjs must first convert it to a disk image, using the following API request:
The PCjs DiskDump module processes the dump request and generates a JSON-encoded DOS 2.x-compatible disk image containing all the specified files.
However, to avoid the PCjs web server re-generating the same disk image for every user-initiated disk load, we have saved that JSON-encoded image as static file on the server, and then added an href attribute to the manifest’s <disk> entry:
<manifest> <disk id="disk01" chs="40:1:8" dir="archive/visicalc.81" href="/apps/pcx86/1981/visicalc/VISICALC1981.json" md5="5b77efdfb86aa747edb49811db75021d" md5json="b1a45cb769cf04daa259263a92bacf16"> ... </disk> </manifest>
PCjs always prefers a resource specified by href. While the <file> entries are now superfluous, they still serve to document the contents of the disk image, and are still necessary if the disk image ever needs to be re-generated.
<manifest> <title>CP/M-86</title> <version>1.1B</version> <type>OS</type> <category>Operating System</category> <company href="http://en.wikipedia.org/wiki/Digital_Research">Digital Research</company> <publisher href="http://en.wikipedia.org/wiki/Eagle_Computer">Eagle Computer</publisher> <releaseDate>May 20, 1983</releaseDate> <machine href="/disks/pcx86/cpm/1.1b/machine.xml"/> <disk id="disk01" href="/disks/pcx86/cpm/1.1b/cpm86-disk1.json"> <name>CP/M-86 (Disk 1)</name> </disk> <disk id="disk02" href="/disks/pcx86/cpm/1.1b/cpm86-disk2.json"> <name>CP/M-86 (Disk 2)</name> </disk> </manifest>
In this case, the software was “born” as disk images (non-DOS disk images at that), so we don’t bother listing the contents of those images with <file> entries inside the <disk> entries.
We do, however, include optional <name> entries that help describe (or at least differentiate) the disk images.
If a machine file wanted to use only the first disk, then it would specify:
<manifest ref="/disks/pcx86/cpm/1.1b/manifest.xml" disk="disk01"/>
and if it wanted to use all the disks listed in the manifest, it would specify:
<manifest ref="/disks/pcx86/cpm/1.1b/manifest.xml" disk="*"/>
which is what our CP/M Machine Configuration does.