cross-platform-guidelisted

# Cross-platform / portability Guidelines How to make native C/C++ software portable across operating systems and targets by concentrating every OS dependency behind a thin abstraction, porting one backend at a time, and reaching new targets including the web and new input hardware. The renderer architecture itself lives in gpu-rendering-guide (and gpu-rendering-vulkan-guide for one API); build-system mechanics live in cmake-guide; the C dialect's per-platform file-naming in c99-opinionated-guide. ## Requirements - A codebase where OS access can be (or already is) funneled through interfaces, not called inline throughout app/engine code. - A build system that can select one backend translation unit per target and define per-platform macros. ## Essentials - **One interface for all OS calls** - A function-pointer struct (or build-selected header) per concern; callers never `#ifdef` or call an OS API directly, see [references/platform-abstraction-layer.md](references/platform-abstraction-layer.md) - **Stub, then fill, in interactivity order** - Window → input → OS services → audio; the program links against stubs from hour one, see [references/porting-strategy.md](references/porting-strategy.md) - **The web is a backend with hard constraints** - Cooperative main loop, async I/O, GL ES mapping, 32-bit pointers, see [references/web-wasm-builds.md](references/web-wasm-builds.md) - **Devices are a backend too** - Enumerate, probe, poll non-blocking, map by code, behind the inpu