CLOE development and runtime environment

Scope and evidence classes

“Complete” here means every product layer, target, installation or system name, delivery file kind, named operation, Listener/debugger control, and key binding that can be recovered from the inspected documentation. It also means recording where a complete answer is impossible. In particular, the documentation teaches command completion but does not enumerate the complete CLOE Listener command table. Without the implementation or a runnable runtime, inventing the missing commands would be worse than leaving a bounded TODO.

The licensed bodies remain ignored local inputs. This page publishes original analysis, short interface labels needed to identify the historical workflow, and portable checksums. It does not reproduce the recovered manuals, source bodies, or PC payloads.

What CLOE was

The most useful model is a development pipeline split across two machines:

Genera on a Symbolics computer
  CLOE Developer + SCT system declaration + target-aware Listener
       |  Migrate System / Migrate File / Migrate Precompiled System
       v
Intel 386 or 486 PC under MS-DOS
  CLOE Runtime / Application Generator
       |  compile and load on the PC; save a VMI delivery image
       v
optional Windows 3.0 Standard-mode front end
  WINFE + CLOE CLIM port + delivered application

The pipeline was deliberately not a cross-compiler. The Developer generated a target compilation plan and migrated sources, journals, and system bookkeeping. The 386 runtime compiled the application for itself. A separately shipped component such as CLOE Flavors could instead arrive precompiled for the delivery environment and be migrated as a loadable-but-not-compilable system.

The public Program Development Utilities manual explains the design tradeoff. A generic Common Lisp Developer targeted the portable least common denominator of many Common Lisps. CLOE Developer targeted Symbolics' own CLOE Runtime, so the two ends could share a richer dialect and purpose-built migration knowledge. That did not make the two environments identical: performance and final compilation still had to be tested on the delivery PC.

The inspected primary documents do not expand the word “CLOE.” Contemporary third-party catalogs often supply an expansion, but this dossier does not elevate it to a vendor-established fact without a primary witness.

Product layers and target boundary

The final two rows must not be merged. CLOE-WINDOW-DEMOS is named only inside a commented-out older installation block. The 3.1 CLIM demo instructions are active documentation for a different demo set on the delivery PC.

Media census and absence proof

The purchased Open Genera media was inventoried as a portable manifest: relative pathname, byte size, and SHA-256 for every file, sorted bytewise. The media root has 5,078 files totaling 242,585,012 bytes; the manifest SHA-256 is b99be9b197d049e87c85fabcd96f948711b3d97708153c1bd870214bf5883f54. Exactly one relative pathname contains cloe, case-insensitively:

There is no sys.sct/cloe/ product directory and no CLOE-named .system, sysdcl, component directory, Lisp source, VBin, FAS, VMI, EXE, page file, or archive. This is an exact statement about this manifest, not a claim about other historical release tapes.

The documentation file is Sage format 7, evacuated version 92, with 61 records and no embedded byte-array payload. Its attributes say that version 92 was compiled on 20 December 1993 with System 451.22 and Sage 439.0 from logical source version 91. The local inert extractor recovered 113,988 bytes of plain research text and a structured JSON tree; both remain under the ignored licensed-help build tree.

Release lineage

The evidence establishes a document lineage more confidently than a complete sales release chronology:

The database's 296 per-record modification timestamps range from July 1990 through December 1993. That range describes document editing, not necessarily product release dates.

Developer installation and entry

The documented Developer installation expected a site-configured Genera 8.1 world, a local or network cartridge-tape drive, enough LMFS space for the restored product, and IP-TCP when migration to a PC was required. The active guide estimates about 300 LMFS records for the Developer and roughly 5,000 FEP blocks for an incremental world containing it. Older, larger User Interface and Window Demo estimates occur only in commentary and are not 3.1 requirements.

The active operations are:

The guide also describes making a dedicated incremental Genera world containing the Developer. That historical procedure used ordinary Genera Load System, Save World, IDS, boot-file, and FEP operations; those are installation mechanics, not CLOE application features. This museum did not load the system or invoke any save.

Delivery workflow on the PC

The documented application workflow is:

1. Define the application as an SCT system on Genera. CLOE-aware declarations preserve ordinary options and use target fields such as :name, :pretty-name, :short-name, and :root-pathname-for-delivery.
2. Develop and test in the CLOE Developer dialect, while remembering that target performance and PC-specific behavior are not simulated exactly.
3. Use Migrate System to move source, journals, and the generated compilation plan to the delivery host. Use Migrate File for a single file, or Migrate Precompiled System for already-built target binaries.
4. Start the base Runtime or CLOE CLIM VMI from DOS. Load the migrated system declaration and compile on the 386. The public System Construction manual limits the 386-side compile-system interface to :recompile, :version, :verbose, :compile-print, and :root-path.
5. Load the application. For CLIM, defining an application frame automatically defines a CLOE program; otherwise call cloe:define-program explicitly.
6. Call cloe:save-program to produce a virtual-memory image. The public CLIM manual documents :simulate for a test run without writing the image.
7. Start the saved image with the appropriate DOS activator or batch wrapper.

cloe:define-program requires a second argument containing the program arguments; the 3.1 release note corrects older examples that omitted it. Both cloe:define-program and cloe:save-program accept :loop. When false, choosing the program-top-level restart exits to DOS; when true, it re-enters the application's top level. This is a delivery behavior, not merely a build flag.

For a migrated precompiled Flavors system, the PC Listener loads system CLOEFL with a target root path. The documentation then defines and saves a program to make a new VMI containing Flavors. Because the payload is precompiled, it can be loaded but not rebuilt from source in that delivery environment.

Files and serialization boundary

CLOE delivery used several very different file types. A VMI is a saved CLOE virtual- memory program image; it is closer to an application Lisp image than to a source archive. The page file is temporary virtual-memory backing. Neither should be mistaken for an ordinary Genera VLOD world, and neither is present here.

The distribution records name these roles and representative files:

• base and CLIM images: CLOE.VMI, CLOECLIM.VMI, and the spelling CLOE-CLIM.VMI in an older list;
• image activators: VMRESTOR.EXE/the command spelling VMRESTORE, and CLIMREST.EXE;
• configuration: CFIG386.EXE;
• Windows integration: WINFE.EXE and STDSTUB.EXE;
• startup: CLOE.BAT and CLOE-CLIM.BAT;
• page backing: CLOE.PAG;
• Lisp payloads: METER.FAS and the Listener binary CLOELIST.FAS; and
• installation packaging: CLOECLIM.ZIP, INSTALL.BAT, decompression tools, and a readme.

Some records use alternate spellings or older filenames. The source needed to map every alias to an exact release is absent, so the table preserves those variants instead of normalizing them away.

The older public Program Development Utilities manual says a CLOE compiled file has type .B. The local 3.1 release record says that such examples are wrong for 3.1 and should say .FAS. This is release drift, not a contradiction to be resolved by choosing whichever manual is more convenient.

CLIM and Windows integration

CLOE Listener and debugger

Two top levels are described:

• the base CLOE CLIM VMI has a TTY-style read/evaluate/print loop with rubout and activation when a complete form terminator arrives; after Windows starts, the same basic terminal behavior is available in the Window Front End; and
• the separately loadable CLIM Listener adds a scrollable output history, mouse-sensitive expressions, multi-line input, completion, command recall, clipboard input, and both Emacs- and PC-style editing keys.

The development Listener accepts Lisp forms or colon-prefixed commands. Space can complete a command name and move to its arguments. F1 gives contextual completion help, and colon followed by F1 requests the available command set. Within the Listener-interface record, the only named ordinary colon command is :Clear Output History; the migration workflow separately names :Migrate Precompiled System. Therefore a complete Listener command inventory remains TODO: requires the unavailable Listener command table or a runnable CLOE runtime.

Listener history output is presentation-sensitive. The documented default gestures are Left to paste an object into input, Middle to describe it, and Right to show an object-specific menu. Clipboard input is inserted with F6 and must contain one complete Lisp expression; the guide recommends loading a file instead of pasting multiple forms one by one.

Complete documented CLOE Listener bindings

This is the complete 29-action table rendered by the CLOE 3.1 Listener record. A dash means the document gives no binding in that style. On the PC, Alt corresponds to Emacs Meta.

The prose says F3 recalls the first history form and Alt-Y continues backward through history. That is more specific than the table's generic “history yank” and “yank next” labels, so both descriptions are retained.

Generic CLIM controls documented for CLOE

The installed and public CLIM 2.0 guide supplies a larger generic input-editor table. It is relevant to the documented CLOE CLIM port, but it must not overwrite the release-specific 3.1 Listener table above. In particular, this later table includes sexp and case operations that the 3.1 CLOE-specific table does not list.

Demos and visible applications

The active 3.1 runtime documentation describes four CLIM demos:

The demo driver is a CLIM menu with an Exit choice. The documented system can be compiled and loaded through CLIM-DEMO, then entered with clim-demo:start-demo. The 3.1 text contains a corrupted target label in this record, so this page relies on the surrounding, consistent MS-DOS/386 evidence rather than guessing at the damaged characters.

No screenshots of these demos are published. A screenshot from generic Genera CLIM would document Genera CLIM, not CLOE CLIM; a reconstruction on modern Windows would be a reimplementation, not a runtime observation.

Language and system compatibility contract

Fresh Genera 8.5 load-state observation

Session d44-cloe-registration-20260718, generation 1, ran one read-only form in Dynamic Lisp Listener 1 on 18 July 2026. It queried four packages, three feature symbols, and five systems using the loaded-only form of sct:find-system-named; it did not load a system or trigger a site lookup.

All four packages were absent: CLOE, WIN, CLOE-RUNTIME, and CLOE-DEVELOPER. All three features were absent: CLOE, CLOE-DEVELOPER, and CLOE-RUNTIME. All five loaded-system queries returned no: CLOE, CLOE-INSTALLATION, CLOE-FLAVORS, CLOE-UI, and CLOE-WINDOW-DEMOS. This proves only the base world's load state. It agrees with, but is logically separate from, the host-media manifest.

The session used the 54,804,480-byte Genera 8.5 world a8ee5e86cc7e322f7385af3e0cd579d7650d4dcfc3ce328acbf8b25515dd0672, 1,533,760-byte VLM 9f5e18d5770f973879716182b6856ef5a8ee9d3b2bb907476ea0cf35986aa4c7, 346,880-byte debugger 2db918cfe8f35f52c7ff4b7695b0ecd3bb85e41a3327ea5a94874edf05edb54a, configuration 5ce6509f5adf2cf2d054d34eb4ba777ce462285b8cd9b01bc071bf819139e086, legacy-command preload f45f45461622975996ab41138f64bb84a4b17c51fba0dbb649208914898c26b7, and X compatibility preload acd71dbcb948f05b7fd2730b2b4706c08f16f46d792bd9aa6aa64370e855e4b1. The private world remained identical to the base.

The Bubblewrap run isolated user, mount, network, PID, IPC, and hostname namespaces, exposed no host root, external route, or guest file service, and used a private Xvfb with MIT-SHM disabled and verified absent. Both exact guest-X compatibility substitutions and the one-shot RFC 868 response were observed. The action log has two intent/outcome entries and SHA-256 d21ab43f8f114b03ade70a5962c57dcf279229f1cefc4aca0d1da4bb7bbeb82e.

A local 1200 by 900 evidence capture has PNG SHA-256 146816e2e696f800e3770b555f2c5028ea4ac9efcf17940f8a358865e14b1498 and normalized pixel SHA-256 7efeeb18880a468601255561445357c6505f77f6af1a22e75395803230d6fa1b. It remains in the ignored session tree because it is only a generic Listener showing negative registration results, not a CLOE application state.

Shutdown reached its prompt, sent and accepted confirmation, and observed cleanup, then reproduced the known bounded VLM cleanup stall and required force-stop. orderly_vlm_host_shutdown is false; forced_after_confirmed_shutdown_stall and state_may_be_incomplete are true. The harness did not invoke Save World or create a host process checkpoint. save_world_performed and guest_checkpoint_created remain unknown, while the private world file's unchanged hash establishes that no world bytes were persisted.

Documentation coverage of the 61-record database

This compact inventory prevents a few prominent records from standing in for the whole recovered corpus. Ranges identify the database order, not page numbers in a printed book.

Several referenced topics have no corresponding record in the file, including the full CLOE foreign-function interface and the 3.0 reference manual. Their behavior is TODO unless another licensed or public primary witness is recovered.

Open questions and preservation priorities

1. Recover an authoritative CLOE 3.1 product distribution. The executable, Developer source/system definition, runtime VMI, Windows front end, and Listener command table are all absent here.
2. Find the standalone 3.0/3.1 reference manual. It should resolve the foreign- function interface, complete Runtime SCT contract, program-image format, and command inventory.
3. Establish the status of CLOE 4.0. Editorial annotations alone are insufficient evidence of a shipped release.
4. Identify CLOE-UI and CLOE-WINDOW-DEMOS. Present evidence gives names and old storage estimates but not reliable features, controls, or screenshots.
5. Preserve a legally acquired DOS/Windows machine image if found. A future harness should keep raw captures ignored, record exact disk/image hashes, and publish only reviewed, claim-specific screenshots.
6. Reconcile filename variants and the damaged demo target label. Do not repair historical text by intuition.

Until those witnesses are found, the strongest accurate museum label is: CLOE is extensively documented as an external Genera-to-PC development and delivery system, but it is not installed or recoverable from this Open Genera media set.

Public primary sources

The public PDFs were verified on 18 July 2026:

Related museum context is in CLIM 2 on Genera, Dynamic Lisp Listener, system construction, patches, worlds, and distribution, and the Genera computer-use harness.