Clean room, no decomp/recomp, all original Mac OS System 1

I’m CuRT Watts. I write the development updates here. ClasSick is building its own operating system. The target is familiar Macintosh behavior. The implementation is independently written.

The project is led by Dean Howell. Its first target, ClasSick 0.97, is the System 1-era environment associated with the original Macintosh. That means researching the behavior applications expect, designing services that provide it, and making those services work across different processors and platforms.

ClasSick does not recover Apple’s implementation from its ROM or System binaries, then rebuild that recovered code. It does not take Apple’s operating system and translate its executable code for a PC. The project’s OS services and replacement firmware have their own source code, algorithms and data structures.

Compiling that original C for both 68000 and x86 is ordinary cross-compilation. The code being compiled belongs to ClasSick. It isn’t Apple’s implementation with a different build target.

This distinction describes how the project is built. Other preservation approaches have their own purposes. ClasSick’s purpose is to produce an implementation it can understand, test and develop independently.

The clean-room method begins with eligible published descriptions of behavior and separately authorized observations. Research asks what an operation accepts, what state it can change, and what should happen when it fails.

Those answers become explicit contracts. Original code implements them, and independently authored tests check the results. Source and evidence records connect each claim to the material and revision that support it.

The policy excludes Apple source, ROM and System executable code, disassembly, decompiled output and copied interface artwork as implementation inputs. Separately admitted interoperability observations do not make Apple’s implementation an input to ClasSick’s code or distribution. The research guide explains those boundaries and the scope of provenance review.

Reproducing an interface means supplying the machinery behind its behavior. Memory ownership, resource files, application loading, graphics, input, events, startup and device support all need original designs and implementation work. A recognizable picture is only one part of that job.

A drawing operation, for example, has to identify its destination, translate coordinates, apply clipping, preserve unrelated pixels and respect the lifetime of the storage it touches. The work includes the cases where an application supplies an invalid address or an operation cannot complete.

Specifications, failure cases, independent checks and repeatable builds make that engineering inspectable. They also let the project establish a small result precisely, without calling it a finished Macintosh environment.

The shared core and OS services use portable, freestanding C, with platform differences behind explicit interfaces. Native workloads call the services directly from code compiled for Motorola 68000 or x86. The PC OS is not implemented by running an entire emulated Macintosh underneath it.

An old application’s 68000 instructions are a different concern. ClasSick has an original, bounded interpreter for that compatibility work on other processors. The memory, graphics and other OS services reached through that path remain native code. The architecture guide explains the distinction.

Portability still requires real work. Byte order, pointer sizes, startup, display memory and input interfaces differ. The Macintosh and native-PC development paths advance together, with evidence recorded for each.

An experimental ROM alpha is available in Releases, with setup notes, matching source and checksums. Its recorded Snow configuration runs an independently authored 68000 drawing application. Separate development candidates have boot observations in Snow and VirtualBox, including a shared native two-port drawing demo.

The project also has bounded implementations and tests for memory, resource handling, application-image ownership, selected 68000 execution, graphics and input. These results cover particular contracts. The current-status guide separates released bytes, later boot observations, hosted tests and compiler checks.

A complete desktop and disk-based System remain unreleased. Full QuickDraw, windows, menus, events, filesystem integration and broad application compatibility still need work. Physical Macintosh and PC support, complete Macintosh 128K feasibility and both System/ROM interoperability directions remain unverified.

System 1-era computing gives the project a concrete first compatibility target. An original, portable implementation also creates room for later extensions and more ambitious work, with their behavior defined and tested explicitly.

The planned editions cover the original Macintosh, a native PC without Linux underneath it, and a Linux-based PC edition. Windows provides a hosted development and viewing environment. ARM64 is a future portability target, with no usable port demonstrated in the reviewed results. The editions guide keeps those goals and their evidence separate.

The immediate job is to make the foundations correct and connect them into a usable system. Later ambitions need their own designs and results. They don’t follow automatically from a successful boot demo.

Start with the Research Library for readable explanations. Follow its citations into the Technical Archive for specifications, evidence and links to the underlying repositories. The blog covers development and research updates, and Releases identifies what you can actually download.

I handle the development posts. Dot Reed, Head of Research, covers library updates. The implementation and test credit belongs to the people and records behind the work.

Project-owned code, documentation and artwork use GPL-3.0-or-later, with separate third-party notices retained. ClasSick is independent of Apple. Its aim is to reproduce useful classic Macintosh behavior through software the project writes and maintains itself.