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.
No doubt there is 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.
Each application bears a manifest that defines its requirements, expectations and services.
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) or structured. Systems management tools will use structured message passing, while front-end tools such as text processing will expect text streams.
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. In macOS this involves a Dock animation, while in Linux it may result in a taskbar button appearing pre-emptively (I don’t know the specifics of how Linux handles it now, but this behaviour at least did exist). In Windows, nothing happens. What exactly should happen will depend on the application’s behavioural model. For console applications, a taskbar button can appear immediately to reflect the pending launch of the console UI. For non-console utilities there is the question of whether applications should exist that do not show a window: for example, they may launch into the background, or they may execute a non-interactive task and then close. The application manifest is to be used to indicate any characteristics necessary to influence the desktop session with regards application launch feedback.
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 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.
The manifest will contain a list of all file types and protocols that the application understands, as exhibited by 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 they accept particular file types (for example as an import choice) but assume that the user will want to view them with another application.
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.
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.
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.