Capsules & Executable Forms

Executable forms serve different boundaries

ArcoFission can emit inspectable text bytecode for the hosted VM, wrap prepared bytecode and its runtime in a Linux ELF64 capsule, or lower a restricted freestanding program directly into a self-contained UEFI PE32+ image.

These are working alpha forms, not a declaration that Arcology’s final executable and package formats are settled. The long-term Capsule contains code, resources, metadata, manifests, and Contracts as a coherent materializable object.

Native outside, Arcology inside

ArcoBASIC source remains the authored truth
A-MIR preserves target-independent program intent
Hosted bytecode supports portable inspection and execution
A native launcher integrates with an existing host environment
Freestanding PE32+ crosses the firmware boundary without C or handwritten assembly
Capsule metadata will describe capabilities, dependencies, state, and lifecycle

Small source, explicit destination

This source can follow the freestanding pipeline into a bootable image. The environment and ABI are declared in the program itself; there is no hidden translation into another public implementation language.

ArcoBASICArcoBASIC source for a self-contained UEFI image

' These declarations make the destination explicit and inspectable.
#PROFILE UEFI
#TARGET X86_64
#RUNTIME NONE
#CALLCONV UEFI
#EXPORT "efi_main"

' UEFI supplies the two values needed to begin interacting with firmware.
FUNCTION Main(imageHandle AS UEFI.Handle, systemTable AS UEFI.SystemTable) AS U64
    ' Reach the firmware console through a readable object path.
    systemTable.ConsoleOut.Write("Hello from ArcoBASIC")
    RETURN 0
END FUNCTION

What remains open

The final Capsule manifest, executable format, package format, signing model, durable object identity, shared-state semantics, migration rules, and cross-device materialization remain design work.

Keeping those decisions open is deliberate: The Arcology should choose formats that serve its object and Contract model rather than inheriting architecture from whichever host format happened to bootstrap the project.

Separate the truth from its packaging

ArcoBASIC source is the one authored truth here; hosted bytecode, a native launcher, and a freestanding PE32+ image are three different packagings of the exact same intent, not three different programs that happen to agree. That separation is the transferable idea, not the specific list of output formats.

Keep one canonical representation of what a program actually means, and treat every deployable artifact as a projection of it, not an independent source of truth. When the canonical form and the packaged form can drift apart, they eventually will, and the two will disagree about something that matters.
Resist declaring a file format permanent just because it was the first one that worked. Early alpha output formats staying explicitly named as "working alpha forms, not a declaration that formats are settled" leaves room to fix a bad early decision before it calcifies into a compatibility promise.
When a format choice does not have to be made yet, say so plainly instead of quietly picking one by default. An open decision that is labeled open stays a decision; an unlabeled default becomes load-bearing before anyone agreed to depend on it.

LEARNING LAYER

Key terms, in plain language

You do not need a systems background to follow the work. These are the specialized terms used on this page.

Capsule: Arcology’s planned materializable software object containing code, resources, metadata, dependencies, and Contracts as one coherent unit.
Manifest: Structured metadata describing what a program contains, needs, exposes, and is allowed to do.
Bytecode: A compact instruction format for a virtual machine. It is lower-level than source code but remains portable across physical processor types.
VMVirtual Machine: A software execution engine that reads bytecode instructions. Here, VM means a language runtime, not necessarily a simulated whole computer.
ELF6464-bit Executable and Linkable Format: A common native executable format on Linux and other Unix-like systems. ArcoFission can use it as a host-side wrapper around prepared ArcoBASIC bytecode.
PE32+Portable Executable 32-bit Plus: A 64-bit executable file format used by UEFI and Windows. ArcoFission can place freestanding ArcoBASIC machine code into a PE32+ image that firmware can boot.
ABIApplication Binary Interface: The low-level agreement that lets separately compiled code call each other. It defines details such as argument locations, return values, register use, and stack layout.