Skip to content
This repository has been archived by the owner on Dec 24, 2020. It is now read-only.

Latest commit

 

History

History

apps

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
c1p
c1p
 
 
pcx86
pcx86
 
 
pdp10
pdp10
 
 
pdp11
pdp11
 
 
README.md
README.md
 
 

README.md

layout title menu_title menu_order permalink
page
Application Archives
Apps
2
/apps/

Application Archives

PCjs provides a variety of archived software:

You can also browse our collection of archived disks:

Last but not least, we also have a few test resources:

{% include_relative pcx86/README.md %}

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:

  • Title
  • Version
  • 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.

Example: VisiCalc

VisiCalc is stored in an /apps folder, and two relevant files are described by <file> entries in its manifest:

<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:

http://localhost:8088/api/v1/dump?path=/apps/pcx86/1981/visicalc/bin/VC.COM;../README.md&format=json

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.

Example: CP/M-86

CPM-86 is stored as two disk images in a /disks folder. The disk images are described in that folder's manifest:

<manifest>
    <title>CP/M-86</title>
    <version>1.1B</version>
    <type>Operating System</type>
    <category>CP/M</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.00/machine.xml"/>
    <disk id="disk01" href="/disks-demo/pcx86/cpm/1.1b/CPM86-DISK1.json">
        <name>CP/M-86 1.1B (Disk 1)</name>
    </disk>
    <disk id="disk02" href="/disks-demo/pcx86/cpm/1.1b/CPM86-DISK2.json">
        <name>CP/M-86 1.1B (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-demo/pcx86/cpm/1.1b/manifest.xml" disk="disk01"/>

and if it wanted to use all the disks listed in the manifest, it could simply omit the disk attribute or use an asterisk; e.g.:

<manifest ref="/disks-demo/pcx86/cpm/1.1b/manifest.xml" disk="*"/>