message の編集

* 著者からのメッセージ
-(by [[K]], 2009.01.16)
*** (0) はじめに
-今更ですが、「この部分はなんでこんな風に書いたの？」「こうしたほうが良かったのでは？」という批判に対して、著者が何も言わないのは実は読者の方や批判してくれた人に失礼ではないかと思ったので、ここにＱ＆Ａ風にまとめておくことにします。
*** (1) Ｑ＆Ａみたいなもの
-[Q] ブートローダのアルゴリズムが気にいらない
--[A] ちゃんとフォーマットを解析して、ファイルシステムの仕組みに従ってロードするべきということなんでしょう。そうしたければそうすればいいでしょう。しかし結局、この本のようにharibote.sysがディスク上の先頭にあったほうが起動が速いですし、そうだとすれば苦労してブートローダがFATをたどってもたどらなくても、同じことです。
--この手の意見を言う人は、「1から100までの和を表示せよ」といわれたら律儀に1+2+3+...+100を計算するか、もしくは「せめてn(n+1)/2の公式で計算しないといけない」と決め付けるタイプの人だと思います。筆者はただ「5050」と表示すればいいと考える人間です。・・・もし計算の範囲が100までではなく10までになったり50までになったりと変わるかもしれないのなら、筆者の方法はよくありません。しかし1から100までの和しか要求されないと分かっているのなら、苦労して計算する必要は全くありません。何も考えずに「5050」を表示することが最速かつ最善なのです。
--ちなみにこのように、いちいち計算する必要がないことまできちんと計算するべきだという考えの人は世の多数派で、その人たちが作ったOSはみんなあんなに大きくて遅いのです。毎回同じ結果しか必要ないと分かっているのに、わざわざ苦労して計算するなら、プログラムが長くなって処理が遅くなるのも当然のことなのです。
--もっといいたとえは、毎日学校に行くときに、「500m進んで右に曲がって300m進めばいい」というのが筆者式。これに対して批判する人は、毎日早起きしてまず最新の町の地図を買い、そこから○○学校を探し、そして××アルゴリズムで家から学校までの最短コースを計算し・・・とやります。確かに学校が移転するかもしれないならこの方法しかないですが、それならそのときにプログラムを「500m進んで左に曲がって400m進んだところを右折」とかに書き換えればいいだけじゃないの？というのが筆者式なのです。
-[Q] メモリチェック関数memtest_subは、volatileを使えばアセンブラを使わなくても解決できるのでは？
--[A] その点に関してはその通りです。でもvolatile属性をつけて終わりにしてしまう方法で解決してしまうと、いざというときはアセンブラで書き直す（たとえばコンパイラのバグに悩まされた場合など）みたいな場合に応用がききません。世間の人たちはコンパイラは信用できると思っているようですし、仮にコンパイラのせいで正しいプログラムが動かなければ、悪いのは自分ではなくコンパイラだと考えるようです。しかしそのコンパイラを使うことにしたのは自分自身なのです。問題ある道具を使うことにした自分の責任はどうなっているのでしょうか。
--自分の使う道具には責任を持つべきだという当たり前の考えを少しでも知ってもらおうと思い、筆者はコンパイラの出力を確認するというやり方を紹介しました。そしてコンパイラがどれだけ最適化に苦心してくれているのかを示すと同時に、コンパイラが使えなければアセンブラで書けばいいじゃないかという最終手段を安易に選択しただけです。
--実はコラムでvolatileのことを少し紹介しようと思っていたのですが、締め切りに終われているうちに書き忘れてしまいました。そんなわけで、volatileについて一言も書いてなくてどうもすみません。
-[Q] どうしてFAT12のフォーマットの説明で、ディスクイメージをバイナリエディタで調べたりするの？これはマイクロソフトから資料をダウンロードしてそれに基づいてプログラミングするべきなんじゃないの？
--[A] 確かにFATに関しては基本的にはそれが王道です。しかし自力でOSを作っていく場合、いつかは未知のフォーマットのデータを扱いたいと思う日が来るでしょう。残念ながら現在世間にある全てのデータのフォーマットが詳しく文章化されているわけではないのです。そしてこれからもたぶんそうでしょう。だから筆者としては簡単なフォーマットくらいは自力で解析できるようになってもらいたかったのです。
--本の中ではハードウェア制御など、自力解析ではどこから手をつけたらいいのか分からないものもあります。そういうのは仕方ないので資料から引用するしかありませんでした。だから資料に基づいたプログラミング例なら既に本文中で何度もやっているわけです。そうであれば、自力解析でプログラミングする例もあるべきだと筆者は思うのです。そしてFAT12で自力で分かる部分に関しては、その手順を簡単に示したのです。
--最近のプログラマの多くは、仕様書を取り寄せてプログラミングするのが当たり前だと思っている人が多いようです。仕様書が間違っていて動かなかったら、「仕様書のほうが正しいのだから修正されるべきなのはオレサマのプログラムではなく他の部分だ」とまでいう人もいるそうです。筆者はそういうふうには考えません。動かないのは常に自分のプログラムが悪いのです。だってプログラムは動かすために書くものなんですから。動かないプログラムなんてたとえ10個作っても、動くプログラム1個にはかないません。
--とにかく仕様書どおりに作ればそれで許されるなんて甘えだと思いませんか？仕様書なんて所詮参考にしかなりません（実際仕様書に致命的な誤植のあることは非常によくあることです）。信じられるのは自分の解析だけです。だから最低限の解析スキルは磨いておくべきですし、自力解析で解決できるようなことでさえ仕様書に頼るのはプログラマとして軟弱すぎると思います（もちろん自力解析で誤解してとんでもないプログラムを作ってしまうことはありえます。それはよくないです。しかしこの本の中ではそういう失敗は無いので、その指摘は当たりません）。
-[Q] （上記のように）いろいろ意図があるのは分からないではないが、これはあくまでOS自作入門なのだから、そういうのは封印してもっとOSそのものの話題に集中するべきだったのでは？
--[A] それは確かに一つの方法だと思います。しかし筆者としては、OSを作ることを通していろいろなことに触れることが読者にとってもいい経験になると信じていて、またそれが楽しいとも思っているので、あえてこのような構成をとりました。順当で簡潔にOSの良書を書くというのは、誰か優秀な著者がいつかやってくれるはずです。筆者は考え方が常識的ではないので、たぶんそのような本は書きたくても書けません。だから開き直って、自分にしか書けない書き方で自分なりの方針を貫いて書きました。

*** (2) サポートサイト開設4年目に当たって
-(2009.07.24追記)
-この本が書かれた時代背景：
--この本は2004年ごろから書き始められました。その頃は、掲示板やブログ上で、OSを自作したいという中学生・高校生が何人もいました（10人以上見かけた気がします）。その人たちはOSASKやMonaOSみたいなものを（中間的な）目標にしていました。しかしその人たちの大部分はブートセクタを使ってhelloを表示するプログラムを作ったあたりで、その先をどう作っていいか分からず、結局投げ出していました。
--「30日でできる！OS自作入門」はそのような人たちが再挑戦して、OS開発を再開できるようにするというのを、目的（の一つ）として書かれました。
--当時はOSを作りたいと自分から言い出してhelloを表示するくらいまでいける人たちは、何らかのプログラミングの経験があり、プログラミングが好きで、それなりにはプログラミングセンスがありました。「まあOSを作ろうと言い出すくらいなのだから」という感じです。
--彼らは本当に苦労していました。まとまった資料などは皆無で、結局はLinuxやOSASKやMonaOSなどオープンソースOSのソースから自分の書きたい処理に近そうなものを探してきて、よく分からないままとりあえず自分のOSに組み入れることが最初の一歩でした。当然ですがこんな方法ではたいていは動きません。しかし根気よく試行錯誤していくと、やがて何とか動くようになり、動いたあとで、「なぜこんなふうに書かなければいけなかったのか？」や「ここを改良してはいけないのか？」や「なぜこのツールをこう使うのか？」などを考えていました。こんな方法はひどく非効率に思えるかもしれませんが、しかし当時としてはこれが最短の方法でした。資料が全く無かったわけではないのですが、しかし不親切で理解しにくい上に誤記が混ざっていて資料の通りにやってもうまく行かないなんてことはしょっちゅうで、結局みんな試行錯誤するしかなかったのです。
--「はりぼてOS」は、そんな人たちのために、「とにかく動くサンプルコード」を提供するために開発されました。機能は最低限度にしました。少しでも短いほうがサンプルとしては適切に思えたからです。サンプルさえ手にはいれば、あとはそれを自由に改造することで、「なぜこんな風に書かなければいけなかったのか？」「ここはそもそもどういう仕組みなのか？」を考え始めることができます。
--「30日でできる！OS自作入門」は発売当初から記録的な勢いで多くの人に読んでもらえました。初期の読者は当然上記の想定読者に近い人たちでしたので、読後のレビューは総じて高いものでした。著者も多くの人に喜んでもらえてうれしかったです。
-3年半後の状況：
--評判があまりによかったせいなのか、今では当初は想定もしなかった人たちがこの本を読んでいるようです：
---この本を見るまでOSが自分にとってプログラミング可能な対象だと思ったことのない人。
---そもそもプログラミングの経験がない人。
---この本には「OSとは何か」や「詳細な議論や説明」があると思っている人。
---OSを作るのが大変なことだと感じていない人（ブログとか見るとみんな簡単とか言っているみたいだし・・・）。
--これらの人にとって、この本を読むことはとても不幸なことです。著者は確かに前書きや本文で「OS自作は難しくない」みたいなことを書いていますが、それは「2004年頃にあんなに苦労していたあの人たちにとって」であって、上記のような人たちに対してではありません。
--また、この本では「OSとは何か」や「詳細な議論や説明」なんて書いてありません。「○○だからここはこうプログラムする」みたいな説明を期待してこの本を読んだら、そりゃもう失望感でいっぱいです。これは非常に単純なサンプルであって、そのサンプルを改造して試行錯誤するのに十分な程度の説明しかないのです。プログラムのどの記述も必然性は無くて、一例でしかないのです。正解を示す気なんて最初からないのに、この本には正解がないと嘆かれても困るのです。あなたは気の済むまで試行錯誤して、それで何が正解かを自分でつかみ取るべきなのです。
-このギャップをどうするのか：
--著者としては、この本はこういう意図で書かれたのだから、そのような読者には対応できない・・・と言うべきなのかもしれませんが、しかしそれはかわいそうな気がするので、できればその人たちの希望にも少しは沿いたいです。だから、そういう「分からないこと」があるひとは、[[q_and_a]]や[[impressions]]を使って質問してみてください。自分からは何もしないで、ただ嘆いているだけでは、誰も何もしてあげられません。・・・とはいえ、とにかくこの本はこういう意図で書かれているということも知っておいてください。限界もあるのです。
--そしておそらくは、上記のような人たちでさえ満足できるような本を、誰かが書くべきなのでしょう。それはたぶん[[K]]ではない誰かです。このような時代背景でしか物を考えられない人間ではなく、前人の苦労なんて何も知らなくてだからこそOS自作の本質を客観的に捉えられている人が、きっと適任でしょう。

* こめんと欄
#comment

タイムスタンプを変更しない

* こめんと欄
#comment

テキスト整形のルールを表示する