★☆OSの作り方★☆

考えすぎて夜も眠れません。
謎が多すぎです。

オッス

オラ悟空

>>1
Linuxのソースでも読みなさい。
いやなら不眠症で氏ね

>>1
ブートでつまずいてるんだと思うけど、
HDDからだとアレなんでとりあえずフロッピーから起動するようにすれば？
先頭の512バイトをBIOSが0x7c00にロードしてくれるから、
まずは512バイト以下のへろーわーるどでも書いてみれ。
後ろの2バイトは0xaaddにしといてね。

とりあえずこんな感じかな？

.code16
.text
.org 0x00

.globl start
start:
mov $0x07c0, %ax
mov %ax, %ds

mov $bootmes, %si
call message
mov $newline, %si
call message
call idle
message:
cld
lodsb
or %al, %al
jz done
mov $0xe, %ah
mov $7, %bx
int $0x10
jmp message
done:
ret
idle:
hlt
jmp idle

bootmes:
.ascii "Hello, world!"
newline:
.byte 10, 13, 0

pad:
.word boottag - .
.fill 10, 1, 0
.org 510
boottag:
.word 0xaa55

どんな言語で書いたら一番いい？

アセンブラか・・・

>>5
どうやってコンパイルするんじゃ。

>>7
不可避なごく一部はアセンブラ。
それ以外の一部の不可避な部分はC。
残り大半はJava(藁

JavaOSまんせー
ボクは今日(いや昨日)からJavaOS厨になりましたー。
みんなよろしくねっ\{heart}

C/C++じゃないの？
アセンブルの知識は絶対必須。ブートはGRUBに助けてもらうにしても
他のとこでいるでしょう。

夏休みにOS書いて友達でもびっくりさせようと思ったの？
君には無理だと思うからｵﾅｰﾆしてたほうが言いと思うよ。

>>1
ほい。

http://bw-www.ie.u-ryukyu.ac.jp/~kono/lecture/2000/os/index.htm

結構役に立つと思う。

>>11
友達いないんです・・・

>>11
C++は、ちょいOSにはむいてないと思うナリ。

>>12
見れない

>>15
見れないじゃなくて、せめて試してね。
おれの間違いだったけど。

>>9
普通にコンパイルしれ。
$ as -o hoge.o hoge.s

それからバイナリ抜け
$ objcopy -O binary hoge.o hoge

ddでフロッピーにつっこめ
$ if=./hoge of=/dev/fd0 bs=512 count=1

URLわすれ
http://bw-www.ie.u-ryukyu.ac.jp/~kono/lecture/2000/os/index.html

何気に良スレの予感・・・



1いらないけど。

関連スレ

OSを書くには？
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=988116280

>>20
倉庫にも入ってねぇぞ。　　　　　　

>>21
pizaにあった。

英語読めるんならこれどうぞ
・OSを作ることに関してのFAQ
http://www.mega-tokyo.com/os/os-faq.html

個人で作ってる人。でも1年以上更新ないけど
ttp://www.os-omicron.org/~takano/doc/gomicron/

インラインアセンブルに関して
http://www-6.ibm.com/jp/developerworks/linux/010615/j_l-ia.html

gasのリファレンス
http://www.gnu.org/manual/gas-2.9.1/html_node/as_toc.html

途中から”専”の字が変わってるじゃん…鬱誌

http://2ch.dyn.to/

なんとなくPC互換機メモリマップ

0x000000〜システムRAM（640KB）
0x0a0000〜ビデオRAM（128KB）
0x0c0000〜拡張ROM（128KB）
0x0e0000〜システムROM（128KB）
0x100000〜拡張メモリ
0xfe0000〜システムROM（128KB）

>>16
ナニをどう試せというのだ？
「URLに有りがちな誤記パターンを試せ」という意味だとは一応思うが、
それくらい言わなきゃ「挙動は不定」って奴だな。

>>27
見えないって言ってるやつに、
わざわざそんなこと説明しないだろ？

うざいよ。

>>18 のURL

うぷぷぷ。プロセス間通信だってー。
JavaOS様では、リモートはさておきローカルなら、プロセスの壁なんてうざいものは
「無い」ので、単にObject間通信(単なるメソッド呼びとか)でOK。
同期とか考える必要もないし、手順も超簡単。壁越えしないからパフォーマンスも高いし、
データをいちいちシリアライズする必要もないのでセマンティックギャップも減る。

あ。UNIXerにとってはpipeこそが馴染みのセマンティックだったんだっけ。
あははーごめんごめんあはははーー
別スレにあったような、「データは整数と小数と文字列だけで十分」で
「参照も使えない糞」な世界に順応している、そういう人々なんだもんねー
まぁ頑張ってねー

バッファーオーバーランとか言って血眼になる暇があったら
そもそも絶対オーバーしないような環境を先に作るほうが
よほど前向きだと思うんだけどね。まぁ頑張ってねー

>>28
はあ？なんで？

説明したら見えるようになる(かも知れない)じゃん。

そんなサービスをしてあげる義理は無い、という意味？
だったらそもそもここにナニも書かなきゃいい。

？

なんで、そこまでする必要があるの？

見えないって言われたから、それに対して書きこんだだけでしょ？

>>29
まあ、互換性のない世界を作るのは簡単じゃないからね。
Javaはそのまれな例かもしれないし。

ところでJavaOSってなに？なんかスゲー遅いって聞いたけど。

HoJavaがあれだけ遅いんだからOS全体がなんて話になったら。。。

>>30
つか、話題それてきたからそう言うのはやめよう。
わざわざネタスレにする必要無いし。

おれが悪かった。

>>32
ネタじゃなかったの？
〜OS最高とかいう宗教まがいのネタだとおもってた・・・

>>31
だからさ、ナニを書いてるんだよ？あれじゃ情報量ゼロだろ？
試すってナニを？お百度参りでも試すか？子犬党に投票したら解決するのか？

>>35
だから悪かったって・・・
たしかによくわかんなかったよ・・・

もうやめてくれよ・・・

>>32
一応実在するぞ。過去形かも知らぬが(藁
http://www.sun.co.jp/products/wp/JavaOS/JavaOS.html
あと本もある。
さすがにNativeより(全てにおいて)優るなんてことはないが、
部分的には優ることもある、と書いてあった。

ふつーJavaって、JVMを(ホストOS上で)立ち上げてから、そこにClassをLoadするわけで、
JVMなんていうお大尽なものをアプリが必要になるごとに上げ下げするのが寒い。

ならば上げっぱなしにすりゃいいじゃん？ということだと思われ。
上げっぱなしならいっそのことそれ自体をOSと見なせば、と。
そうすれば却ってプロセス間の壁とかの従来OSで必要と思われてたものが無くなるので
構造もスリムになるし時としてパフォーマンスすら良くなる、らしく。

ところで「互換性のない世界」ってなんのこと？
unixまたはwinと互換性のない世界、のことか？(藁

「C言語の」野蛮なポインタの流儀の…を受け入れてしまったばっかりに、
unix(やその超遠縁のwin)は、色々面倒を背負い込んでいるわけっしょ。

野蛮なポインタを、カーネル最深部以外には許さない、という発想をするだけで
随分物事はシンプルになるんだな、という見本らしく。

けんかをやめてー
わたしのためにー
あらそわないでー

>>37
すげぇ・・・
Sunってやっぱりやってくれちゃうんだね。(いろいろと(w )

そういえば、Javaバイトコードを実行するCPUはどうなっちゃたの？
やっぱり、無理があって消えちゃったのかな・・・

>>39
あるよ。たまに組み込みで使われるよ。

>>40
まじで？


・・・Javaマンセー(藁

専房様に二度ご降臨してほしいであります。

>>37
JavaOS は伝統的な OS の範囲と JavaVM を両方含んだもの。

結局のところ JavaOS でも伝統的な OS と同じ仕事は必要になるわけ
で、その責任をアプリケーションプログラマと OS プログラマいずれ
に負わせるかという差に過ぎない。

JavaOS を以って伝統的な OS の範囲に関する講義を嘲笑するのは、
ソフトウェア屋さんがハードウェア屋さんを嘲るのと同種の馬鹿げた
行為。いいから、黙って勉強しとけ。

http://www.jblend.com/

>>42
降臨とか言われるほどスキルないんだけどなぁ。”專房”だし…

じゃぁヘタレなりに>>5-6について補足。
>>5で”0x7c00”って言ってるのに>>6のコードではなぜ0x7c0なのかというと、
リアルモードのDSレジスタは4ビット左シフトして使うわけよ。
だから後のメモリ参照では0x7c00を基準とできるんだな。
このへんは「はじめて読む486」（アスキー出版局）の130ページを読んでくれ（わらい

知ってる人には当然の知識なんだけど、
最近の若いやつはこんなことも知らないのさ（俺も含めて）。
くだらないのでsage。

>>37
ポインタまんせー

>>43
おいおい。1人のOS作者と100人のアプリ作者の
どっちの「手間」を優先的に考えるほうが世のためになると思う？

全てのアプリでポインタ演算でうんうん悩むのと、
マイクロカーネルの部分でだけ悩むのと、どっちがいいと思う？
まさに怠惰のための努力って奴だよ。

しかもプロセス壁なんか無くなるんだぜ。
空間のスイッチングに伴う処理の(コーディングの)手間と処理そのものの重さの
両方が「いらなく」なるんだぜ。
ハードvsソフト云々という論法が成り立つのは、トレードオフの関係が成り立つときだけだろ。
ある要素が丸ごといらなくなりトレードオフが成り立たないなら、勝負は見えてる。
いらんものをいらなくしただけ。すっきり。

ところでOSを作るスレなんだろ？
じゃあ最下層の汗でポインタ演算でひーこら言う部分の話「だけ」をするのは
ちと不味かろう。

まあ既存OSの一派の紹介に半年を費やすという意味なら
頑張っておけということになるが。

>>46
javaにも「ポインタ」は有るよ(^^;;;;;
ポインタ「演算」を許してないだけで。

>>47
JavaOSはリアルタイム用途には使えないって書いてあるように見えますが、何か？

JavaOS=PC用OSって考えると、
なんかびーおーえすみたいな運命たどりそうだな。

広く普及したOSの例としてWindowsとPC-UNIXがあるがPC-UNIXに関しては
普及する前からUNIX用にアプリが沢山書かれていたっていう事実がある。
だからスクラッチから新たなターゲットに向けて書く必要が少なかった。
Windowsに関しては、んーと、そうだな。資本とマーケティングの力か？ｗ
Win32APIが出だした当時なんて勿論アプリなんてなかった。
Windows95が出た当時だってPC-UNIXを用いる利点としてアプリの多さが
上げられていた。今はかなり増えたけどね。

Javaのアプリが今後もっと増えるだろうとは思うけど、現時点ではまだまだ
足りない。ところでJavaOS向けに書くアプリってなんか独自の書き方とか
あるのかな？既存のアプリをそのまま動かせるのかな？

今OSを作る人ってUNIXの資産をどう活用するかってことをして
なんとか使えるものを作っているし、そこで苦労もしてる。
まったく新しくOSを作るなんてだれも見向きもしないから避けられないこと
なんだけどね。

おもしろそうだとは思うよ。47の言ってることは正しいし。

ところで>>37に張ってあるリンクに書いてあることで、
> Javaプログラミング言語により提供される保護機構によって、
> JavaOSとすべてのアプリケーションは同一アドレス空間で実行することができます。
こんなのがあるんだけど、これって興味がありますな。
こうすることで一つのアーキテクチャでスケーラブルにするってのは
いい作戦だろうね。

ところでJavaOSはなんで廃れていったのかな？
37を読む限りいいことしかないような気がするんだが。
それともC/C++を切り捨てるのがそんなに難しいのか？
今でも取り組んでる人がいるならそれに関するリンクなんか貼ってもらえると
嬉しいなぁ。

OS板
OSの参考書
http://mentai.2ch.net/test/read.cgi?bbs=os&key=996204956

4死ね。

>>47
そうではなく、河野先生の OS の講義に対して「今は JavaOS がある
から、これからコンピュータの専門家を目指す学生に現在の OS を教え
るなんて意味がない」という態度は違うだろ、と言ってる。

全く新しいものを作ろうと意気込むのは良いが、その前に歴史を勉強し
ないと、質の悪い車輪を再発明するだけで終わるぞ。

http://www.imasy.org/~kawai/osask/index.html

オープンソースでいいんじゃない？
ついにファイル読み込み(まだ読み込みだけ)も
できるようになってきたみたいだし。

>>52
4ですが何か？

OSASK作ってる人みたいに何か行動を起こす人がやっぱりいいな。
ここに書き込むことに意味がないとか言うつもりはないけど。
自分の何か作らねば。。。

>>50
詳しくは知らないけど、
x86+winに対抗できないくらいに遅かったからとか、
リアルタイム性が弱くて組み込みにも使えなかったとか、
要するに使い道がなかったのでは。

>>56
OS書こうと思ったら必要とされる知識量が半端じゃないからね。
勉強ばっかりで、なかなかコード書けないから飽きてくる…

>>57
JavaOSで検索かけても出てくるのって殆ど98年ぐらいまでもの
ものばっかり。いつまでもCでアプリ作るのって効率悪いから
いつかは仮想マシンに最適化されたOSって出てくると思うけど、
そんなネタはあんまり聞かない。何でだろう。

ちなみにCEは単一アドレス空間らしいです。
MSが.NETのCLRに最適化されたOSをプランしてるとかそういうの
あるのか？組み込み用途とかで。

OSって
「オマエなんかシラネーヨ」
ですか？

>>58
一から書くのが大変なら、既存の OS に手を入れて遊ぶのもいいと思う。
今だと Linux やら *BSD やら、遊ぶ道具にも、情報をやり取りする相
手にも不足しない環境に、簡単にアクセスできます。

>>23のmega-tokyoのサイト、ｲｲ!!

あげ

>>60
「オレ様専用｣のことです。

おれ的にはここがすき

http://www.execpc.com/~geezer/os/index.htm

OS作るのってどっちかってーとプログラマのロマンな気がする。
実現可能性とか実用性とか、そういう以前のもので。

ＯＳ開発の必需品
http://bochs.sourceforge.net/

Unixライクなお化粧をするツール
http://www.cs.utah.edu/flux/oskit/

姉妹スレ
http://yasai.2ch.net/test/read.cgi?bbs=win&key=994935922

>>66
すみません、乏しい英語力を振り絞って読んだんですけど、
それって仮想的なx86環境を既存OS上で実行できる、ってやつですか？
っていうかもし>>66さんが実際に使ってらっしゃるんでしたら
どんな感じか感想聞かせてほしかったり。

>>69
いわゆるエミュレータというやつでフリーなので愛用してます。
私の場合はフロッピーのディスクイメージつくって動作確認に使ってます。
他のエミュレータはつかったことないですが
すごく簡単でイイと思いますよ。

近代的なOS設計の70%は排他処理とファイルシステムに尽きます。
排他処理のち排他処理。ファイルシステムと排他処理を一緒に
しちゃってるのもあるね。

>>53
>全く新しいものを作ろうと意気込むのは良いが、その前に歴史を勉強し
>ないと、質の悪い車輪を再発明するだけで終わるぞ。

昔のものをも学習しないと駄目だ、というだけならまだ賛同できるんだが、
車輪の再発明は無関係だろう。

全く(というのは大げさだが)違う技術を使うことで、
従来の技術「のうちのある部分」が丸っきり不要になるぞ、
というところが味噌なわけよ。

それとも「歴史の勉強」ってのは、反面教師も含めた話？
ならば納得だ。

「過去に存在した優良なもの」が「今もまた再現する価値がある」とは、限らないっす。
水の国や泥の国では車輪なんか役立たない。あらゆる地面をまず舗装しましょうだなんて
考えるのは、必ずしも常に良策とは言えない。

>>59
もし本当に技術的優位だとしても、
普及って奴はHacker一人もドキュ一人も同じ一人としてしかカウントされない(藁)し、
使い物になるだけの世界(卑近にいえばユーザーランド?)を構築する手間ってのが
それなりにかかるってのは、致し方ない。

まあ、今既に普通に使われている(ホストOS上の)Javaの世界のうち
かなりの割合は、JavaOSってのにも持ちこめるだろう。
言語がJavaであること自体にはあまり関係はないが。(Javaの類似物が少ないってのが微妙に影を落としている)

>>53
OSの歴史を勉強するのに実装まで見るべきものって今ソースコードが公開
されてるものの中ではどれになるかな？

IPStackはBSDで十分

>>72
あまりメタな喩え話をしても仕方ないんで、具体的な事例で行くよ。

OS に関しては企業にも大学にも、研究している人間は山のようにいるわけよ。プロ
セスの「利点」「欠点」に関しても多方面から研究されていて、その成果の一つが
Mach, L4 に代表される Microkernel の実装であり、JavaOS なわけだ。

論文をあさると分かるけど、だいたい自分が思いつくようなことは、どこかの研究
者が思いついている。それが普及していないのはなぜかといえば、もちろん商業的
な理由もあるが、多くはアイデアを実現するにあたっての技術的な困難や、研究を
勧めた結果として当初の見通ほど「目標達成に役に立たない」ことが判明した、と
いうのが大部分。また、既存の OS にアイデアの一部が形を変えて実装されている
こともある。

質の悪い車輪の再発明と書いたのは、こういった研究成果を勉強せずに自分の頭だ
けで考えると、すでに可能性が無いことが分かって捨てられたアイデアを「これは
誰も考えていない新アイデアだ！」と思ってのめりこんで時間を無駄にしたり、す
でに実装されれているアイデアを縮小した形で実装しかねないから。

現在の OS に限界を感じていて新しい OS を目指そうというのなら、少なくとも既
存の OS について熟知して、それが提供する機能と背景を押さえ、さらに現在の研
究状況を知るのがスタートライン。そこまでやらないうちは、思い込みで物事を言っ
ている素人さん扱いされても仕方ないだろ。

L4はなんでいくつも実装があるわけ？
関係なくてごめん。

>すでに可能性が無いことが分かって捨てられたアイデアを「これは
>誰も考えていない新アイデアだ！」と思ってのめりこんで時間を無駄にしたり

「誰も考えてないアイデア」だなんて(今回ここでは)誰も言っていないと思うが。
UnixおよびJavaOSという、どちらも既存のものを、ある面について比べてただけじゃん。

それに、目標達成といっても、そもそも「目標」は何なの？
オリジナル開発者とそれ以外では「目標」が違うかも知れないんだから、
それについてはむしろ、オリジナルの論文をなんぼ当たっても書いてないよね(^^;

>>75-77
どうも、話が抽象的な方向に逸れるな。メタな議論は fj.news.usage あたりでや
ることにして、具体的な OS の設計・実装の話をしてくれよ。

ちょっと話が逸れるが、リサーチ的な作業に対する報告書だと

- 現在の問題点
- 達成すべき目標
- この文書で提案する改善の具体的内容
- それで、結局、何が達成できて今後の課題は何なのか

を書いてなかったらゴミ箱直行だぞ。理系の研究論文に限らず、コンサル屋さんと
かＳＥさんが出してくる提案書の類とかも同様。

>>78
それをいっちゃぁ、おしめぇーよぉ。

>>78
>具体的な OS の設計・実装の話をしてくれよ。

なんで人民がチミの御要望にこたえないとならないのか具体的に説明してください(藁
2chを論文や提案書と比較する意味、有るの？
ここの誰一人として、チミを恩師や顧客として接しているわけじゃ無かろうに。
Just For Funって、知ってる？知ってる？

「話が逸れる」ねえ。本当に逸れてるな。
チミこそ最もメタ議論(議論メタ)に逝ってしまっている…
いや違うか。メタですらないな。学校や企業の話をしたいなら、単なる板違い。

>リサーチ的な作業

誰が2chでリサーチしてるってんだ(劇藁

>>79
そうです。おわってます。

78はカノジョとかに仕事の話しを、得々と話してそうだな

たまにはアゲ

MINIXのソースすら読めないようなやつばっかり。
晒しアゲ

これはここかも知れない・・・

MIPSでタスクスイッチ部を作ってみたのです。

大抵のMIPS本には、例外が発生したとたんに
実行プロセス／スレッドのローカルスタックへ
現在のCPU・コプロセッサのレジスタを退避してから
カーネルのスタックをロードしてくるのですが、

退避領域をあらかじめ作っておいて、
そこへ使用中のレジスタをスタックすると言う方法はダメなんでしょうか？
ローカルスタックがオーバーフローしないから、
こっちの方が良いかと思うのですが・・・

>>80
だから、メタ議論と煽りは他でやってくれよ・・・

>>84
工学板の人だっけか？

>>84
MIPS は詳しくないので外してるかもしれないが、その「退避領域」に
アクセスするために、まず退避領域のアドレスやら何やらをレジスタに
読み込む必要があって、と鶏卵の関係にならない？

>>86
そです。こちらでは教えて君で失礼します。

>>87
一応、コンパイラ・アセンブラで
なんの前触れも無しに使用すると怒られるカーネル専用レジスタが2本あって、
これの片方にスタックポインタを入れてあります。

スタックには合計30本の32ビットレジスタと、掛け算用の32ビットHi/Loレジスタ、
コプロセッサにある5本の32ビットレジスタ、
合計で148バイトを保存する事になります。

2本目は、MIPSにはx86のretに当たるようなリターン命令は無くて、
レジスタ相対ジャンプ命令で例外発生元へ戻るようになっています。
そのためのアドレスの指示のために破壊されます。

ちなみに他の本では使える方にはプロセス／スレッドのハンドルが入ってます。

でもプロセス・スレッドのハンドルを入れておいても
レジスタをカーネル用に構築すれば何時でもメモリから読めるので
わざわざ入れておいてもそれほどには役に立ちそうにない・・・？

>>84　その方法だとスレッド毎に　退避領域が必要になりませんか？
　　また、スレッドに戻る時にどのスレッドかによって復帰領域を別けなければいけません
　　スタックにしておけば、スタックポインタの切り替えだけで済むので多少楽なのでしょう

>>89
有難うございます。

一体今はどうやっているかと言うと
1.例外が発生したら、まず退避用スタック(=カーネルスタック)に
　全部積んでしまう。
2.ディスパッチャはタスクを退避したい場合、退避用スタックと
　TCB(タスクコントロールブロック)に保存されている内容を入れ替える。
3.例外復帰時に、移動のありなし関係なしに、退避用スタックを復元する。

てな、感じなのです。

仰られる通り、たしかにTCBにも
大きな保存領域が必要になってしまうので厄介ですね・・・

例外発生時に、TCBには保存に利用したスタックへのポインタを
記載するようにすればひょっとして速いって事でしょうか？

>>90 そのCPUに応じた方法を考えなければならないと思いますが、

速さが目的なら例外時でもユーザスタックに全部突っ込んでしまってから
スタックポインタを切り替えた方が　管理対象がユーザスタックポインタ
だけになるので最速でしょうね

>>89=91
有難うございました。
TCBの実装を書き換えてチェックして見ます。

>>84-92がこのスレを救った！！

>>66 = >>70
今ディスクイメージ作ってbochsで起動させたらできました！
今まではほんとに再起動とかさせてたんで、開発効率が大幅にUPしそうです。
良いアイテム教えてくださってありがとうございました。

これからリアルモード→プロテクトモードに挑戦してみます。

良スレage

CPUは決めた(移植性重視でもいいが)。
ブートもうまくいった。

次はいよいよ、OSのアーキテクチャを選ぶ番だな!!!!
Unix風？Multics風？それとも…

#JavaOSを選ぶと神の御加護がボーナスとして与えられるけどな!!!!

>>94
そんな非本質的なところで油売ってないでサクっとGRUBを使いなされ。
http://www.gnu.org/software/grub/grub.ja.html

>>97
GRUBは愛用してるんですけどね。
オリジナルのカーネルの起動方法がわかんなかったんで
結局自分で書いてるんですが。
＃LinuxのソースコピペしたらLinuxって誤認識されるし

宣伝ついでにやりかた教えてくれ。
もしくはドキュメントある？

>>98
infoを読むべし。
サンプルもtar玉のどっかに入ってるはず。
てか、ドキュメントすら自分で探せないくせにOS書こうなんざ笑止。
OSなんか書いてないでもっと基本的な所からやり直した方が良いと思われ。

>>99
すみませんね。ちょっと興味があってかじってるだけだから。
基本的なことからやり直して、他のOS制作に興味を持ち始めてる人たちの
足がかりになるようなもんができたらまたレスさせてもらうよ。

>>93 >>100

君はまだ甘いな。既存の道具の具体的な話が連発されるようになったら、
却って危ないんだよ。スレ救ったどころの騒ぎじゃなく、実は
専門家(藁)しか会話できない世界に突入しただけなんだよ。
あげく、ちょっと弱い人はdoc読め攻撃を食らって撃沈される。

どうだ？君は今幸せか？スレが救われた(?)のと引き換えに君自身が辛くなったことに、満足できるか？

>>100
そんなレベルまでレベルアップできた暁には、ここに来る必要は無いと思われ(藁

なんか叩かれてるよ（；´Д`）ﾊｧﾊｧ
ただのコンピュータ好きの専房なのに…

>>101
来る必要はないっていうか、そんなレベルまで行った頃にはもうこのスレ無いと思うけど（藁

がんばれ、おれの知らないことを書いてくれる、または書かれるきっかけを
作ってくれてるキミを応援してる。＞羨望

なんとなくリスト
http://sourceforge.net/softwaremap/trove_list.php?form_cat=144
http://www.osdev.org/cgi-bin/projects.cgi
http://www.cs.arizona.edu/people/bridges/oses.html
http://tunes.org/Review/OSes.html
http://www.d1.dion.ne.jp/~r_high/GeekOS/indexos.html

専房さんがつくってるものみてみたいな

>>102
いや、叩いた対象は君でわない。周囲だ。
安心してくれたまえ。

>>103
2chで感動するなんて俺ももう終わりかな･･･
ありがとう。

>>104
俺がコード書けるわけないでしょ！
せいぜい既存のソースを丸１日かけて10行読む程度！
でもobjcopyとかobjdumpとかldの細かいオプションを知るたびにドキドキするんで
そのうちなにかやるかも。

>>105
安心はいらないです。
常に緊張感もってやっていきたいっす。