nexoniarz/SchOS
nexoniarz/SchOS
Watch
1
0
Fork
You've already forked SchOS
 0
Code Issues Pull requests Projects Releases 1 Packages Wiki Activity Actions
SchOS/.claude/memory/schunix-build-environment.md
Nexoniarz 3182da3965 Carry project memory in the repo, with tools/memory-sync.sh 
Claude Code keeps per-project memory at <home>/.claude/projects/<key>/,
where <key> is the project's absolute path with every separator and the
drive colon turned into a dash. That makes it both rename-fragile and
machine-specific, and this project has hit each of those once:

  - D:\DEV\Schunix -> D:\DEV\SchOS changed the key, and 43 memories were
    invisible until moved across by hand.
  - Development happens from Windows and from Linux, and each looks in a
    different place for the same checkout.

Committing .claude/memory/ fixes both -- git carries it across renames
and between hosts -- and `import` puts it wherever the local machine
expects. .claude/settings.local.json stays ignored: those are per-machine
permissions.

The colon maps to a dash rather than being dropped. Deleting it gives
D-DEV-SchOS, which matches nothing and silently finds zero memories; that
was the first attempt. On Git Bash the key comes from `cygpath -w`,
because Claude Code is a Windows program and sees D:\DEV\SchOS, not
/d/DEV/SchOS.
2026-08-09 14:27:22 +02:00

2.9 KiB
Raw Blame History

name description metadata
schunix-build-environment Schunix builds natively on Windows with clang/lld + mingw + Git Bash; WSL is gone because WSL2 needs Hyper-V
node_type type originSessionId modified
memory project 9d8a2aef-bcf0-47a0-96c6-f706efab4a95 2026-08-07T17:19:34.188Z

Builds natively on Windows. WSL is no longer used at all. WSL2 runs a real Linux kernel in a Hyper-V VM, so it hard-requires virtualisation, and enabling that puts the Hyper-V hypervisor under the whole machine — which demotes VMware to running nested and slows the box down permanently. Nexoniarz will not enable it, and that is a reasonable call.

make from Git Bash does everything. run.ps1 builds natively too. The toolchain, all already installed:

  • clang + ld.lld + llvm-objcopy/objdump (C:\Program Files\LLVM\bin) — clang is a cross-compiler by construction, so --target=x86_64-elf builds the kernel and --target=i386-elf the bootloader. No cross-binutils needed.
  • mingw-w64 gcc (scoop install mingw) for host tools — tools/mkfs.c needs <unistd.h>/<dirent.h>, which the Windows SDK lacks.
  • make (scoop install make), plus Git Bash's perl/sed/dd/sha256sum.

run.ps1 prepends all three directories itself, so it works from any shell. The Makefile detects Windows via uname -s matching MINGW* and sets WINHOST. Ports (musl/mksh/toybox) are not rebuilt on Windows — they are Linux userland built by configure scripts, already staged in sysroot/, and the Makefile says so out loud rather than skipping silently. Everything is a no-op on Linux, so a Linux/VM build still works identically.

Five latent bugs the move exposed, all real, none Windows-specific — see docs/architecture/kernel-history.md §8 for the two hardest:

  1. kernel.ld named no .ltext/.ldata/.lbss — with -mcmodel=large, LLVM and GCC 13+ put nearly everything there, and orphan placement put them past end, so kinit1(end,...) handed the allocator live .lbss.
  2. uint64 was unsigned long — 64-bit on Linux, 32-bit on Windows (LLP64). Host tools include the on-disk structs, so this would have silently written images with half-width inode fields. Now data-model-aware + _Static_assert.
  3. syscall_entry used %fs:(0) as scratch — that is the TCB self-pointer. GCC's direct %fs:-8 TLS never reads it; clang materialises the TP from it.
  4. _start read argc/argv via register ... asm("rdi"), which is only guaranteed for inline-asm operands. clang read uninitialised stack. Now lib/start.S.
  5. lld needs --image-base=0 for anything linked below 0x400000, and -m elf_x86_64 on ld -r -b binary.

When a symptom moves as you add printfs, stop printing and use the watchpoint. QEMU -S -gdb tcp::26000 plus mingw's gdb (hbreak, then watch) named the offending instruction on the first run after three rounds of cprintf had failed. See schunix-verify-by-driving-shell.