V12.0 BASE CONTRACT

Build, run, test

Two complete workflows: one hosted source you create yourself, and one exact release-native source compiled into an i686 ELF object.

DByte 12.0 · Getting started

01 hosted path — create, check, tree, VM§

RUNNABLE · WINDOWS POWERSHELL · HOSTED

New-Item -ItemType Directory -Force .\hosted-demo | Out-Null
Set-Location .\hosted-demo
@'
print("HOSTED OK")
'@ | Set-Content -Encoding ascii .\app.dby

FILE TREE

hosted-demo\
`-- app.dby

COMMAND · WINDOWS POWERSHELL · HOSTED CHECK

dbyte check .\app.dby

SUCCESS GATE: exit without a compiler diagnostic. IF THIS FAILS → DIAGNOSTICS

COMMAND · WINDOWS POWERSHELL · HOSTED TREE

dbyte run .\app.dby

COMMAND · WINDOWS POWERSHELL · HOSTED VM

dbyte run --vm .\app.dby

EXPECTED OUTPUT FROM TREE AND VM

HOSTED OK

SUCCESS GATE: both engines print the exact same line. IF TREE OR VM FAILS → DIAGNOSTICS

02 test-runner boundary§

DOCUMENTED CLI · SHIPPED PROJECT EXAMPLE · TEST LAYOUT NOT CANONICAL

Project · test status map§

Status	What is actually established	Use it as
FROZEN RELEASE CONTRACT	`dbyte test` and `Dbyte.toml` project workflows are documented for v12.0.0. A mandatory `tests\` directory layout is not frozen.	CLI/project capability boundary.
SHIPPED PROJECT EXAMPLE	`examples\project_demo\Dbyte.toml` + `src\main.dby` ship in the release ZIP.	Concrete manifest/source example, not a mandatory template.
REPOSITORY CONVENTION	Repository verifier/test trees may use additional layout or fixtures.	Implementation practice only unless a release contract explicitly freezes it.

The v12.0.0 release README documents dbyte test and Dbyte.toml project workflows. The frozen release ZIP does not ship a canonical tiny test fixture that defines a stable test-directory convention, so this manual does not invent one.

dbyte test

DOCUMENTED BUT NOT CANONICAL: test discovery/layout remains project or repository behavior until a release contract freezes a fixture. Do not infer a required tests\ directory from this page.

The release does ship a small project example that can be inspected as the authoritative v12.0.0 project-manifest shape:

examples\project_demo\
|-- Dbyte.toml
`-- src\
    `-- main.dby

VIEW EXACT Dbyte.toml · VIEW EXACT src/main.dby

main.dbyDOWNLOAD OPEN RAW

import std.math as math

fn add(a, b):
    return a + b

let x = add(10, 20)
print("10 + 20 =", x)
print("abs(-42) =", math.abs(-42))

DBY · 142 BSHA-256 b09967de2616142d1bf28e5cbbcdd0da1156aee04beb7ba2de4455c84efa7a96

Dbyte.toml SHA-256  df727260fe15fb50c7193d20ee7170b5866e402ec9e2b5c7fee85f7484a0c52d
main.dby SHA-256    b09967de2616142d1bf28e5cbbcdd0da1156aee04beb7ba2de4455c84efa7a96

SOURCE: both mirrors are byte-for-byte copies from dbyte-v12.0.0-windows-x64.zip. They document a shipped project example, not a frozen test-directory contract.

03 native path — exact source to ELF32 object§

RUNNABLE · WINDOWS POWERSHELL · NATIVE i686-dbyte-none

This path starts at the root of the extracted v12.0.0 Windows package and copies the exact shipped examples/native_kernel/kernel.dby into an isolated demo directory. It does not create a Windows executable.

Exact release source SHA-256: b4ca562caf06e9e3cee0aa188f2420a3c4eed34cd2208a552e2302d1d6d0aa8d.

New-Item -ItemType Directory -Force .\native-demo | Out-Null
Copy-Item .\examples\native_kernel\kernel.dby .\native-demo\kernel.dby
Set-Location .\native-demo

FILE TREE BEFORE BUILD

native-demo\
`-- kernel.dby

COMMAND · WINDOWS POWERSHELL · NATIVE BUILD

dbytec build .\kernel.dby --target i686-dbyte-none --emit obj -o .\kernel.o

FILE TREE AFTER SUCCESS

native-demo\
|-- kernel.dby
`-- kernel.o

SUCCESS GATE: kernel.o exists and the build exits without a native-profile diagnostic. IF NATIVE BUILD FAILS → DIAGNOSTICS

04 inspect the native artifact§

COMMAND · WINDOWS POWERSHELL · DBYTE INSPECT

dbyte inspect .\kernel.o --symbols --relocations --disasm

SUCCESS GATE: the DByte inspector accepts the artifact instead of reporting malformed ELF. The object contract is ELFCLASS32, little-endian, EM_386, ET_REL with symbols/relocations where required.

Expected native inspection invariants§

OUTPUT GUIDANCE · NATIVE ET_REL · FORMAT MAY VARY

The exact text produced by dbyte inspect is not frozen by this tutorial, and symbol/relocation rows depend on the source. Treat these object properties as the stable acceptance markers:

ELF class      ELF32
endianness     little-endian
object type    ET_REL / relocatable
machine        EM_386 / Intel 80386
entry address  0x00000000 for a relocatable object
symbols        source-dependent
relocations    source-dependent; present where cross-symbol references require them

OPTIONAL CHECK · GNU BINUTILS · NATIVE HEADER

objdump -f .\kernel.o

For a conforming DByte i686 relocatable object, the stable part of the header should identify file format elf32-i386 and architecture: i386. Flags, symbols and relocation names can vary with the source; do not compare a whole listing byte-for-byte unless the fixture itself freezes that output.

OPTIONAL CHECK · GNU BINUTILS · SYMBOLS · RELOCATIONS

objdump -f -h -t -r .\kernel.o

READ ELF OBJECT CONTRACT · READ INSPECT CONTRACT

05 failure boundary§

FAILURE EXAMPLE · DO NOT EXPECT WINDOWS EXECUTION

.\kernel.o

An i686-dbyte-none ET_REL object is a native build artifact, not a Windows program. Do not double-click it or expect PowerShell to execute it. Link/boot steps belong to the native systems path.

06 next step§

Hosted work: LANGUAGE BASICS · Native work: TARGETS → BARE METAL · Failures: DIAGNOSTICS.

BOUNDARY: hosted execution is a Windows-host workflow in the published v12.0.0 package. Native i686-dbyte-none output is a target artifact and is not a Windows application.