hikarupsp

まずは自己紹介

• 名前：hikarupsp(hikaruは本名)
• 誕生日：1996年4月p日(pは素数)
• 現在新宿区在住

理科とコンピューターを好む。

ちなみに(理科>コンピューター)である。

しかしOSと理科のどちらをより好むかは未定義である(おい)。

ゆえに、制作中のOSの名前がCHNOSProjectになりました。

CHNOSProject

「30日で出来る!OS自作入門」の内容を基にしながら、できるだけコピーアンドペーストを行わないで独自の改造を加えていきます。

現状　rev.318現在

できること　

• メモリ管理
  • しかし、つい先日重大なバグを発見&修正…大丈夫なのか？
• マルチタスク
• RS232Cシリアル通信（送信のみ）
• キーコード取得
  • カーソルキーなどの拡張キーコードも認識します。
• 仮想86モードの利用
  • これを利用して、VBEの切り替えはプロテクトモードで行っています。
    
    なので、画面モード番号は決め打ちでなく、起動時に取得した中から選択することができます。
• VBEを使用した多色対応
  • 8, 16, 32ビットに対応。
• シートの階層化及び自動色変換、透明色対応
  • シートを入れ子にすることができます。
    
    また、自動色変換は、たとえば8ビット画面モードを利用していても、32ビットシートを利用することができ、リフレッシュ時に自動で減色されます。対応しているビット数すべての相互変換ができます。
    
    透明色は、任意の色番号を透明色に指定する方法と共に、32ビットシートでは、最上位バイトが0xffである場合は透明色として扱います。
• QEMU とBochs とMicrosoftVirtualPC2007(そしてたまに実機)での動作を確認。
  • しかしエミュレーターはやはりエミュレーターでしかない(後述)。実機で動かなきゃだめなんだ。

できないこと（やりたいこと）

• フロッピーディスクのBIOSによらない読み書き
• タスクの優先度管理
• サウンド対応
  • ビープ音でMidi再生はそう遠くない(以前のバージョンで、適当だが一度実装したことがある)。
• ページングの活用
• 半透明色の対応

以下、適当に書いた計画案らしきもの。

CHNOSProject (案)

• 命名理由 C,H,N,O,S,P それぞれは、元素記号で炭素、水素、窒素、酸素、硫黄、リンを表し、これらを組み合わせることにより、多くの有機化合物を創り出すことが出来る。
  
  このことから、ユーザーの目的に応えられるように自ら進化していくOSを目指して命名しました。

• 構想
  プログラマーにも、ユーザーにも、OSをOSと感じさせずに、まるで人間を相手としているかのように分かりやすく、快適な使い心地を実現する。
  • 具体例
    • 分かりやすいシステム操作、エラーメッセージ、ヘルプ
    • より体感的な操作を実現 重い処理の時はそれなりの早さを、軽い処理は徹底的に無駄を省く
    • システムはどんな場合も必ず上位に立ち、制御を失わない
    • プログラムのインストールという概念を無くし、削除はフォルダごと捨てれば簡単確実・再起動不要
    • エラー、バグ、ウイルスに負けない
    • 修復不能に陥っても、最低限の機能での動作を保証(物理的問題は例外)
    • どのOS、どのプログラムとも確実に互換性を保つ
    • ハードウエアに合わせ、負荷を掛けすぎない

実現までの道はまだまだ遠いですが、よろしくお願いします。

更新は、主にsourceforge.jpで行うので、たまに見に行ってもらえると嬉しいです。

エミュレーターのエミュレーション能力不足…

エミュレーターは便利です。そして素晴らしいソフトウエアだと思います。

しかし、やはり実機や仕様と挙動が異なる場合が多々あるようです。

そして時にそれは、開発者達を惑わせます。

デバッグ例外に関すること

デバッグ例外は、CPUに用意された便利で強力な機能の一つです。

指定されたアドレスのコードを実行したり、またはデータとして読み書きを行ったり、はたまたIOポートとしてアクセスしたときに、例外を起こしてくれます。

これは、メモリがいつの間にか破壊されていた！という心霊現象のようなバグを解決するために非常に有効です。

#ええ、そうですとも。まさかメモリ管理システムがメモリを破壊していたなんて、思い至りませんでしたよ（涙）。

…ということで、その素晴らしい機能を使ってデバッグしようとしていたのですが…。

1.QEMUとBochsではデバッグ例外が起きない

いきなりこの関門にぶち当たってしまいました。

どうやら検索したところ、QEMUはKQEMUという高速化モジュールをインストールしなければデバッグ例外が使えないようです。

Bochsに関しては、「エミュレーション速度は遅いけれど例外の報告は正確だから！」ということで重宝していたのですが、動きませんでした。

もしかすると、自分の設定ミスかと思い、VirtualPC2007で実行してみました。

すると…出ました。デバッグ例外。

これで一安心、と思いきや、次なる関門が待ち受けていました。

2.MicrosoftVirtualPC2007ではリターンアドレス(EIP)の指す命令が仕様と異なる

今回は、ある特定のアドレスにアクセスした命令をすべてリストアップしたかったので、ブレークポイント例外が発生しても、情報を確認後、実行を再開させたかったのです。

ということで、「紙に印刷したらきっと分厚い」IA-32 インテル® アーキテクチャソフトウェア・デベロッパーズ・マニュアルを参照して、例外ハンドラーを実装しました。

このマニュアルが言うには、私が今求めている、指定アドレスへの書き込みに対するブレークポイント例外が発生した時、

「プロセッサは、このアクセスを行った命令を実行した後に例外を発生する。したがって、これらのブレークポイント条件によってトラップクラスの例外が発生する。」

「トラップの場合－レジスタCSとEIP にセーブされている内容は、その例外を生成した命令の次の命令を指す。」

つまり、単純にIRETDすれば、実行を再開できるはずだったのです。

しかし…VirtualPC2007は

「例外を発生させた命令自体を指すEIP」

を保存していたのです…。

なるほど、だからあんなに繰り返しシリアル出力にデバッグ例外の発生が記録されていたのか。

…しょうがないので、こうしました。

1. .mapファイルと.lstファイルを調べて、「例外を発生させた命令」が何バイトで構成されているか調べる。
   
   ->その命令はMOV　DWORD [EDX+EAX*4],EDI　= 89 3C 82 = 3バイト。
   
   つまり、次の命令は「例外を発生させた命令自体を指すEIP + 3」にある、ということです。
2. ということで、デバッグ例外ハンドラー内部で、EIP+=3とするようにしました。
   
   当然、3バイト以外の命令も例外を起こす可能性があるので、あくまでも緊急措置でしたが…。

これでやっと、メモリを破壊していた犯人が…え？Memory_Allocate関数？

ということで、結末は先にお話しした通りです。

• わかったこと
  • エミュレーターは完全ではない
  • バグは根本的なところに潜んでいる
  • それでもやっぱりエミュレーターがなければ解決できなかった->エミュレーター最強！

…そもそもバグのあるコードを書いた私がいけないんですけどね…。

ということで、めでたし、めでたし。

hankaku.txtにカタカナを！

hankaku.txtに、半角カタカナを追加しました。きっと作るのは面倒だし、はりぼて系のOSでは使えると思うので、ぜひ使ってください。
http://keihanna.dl.sourceforge.jp/chnosproject/45774/hankaku.txt
＊右クリックして、「対象をファイルに保存」を選んでください。
適当に実装したので、文字が読みづらいですが…。
気に入らなかったら、改造しましょう。そのためのオープンソースです！（笑）
ライセンスは、KL-01とします。

352ページのコラムについて…

ある日、かの緑の本を読み返していて、352ページのコラムに、

「左シフト+右シフト+ASDF」は入力できない！！！！とあったので、試してみました。すると…

QWER UIOPASDFGHJKL BNM（空白は、入力できなかった。）

つまり、TYZXCVが入力できませんでした！

なぜ、こんな中途半端なんだ…。

（使用したコンピューターは、SONYのVAIO、VGC-LJ91Sです。）

リンク

はりぼてwiki内のページ
http://hrb.osask.jp/wiki/?hikarupsp

sourceforge.jp内のページ
http://sourceforge.jp/projects/chnosproject/

sourceforge.jp内のプロジェクトWiki(技術文書などを書いてあったりします)
http://chnosproject.sourceforge.jp/wiki/