Haiku on ARM: Porting Challenges Without Pretending It Is a Finished Product
Why ARM and ARM64 support requires platform-specific timers, boot, interrupts, drivers, and firmware beyond compiling the kernel.
Conceptual, architectural explainers — how a subsystem actually works underneath.
Why ARM and ARM64 support requires platform-specific timers, boot, interrupts, drivers, and firmware beyond compiling the kernel.
The message-driven path from BApplication and BWindow to views, drawing commands, fonts, compositing, and input.
Why building Haiku is more than invoking a compiler, especially for GCC2 compatibility and cross-host image generation.
How native Haiku applications separate translatable strings from code and format dates, numbers, and time for the active locale.
A system-level view of Haiku networking and why hardware drivers, protocol modules, DHCP, DNS, and applications fail in different layers.
How runnable threads, priorities, blocking, and CPU allocation affect Haiku's desktop and media workloads.
How applications expose properties and commands through the same messaging architecture used by native UI components.
How Haiku represents processes and threads, communicates through ports, and exposes system state to native tools.
How translators advertise formats and let applications decode or encode images and other data without bundling every codec.
The timing and brightness tricks behind classic light guns, their platform variations, and how modern emulators replace a physical CRT dependency.