#Part 14. ClosedBitOS Desktop And Phone
The current Computer ISO is no longer a full-screen launcher mockup. It contains ClosedBit-owned x64 and IA32 UEFI applications, a ClosedBit-built FAT16 EFI system image, El Torito catalog, and ISO9660 filesystem. It selects the EDID preferred monitor mode when firmware exposes it, with a highest-usable GOP fallback, and provides antialiased Inter text, official ClosedBit/Browser branding, wallpaper, desktop icons, a taskbar, pointer input, z-ordered overlapping windows, and Studio, Browser, Terminal, Files, and Settings surfaces. The image is structurally validated without launching it in an emulator or VM.
ClosedBitOS-Phone-20260803-r2.iso is a separate ARM64 UEFI image. It contains Browser and Settings only and is statically checked to reject Studio, compiler, .cbp, and programming-environment material.
Current images live under D:\ClosedBitOS\release and use revisioned filenames so virtual optical-media caches do not confuse a rebuilt image with an older registered disc. Fully power off a VM and eject the previous virtual DVD before selecting the new file. The Computer image requires UEFI; legacy BIOS is not yet part of the ClosedBit-owned boot path.
These remain firmware-shell milestones rather than releases: they still use UEFI boot services for input and timing. Exiting boot services, owning the firmware memory map, persistent storage, .cba loading/execution, scheduling, isolation, native networking/TLS, audio, and accelerated GPU drivers remain release gates.
#Part 14 Section 1. What Counts As A Real OS
A real ClosedBitOS release needs a boot chain, kernel, memory management, interrupt handling, clocks, scheduler, process isolation, syscalls, storage and filesystems, device discovery, input, display, networking, security boundaries, recovery, installer/update strategy, user space, applications, diagnostics, and hardware support documentation.
An ISO that boots to a graphical demo is valuable engineering progress, but it is not automatically a secure or generally usable OS. Release labels should state exactly which hardware, VM firmware, architecture, storage model, display path, and features were tested.
#Part 14 Section 2. Desktop Product Shape
The desktop target includes the ClosedBit IDE and OS-development toolchain as first-party apps. It should boot at the monitor's native resolution, support scale-aware layout, expose a recovery console, and keep the programming environment outside the kernel trust boundary. Compiler crashes must not crash the OS.
The IDE image should include the ClosedBit compiler, package checker, debugger/log viewer, library sources/reference, x86 and ARM64 kernel targets, disk-image builder, symbol tools, test runner, and emulator/VM launch profiles. Toolchains should be versioned and reproducible.
#Part 14 Section 3. Phone Product Shape
The phone edition is a separate product profile, not the desktop image squeezed onto a narrow screen. Its initial app set is the shell, settings, dialer/emergency surface when telephony exists, and ClosedBit Browser. It intentionally omits the programming environment.
Phone release work additionally requires verified boot, signed updates with rollback protection, suspend/resume, thermal and battery management, touch/rotation, modem and emergency-call compliance, audio routes, cameras, sensors, secure lock screen, encrypted user data, application permissions, accessibility, reset/recovery, and a supported hardware device. Until those exist, it is an OS development target rather than a finished phone product.
#Part 14 Section 4. ISO And Media Safety
The current deliverable should remain an ISO or VM disk image. ISO generation writes a regular file in the build output; it must not enumerate or modify physical disks. A future media creation tool must show the exact removable device model, size, serial, partitions, and destructive warning; require explicit re-selection and confirmation; refuse the system disk; re-check identity immediately before writing; and verify the image afterward.
Never test media writing against a broad drive letter, the current OS disk, or an automatically chosen “first disk.” VM validation comes first.
