message
の編集
http://hrb.osask.jp/wiki/?message
[
リロード
|
差分
|
単語検索
|
一覧
] [
編集
|
バックアップ
|
添付
]
-- 雛形とするページ --
A
Akkie
Athlon64X2
Clover
DAsoran
Falcon
FormatRule
FrontPage
Genesis
Help
I
InterWikiName
InterWikiSandBox
InterWikiテクニカル
Jormungand
K
Kebo
Kor_Lee_Hee_Rak
Leaf
Linux
Linux/wako_memo
MOIZ99
MW
MenuBar
OSC
PG_MANA
ReadersOS
RecentDeleted
SKYDASH
SandBox
Sero
Sigle
Source
Triangle_Ld.
Zxcvbnm
advance
advance/CPU
advance/FDC
advance/FPU
advance/NotHariMain
advance/QEMUVGA
advance/RTC
advance/blike
advance/cpu_reset
advance/driver
advance/driver/01
advance/driver/02
advance/families
advance/filesystem
advance/fwrite
advance/hddboot
advance/he86
advance/hints
advance/ipl
advance/kernel
advance/keycode
advance/osselect
advance/smaller1
advance/startup
advnace/smaller2
anzy
aotatsu
banbi-
bluedwarf
bo
bugs
challengers
cybozulabsyouth11
deskmanta
esb02b
faq
faq/advance
faq/asm
faq/c00-03
faq/c04-07
faq/c08-15
faq/c16-23
faq/c24-31
faq/make
faq/others
faq/qemu
guide
guide03
guide05
guide07
hikarupsp
imp_log/0000
imp_log/0001
imp_log/0002
imp_log/0003
impressions
index
k
killer_elf
kota
lea
lea/10_memory
lea/4_color
lea/idea
lea/terms
links
logs
logs/osa_hrb/comments0000
logs/osa_hrb/rumors0000
masa
members
message
mistakes
moge32
moppoi5168
notice
osdevjp
populars
prog_index
projects
q_and_a
q_and_a_2
qa_log/0000
qa_log/0001
qa_log/0002
qa_log/0003
qa_log/0004
qa_log/0005
qa_log/0006
qa_log/0007
qa_log/0008
qa_log/0009
quark
rankings
rule
sakamoto
sasaki
spc09
spcc_30min_os
tatsu
tools
tools/bim2hrb
tools/bin2obj
tools/cc1
tools/edimg
tools/gas2nask
tools/makefont
tools/nask
tools/obj2bim
tools/sjisconv
uchan
uho
updates
violations
wako
white
win64-bit
x
ytakano
ヘルプ
リックス
質問します
整形ルール
本は買ったぞ!持ってるぞ!
練習用ページ
* 著者からのメッセージ -(by [[K]], 2009.01.16) *** (0) はじめに -今更ですが、「この部分はなんでこんな風に書いたの?」「こうしたほうが良かったのでは?」という批判に対して、著者が何も言わないのは実は読者の方や批判してくれた人に失礼ではないかと思ったので、ここにQ&A風にまとめておくことにします。 *** (1) Q&Aみたいなもの -[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
タイムスタンプを変更しない
* 著者からのメッセージ -(by [[K]], 2009.01.16) *** (0) はじめに -今更ですが、「この部分はなんでこんな風に書いたの?」「こうしたほうが良かったのでは?」という批判に対して、著者が何も言わないのは実は読者の方や批判してくれた人に失礼ではないかと思ったので、ここにQ&A風にまとめておくことにします。 *** (1) Q&Aみたいなもの -[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
テキスト整形のルールを表示する