Jump to page content

Applications

Caveats

Most if not all pages are just rough notes, and these pages as a whole are far from complete. More notes will be added in time, eventually, maybe.

If, from reading these notes, you conclude that I am off my rocker, you won’t be the first, and you may even be right. These pages may simply position me as an acolyte to the late Gene Ray.

No doubt there are a dozen and one reasons why none of this would ever work, but perhaps somewhere deep down there is a tiny fragment that could be used for something.

Contents

Caveats

There are many approaches to a GUI, e.g. overlapping windows vs tiling windows and application-based (standard GUIs) or document-based (THE/Archy). Discussion on this page relating to graphical applications does not indicate which if any approach is to be taken and may ultimately become irrelevant.

Program types

This page covers “applications”, which for the purposes of this page are complete self-contained software packages that play a major role. There is a distinction between complete packages and toolchains. A toolchain is a set of binaries that provide small, distinct tasks typically on the command line. Linux supplies each toolchain utility as its own package, but Linux packages are more lightweight than the packages defined here for holding the contents of entire applications. Having a complete package for each individual binary seems excessive and as such it may be possible to place a whole toolchain into the same package, although this would make it impossible to add or remove individual utilities.

Binary structure

The Macintosh introduced a rich and flexible binary structure, using something bearing a passing resemblance to miniature relational database to hold the various resources (dialog box definitions, menu definitions, file type definitions, string tables, sound effects and so forth) for programs. Windows copied this idea but made it a custom file format, unlike the Mac’s resource fork system that was free for everyone to use for any purpose, including document files. Changing a single resource inside a Windows binary file (e.g. changing the program’s icon) is a slow and fragile process, as the whole binary has to be rebuilt and this often leads to corruption (a program that will crash on load). Adding, amending and removing resources from a file on the Mac was just like working with a database: it was fast, efficient and 100% reliable. The Mac originally stored the program code in resources, but moved the binary code to the program’s data fork (standard linear file) with the move to PowerPC processors in the mid-1990s.

Questions for the structure of a program binary include which resources need to baked in, and which can be kept external. Both Mac OS X and RISC OS use application directories: applications are folders (directories) disguised as a program, with the resources held as separate files. That is broadly the approach selected here.

Package contents

In additional to the application binary itself, the contents of the application’s package may include:

Binary files will have the version information and program icon embedded so that this information is specific to the binary and not the the package. A single package may contain various toolchain or helper binaries that need to be identified separately and maintain their own identity. A package should only have one manifest, but it may be necessary to bake this data into program binaries too. There may need to be separate package manifests (for file type handling and other package-level concerns) and binary manifests that instruct the OS on how to treat the binary itself.

Manifests

Each application bears a manifest that defines its requirements, expectations and services. The details below are not currently separated into high-level and low-level concerns.

The application manifest could be the same file as the package manifest (detailing the package type, dependencies etc), or it could be a separate file detailing application-specific matters, separate from the package manifest.

Application type

The application type field identifies which environment the application expects. In particular, the two default types correspond to the two event models: the Legacy Model and the Native Event Model.

Native Event Model applications are then able to elect whether or not they expect a text console to function, and whether they expect the input pipelines to be plain text (stdin, stdout and stderr emulation for plain-text pipelines) or structured for machine-readable pipelines (akin to PowerShell pipelines). System management tools will use structured message passing just as PowerShell does, while front-end tools such as text processing (akin to grep, wc, sed etc) will expect text streams. Pipeline content will be converted at format boundaries.

As there is no real distinction in application type, console applications are allowed to talk to the Desktop Manager and launch files, URLs and applications. This will only work if the Desktop Manager is available; a machine configured as console only or a process running inside a headless shell will fail to instantiate a handle to the Desktop Manager.

When starting an application, the UI should immediately provide feedback to show that the application launch has commenced, as noted under GUI: experience. This feedback requires the UI to understand the application’s working model and its needs. For example, a program that expects console interaction will require a console window, and this is what will be launched, and what a facility such as a taskbar or icon bar will indicate is being started.

Daemons are a special case. They do not interact with the graphical desktop and would not be started by the user directly, but do use the Native Event Model. Attempting to launch a daemon program should generate an error as they should only be started and stopped by the operating system (even if under the user’s instructions), not least because there is no useful way for the UI to demonstrate the results of the request (nothing will appear on the screen) or allow the user to cancel or reverse the request. Daemons will thus be marked as such in the application manifest as an alternative to console and graphical applications. Unlike Windows, daemons will not need a separate entry point, as the Native Event Model will cover any special messages required.

Handlers

The manifest will contain a list of all file types and protocols that the application understands, in a manner very similar to that of macOS. (Advertised file types date back to classic Mac OS, but advertised protocol handling did not appear until Mac OS X.)

Applications could also designate the permitted file types as primary/native and secondary/accepted, where the latter indicates the file types that they accept (for example as an import choice) but assume that the user will want to view them with another application. For example, a text editor may mark .html files as secondary/accepted in that the program can be listed as an editor for this type, but by default the files will open with a browser (which will mark .html as a primary/native type). Another option would be to have types marked as for viewing and for editing. A text editor would mark .html as a for-editing type, whereas a browser would mark .html as a for-viewing type. This would allow split responsibility over types, as noted on the file types page.

Multiple-document behaviour

One of the most fundamental differences between Mac OS and Windows is how each one handles opening two files of the same at once. At the user level, programs and processes on the Mac are not separate: a program is either running or not. macOS only allows one process per program per user, so document-based applications are expected to support having multiple open documents with a Window menu to select between them. Windows imposes no such limit and Windows applications choose whichever model they want: multiple documents per process (using the vintage MDI interface or by re-using an existing process for new document windows), separate processes for each document window, or a blanket ban on ever opening more than one document at once (even to the extent that different user sessions on a terminals server are blocked, a staggering violation of session isolation).

The consequence is that Windows itself has no idea how to open documents. For a while there was an DDI idea used by some programs for passing new files into existing processes, but this was clumsy and broken. Windows tends to just launch a new process and allow that process to locate the existing process if needed. When launching a batch of files, each one gets a separate process and these processes sometimes find each other instead of the original process. macOS simply bundles up the list of files and sends a message to the existing process, or launches the application and presents the file list collectively.

If we are to allow both multiple instances of a process and multiple documents open in the same process, this choice must be included in the application manifest. This way, the Desktop Manager knows whether to launch a new process or hand the file or list of files to an existing process.

Whether multiple instances of the same process should be allowed requires consideration. A single process handling multiple documents will, however, just like a Mac, receive system events collectively instead of the brain-dead Windows approach of trying to communicate with each window separately due to having no real method for processes to communicate.

Entry point

The application entry point may depend on the event model in use. Native Event Model applications will need a means to collect their start-up data, such as the start-up parameters (akin to the first Apple Event passed to a Mac program on launch that indicates what the program’s first task is) and to identify which services are available, in particular whether or not the user is inside a graphical session. There may simply be an OS call that the program can issue to obtain its start-up information rather than delivering it via the entry point.

Command-line specification

This portion of the manifest will define, for Native Event Model applications that are designated for command line or mixed invocation, the program’s command line parameters, allowing the OS to parse and process the command line and convert it to a structured message.

Each parameter will be defined with a name, type, status, conditions and description. The status in particular will indicate whether the parameter is optional or required. Conditions specify whether the parameter requires or proscribes another parameter or specific values of another parameter. The description allows for generation of brief documentation (akin to -? or --help). Name potentially may be short, long or both, depending on the practice chosen. Types will include text, integer, float and file identifier, and whether the parameter is a single item or a list.

Graphical applications will not require a command line definition; the OS will use dedicated high-level messages for sending files and URLs to applications. With graphical applications, the command line specification is only required where the application has custom start-up parameters.

Daemons

The list of available daemons (services in Windows terminology, and likely to be known as such here) will be cached from the relevant dimensions just as with regular applications. Only ratified daemons will be allowed to operate. The application installation process will be authorised to ratify daemons. Items added to the relevant dimensions by the user would not function as daemons until specifically ratified.