OSを自分で作った奴いっか？

ここにいるプログラマーの中で
完全オリジナルのOSを
自分で作って自分で使ってる
天才的な奴いっか？
いたら話聞かせてくれや

Unix板逝ってみれ

野球ヲタﾜﾗﾀ

http://ime.nu/www.baseball-lover.com

はい終了

貴様のいうOSの定義を述べよ>>1

技術的な話を聞きたいのならム板かうに板が適当と思われ。
そんな大それたテーマをここで聞く訳が無いので、そういうものを
作れる奴と雑談をしたいだけだろうから、ここが適当かと。

問題はそんな奴がここにいるかどうかだ。

>>1

OSの意味、分かってる？
かなり恥ずかしいことを書いてるよ。無知なことは良く分かったけど...

>>7その位知ってるわ！！！

>>8
で、君が訊きたい事は>>6の通りでいいのか？

>>7DOSやエクスプローラみたいなもんやろ

>>1
氷魚の爪の垢でもなめてろ

>>10
とりあえずその解釈でいいや。

で、君の言う「ＯＳ」がどんな仕事をするのか解っているのかな？

>>11わからんことわざ出すなやオッサン

>>12周辺機器をまとめるドライバの管理をしたり
ファイルの管理等をする
ソフトを実行する

そろそろ逝くわ
じゃ！

>>1
とりあえず、プロテクトモードからリアルモードに、
またその逆をやるアセンブラコードを書けば...

ＳＯＳ

>>17
懐かしいなー。

Windows NTを作るのに8年かかったらしい。

Windowsは386べったり。
どんなにパフォーマンスが良くても、
設計的に誉められたもんじゃない。
というこでおれが新たに設計する。

期待してまってろよ。

とりあえず、割り込みまでは実装した(ついでにシリアルI/Oも)。
次はマルチタスクかページングを実装しようとしてるが、ここ１ヶ月進展なし。

UIと混同してないだけでも誉めてやろうよ。
あとはコンパイラとハードにどれだけの知識があるかだな。

>>20おいおいここの1は俺だよ偽者君
さっきは飯を食いに1度逝ったけど
戻ってきてみりゃきさまぁ
勝手な事すんな！

>>22
コンパイラよりもローダー(とリンカ)の知識のほうが重要です。

>>14
それでよければ２０個ばかし書いた

仮想メモリを考えている。
UVM,MachVM,JVMなど色々あるみたいだ。
もう少し調査が必要だな。

優良スレの予感。

さらに、進捗報告が滞る間に厨房が流れ込んで糞スレになる予感。
糞スレになるよかは沈んで>>1がたまに進捗報告する方がいいな。
応援する。がんばれ。

>>25
あげ阿蘇(w
漏れも１０本は書いた

>>27
なんで時間が少ないんだ？

>>29
そのロジックが理解できないとＯＳなぞとてもとても

おれOSには同期I/Oしか認めん

>>31
全く的外れ、めでてーな

スケジューリング

>>26 仮想マシンじゃ．．．。

おれOSはこんないい加減な時間管理はしないぜ

おれOSは完璧なリアルタイムスケジューリングを成し遂げてみせるぜ

>>36
富士通となら、きっとできる（ｗ

まいくろあいとろんじゃだめ？

なんでファイルシステムが話題にならんのだ？

Ｏｈ！　Ｙｅｓ！！

>>39
OSといえばスケジューリングが一番重要な一つでそ。
ファイルシステムは別に必ずしも必要じゃないじゃないの？

>>41
そうか・・・21世紀だし、そうかもしれないな。

あ〜、お前らぜんぜん駄目。
お前らがウンチクたれてるのは前世紀のOSの話だ。
ネットワーク全体がOSのリソースとなった今、ファイルシステムだの
スケジューリングだの古臭いこと言ってるオヤジにゃOSなんぞ作る
のは無理だ。
逝ってしまいなさい。

ファイルシステムはネットワーク全体がリソースになっても
必要ですが、何か？

>>1 >>>7DOSやエクスプローラみたいなもんやろ

エクスプローラはOSじゃねぇ　シェルだ。

分散系の次世代ＯＳは、ファイルという概念は、ありません。
多分、二次的な表現としてのファイルという概念は人間のために用意するけどね。

隣のコンピュータのどこに何のファイルがあるかなんて、管理不可能。
しかも、複数の目的の違うコンピュータ間での同一名称のファイルのブッキングなんて、馬鹿じゃん。

>>43
現在のコンピュータのハードウェアではファイルシステムや
スケジューリングは必須ですが、何か？

>>46
低レベルI/Oがなくなるわけじゃねーよ。

>>48
やっぱそうですよね？
ＯＳのほうで一切合財ひきうけて、プログラマやアプリが気にしなくて
よくなるというだけで・・・・
先輩が46みたいなことを言ってるんです。でも必要なときは探せばそういう
APIやインターフェースあるんじゃないかと思うので。

>>47
「コンピュータ」とか纏めちゃてる時点でもう駄目。
お前だってファイルシステム無し、まともなスケジューリング無しの
環境見たことあるはずだ。
>>1よ ム板にゃこの話題はむかねえよ。。。

あ、昔ながらのディレクトリ構造に良く似た、構造ってのが生きのこるかもね。
まあ、UNIXとかのリモートリンク型のディレクトリの発展系かな？
違うのは、エントリーそれぞれが、物理的な構造と対応していないって感じ。

平たく言うと、連想記憶型ディレクトリ構造。
つうか、サーチエンジンにユニークキーを付加したような感じかな？

自分の保存したデータが、どこのコンピュータのどこにあるかなんて、知らなくても良い使い方と、
厳密に指定できるやりかたが、両方記述できるシステムが出て来るんだよ。

>>50
> お前だってファイルシステム無し、まともなスケジューリング無しの
そりゃ OS じゃないだろ…

OSの意味知らない人ハケーン。

ファイルシステムなんて飾りです。えらい人にはそれがわからんのです。

召集召集！！富士通/PFU/日立/NEC/オムロン/SHARPのOSプログラマの方はこちらですー！！

>>52
ファイルシステムがないからといって
不揮発情報を収めるレポジトリがないわけじゃないよ。

各プログラムの命令実行時間の管理としてのスケジューリングは、
さすがにOSとしてつけててほしいけどね。

もうこれは坂村先生を呼ぶしか。

>>57
危険だから止めなさい(W
年寄りの出番はねえよ。

>>57,58
高田先生召喚だよ。

今はＲＴＯＳの上にＲＴじゃないＯＳを幾つものせるのが
おもしろそうだよ。

>>59
高田先生は豊橋にいくと気軽に会える機械があるという事実。

つうか、日本に２人しかいない事実

やっぱり助教授はADなみの扱いだという事実。

>>62
豊橋って、助教授が教授並の振る舞いを許されてなかった？
7系だけか？

Linuxはサブシステムとして活用させて頂きます。

サブが無いと存在があやういOSがあるという事実。

>>61
http://www.itron.gr.jp/list-j.html

実装できなくてもOSを作った気分になれるという事実。

市販車はμITRONなのにF1はOSEKの可能性があるという事実。

>>67
>>43のことか？
OS作るって泥臭い仕事だから、素人にはお奨めできない。
両刃の剣。

>>69
残念違いました。
直前の話。

OS作ったって人見つけたYO!!
http://pc.2ch.net/test/read.cgi/prog/1018361057/204

モノシリックカーネルとヌカス馬鹿が多いという事実。

物知りっく

以前、ゲーム会社に勤めてたときに作ったよ。MS-DOSもどき。
あの程度ではOSといいませんか、そうですか。

>>71,72
ﾜﾛｰﾀ

>>75
ﾛﾘｰﾀに見えた俺は逝って良しですか？

46がどんなペーパーを読んでデンパに感染したのか気になる

PC-98べったりなOS?でよければ何本か書きましたが、何か。

最近はPentium搭載組み込みボード向けのRT（リアルタイム）OS
書かされてますが。

別に、OSなんて時間と根性とCPU(アセンブラ)の知識さえあれば
誰でも書けると思うけど･･･？
まぁ、IPLの解析も出来ないような素人にはお勧め出来ないが･･･

>>78
IPLってなんですか（汗
検索してもそれらしいのが引っかかりませんでした

>>79
イニシアルプログラムローダー

>74
MEGA-DOS？

>>79
Initial Program Loader

IPLも知らないプログラマって結構居るのか？

Winｴﾑｴｸｰｽで
「こいつのダウンロードだけ異様におそくしてやりたい」
と思ったヤツは
「スケジューリングなんてネットワーク基調のP2Pでは不要」
なんてこと

ぜったいにイエネーダロ　バーカ

PCで言えばブートローダーがそれになるんですか？ですか？>>79 >>82

>>85
BIOS

>>83
たとえば>>85
AT互換機しかしらん人間は、たいていブートローダーって言葉しか知らんよ
というか、ブートローダーという言葉すら知らん人間の方が多いよ

X.25交換機のOSを作ったことがあります。設計は50%、製造は10%ぐらい担当。
もちろん、シェルなどというものは存在しません。仮想メモリもありません。
ディスクもメモリも固定アドレスに割り付けます。

ブートローダーにシーケンスが渡るまでということですね。
分かりました。

何か、レスが付いてると思えば･･･
DOSだと、IPLってディスク上(Sector#1,Track#0,Head#0)にあるやつを
指すよね。

ブートローダーをIPLと呼ぶ場合もある・・・

grubをIPLって呼んでもいいんですか？

方言というか、人や本によって言い方違うから･･･
とりあえず、漏れはブートセクタの中身と言いたかった
>>92
grub??

なんだかんだで盛り上がってるじゃないか。

未来のOSなんて話してるやつがいるがプロトタイプの一つでも作ってから言え。
それが無理なら足りてないものがなんなのか明記しろ。ﾃﾞﾑﾊﾟはOS板に帰れ。

>>95
最近の保護モードで動作するOSが、ROM BIOSをどのように扱っているか
教えてください。
仮想8086ﾓｰﾄﾞで動作させるのか、或いはﾄﾞﾗｲﾊﾞが直接I/O叩いているのか･･･
正直、どちらにしようか迷っています

こんなんで、ｲｲ？

IOをサブシステムと言ってのけるのは流通だけで飯が食えると
思ってる某国を彷彿させますな。

あーあ、レベルの低い話ばっか・・・

>>98
藁藁
ごめんよ。漏れがレベルを下げていたようだ。
そうだね、君とはもっとレベルの高い話がしたいﾈｪ(藁藁

>>97
この間、oskitの新しいのでたからその話をしよう。

>>778
結局、貧乏なのでH8TinyでOSもどき作ってます。
でもスケジューラを実装した時点で力尽きました。

Z80でマルチタスクOS作ったことある。
結構簡単だったけど、価値はなかったというか、
アプリそのものがブートする仕組みじゃないと
やってられないという時代背景。

>>102
は、マルチタスクの意味を誤解していると思われる。

海外向けの昔の商品だけど、BIOSしかないのに営業が勝手にOS搭載と称して
商品を売っていたのは恥ずかしかった・・
やみちくれぃ。

今度はμITRONベースのスケジューリングと、アプリケーションやドライバの
ロード機構、ファイルシステムを載っけたので堂々といえるけど。

面白いこのスレ。もっと OS の話きぼんぬ。つーか、OS 例えば
Windows や Linux のようないわゆる Modern OS ってどう書けば
いいのかな。ソースを読めって言われそうだけど、まずはどこから
始まってどこに続いていくものなのか。i386 向けならまずブート
させるところからだよね。ブートするってのも、どこまで行ったら
ブートしたと言えるのか分からないし。

どなたかこの辺で概略きぼんぬ。

「はじめての486」を読め

「はじめての69」

>>103
ゲームは大昔からマルチタスク実践してたけど、何か？

>>103
はれ？？なんで？
ノンプリエンプティブで複数のプロセスが
動作するようにしてたんだけど。

>>105はとりあえずこれよんどけ。
http://www.linux.or.jp/JF/JFdocs/readkernel.html
多少は参考になる。

http://www.personal-media.co.jp/whats_new/press/011026_itron40.html
取りあえず日本人ならこれを読まないと。ｵﾚﾓﾅｰ

>>108
君は、タスクの意味を誤解しているのは明らかだが、何か?

>>109
あなたも誤解してますね。

試しに、君らの言ってるタスク/プロセスの定義を言ってみ?

タスクとかプロセスなんつーもん、
汎用の定義でもメトリックでもないだろ

実装上の仕様　ないしは便宜的なもんだろあんなの

>>112
ファームではタイマ割り込みでタスク（のようなもの）を強制的に
切り替えていって、各タスク内ではその割り込み時間内でできる処理だけ
行って次に呼ばれたときに続きをするための情報だけグローバルなり
スタティックなりに保存しとくっていう形でマルチタスクのような
動きをする C のコーディングは常套手段だったけどなぁ。

的外れな事言ってる？

>>114

いわばここがコンテキストになってて
＞次に呼ばれたときに続きをするための情報だけグローバルなり
＞スタティックなりに保存しとくっていう形

いわばここがスケジュールポリシーがないけどスケジューリングになってて
＞タイマ割り込みでタスク（のようなもの）を強制的に
＞切り替えていって

で、動くものがある、と。

十分じゃないですか？

>>115
あ、なんか嬉しいな。レス＆解説どうもです。

タスクが発生した時にそれを登録するテーブルを設けてたんだけど、
スケジュールポリシーってそれの事なのかなぁ。それとも優先度の事
なのかなぁ。ウォッチドッグとかは最優先なんだけど。

質問ばっかでごめんね。

PC98時代のゲーム作ってた奴は、簡易モニタはみんな作ってるよ。

> 名梨産
そのマイコンにプログラムローダ付けたら
立派なマルチタスクOSだと思うんだけど。。。

月曜の朝からマ板といいム板といい濃いですねｗ

>>116
スケジューリングポリシーで意図したのは、、、
うーん、優先度を決めるときの決めかた規則ですね。
（solarisしかそーいういいかたしなかったかも　スマソ）

リアルタイム系の場合は、どれも優先したいしキッチリ時間守らせたい、
けど緊急停止系の処理が入った時は
「そいつ死んでも動けゴーゴー！」
みたいなのありますよね？
それもまたポリシーともいえます。
単にインターバルタイマーで一律コリコリ動かす場合は
ノンポリ系（？）スケジューラー、でしょうか。　昔BASICなんかでもありましたね。

>>117
昔のゲームプログラムは、ある意味で究極のリアルタイム系ですから・・・

画面のリフレッシュレート待ちしたり、
ジョイスティックポートがトリガーになって動作する処理があったり、
大量のビットマップデータのスクロール、マージ、消しこみ
敵キャラのバックグラウンド動作

なかなかバカにできないですよね。

http://homepage2.nifty.com/nowsmart/
日本製OSどうよ？

>>120
あ、そっかぁ。俺の場合は単体のプログラムだったから優先度はロジックで
解決できたけど、OS ともなると優先度自体をカスタマイズできるように
しなきゃならないもんなぁ。うーむ、奥が深い。

>>122
I/Oまわりの制約が軽いのと、
スケジューリングに待ちがない（多分かなりシンプルにしてあるでしょう）と、、、

仕様からすると、これかなり軽いですね、
フォアグラウンドウィンドウに対して
より多い目のタイムスライスを与えるようにしてやれば
おそらく体感的にWindows3.1以上の軽さまでいけると思います。

ただ、利用用途が問題かもしれません。理由は以下の通り。
----
ゲーム？　I/Oはドライバ開発者まかせですから、ビデオカード依存になります。
Windowsの場合、DirectXがあります。
これによってビデオカード固有の機能をある程度吸収して抽象化された環境を
プログラマに渡してくれますから、逆にこれがないとプログラマにはつらい。

なんちゃってビジネス系ソフト？
Excelとか動かそうとしたとき、
「MSのサポートが受けられない」なんていうのはどうでもいいんですが、
動く動かないレベルの問題があります。

Linux的なところを狙うのであれば、、、みんなLinuxになりますし、
アンチWindowsを狙うのであれば、OS/2もあります。

パビリオンや駅に設置する、OSじゃなくてアプリが画面にでてればいい的な
用途がいいか？
パビリオンに置いてある感じのだと、Shockwaveが動かないとつらいかも。
駅に設置するようなのであれば、、、これは大丈夫ですね。

>>123
逆に、ロジックでの部分をAPI化＋カーネルっぽいところに実体をおく
っていうのをやってあげれば十分でしょうね。

リアルタイム系をつきつめると、リアルタイム系のやりかたが
トランザクション系をつきつめると、トランザクション系のやりかたが
バッチ系をつきつめると、バッチ系のやりかたが

それぞれ違うので、全部に対応するのは難しいですし、
どれがエラい、なんていう話でもないです。

ツクバ速くて最高速トライ速くてゼロヨン速くて、みたいな万能設定は
アキオと地獄のチューナーでないかぎり難しいです（ｗ　シンプルにいきましょう♪

>>112
ごめん、マジでわかんない。

定義については、113とほぼイッショで
実装対象になる環境次第。

プロセスってのはタスクとほぼ同義じゃない？
というか、タスクってのはプロセスとかスレッドとかが動作している様を
表現するのに使う、適当な言い回しかなぁ。
スレッドっていうとひとつのプロセスから派生したプロセスみたいなもんで
リソースは共用してるとか、なんかそんな感じ。
プロセスとプロセスはたがいのリソースに影響しないように、とか作られてて。
タスクって定義はマジでなんだろうね。

>122 スクリーンショットがX11+twmで動いてるDOSみたいでワラタ。

>>127
システム毎にいろいろな名称が使われるね。

タスクは、ＭＶＳ（および、その真似をしたシステム）でスレッド的
な意味で使われたのじゃないか。
その場合、メモリー空間等のリソースを含めて別にする（場合の）
プロセスに該当する用語はジョブか。

ただ、いずれもＣＰＵ装置を管理する概念って感じで古いよな。
新しいシステムなら分散型のオブジェクトで十分か！？。

>>126
ほっといてやれよ。
突っかかってみたかっただけなんだよ。

うーん。細かいつっこみはしないけどさ。

とりあえず、
君らの言うマルチタスクOSは、三輪車にエンジン乗っけて走らせました。
というレベルだって事はわかったよ。

マルチタスク、と、リアルタイムをごっちゃにしているヤツもいるしな。
とりあえず、ゲーム上がりのヤツはだめなようだ。

>>129
えーと、ぶっちゃけて
プロセス≒ジョブ
スレッド≒タスク
ってな感じでいいすか？

つーか「マルチタスク」というとき、
単語に含まれてるタスクの指す所の意味は
これだとプロセスっぽいんだけどどうなんだろ。

言葉遊びだなぁ。

言葉遊びにならないように、定義は
http://yougo.ascii24.com/
とかにしたがわない？

>>133
プロセスの定義が存在しないという罠

うを、何時の間にやら、伸びてる。
>127-134
"ﾌﾟﾛｾﾃﾞｭｱ"ってのもあるよ。Intelの方言かな？

他所でも書いてるけど、ホンとにx86系でマルチタスクOS書く気があるなら、
CQ出版が出してる"Pentiumﾌｧﾐﾘｰ　ﾃﾞﾍﾞﾛｯﾊﾟｰｽﾞﾏﾆｭｱﾙ　下巻"(Intel)
は、もってた方がいいよ。内容の割りに安い（3k弱）し。
後は、PC/AT機でやるならPC OpenArchitectureDevelopers'Group
へ逝ってBIOSなりの詳細の載ったPDF落として来れば良い。
基本的には上記の２つでどうにかなると思う。汗分かるヒトなら。

それ以上のことは、ブートセクタ(IPL)なり、BIOSなりを(ﾎﾝとはダメだけど)
ディスアセンブルして解析した方が早い。
この辺はExDeb使えればなんとでもなるし。

･･･組み込み・制御上がりはI/Oを直接叩きたがるという罠
うをー、uPD765B待っておれぇ･･･

>>135
それプロシージャのこと
一連の処理単位を指し、発祥はどこかのホスト用語だったはず

リアルタイム性って実時間を保証するって意味でしょ。そういう
定義なら、Linux/Windows いずれもリアルタイム OS ではない。
マルチタスクってのは、ある基準に基づいて複数プロセスに渡す
CPU リソースを細かく自動的に切り分けることで、見かけ上
並行・同時動作を実現することであり、結局全然直交しない別
レイヤのお話だと思う。

>>137
言いたいことには同意だが
おそらく直交の用語の意味を誤解しているに１００ドラクマ

asdasdasd

Linuxは沢山種類があるので(以下略
がんばれ若造。

>>リアルタイム性って実時間を保証するって意味
なんか、変な日本語
実行時間と云いたかったのか？

>141 リアルタイムの話だから実時間で正しいと思われ。

>>142
そうか･･

リアルタイムっていっても優先度逆転を解消するような
仕組みを実装しないといけないよな

>>111
今日でかい本屋に逝ってきたけどなかったぞ、ｺﾞﾙｧ！！
あした秋葉に帰りによってきます。

eCosってどうなんでしょうか？redhatがやってるからって
Linuxと何か関係あるように思われがちですが、これってC++で
書かれていてlinuxとは関係ないですよね？
http://sources.redhat.com/ecos/

>>146
eCosは普通にリアルタイムOSだけど、Linuxはそうじゃないと思われ。

>>147
いや、べつにLinuxをRTOSなんて言ってないんですが、、

>>1
ＯＳと呼べるかどうかわからんが、
スタックスイッチャ＋メモリ管理程度なら
ちょっと前までみんな普通に作ってたと思われ。

>>148
ごもっとも。とりあえずeCosとLinuxのつながりで連想するのは
GPLだけ。他に関係ある所ってあるのかな。プロセステーブルの
構造が一緒とか…??

>>150
今eCosのソースをちょこっと眺めたのですが、
なんか組み込みって言う割には結構巨大ですよね。
ITRONってもっとミニマムなものなんでしょうか？
あと開発パッケージ買わないとソースコードって
手に入らないみたいですね。WinMXで検索しても
当然出てこないし。。

>>151
売られてるITRONのソースはまだ見たことないけど、
公開されている仕様をもとに作られたフリーのuITRON
互換OSのソースなら見たことがあるですよ。たしか豊○科技大の人
だったような…

既出ならｽﾏｿ。
http://member.nifty.ne.jp/Ryuz/hos/index.html

>>152
どうもです。さっそく検索しましたところありますたです。
http://www.ertl.jp/TOPPERS/

>>153
ﾈﾀかとオモタYO
篠原製ですか？

仕様書にのっとっていれば勝手にuITRON4.0準拠とかって
言ってもいいのでしょうか？
uITRON4.0仕様書
URL http://www.itron.gr.jp./SPEC/FILE/mitron-401j.pdf

>>154
どうもです。
>>155
実はソースじっくり読んでないのでどんなもんか分からん（ｗ
ところで篠原製って何？

>>156
何準拠にせよ、コンフォーマンステストってあるのかなあ？
TRON協会がやってくれるのかな。
まあ、どうせやってもデファクト標準が勝つ世界な気がするけど。

uITRONはドキュメントもコメントも日本語なので
気持ちが楽です（ｗ

>>157
HyperOperatingSystem
HOSと帆場瑛一で検索すればでてくると思われ
大して重要なことではないYO

関係ないんですがuITRON上のWebブラウザはアクセスのやつが
業界標準というふうにみなされてるんですか？

>>160
ありがとう。２０円ぶんくらいﾜﾗﾀﾖ!

uITRON（・∀・）ｲｲ!!

・∧・

>>161
netfrontのこと?
組み込みの世界にスタンダードは無いような気がする。
この辺りが組込み系の経験者不足に拍車をかけてるのかも。
実際ここで話題に上がってるITRONもメーカによって反応はさまざまだし。
実装仕様が無く、ほぼ実用に耐えられる互換性が無いってことは、実際の
ところオープンじゃないんだよな。

メモリ保護機能付きuITRON（・∀・）ｲｲ!!
http://www.zdnet.co.jp/mobile/0204/15/n_tron.html

うお、さすが高田先生、実装はやいな…。
これの予稿よんだのだが、ARM domainそのまんま採用したようなかんじで、
オーバヘッドを低くおさえてるらしい。
SHなら割と効率よくエミュレートできるとおもうのだが、i386だと
ふつうの保護並の重さになりそう。ソースがはやくみたいなぁ。

>>167
それってARMべったりな仕様ということになるんでしょうかね？
とりあえずコードを見せて頂かないことにはなんともいえないけど。

>>105
今更だけど、一応書いておく。
趣味でOSが作りたかったら、最初は作りたいところから作るのが一番いい。
ブートなんかは、興味がなかったら面白くないから、最初はDOS上に作るなど
すればいい。
俺も昔、X68000上にOSを作って遊んでたけど、ブートとファイルシステムは最
後までHuman68kというDOSライクなOSに依存していた。ま、遊びだから。

>>169
最後までHuman68kに依存してた・・・？ってことは、
それって、Shellとコマンドを作ったって意味で
結局OSは作らなかったってことでは。

>>170
タスクスイッチと仮想メモリの部分は
自分で作ったんならOSと呼べるだろ

>>171
マルチタスク化したわけですね。Windows3.0みたいに。

さすがに、プリエンティブなマルチタスクを自力で実装した強者or変わり者はいないの？
ここまでやったらリーナス級だよね、多分。
ところで、Linuxのカーネルって再入可能なの？

>173
なあ、preemptive を読めるようになってから議論したら?

>>174
なにそれ？

www

呼ばねえんじゃねえの?
JAVAの環境はOSなのか?

ここは、俺の作ったモノはOSなんだ。

というすれになりました。

>>177
それはDOSを引きずってたWindowsがOSか、OS環境かって問題と等価だね。

>>170
まさか…
起動だけHuman68kに依存しているだけで、後はシステムをほとんど乗っ取って自走
していました（ファイルシステムは、IOCSを一部使っていたが）。
DOSを使った方がいいというのも同じ意味で、簡単にシステムを乗っ取ることができるため。

おい、おまえら関係ない話ばっかりじゃんかよ
タイトルみろよＯＳ作ったかどうか聞いているんだろ
ＯＳ作った人はここにいるよ
http://www43.tok2.com/home/patrosystem/

>181
お前、ガキからかってかわいそうだろが。

>>182
自業自得、というやつですな。

μITRON準拠に逃げてもいいですか?(藁
営業畑の人間と話したら、組み込みはTRONじゃないと売り込めない
って馬鹿にされました(鬱

せっかく、ファイルシステム構築したのに･･･
これ、TRONじゃ無理だ

鬱。全部やり直しｶﾓ･･･

>>184
さすが「営業」としか言い様がないな。
タワシでも売ってろ。

御愁傷さま。。。

>>185
他の営業の人に話をもちかけるそか、
何か配布できるサンプル作ってみたらどう？
ひそかにに応援。

多数派でないことによるデメリットは大きいと思うよ。
Windowsなんて、多数派だからこその製品じゃないですか。
多数派になった理由で、それほど技術的なものも聞かないし、思いつかないし。
あるとしたらPnPくらいか。出始めは悪評だったけど。

　　　　　　　　＿＿＿＿＿　　／￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　　　 |　 　 　 　 |｡ |　｜このままじゃオレたち…
　　　　　　　(|　　(二)　 |｡ | ＜ μITRONに支配されちまうぜ！！
　　　　　　　 |＿＿＿＿|｡ |　　＼＿＿＿＿＿＿＿＿＿＿＿＿
.　　　（___）　∧__厂￣￣￣|
　 　 　 ||　,く|　o　 　 |＿_| |
　　　　 ||〃 |　o　 　 　 ||　|
　　　 　 "　 |　o 　 　 ,〃　|
　　　　　　 └i^iー―(⌒) ┘
　　　　　　　　| |　　　　| |
　　　　　　　　| |　　　　| |
　　　　　　 l二二l　　ｌ二二ｌ

>>189
CEとか、Javaチップとかいう話はないの？
よくしらないんだけど。

Linuxのブート処理みるだけでもかなりためになるね
http://lkh.linux.or.jp/24kernel/source/html4/boot.html

JVMからVを取ってみました。
いちおうそれらしく動いているのでいい感じです。
でもtry節は動きません・・・がんばります。

>>168
べったりというか、ARM9だとハードウエアにそのままの機能があります。
アドレス変換なしで、アドレス空間を16にわけてそれぞれに対して、
アクセス権を設定するやりかたです。

SHだとTagged TLBがあるので同様のメモリ保護機構を
低オーバヘッドで実現できるとおもいます。
ただ、高田先生はまじすごい人なので、なんか良い解決策があるのかも。

>>173
マジレスしても仕方ないのだが…。

プリエンプティブなマルチタスク/スレッドをただ実現するだけなら、
そんなにむつかしくないのでは…。わたしでも書けるくらいだし。

ただ、IOとかのOSとして必要な（だとおもわれている）機能を
すべて横取り可能なように実装するのは血がにじむような努力が
必要なのではないかとおもいます。

>>184

OSを作り出して安定するまでには時間がかかるとおもうのですが、
その時にuITRON準拠なことがアドバンテージになるかどうか…を
考えると、どうかな？とおもいます。

それに、APIを自分できめれないのでは、自分でOSつくる甲斐が
ないですよね…。OSのセマンティックスに思想が色濃く反映されるわけで。

インターフェイスが規定されてるだけでもそれを
理解しなければならない第三者の努力が少なくて済む。

っていうのは建前か？！

実装する人が、APIのデザインに興味があるとは限らない。
タスクスケジューリングやVM、ファイルシステムだけなら
やってみたいと考えている人は多いのでは。

携帯電話はARMが殆どなんですか？

オリジナルから既存へ、マ板として正しい展開だ(w

GUIとアプリケーションレベルのAPIが公開されていれば
ＯＳなんか何でもいいのではないですか？

>>200
細かいことをやり出すと、既存のAPIじゃ実現不可能だったり、
OSにリソースを管理してほしかったり、反応が遅かったり、もっとバッファが
ほしかったり、動作を「保証」できる資料が必要だったり、エラーがでたときの
対応に不満があったり・・・要求自体はいくらでもある。

>>201　カーネルだけ共通であとは勝手にするってのがいいのですか？

よく分からないんだけど、組み込みOSってカーネルバッファが
足りなくなったらどうするの？

あれだ、
新しいOSを作るってんなら、既存OSのいいとことわるいとこを把握しなきゃいけないと思うんだがどうよ？

＞＞197
そういうのは、OSを作るというのではなくて、OSを改造するとか
機能追加するというのではないのでしょうか…。

>205
例えば、Windows互換で落ちないOSとかを作った場合、
それは改造や機能追加では無いと思うが。

OSは作らなくていいからX Windowをナントカしてﾎｼｲ。
あれはUNIXとは関係ないジョークとして無かったことに
ならないかな。

うーん、ひまなのか＞自分ってかんじなのだが。

>>206
タスクスケジューリングやファイルシステムだけやってみたい人もいるのでは？
というから、そう書いたのです。

（実現可能性はともかく）もちろん互換性もついいOSをってのも、一つの
モチベーションになるとおもいます。でも、>>201の言うとおりのようなことは
かなり多いし、OSを作るならAPI設計もやったほうがたのしいのではないかな？
と主張したいわけです。

なるほど。
俺もカーネルアーキテクチャに合わせて全く新しいシステムコールを
デザインする方が面白いと思うよ。

>>206
そんなの作ったら、MSから弁護士が15人くらい来て、
改造や機能追加したOSだと言われる事に、500カノッサ。

>210
大丈夫。そんなの誰も作れないから。

>>205
まぁ、既存OSの実装ということになるんでしょうが、それはそれで面白い
作業だと思う。仕様だけで動くモノでもないし、実装フェーズでもいろいろ
デザインできる場所はあるから。
あと、自分の作ったOSで既存のソフトを動かせる(多くの人に使ってもらえる)
というのは大きな魅力かと。

手を動かす人だけがプログラマ。

>>212
うんうん、それはそうおもいます。
逆にそういう経験がないひとが、OSを作ろうとして、過去にあったような
失敗をくりかえしがちだし、なにが問題かよくわかんなかったりすると思うので、
既存のOSをいじくり倒すのがさいしょかなぁ？と、おもったりもします。

さいきんは、いいOSのソースがごろごろ手に入りますし…。

自作OSを作るのに適してるプラットホームって何がある？
自分はPC/ATで始めたんだけど、挫折中(2ヵ月半)。。
機材が安く手に入って、そんなに仕様が大きくないものが
あるといいんだけど。
(かつ、性能的にいろいろ遊べればなお可)

SH-3/4とかはどうかな。わりとやりやすいような。
ただ、アセンブラわ非常に書きにくいけど、ほとんどCでできるはず。
評価用ボードとかも7万とかで買えるし、ちゃんと動くようになってきたら、
PDAとかに移植しましょう〜。

vmwareはいいよ。あとgrubとかoskitとか。
こんだけ道具が揃ってて作れないとしたら
おれプログラマ辞めた方がいいのかな？ｗ

>>215
PlayStation.

>>212
それだったら、自作のOSにVC++互換の開発環境を実装すれば
オープンソース利用者のみならず多くの企業が簡単に参入してくれるね。
世の中のアプリが全てJavaなりに統一されてくれればJavaVMを
実装するだけで済むんだけれど。。。

>211
Lindowsってのはまた違うの？

>>220
wineをつかってるんじゃなかったっけ？

>220
広い意味のOSに含めてもいいけど、エミュレータなんだよね。

http://www43.tok2.com/home/patrosystem/

やっぱＯＳと言えばこれだよね。

>>219
開発環境だけ互換でも仕方無い。
MS-Officeアプリが動く環境を作らないとだめでしょ。

>>181=>>223=

itronでもOSと呼べるなら,その程度のものは何度も
作ったがファイルシステムも無いようなもの。

http://edoya.neko.to/gw.cgi/edoya3407.jpg

ここである仕様にのっとってカーネル組んだら
少しは注目してもらえるかな？なんかOSASKとか
ボロボロに言われているのをみるとなんだか
気が引けるんだけど。

>228
ここのみんなのやりたいことに OSASKが合わないから、言われるだけだと思う。
作者の考えてる目的や用途に添ってれば、作者にとっての OSASK の方向は
問題ないと思うのだがいかがかな。
それをみんなが（また）自己満足などと呼ぶかどうかはさておき。
注目されたかったり人の目ばかり気にする八方美人でまともなモノが作れるとは
思えないんで、ある程度はわが道を行く根性も必要でしょ。

斎藤ＯＳ
略してＳＯＳ
ダセーヨ

>>230
関係ないけど
ヒューレット・パッカードとかハーシーズとかハーレーダビッドソンとか
ガイジン（アメリカ人？）は自己主張強いよな。

近江兄弟社

メンタム？

･･･ITRONになびいたものか、決めかねたまま、ただ今BIOS解析中
DISK BIOS周りをとりあえずやってんだけど、PC-98のBIOS眺めてたら

FD80:1A9E 8AE0　　　　　　MOV　AH,AL
FD80:1AA0 32C0　　　　　　XOR　AL,AL
FD80:1AA2 A3AE04　　　　　MOV　[04AE],AX ;<????
FD80:1AA5 9A0000C7F4　　　CALL　F4C7:0000
FD80:1AAA FF2EAC04　　　　JMP　DWord Ptr [04AC] ;<????
き、気持ち悪いぞ、コイツ･･･やりたいことはわかるんだけど。
生理的に納得いかん（ｗ

OSASKの作者は勉強不足で、思い込みが強すぎると思う。
やりたいことの気持ちは判るけれど、既存のOSや他人の
研究成果をきちんと評価できるようにならないとだめじゃないか?

>235
だったらおしえてやれよ。
ってか、俺にも教えてくれ。

>>236
川○さん？w

というか研究成果を勉強すればするほど、UNIXで
いいじゃんというワナにはまるような気がするのだが。。。

研究成果を勉強したら、すぐにUNIXはどうよ…とおもうようになるとおもうけどなぁ。
実際に普及するかどうかを考えるなら、たしかにそういうワナにはまるが。

OSASKの作者があまりまわりみてないってのは同意。

既出かもしれないけど、XTALって結構すごいと思う。

>>239
それはなんですか？

http://www.xtal.org

http://www.axe-inc.co.jp/

>>238
threadの実装においてUNIXが不利なのはなんとなく
分かるんですが、設計から見直せばもっと高速なものは
作れるんでしょうか？

>>243
私見ですが、UNIXにおけるスレッド実装に関しては、速度面での不利益よりも
実装上の不利益のほうが大きいようなきがします。
プロセス周りのデータ構造とかをすべて書き換えてやれば、UNIXでもそう
大差ないthreadを提供できるのではないかなぁ。
それが大変だから、Linuxなんかはああいうしょぼい実装になってるわけなんでしょうけれども。

Solarisのthreadの実装はすごいですよね。
って、正直どれくらいの性能がでるかしらないんですけど

名刺フォルダの整理をしてたら
高田先生の名刺でてきた。
某ギコ大の講師って書いてあるな。

Solarisのカーネルってまだもらえるのかな？

>>246
ソースコードならもらえるはず。
ただ手順がメンドクサイ。

>>246
あと、ライセンスとかどうなんだろう。
ソースみちゃうと、OSかけなくなりそうでこわひ。

ソース見るのもいいけどさ、
設計という工程はどうしてる？

>>249
ソフトウェアの設計？
プログラムの設計？

ところでOSASKの作者が馬鹿にされているのはUNIXを
知らないという事情が大きいのかな？

>>251
UNIXが、というより「私の知る限り〜を実現しているシステムはありません」
という発言がことごとく既出の仕組だからじゃないかな。あれさえなければ
素直に応援してくれる&教えてくれる人も増えるのにね。

>>252
http://www.imasy.or.jp/~kawai/osask/reason.html
これ、ワラタ。

すごいと思ったのが「ファイルキャッシュ機構と仮想記憶管理機構の統合」を
実現してるOS名をおしえてくださいってのだ。そのへんのFree UNIXなら
たいていしてるとおもうんだが。

>>252
既存の手法との違いという説明のスタイルが
あるだろうにねぇ。

http://www.imasy.or.jp/~kawai/osask/filesystem.html
うお、ディスクキャッシュと仮想記憶の統合ってそういうことなのか、
勘違いしてた。失礼＞川合さん

UBCとかそういう機構のことかとおもった。
用語も世の中とあわせてほしいなぁ、とおもったりしました。

http://pc.2ch.net/test/read.cgi/os/989544577/
このスレなかなか熱いね

矢張りここは
「現代PCはメモリがふんだんにあるから、仮想記憶はサポートしない」
「OSプロセスとして、ガベコレを発動させる」
「I/Oへのアクセスは、速度のため非同期のみ」
「ネットワークは、raw socketのみ」
「超漢字並の多言語処理をシステムでサポート」
くらいはフカしてほしかった。

>>255
ねーＮＴのメモリマップドファイルとどうちがうのー？
キャッシュと仮想記憶も統合されてるしさー　
実行ファイルも仮想メモリにマップしてそのまま実行してるしさー
（もちろんＰＣが指した場所しか読み込まれない）
おいらＵＮＩＸはしらないけどー

>>257
それってJavaOS、、、

絶対知ってて振ってるだろ（笑

>258
よく似てる。ただ、ファイルシステムがなくなっても
メモリマップドのまま動きつづけることができるってことみたい。

メモリマップドよりも、疎な結合ってことだね。

JavaOSなら同期がデフォだな
いってくる、、、

>260
なるほど。

>>258
>>260が書いちゃってるけど(^^;;、わたしがおもうに、よくある
キャッシュと仮想記憶の統合とちがうのは、すべてのメモリオブジェクトが
永続(不揮発な？)オブジェクトだってことだと思う。
リブートしても再開できるってところかな。

タスクのsuspend resumeを実装するにはわるくないのかな？

でも、ファイルとしてメモリを抽象化するんじゃなくて、ふつーは
メモリを永続オブジェクトにして、ファイルをみせなくするんだとおもう。

アドレス空間はあるけど、実メモリは見えないっていう実装はなんだか
きもちわるい。

>>257
メモリ保護はどうするのよ(^^;;
あと、I/O accessが非同期だとどうして高速？

現代のプロセッサは仮想メモリでメモリ保護をするのに
最適なつくりになってると思うけどその辺は川合さん
どう考えてるんだろう。

マイクロカーネル以降はカーネルのコアをなるべく
プロセッサ、メモリに集約できるように設計するのが
暗黙の了解みたいになっているけど、OSASKの
設計だとファイルシステムがもろにカーネルに入ってきたり
しない？

もちろんマイクロカーネルなんて幻想はもう昔の話だけど
その幻影だけは根強く残ってるからねｗ

>>266
んー、マイクロカーネルから得たモノリシックカーネル（のようなもの？）の
組み方って至る所で採用されてるよね(*BSDのvmとか)。だから、ふぁいるしすてむが
カーネルにはいるのは一概にわるいとはいえない。VFSみたいに十分抽象化
されていればふつーはこまらん。

でもね、UNIXじゃないAPIにするんだったら、名前空間=ファイルシステムな
設計はやめたほうがいい。機能分割がうまくいかなくなる。

>>263
もっかいなるほど、
ディスクキャッシュをフラッシュすれば
サスペンド作業完了ってわけっすね。

>>264
あ、メモリ保護が無いのも
俺がJavaOSとカンチガイした理由の一つ。
クラスローダがバイトコードがメモリ破壊しないかをチェックできるから、、

PC-UNIXはLinuxしかしらないのですが、
NetBSDは移植性に関してかなりよく設計されていると
聞きます。実際のところはどうなんでしょうか？

http://www43.tok2.com/home/patrosystem/

OS
を作った人をついに発見!

NetBSDはよいです。
CPUの仮想記憶まわりの抽象化層とかもよく考えてあるなぁとおもうっす。

Linuxは…、移植生向上といいつつ、ページテーブルエントリの切れ目を
なんとなく可変にしてるだけなやうな。
塩にいちゃんにいわせると、Linuxの移植ってのはIA-32 emulation層を
つくることだそうです。

>>272
ということはタネンバウムに言われた386べったりの設計というのは
今でも変ってないということなんかね？

386かぁ、、、

チャット状態だ(^^;;

さすがに、批判されたころのような、べったりさではないとおもいますが。
って、さいきん、読みやすいNetBSDに逃げがちになってLinux読んでないので、
2.4とかだと変わってるのかもしれないけど。

>>272
NetBSD の移植についての記事でNetBSD のほうが IA-32 のエミュ
レーションレイヤーを作るような作りになっていると書いてあったよう
なのですが、真相は？

あ、でもさいきんLinuxのkernel読んでてわらったのが、
ページテーブルの１段目がstatic変数で宣言されてたことだ。
どういうことだ＞Linus

CPUとOSは切っても切り離せない関係だから
あるレイヤーを儲けるのは当然のことなんじゃないでしょうか？

>>275
うーん、だれがそんなこといったんでしょう？
それはおかしいとおもう。って、仮想記憶まわりに限ると（ほかあんましよんでない）
NetBSDはページテーブルの初期化とか変更とかマップとかの関数で
ハードウエアを抽象化している。これらの関数を各ハードウエアように
提供してやればおっけー。

>277
特殊なアーキテクチャを持ったCPUの機能を
そのレイヤーに使っちゃいけないと思う。

>>279
もうちょっと説明お願いします。

酒の勢いでさっきから好きなこと書いてるが…(^^;;

特殊でもなんでもいいけど、上位層にとって便利な抽象化であること、
あらゆる下位層にとって実装可能であるひつようがある。

IA-32はそういう意味では、不的確ですな。

あ、281==278っす。

もう386が発売されてから15年以上が経つのにプロセッサが
OSに対して提供する機能は大して変ってないのですかね？
もっと勉強してから出直します。

ブレークスルゥとよぶほどの機能はないですね。
386どころかVAXのあたりからかわってないというか。

ぼくてきな、最近の大きな変化といえば、RISCがでてページテーブルを
プロセッサが引かなくなって、Tagged TLBみたいな機構がでてきた
ことかなぁ。

でも、基本的なアーキテクチャはやっぱりたいしてかわってない。

286にすら4段階(5段階だったっけ？)の動作モードがあるけど
あれはなんのためなんでしょうか？最近のメジャーなOSは
上と下の二つしか使ってないですよね？

まだOSの設計理論が熱い頃のなごりかな。

Penの命令はRISCによるエミュレーションっていいますよね。
ソフトの互換性のための。

俺は、そういう凝った仕掛けを活用したカーネルも作ってみたいな。

286って、16ビットと32ビットの変わり目のCPUだから、そうなんじゃないかなぁ。
386へ行く前に試行錯誤してたっぽいですね。

>>285
real modeとかってことかな？
あれは、メモリアーキテクチャ拡張をしたいがために、互換性がなくなったから
ああいうことになっちゃってるのだとおもうけれども。
8086のころの基本設計がしょぼい証拠？（うそかも）

>>286
いい番号だね（わらい）
あ、PentiumはほとんどRISC emuだけど、IA-32のアーキテクチャを
ひきづってるために非常にアドレス空間の切り替えがおそい！
100 clocksちかくかかるんじゃなかっただろうか。
Alphaとかだと10 clocks程度。

>>288
そういうと、確か24ビットでアドレッシングするモードなかった？記憶違いかなぁ。

286って。

これからの業界標準はxscale(strongarm後継)です

>>290
あったきがする…。

>>291
XScaleは萌えるね。GENIO eの新しいやつかわなきゃ。
OSうごかしてみたい（これはきびしいか？）
しかし、あのプロセッサ採用してる割には電池が10時間しかもたないとか。
なんでだろう。

>あのプロセッサ採用してる割には電池が10時間しかもたない
冬でもホッカイロいらず。すばらしい。。。

やだよ（なき）
わたしはあつがりなんだよ（なき）

ちょっと検索してみたら、286はアドレス空間、およびデータバスが24bitだったみたい。

うー、もう、酒のつまみにOSばなしつきあってくれるひとはいないか。
酒板いってこよう。

>>295
もう少し調べればリセットしないと移行できないモードとか気の狂った設計が出てきます
当時のOSと組ませた場合の設計としては問題無いですが、さすがに今見るともうだめぽ

>>297
情報ありがとです。がぜん興味わいてきたんですが（わらい）
でも、386以降でも十分気が狂ってると思うのはぼくだけだろうか。
vm86 modeとか…。

>289
> real modeとかってことかな？
ではなくて特権リングのことじゃ？
いや、漏れは 386 以降しかしらないから 286 に当てはまるのかどうかわからんけど。
リング 0 と 3 だけでもいいんじゃない､ってことが言いたかったのだとおもわれ。
でも Windows は 2 もつかってるね。

いや、リングだと0,1,2の3重じゃなかったっけ？
リング機構ももっと軽くできるなら利用価値がいっぱいあるのかなぁ。
いや、やっぱコールゲートとかそういうのたいへんだから、いみなひか。

OS/2とちがってどーせ落ちるときゃ落ちるんだから、
Windowsもリング1コだけ使やいーのにね　と言ってみるテスト

ところで、ここで言ってるWINは95/98系っぽいが、
2000/XP系はどうなのよ？

>>302
pc-unixが好きで色々と勉強したけど
Windowsは世界最高のソフトウェアかもしれない
という考えになんかなってきた、、、鬱

ＯＳ以前の問題だが、フロッピーからの起動で、
オリジナルＯＳの起動メッセージだけ表示させて
喜んでいる。
電源入れてから、ブートに行く手順が分かった
だけだが、これがオリジナルＯＳの一歩になるかも。

>>304
おれも同じ経験あり。うれしいよね。

今のマイクロカーネル研究の最優先事項には
UNIXのサブシステムを高速で動作させるのは
あんまり考えられてないみたいだね。
リアルタイムとSMPに対する軽量なスレッドの提供、
これらを共通の設計に基づいて提供するっていうのが
カーネル研究に課せられた残り僅かな使命か？（藁

こうして今使ってるWindows2000だけど、この安定性は
最初は奇跡を見ているような錯覚に陥ったものだけど、
もうなんか当たり前に思うようになった。当然MSに対する
見方も変った。これだけのパフォーマンスを出しながら
まったく安定している。理論なんかいくら積み重ねても
インプリメントで勝たないことには意味がないことを
マイクロソフトは証明してくれたね。

おれはもうOSについて考えるのは辞めたよ。人生短いから
もっと有意義に使わないと（藁

>>304,305
俺も俺も! よっしゃあ!って感じだよね。
その後A20ゲートでハマった。何かVRAMにファントムが出ててしばらく原因わかんなかった。

富豪的プログラミングの考えから行くと、スレッドなんて中途半端な技術で、
無くなっていいと思う。
スレッド・セーフなんてことをアプリに考えさせないようにするのがこれからの
環境じゃないかな。

>>309
スレッドなしにどうするの？
fork1本でがんばるのか？！

CPUの構造を考えてOSを作るスレはここですか？

>>311
CPUを完全に仮想化した素晴らしい理論をお持ちなんですか？

CPUよりか、周辺機器の乗りっぷりがOSの決め手だと思うなぁ。
メモリの量とかさ。
メモリ４Kbでもどうさするようにきちんと考えてくれよ。

OSの決め手は、思想だと思うよ。

いや仮想にするとかじゃなくて、
CPUの機能のことも考えてOS作る(普通だけど)って凄いなと思っただけあるよ
喧嘩売ってる気分ははないです

OSの決め手は、死相だと思うよ。

Linuxが企業から見向きもされなくなったら
コミュニティーも崩壊しますか？
RMSはフリーソフトを使う動機は性能であっては
いけないとか言ってたよ。

やっぱプログラマならOSやコンパイラみたいな基礎的なソフト、
一度は作ってみたいな。

>312
それって Java VM じゃ…

ゲーム用超軽量Threadコアソース公開

#define　THREAD_MAX　256
void　*thread_adr[THREAD_MAX];
int　thread_now;

void　ThreadExec( int thread_no ){
　void　*func = th_adr[ thread_no ];
　thread_now = thread_no;
　func();
}

void　NullThread(){}

void　ThreadClear(){
　int　i;
　for(i=0;i<THREAD_MAX;I++){
　　thread_adr[i]=(void *)NullThread;
　}
}

void　SetThread( int n,void *adr )
　thread_adr[n] = adr;
}

＊ローカルスタックほしけりゃ自分で確保しろやヴォケ！
＊ローカルスタックはなるべく使わない。
＊システムスタックは元に戻して返す。

>>320

コンパイルエラー発見！

void SetThread( int n,void *adr ){
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

すまん。この程度のレビューしかできん。
プログラマーとして失格っすか？

>>321
ワーニングどまりじゃないかな。

>>320
それをthreadとよぶには抵抗が…。
周期的関数起動ルーチンってところじゃないか。

>>323
抵抗のないようなのは重過ぎてゲームには使えないのです。

>>324
そういうことも多いのだろうけど、まぎらわしいから違うなまえつけてくださいよ。
OSASKの某氏みたいだよ、それでは。

yieldすらできないヤツをthreadとは呼びたくねー

>>326
それは、君がThreadというかOSを２〜３種類しか知らないからじゃない。
OSもThreadも世間にはごまんとあるんだよ。

実用されてるOSで採用されてるかどうかはわかんないけど、
走りきりスレッドモデルを採用してるOSを研究してるひとがいるね(名前わすれた、九大のひと).
発想はおもしろいけど、スレッドと呼ぶには微妙に抵抗があるし、
プログラムくみにくそうとおもった。システムコールを発行しただけでも、
スレッドが終わらされて、結果を受け取るのは違うスレッドなんだもんな。

メモリ空間を共有する複数のコンテキストはスレッドでいいだろ。

>>329
「複数コンテキストが存在する」ことの定義は？

いやね、>>320のは、見方によってはコンテキストが一つだよね。

コンテキストの定義次第だと思う。

>>331
それは、もちろんそのとおりなんだが(^^;;;
そこでおわっちゃったらつまらん。

おまえらはどう考えているのですか？

ふつうだと、PCとレジスタとスタックをコンテキストとするのかな？

コンテキストを途中で切替えることができないのなら、
事実上コンテキストが一つしかないのと同じじゃない?

だから、俺の定義ではyieldすらできないものはthreadじゃないし、
>>328のもthreadとは呼びたくない。

まあ、俺がこだわっているのは呼び方だけなんで、
>>328のようなアイディア自体は面白いと思うけど。

>>333
それでいいんじゃない? <コンテキスト

>>320, 327あたりの意見をきいてみたいさげ。

yieldねえ。
Ｃで書いたけど、本来はアセンブラ用。
PCとnow_threadを保存するだけ、

Ｃだとsetjmp,longjmp使わないと駄目かね。

setjmp, longjmpつかうと移植性があってよろしいかんぢですな。

もともとプロセスコンテキストスイッチがヤだったからスレッド使いはじめたんじゃねーか！！
実装面の歴史もちゃんとフォローしろよ。

プロセスコンテキストスイッチって、ふつーにつかう用語なんでしょうか？
アドレス空間もおおまかにみればコンテキストの一部なきがするけど、
ふつーはアドレス空間の切り替えとかっていうんでしょか。

http://www.imasy.or.jp/~kawai/osask/filesystem.html

>それでいっそのこと従来のファイルアクセスのためのシステムコールも
>撤廃してしまおうかと思ったのですが、それは互換性を損なう恐れがあり、
>OSASKの精神に反するので思いとどまりました。

これが、よく分からん。いったい何と互換性があるのだろう。
ライブラリとして実装されているのならば、エミュレータの開発はできるだろうし。

↑のレスは流れ読めてなかったようなので忘れてくれ

ちょっと、おそレスだが...
>>295
データバスは、16bit かと...。(つーか、24bit データバスの CPU ってあっ
たっけ ?)

ああ・・・

・・・だから、ゲーム機は、今でも自作ＯＳだろ〜に。

今のゲーム機って、リソース管理やタスクスケジューリングまで行ってるの？

>>344
どういうコンテキストでそういう発言になったんでしょう？

ゲーム機の話が出ると萎える。
OSのつもりかよ..

ゲーム機のでも、組込でも、わたしはOSだとおもうし、そういう話
してもかまわないとおもいます。いろんな業界の話きけるのはたのしい。

でも、なにを批判したいのかよくわからないのに、なんか批判的に
かかれるのはちょっとどうかとおもいます、はい。

いや、まぁ、ここは2chなんだからそんなこといってもしかたないんだけど。

藁藁
確かに･･･
どうも、PC用のOSの話をするヒトと、組み込みなどの低レベルOSの話を
するヒトが入り混じっており、妙な運びになっているような･･･
ここで、OSの定義をあれこれ議論しても無駄だしﾈｪ･･･

しつこく書いちゃいますが(^^;;
なんか業種がちがっても、やっぱり最下層ソフトウエアを作ってる
ひとたちの集まりなんだろうから、お互い理解してマターリと
やれるとおもうんだけどなぁ。

そっちもたいへんねぇ。いやいや、そちらこそとか。
…って、これじゃ、酒飲みの会話ですが。

でもね。

ゲーム上がりはダメダメ。　
本人が気が付いてないのでさらにダメ。

>最下層ソフトウエア

既に、きみもダメ。

ダメなのはわかった。
なにがどうだめなんですか？

ゲームプログラマってのは、ゼロヨンチューナーみたいなもんだな。
最高速向きじゃあない。

ただ、ゼロヨンのノウハウは最高速に役立たない、なんていうことは、ない。

結局、最終目標が違うからなぁ。
水泳と砲丸投げくらい違うと思う。

でもお互いの知識が役に立つこともあるし。

OSとゲームの違いなんてのは、
汎化と特化の違いであって、
ヒューマンリソースの注ぎこみ度合いはどっこいどっこいっしょ。

OSはoptimumを狙う
ゲームはmaximumを狙う

最良のシステムを、協議、取捨選択するという、
訓練を受けてない。

だから、チームとして物は作れるが、
バランスが取れた技術を提供する事が出来ない。
>> ゲームプログラマ。

ま、ゲームプログラマってのは、町のチューニング屋さんみたいなもんだ。

それから比較すれば、OSの技術はF1の世界だな。

だから、それを一括りにして、
>>最下層ソフトウエア
とか言っちゃうのは、ダメダメ。

ハァ？
日本が世界に誇れる技術はゲームだけなのに何いってんだか。

OS程度のソフトウェアで騒いでいるやつは、一度、
スーパーマリオの仕様書でも書いてみろっつーの。

>最良のシステムを、協議、取捨選択するという、
>訓練を受けてない。

これのできているOSとは何か教えて欲しいなぁ。

>>357
なんだよ、つまらん思い込みかよ。もうちょっと、他の世界も見てみたら
どうよ。

>>358
純粋な技術的側面を比べると海外のほうが上だと思う。
日本が優れているのはコンテンツ制作力。

>>350
> 組み込みなどの低レベルOS
あんた、今時の組込 OS 知らんでしょ。

>>357
汎用やさん…？

いちおう言い訳しとくと、ハードウエアを抽象化して、たたくのは
すべからくOSやさんじゃないですか。その上にさらにどれだけ積んで
いくかは目的によって違うとおもうけれども。
ハードわからないソフトやとはできない話もできるのではないかと
期待してるんです。

>>362
ついでに今の組込といっても、開発力がおいついてないので、
むかしのままべた〜なOSつかってたり、逆にほとんどPCだったり
することも多いような。
低レベルと言い切るのはどうかと、わたしもおもうけど、
ますます「組込オペレーティングシステム」っていう分野が
あいまいになっていくとおもわれ。

>>363
＞ ハードウエアを抽象化して、たたくのは
＞ すべからくOSやさんじゃないですか。
いわゆるOS作りって、ハードを直接叩く部分はそんなに多くないと思う。
MMUと割り込みくらい制御できれば一応OSの形になるし。
それ以上の個々のデバイス制御はデバドラの役目だと思う。

TRONで間に合う。

>>363
デバドラまわりのアーキテクチャをかんがえるのは、OS屋の腕の
みせどころなのではないかとおもうんですが、いかがでしょう？
たしかに、直接手を出すのは、MMUと割り込みくらいですけど。

>>365
うーん、大規模システムだとつらそうですね。
（いまのところは）保護ないし。

while ( 1 );

OSのカーネルなんてこんなもんだよね (^^;

while ( 1 );

OSのカーネルなんてこんなもんだよね (^^;

MMU、割りこみ、排他、コンテキストスイッチ

Solarisの構造を知っているか？
たったこれだけのものについて、
涙ぐましいまでの実装をやっている

ヒマがあったら、「Solarisインターナル」を読むと面白い。

ゲーム屋より優れたOS書いたのは判ったからコード出してくだしい。

なんか、低レベルの意味がわかっていないやつがいるような。

>>371
低俗な人間にとって「ｘレベル」「ｘ級」は差別用語みたいなもんだからな。
なんのためにOOPとか勉強してんだか。

うだうだ言ってねーで、俺達で作ろうぜ！
２ちゃんねらーが作ったＯＳです！と、堂々と言えるような物を。

作りました。本社は非営利です。
http://www43.tok2.com/home/patrosystem/

>>374
なんだソコのトップページの断り書きは。
なんだかなぁ。

>Internet Explorer 6.0以降でご覧ください

>以前のInternet Explorerでご覧になると一部のコンピュータで不具合が発生することが確認されています

>Internet Explorer以外のブラウザでご覧になるとすべてのコンピュータで正しく表示されないことが確認されています

>>368
携帯系はそれだとﾏｽﾞﾋ。電力食いまくり。普通はスタンバイにCPUを入れたり
いろいろ涙ぐましい努力をする。どういじったら、何μA減った、ﾊﾞﾝｻﾞｰｲとか・・
FailSafeでもﾃﾞｽｸﾄｯﾌﾟで使うOSとは違った苦労があるね。

>>369
Solarisインターナルはすごいおもしろいですよね。

>>371
Thanx
これ以上何も言うまい。

#include<stdio.h>

void main()
{
printf("オナニーしたい");
}

>371
ハードウェアのレイヤーに近い、とかいったほうがいいのかな？
でもアセンブラのことを普通に低級言語って言うような｡

>>278
その仮想の仕方が x86 に都合のいいように作られているって書いてあったよ。
たしか、SH に移植してる日本人の人だったとおもうよ。移植レイヤーがない
とは言っていないよ。

>>381
へー、そうなんだ。ちゃんとしらべてみます、ありがとう。

>>371は理解していっているのだと思われ。

確かに最下層とか低レベルとかごちゃ混ぜにして
語っているやつがいるのには藁えるな。
いや、藁ってるばあいじゃないか・・・。

ワタシ理解力低いらしい。
逝ってきます。

>>381
なにも前提ナシであんなもん書けねーって
書けてそれでいて効率がいい、ってのは神の所業だ

「はじめて読む486」を何度読み返しても
仮想メモリのところがどうなっているのか分かりません。

こんな私にはOSを理解するのは無理なんでしょうか？

仮想メモリだけがOSじゃないし、気にしなくていいんじゃない？
でも、わかってくると楽しいよね。

俺、SunOS4.Xに初めて触ったとき、mmap(1)に感動してションベンちびっちゃいました。

というわけで、System/38とかAS/400とかの方面に興味あるんですが、
そっち方面の話題はない?

マイクロソフトの技術力を持ってしても、
なんで386でしかWindowsNTを動かせないのですか？
それともサブセットとしてのWinCEがあるからいいと
考えてるのでしょうか？

>>390
NTは歴史的に Intel版以外に PowerPC版, DEC Alpha版, MIPS版があった。
技術的ではなく、政治的な理由で廃止したんじゃなかったか。

>390
MIPSアーキテクチャでNT動いてたじゃないか。
今は商売上メリットが無いのでサポートされなくなっただけ。

CPUのサポート数ならCEの方が上だね

CEかぁ。
あれも、結構キワモノといえばキワモノかも
・・・
漏れはCP/Mに感動した。むかーし。80と68と86あったよね

K8版のWindows XP 64
http://prom.alphaloop.com/view.php?type=prom&ID=1845

何気に優良ｽﾚですな
ｽﾚﾀｲﾄﾙからは想像出来なかった（ｗ
勉強なりますａｇｅ

>>390
VCのヘッダ見てみ。
いまだに、OS別にマクロ残ってるから。Alphaとか。

Power CE

CEはNTよりもさらにスマートな実装だと聞いたが、
詳しい人の解説キボンヌ

CEは、Win16の互換性とか、A系APIとかをずばっと切り捨ててるし、
実装が大きそうな余分なところもバシバシ切ってあるので、そのあたりは
スマートといえば、そうであるといえるかも。

普通にWindows載ってるマシンにCEは入らないのかな。
軽くてよさそうなのに。

>>401
ドライバがなーいんだと思う

すっげぇ厨房臭い質問イイですか？
WindowsXPのコンパイルってWindows2000上でやってるんだろうか？

ＯＳ自分で作るなら、Windows 関係は一切関わらないほうがいいよ。
だって、ほら・・・。

>>403
クロスコンパイラでつくってんだろーね。
いまでもalpha環境でビルドかけてるかどーかは知らん

おれもすっげぇ厨房臭い質問してもイイですか？
カーネルってさ絶えず割り込みが入ってきてて
処理がどこを流れているのか正直分かりにくいけど
カーネルハックしてるような人は大体今どの辺りの
処理をどれぐらいの時間をかけてやってるとか
イメージできるもんなの？

>>406
まずは、割込みは無視して、見てみようね。
次に、一つの一回の割込みだけに的を絞って、見てみようね。
それから、様々な割込みの中のそれぞれの一回の割込みだけを見てみようね。
これだけで、だいたいわかるとおもう。

>400
A系API ってなぁに？

>>408
MBCS用API。（対 U系: Unicode系)

>>406
割り込み処理は、かならずどこら辺までやったか覚えています。
同じく割り込まれたときに、今までの作業どこら辺までやったか必ず覚えています。

ただ、ほんとのこというと、今時のカーネルはタスク切り替え以外の作業はしない。
一般的な割り込み時にとりあえず現状を保存してやりたいことキュー（リスト）に
割り込み処理をセットする。
んでもって
タイマの割り込み時にOS内部の時計を更新してタスク切り替えするかどうか決めて、
切り替え時だと思ったらやりたいことキュー（リスト）のうち、アクティブなものから
どれか一つ（CPUがたくさんあるなら複数〜を選んで現状保存＆やりたい処理起動
（タスク切り替え）する。

でもこの辺で自分でOS作ったとか行ってる連中のはほとんどは
割り込み->強制的に現状を保存->割り込み処理起動
タイマ割り込み->強制的に現状を保存->タスク切り替え
なカーネル。
カーネルというか、割り込み処理ルーチン書いてるだけ。
組み込み系だと、応答性第一だから、これで正解。

カーネル自身は誰にでも書ける。
OSを書くのは大変だけど、もっと大変なのは矛盾・破綻しない設計をすることと
でも、矛盾・破綻しない設計は、そのへんのOSの教科書に書いてあるから
やはり簡単。
でも、いざ書き始めてみると、OSを支えるデバイスドライバとかを、
OSの設計思想やドライバ・UIと協調して書くのが大変。

>409
ヘタレは漏れは、落ちても大丈夫な VMware 上で
OS（ウソ、本当はただのモニタに毛がはえたみたいな奴です）書いて遊んでます。
仮想記憶もそれなりにできてきたんで、いま標準シェルを書いてみてるところ。
あ、相変わらず文字しかダメ。日本語ダメ（ってか、BIOSしかつかってないし、入出力）
標準シェルって言っても､実装が簡単なほうがいいので FOTRH の子供みたいな奴。
はじめは lisp の子供みたいな奴だったんだけど､
対話的に一行ずつ入力して実行を繰り返す用途だと､ちょっと使いにくかった。
いまのところ使い道は何もなくて､memtest86 みたいなことができるだけ。

ｺﾞﾙｧそこの奴､しょぼいと思ってるだろ！
いいんだよ……趣味なんだから。

oskit使うとカーネルのコア部分に集中できるのかな？
ドライバとかはやっぱり後回しにしたいので、、、（＾＾；

>410
入出力はBIOSってえと、昔のMINIXみたいな感じかな?

>412
もっとしょぼい。コレじゃ単なる仮想８６モニタに思えてきた…（鬱
そういやさぁ、ちょっといじって DPMI ホストにできるようにしたら､
まるっきり昔のEMSドライバじゃないか…

すまん､ぜんぜんOSじゃなかったYO!!!
本人はOSのつもりだったけど。

取りあえず、オマエら。

本当に OS 作ったヤツはいないのか?

OS作ったんだったら、俺が出資して会社作って、そこの社長にしてやるぞ。








いや、マジで。

>>413
仮想86モニタだって自力で書き上げたんなら大したもんだ。

ちょっと脱線するけどさ、モニタってどういう意味?
Jargonに載ってないから日本生まれの言葉のような気がするんだけど。
「マシン語モニタ」あたりから引き継がれた言葉?

見えないとこにあるものを監視（＆いじる）できる装置がモニタ。

昔のコンピュータはデカくて専用の部屋に置かれてたんだけど
その横にちょこんとおかれていた、処理の状況やエラー表示用に使ってた
表示装置をモニタと呼んだ。

そのうち別の部屋でオペレータが使用するテレタイプがでてきたけど
それについてたテレビ型表示装置をモニタと呼んだ。

時は流れてマイコンが世に出たとき、性能も表示装置も入力装置もしょぼくて、
プログラムも自動ローディングすらしなかったんだけど、
ROMから読み込まれたプログラムの画面で、BIOSに指示を出したり、
コンピュータの中身をマシン語レベルで見る（そしていじる）ことができた。
これがマシン語モニタ。

>>417
解説ありがと。

じゃあ、このスレで言う「モニタを作った」ってのは「マシン語モニタ
を作った」と同じような意味だと思っていいのかな? ロードしたりセー
ブしたりいじったり実行したり。そうするとコンテキスト切り換えは範
囲外?

>418
>そうするとコンテキスト切り換えは範 囲外?

そそ、基本的にはコンテキスト切換は範囲外。
でも仮想８６モニタってことになると､結局コンテキスト切換は必要。
i386 以降のアーキテクチャで出てくる V86 モードは
複数の 8086（厳密にはちょっと違うけど） を作り出せる。
それぞれの V86 はタスクスイッチさせながら並行して実行可能。
なので仮想86モニタっていった場合はコンテキスト切換も含んでる。

Windows 9x の「DOS窓」も V86 のタスクなわけだけど、
Windows 9x までいっちゃったらOS。 V86 モード以外のタスクも
動いてるわけだしね（てかそっちがメインだし）。

V86「モニタ」っていう言葉はまぁ簡単なことしかしてないよ〜
って意味をこめてのことだと思う。自分もそういう意味で使ったし。

そもそもWin9Xはただのシェルでしかないぞ。

>420
うーん、あえてシェルというなら Explorer がシェルといえなくもない。

そして上げてみるてすと

http://choco.2ch.net/news/index.html#2

>>421
DOSとの違いは、スワップ可能な仮想メモリ管理システムが付いたこと、
グラフィックアクセラレータとの親和性が高くなったこと、それに伴ってGUIがついたこと。

UIはすべてメッセージベースで動いているが、不作法なアプリケーションから
OSやシェルを守る方法が存在しない。
やっぱりただのアプリケーションランチャーだよ、アレは。
よく言っても「シェル」

リアルタイムＯＳを作ろうとしているのだが、
ＳＨ４は全レジスタ３２ビットで綺麗だな。
aaaaxxxxyyyybbbb(a,bがコード識別ビット、x,yがレジスタ番号ビット)
見たいな命令があるけど、どうしてこうなってるんだ？
このほうがチップを構成するときに効率よく設計できるからか？

>>425
解析しやすいだろ？
コンパイラも、マイクロコードも助かるしな。

>>383
プログラムでいうところの最下層と低レベルは同じ意味じゃヴォケ！

>>425
大抵のＣＰＵの命令セットは綺麗に並んでるよ。

>>427
ハードウェアに近いところ＝低レベル
カーネルコアモジュール＝最下層
こんな感じのことがいいたいとか？

>>363
> ついでに今の組込といっても、開発力がおいついてないので、
> むかしのままべた〜なOSつかってたり

逆逆、開発力が追いつかなくなったから自前の OS はあきらめて VxWork とか
使うのよ。開発力があるなら、自前の OS の方が (少なくともデバッグは) 楽だ
よ。ライセンス料もいらないしね。

>>424
>UIはすべてメッセージベースで動いているが、不作法なアプリケーションから
>OSやシェルを守る方法が存在しない。

これには、ちょっと同意できない。
その手の保護機能がないのにOSを名乗っていたのは、
「当時」結構あったよ。

>>431
> その手の保護機能がないのにOSを名乗っていたのは、「当時」結構あったよ。
OS-9 とかはそうだね。OS-9/68020 Ver. 2.2 まで使ってたけど、メモリ保護は
オプションで (SPU: System Protection Unit) と言う専用ハードウェアが必要
だったよ。

保護*も*仕事であって、保護*が*仕事ではないと思うが。
「最適化できないコンパイラはコンパイラではない」みたいな。

もうWin9Xのことは忘れよう。あれから学ぶことって何もないだろ？

過去の互換性は大事です、って事とか。
あんまし互換性を大事にすると、安定しない、とか。

Win9xは、互換性維持だけじゃなくって、軽くなければならないという命題があったため、
ああなってしまった。まだ、メモリ8M〜16Mという時代だったからね。
本当だったら、Win95なんか作らず、NTでいけばよかったのに。

>>436
NTの開発が予定より遅れたってのもあるんじゃない？
当初(88年)は91年ぐらいに発売する予定だったとか。

OSKITの使い方教えてくれ！

oskitすら使えないようじゃOS開発なんて無理だろ･･･

>>436
主要因はＭＳ社内の政治的なもの

互換と言えば、いまのNTってOS/2のプログラムの互換は取れる
ようになっていたんだっけ？　昔は OS/2 1.xのアプリも動くという
ふれこみがあったよーな・・・

いまでもあるらしいよ

低レベル・・・程度の低いプログラマのやる部分。
最下層・・・・最下層のプログラマのやる部分。
高レベル・・・一流大学を出た年収１０００万円以上のエリートプログラマの組む部分
上位層・・・・地位の高いプログラマが担当する部分。

>>443
全然おもしろくないんだけど

この前、上司に「低レベルなプログラムうんぬん…」と話したら、
もろ>>443のような解釈をされて困ってしまった(w

OS作ります。
LinuxとNetBSDでUNIXについては勉強しました。
まだまだ知識が足りないので作りながら色々と
勉強していきたいと思います。

１の言うように完全独自なんてものは到底無理なので、
L4のインターフェイスを実装するところから始めたいと
思います。www.l4ka.org

夏休みが始まる頃までには何とかしたいです。

OS作ろうって考えてるならせめてMVSくらいはかじっておいてくれ。

age

mvsか

http://homepage2.nifty.com/nowsmart/nwsos.htm

*BSDやLinuxのソース見て思うのは、ターゲットに関する
豊富な知識とOSの理論に精通してれば（この前提が大切だけど、、）、
ゲームプログラマぐらいのレベルのひとなら作れるような気がする。
それよりもゲームと違って、永続的に保守していかなくちゃ
ならないから、そういったことを意識してプログラム設計できるのか
どうかが重要かもね。

>451

　昔は「ゲームプログラマレベルの」っていうと非凡な才能を
意味しましたが、最近では馬鹿にされているみたいですね。

　ゲーム開発者が増えるにつれ「凡才」が増えたからだと思い
ます。最初は、天才的能力を持て余した人たちが行く場所だった
んでしょう。

>452
どんな業界でもそうですが、「みんなおんなじ」ではないですね。
非凡な人もいれば、馬鹿みたいな人もいます。
まとめて捕らえると偏見になりますね。

>451
OS 作りそのものは、ある一定レベル以上のプログラマなら出来る
でしょう。
しかし、概念理解が出来ないタイプのプログラマには、
「豊富で正確な知識」
を獲得すること自体が難しいのではないでしょうか。

なんといっても、実際に作ってしまえれば、全ての証に
なりますね。

>>454
ペーパーをさくさく読めるぐらいじゃないと
ちっと厳しいかもね。いまさらUNIXもどき作っても
だれも見向きもしてくれないし。

　あと、誰でも出来るとか簡単とか言う人は結構いるし、実際そうなの
かもしれないけど、じゃあなぜやらないのかと思わない？

　意味のあるほどのものを作るのが大変だからかな？

　逆に考えれば、「意味のあるほどの OS」が作れたとしたら、
評価に値するってことだよね。

>>456
そりゃ、この世界においては常識でしょ。
誰でもできることでも実際に手間かけてやった人こそが
評価に値する。

>>456
やってるのだよ
意味あるが色々なだけ
OS研究者は、自身の研究内容を実装した実証用OSは意味がある
仕事で書いてる奴は、要求機能を満たしたOSに意味がある
趣味で書いてる奴は、自己満足できるなら意味がある

>>456-457
同時に、
「意味のあるほどの何か」を設計することができる人間は、
そう多くないというのも事実だと思う。

カーネル組むのってPC何回もリブートしたりして
結構疲れるよね。最近じゃvmwareがあるから多少楽には
なったかもしれないけど。

あ、いい方法なんかあれば教えて欲しいです(^^

その辺りの苦労から、MKのバグのないカーネルコアを
まず作って、その後にOSサーバーをって話が出てきたんだろうけど、
バグのないカーネルコアを作るのがまずたいへんだよねぇ。
センスねーのか？俺（汗

>>462
デカくてバグなしより楽って話ですからね
マイクロカーネルを採用したら、いきなり簡単に作れるようになるわけじゃない
ただし、マイクロマイクロカーネルを一度書いて使いまわすという
開発スタイルでは非常に効率が上がります
つまり全部を書き下ろすために、マイクロカーネルを作ってもあまり美味しくないって話

>>463
なるほど。

Ｗｉｎ系統を含めて
「可能な限りのハードウェアをサポートする為のＯＳ」
っていうのなら、やはりキツイし、内部はぐちゃぐちゃ、
パフォーマンスも機能をかなり削ぎ落とす事によってでしか、
上げる事は普通の人間には無理だと思ふ。
一番人気有りそうなハードウェアの組み合わせ環境を
最初から想定して、ＯＳ作るのがよいとおもふ

http://www.h3.dion.ne.jp/~teruhi/
糞なｃｐｐ，ｃも書いておいたよ。恥さらし用に。
人種は大別して2種。片方に救いなどない。見極めれば見捨てるべき
人間である事は知れるだろう。よりよい社会環境を現在までいかに
あし引き続けてきた連中であるかを知るべし。小泉もそれだ。
それ以外の連中なら張り合う意味もあるのだろうけど、、、

彼らの行動理由は常に、「他人の幸せを削ぐ事」
世の中に騒乱を引きおひこさせる事。
暖かい人間には冷や水を浴びせ、クールな人間には熱湯を
注ごうとする連中。
こう書けば彼らの表情やしぐさは、呪詛用のそれから、しばらくは
元に戻るのかもしれないが。
品がないとか、粗雑とか、そういうレベルの話ではなくて、
本当に、他人を見殺してせせら笑ったり、病気を教えずに病人に
可能な限りの傷を負わせたり、幸せに感じるもの全てを奪い尽くす
ことが生き甲斐の連中。例え己の全てを失ってでも彼らはそうする。
というか、その為にこそ信用や地位や実績を積み上げる連中、イエジ。

ああ、ちなみに粗雑、品がない、わがまま、嘘好き、盗み好き、
喧嘩っぱやい等は確かに、、秩序や調和の整った社会環境でも
やや警戒されるべきだが、しかしそれは、
蔑まれるべきでも、阻害されるべきでもなく、それも個人の特性
の一つなのだろうと思われる。
何の品も誇りもないイエジはそれらを過剰に蔑み排斥した。
それらの特性が必要以上に人を傷つけたと強調し続けた。
品も誇りも汚す&破壊する事しか知らない彼らのほうが余程、、、

需要を読んだ時に彼らイエジの偽りの需要が紛れこむだろう。
好きで作っているだけなのに過剰な期待や責任を負わせるだろう。
例え完成したところで彼らが満足したり認めることは1000%、有り得ない。

久しぶりです＞氷魚

何よりも需要がない状況でなど、頑張れるわけがないし、
頑張るべき理由もないだろう。
知的資産はやはり高く評価されるべきで、、、(謎
ｃ書いてみた。
ｉｏｓｔｒｅａｍみたいなものを作るの競る？
昔、ＯＳこじ開けまくってた、頃に必要な技術では有ると
感じたから、ＯＳ作るなら余裕で作れる筈だろう。

けど言っておくけど、自分の場合もスレッド目当てのＯＳ
以前の物と、当時のそれらしか参考にはしていないし、
しても無駄だろうと思う。
ショートプログラムを参考にはできるが、糞長いコード
から学べるのはほんの一部分一部分と思われるゆえ。

＞氷魚
日本語変じゃない？

>>470
いまさらなにを･･･

>471
東南アジア系の人なの？

ジャンルはアバンギャルド。
これで十分説明になってるだろ？

>473
分からぬ。
詳細キボーヌ

アバンギャルドって死後？
そんな意味だったとは。

不毛な

ＯＨ！ＹＥＳ！

氷魚って漢字使わないんじゃなかったけ

はぁ？
確かに漢字変換面倒だから、適当にほっぽってたけど、
書こうと思えばそりゃあ書けるだろうよ。

とか言いつつ、最近紙に字を書こうとしたら、忘れている漢字が
かなりあって正直焦ったけど。
ま、周囲の人間の質が良い環境であるのならば、
また能力は変わってくるからなぁ・・特に俺の場合は。
イエジ、、、呪うのを止めるつもりはないのだろーかな、、かなり疲れる。

カーネルをC++(gcc)で組んでるやしはいるかー？

g++だろばーぁ

gnu compiler collection

Ｒｕｂｙ！！！！！！！！！！！！！！！！！！！！！！！！

ＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙ
ＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙ
ＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙ
ＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙ
ＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙ
ＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙ
ＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙ
ＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙ
ＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙＲｕｂｙ
ｖ

ｄふｙｙｋ、ｙｐｙｔ＠ｊｋ＠ｐｇｈｋんｈ：ｇん・。、￥ｑうぇｒｇ、ｐ＠いｚ

が・。えｒｊｓｚぽいぇｒｈｔ７８ｖｇｐ
あｋｊｄｆｈｖびあせｙｖ


うぇｔｌくあうぇ９８ｆｙｐ２ｑｔｄｆんｑおｐｆ
えｒｌｇ

ｃｙｄｓｔｇｒうぇ５６ｒｆ２３７５ｒ２３６６６６６６６３６６３
うぇえええええええ

例外をどうするか、と、コードサイズの肥大に悩むことになると思うわ。
例外を使わないC++という手もあるけれど…嫌だわ。

>>481
今のgccは"GNU C Compiler"ではなく"GNU Compiler Collection"だから
CもC++もObjective-CもFortranもJavaも
みんなひっくるめてgccでいいのよ。

>487
それは間違いだよ

>>487
例外は使えないだろ。
そういうコードをC++と呼びたくないのは分かるが、
現実的な課題に対してコーディングスタイルを変えられるのも
C++のメリットだと思うよ。
基本的にはtemplate, class with Cみたいな
スタイルになると思うけど、それならCとさほど変わらんでしょ。

間違は当然あるんだけど、どこがどう間違いなのか言ってくれないと困ってしまうわ。

例外を捨てると、コンストラクタのエラーはどう返すのかしら。
new(nothrow)が散りばめられたソースはホラーよ。使う方は血まみれよ。
pureなCの方がましだわ。
Stroustrupが悲しむわ。

そだなー、はて困った。
例外を否定したらnewも殆ど使えないことになってしまうのか･･･

以前のようにnewでNULLが帰ってくればいいのになぁ。

つーかおれC++のことよく分かってなーね（ｗ
もっと言語仕様知らんとだめなのは良く分かった。

>>494
オーバーロードで解決

ほっほっほ　みなさんお熱いですなあ。

今の人たちはOS＝Windows　みたいな人もいるだろうから、
「OSを書くなんてとてもとても」
という向きもありましょう。

お商売としての"OS"と、
本来のOperating-Systemと、切り離して考えてみられよ。
そして、その上で動く言語のことも、切り離して考えて見られよ。
（この先どんな言語があるかわからんですから）

ま、たまには↓昔話でも読んでひとやすみひとやすみ。


http://www.is.s.u-tokyo.ac.jp/~vu/99/jugyo/OS/

熱！

sage

Windows！

で500GET!

うぉー501

これからはLinuxでしょ、きっと。

　　　　　　　　　　　　、　き　っ　と　。
　　　　　　　　　　　i　n　u　x　　ょ
　　　　　　　　　　か　　　L　　し
　　　　　　　　　れ　　は　　で
　　　　　　　　こ　ら
　　　　　　　彡

(,,ﾉﾟдﾟ)ﾉ