How Haiku's Interface Kit and app_server Render Native Windows
The message-driven path from BApplication and BWindow to views, drawing commands, fonts, compositing, and input.
Native Haiku applications use Interface Kit classes such as BApplication, BWindow, and BView. Windows and views participate in the Looper/Handler message model; drawing requests and input travel through system services rather than applications painting directly to arbitrary hardware memory.
app_server manages on-screen windows, drawing state, fonts, clipping, and compositing. Applications must respect view locking and thread ownership. Long work on a window thread blocks message handling and makes the interface appear frozen even when the process remains alive.
Use layout APIs instead of fixed pixel coordinates, invalidate only what changed, and keep worker results message-based. Native appearance comes from cooperating with the kit, not copying a screenshot of system controls.
Sources: Haiku Interface Kit, Haiku application programming guide