hrhOSの生涯！！！

独自OS「hrhOS」開発ログ
GUIが動くところまで来た

独自OS hrhOS の開発を進めていて、現時点で「GUIが表示され、操作できる」ところまで到達しました。
この記事では、見た目の派手さだけじゃなく、GUIを成立させるためにOS側で何を積み上げたかを、開発ログとしてまとめます。

今回の到達点（3行）

• できたこと：画面にGUIを描画し、マウス/キーボード入力でウィンドウを操作できるようになった

• 成立させた土台：フレームバッファ描画・イベントキュー・ウィンドウ管理（最低限）

• 次に詰まるところ：再描画の最適化、フォント、アプリ実行モデル、クラッシュ耐性

GUIが動く＝OSとして何が揃ったのか

GUIって「描けた！」で終わりに見えるけど、実際は 描画・入力・管理が噛み合って初めて“動く”になります。
hrhOSでは、まず次の3つを「最小の形」で揃えることを目標にしました。

1. 描画パイプライン：ピクセルを出し続けられる仕組み

2. 入力とイベント：割り込みからGUIまでイベントを運ぶ仕組み

3. ウィンドウ管理：複数要素を破綻なく扱うルール

この3つが揃うと、OSとしての手触りが急に増します。

1. 描画まわり：フレームバッファから“UI”にする

1-1. まずは「確実に描ける」最小描画

最初にやったのは、GPUの高度な機能ではなく、フレームバッファに確実にピクセルを書き込める状態を作ることでした。
ここが不安定だと、上の層（ウィンドウや文字）をどれだけ頑張っても全てが崩れます。

• フレームバッファのアドレスと解像度・ピッチを取得

• putPixel / fillRect / blit のような 最低限の2Dプリミティブを実装

• まずは「描ける・消せる・塗れる」を安定させた

そこで hrhOS では段階的にこう進めました。

• Phase A：全画面再描画（動作確認最優先）

• Phase B：ダブルバッファ（ちらつき抑制、描画の一貫性）

• Phase C：dirty rect（無効領域）（必要な範囲だけ更新）

まだ完璧ではないですが、「今後の伸びしろ」が見える形になったのは大きいです。

2. 入力とイベント：割り込みからGUIへ運ぶ

GUIで地味に重要なのが、入力が「途切れず」「順序を保って」「扱いやすい形」で届くことです。

2-1. 入力を“イベント”に変換する

キーボードやマウスは低レイヤではそのまま使いづらいので、OS内で イベント型に整形します。

• キーボード：scancode → keycode（必要なら修飾キー状態も保持）

• マウス：移動量/座標、ボタン押下、ドラッグ判定

• それらを Event { type, timestamp, payload } 的な構造で統一

2-2. イベントキュー：割り込みとGUIを分離する

入力は割り込みで飛んでくるので、その場で重い処理をすると危険です。
そこで「割り込みでは積むだけ」「GUI側で捌く」という分離を明確にしました。

• 割り込みハンドラ：イベントをリングバッファへ push

• GUIスレッド（もしくはメインループ）：popして処理

この分離ができると、入力の取りこぼし・溢れ時の方針（ドロップする？まとめる？）も設計できるようになります。

3. ウィンドウ管理：最小のWM（っぽいもの）を作る