OSをつくろうpart4

1 ：ひげぽん：02/11/12 19:20

独自にOSを作っているまたは、作ろうとしている人たちのための
スレッドになればと思います。

前々スレッド
OSをつくろうpart2
http://pc3.2ch.net/test/read.cgi/tech/1024411711/

前スレッド
OSをつくろうpart3
http://pc3.2ch.net/test/read.cgi/tech/1027080631/

2 ：デフォルトの名無しさん：02/11/12 19:24

調子どう？
がんばってねん。

3 ：ひげぽん：02/11/12 19:25

■勝手にリンク
OSASK
http://www.imasy.or.jp/~kawai/osask/
NWSOS
http://homepage2.nifty.com/nowsmart/nwsos.htm
????
http://sourceforge.jp/projects/higepos/

4 ：FreeDOS教徒：02/11/12 19:43

新スレおめ～♪

5 ：ひげぽん：02/11/12 20:15

>>4
ありがとうございます。
ブートコード問題が一段落したのでほっと一息です。
ついでにA20問題も一応対処しました。

6 ：うえぽん：02/11/13 01:17

＞ひげぽん
忙しいとは思いますが、がんばってください。
僕も大学の後半からプログラミング初めて、
趣味でi486(386)エミュレーションなど体験し
遊びました。（なかなか安定しませんが）
結局マクロアセンブラなどはあまり解りませんが、
楽しく板を読ませて頂いております。
忙しいけど、またエミュはじめたいなあ。

7 ：デフォルトの名無しさん：02/11/13 02:39

2げっと

8 ：LightCone ◆sSJBc30S5w ：02/11/13 11:10

　firstboot.asm の readsector ですが、bx=0以外のときには対応して
ないと思うのですが、それより問題になると思うのが、

laddr = (es * 16 + bx)

から始まるバッファが、64KB の境界をまたぐとき、PC/AT 機の BIOS
が対応していない（機種がある）ことです。

>Because of the architecture of the DMA channel, an error will
>occur if the buffer in memory for the sectors overlaps a 64K page
>boundary. A 64K page boundary is a memory location which is one of
>the following (10000h, 20000h, 30000h, etc.). Ensure that no part
>of your buffer falls on such a boundary. If it does, create a new
>buffer or start the buffer just after the boundary.

とあります。

9 ：LightCone ◆sSJBc30S5w ：02/11/13 11:16

　お節介なようですが、もう一つ気になる所があります。

　以前にも書きましたが、cf = 1 で返ってきた時の処理です。PC/AT の
DISK BIOS は、失敗した時に自分でリトライするのですが、単に繰り返すだ
けでは駄目で、ah = 0 で、"RESET" する必要があることです。
たしか、ハード的に現在のシリンダの絶対位置を取得することができないが、
シリンダ０へだけは正確にシークできるそうで、"RESET"はそうする
そうです（相対的には、盲目的にではあっても正確に動かせるそうです。）。

以下を参考までに。

>If an error is encountered reading a sector, use Service 0 to
>reset the drive and retry the operation. It is recommended that at
>least 3 retries be attempted before an error is signalled, since
>the error may have resulted from the diskette motor not being up
>to speed.

10 ：FreeDOS教徒：02/11/13 12:59

>>LightCone氏
そこら辺は私が提供したのですが、明らかに手抜きしてました。

DMA境界をまたぐ時これじゃ問題ですよね。
早いうちに修正します。

11 ：LightCone ◆sSJBc30S5w ：02/11/13 13:29

>>10

FreeDOS教徒様。

少なくとも、今のところ、

>mov ax, 0x0100 ; 512 byte from 0040:0000 is BIOS work area
>mov es, ax ; ... but usually it wasn't use only 256 byte
>xor bx, bx
>mov ax, 0x0001 ; read kernel from next sector
>mov di, 0x0040 ; 64 sectors
>call readsector

となっていて、512 BYTE * 64 SEC = 8000h バイトに対して、
ES:BX=100:0 ---> 線形アドレス=1000h

ということで、1000h～9000h のバッファなので、#8の方は現状は問題ない
んですね。

12 ：FreeDOS教徒：02/11/13 18:06

>>11
まだ32KB程度ですが、すぐ64KBを超えると思います。
640KBに近付いたらまた別の対策が必要でしょうね。

13 ：LightCone ◆sSJBc30S5w ：02/11/13 21:46

>>12
　多分、基本的なファイルシステムを含めて、カーネルの基本部分は、
640 KB のイメージに収まるでしょうから、それを超える部分は、
カーネル起動後の正式なファイルシステムを利用できるのではないで
しょうか。

　NWSOS では、まず、BIOS がブートセクタを読み込み、
そのブートセクタが、2KB程のローダーを読み込んで、
さらに、そのローダーが、FAT 情報を見ながら、通常のファイル形式の
カーネルイメージ(Ver 0.030現在で110KB程度)をロードする仕掛けを
採っています。

　JIS フォントを 216KB ロードする必要があるのですが、それは、
カーネルの持つ正式なファイルシステムを用いてロードしています。
フォントが読み込まれるまでは、まだ、表示系統がある意味では不完全
な状態ではあるのですが、もし、このときにエラーが起きて表示するときは、
JIS FONT相当の部分は、いわゆる「豆腐」を表示すれば暴走は防げます
ので。

14 ：ひげぽん：02/11/13 23:22

>>6 うえぽんさん
ありがとうございます、私もなかなかアセンブラが得意でなく
苦労しています(→勉強しろって感じですが･･･)
この機会にまた始められたらどうでしょうか。

15 ：ひげぽん：02/11/13 23:27

LightConeさん、FreeDOS教徒さん

ひげぽんが考慮漏れしているところをいろいろとご指摘
していただきありがとうございます。

とりあえずLightConeさんのおっしゃっている

>　多分、基本的なファイルシステムを含めて、カーネルの基本部分は、
>640 KB のイメージに収まるでしょうから、それを超える部分は、
>カーネル起動後の正式なファイルシステムを利用できるのではないで
>しょうか。

ということを踏まえて、ファイルシステム部構築に取り組もうかと思っています。

16 ：LightCone ◆sSJBc30S5w ：02/11/14 08:35

>>14
　私は、アセンブラは擬似命令などは結構慣れていても、アセンブラで
書くと良く間違いをするタイプの人です。大き目の関数などだと、
C言語で書いたときより、開発やデバッグに何倍も時間がかかります。

特に最初から書いていくときはまだしも、後から修正したい場合なども、
アセンブラの場合は、関数全体のソースコードをかなり理解してから
でないと大抵正しく修正できないのでめちゃくちゃ大変です。

17 ：LightCone ◆sSJBc30S5w ：02/11/14 08:40

>>16
例えばの話、FILE_MAX みたいなマクロがあったとしても、GREP置換で、
g_maxFile みたいな変数に置き換えて、再コンパイルするだけで修正
完了となる所が、アセンブラだと、一々ソースを眺めて

xxx [ebx],FILE_MAX

みたいな部分なら、
mov eax,g_maxFile
xxx [ebx],eax
見たいに修正するわけですが、もし、eax が使われているなら、
ecx や edx が使えるかどうか探してどれも駄目なら、push eax, pop eax
で囲って、というような判断を手作業でやっていくしかないですから、
めちゃくは大変です。

18 ：ひげぽん：02/11/14 23:35

>　私は、アセンブラは擬似命令などは結構慣れていても、アセンブラで
>書くと良く間違いをするタイプの人です。大き目の関数などだと、
>C言語で書いたときより、開発やデバッグに何倍も時間がかかります。

これは分かります。
そんなに大きいものは書いたことがありませんが
いくら賢く書いたつもりもでもやはりメンテナンス性は
なかなか上がらないです。

>push eax, pop eaxで囲って
これは良く見かけますね・・・

賢い人の書いた良いソースに触れる機会があって、さらにバリバリ自分でも
書くようにすれば多少は進歩するとは思うのですが
どちらもやっていません･･･

19 ：デフォルトの名無しさん：02/11/15 05:17

ファイルシステムをカーネルには組み込まないのが一番だと思われます。
スレッド管理、プロセス管理、メモリ管理などのみをカーネルに組み込み
ファイルシステムは、特殊１プロセスに過ぎない存在にすることをお奨めします。

ちなみにlinuxのカーネルは圧縮しても512kbを越えて大変なことになった時期が
あるそうです

20 ：LightCone ◆sSJBc30S5w ：02/11/15 08:04

>>519
マイクロカーネルですね。

NWSOSでは、今のところカーネル内に持っていますが、DLL形式にして
分離すれば効率を落とさずに済むのでしょうか。

そういえば、マイクロカーネル方式だと、瞬間瞬間では、1プロセスのみが、
ファイルシステムのコードを走行するのでしょうか。もしそうだとすると
並列製が落ちる可能性はありませんか。

モニリシックカーネルだと、複数プロセスが同時にカーネルコードを
走行できるので、タスク間の並列性が上がったりするのではないかと
思うのですが。

21 ：うえぽん：02/11/15 14:31

>>14 ひげぽんさん
>>6 では敬称略などしてしまい、申し訳ありませんでした。
x86エミュレーションの保護モード部の実装のために、マニュアルでは
解りにくい動作を実機で調べたりするのですが（i486搭載pc9821使用）
タスクやページングを使おうとすると DDEB.EXEなどではもうお手上げです。
エミュレーションの方はもう少し動作原理を理解すれば、
安定性が上がりそうな気もしますが・・・実モード部も遅くて不安定だし（泣）

>>16 LightCone ◆sSJBc30S5w さん
なるほど。
かなりの経験者の方でも、Ｃのように気軽に組んでいくのではなくて、
根気が必要なわけですね。たしかにマクロアセンブラでも、レジスタ資源
が限られているわけだから、そういった苦労がつきものですね。

擬似命令も結構わからない部分が多いですが、少しづつ勉強しながら
レスを読ませていただきます。

22 ：デフォルトの名無しさん：02/11/15 14:32

ﾗｲﾄｺｰｿﾀﾝのﾏﾝｺ見たい。

23 ：超先生＠OS板 ◆leaf/RYZgY ：02/11/15 17:05

>そういえば、マイクロカーネル方式だと、瞬間瞬間では、1プロセスのみが、
>ファイルシステムのコードを走行するのでしょうか。もしそうだとすると
>並列製が落ちる可能性はありませんか。

subsystemサーバープロセスのスレッド数を、プロセッサ数×n (※)などで
決め打ちしておき、message-queueで処理するとか。(nまで再入可能)

※ threadが極めて軽量な実装ならば、ユーザー側スレッドのトータル数でもいいかも。

24 ：ひげぽん：02/11/15 20:02

>>19さん曰く
>ファイルシステムをカーネルには組み込まないのが一番だと思われます。
>スレッド管理、プロセス管理、メモリ管理などのみをカーネルに組み込み
>ファイルシステムは、特殊１プロセスに過ぎない存在にすることをお奨めします。

LightConeさん曰く
>マイクロカーネルですね
以下略ですすいません。

higeposは一応マイクロカーネルを目指しています。
また、ファイルシステムが容易に差し替え可能である手段として
ファイルシステムをカーネルに組み込まないというのはありだと思っています。

そのばあいは、やはりプロセス管理からはじめないといけないですよね。
minixのファイルシステムとカーネルの関係がいまいちつかみきれていないので
勉強中です。

25 ：ひげぽん：02/11/15 20:05

>>21うえぽんさん
>>14 ひげぽんさん
>>6 では敬称略などしてしまい、申し訳ありませんでした。
全然気にしてないです、というかひげぽんで良いですよ。

>x86エミュレーションの保護モード部の実装のために、マニュアルでは
>解りにくい動作を実機で調べたりするのですが（i486搭載pc9821使用）
この辺の姿勢には全く頭が下がります。見習わなくては･･･

26 ：ひげぽん：02/11/15 22:34

プロセス管理のほうを
ファイルシステムよりも先に実装したほうがよさそうな気がしてきました。
ここは考えどころですね。
マイクロカーネルの勉強もしないといけない。

27 ：デフォルトの名無しさん：02/11/16 00:38

ひげぽん、この辺よんでみなよ。
http://www.qnx.co.jp/products/manuals/index.html
おもしろいよ。

ところで、たんねんばうむの本はどのくらい進んだ？

28 ：デフォルトの名無しさん：02/11/16 00:58

>>27
こんなおもしれーマニュアルが、、、知らんかった。
情報ｻﾝｸｽﾎﾟ

29 ：ひげぽん：02/11/16 12:59

>>27
有用なリンク紹介ありがとうございます。

>ところで、たんねんばうむの本はどのくらい進んだ？
一応ソース以外は、斜め読みしたのですが
結局辞書代わりになっていますね。
あの辺にこんなことが書いてあったはず、みたいな感じで
何回も読み返しています。

30 ：22：02/11/16 13:47

おい、乱子交濡(ﾗｲﾄｺｰﾝ)。
てめえさっさとやらせろやおけ！

31 ：ひげぽん：02/11/16 16:12

動作テストは、主にbochsで行っています。
そして大きな変更があったときや、CVS commitする前に
実機で動作確認を行っています。

他のOS製作者の方々は、どういう手段を用いているのでしょうか。
bochsではいずれ限界が来るのかな･･･
vm wareも以前評価版を入れていましたが、本格的に使うとなると
買わなきゃいけないんでしょうね。
OS開発者はタダ！！みたいなライセンスではないだろうな･･･

32 ：デフォルトの名無しさん：02/11/16 16:52

そのうちどうしても実機が必要になると思われる。

33 ：デフォルトの名無しさん：02/11/16 17:11

VS.NETのMSDNデラックスっていうのを買って登録したら
OSやらサーバーやらオフィスやらいろいろ送られてきたから、
何人かで分けて使ってるけど、これって違法じゃないよね？
マイクロソフトから何か言われた人いる？

34 ：デフォルトの名無しさん：02/11/16 17:20

http://pc3.2ch.net/test/read.cgi/tech/1037433921/のコピペですな

35 ：デフォルトの名無しさん：02/11/16 17:32

>>34
オマエうざいよ。

36 ：デフォルトの名無しさん：02/11/17 04:57

>>30
マムコ見たかったんじゃないの？

37 ：ひげぽん：02/11/17 14:10

OS名を Mona に正式改名いたしました。

sourceforge.jpのPJも移動しました。
http://sourceforge.jp/projects/mona/

今後ともよろしくお願いいたしますm(__)m

38 ：ひげぽん：02/11/17 18:02

当面の目標は、タスク(プロセス)管理です。
2つのタスクの実行の切り替えの実験から始まると思います。
一から勉強します。

39 ：デフォルトの名無しさん：02/11/17 20:15

>>37
で、Monaの由来どうするの？

Micro Kernel
Operating System
with
Network Suit
Architecture

とかにするの？

40 ：ひげぽん：02/11/17 20:59

こんばんは

>Micro Kernel
>Operating System
>with
>Network Suit
>Architecture

なかなか良いですね
がんばって早く、Network Suitにしないと（笑）

41 ：デフォルトの名無しさん：02/11/17 22:19

MONA
OS is
Not
Abone

MONA OSは落ちません。

42 ：デフォルトの名無しさん：02/11/17 22:24

>>41
ﾜﾗﾀ

43 ： ◆Db/E231N/A ：02/11/17 22:30

MONA
OS
does
Never
Abone
は、どうよ?

44 ：デフォルトの名無しさん：02/11/17 22:43

>>43
決まり。

まぁ、落ちるんだろうけどな。

45 ：デフォルトの名無しさん：02/11/17 23:04

2ch生まれだから『MONA』それでいかんの？

46 ：ひげぽん：02/11/17 23:24

>>41
>>43
いいですねぇ。

>>44
>まぁ、落ちるんだろうけどな。
なるべく落ちないようにがんばりまふ。

>>45
>2ch生まれだから『MONA』それでいかんの？
という意見もありますね。

47 ：デフォルトの名無しさん：02/11/17 23:48

MONA・・・モナｰ・・・マナー・・・マナマナ・・・ｶﾞｸｶﾞｸ(((ﾟдﾟ;)))ﾌﾞﾙﾌﾞﾙ

48 ：デフォルトの名無しさん：02/11/18 00:10

MinOr kNown Application

49 ：デフォルトの名無しさん：02/11/18 00:31

MONA・・・モナｰ・・・マナー・・・マナカナ・・・ｶﾞｸｶﾞｸ(((ﾟдﾟ;)))ﾌﾞﾙﾌﾞﾙ

50 ：デフォルトの名無しさん：02/11/18 04:13

>>43
doesは不要かと。

Mona is a Operating system Never Abone

とか。
というかaboneなどという英単語は無いし。
Abortならわからんではない。

MOna is Not A giko
MOna is Not Asso

とか。

MOna is Not an Application
Mona is an Operationg system, Not an Application

あれ？これｶﾞｲｼｭﾂかな？

51 ：デフォルトの名無しさん：02/11/18 08:20

＞というかaboneなどという英単語は無いし。

いや、あってたまるか。と。

52 ：ひげぽん：02/11/18 23:07

>>50
>>51
笑いました。
ところでvmwareって高いですね。ちょっと手が出ない（笑）

LightConeさん
nwsosのソースって公開されているんでしょうか。
ちょっと見てみたいなあと最近思います。
すんません独り言です、気にしないでください・・・

53 ：デフォルトの名無しさん：02/11/18 23:31

>>52
nwsosは商用を目指しているので、ソース公開はあり得ないんじゃないかな？
個人的には、商用クローズ開発と、オープン開発、お互いにどういう経路で
発展していくか？に興味あるので、nwsosとmonaに激しく注目している。

今のところ、さすがにnwsosとは比較にならない工事段階だけど、
比較対照としてはおもしろいと思ってます。

54 ：デフォルトの名無しさん：02/11/18 23:35

簡単にソース見ちゃ詰まらないと思いますよ。
現在の段階では、識者からアドバイスを受けて成長するのが一番。
このスレの存在意義に、ひげぽんさんの成長も含まれていると思う漏れ。

55 ：ひげぽん：02/11/18 23:42

>>52
>nwsosは商用を目指しているので、ソース公開はあり得ないんじゃないかな？
>個人的には、商用クローズ開発と、オープン開発、お互いにどういう経路で
>発展していくか？に興味あるので、nwsosとmonaに激しく注目している。
そうですよね。
商用であるということ＆今までクローズでやってきた事から
オープンにするメリットは少ないかもしれませんね。

>簡単にソース見ちゃ詰まらないと思いますよ。
>現在の段階では、識者からアドバイスを受けて成長するのが一番。
>このスレの存在意義に、ひげぽんさんの成長も含まれていると思う漏れ。
そうなんですよね。
簡単にソースを見ちゃあいけない・・・分かっています。
ただ、煮詰まったときに賢い人の書いたソースを見ると
目から鱗ですごく自分の成長になるんですよね。
もう少し煮詰まるまでがんばってみます。

56 ：デフォルトの名無しさん：02/11/19 01:32

Mysterious Occult Night Affair

神秘的で超自然的な夜の出来事

57 ：デフォルトの名無しさん：02/11/19 01:35

つーか、意図的にｘはずしたってことはPOSIX互換にしたくないってことなの？？？

なんのために？？？

58 ：LightCone ◆sSJBc30S5w ：02/11/19 07:32

>>そういえば、マイクロカーネル方式だと、瞬間瞬間では、1プロセスのみが、
>>ファイルシステムのコードを走行するのでしょうか。もしそうだとすると
>>並列製が落ちる可能性はありませんか。
>subsystemサーバープロセスのスレッド数を、プロセッサ数×n (※)などで
>決め打ちしておき、message-queueで処理するとか。(nまで再入可能)
>※ threadが極めて軽量な実装ならば、ユーザー側スレッドのトータル数でもいいかも。

ご返答有難うございます。

これは、例えば、ファイルシステムのプロセスが、内部的に固定的に、
5個のスレッドを持っているような状況を想像すればいいのでしょうか。

　こういう仕組みでも一応「１プロセス」と言えなくもないわけですね。
これだと、確かに並列性は落ちないかもしれませんね。

　マイクロカーネルは、それぞれのサブシステムがシングルスレッドしか
持ってないのだとに思っていたので、もっと並列性が落ちるのかと思って
ました。

59 ：LightCone ◆sSJBc30S5w ：02/11/19 07:35

>>52
残念ながら、今のところ公開はされてません。

ところで、公開されていると、逆に詰まらなくなったりしませんか？

60 ：LightCone ◆sSJBc30S5w ：02/11/19 07:50

>>19, >>23

なんだか、NWSOSも、マイクロカーネルを採用したくなってきました。

　ファイルシステムのプロセスが、メモリ空間的に分離されている別
プロセスのバッファを扱う仕組みを１分くらい考えてみたのですが、
どのようなものが考えられるでしょうか。

　ちょっと思いついたのは、個々の一般ユーザープロセス内に、DLL の形で
「ファイルシステム-サポートライブラリ」みたいなものをロードして、
ファイルシステム本体のプロセスと通信するようなものです。
　サポートライブラリ自体は、それぞれのユーザープロセスの全メモリが
可視なので、共通メモリなどを介して（コピーして）ファイルシステム本体
と通信をする、という方法です。
（ちょっと難しくなりそうですが、ページングを駆使すれば、コピーせずに
済ますこともできるかもしれませんが。）

　仮想メモリ(固定ディスクとのSWAP)などとの連携も難しそうですが。

61 ：LightCone ◆sSJBc30S5w ：02/11/19 07:55

>>55

>煮詰まったときに賢い人の書いたソースを見ると
>目から鱗ですごく自分の成長になるんですよね。

　私のコードにも恥かしながら汚い場所がいっぱい有り、それが公開に
踏み切れない理由の一つでも有ります。

　他人のソースを見ると目から鱗、というのは、確かにありますね。

62 ：デフォルトの名無しさん：02/11/19 08:51

、、、
このスレでもやってるな
58と60、59と61は一つのレスにまとめられるだろうに。
行き当たりばったりでレスせずに、もっと思慮を入れろよ

63 ：LightCone ◆sSJBc30S5w ：02/11/19 10:53

>>62
「まとめた方が良い」ということが絶対的に正しいのですか。

64 ：デフォルトの名無しさん：02/11/19 11:29

少なくともﾚｽ数の節約にはなるだろ

65 ：LightCone ◆sSJBc30S5w ：02/11/19 11:36

>>64
逆に、スレを分けた方が分かりやすいと思う人がいたとしたら？

66 ：デフォルトの名無しさん：02/11/19 11:43

それは文章の書き方次第。工夫すれば読みやすい文章はいくらでも書ける。

67 ：デフォルトの名無しさん：02/11/19 11:52

>>65
とりあえず、文章書いたあと30分位置いてみる。
これくらいの流れなら、多少寝かせても亀になることはなかろう。

68 ：LightCone ◆sSJBc30S5w ：02/11/19 11:56

>>67
文章が汚い、読みにくい、まとまりが無い、ということは認めます。
そういうことなら納得です。ついつい、殴り書きみたいな感じで書いて、
一度も読み返さない癖がありますので、、、（読み返すと何故かイライラ
するんです。）。

69 ：デフォルトの名無しさん：02/11/19 11:56

今くだらん論争でレス数を無駄に消化してるという自覚はないの？お前ら。

70 ：デフォルトの名無しさん：02/11/19 20:02

少々レスが多いほうが、見てて楽しいのですが。
技術的なｳﾝﾁｸばかりじゃ飽きますし、頭も痛くなります。

71 ：デフォルトの名無しさん：02/11/19 21:57

レスが多いのは結構な事だが、
同一人物の連続投稿はウザいだけ

72 ：ひげぽん：02/11/19 23:19

プロセス管理について勉強しつつ
あーでもないこーでもないと考えるのが楽しいですね。
二つのプロセスの切り替え実験をやろうと思うのですが
設計の段階でいろいろと欲張りすぎて・・・破綻
の無限ループに陥ったりします。

73 ：デフォルトの名無しさん：02/11/19 23:30

自作自演大好きなひげぽんがウザいだけ
定期ageするひげぽんがウザいだけ

74 ：デフォルトの名無しさん：02/11/20 00:09

荒れてきたね（￣ー￣）ﾆﾔﾘｯ

75 ：デフォルトの名無しさん：02/11/20 00:23

>（ちょっと難しくなりそうですが、ページングを駆使すれば、コピーせずに
>済ますこともできるかもしれませんが。）
既存のOSには見られない傾向ではあるんですが、ここは思い切って
アプリケーションが読み込みエリアを指定することができないファイルAPI作ってみては
いかがでしょ？通常、freadなどはポインタも指定しますが、これを指定させない。
で、かわりに、FileOpen時にメモリハンドラを貰う。
アプリはこのメモリハンドラ経由でアクセス。
OSがメモリプールを責任もって確保。

posixにあるようなfreadとかって前時代的な仕様だと思うんですよ。
アプリ屋のミスで不法なメモリでも平気でガツガツ書き込んでしまうし。
保護例外で止まってくれればまだありがたいんですがね。

76 ：LightCone ◆sSJBc30S5w ：02/11/22 10:03

>>75
>アプリケーションが読み込みエリアを指定することができないファイルAPI作ってみては
>いかがでしょ？通常、freadなどはポインタも指定しますが、これを指定させない。
>で、かわりに、FileOpen時にメモリハンドラを貰う。
>アプリはこのメモリハンドラ経由でアクセス。
>OSがメモリプールを責任もって確保。

　一度聞いてみたいアイデアなような気がしますので、
ここでおっしゃる「メモリハンドラ」というものの詳細や、この方式での
具体的なファイルアクセスの手順を聞ければ幸いです。

>posixにあるようなfreadとかって前時代的な仕様だと思うんですよ。
>アプリ屋のミスで不法なメモリでも平気でガツガツ書き込んでしまうし。
>保護例外で止まってくれればまだありがたいんですがね。

アプリ側が不法なバッファアドレスを指定した場合、fread() API 内部で、
スーパーバイザ権限で「身代わりアクセス」してしまうことを指摘されて
いるのですね。

ご存知かもしれませんが、これを防ぐ手は一応存在していて、API の処理冒頭
で、メモリが合法かどうかをソフト的にチェックするルーチンをかませば、
跳ね返せます。CPUの保護機能だけでは無理で、通常のCPU命令を用いて
ページテーブルやセグメントの属性やフラグ類をチェックしなければならない
ので、確かに煩わしいのですが。

77 ：ひげぽん：02/11/23 23:31

暫定版PJホームページを公開しました。
たいしたコンテンツはありませんが、最新版ブートイメージが
ダウンロードできます。
http://mona.sourceforge.jp/

タスク切り替えを試みているのですが
実際の切り替え部分(セグメント間ジャンプ)て、
インラインアセンブラでも可能でしょうか？
いろいろとやっているのですが、もし不可能なことを
試みているのであれば、方向転換が必要です。

78 ：LightCone ◆sSJBc30S5w ：02/11/24 00:52

>>77

>タスク切り替えを試みているのですが
>実際の切り替え部分(セグメント間ジャンプ)て、
>インラインアセンブラでも可能でしょうか？

　単体のアセンブラでさえ、通常はOS作成を前提にしていない場合が多い
ため、far jmp、その中でも特殊セグメントへの jmp 命令は記述が無理か、
または、出来たとしても特殊なOBJファイルを掃いてしまう場合があるため、
一番安心なのは、db 命令で直接埋め込む方法かもしれません。

　あと、IA32の場合、タスク切り替え用の jmp 命令は、通常の命令の
組み合わせで書けてしまいます。フラグ類の設定を通常命令の組み合わせ
でやってしまうだけです。実はそちらの方が楽だったりします。

79 ：LightCone ◆sSJBc30S5w ：02/11/24 01:03

>>78
　IA32には、「タスク間jmp/call」「レベル遷移jmp/call」など色々
用意されていますが、なんのことはない、メモリ中のデータ構造のフラグ
変更と、レジスタセットの値の変更を超えるものではないんですね。

　ページディレクトリの物理アドレスを保持するcr3、ローカルセグメント
のテーブルを設定する ldtr、Protect/V8086 モードを区別するeflags、
TSSセグメントセレクタtr などの設定を変えることや、全レジスタの
保存・復帰以外とには、特にやることは無かったと思います。

　（tr から全ての情報がたどれますが、ltr 命令だけでは、確かcr3や、
ldtr は変更されなかったような気がします。）

80 ：ひげぽん：02/11/24 18:46

LightConeさん

>　単体のアセンブラでさえ、通常はOS作成を前提にしていない場合が多い
>ため、far jmp、その中でも特殊セグメントへの jmp 命令は記述が無理か、
>または、出来たとしても特殊なOBJファイルを掃いてしまう場合があるため、
>一番安心なのは、db 命令で直接埋め込む方法かもしれません。

目から鱗です。db命令で埋め込むとは気づきませんでした･･･
最悪の場合この手があるのですね。ありがとうございます!!!

>　あと、IA32の場合、タスク切り替え用の jmp 命令は、通常の命令の
>組み合わせで書けてしまいます。フラグ類の設定を通常命令の組み合わせ
>でやってしまうだけです。実はそちらの方が楽だったりします。

これは一応認識していたのですが、
たしかに、おっしゃる通りかもしれません。

81 ：ひげぽん：02/11/24 18:48

>>78, 79
おかげでProcessManagerの設計指針が見えてきました。
ありがとうございます。

82 ：ひげぽん：02/11/25 00:55

monaでは
secondboot.asmにてgdt関連の設定を行っています。
dw gdt_end - gdt0 - 1 ; gdt limit
dd gdt0 + 0x100 * 16 ; start adderess
プロテクトモード移行後
インラインアセンブラで
asm volatile("sgdt %0\n"
: /* no output */
: "m" (gdtr)
);
_sys_printf("gdtr.limit = %d\n", gdtr.limit);
_sys_printf("gdtr.base = %d\n", gdtr.base);
とやってみると
gdtr.limit = 31
gdtr.base = 0
と表示されます。
limitは意図どおりの値なのですが
baseの値が0というのが違和感があります。
何か大きな勘違いをしてそうで・・・

83 ： ◆sVYyxB.646 ：02/11/25 09:31

trの参照先のTSSが32bitならcr3があるよ。
ldtrは使ってないんで覚えてないがあるはず。。。

84 ：デフォルトの名無しさん：02/11/25 20:28

ぶー何処いった？

85 ：デフォルトの名無しさん：02/11/25 23:04

>75 じゃないから、違っているかもしれないけど...

>>76
> 　一度聞いてみたいアイデアなような気がしますので、
> ここでおっしゃる「メモリハンドラ」というものの詳細や、この方式での
> 具体的なファイルアクセスの手順を聞ければ幸いです。

メモリハンドラは、単なるポインタでいいと思う。C で書けば...

File F = fopen("test.txt", "r");
char *p = fread(F, 100);

とかすれば、OS が 100バイトの領域を確保して、そこにデータを読み込んでから、そのアドレスを返してくれるという感じかと...。
C だと、free(p) とかしないとダメだけど、Java とかならそれも必要ないだろうし。これで、fread() が間違ったアドレスにデータを書き込んでしまうことは防げるでしょ ?

> アプリ側が不法なバッファアドレスを指定した場合、fread() API 内部で、
> スーパーバイザ権限で「身代わりアクセス」してしまうことを指摘されて
> いるのですね。

今時、そんなタコな OS は無いでしょう。当然...

> ご存知かもしれませんが、これを防ぐ手は一応存在していて、API の処理冒頭
> で、メモリが合法かどうかをソフト的にチェックするルーチンをかませば、
> 跳ね返せます。

ぐらいはやってはず。そうではなく、fread() に間違ったアドレス指定して、自分で使う領域を壊したりするのを防ぎたいんだと思う。最近のコンピュータウィルスで使われるバッファーオーバーランとかを避けたいだけじゃないでしょうか。

> CPUの保護機能だけでは無理で、通常のCPU命令を用いてページテーブルや
> セグメントの属性やフラグ類をチェックしなければならないので、確かに
> 煩わしいのですが。

プロセサによっては、保護機能を使えるのもありますよ。(68K の moves とかね。)

86 ：ひげぽん：02/11/25 23:59

>>82
新たにTSSを追加をする場合
dt分のスペースをお尻に確保しなければならないことに気がつきました。
secondboot.asmで仮に設定しておいて
C++に移行してからもう一度設定しなおしたほうがいいのでしょうか。
うーん勉強が足りません。

87 ： ◆sVYyxB.646 ：02/11/26 11:24

バッファを固定にしてユーザーモードからバッファを転送すれば何も考えなくても保護機能が動きます。(*ﾟーﾟ)
少し無駄ですが、、、

88 ：ひげぽん：02/11/26 21:05

今日本屋で久しぶりに詳解Linuxカーネル
を立ち読みしてみました。
初めて読んだときはさっぱり分からなかったですが
難易度的にちょうど良く、自分の知りたいことが
たくさん書いてあるので欲しい。。。でも高い。
http://www.amazon.co.jp/exec/obidos/tg/detail/-/books/4873110483/reviews/ref%3Ded%5Fer%5Fdp%5F1%5F1/249-3833329-4800325

どこかの古本屋に売ってないかな･･･
図書館でも良いな。

89 ：デフォルトの名無しさん：02/11/27 07:32

>>88
あれってソースがただ印刷されて、コメントが日本語訳されてるだけじゃなかった？
役に立つような解説はなかったような。
カーネルをダウンロードして読むってのじゃだめなのかな？

90 ：89：02/11/27 07:35

>>89
こっちと勘違いしてた。上のは見たことない。
http://www.amazon.co.jp/exec/obidos/ASIN/4797820063/qid=1038350048/sr=1-6/ref=sr_1_2_6/250-3155597-6663410

91 ：デフォルトの名無しさん：02/11/27 07:46

ＢＳＤだけどこれがお勧め
http://www.ascii.co.jp/books/detail/4-7561/4-7561-3313-4.html

92 ：LightCone ◆sSJBc30S5w ：02/11/27 10:47

>>88
詳細Linuxカーネル 5800円：高いですが参考になりそうなので一ヶ月ほど前に購入。
Linux2.4 インターナル 3200円:内容は上記より少なめですが、短いので読みやすいかも。

OS そのものとは関係有りませんが、SHELL プログラミングでお勧めなのが、

SOFT BANK「入門UNIXシェルプログラミング」Bruce Blinn著山下哲典訳

93 ：LightCone ◆sSJBc30S5w ：02/11/27 11:19

>>87
　（恐らく）転送時間が1レベル増えるであろうことを気にしないなら単純でよさそうな方法
ですね。

　セクタの内容をキャッシュするセクタバッファの他に、ファイルごとに
キャッシュするファイルバッファというものがあるそうですが、後者を
うまく使えばバッファの転送時間もかなり減らせるかもしれませんが。

94 ：LightCone ◆sSJBc30S5w ：02/11/27 11:50

>>85

>そうではなく、fread() に間違ったアドレス指定して、自分で使う領域を
>壊したりするのを防ぎたいんだと思う。最近のコンピュータウィルスで使わ
>れるバッファーオーバーランとかを避けたいだけじゃないでしょうか。

fread()の場合は取得サイズをアプリ側が指定するので特に問題は
ないと思うのですが、OS側から可変長のデータを取得する時には
その問題を感じます。

　例えば、何らかの文字列データ(例では他のタスクの名称)をOSから
取得したい時、APIによっては次のような形式を用いますが、ちょっと問題
を感じます。

<<続く>>

95 ：LightCone ◆sSJBc30S5w ：02/11/27 11:51

<#94の続き>

//int GetTaskName(HTASK hTask, char *pFilename);

void PutTaskName(HTASK hTask)
{
int size = GetTaskName(hTask, NULL);
if (size == 0) {
put_err("hTask is wrong?");
}
char *pName = malloc(size + 1);
if (ptr == NULL) {
put_err("Memory shortage!!");
}
else {
GetTaskName(hTask, pName);
printf("The name of task(%08X) is %s\n", hTask, pName);
free(pName);
}
}

一言メモ:
　GetTaskName(hTask,pName)は、pName にNULLを指定すると、
受け取るタスク名の長さを返す。通常、二度呼び出して、pNameのバッファ
をアプリ側が確保する。

96 ：LightCone ◆sSJBc30S5w ：02/11/27 11:51

<#95の続き>

　ここで問題となるのは、hTaskの名前が二度のGetTaskName()呼び出しの
間に変化する可能性です。起動後のタスクではタスク名が絶対変化しないよう
なシステムだと問題なくても、SetTaskName()のようなAPIが用意されている
場合に問題が起きます。
　もし、今の例の様に、GetTaskName()を二度呼ぶような仕様だと、
何らかのロック処理が必要になるはずですが、現実のよく知られたOSでは
私の知る限りそれが出来ないケースがあります。

このような場合には、

const char *GetTaskName2(void);

のようなAPIの方が簡単では有ると思います。ただし、これにも短所が
あります。空システムメモリ空間が圧迫される可能性があることです。

97 ：ひげぽん：02/11/27 23:11

>>90
>こっちと勘違いしてた。上のは見たことない。
おお、こんなのもあるんですね。
指定されたURLのレビューを見ると詳解の後に
読むことを薦めていますね。

>>92 LightConeさん
>詳細Linuxカーネル 5800円：高いですが参考になりそうなので一ヶ月ほど前に購入。
えっと、だいぶ背中を押されました（笑）
たぶん買います、いやきっと買うでしょう。

>OS そのものとは関係有りませんが、SHELL プログラミングでお勧めなのが、
>SOFT BANK「入門UNIXシェルプログラミング」Bruce Blinn著山下哲典訳
これ会社の同僚が持っていた気がします。仕事でcshを使うので
ちょっと見せてもらってみます。

98 ：ひげぽん：02/11/28 00:10

>>91
>ＢＳＤだけどこれがお勧め
>http://www.ascii.co.jp/books/detail/4-7561/4-7561-3313-4.html
これ安いですねぇ。
内容の難易度的にはどうなんでしょうか。
今度本屋で探してみます。

99 ：LightCone ◆sSJBc30S5w ：02/11/28 02:13

>>97
　OS作りでは、実はコマンドラインSHELLがかなり重要なのではないかと
思えてきた今日この頃です。

　UNIX好きの人でも、CYGWIN環境があれば満足してしまう人も多いようで、
一番大きな理由が、UNIX互換のシェルが使えるからだそうです。

　UNIXは、カーネルも優れた側面を持っていると思いますが、
シェル、特にシェルスクリプトの機能（その一行切り出しとしての
コマンドライン解釈部）が強力なことも見逃せないと思います。

　それにしても UNIX のシェルはいいですね。

100 ：デフォルトの名無しさん：02/11/28 02:16

割込み、すいません。

C言語でモニタとコルーチンを実装（ライブラリを作成）したいのですが、
WEBで探してもなかなか合った文献がみつかりません。

どなたか、実装方法教えてくれませんか？
WEBや書籍でもいいのでお願いします。

＊Modula-2からCへの移植を行うため、モニタとコルーチン機能がCで必要になりまし
た。

101 ：デフォルトの名無しさん：02/11/28 16:09

>>98
中級ぐらいと思う。
メインはデバドラとブートコード。
「詳解Ｌｉｎｕｘカーネル」はあまりLinux板では評判よくなかった。
自分ももってるけどLinuxOSの概念の説明で
具体的なコードが書かれてないからすきじゃない

102 ：LightCone ◆sSJBc30S5w ：02/11/28 18:33

>>101
良いことを聞きました。
「詳細Linuxカーネル」は訳本のせいもあるのか文章量が多めで、途中から
斜め読みするには辛いものを感じていたのですが、よく考えるとこの本は、
プログラミング言語で書かれた部分は、構造体定義のみで、他は
ほぼ全て自然言語で書かれています。プログラミング言語も適度に有った
方が分かりやすいのかもしれませんね。今度ご紹介の本を見てみたいです。

103 ：デフォルトの名無しさん：02/11/28 19:47

Linuxのソースを参考にしながら開発するとmonaはGPLになると思われるがよいか？

104 ：LightCone ◆sSJBc30S5w ：02/11/28 21:31

>>103
ソースをコピーしない限りは、恐らく大丈夫かと。
特許が採られてない限り、技術の内容を真似ること自体は自由では？

そうでないと、知らず知らずにGPLのソースを偶然目に触れてしまって、
いつのまにか真似てしまった場合などにおかしなことになるかと。

105 ：デフォルトの名無しさん：02/11/28 21:31

>>103
monaはGPLだったと思うけど。

106 ：デフォルトの名無しさん：02/11/28 21:37

>>104
> ソースをコピーしない限りは、恐らく大丈夫かと。
これはGNUプロジェクトでは"駄目orグレー"だと認識されています。そのため
GNU Coding Standardには"他の実装(Implementation)"を見ないことを推奨し
ていて、見てしまった場合は別の実装を考えるように推奨しています。
日本の法律ではコピーしなければ大丈夫だったと思うけど、海外から訴えられ
たらたまらんですな。

107 ：ひげぽん：02/11/28 21:39

>中級ぐらいと思う。
>メインはデバドラとブートコード。
ありがとうございます。
なるほど、詳解Linuxカーネルはほとんどソースがないということであれば
立ち読み程度にしておこうかな・・・

ご存知かもしれませんがこんなのを見つけました。
http://lkh.linux.or.jp/24kernel/source/html4/boot.html

108 ：ひげぽん：02/11/28 21:44

>>103
>>104
>>105
>Linuxのソースを参考にしながら開発するとmonaはGPLになると思われるがよいか？
一応monaはGPLなので問題ないかと。

LightConeさんの仰るとおり
>ソースをコピーしない限りは、恐らく大丈夫かと。

という認識で私もやっています。とおもったら・・・

>これはGNUプロジェクトでは"駄目orグレー"だと認識されています。そのため
>GNU Coding Standardには"他の実装(Implementation)"を見ないことを推奨し
そうなんですか･･･
いろいろなフリーのOSのソースを見て勉強してしまっているんですが･･･

いちおう参考にすることはあっても、コピーはしないようにしています。
自分のためになりませんし･･･

109 ：LightCone ◆sSJBc30S5w ：02/11/28 21:49

>>106
>> ソースをコピーしない限りは、恐らく大丈夫かと。
>これはGNUプロジェクトでは"駄目orグレー"だと認識されています。そのため
>GNU Coding Standardには"他の実装(Implementation)"を見ないことを推奨し
>ていて、見てしまった場合は別の実装を考えるように推奨しています。

こわばらこわばら。

「見てない」って言い張るだけで回避可能とかではない？

110 ：FreeDOS教徒：02/11/28 21:51

GNU GPLにそこらへんの基準は載ってないのね。

‥‥ていうか、コピペまがいの行為はしないから、大丈夫でしょ？
実装が似通う例なんて腐るほどあるし。

111 ：LightCone ◆sSJBc30S5w ：02/11/28 21:56

>>110
>‥‥ていうか、コピペまがいの行為はしないから、大丈夫でしょ？
してないつもりです。

>実装が似通う例なんて腐るほどあるし。
そうですよね、、、。

　もし、GPLのソースを見て勉強しただけで、自分のプログラムのライセンスまで
制約されると言うのならば、かなり無理が有りませんか。

112 ：デフォルトの名無しさん：02/11/28 21:57

こわばらage

113 ：デフォルトの名無しさん：02/11/28 22:05

>>110
> GNU GPLにそこらへんの基準は載ってないのね。
いや、GNUの場合はUNIXの著作権を侵害しないように気を付けろってことだし、
"よりCoolな実装"を目指せば、同じにはならないでしょ。
似たものになっても、より優れていれば大丈夫。
当然、悪くても可 > オレモナー

114 ：デフォルトの名無しさん：02/11/28 22:07

>>111
そう言ってるともとれるのがGPLです。

115 ：デフォルトの名無しさん：02/11/28 22:12

一応参考までに
ttp://www.sra.co.jp/wingnut/standards/standards-ja_2.html

116 ：デフォルトの名無しさん：02/11/29 00:43

>>96
> ここで問題となるのは、hTaskの名前が二度のGetTaskName()呼び出しの
> 間に変化する可能性です。

普通、ユーザーが確保した領域に書き込む API は、サイズを渡すように
なっていて、気の聞いた API/OS なら、入りきらない時は必要なサイズを
返すようになってたりすると思うけど ? (例えば、Win32 の
GetWindowsDirectory() とか。)

悪いけど、もう少し他の OS の勉強した方がいいと思うよ。

> 何らかのロック処理が必要になるはずですが、

そんなことしたら、わざとロックかけて SetTaskName() しようとしている
タスクの実行を邪魔することができちゃうよ。(バッファを別に持つとかし
て、回避できるだろうけど、複雑になるしね。)

> ただし、これにも短所があります。空システムメモリ空間が圧迫される
> 可能性があることです。

どう言うこと ?

117 ：デフォルトの名無しさん：02/11/29 01:14

おそらく詳解Linuxカーネル。でも部分的にしかないみたい
http://aglaia.c.u-tokyo.ac.jp/~yamamoto/UNIX/kernel/
http://www.graco.c.u-tokyo.ac.jp/~kamina/jugyo/kernel/chap4_half/

118 ：デフォルトの名無しさん：02/11/29 01:20

>>116
きっとタスク名をシステムメモリ空間に確保したバッファに書き込んでユーザープロセスに返すのでしょう。
どうやって読み出すのかは知りませんが。

119 ：LightCone ◆sSJBc30S5w ：02/11/29 09:17

>>116
>普通、ユーザーが確保した領域に書き込む API は、サイズを渡すように
>なっていて、気の聞いた API/OS なら、入りきらない時は必要なサイズを
>返すようになってたりすると思うけど ? (例えば、Win32 の
>GetWindowsDirectory() とか。)

　そういうAPI仕様は知ってはいましたが、#94-#96では言及できてません
でした。すみません。

UINT GetWindowsDirectory(
LPTSTR lpBuffer, // Windows ディレクトリが格納されるバッファ
UINT uSize // ディレクトリバッファのサイズ
);

その方法では結局、実際に文字列を取得する際のサイズが前回取得した
文字列のサイズ以下になるまで繰り返しが必要になり、単に文字列を
取得したいたびにそのようなループを書く必要があることになる
わけですよね。

結局#96での結論と同じく、

const char *GetTaskName2(HTASK hTask);

というような API 仕様だと便利だと思うんです。

120 ：LightCone ◆sSJBc30S5w ：02/11/29 09:19

>>118
>きっとタスク名をシステムメモリ空間に確保したバッファに書き込んで
>ユーザープロセスに返すのでしょう。
その通りです。ただし、API呼び出し時に書き込むのではなく、元々存在
している場合の方が多いかもしれませんが。

>どうやって読み出すのかは知りませんが。
共通空間でも、ユーザーが読めるようにすることは可能です（書けるように
することも可能ですが）。
メモリ空間がタスク固有空間か共通空間かと、アクセス禁止属性は独立
して扱えますので。

一応、NWSOS でも、
const char *GetTaskFilename( HTASK hTask );
というAPIにしてみています。

http://homepage2.nifty.com/nowsmart/nwsosapi.htm#NWSOS API

121 ：デフォルトの名無しさん：02/11/29 09:28

GC完備すれば「バッファサイズ」なんて死語になるのに。。。

122 ：デフォルトの名無しさん：02/11/29 10:57

『GC』て何？

123 ：デフォルトの名無しさん：02/11/29 11:00

>>122
…。･･･。･･･。

124 ：LightCone ◆sSJBc30S5w ：02/11/29 12:11

>>122
文脈から、ガーベッジ・コレクションの略だと思います。

125 ：デフォルトの名無しさん：02/11/29 13:59

>>124
ありがとう。

126 ：デフォルトの名無しさん：02/11/29 18:41

理解が間違っているかもしれませんが、
LightConeさんはカーネル内部にTASKのデータを持たせておいて、
外部からはHTASKで操作し、
>>116さんはTASKのデータをTASKに持たせておいて、
カーネルではTASKのIDとかで識別できる程度にしておいて、
カーネルからのメッセージでTASKが動作するといったイメージでしょうか？
# 必要なデータはTASK側で確保するってこと。
そうだとすると、マイクロカーネルを目指すmonaとしては後者の方が
有利だと思うのですが、何か間違ってます？

127 ：ひげぽん：02/11/29 23:49

セグメントディスクリプタテーブルについて
どなたかアドバイスください。
長文になることをご了承くださいm(__)m

Monaではsecondboot.asmにて以下の手順で
ディスクリプタテーブルの設定を行っています。

(1)lgdtにてロード(エントリー数は4)
(2)プロテクトモードに移行
(3)far　jump　0x08へ
(4)レジスタの設定
(5)オフセットアドレス決めうちでCで実装したコードへjump

ここまで前提です。

最近タスク管理を実装しようと思い勉強していたのですが
基本的にはタスクひとつにつきTSSが必要っぽいことが分かりました。
エントリー数が足りない・・・

128 ：ひげぽん：02/11/29 23:50

そこでアドバイスいただきたいです。

(A)セグメントのエントリ数はどのくらいが適当か？

(B)固定or動的にエントリ数を増やせるような仕組み
　　　どちらが一般的でしょうか？
　　　
　　　もし固定であればsecondboot.asmにて
　　　エントリー数分メモリを確保しようと思っています。

(C)動的な場合
　　　エントリー数が増えた場合、連続領域にメモリを確保し
　　　lgdtをしなおさなければならないと考えていますが
　　　lgdtを複数回行うのはありでしょうか。
　　　
(D)secondboot.asmにてlgdtを行わず
　　　プロテクトモード移行後に、Cで実装している部分
　　　monaKernel.cppでlgdtを行うことは可能か？

　　　「はじめてよむ486」にはプロテクトモード移行後
　　　　セグメントレジスタにセレクタ値をロードするまでは
　　　　リアルモードのセグメント配置を引きずるとあるのですが・・・

　　　※これが可能であれば、エントリ数を増やすときに
　　　　　secondboot.binのサイズを固定のままでよいかと考えています。

(C)(D)は実際に自分で、いろいろやってみているのですが
現時点では成功していません。

129 ：LightCone ◆sSJBc30S5w ：02/11/29 23:52

>>126
>TASKのデータをTASKに持たせておいて、
>カーネルではTASKのIDとかで識別できる程度にしておいて、
>カーネルからのメッセージでTASKが動作するといったイメージでしょうか？

「メッセージでTASKが動作する」と言う意味がよく分からないのですが、
TASKならではの情報は、なるべくそのTASK独自のメモリ空間に入れるべ
きだということは同感です。

　しかし、共通空間に入れたほうが簡便になる場合もあるので、事情に
よりけりだと思います。

　他のタスク固有の情報を、「運んでくる」と言うのは結構メンドクさく
感じます。多分、

1. ページングで「窓」をあける。
2. 一旦、ソース側のタスクにいる時に共通空間にコピー、デスト側に来た時に
　共通空間からコピー

みたいな感じになるのでしょうか。

130 ：LightCone ◆sSJBc30S5w ：02/11/30 00:03

>>127
>基本的にはタスクひとつにつきTSSが必要っぽいことが分かりました。
>エントリー数が足りない・・・

基本的にはそうで、最新版のNWSOSでは、タスクごとにTSSを用意して
いるのですが、同一タスクのスレッド（軽量タスク）では同じTSSを指
しています。

しかし、Linux 2.4 では、TSSはひとつだそうです。

ちなみに、タスクゲートは、Linuxでも用いていないそうです（NWSOSでも）。

131 ：超先生＠OS板 ◆leaf/RYZgY ：02/11/30 00:10

　 ∧＿∧
＜　｀ー´＞y-~~~
個人的にはTSSを使うのはあまり好きじゃないな・・・。
コンテキスト保存用のブロックが無駄に大きすぎる。
nest-taskができるのは便利なんだが。

132 ：LightCone ◆sSJBc30S5w ：02/11/30 00:12

>>128
　調べて見たところ、NWSOSでは、lgdt は、初期化時に一回だけ、
8192 個のリミットで確保していました（TSS領域自体は、動的に
確保しています。）。

　多分、lgdtは何度でも行えると思うんですが、その際必要となるのが、
「連続した”物理”アドレス」ですので、動的に伸張していく際、
必要なサイズの「連続した物理アドレス」が空いてない場合は、
どこかにページングされているものから集めてくる処理が必要にな
ると思います。

133 ：ひげぽん：02/11/30 00:12

LightConeさん　こんばんは
>基本的にはそうで、最新版のNWSOSでは、タスクごとにTSSを用意して
>いるのですが、同一タスクのスレッド（軽量タスク）では同じTSSを指
>しています。

なるほど、スレッドは、メモリ空間？を共有している特殊なタスクということですね。
ということは、エントリ数は512とか256位必要な気がしますね。

>しかし、Linux 2.4 では、TSSはひとつだそうです。
どういう方法をとっているのでしょうか。なぞです。
でも結局はTSSに相当するものはどこかに持っていないとおかしいですよね。

134 ：ひげぽん：02/11/30 00:16

>>131 超先生＠OS板さん　おひさしぶりです。
>個人的にはTSSを使うのはあまり好きじゃないな・・・。
>コンテキスト保存用のブロックが無駄に大きすぎる。
勉強不足なのですがTSSの使用はmustではないのでしょうか？
segment typeはTSSでなくても、結局は使用するセグメントを
ディスクリプタテーブルに登録しなければならない気がするのですが
激しく勘違いしているかもしれません。

135 ：LightCone ◆sSJBc30S5w ：02/11/30 00:17

>>131
超先生、コメント有難うございます。

Linuxの参考書を見るべきかもしれませんが、
TSSを固定するとなると、I/O 許可ビットマップは利用しないという
ことなんでしょうか。in/out 命令は全部例外を起こさせて
エミュレートするか、I/O用システムコールを利用？

136 ：ひげぽん：02/11/30 00:22

LightConeさん
>　調べて見たところ、NWSOSでは、lgdt は、初期化時に一回だけ、
>8192 個のリミットで確保していました（TSS領域自体は、動的に
>確保しています。）。

わざわざ調べていただいて恐縮です。
なるほどNWSOSでは最初に一回多めにとっているのですね。
結局は、この方法がベストな気がします。

>多分、lgdtは何度でも行えると思うんですが、その際必要となるのが、
>「連続した”物理”アドレス」ですので、動的に伸張していく際、
>必要なサイズの「連続した物理アドレス」が空いてない場合は、
>どこかにページングされているものから集めてくる処理が必要にな
>ると思います。
おっしゃるとおりですね。
動的拡張は、ちょっと面倒であまりメリットがないかもしれません。
結局は初期サイズで余分に取っておくでしょうし･･･

137 ：LightCone ◆sSJBc30S5w ：02/11/30 00:29

　レベル遷移時に、どうしても、TSSの内側レベルのスタックポインタ
(SS0:ESP0, SS1:ESP1, SS2:ESP2) がCPUによって自動参照されて
しまうはずなので、TSSの切り替えをしない場合は、そこをタスク
スイッチ時に書き換える必要がありますよね。違っていたらNWSOS
では無駄なことをしていることになりますが、それをしないと確実に
暴走するので間違いないと思います。

　最新版のNWSOSでは、スレッドを切り替える際は、TSSを変更せずに、
そこだけを書き換えてます。

　他の項目は、タスクゲートなどを使わないなら書かなくていいん
はずですよね。TSSの CR3,LDTR などもどうでもいいんですよね。

　TSSの「レジスタセーブ領域」は、自信を持って書き換える必要がないと
言えます。
　なぜなら、最新版NWSOSでも利用せずに、独自の構造体に入れてますので。

138 ：超先生＠OS板 ◆leaf/RYZgY ：02/11/30 00:32

>>134
使わないというか、TSS一つを共有と。

>TSSを固定するとなると、I/O 許可ビットマップは利用しないという
>ことなんでしょうか。in/out 命令は全部例外を起こさせて
>エミュレートするか、I/O用システムコールを利用？

そもそもi386以外ではI/O access mapのようなものはないですからね。
移植性を考慮すると、subsystemプロセスに限定しても、
直接ユーザーランドからI/O命令を発行するような実装は綺麗でないです。

139 ：LightCone ◆sSJBc30S5w ：02/11/30 00:32

>>134
>勉強不足なのですがTSSの使用はmustではないのでしょうか？

恐らくその通りで、Linux でも、TSSは、一つだけは使っています。

超先生がおっしゃっているのは、TSSを複数使うかどうかだと思います。
#135 の私の質問も、その意味で書いたつもりです。

140 ：LightCone ◆sSJBc30S5w ：02/11/30 00:34

>>138
>そもそもi386以外ではI/O access mapのようなものはないですからね。
なるほど。

ご返答有難うございます。

141 ：LightCone ◆sSJBc30S5w ：02/11/30 00:38

やはり、「I/O許可ビットマップ」は使わない、ということなんですね。
　Linuxが、in/out 命令をユーザーレベルで直接使わずに、関数コール
しているのかが今分かった気がします。

やはり、TSSは、一つだけ固定的に持つのが一番賢そうですね。

そして、タスクスイッチ時は、「TSSの内側スタックポインタ」だけを
書き換えればいいわけですよね？

142 ：ひげぽん：02/11/30 00:43

一人レベルが低くて申し訳ないのですが

>やはり、TSSは、一つだけ固定的に持つのが一番賢そうですね。
となると、TSSをタスクの数だけ用意するのは
何もメリットがないのでしょうか？

143 ：ひげぽん：02/11/30 00:55

TSSディスクリプタを一つだけ固定で持つということすよね。

そうすればセグメント間ジャンプのときに
セグメントタイプがTSSであることをCPUが検知してくれて
TSSの内容を参照し、セグメントを切り替えてくれる。

OS側では、タスク切り替えの前にTSSディスクリプタが持つ
TSSのアドレスに切り替えたいタスクのTSS構造体のアドレスを設定する。

うーんなんか間違っている気がします･･･

144 ：LightCone ◆sSJBc30S5w ：02/11/30 00:55

>>142
>となると、TSSをタスクの数だけ用意するのは
>何もメリットがないのでしょうか？

複数使うメリット:

1. タスクゲートなどを使ったCPUネイティブなタスクスイッチが行える。
2. 割り込みなどをタスクゲートで行える。その際「ネスト」できるハズ。
3. TSSの「内側レベルのスタックポインタ」を頻繁に書き換えないで済む。
4. I/O 許可ビットマップを（一々コピーすることなく）利用できる。

複数使うデメリット:
1. タスク数に制限がついてしまう
2. I/O ビットマップを使うとなるとメモリが無駄。
3. セグメントレジスタの DWORD align が無駄
　（だけどアクセス高速化のためには結局必要かも）。

145 ：LightCone ◆sSJBc30S5w ：02/11/30 01:01

>>143
>そうすればセグメント間ジャンプのときに
>セグメントタイプがTSSであることをCPUが検知してくれて
>TSSの内容を参照し、セグメントを切り替えてくれる。

CPU定義のタスクジャンプや、タスクコールを使わないで済ますんです。

あと、タスクスイッチを伴うjmpは、「セグメント間ジャンプ」
とは言わない習慣のはずです。

146 ：みとこ ◆AEqcy/sQU6 ：02/11/30 11:33

GDTは連続した物理アドレスではなくリニアアドレスが必要だと思ったんですが。
物理アドレスを使うのはCR3とページディレクトリ・ページテーブルだけですよね？

147 ：デフォルトの名無しさん：02/11/30 11:45

>>119
> その方法では結局、実際に文字列を取得する際のサイズが前回取得した
> 文字列のサイズ以下になるまで繰り返しが必要になり、単に文字列を
> 取得したいたびにそのようなループを書く必要があることになる
> わけですよね。

ライブラリというものの存在はご存知 ?
個人的には、OS が勝手に領域を確保するという仕様は好みでない。
全ての言語が動的メモリーをサポートしているわけじゃないからね。
文字列領域をユーザーに確保させるか環境が確保するのかは言語/ライブ
ラリ作成者が決めればいい話で OS が決めることではないと思う。

重要なことは、const char *GetTaskName2(HTASK hTask); と言う API
を使って領域を確保しないでタスク名を取得することはできないけど、
GetWindowsDirectory() なら、ライブラリで領域を確保することもでき
るし、ユーザーに領域を確保させることもできると言う自由度があると言
うこと。その自由度を捨てて OS でできる限り安全にすると言うのも一つ
の方向ではあるけどね。

148 ：デフォルトの名無しさん：02/11/30 11:50

>>126
> >>116さんはTASKのデータをTASKに持たせておいて、
> カーネルではTASKのIDとかで識別できる程度にしておいて、

>>116 では、タスク名称の置き場所とかには言及してません。
まあ、普通は TCB (Task Control Block) 等のタスク管理領域に置くと
思う。

> カーネルからのメッセージでTASKが動作するといったイメージ
> でしょうか？

これは、まずいと思う。ps や taskmgr.exe で、ハングアップしたタス
ク名称が取得できなくなってしまう。

149 ：126：02/11/30 11:59

>>129 >>148
説明ありがとうございます。できるだけ小さいカーネルと、周りのプログラム
というのが実現できればいいと思ったのですが、ある程度のメモリサイズは
どうしても必要になるのですね。書籍の勉強だけでなく実装の勉強も
してみます。ありがとうございました。

150 ：LightCone ◆sSJBc30S5w ：02/11/30 12:14

>>146
ホントですね。すみません。
lgdtで指定するのは「連続した線形アドレス」でした。
gdtrやidtrは、「セレクタ」が必要ないんでしたか。最近忘れてます。

151 ：みとこ ◆AEqcy/sQU6 ：02/11/30 12:29

GDTRとIDTRは開始アドレスとリミットで構成される擬似ﾃﾞｽｸﾘﾌﾟﾀという構造体だったと思います。
ｾﾚｸﾀが必要なのはLDTRやTRですね。

152 ：LightCone ◆sSJBc30S5w ：02/11/30 12:38

>>151
　そういえば、そうそう。gdtrとidtrのディスクリプタだけは、
「擬似」なんですよね。

153 ：みとこ ◆AEqcy/sQU6 ：02/11/30 12:43

TSSを使わないスタック切り替えは工房の頃に力技で試しましたね。
タスク切り替えが頻繁に起きると大変な事になりそう。。。

めぐではどうしようかな。

154 ：LightCone ◆sSJBc30S5w ：02/11/30 12:52

>>153
>TSSを使わないスタック切り替えは工房の頃に力技で試しましたね。
素晴らしい。

>タスク切り替えが頻繁に起きると大変な事になりそう。。。
　最近のCPUで改良されたかもしれませんが、
速度パフォーマンス的には、CPUが持つタスク切り替え機能も
クロック数はかなりかかるので、気になるほどの差は出ないように思います。

155 ：LightCone ◆sSJBc30S5w ：02/11/30 13:02

>>153
　Linuxでは、バージョンアップ時の改良として、TSSが一本化された
こともありますし、超先生の見解通り、TSSを一本化（使わない）方針が
よいように思います。

　私の個人的見解でもTSSを用いたタスクスイッチはやめたほうが
いいと思います。理由はTR用のセレクタ数にGDTの制限が出てしまう
ことと、実際問題上、コールゲートを呼び出してタスクスイッチする
のは、逆にメンドクサイことになりそうだからです。

　経験上、CR3 等だけ変更して、CS:EIP は連続していた方が何かと楽
です（コードの流れは連続して、メモリマップだけを切り替える方が
楽です。）（CPU定義のタスク切り替えだと、EIPなども変えようと
してしまうわけで）。

156 ：みとこ ◆AEqcy/sQU6 ：02/11/30 13:04

あの頃はｶｰﾈﾙ(ﾘﾝｸﾞ0)ｽﾀｯｸをﾀｽｸ切り替えの際に毎回ｺﾋﾟｰしなおしてた気が・・・

157 ：LightCone ◆sSJBc30S5w ：02/11/30 13:08

>>156
>あの頃はｶｰﾈﾙ(ﾘﾝｸﾞ0)ｽﾀｯｸをﾀｽｸ切り替えの際に毎回ｺﾋﾟｰしなおしてた気が・・・
逆に思いつかない(^_^;)

158 ：みとこ ◆AEqcy/sQU6 ：02/11/30 13:13

TSS操作とかﾍﾟｰｼﾞ切り替えをしないように考えてたらｽﾀｯｸｺﾋﾟｰという荒業を思いついたのですが、、、

若いって素晴らしい(汗

159 ：デフォルトの名無しさん：02/11/30 17:51

幾つか質問します
1.OSを作っている言語は何ですか？
2.発表時期は何時？
3.有料？無料？
4.CUI系?GUI系？どちらで操作するようにするのですか？
5.ソースコードは公開するのですか？

私も参加してみたいですねぇ…

160 ：デフォルトの名無しさん：02/11/30 18:01

過去ログ読めやぁ

161 ：LightCone ◆sSJBc30S5w ：02/11/30 18:05

>>159
　３種のOSの作者が来ていて、一つのOSを共同制作しているわけではない
ことはいいですか？

　ひげぽんさんの OS(higepos, Mona?)は、GPLなので参加者は歓迎されると思い
ます。

　私は NWSOS を作っていて、ソースコードは今のところ非公開。開発言語は
C とアセンブラです。GUIのWindowの中でCUIをサポートしています。
「発表時期(?)」というのは意味がわかりません。今のところ売れそうも
ないので無料です。将来はわかりませんが有料でもただ同然になるはず
です。

　みとこさんは、MEG-OS の作者です。

162 ：ひげぽん：02/11/30 18:18

どうもIA32におけるタスク切り替えの本質を理解できずに
苦しんでいます。

インテルのマニュアルによると

>プロセッサは次の4 つのどれかが起こった場合に他のタスクへ実行を転送する。
>• 現行プログラム、タスクまたはプロシージャが、GDT 内にあるTSS ディスクリプタに対
>してJMP またはCALL 命令を実行した。
>• 現行プログラム、タスクまたはプロシージャが、GDT または現行LDT 内にあるタスク・
>ゲート・ディスクリプタに対してJMP またはCALL 命令を実行した。
>• 割り込み/ 例外ベクタがIDT 内にあるタスク・ゲート・ディスクリプタを指している。
>• EFLAGS レジスタのNT フラグがセットされているときに現行タスクがIRET を実行した。

そこで私は、TSSディスクリプタ、TSSを用意し
そのTSSディスクリプタに対してjmp(call)すれば
タスクが切り替えられそうだと言うことをなんとなく理解しました。

タスクの切り替えとは大まかに言って
コンテキスト
コードセグメント
データセグメント
スタックセグメント
開始アドレス等
を切り替えることだと思っているのですが

163 ：ひげぽん：02/11/30 18:19

>LightConeさんの仰る
>超先生の見解通り、TSSを一本化（使わない）方針が
>よいように思います。
>
>　私の個人的見解でもTSSを用いたタスクスイッチはやめたほうが
>いいと思います。

超先生＠OS板さんの仰る
>使わないというか、TSS一つを共有と。

がよく理解できないのです。

Intelは、タスク一つにつき、ディスクリプタとTSSを一組
を用意せよと言っているのに対して
TSSは一つを共有すればよいと仰っていると思うのですが

その場合具体的にはどういう方法でOSが何をすればよいのかが
分かりません。

この辺のことはどのような勉強方法で学習されたのでしょうか。

164 ：ひげぽん：02/11/30 18:24

>>159
>幾つか質問します

以下、私が中心となって開発しているMons(旧名higepos)について
書かせていただきます。

>1.OSを作っている言語は何ですか？
アセンブラ、C++

>2.発表時期は何時？
すいません、何の発表ですか。
まだ完成していないのでリリースは当然していないです。

>3.有料？無料？
無料です。

>4.CUI系?GUI系？どちらで操作するようにするのですか？
現在はCUIです。
将来はGUIを目指しています。

>5.ソースコードは公開するのですか
sourceforge.jp上で開発していますので公開しています。
http://mona.sourceforge.jp/

>私も参加してみたいですねぇ…
熱意とやる気のある方であれば大歓迎です。

165 ：ひげぽん：02/11/30 18:25

>>164
訂正です。
>以下、私が中心となって開発しているMons(旧名higepos)について
→以下、私が中心となって開発しているMona(旧名higepos)について

166 ：LightCone ◆sSJBc30S5w ：02/11/30 18:27

>>163
>この辺のことはどのような勉強方法で学習されたのでしょうか。
私の場合、

工学社「80386 プログラミング」
John H,Crawford + Patrick P Gelsinger 著
岩谷　宏　訳

をじっくり読みました。

　この本の中には「命令の論理ソース」がC言語風に掲載されていて、
タスクスイッチが内部的にどのように処理されているのかが厳密に
分かるようになっています。文章量が多くて少々難解ですが、
「論理ソースコード」は参考になります。

　その本を見ると、タスクゲートや、TSSセレクタに対する jmp や call
も、mov cr3,reg や、ldtr, ltr などの組み合わせで書けることが分かる
ようになっています（一目瞭然とまではいかないまでも。）。

167 ：FreeDOS教徒：02/11/30 18:29

>>ひげぽん
Typoです(Mons->Mona)

168 ：FreeDOS教徒：02/11/30 18:32

うわ。先に訂正されてしまった。ゴメソ。

何はどもあれプロジェクトに協力できる人募集中です（；

169 ：LightCone ◆sSJBc30S5w ：02/11/30 18:33

>>162
　要するに、それは、IA32のCPUが、
タスクとはこうである、タスクスイッチとはこうである、と定めた
内容を書いているだけで、タスクスイッチとは、所詮、ページテーブル
の変更と、ローカルセレクタの変更、汎用レジスタの復帰、などに
他ならないんです。

ページテーブルの変更--->レジスタ CR3 の変更(mov cr3,reg)
ローカルセレクタの変更--->ldtr の変更(LLDTR)
汎用レジスタの復帰--->通常mov命令

でことたります。

　ただし、一点だけ注意することとして、内部レベルへの遷移時には、
TSSの SS0:ESP0 が自動的に参照されてしまうことです。この動作
だけは、変更することが出来ない（はず）です。

170 ：ひげぽん：02/11/30 18:39

LightConeさん
>工学社「80386 プログラミング」
http://www.amazon.co.jp/exec/obidos/ASIN/487593128X/qid%3D1014798612/sr%3D1-1/ref%3Dsr%5F1%5F0%5F1/250-3723145-5289069
これですね。在庫切れだ。

>その本を見ると、タスクゲートや、TSSセレクタに対する jmp や call
>も、mov cr3,reg や、ldtr, ltr などの組み合わせで書けることが分かる
>ようになっています（一目瞭然とまではいかないまでも。）。

納得しました。そういうことなんですね。
昨日はこれを知らなくて????となっていました。
やっぱりできる人は勉強してるんですね。

171 ：ひげぽん：02/11/30 18:42

>>167
>>168
FreeDOS教徒さん
ご指摘ありがとうございます。
>>ひげぽん
>Typoです(Mons->Mona)
OS名だけ見事にtypo、もうバカかと・・・

>何はどもあれプロジェクトに協力できる人募集中です（；
大募集ですm(__)m

172 ：ひげぽん：02/11/30 18:45

>>169 LightConeさん
>タスクスイッチとは、所詮、ページテーブル
>の変更と、ローカルセレクタの変更、汎用レジスタの復帰、などに
>他ならないんです。

これを知らずに、タスク切り替え部をいびつに
実装してしまったら後悔するところでした。
ありがとうございます。

工学社「80386 プログラミング」探してみます。

173 ：LightCone ◆sSJBc30S5w ：02/11/30 18:47

ちなみに、この本の初版は、昭和63年です。私のは平成4年版です。
初版は、14年も前なんですね、、、、、、、、。

174 ：ひげぽん：02/11/30 18:51

>>173
>ちなみに、この本の初版は、昭和63年です。私のは平成4年版です。
>初版は、14年も前なんですね、、、、、、、、。

ここを見ると絶版と書いてあります・・・(T_T)
http://www.skyfree.org/jpn/recommend-1.html

175 ：159：02/11/30 18:51

はい、分かりました。
凄いです。

176 ：159：02/11/30 18:57

あ、発表って正式リリースの事です。

177 ：LightCone ◆sSJBc30S5w ：02/11/30 19:12

>>174
絶版本を探すには、古本屋に行くといいのではないでしょうか。

個人的には、中古でも、探していた本が見つかった時は、新しい
本よりも嬉しく感じます。

178 ：FreeDOS教徒：02/11/30 19:16

何はどもあれ -> 何はともあれ

179 ：ひげぽん：02/11/30 19:30

>絶版本を探すには、古本屋に行くといいのではないでしょうか。
>個人的には、中古でも、探していた本が見つかった時は、新しい
>本よりも嬉しく感じます。
近くの図書館と、オンライン古本屋では見つかりませんでした。
ますます欲しいーーーー

>>178
typo伝染りましたね。

180 ：。。。：02/11/30 20:26

前々スレから読み始めてやっと追いつきました。
このスレをたどっていくと、誰でもOSを作れそうですね。

181 ：デフォルトの名無しさん：02/11/30 21:29

じゃあ俺も
「NanihaDomoare MONS」っていうOS作るよ！

182 ：LightCone ◆sSJBc30S5w ：02/11/30 22:11

>>180
>このスレをたどっていくと、誰でもOSを作れそうですね。

　正直言って、誰でもとは言わないまでも、Cとアセンブラプログラムが
できる方なら基本的なOSは時間さえあればできると思います。
　大事なのは、CPUアーキテクチャの正しい情報を得ることと、
もう一つがデバッグに耐えられる忍耐力があることではない
かと思いますが、どちらも「やる気」の問題が大きいように思います。
スケジューリングやファイルキャッシュの優秀さなどを追求するのは
実験的と勘でやっていけばいいでしょうし、時間が取れなければ先人の
結果を、Linuxの解説本やOSの基礎論の本で見ることで済ませられますし。

　私も含めて不注意な人にはちょっぴりデバッグ回数が増えてしまうのが
大変な所ですが（笑）。

183 ：デフォルトの名無しさん：02/11/30 23:06

>>180
俺もそう思う。
「ＯＳ作るのって難しそう」と思ってる人にそう思わせる、
このスレは文化的価値がある思う。

184 ：。。。：02/12/01 00:06

実際、Lたん、ひげぽんってどうなの？
実力的に

185 ：デフォルトの名無しさん：02/12/01 00:07

>>183
禿同。まあ、誰でも作れるとまでは言わないけど、「OS だって、単なる
プログラムだ」と多くの人に思わせた功績はある。

これからも頑張ってね。> ひげぽんさん

186 ：デフォルトの名無しさん：02/12/01 00:40

>>184
Lﾀﾝはあれだけのものを作るので結構すごいんじゃない？
ひげぽは、学習能力が高そうなのでこのまま作り続ければ
NWSOSやOSASKレベルにはまちがいなく到達できると思う。

187 ：LightCone ◆sSJBc30S5w ：02/12/01 07:56

>>180
#182 だけだと誤解を生みそうなので少し補足します。
本当にこのスレを読んだ「だけ」だと、ブート部分と簡単なキー入力とその
エコー程度のところまでしか行けないと思います。

　難しくはないと思いますが、ファイルシステムがどういう仕組みで作られて
いるか、マルチタスクがどうやって実現されているか、割り込みとは何か、
グラフィックのLINEやCIRCLEやPAINTどうやって処理されているか、
排他制御とは何か、デッドロックを防ぐ方法、ページングとは何か、
セグメント、セレクタとは何か、みたいなことの理解が必要になってきます。

　今度はそれらをIA32でどうやって実現すればいいかという
ことを調べる必要があります。ページングが何かが分かっても、
次には、IA32においての、ページディレクトリやページテーブルの具体的
な仕組みを知らなければ、本格的なOSを組むことは出来ません。
このスレではそこまでは説明されてません（higepon さんのMonaも、
ページングは、まだなはずなので。）。

　あと、Windowシステムを組むのは、既存のOSのWindowシステムを体験
してからでないと難しいかもしれません。私も(MS)Windowsのプログラムを
練習する前に独自にWindowシステムを作ってみたことがあるのですが、かなり
無理があるような構造になってしまったことがあります。やはり、
一度は既存のWindowシステムの仕組みを体験することがGUIのOSを作るに
は必要だと思います。

188 ：LightCone ◆sSJBc30S5w ：02/12/01 08:06

>>186
>ひげぽは、学習能力が高そうなのでこのまま作り続ければ

　本当にひげぽんさんの成長ぶりには驚かされます。

　しかし、ひげぽんさん自身が、「何も知りません」と言うような場面
があったら、心の中で（「また、ご冗談を」）と言いましょう。

189 ：LightCone ◆sSJBc30S5w ：02/12/01 08:54

　スレの浪費と言われそうですが、#182 で「やる気」があれば、IA32が
理解できる、とは言ったものの、#166 で紹介した本は、全部で687ページ
有ります。
　これは、初代の80386の本なので、キャッシュや、その後に追加された
特殊ビットや、MMX/SSE/SSE2 は、IntelのPentium4のPDFファイル3本組み
読まないと分かりません。

上巻:378ページ（基本アーキテクチャ）
中巻:878ページ（命令リファレンス）
下巻:634ページ（システム・プログラミング・ガイド）

　ちなみに、日本では、こういう知識は何故か大学などでは（普通は）教えてくれ
ないので、自分で勉強するしかないです。場合によってはOSの専門家でもIA32の
ことを知らない人もいますので、「教育機関」に行ってもなかなか学べません。
こういうことを勉強したい人は、自分でこつこつやるしかないので、
海外のように巷にOS作者が溢れてこない理由はそこだと思います
（専門家からの猛反撃を受けそうなので、なかなか言えないことですが、
これで鬱になります、、、）。

190 ：デフォルトの名無しさん：02/12/01 12:35

>海外のように巷にOS作者が溢れてこない理由はそこだと思います
これなんだけど、OSに限らずソフトウェア業界全体的に、日本の勢力って
よわっちぃ-です。もちろん、人口比率以上に弱いという意味。
教科書もないのは、海外も同じで、結局、やる気あるやつの人口が桁違いに
多いんだと思うね、向こうは。

191 ：名無しさん＠Ｅｍａｃｓ：02/12/01 12:57

東大の情報系学科３年でやるCPU実習ではCPU設計から始めてOS制作までやるはず。

192 ：デフォルトの名無しさん：02/12/01 13:16

>>191
たしか論理合成までできて、やる気があればマザーボードの設計まで
できる環境になっている。うらやますぃー

193 ：デフォルトの名無しさん：02/12/01 13:29

余談だが、OSASKのソースを最近見たが激しくスパゲッティだね。
いずれ破綻すると思う。
NWSOSとmona?は大丈夫？

194 ：LightCone ◆sSJBc30S5w ：02/12/01 13:31

>>191
自分でCPUを設計して、そのCPUでOSを書くことだけでいいのでしょうか。
IA32の複雑さには定評がありますし。

195 ：LightCone ◆sSJBc30S5w ：02/12/01 13:32

>>193
NWSOSは、大丈夫です、と言っておきます（笑）。

196 ：デフォルトの名無しさん：02/12/01 13:34

>>195
OSASKのスパゲッティ状態についてどう思う？

197 ：LightCone ◆sSJBc30S5w ：02/12/01 13:36

　あと、学校でやる場合、実際の売り物のマザーボードとは複雑さがけた違い
だったりしませんか。
　ブリッジが何段階もあって、レガシーハードを引きずっている現状を
勉強してこそ（笑）、真の実力が身につくのではないかと。

198 ：LightCone ◆sSJBc30S5w ：02/12/01 13:39

>>196
NWSOSの場合、C言語で書けることもあって、かなり楽なんです。

OSASKの場合、現状「エセ」だそうですので最後まで見守る必要があるかと。

199 ：デフォルトの名無しさん：02/12/01 13:40

>>191
数年前の話だけど、OSまではやらなかったよ。
ROMに書き込んで直接実行させてた。
I/Oはシリアルだけだったかな。

200 ：LightCone ◆sSJBc30S5w ：02/12/01 13:42

>>190
>教科書もないのは、海外も同じで、

それはちょっと疑問があります。

OSの教科書については分かりませんが、3Dグラフィック関係の本は、
高度でしかも分かりやすい教科書がアメリカには沢山あるようです。

日本の教科書は、抽象的過ぎるか、または基礎過ぎるように感じます
（抽象的なものはある意味では高度ですが）。

201 ：デフォルトの名無しさん：02/12/01 13:43

Lﾀﾝ教科書、書いてくれ

202 ：デフォルトの名無しさん：02/12/01 13:44

＞OSASKのスパゲッティ状態についてどう思う？
いや、別に。おまえのソース解析力が、近代的なプログラミング作法に
慣れすぎたが故に、スパゲッティに見えるだけだ。
ためしに、linuxやgccのソース見てみぃ。latexでもいいし、Bシェルのソース
でも構わん。

203 ：LightCone ◆sSJBc30S5w ：02/12/01 13:48

>>201
NWSOSをもとに、OSの書き方を実践的に書くとか？
現状のNWSOSでは、スケジューリングとかが馬鹿すぎるのでちゃんと
してからでないと、バッシング受けそうで怖いです。

204 ：名無しさん＠Ｅｍａｃｓ：02/12/01 13:49

>>199
グループによるんじゃない？
実際に環境をつくってgcc移植してる人のHPを見た記憶があるんだよ

205 ：デフォルトの名無しさん：02/12/01 13:49

>>202
>ためしに、linuxやgccのソース見てみぃ。latexでもいいし、Bシェルのソース
>でも構わん。

linux-0.01のソースを見たことがあるが、きれいに構造化されていたよ。
linusやるねぇ。と思った記憶がある。
他のはみたことない･･･

じゃあOSASKは、近代的プログラミング作法を用いず
どういうスタイルなの？スパゲッティ作法(ｗ

最近のOSなら近代的プログラミング作法使おうよ

206 ：LightCone ◆sSJBc30S5w ：02/12/01 13:50

>>204
実は、授業ではなく、クラブ活動だったりして。

207 ：FreeDOS教徒：02/12/01 13:54

>>190
英語は世界に広まってるから、余計に強いよね。
逆に日本語で書籍出してもいわゆるニッチな市場だから生き残れない。
日本ではとにかく数が売れないとどうしようもないから。

>>193
アレよりは遥かにマシ。間違いねぇ。
俺はＣ＋＋使えないけどMonaの流れは掴めるし。

208 ：名無しさん＠Ｅｍａｃｓ：02/12/01 14:00

>>206
あーOS作ってなかったですね、CPU向けのgccを作ったということでした。
記憶があいまいだった...
http://www.yl.is.s.u-tokyo.ac.jp/~sumii/tsugcc/tsugcc.html

209 ：デフォルトの名無しさん：02/12/01 14:01

>>204
gccの移植（というかアーキテクチャ依存部分の作成？）
はおそらくコンパイラ担当者がそうしたかったんだろうねえ。
つか、コンパイラの作成方法も言語の選択もお任せだった。

課題としてOSを載せろ、という要求は無かった。
今はもしかしたら違うのかもしれん。そこは勘弁。

210 ：デフォルトの名無しさん：02/12/01 14:30

>>202
> ためしに、linuxやgccのソース見てみぃ。latexでもいいし、Bシェルのソース
> でも構わん。

悪いけど、LaTeX とちゃんと書いて欲しいし、この文脈で LaTeX は筋違いかと。
LaTeX が何で書かれているか理解してるか ?

211 ：デフォルトの名無しさん：02/12/01 16:20

出たよ、名称粘着が

212 ：デフォルトの名無しさん：02/12/01 16:46

>>211
> 出たよ、名称粘着が

プッ、そっちにしか突っ込めないのかよ。
お前 LaTeX ってなんだか知らないんじゃねーのか ?

213 ：ひげぽん：02/12/01 16:57

亀レスですが
LightConeさんの言うとおり
>Cとアセンブラプログラムが
>できる方なら基本的なOSは時間さえあればできると思います。
>　大事なのは、CPUアーキテクチャの正しい情報を得ることと、
>もう一つがデバッグに耐えられる忍耐力があることではない
>かと思いますが、どちらも「やる気」の問題が大きいように思います。

この辺が大事だとおもいます。
やる気が続くかどうかが鍵かと。

>>185
>これからも頑張ってね。> ひげぽんさん

ありがとうございます。

>>186
>Lﾀﾝはあれだけのものを作るので結構すごいんじゃない？
同意
>ひげぽは、学習能力が高そうなのでこのまま作り続ければ
>NWSOSやOSASKレベルにはまちがいなく到達できると思う。
それはどうでしょうか（笑）
まだだいぶ差がありますので

214 ：ひげぽん：02/12/01 17:04

>>189 LightConeさん
>こういうことを勉強したい人は、自分でこつこつやるしかないので、
>海外のように巷にOS作者が溢れてこない理由はそこだと思います

確かに英語圏にはOS作者があふれていますね。
おかげで参考になりますが・・・
ただ、その分レベルが様々ですね。
>>193
>余談だが、OSASKのソースを最近見たが激しくスパゲッティだね。
>いずれ破綻すると思う。
>NWSOSとmona?は大丈夫？
Monaは一応きれいに書こうとは試みていますが
あとでリファクタリングしようとほっとかれてる部分もあります。

一から書き直したいところがちらほら

215 ：デフォルトの名無しさん：02/12/01 17:04

OSASKはキューにシステムへのメッセージを溜め込むという構造らしいので、
近代的といえば近代的な気もするのですが？

OSASKのソースがスパゲッティ状態だとは思いませんが、
ASKA部分の定数直打ちは勘弁して欲しいです。
内部のシステムコールの番号とかへたれな私にはもはや記憶不可能な状態です。

216 ：ひげぽん：02/12/01 17:07

>>208
>あーOS作ってなかったですね、CPU向けのgccを作ったということでした。
>記憶があいまいだった...
>http://www.yl.is.s.u-tokyo.ac.jp/~sumii/tsugcc/tsugcc.html

これ面白いですね。
いやあ勉強になります。

217 ：デフォルトの名無しさん：02/12/01 17:08

>>209
ただ、3年後期のCPU実験とは別に、3年前期にNachosというMIPS
のシミュレータ上で動く半完成のOSを実装するという演習は
あるけどね。今年のレジュメは
http://www.bi.a.u-tokyo.ac.jp/~wataruk/os-ensyu/2002/
かな? Monaの作成にも役立つと思うので見てたら -> ひげぽん

218 ：ひげぽん：02/12/01 17:09

ずいぶん前に、リクエストのあったdoxygenドキュメントを
アップしました。
http://mona.sourceforge.jp/html/index.html

219 ：デフォルトの名無しさん：02/12/01 18:39

>お前 LaTeX ってなんだか知らないんじゃねーのか ?
知識は増やすだけだけど、心理は減らさないと求めることはできないよ？
そろそろ大人になったらどうだい？つか俺tex系不便だし
UNIXMagazineみたいに辛気臭いのばっかできあがるからつかわね。

220 ：デフォルトの名無しさん：02/12/01 20:09

>>219
知ってるの？知らないの？

221 ：デフォルトの名無しさん：02/12/01 20:34

知らないに1票
心理？真理じゃなくて？
俺tex系不便だし？？
ｱﾌｫ

222 ：デフォルトの名無しさん：02/12/01 20:41

ﾈｪﾈｪﾐﾝﾅ(　´∀｀)・ω・) ﾟДﾟ)・∀・)￣ー￣)´_ゝ`)ﾏﾀｰﾘｼﾖｳﾖ

223 ：デフォルトの名無しさん：02/12/01 20:45

LaTeXがどのようなものなのか知らないアフォがOSを作るとかほざいてるのか・・・
世も末だな。きっとこういう輩はPerlが内部的に持ってる中間言語の
形態についても全く知らないんだろうな。ダメすぎ。

224 ：デフォルトの名無しさん：02/12/01 21:00

OSから入っている人はアプリにたどり着いた時に、アプリから入った
人より遥かに深い理解ができると思います。

道のりが遠いので、今現状の理解度については目をつぶらないとね。
自慢げに煽っていると、そのうちに立場が逆転するかも知れませんよ。

というか、LaTeXってそんなに凄いもんなんか（藁

225 ：デフォルトの名無しさん：02/12/01 21:06

　　　　　________________
　　　　　|ﾏﾀｰﾘｼﾖｳﾖ|
　　　　　￣￣| |￣￣
⊂ ´⌒つﾟーﾟ)つ

226 ：デフォルトの名無しさん：02/12/01 21:32

LaTeXってなんじゃい？ptexの親戚かなんかか？と思って調べてみた。
何だ、まんまじゃねえか。
つかさ、どっちもどっちだよ。ソフトを知ってることがそんなに偉いの？

227 ：デフォルトの名無しさん：02/12/01 22:01

>>226
> ソフトを知ってることがそんなに偉いの？

じゃなくて、知らないでえらそうに書くことが恥ずかしいの。
わかった ? > >>202

228 ：デフォルトの名無しさん：02/12/01 22:56

　　　　　　　　　　　　　　　　　　　　＼
　　　　　　　　　　　　　　　　　　　　　＼
　　　　　　　　　　　　　　　　　　　　　　　＼
　　　　　　　　　　　　　　　　　　　　　　　　＼　　　　　　　　　　 /|　　　。.
　　　　　　　　　　　　　　　　　　　　　　　,,-'―＼　　　　　　＿,／ノ　　　.　.
　　　　　　　　＿＿＿,,-―――＝''￣￣　　＿,,-'―＝'''￣＿,／|　　o　　　　*
_,,-―＝'''￣　　　　　＿＿＿,,-―――＝''￣＿_,-―＝''￣　　 / .　　　.　.
　　　＿,,-―＝'''￣　　　　　　　＿,,-―＝''￣　ヽ　　　　　　　／　　+
￣￣　　　　　　　＿,,-―＝'''￣　　　　　　　　　　＼　　　　／　　. .　.　　.
　　　　　 ,,-＝''￣　　　　　　　　　　　　　　　　　　　ヽ　　／　　　　.　　。. ★　　☆
　　　 ,,,-''　　　　　　　　　　　　　　　　　　　　　　　ヽ／　　　　　。.　　　　.
-―''￣　　　　　　　／＼　　　　　＿＿＿,　　／＼　　 |　　　.　☆　　+
. 　　|　　　　　 ..::::::::::::... 　　　 |　　　 /　　　..:::::::...　|　+　.　　　.　.
　　 |　　　　　　　　　　　　 | 　　 /　　　　　　　　|　　　　.　.　　　☆
　　ヽ　　 γ´~⌒ヽ.　　　　　　 |　　 /　　　　　　　 /☆　.　*　　+.　　.　また～りしよっ♪
――ヽ　 /　　　　　ヽ　　　　　 |　 /　　　　　　　　 /⌒ヽ、.　　.　　.　.
　　　　＼/　　　　　　　|　　　　 |_/　　　　　　／　　　ヽ +★
　　　 / 　　　　　　　 |　　　　　　　　　　　　　／　　　　　ノ　*　　☆

229 ：デフォルトの名無しさん：02/12/01 23:08

>>223
別に、OS 作るのに LaTeX がどのようなものか知る必要はあるとは思えんし、Perl の中間言語が OS と何か関係あるのか ?

>>224
そう言う話じゃないよ。
LaTeX について知らないんなら黙ってた方が良いと思うよ。

今時は、LaTeX なんか知らなくても別に問題ないし。

230 ：ひげぽん：02/12/01 23:14

    asm volatile("sgdt %0\n"
                 : /* no output */
                 : "m" (gdtr)
                );
    _sys_printf("gdtr.limit = %d\n", gdtr.limit);

    _sys_printf("gdtr.base  = %d\n", gdtr.base);

baseが0で返ってきます。
実機でもbochsでも・・・うーんなぜだ･･･

231 ：LightCone ◆sSJBc30S5w ：02/12/01 23:37

ちなみに、私は、OSを専門的に勉強したことはないです。

232 ：ななし：02/12/01 23:42

これスレ面白いね。
正直、何が討論されているのかさっぱり理解できんが、
なんつーか、プログラミングを初めて覚えたころの
ドキドキ感を味わえているような気がしてくる。

スレ汚しごめんね。あとマターリしる！

233 ：超先生＠OS板 ◆leaf/RYZgY ：02/12/01 23:47

>>230
構造体のアラインの問題かも。
だとすれば、dd 0x12345678
のようにするとすぐに分かる。

234 ：デフォルトの名無しさん：02/12/01 23:59

要するに、latexを知らないとOSを作れないといいたいんだな？

235 ：ひげぽん：02/12/02 00:21

>>233
>超先生＠OS板さん
ビンゴです!!!
ありがとうございます。

236 ：ひげぽん：02/12/02 01:08

>>233
>>235
#pragma pack(2)

/*! gdtr */
typedef struct {
word limit;
dword base;
} GDTR;

#pragma pack()
のようにしたところ目的の動作が得られました。
ありがとうございます。

237 ：日和見主義：02/12/02 06:16

現状、MONAに傾こうか、NWSOSに傾こうか、日和見中。
趣味にしても、時間は限られてるしね。

238 ：デフォルトの名無しさん：02/12/02 09:27

ひげぽん氏は、GUIもサポートする予定ありますか？

239 ：デフォルトの名無しさん：02/12/02 10:32

GUIをサポートしようとすると、OS作りってとたんに難しくなると思われ。
海外では確かにOS作ってる人がたくさんいるけど、GUIまでのサポートと
なると、かなり限られてくる。

240 ：LightCone ◆sSJBc30S5w ：02/12/02 11:00

>>237
NWSOSの方に来るとマイレージが入ります、と言ってみるテスト。

241 ：みとこ ◆AEqcy/sQU6 ：02/12/02 11:03

だれかめぐに傾いてよ･ﾟ･(ﾉД`)･ﾟ･

242 ： ◆cIQBj36mnM ：02/12/02 13:18

>>240
マイレージためたら何かあるの？

ちなみに漏れはOSASK派。

243 ：デフォルトの名無しさん：02/12/02 16:24

MEG-OSの進展してるの？
一応サイトいったけど

244 ：みとこ ◆AEqcy/sQU6 ：02/12/02 16:34

スローペースですが一応リリースのたびにAPI増えてます。。。

現時点ではOSとしての完成度は「ライバルOS」と称されている他のOSより
遥かに遅れてるんですよね。

技術的な革新点も特にないし。

だめぽ。･ﾟ･(ﾉД`)･ﾟ･

245 ：LightCone ◆sSJBc30S5w ：02/12/02 16:51

>>242
マイレージが増えれば増えるほど、幸福感が増すでしょう、、、

きっと。

246 ： ◆cIQBj36mnM ：02/12/02 21:50

>>245
ふむふむ。

247 ：ひげぽん：02/12/02 21:55

>>237
>現状、MONAに傾こうか、NWSOSに傾こうか、日和見中。
>趣味にしても、時間は限られてるしね。
MONAにおいでくださいまし（笑）

>>238
>NWSOSの方に来るとマイレージが入ります、と言ってみるテスト。
やられますた。
Monaの方に来ると楽しいですよきっと、多分。おそらく。

>>238
>ひげぽん氏は、GUIもサポートする予定ありますか？
あります。と言っておきます。

>GUIをサポートしようとすると、OS作りってとたんに難しくなると思われ。
>海外では確かにOS作ってる人がたくさんいるけど、GUIまでのサポートと
>なると、かなり限られてくる。
そうですね。
その点においてNWSOS、OSASKはすごいですね。

248 ：デフォルトの名無しさん：02/12/02 22:05

スレ違いなのは重々承知の上で質問させてもらいますが、
国内で独自のJavaVMとかJavaネィティブコンパイラ(バイトコードをネィティブコードに変換)
を開発してるとこってあるんでしょうか？

249 ：ひげぽん：02/12/02 22:15

Monaは、ゆっくりと開発を行っているのですが
みとこさん、LightConeさんは、どういうペースで開発されてるんでしょうか？
開発の定義があいまいですが･･･
私の場合は、平日は本を読んだり、構想を練ったりしてます。
土日はテストコードを書いたり、ちょっとだけOSのコードを書ければ
いいかなって感じです。

250 ：デフォルトの名無しさん：02/12/02 22:27

GUIはアプリケーションで実現してほしいんだけど・・・。

つーか、Xでいいじゃん。だめ？

251 ：ひげぽん：02/12/02 22:30

>>250
それもありだと思います。
MonaはGUIの機能をアプリケーションに任せるつもりです。
あくまでも予定ですが。

252 ：みとこ ◆AEqcy/sQU6 ：02/12/03 12:24

>>249
他にもいろいろとやってるので開発ペースが安定してません。
なるべくめぐに時間を注いでますが。。。

でも単純比較なら開発時間はひげぽんさんより長いはず。
ついでに作り始めたのも。。。

253 ：LightCone ◆sSJBc30S5w ：02/12/03 12:52

>>249
PC/AT機版の元となったOSを開発を始めたのはだいぶ前です。
そのとき数ヶ月開発し、そのまま放置していたのを、2002年に
なってから移植し始めました（4月頃かな?）。

254 ：デフォルトの名無しさん：02/12/03 15:14

　　　　　 ☆　チン　　〃　∧＿∧ 　　／￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　　ヽ　＿＿_＼（＼・∀・）＜みとこさんは女ですか？
　　　　　　　＼＿／⊂　⊂＿)＿　＼＿＿＿＿＿＿＿＿＿＿＿＿
　　　　　　　／￣￣￣￣￣￣￣／|
　　　　　　　　l￣￣￣￣￣￣￣￣|　.|
　　　　　　　　|　　　　　　　|／

255 ：デフォルトの名無しさん：02/12/03 18:14

つーかﾏﾝｺだろ？

256 ：LightCone ◆sSJBc30S5w ：02/12/03 21:06

>>244
>技術的な革新点も特にないし。

　個人的に、Windowsで「アプリレベルで根本的に出来ない事柄」
「根本的に不足している事柄」を探してみてますが、めったに見つからない
です。
　裏を返せば、他のOSの出る幕がほとんどないということでは？

　「強いてやろうと思えばできるけど、手間がかかること」はあるの
で、そこに対案を出して売りにするしかないかもしれません。

257 ：デフォルトの名無しさん：02/12/03 21:58

wide系で、&osdev:*.jp なんてのを立ててみた.
一応匿名なので、暇なら誰か来て

258 ： ◆cIQBj36mnM ：02/12/03 22:02

>>257
?

259 ：257：02/12/03 22:07

>>258
irc.tokyo.wide.ad.jp
OS作る系匿名チャンネル

260 ：デフォルトの名無しさん：02/12/03 22:19

>>256
> 　「強いてやろうと思えばできるけど、手間がかかること」はあるの
> で、そこに対案を出して売りにするしかないかもしれません。

反対じゃないの ?
もっとシンプルでスマートな OS を作って欲しいと思う。
(でも、売れないんだよなァ...。)

261 ：LightCone ◆sSJBc30S5w ：02/12/03 22:29

>>260
「反対じゃないの」と、
「もっとシンプルでスマートな OS を作って欲しいと思う。」
との繋がりが分からない。

「反対」だと思う理由を書いてください。

262 ：デフォルトの名無しさん：02/12/03 23:27

>>261
そもそも Windows には...

>「強いてやろうと思えばできるけど、手間がかかること」

と言うのがあまりない。これほど強力な API/ライブラリ等が揃っている OS はそうそうない。

だから...

> で、そこに対案を出して売りにするしかないかもしれません。

なんてことするのは、非常に困難。

その代わり、全体的に複雑で統制の取れていない設計があちこちにある。
このために、プログラムを作るのに覚えることがたくさんあって大変だし、サブシステム毎に思想がばらばらだから同じようなことをしようとしても苦労が絶えない。

だから、もっと「シンプルでスマートな OS」を作って、それを売りにした方がいいと思う。
(というか、機能の豊富さ (≒ 開発の物量) で MS と勝負してもしょうがないでしょ ?)

> 「反対」だと思う理由を書いてください。

なんで、これぐらいわからんのか... ?
Windows がシンプルでスマートな OS と思ってるのかなぁ...。

263 ：ひげぽん：02/12/03 23:32

>>252
みとこさん
>>他にもいろいろとやってるので開発ペースが安定してません。
>>なるべくめぐに時間を注いでますが。。。

なるほどみとこさんは、めぐに時間を注ぎ
ひげぽんは、モナーに時間を注ぐのですね（笑）
冗談はさておき、やはりOS作成には時間がかかりますね。
一応私は5年計画ですが。。。

>LightCone さん
>PC/AT機版の元となったOSを開発を始めたのはだいぶ前です。
>そのとき数ヶ月開発し、そのまま放置していたのを、2002年に
>なってから移植し始めました（4月頃かな?）。

なるほど、NWSOSと比べてMonaは2年分くらいの差があると感じてます。
全くの私の主観ですが･･･
もっとがんばらなくては･･･

264 ：みとこ ◆AEqcy/sQU6 ：02/12/04 00:08

PROJの最初から考えるともう５年以上たったかもしれない、、、
今のコードベースは一年くらいかな

265 ：ひげぽん：02/12/04 00:11

みとこさん
>PROJの最初から考えるともう５年以上たったかもしれない、、、
>今のコードベースは一年くらいかな
ひえー、大先輩ですね。
今後ともよろしくお願いいたします。

266 ：257：02/12/04 00:26

いろいろあって#osdev-jに変えました
ひげぽんさん、LightConeさんも、お暇なら是非来てください

267 ：超先生＠OS板 ◆leaf/RYZgY ：02/12/04 00:30

　 ∧＿∧
＜後ろ頭＞ y-~~~ 面白そうになってきたな。
私もちょいと昔のを引っ張りだしてこようかな。

268 ：みとこ ◆AEqcy/sQU6 ：02/12/04 00:35

>>265
むしろ、長くても大成するとは限らない見本ということで。。。

269 ：デフォルトの名無しさん：02/12/04 00:41

>>261
煽るなよ

270 ：デフォルトの名無しさん：02/12/04 01:15

煽り騙りは2chの華ってか。

271 ：デフォルトの名無しさん：02/12/04 03:07

ちなみに私もPC/ATでのOS作りに今日から参戦することにします。
普段は組み込み機器でリアルタイムLINUXのカスタマイズを仕事にしてます。
mips系ばかりでx86は初めてですが、NWSOSを追い抜くべく頑張ります。
BIOSがかなり整備されてるっぽいところが、唯一の月明かり･･･

272 ：デフォルトの名無しさん：02/12/04 05:25

>　 ∧＿∧
>＜後ろ頭＞ y-~~~ 面白そうになってきたな。
おー。超先生、も参戦ですか？

273 ：LightCone ◆sSJBc30S5w ：02/12/04 09:48

>>262
>その代わり、全体的に複雑で統制の取れていない設計があちこちにある。
>このために、プログラムを作るのに覚えることがたくさんあって大変だし、サブシステム毎に思想がばらばらだから同じようなことをしようとしても苦労が絶えない。

それは同感。

274 ：デフォルトの名無しさん：02/12/04 16:59

IRC寂しいすぎ

275 ：LightCone ◆sSJBc30S5w ：02/12/05 00:01

　マルチスレッドが使えるカーネルと、パイプ,リダイレクト,ヒストリが
使えるシェルを正式公開しました。テキストエディタや gnu-sed も付いてます。

NWSOS Ver 0.030 :

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

sed をパイプで起動したスクリーンショットがあります。

なお、テキストエディタは、SHIFT+ESC で出力を取り込んでエディタが
起動できます。

276 ：LightCone ◆sSJBc30S5w ：02/12/05 02:06

>>275 修正
>なお、テキストエディタは、SHIFT+ESC で出力を取り込んでエディタが
>起動できます。
テキストエディタのことではなく、SHELL のことです。
SHELL が、Vz エディタのように、SHIFT+ESCで、コンソール出力を
エディタに取り込んで編集モードに入れるようになってます。

277 ：LightCone ◆sSJBc30S5w ：02/12/05 02:20

ファイルバッファのサイズを動的に変更する方法が知りたいです。

他の目的で使うメモリが不足すると、ファイルバッファの内容をディスクに
フラッシュして、ファイルバッファのサイズを小さくし、メモリとして
利用できるようにしたいです。

でも、まだ漠然として上手い方法が今一よくわかりません。
一応、今のところ思いついた必要条件っぽいものは、

・ディスクにフラッシュしようとした際に、ファイルシステム自体が
　新たにメモリを要求してはいけない（？）。

・もし、マイクロカーネルでこれを行う場合、メモリを必要とするタスクは、
　一時的に停止状態にし、その間に
　「ファイルサブシステムのタスク」がディスクにフラッシュする（？）。
　（ちょっと不思議）

・仮想記憶(SWAP IN, OUT) と上手く折り合いをつけないといけない。
　そもそも、SWAP OUTしてはいけない部分も有りそうだし、、、。

278 ：デフォルトの名無しさん：02/12/05 02:44

＞SHELL が、Vz エディタのように、SHIFT+ESCで、コンソール出力を
＞エディタに取り込んで編集モードに入れるようになってます。
おいらの指は、この10年間、Viに慣れきったんで
ViがNWSOSに移植されれば、遊びに行くYO。
sedがパイプで使えるってことは、Viが移植される日も近い？

279 ：デフォルトの名無しさん：02/12/05 03:29

NWSOSの最新バージョンみたよ！
数ヶ月ぶりにFDにインストールして、起動してみたんだけど、開発は順調みたいだね。
テキストエディタ（かなり前からあるようだけど）も、HD上のファイルから
S-JISが問題なく読み込めたし、HDアクセス中も、FireDEMOが止まらないし。

難いえば、マウスカーソルが異様に遅いことかな？

現状、Windows2.0程度といったところ。
もっと頑張れ！

280 ：デフォルトの名無しさん：02/12/05 03:44

sedが動いててびびった。おそらくGPLのソースをほとんどそのままコンパイル
したんだろうけど。
というか、unix系ツールはほとんどコンパイルしなおせば動くんでないの？

これら基盤ツールはGPLで構わんと思うよ。
実行ファイルとして分離されてるんだし、NWSOSとGPLとは無縁でいられる。

Lightﾀﾝは、カーネル、Windowマネージャなどは、NWSOSとしてがっちり
開発し、周辺ツールはソース込みでこれら古典的なツールをGPLでがんがん
出してみてはいかが？

281 ：LightCone ◆sSJBc30S5w ：02/12/05 09:10

>>280
>というか、unix系ツールはほとんどコンパイルしなおせば動くんでないの？
　理想的にはそうであって欲しいのですが、SEDの場合は、いったん、
Visual C++でコンパイルできるように修正（確認）してから、NWSOS
用にさらに微妙に修正する必要がありました。
POSIX互換(風)のライブラリを整備していけば、だんだん改善されていく
と期待してるのですが。

>周辺ツールはソース込みでこれら古典的なツールをGPLでがんがん出してみて
>はいかが？

そうしたいです（有志の人に手伝って欲しいです。）。

282 ：LightCone ◆sSJBc30S5w ：02/12/05 09:13

>>279
>NWSOSの最新バージョンみたよ！
有難うございます。

>難いえば、マウスカーソルが異様に遅いことかな？
これは、単に移動速度が遅い（1カウントあたりの座標の変化が少ない）と
いうことですか？　それとも、、、。

283 ：LightCone ◆sSJBc30S5w ：02/12/05 09:17

>>278
>おいらの指は、この10年間、Viに慣れきったんで
>ViがNWSOSに移植されれば、遊びに行くYO。
>sedがパイプで使えるってことは、Viが移植される日も近い？

sedよりは大変かもしれませんが、多分、気合を入れれば移植できると思います。

284 ：LightCone ◆sSJBc30S5w ：02/12/05 10:23

　DOS/Windows だと、rename *.doc *.txt のようにして拡張子を
変更可能なんですが、UNIX 系だとシェルスクリプトを書くしかないの
でしょうか？

UNIX では、ワイルドカードはシェルの段階で展開してしまうので、
cmd *.doc *.txt としても、doc と txt が一列に並んでしまうので、
cmd側は区別できませんよね。

（DOSだと、copy *.c *.old とかも使えたのですが。）

285 ：LightCone ◆sSJBc30S5w ：02/12/05 10:28

cmd *.doc *.txt
と書いたときに、

cmd x1.doc x2.doc x3.doc dlm y1.txt y2.txt y3.txt

のように、間に dlm という「仮想ファイル名」を渡してしまい、
dlm をオープンすると、nul デバイスのように働くようにするとか。

286 ：LightCone ◆sSJBc30S5w ：02/12/05 10:31

あ、*.txt はそういう風に展開できないか、、、。

287 ：LightCone ◆sSJBc30S5w ：02/12/05 10:49

対案:

行頭に ! を書くとワイルドカードを展開しないことにする。

!rename *.doc *.txt

と書くと、renameコマンドは、

argv[0]=rename
argv[1]=*.doc
argv[2]=*.txt

という引数を受け取る。

288 ：LightCone ◆sSJBc30S5w ：02/12/05 10:51

一般化:
「ファイル名変換支援ツール」 fncnv.exe を用意して、
x1.doc, x2.doc, x3.doc
と言うファイルがカレントディレクトリにあるとき、

!fncnv *.doc *.txt とすると、例えば、
x1.doc x1.txt x2.doc x2.txt x3.doc x3.txt
という文字列を標準出力に出すようにして、これを個別のコマンドで
利用する手も考えました。

289 ：デフォルトの名無しさん：02/12/05 12:19

LightConeタンへ

マウスカーソルがｶｺ(・へ・)ﾖｸﾅｲ!

290 ：デフォルトの名無しさん：02/12/05 13:07

""で括るとワイルドカード展開しない。
という仕様が一般的な気がします。

sh/csh系だけの話なのかもしれませんが。

291 ：LightCone ◆sSJBc30S5w ：02/12/05 14:11

>>290
実は既に現状のNWSOSでもそうなってはいるのですが、
rename "*.doc" "*.txt"
と書くのがなんとなく納得行かないことと、どんな記法で書いたとところで、
最終的に
argv[0]=xxx.exe
argv[1]=*.doc
argv[2]=*.txt
となってしまうのなら、各xxx.exeでの判定が必要になるので、
しっくり来ません。

#288では、fncnv.exe と連携して、
xxx.exe x1.doc x1.txt x2.doc x2.txt x3.doc x3.txt x4.doc x4.txt ...
と展開してやることを思いついたのですが。

292 ：LightCone ◆sSJBc30S5w ：02/12/05 14:13

>>289
いずれ形状を変更できるようにしますのでお待ちください。

293 ：デフォルトの名無しさん：02/12/05 18:08

MONAのスレがNWSOSスレ化している気が…

294 ：みとこ ◆AEqcy/sQU6 ：02/12/05 18:11

ただいまからこのスレはめぐたんスレになりますたヽ(｀ー´)ノ

295 ：デフォルトの名無しさん：02/12/05 20:23

guiよりも先にネットワーク対応した方が使用者増えるよ
もう使えるのかな？試してないんでわからないんだけど

296 ：デフォルトの名無しさん：02/12/05 20:23

めぐたんハァハァ
てか、NWSOSスレでやろうよ＞LightConeたんほか

297 ：デフォルトの名無しさん：02/12/05 20:34

みとこﾀﾝのエロ画像ｷﾎﾞﾝ！( ●∀●)

298 ：名無しさん：02/12/05 21:01

MONAのスレじゃないと思うけど・・・。

299 ：デフォルトの名無しさん：02/12/05 21:07

Σ(●∀● )あんのか!

300 ：デフォルトの名無しさん：02/12/05 21:44

ひげぽんさん、感動しますた！
漏れはやっとVBとかCができる程度ですが、
(ヘボですが)Webデザインなら多少応援してあげられますけど。。。

これからも、がむばってください！

301 ：ひげぽん：02/12/05 21:52

>ひげぽんさん、感動しますた！
>漏れはやっとVBとかCができる程度ですが、

ありがとうございます。VBとCができるだけで既に
すごいです。VBは良く分からんです。

>(ヘボですが)Webデザインなら多少応援してあげられますけど。。。

Monaプロジェクトは、慢性的WEBデザイナー不足なので
もしお力を貸していただけるのであれば
[email protected]までメールくださいm(__)m

302 ：ひげぽん：02/12/05 21:55

NWSOSは、シェルが進化しましたね。
やはりLightConeさんはすごいですね。

Monaはタスクスイッチ実験中です。
あまりうまくいっていませんが、少しずつ前に進んでます。

303 ：LightCone ◆sSJBc30S5w ：02/12/05 21:58

>>295
　ネットワークにも対応したいんですが、WEB-BROWSERも、GUIを
最低限整備しないと作れないわけでして(笑)。
　優先順位はやはりGUI>>>>ネットワークかと。

304 ：LightCone ◆sSJBc30S5w ：02/12/05 22:05

　タスクスイッチと、タスクをロードして実行を開始するあたりが、
OS作りでひとつの山場っぽいですよね。
　割り込み中でメモリ空間やスタックを切り替えるのは、普段絶対に
経験しないことですし。

　あと、タスクをロードできると言うことは、
メモリ管理やファイルシステムがその程度の使い方ではバグ
フリーになった証拠でもあるわけで。逆にいえば、それらの
支援機能のバックアップがなければタスクをロードできないわけで。

305 ：ひげぽん：02/12/05 22:10

ircクライアント入れてみたが、使い方が良く分からない・・・
ってMona開発に精を出せって話ですね。

306 ：デフォルトの名無しさん：02/12/05 22:16

>>305 ひげぽんさん
LimeChatがお勧めですよ！
#osdev-j チャンネルに参加してもらえると
かなりうれしいです!!

307 ：LightCone ◆sSJBc30S5w ：02/12/05 22:26

　ネットワーク技術は全くの素人なんですが、
「ネットワーク対応」とは一体どういう状態のことなんでしょう。

　COMポートやLANカードのドライバを提供することでしょうか。
　それとも、ソケットみたいなものへの対応？

　LANカードを直接制御すれば、OSの支援機能がなくてもなんとか
なるんじゃないかと素人考えしてしまうのですが。なんらかの調停が
必要なものなんでしょうか。

308 ：デフォルトの名無しさん：02/12/05 22:52

あるOSがネットワーク対応してます、と表明していたら、
TCP/IPスタックとbsd socket互換インターフェースがあり、
物理層としてethernetが使えることを期待しちゃいます。

> OSの支援機能がなくてもなんとか

パフォーマンスを考慮しないのであれば問題ないでしょう。

309 ：デフォルトの名無しさん：02/12/05 23:16

guiのブラウザなんかずっと後でいい
cuiのftpクライアント一つあるだけで相当便利になると思う

310 ：ひげぽん：02/12/05 23:49

>>306
おかげさまで、有意義な時間が過ごせました。
また顔出します。m(__)m

311 ：デフォルトの名無しさん：02/12/06 00:19

>ネットワーク技術は全くの素人なんですが、
>「ネットワーク対応」とは一体どういう状態のことなんでしょう。
そのネットワーク対応ってのは、俺が言ったものではないけど、俺的希望としては
LANなどで接続されたNWSOS起動中マシンへ実行ファイルなどを送り込み、
runできるという環境が欲しいかな。要はリモート機として機能することね。

これでぐっと、NWSOSのアプリ移植は早まると思うな。
営業妨害するつもりはないが、NWSC-Cは、現状、C++は未対応なんだし、
当分はVC++だとかgccに頼ることになるでしょ？（NWSOSの実行ファイル作るに
しても）

312 ：306：02/12/06 00:44

>>310 いえいえこちらこそ
また是非いらしてください。

313 ：LightCone ◆sSJBc30S5w ：02/12/06 02:04

>>311
物理層のドライバ書くだけでも大変そうですね。
そもそも、LANカードの共通規格は無いんですよね？

でも、LANでつながずに、RS-232Cケーブルでシリアル接続
でいいなら、簡単に出来そうです。ネットワークと言うより、単なる
シリアル通信ですが（笑）。ポケコンとPCの間でもできるぐらいのもの
なので。

話はずれますが、"UNIVERSAL-DRIVER 計画"みたいなのがあるそうです
よね。しかも、あのMSも積極的っぽいらしく。

314 ：デフォルトの名無しさん：02/12/06 06:09

いや、RS-232Cじゃ転送速度に限界あるし。
linuxのLANカードドライバのソースコードでも引っ張ってきて、
NWSOS向けに移植するしかないのでは？

nwsos上にセルフ環境構築しても人は寄ってこない。
様々な便利なツールが、linuxだとかwindowsにあって、
体や指がそれに慣れきってるから。生理学的な問題ってことで。

てなわけで、nwsosがリモート操作できるという環境ができるならばおいらも賛成。
一番ご利益があるのはむしろ、L氏では？

315 ：314：02/12/06 06:13

あ、でも慣れるまでの橋渡しってことで>>リモート環境構築

NWSOSのshellはいい線、いってると思う。
バックログがキー操作一発ででき、しかもそのまんま編集が出来てしまう
という環境は、unix系のshellでは見たことない。
shellとeditの融合shell？

この手の、他にはない優位性が標準として実装されればNWSOSの自立性としての
価値が輝いてくると思う。（あーもちろん、カーネル書ける人からみたら
シェルは一アプリケーションに過ぎないことは当然承知の上でな）

316 ：LightCone ◆sSJBc30S5w ：02/12/06 09:31

>>315
>shellとeditの融合shell？
Vz Editor からアイデア貰いまくりです。(^_^)

>この手の、他にはない優位性が標準として実装されればNWSOSの自立性としての
>価値が輝いてくると思う。（あーもちろん、カーネル書ける人からみたら
>シェルは一アプリケーションに過ぎないことは当然承知の上でな）

　他のものでも、「ちょっと優位」なだけで輝いて見える場合って意外に多い
ような気もしませんか。

　ウォークマンも、「小さい」ことに意義があるのだし、
軽自動車だって走行性能は普通自動車に劣るかもしれないのに人気が有るし
（どちらも「小さい」という共通点が有るのが不思議）。

317 ：デフォルトの名無しさん：02/12/06 09:46

でかけりゃいいってもんじゃないことを肝に銘じておいてくださ～い♪by ﾍﾟﾘｰ

318 ：LightCone ◆sSJBc30S5w ：02/12/06 12:31

>>314
そうですね。

　ただ、今のカーネルや SHELL でも、まだまだ至らない部分が多いので、
そちらを先に改良したいです。
　ドライバ仕様の確定とDLLへの対応の優先順位はかなり高いと思います。

　あと、コマンドをパイプやリダイレクトを使わずに起動しても、
今の shell ではコマンドの stdin に直接データを送れません。
　これ改善するには、カーネル側とshellの両方の修正が必要だと
思ってます（パイプ関係で）。

319 ：デフォルトの名無しさん：02/12/06 16:20

>バックログがキー操作一発ででき、しかもそのまんま編集が出来てしまう
>という環境は、unix系のshellでは見たことない。

M-x shell の環境が近いかな？
tab補完はできるの？

320 ：LightCone ◆sSJBc30S5w ：02/12/06 16:28

>>319
>M-x shell の環境が近いかな？
恥ずかしながら、名前も聞いたこと有りいません。

>tab補完はできるの？
今のところ出来ません。

321 ：デフォルトの名無しさん：02/12/06 16:44

>>320
>>M-x shell の環境が近いかな？
>恥ずかしながら、名前も聞いたこと有りいません。
emacs ってエディターの中でシェルを使えるモードがあるんです

tab補完はほしいなぁ、ディレクトリが深くなる場合無いときついです

322 ：LightCone ◆sSJBc30S5w ：02/12/06 21:06

>emacs ってエディターの中でシェルを使えるモードがあるんです
そんなモードがあるとは始めて知りました。

>tab補完はほしいなぁ、ディレクトリが深くなる場合無いときついです
私もそう思ってます、、、。

でも、実の所、そういう機能はいつでも追加できるので優先順位的には
低く思ってるんです。

323 ：デフォルトの名無しさん：02/12/06 23:04

>>320
emacsはUnix系で広く使われているテキストエディタ兼
統合環境です。vi系と人気を二分してきました。
emacs系は、Win環境ではMeadowが広く使われています。
Cygwin環境用のemacsもあります。

emacsは慣れると手放せなくなる良品ですね。
LightConeさんには特にお奨めです。だまされたと思って
試してみてください。

324 ：LightCone ◆sSJBc30S5w ：02/12/06 23:09

>>323
>emacsはUnix系で広く使われているテキストエディタ兼
>統合環境です。vi系と人気を二分してきました。
　emacs と vi が人気を二分していたとは知りませんで
した。今まで、emacs,nemacs,kemacs(?)が圧倒的に人気が有るのかと。
Muleもemacs系ですか？

>emacsは慣れると手放せなくなる良品ですね。
それはよく聞いてます。LISPマクロ(?)がいいんでしょうか？

最初、カーソルキーが使えなくて面食らったことがありますが。

325 ：デフォルトの名無しさん：02/12/06 23:49

>>324
> それはよく聞いてます。LISPマクロ(?)がいいんでしょうか？
TAGSファイルとか使うと本当に便利ですが、Cのコーディングスタイルが
押しつけられるので、好き嫌いはあると思います。
でも、emacsでアセンブラは二度とやりたくないです。自分でmodeを作る能力が
なかったため、字下げがわけ分からん状態になりました。

326 ：ひげぽん：02/12/06 23:52

>Win環境ではMeadowが広く使われています

MonaのコーディングはMeadowを使ってます。
確かに便利ですね。
MakeもMeadow上から実行しているので
Meadowがないとつらいですね。

327 ：デフォルトの名無しさん：02/12/07 05:25

とりあえず、NWSOS標準Shellがunixの端末仕様に揃えれば
Vi系だとかEmacs系などの移植も進むと思われ

328 ：デフォルトの名無しさん：02/12/07 09:52

なんつうかそうなっちゃうとたんなる亜種になりさがっちゃう気がして...

329 ：LightCone ◆sSJBc30S5w ：02/12/07 10:25

>>327
>とりあえず、NWSOS標準Shellがunixの端末仕様に揃えれば
>Vi系だとかEmacs系などの移植も進むと思われ

　カーソルを移動したり色を変えたりするエスケープコードみたいなものが
決まってるんでしょうか。
　昔、REMOTE LOGIN で、自宅のDOSで遠くのemacsが動いてびっくりしま
したが。

>>328
>なんつうかそうなっちゃうとたんなる亜種になりさがっちゃう気がして...
　基本的な部分を UNIX と似せておくことはプラスになると思います。
　Windowsでも POSIX(UNIXの標準仕様みたいなもの)に大まかに対応し
てますが、Winを UNIX と思う人はいないわけで。

330 ：デフォルトの名無しさん：02/12/07 10:52

MacOSXのように個性が出せればですね。

>カーソルを移動したり色を変えたりするエスケープコードみたいなものが決まってるんでしょうか。
http://vt100.net/
この辺でしょうか？ちゃんと読んではいませんが。

331 ：LightCone ◆sSJBc30S5w ：02/12/07 11:09

>>330
　まず基本的なことから知りたいのですが、sh,csh,bashなどは、
「コンソールの枠」としての「kterm」中で起動し、エスケープ
シーケンスの処理は、kterm がやっている、ということなんで
しょうか。

　どうやら、kterm のエスケープシーケンスとMS-DOS のそれとは互換性が
あるようですが、あってるでしょうか。

332 ：LightCone ◆sSJBc30S5w ：02/12/07 11:21

エスケープシーケンス Google検索:

http://www.google.com/search?hl=ja&inlang=ja&ie=Shift_JIS&q=xterm+ESC+%5B&lr=

333 ：デフォルトの名無しさん：02/12/07 11:23

>>329
> カーソルを移動したり色を変えたりするエスケープコードみたいなものが
> 決まってるんでしょうか。

termcap/terminfo

334 ：LightCone ◆sSJBc30S5w ：02/12/07 11:38

>>333
　termcap や terminfo を変えれば、「UNIXの端末使用(xterm,kterm)」と
同じでなくても emacs等が動くかもしれない、ということでしょうか？

335 ：LightCone ◆sSJBc30S5w ：02/12/07 11:39

使用--->仕様

336 ：デフォルトの名無しさん：02/12/07 12:39

>>334
プログラム中にエスケープシーケンスをハードコーディングしたりすると特定端末でしか動かなくなるから、Unix ではカーソル制御ライブラリを使うのが定石。
これによって、プログラムはカーソルの論理的な動きを記述すれば良い。
実際にエスケープシーケンスへの変換は、カーソル制御ライブラリが行う。
更に、各種の端末に対応するため端末毎に変換規則をデータベース化してある。(termcap/terminfo は、データベースの名前。)
だから、カーソル制御機能がある端末に対応した termcap/terminfo が書ければ、どんな変な端末でも emacs とか動くよ。

337 ：LightCone ◆sSJBc30S5w ：02/12/07 15:10

>>336
>実際にエスケープシーケンスへの変換は、カーソル制御ライブラリが行う。
>更に、各種の端末に対応するため端末毎に変換規則をデータベース化してある。

　解説有難うございます。UNIXでのカーソル制御や文字装飾制御は、
思った以上に柔軟性が高く、

1. アプリ--->カーソル制御ライブラリ

2. カーソル制御ライブラリ--->エスケープシーケンス
(termcap/terminfoでカスタマイズ可能)

3. エスケープシーケンス--->端末(xterm, kterm)

の3段構えだったんですね。

興味深いのは、アプリやカーネルを対応しなくても、各種環境に

1. カーソル制御ライブラリの置き換え
2. termcap/terminfo の書き換え
3. 端末(kterm/xterm)の書き換え

などで対応できそうな点です。

338 ：デフォルトの名無しさん：02/12/07 23:32

大変なことになってる。
http://pc.2ch.net/test/read.cgi/os/1039075591/l50

339 ：デフォルトの名無しさん：02/12/07 23:34

>>284
遅レスですまんが・・・
cmd *.doc *.txt　の'*'は自明のとおりshellが展開する。
copy *.doc *.txt　みたいなことは基本的にできない。
できないというより、copy Src dst っていうアトミックな
機能だけをコマンドが提供し、ループはshellが担当する
ってのが機能分割の面でメリットあると考えられたからだと
思う。

もし、copy がファイル名を展開できたとしても、次にmove という
コマンドを作るとしたら、同じようにコマンドがファイル名展開
できないと違和感あるし、コマンドの作者が違うと、ルールの
統一をするのも大変だし・・・

あとshell scriptを書かなくちゃいけないって疑問は半分正解で
半分違うと思う。
shell はスクリプトの入力先が、ファイルでも標準入出力でも
気にしないので、コマンドラインから while を打ち込んでも全然
問題ないし。

だから、コマンドラインから直接、
$ for i in *.doc
do
j=`echo $i | sed 's/doc$/txt/'`
cp $i $j
done
やるしね。

ここらへんは文化背景になっちゃうから軽くながしておいてね。

340 ：デフォルトの名無しさん：02/12/07 23:37

>>338
ﾜﾗﾀ。

341 ：デフォルトの名無しさん：02/12/07 23:51

光円錐ﾀﾝ。。

342 ：デフォルトの名無しさん：02/12/07 23:56

LightConeマヂギレ！！！

343 ：名無しさん：02/12/08 11:21

俺は、LightCore氏が連続カキコしてても気にならないけどなあ・・。

344 ：名無しさん：02/12/08 11:21

前スレがあがっていたのでage

345 ：デフォルトの名無しさん：02/12/08 13:01

名無しで連続カキコしてるやつもいるからな。コテハンだから目立つだけだよ。
＃っていうか俺は全然気にしてないけど。低脳な話してるわけじゃないんだし。

346 ：デフォルトの名無しさん：02/12/08 14:13

Emacsがどうとかシェルがどうとかはどうでもイイ話だろ？
LightConeは餓我なのか？あんま度がすぎるとム板に
NWSOSの開発スレ作ってやるぞ

347 ：ひげぽん：02/12/08 15:13

タスクスイッチに実験中(いまだ成功せず)なのですが

Monaでは

secondboot.asmにてGDT上に
セグメント 0x08 type=0x9a(特権レベル0,コードセグメント)
セグメント 0x10 type=0x92(特権レベル0,データセグメント)
セグメント 0x18 type=0x96(特権レベル0,スタックセグメント)
とセットしてブートしています。

ブート後sgdtを実行して
GDTの中身を表示してみると
セグメント 0x10 type=0x93(特権レベル1,データセグメント)
セグメント 0x18 type=0x97(特権レベル1,スタックセグメント)

特権レベルがデータセグメント・スタックセグメントで変更されています。

これのせいでタスクスイッチ時にfault0dが発生しているような気が
するのですが、どこでこのような状況に陥ったかが
つかめていない状況です。

どなたかアドバイスいただけないでしょうか。
よろしくお願いいたします。

348 ：デフォルトの名無しさん：02/12/08 15:50

それはアクセスビットがたっただけではないでしょうか？
原因は別だと思います。

349 ：LightCone ◆sSJBc30S5w ：02/12/08 15:52

>>347
NWSOSの初期化コードです。参考にして下さい。
このコードは、16BITコード(USE16)です。

OPER_PREFIXequdb66h

moveax,cr0
;AM=0(アラインメントチェックをしない)
;PG=0(ページングをしない)
;CD=NW=0(WriteThrough キャッシュ有効)
andeax,01ffbff10h
;ET ビット有効
oreax,1;PE=1,PG=0（ページングは無し）
movcr0,eax

;nosmart
;”１６ビット”のプロテクトモードへ入る。
db0e9h;jmpnear ptr Init1
dw0

Init1:;本当の３２ビットプロテクトモードへ入る
OPER_PREFIX
db0eah;jmp far ptr(Direct Inter Segment)
dd0
dwGDT_INIT32_CODE

Mona の場合、0eah が、16BIT版を使ってますが、このコードでは、
32BIT版を使ってます。

350 ：LightCone ◆sSJBc30S5w ：02/12/08 16:12

>>348
確かにそうですね。

351 ：ひげぽん：02/12/08 16:15

>>348
>それはアクセスビットがたっただけではないでしょうか？
>原因は別だと思います

アドバイスありがとうございます。
ということなので現在の状況を書かせていただきます。
もし何か気になる点がありましたら、ご指摘いただけたらと思います。

「はじめて読む486」のようにprocess1(),process2()という関数を
作成して実行の切り替えを試みています。

■前提条件
0x08 CS
0x10 DS
0x18 SS
0x20 TSS process1用
0x28 TSS process2用

352 ：ひげぽん：02/12/08 16:16

■やってみた事

/* グローバル変数 */
TSS tss[2];
byte stack[512];
{

/* process2用のTSSを用意 */
setTSS(tss + 1, 0x08, 0x10, process2Tester, 0x200, stack, 0x10, 0, 0);

/* GDT 0x20, 0x28にtssのアドレス等をセット */
/* gdt_はgdtr.base */
setDT(gdt_ + 4, (dword)tss , sizeof(TSS), TypeTSS);
setDT(gdt_ + 5, (dword)(tss + 1), sizeof(TSS), TypeTSS);

/* 現在のタスクはprocess1ですよ */
ltr(0x20);

/* 開始 */
process1();

}

353 ：ひげぽん：02/12/08 16:17

void process1() {

    while (true) {
        _sys_printf("process1");

        /* プロセス2へ切り替え */
        asm volatile("jmp $0x28, $0\n");
    }
    return;
}

void process2() {

    while (true) {
        _sys_printf("process2");
    }
    return;
}

■ひげぽんの予想する結果
process1process2process2process2process2process2・・・
■bochs上での実際の結果

00000431987i[CPU  ] task_switch: bad LDT segment
00000431987i[CPU  ] task switch: posting exception 10 after commit point
00000431987p[CPU  ] >>PANIC<< can_push(): SS invalidated.

354 ：ひげぽん：02/12/08 16:29

■やってみたこと2

LDTが必要と言われているっぽいので

GDT ldt[1];
GDT sss[1];

それぞれのtssに tss->ldt = 0x30;

/* GDT に0x30 LDT用追加 */
setDT(gdt_ + 6, (dword)(ldt), sizeof(GDT), TypeLDT);
setDT(ldt , (dword)(sss), sizeof(GDT), TypeLDT);
setDT(sss , (dword)(0), sizeof(GDT), TypeLDT);
lldt(0x30);

■結果
0000487970e[CPU ] load_seg_reg ss: LDT: index > limit
0000487996e[CPU ] prefetch: running in bogus memory

■やってみたこと3

GDT ldt[1];→GDT ldt[2];

■結果
process1fault0dと表示される。
コンソールには

002547802e[CPU ] prefetch: running in bogus memory
と表示されます。

355 ：ひげぽん：02/12/08 16:30

LightCone さん
ありがとうございます。
一部とはいえ、NWSOSのコードを見たのは初めてです。

356 ：超先生＠OS板 ◆leaf/RYZgY ：02/12/08 16:36

TSS中のLDT　SegmentSelectorやFS/GSレジスタが正しく埋まってないとか・・・？

357 ：ひげぽん：02/12/08 16:44

こんにちは超先生＠OS板さん
いつもお世話になっております。m(__)m

>TSS中のLDT　SegmentSelectorやFS/GSレジスタが正しく埋まってないとか・・・？

LDTセグメントセレクタは 0x30としています。
gs,fsは0に設定しています。

そもそもLDTってこの場合必須なのでしょうか。
だいぶ煮詰まってきました。

358 ：LightCone ◆sSJBc30S5w ：02/12/08 17:33

こういう部分がOS作りで厄介な所ですよね、、、。
今後数百回はこういう作業の繰り返しになると思います。
最終的には誰にも頼れないかもしれませんが。

359 ：ひげぽん：02/12/08 17:49

>こういう部分がOS作りで厄介な所ですよね、、、。
>今後数百回はこういう作業の繰り返しになると思います。
>最終的には誰にも頼れないかもしれませんが。

本当ですね。非常に厄介です。
また実践的な資料をなかなか見つけられないのがつらいですね。

ちょっとした間違いで失敗しているのも、全く見当違いのことをしているのも
見た目上、区別がつかないです。(特に独りよがりになっていると・・・)

そこは、LightCone さんや、超先生＠OS板さんのような
先人のアドバイスを頂きながら進めると良いなあと勝手に思ってたりします。
いつか、私もOSを作ろうとしている人たちにアドバイスできるほどになりたいです。

360 ：LightCone ◆sSJBc30S5w ：02/12/08 18:24

　今のケースは、　
　setTSS()や、setDT()の中身が正しいか、TSSの構造体が定義通りになって
いるか等を丹念に調べることと、きちっとCPUの動作を理解するしかないです。

361 ：LightCone ◆sSJBc30S5w ：02/12/09 00:50

>>359

とりあえず、MonaのSourceに一箇所間違いを見つけました。

void ProcessManager::setTSS(TSS* tss, word cs, word ds, void (*f)(), dword eflags
, byte* esp, word ss, byte* esp0, word ss0) {

memset(tss, 0, sizeof(TSS));
tss->cs = cs;
tss->ds = ds;
tss->eip = (byte)f;
tss->eflags = eflags;
tss->esp = (byte)esp;
tss->ss = ss;
tss->esp0 = (byte)esp0;
tss->ss0 = ss0;
tss->ldt = 0x30;
return;
}

　何箇所か、(byte) でキャストしてますが、(byte *)か、(dword)の
間違いだと思います。

　これは明らかに間違った挙動を起こすはずです。

362 ：ひげぽん：02/12/09 01:10

LightCone さん
貴重なお時間を割いていただいて大変恐縮です。

ご指摘の部分を修正したところ、ばっちり二つのタスクが交互に動くようになりました!!!!
ひとえにLightCone さんのおかげです。
厚くお礼を申し上げます。

成功した瞬間に、背筋がぞくぞくっと来ました。
どうもありがとうございました。

363 ：LightCone ◆sSJBc30S5w ：02/12/09 01:11

>>362
何よりですね。(^_^)

364 ：LightCone ◆sSJBc30S5w ：02/12/09 01:15

>>362
　そういえば、Monaのソースでは既にコンストラクタやデストラクタは
正常に動作するようになってるんでしょうか。
　OSを書くときに非常に便利そうなんですが。

365 ：ひげぽん：02/12/09 01:18

>>363,364
どうもありがとうございます。

>そういえば、Monaのソースでは既にコンストラクタやデストラクタは
>正常に動作するようになってるんでしょうか。
>OSを書くときに非常に便利そうなんですが

正常に動作しています。
ただし継承関係のあるクラスできちんと動くかどうかは
確かめていないです。
きちんとカプセルかできるだけでもかなりのメリットです。

366 ：LightCone ◆sSJBc30S5w ：02/12/09 01:23

　NWSCも、メンバ関数とコンストラクタ、デストラクタだけに
対応する位でも相当便利になるんでしょうけれども。。。
　でも、デストラクタを呼び出すタイミングが意外に厄介そう
だし。

367 ：LightCone ◆sSJBc30S5w ：02/12/09 01:26

goto文でコンストラクタを迂回した時にエラーを出したりするのが
メンドクサそうなのでやってないんですが。

368 ：ひげぽん：02/12/09 01:28

>NWSCも、メンバ関数とコンストラクタ、デストラクタだけに
>対応する位でも相当便利になるんでしょうけれども。。。
>でも、デストラクタを呼び出すタイミングが意外に厄介そう
>だし。
なるほどあまり深く考えていませんでした。
今のところインスタンスを大量に作ったりしないので
問題になっていないですが・・・
覚えておきます。

369 ：LightCone ◆sSJBc30S5w ：02/12/09 01:32

>>368
　#366では、コンパイラを作る時のボヤキだったんですが、
OSを作る上でも、もしかしたら、デストラクタの呼び出し
タイミングとかが問題になる可能性もあるかもしれませんね。

　でも、きっと、純粋なCで書くより開発効率は上がると
思います。羨ましい。

370 ：デフォルトの名無しさん：02/12/09 06:10

c++の本領が発揮するのはSTLだと思う。
でもOSを記述するなら、list vector などを void* ポインタ限定に
してしまえば、cでもSTLもどきは実現できる。

371 ：LightCone ◆sSJBc30S5w ：02/12/09 10:32

>>370
>c++の本領が発揮するのはSTLだと思う。
>でもOSを記述するなら、list vector などを void* ポインタ限定に
>してしまえば、cでもSTLもどきは実現できる。

リストを自動化できれば便利ですよね。NWSOSでは、おっしゃっているような
方法を用いてます。同じリスト関数群で色んなリストに適用してます。

372 ：ひげぽん：02/12/09 21:45

LightConeさんのおかげでマルチタスク実験に成功しました。
記念にimgファイルを↓におきました。
http://mona.sourceforge.jp/に

今回の件は、Monaにとって大きな節目だと考えています。
イメージサイズも33kbになりました。
FreeDOS教徒さんのブートコードも順調です！！

今までアドバイスいただいた方、手伝って下さった方々に
深く感謝いたします。m(__)m

373 ：FreeDOS教徒：02/12/09 23:05

>>ひげぽん
マルチタスク化おめ～♪

374 ：LightCone ◆sSJBc30S5w ：02/12/09 23:07

　それにしても、当初アセンブラも余り使われた事のないような状態から
よくこんな状態にたどり着きましたね。未だに信じられません。

375 ：ひげぽん：02/12/09 23:13

>>373　FreeDOS教徒さん
ありがとうございます。
これからもよろしくお願いしますね(必須)（笑）

>>374 LightCone さん
>それにしても、当初アセンブラも余り使われた事のないような状態から
>よくこんな状態にたどり着きましたね。未だに信じられません。

私も信じられないです（爆）
LightConeさんにはお世話になりっぱなしです。

376 ：デフォルトの名無しさん：02/12/10 00:12

　　　　　*　*　*
　　　　*　　　　*
　　　*　 ∧＿∧ 　*
　　　* （´∀｀)　　*
　　　*　　　　　　 *
　　　　*　　　　 *
　　　　　*　*　*
　　　　　　 |
　　　　　　 |
Mona マルチタスク化おめでとー

377 ：ひげぽん：02/12/10 00:16

>>376
ありがとうございます。
感動しますた。

378 ：デフォルトの名無しさん：02/12/10 00:27

>>377
耳のずれ方にか？ｗ

379 ：デフォルトの名無しさん：02/12/10 02:06

全然話題にならないけど
Hurdと"MAC OS X "のコアMachはこのスレの住人的にはどうなのよ？
マイクロカーネルってMachかWindowsNT系以外思いつかんが

いちおリンク
http://www-2.cs.cmu.edu/afs/cs.cmu.edu/project/mach/public/www/mach.html
http://www.zdnet.co.jp/news/0104/09/e_torvalds.html

380 ：FreeDOS教徒：02/12/10 08:15

>>ひげぽん
これからもできる限りお手伝いさせて頂きますｗ；

>>379
当方マイクロカーネル方面に疎いため、
その方式のどこがいいのか分かりません。

モジュールに分割したら、何かいいことがあるのでしょうか。

381 ：LightCone ◆sSJBc30S5w ：02/12/10 10:50

　マイクロカーネルの本質は、サブシステムを独立「プロセス」で動かすと言う
発想であって、論理的なモジュール分けを行うこと自体はモノリシックカーネル
でも行われます。単にカーネルの外にAPIの実装を出すのとも違うので、DLL
でAPIを実行するだけでは、マイクロカーネルとはいえません。

　利点ばかりであれば、大手を上げて賛同したい所ですが、本来の
目的とは裏腹に、下手すると設計がむしろ複雑になる危険性や、
速度パフォーマンスの低下の問題などもあり、反対意見が出てもおか
しくないと思います。

（システムコール発行から結果が出るまでの速度（ターンアラウンド時間）
　において不利な一方、割り込み禁止区間の粒度を「確実に」小さくできる
　利点があったりして悩みどころ。）

382 ：LightCone ◆sSJBc30S5w ：02/12/10 11:16

　はっきり個人的意見を言っちゃうと、どの分野でも「新しい概念」が現れた
ときに、「知りたい」と思う人が沢山出てきて、本当にその概念が「良いもの」
かどうかは別としてその新しい概念の研究が盛んに行われる傾向があるので、
研究が盛んであっても、その都度ちゃんと判断して見極めることが大事だと
思っています。その見極めがどっちに転ぶかは人それぞれということで。

383 ：LightCone ◆sSJBc30S5w ：02/12/10 11:30

　あと個人的な疑問なんですが、日本で独自なOSを研究以外で作ってるのって、
組み込み向けのiTRONと、超漢字(bTRON?)だけなんですか。

　日立やNECのスーパーコンピュータのOSとかはどうなってるんでしょう。

　日本では「研究」は盛んですが、実際に作っている人が少ないと
思うのは気のせいですか？　あと、OSの研究とは、OSの歴史分類や概念の
取りまとめのことなんですか?　「実際の作り方」の研究はしない?

384 ：FreeDOS教徒：02/12/10 11:56

>>LightConeさん
よく分かる説明をありがとうございます。
実装を軽くするにはモノリシックカーネル内でモジュール化
するほうが楽そうですね。参考になりました。

385 ：LightCone ◆sSJBc30S5w ：02/12/10 12:50

　現状、「マイクロカーネル」そのものをテーマに研究が行われること
さえあるのは、独立プロセスとしてサブシステムをどうやって記述すれば
いいかが自明でないからかもしれません。

　仮想記憶とファイルシステムとの結びつき、メモリシステムと仮想記憶の
結びつき、サブシステム用のプロセスのローディングとファイルサブシステム
との結びつきなど、自明とは言いがたい問題が沢山あるため、研究してみな
いとマイクロカーネル自体の利点や問題点さえ正確に把握する事が
できないのかもしれません。

　告白すると、わたしもよく知りません。

386 ：デフォルトの名無しさん：02/12/10 12:55

Hurdの開発者がマイクロカーネルはそれほど遅くなかったとか言ってたな

387 ：LightCone ◆sSJBc30S5w ：02/12/10 13:05

>>386
実は、マイクロカーネルの最大の問題点は設計が難しいことかもしれません。

388 ：デフォルトの名無しさん：02/12/10 21:31

>>383
>　あと個人的な疑問なんですが、日本で独自なOSを研究以外で作ってるのって、
>組み込み向けのiTRONと、超漢字(bTRON?)だけなんですか。

TRON系を除いて、私の知る範囲で入手可能である非研究OSは
以下のが挙げられます。きっと他にもあるでしょう。

XTAL
ttp://www.xtal.org/xt2.html

Human-OS

NOWSMART-OS
ttp://homepage2.nifty.com/nowsmart/nwsos.htm

H8/OS
ttp://www.linet.gr.jp/~mituiwa/h8/

GR-DOS
ttp://www.nekok.jp/green/k2/gr_dos/gr_dos.htm
>　日本では「研究」は盛んですが、実際に作っている人が少ないと
>思うのは気のせいですか？

気のせいです。

389 ：FreeDOS教徒：02/12/10 23:00

>>388
GR-DOSはもう一昔前に開発を終了しているはずですが？
あと、確かにこれ以外にも人知れずOSを開発してる人はいます。

世界と比べても、そう少ない割合だとは思いません。

390 ：LightCone ◆sSJBc30S5w ：02/12/10 23:33

32BIT, MultiTask に限定したりすると？
あと、x86、GUI付きに限定したりすると？

391 ：デフォルトの名無しさん：02/12/10 23:36

Machマイクロカーネルはオーバーヘッドがどうとか言っても
Mac OS Xは動いてるしHurdもいちを実用段階には入ってるんだよね？
Machっていうのは単体で動くものなの？

392 ：デフォルトの名無しさん：02/12/10 23:39

>>あと、x86、GUI付きに限定したりすると？
なんでx86限定なんだｗ
たしかにゴミのように今後もあふれるであろう32bit-x86CPUの再利用っていうのは
大事なテーマになると思うが。

393 ：デフォルトの名無しさん：02/12/10 23:39

マルチタスク化おめでとうございます。
GUI実装目指して頑張ってください

394 ：デフォルトの名無しさん：02/12/11 00:01

空想マニアのたわごとでゴメンだが、将来的にマイクロカーネルが洗練すれば、
それぞれのサーバプロセスを複数のマシンに分散できたり・・・
カーネルを2台以上のマシンで走らせたり、カーネルマシンが落ちたとしても
ホットスタンバイしてるカーネルマシンにスイッチできたりとか・・・

ドラえもんレベルの空想でごめん。

395 ：デフォルトの名無しさん：02/12/11 00:02

20年ぐらい前からそう言われてますた。

396 ：デフォルトの名無しさん：02/12/11 00:22

>あと、x86、GUI付きに限定したりすると？
Windowsがあるし、linuxがあるし、BSDもBeOSもあるし。
特にGUIの性能はWindowsがずば抜けてるし、わざわざ用意する必要がない。
日本の場合、FEPの開発もせねばOSとして使い物にならないことが
多いゆえ、OS開発の敷居は高い。それこそ、「超漢字」などという名前のOSが
あるくらい。

一方、米国人だとか欧州人はとても裕福。
週休４日なんてあたりまえで、いわゆる自分の時間を多く確保しても
メシに困らないほどの経済力がある。だから、余暇でOSやツール群に
夢中になる人の割合が多い。

この差だ。

日立、富士通、NECなどの大手は30年も昔からスパコン用のOSを作ってる。
IBM機OSのエミュがあまりにも互換性が高すぎるゆえ、スパイ罪として逮捕された
事件もあるほど。

うぬぼれるな、青木。もっと見識を「豊か」にしろ。

397 ：ひげぽん：02/12/11 00:22

>>393
ありがとうございます。

思うところがあって、Linkers&Loadersという本を買いました。
初心者向けっぽいですけど、勉強になりますね。
あと、Monaはマイクロカーネルで行く予定です。(あくまでも予定ですが・・・)

398 ：LightCone ◆sSJBc30S5w ：02/12/11 00:26

>>396
日本製を聞きたかったんですが。

399 ：LightCone ◆sSJBc30S5w ：02/12/11 00:29

FEPとかは、JUST SYSTEM等に任せればいいかと。

出来ないのは単純に技術力がないからだと思ってたんですが。

400 ：ひげぽん：02/12/11 00:39

gccインラインアセンブラの話なんですが
asm volatile("ljmp $0x20, $0\n");
はOKなのに
word selector = 0x20;
asm volatile("ljmp %0, $0": /* no output */:"g"(selector));
は
Error: suffix or operands invalid for `ljmp'
と怒られます。
この辺詳しい方いらっしゃいましたら教えていただけないでしょうか。
アセンブラ板のほうがいいのかもしれないですが・・・

401 ：デフォルトの名無しさん：02/12/11 00:45

>一方、米国人だとか欧州人はとても裕福。
日本は世界第二の経済大国ですが。

>日立、富士通、NECなどの大手は30年も昔からスパコン用のOSを作ってる。
それは、マルチタスクや、GUIを持ってましたか。

402 ：デフォルトの名無しさん：02/12/11 01:08

>>396
足引っ張るな！

403 ：デフォルトの名無しさん：02/12/11 01:13

>>400
gcc -Sしてみるとわかりますが
ljmp _selector , $0
というふうにインライン展開されています。
asmには定数を渡す必要があるので
#define FOO_CS 0x20
などとしてやる必要があります。

404 ：ひげぽん：02/12/11 01:25

>>403
ありがとうございます。
ということは、ljmp先は動的に指定できないということでしょうか。
拡張インラインアセンブラの入力パラメータは使えない？？？
でも、ljmpのオペランドは即値だけでなくメモリ、レジスタもOKだと
思っているのですが・・・

何か大きな勘違いをやらかしてそうです。→私

405 ：デフォルトの名無しさん：02/12/11 01:34

>404
セレクタだけメモリというわけにはいかないので
struct {
dword ofs;
word sel;
} far_ptr;
こんな感じで6byteのポインタを渡す必要があります。

あとあまりお奨めできない方法として
push word selector
push dword 0
retf
(NASM風記述。gasニーモニックは忘れました。)

406 ：ひげぽん：02/12/11 01:50

>struct {
>dword ofs;
>word sel;
>} far_ptr;
>こんな感じで6byteのポインタを渡す必要があります

ありがとうございます。
出来ました!!!!

407 ：LightCone ◆sSJBc30S5w ：02/12/11 10:41

ITRONの仕様書:

http://www.ertl.jp/ITRON/SPEC/mitron4-j.html

スケジューリングなどが参考になります。
OSの勉強に使えそう。

408 ：FreeDOS教徒：02/12/11 11:18

>>LightConeさん
32ビットでマルチタスクのOSといえば、OSASK、NWSOS、EOTA、MEG-OS、Mona
ぐらいしか思いつきません。
x86系、GUI付きOSはそれにMonaを除いてもう１つあります。

409 ：LightCone ◆sSJBc30S5w ：02/12/11 12:18

あと、
　SCE(SONY COMPUTER ENTERTAINMENT), 東芝, 米IBM が、2005年をめどに
新OS を開発中（SONY の AIBOは、Aperios という独自OSが載ってるらしい。）

　大手電機メーカー各社のWorkstationには、UNIXの移植版が
載っている模様。

　スパコンは、UNIXの他、独自OSが載っているのもあるらしい。

　でも多分、ハードメーカーが載せてるUNIXは、海外ソフトメーカーに委託
したか、FreeBSD等を載せているんだと思う。

BTRONは、超漢字,EOTA など。

410 ：デフォルトの名無しさん：02/12/11 12:20

JUST-SYSTEM が昔作ってた、JUST-Windowというのが国産GUI-OS。
ところが資金力尽きて、ついにWindows帝国に敗北。

正確には、土地バブルに載って購入した土地資産が1/10以下になって撃沈。
実力はあったのに本業をおろそかにして、
駄目だと言われ続けてたWindowsの拡張工事に余念のなかったマイクロソフトに
頭を下げたのが '93だから、あれからはや１０年。

元、ジャスト社員より

411 ：超先生＠OS板 ◆leaf/RYZgY ：02/12/11 12:29

　 ∧＿∧
＜　｀ー´＞-~~~
PC-98用のMS-DOSについてきたDOS-SHELLは手動タスク切り替えもできたよな・・・。

ところで、高級言語とassembleの比率は今のところどのくらいなんでしょう。 >> NWSOS他

412 ：LightCone ◆sSJBc30S5w ：02/12/11 12:47

>>411
とりあえず、ソースのバイト数:

アセンブラコード部:754KB
アセンブラデータ部:30.4KB
アセンブラヘッダ部:63.4KB
C言語コード部:362KB
C言語ヘッダ部:39.8KB

です。

今のところ、アセンブラ部が大きすぎると思うのですが、内訳は
初期化:34KB
カーネル:193KB
ファイル:99KB
割り込み:58KB
メモリ管理:66KB
DISK-DRIVER:37KB
内臓PROMPT:43KB
旧EMS MANAGER:32KB
旧DPMI MANAGER:53KB

このうち最後の3つは、今後削除する可能性があります。

413 ：みとこ ◆AEqcy/sQU6 ：02/12/11 13:17

>>411
DOSSHELLはタスク切り替えというよりタスクスワップの気が

めぐたんは現在ﾌﾙｱｾﾝﾌﾞﾘです。
ついでに、最新ビルドでもまだマルチタスクをサポートしてません(つД｀)

414 ：ひげぽん：02/12/11 14:15

>>411
Monaは
アセンブラコード：10KB(ブートからプロテクトモード移行まで)
C++コード：70KB
C++ヘッダ：10KB
ただしC++部には、ごく一部インラインアセンブラが含まれています。
またdoxygenコメントに対応するため、コメント量が多くなっていますので
C++部は実際は半分のサイズくらいだと思います。

NWSOSとの規模の差が歴然ですね・・・

415 ：ひげぽん：02/12/11 22:20

タイマー割り込みハンドラ内でタスクスイッチをしようとして
気づきました。
タスクスイッチの前にEOIは発行しなければいけないと思うのですが
iretは？疑問がいっぱい出てきました。
この辺のことに詳しい資料とかないでしょうか。
そろそろ「はじめて読む486」だけでは限界がきたかもしれません・・・
もし良い資料等ありましたら教えてくださいm(__)m

416 ：FreeDOS教徒：02/12/11 22:33

>>ひげぽん
インテルのマニュアルさえあればいいと思う。
iret自体は通常のretfにpopfを追加したものだった気がする。

必要なところを探す能力があれば、それなりに役に立つよ。

417 ：ひげぽん：02/12/11 22:52

>>インテルのマニュアルさえあればいいと思う。
>>iret自体は通常のretfにpopfを追加したものだった気がする。
>>
>>必要なところを探す能力があれば、それなりに役に立つよ。
ありがとうございます。
全くおっしゃるとおりですね。
ちょっと調べてみますです。

418 ：デフォルトの名無しさん：02/12/11 23:10

>>416
プロテクトモードのiretは結構違います
インテルの命令セットリファレンスに詳しい動作が書いてあります

419 ：FreeDOS教徒：02/12/11 23:42

>>318
いま手元に確認できる環境がないのですけど、
リアルモードとは勝手が違うのですね。

鋭い指摘ありがとうございます。

420 ：デフォルトの名無しさん：02/12/12 00:10

前スレで既出ですが一応
http://www.intel.co.jp/jp/developer/download/index.htm
インテルの日本語マニュアルPDF版

421 ：超先生＠OS板 ◆leaf/RYZgY ：02/12/12 11:12

　∧＿∧
＜　｀ー´＞-~~~ TSSはあまり使ったことがないが・・・・。

IDT上に割り込みハンドラ用のタスクゲートを置くとかできたっけかな。。。
割り込みハンドラをタスクに見立ててTSSを作っておき、
iretの代わりに実行するTSSへ向かってjmpするとか。

for(;;)
{
　/* 割り込み時はここへ飛んで来る */
　....
　....
　jmp tss_next_task; /* 次のタスクへ */
}

422 ：超先生＠OS板 ◆leaf/RYZgY ：02/12/12 11:12

423 ：デフォルトの名無しさん：02/12/12 11:13

ｽﾏｿ。なぜか多重書き込みに・・・ABoneのバグか。

424 ：みとこ ◆AEqcy/sQU6 ：02/12/12 11:44

タスクゲートはIDTにも置けます。
割り込みでタスク切り替えするとCR0のNTフラグ？がたって
iret命令でこのフラグチェックするれす。

425 ：デフォルトの名無しさん ◆mXrBwDDzyw ：02/12/12 20:16

記念パピコ

426 ：デフォルトの名無しさん：02/12/13 01:27

monaに期待

427 ：ひげぽん：02/12/13 01:30

>>421 超先生＠OS板さん
>>424 みとこさん

いろいろとアドバイスありがとうございます。
週末に試してみます。

やっぱり平日はなかなか作業できないっす。
そのかわり年末年始にガツンとがんばります。

428 ：デフォルトの名無しさん：02/12/13 02:17

わーい、今日はじめてbochsいれてhigepos.bin動かしてみました。
過去ログどおりにやったら動いた。
ちょっと感動。

429 ：超先生＠OS板 ◆leaf/RYZgY ：02/12/13 13:54

>424
　∧＿∧
＜　｀ー´＞-~~~
ということは割り込み用tssのtask chainに次のタスクを入れてiretすれば楽勝ですな。
元のtssはbusy flagを手動で消さないとダメか・・・。

430 ：超先生＠OS板 ◆leaf/RYZgY ：02/12/13 13:54

431 ：デフォルトの名無しさん：02/12/13 13:55

また多重に・・・ｽﾏﾝｶｯﾀ。ABone作者を小一時間問い詰めておきます。

432 ：みとこ ◆AEqcy/sQU6 ：02/12/13 15:24

どうでもいいけどTSSのビジー消しは面倒ですね。
昔、RMに落ちた後PM戻るPG書いたとき一般保護例外発生して困って
よく調べたらビジーTSSが原因だった、、、（＞＜

433 ：ひげぽん：02/12/14 00:15

今の３倍くらい勉強しなければだめだ。
と最近思います。

434 ：デフォルトの名無しさん：02/12/14 02:36

ひげぽんもLﾀﾝも頑張れ

435 ：デフォルトの名無しさん：02/12/14 06:19

この静けさ。どうやら、LさんもHさんもコーディングにいそしんでるご様子。

436 ：デフォルトの名無しさん：02/12/14 15:11

ライトコーンﾀﾝってどっかで見たことあるなと思ったらこれか！Σ(ﾟДﾟ )

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

437 ：デフォルトの名無しさん：02/12/14 15:30

販売中か！カッコイイ

438 ：LightCone ◆sSJBc30S5w ：02/12/14 23:16

>>437
販売中なのは、Windows用の統合開発環境です。
OSは無料で自由にダウンロードして使えるようになっています。

439 ：デフォルトの名無しさん：02/12/15 10:41

Light氏のHP見てると、とても個人の作品群とは思えないラインナップだな。
リンカ、ライブラリアン、アセンブラ、ANSI-Cコンパイラ、NWSOSですか･･･

どうも、漏れはケンカ売る相手、間違えたっぽい。
もう、このスレに来ません。ごめんなさい。

440 ：朝鮮製＠OS板：02/12/15 11:32

　∧＿∧
＜　｀ー´.＞-~~~

へへへ、俺って顔つきも朝鮮人だろ？
発音も「超先生」と同じ、兄弟さ。
テポドンのOSを作ったのは、何を隠そう、このワシじゃ。

ＯＳに関して、右に出るものはいない。
さぁ、質問してきなさい。ＨもＬも。
ひゃひゃひゃ。

441 ：デフォルトの名無しさん：02/12/15 13:08

x86の特権レベル1と2って使ったことがないな
効果的な利用法ってあるのだろうか

442 ：超先生＠OS板 ◆leaf/RYZgY ：02/12/15 14:00

　∧＿∧
＜　｀ー´＞-~~~ PL1,2は使いものにならない、がファイナルアンサー。
ページレベル保護はU/Sの２段階しかないのでほとんど無意味ですな。

443 ：LightCone ◆sSJBc30S5w ：02/12/15 14:53

>>442
私も同感です。

　システムコールに一旦入ってしまえば、コール元の各種属性はいくらでも
知ることができるので、わざわざCPU定義のレベル1,2で判別する意味がない
ので、もし、レベル1,2に利用価値があるなら、CPU命令を実行中の自動保護、
例えば、「ページレベル保護」などに変化が付けられるなどに限定されるはず
なんですが、IA32の場合そこに実質的な変化が付けられないので意味がない、
という説明ができると思います。

結論的には、超先生のおっしゃる事の通りだと思います。

444 ：441：02/12/15 18:32

やはり、使えませんか。

JITコンパイラ実装時にリミットの異なるセレクタを用意して、
JITコンパイラ自体を保護できないか、などと考えてみたのですが。

445 ：朝鮮製＠OS板：02/12/15 20:00

∧＿∧
＜　｀ー´.＞-~~~
ふむふむ、既に弟の超先生が、
レベル1,2の蛇足っぷりを示してしまったようだな。

446 ：ひげぽん：02/12/15 21:15

タスクスイッチ勉強中(若干逃避(ﾉ´∀｀*))
http://www.research.att.com/sw/tools/graphviz/

こんなツール入れたらdoxygenで生成されるドキュメントに
カッコイイ図が！！！
こんなの↓
http://mona.sourceforge.jp/html/classX86MemoryManager__coll__graph.png

447 ：デフォルトの名無しさん：02/12/15 21:45

>>446
うぉ。ｶｺｲｲこれとかｶｺｲｲ
http://mona.sourceforge.jp/html/monaTypes_8h.html

448 ：LightCone ◆sSJBc30S5w ：02/12/15 23:21

>>444
　セレクタの要求レベルを使った保護なら、レベル1,2が有効に使える可能性
は有ると思います。

449 ：デフォルトの名無しさん：02/12/16 17:59

ちょいっとメモリ管理について質問します。

Ｘ３８６でメモリ管理する場合って、
例えば、連結リストで物理アドレスにダイレクトマッピングして
管理しているとする時でも、eip, espって結局オフセット値ですよね？

だから、コンテキストスイッチするには
最低限度、cs:eip ss:esp cr3とかは退避しないと駄目なんですか？

ハードウェアのメモリ管理機構とＯＳでのメモリ管理との繋がりが
よくわからないです。書ボーン。

だれか～目から鱗落させてクダサイ＞＜

450 ：デフォルトの名無しさん：02/12/17 00:31

そういえばアメリカの中学生グループがWindowsみたいなGUIを持ったOS作ってたよね。
あれはどうなったのかな？

451 ：デフォルトの名無しさん：02/12/17 00:40

セグメントと論理の違いをべんきょうしる。
３８６アーキテクチャはちょっとむずいかも。

452 ：デフォルトの名無しさん：02/12/17 00:44

S370は単純でおすすめ

453 ：デフォルトの名無しさん：02/12/17 00:48

286はなんで動作レベルが5段階にもなってたんだろう？
あれにはページングがなかったからセグメントのレベルだけで
保護してたわけだけど、意味あったのかな？
もしかして386が4段階の動作レベルを持つのってその名残？

ウンチク的な役に立たない話ですんまそん。

454 ：デフォルトの名無しさん：02/12/17 01:38

453>> 286+α=386だからあなたの予想は的中なのだ
セグメント＋リミット＋ページング＋コールゲート
なのだ

455 ：朝鮮製＠OS板：02/12/17 06:16

　∧＿∧
＜　｀ー´＞-~~~
>JITコンパイラ実装時にリミットの異なるセレクタを用意して、
>JITコンパイラ自体を保護できないか、などと考えてみたのですが。
ほうほう、君はひょっとして首藤ｸﾝかね？

456 ：デフォルトの名無しさん：02/12/17 23:40

保守

457 ：朝鮮製＠OS板：02/12/18 07:18

　∧＿∧
＜　｀ー´＞-~~~
図星かね？

458 ：デフォルトの名無しさん：02/12/18 14:21

須藤先輩…(；´Д｀)ﾊｧﾊｧ

459 ：デフォルトの名無しさん：02/12/18 15:51

part3ダット落ち。。。
読みたかったのに。
だれか保存してたら下さい。

460 ：みとこ ◆AEqcy/sQU6 ：02/12/18 15:59

http://meg-os.org/2ch/1027080631.dat

461 ：デフォルトの名無しさん：02/12/18 18:26

>460

ありがとうございます！

ですが。。。なぜか家に帰ってから見たらDAT落ちしてない。。
外で見たときは落ちてたのに。
なぜだぁぁぁ・・・

462 ：みとこ ◆AEqcy/sQU6 ：02/12/18 18:30

●もちですか？(；´Д｀)

463 ：ひげぽん：02/12/18 21:31

最近、いろいろと勉強中で見た目上あまり進んでないのですが
年末年始にドーンと更新しようかと思います。(あくまで予定ですが)

タイマ割り込みでタスクスイッチできずです・・・

464 ：デフォルトの名無しさん：02/12/18 22:46

>>463
ひげぽんﾀﾝ、がんばれり。
なまあたたかく応援sage

465 ：ひげぽん：02/12/18 23:46

>>464
なまあたたかい応援ありがとうござます（笑）

ところでこのスレを見ている人たちは
他にはどんなスレッドを見ているのでしょうか。
やっぱりNWSOSやOSASKのスレッドですかね。

466 ：デフォルトの名無しさん：02/12/19 00:20

>>465
ココしか見てない。他は自分にとってあまり有益でないから。。。と言うか『ひどいインターネット』だから
OSをつくろうはpart2から見てるけどすっごく勉強になってる。

467 ：デフォルトの名無しさん：02/12/19 01:28

コス萌え
http://www.cosmoe.com/

468 ：デフォルトの名無しさん：02/12/19 10:06

>>465
個人的にボードコンピュータを使用することがあるので、
monaを自分が制御したいもののタスクスイッチとして使えたら
いいなと思ってここ見てます。まだ夢の話ですが。

469 ：デフォルトの名無しさん：02/12/19 20:46

>>465
漏れの場合は、OSASK系ｽﾚがメイン。
ひげぽんのｽﾚを見て和製OSを知ったり。

470 ：みつみ里美 ◆CBIOIS./eo ：02/12/19 20:55

割り込み関数を書くときは、スタックフレームを
明示的に扱わないとハマるよ（｀□´）くわ～っ

さて原稿～(;´д｀)へろへろ

471 ：デフォルトの名無しさん：02/12/19 20:57

ﾐﾂﾐﾀﾝﾊｧﾊｧ

472 ：デフォルトの名無しさん：02/12/19 22:00

あの･･･
馬鹿なOS作って、実験かねて実機で動かして
マシンがぶっ壊れた（ﾟ∀ﾟ）なんてことはありうるのでしょうか？
あったら体験談おね

473 ：デフォルトの名無しさん：02/12/19 23:12

>>465
俺もここしか見ない。
OSASK は Web 見て、愕然としたから、もう見ない。

>>472
ディスクの中身を飛ばすことはあるが、ハードウェア的に壊れることはまずない。

(もちろん、その PC が、ロボットや溶鉱炉の制御してるとか言うんなら話は別だぞ。
あと、頑張れば BIOS 書き換えぐらいは可能性があるけど、意識的にやらないと
なかなか難しい。)

そう言う意味で、開発機と実験機は分けたほうがいいと思う。
(一緒だと、リブートの嵐だからね。)
今時なら、中古の Pen133MHz 機程度なら \5,000 ぐらいで売られてるから、そう言うのを
使えばいいと思うよ。

474 ：デフォルトの名無しさん：02/12/19 23:57

>>472
PCじゃないけど…ドライバいじってる時、なぜかNICが壊れた事あり。
原因はいまだに不明。
試作ハードだったから、ハード的な問題だったのかもしれない。

475 ：デフォルトの名無しさん：02/12/20 01:49

　概ねファイルシステムが出来たと思って遊んでいたら、ハードディスクが
論理的に破壊された経験をもつものです（汗）。
　原因は、PC-98x1のBIOS呼び出し時の、CFフラグの1,0が逆になって
いただけ。

　それからというもの、ハードディスク書き込み恐怖症になり、
さらに厳重にするため、開発機と実験機を分けるようになりました。

　一種のトラウマですが、良い経験だったかもしれませんね(^_^;;)

476 ：げすきー：02/12/20 06:12

ハナゲを抜いたときの痛さと、
ＯＳ開発時にＨＤを吹っ飛ばす痛さと、

どっちが痛いですか？

477 ：みつみ里美＠しゅら場もーど ◆CBIOIS./eo ：02/12/20 06:27

新刊落としたときの痛さに勝るものはないよ～！≡≡(つдT)ひぃいい～！！

>>472
初代IBM PC/ATでPICのバッファリングモード使うと焼けるよ。
SP/ENがGND直結で危険（｀□´;）
最近の統合chipsetではそんなこと絶対に起きないけどね（｀ー´）ふふり

478 ：デフォルトの名無しさん：02/12/20 08:18

>>465
ひげぽん、がんばれ～こっちはﾏﾀｰﾘしてるからｲｲ!!
私は技術がないんでとても協力なんてできませんが
使う側としてmonaをしっかり見ていきたいと思います。

NWSOSは見てます、ちょいと揉めてるみたいですけど。
OSASKは見ていません。

でもでも、個人的にはﾒｸﾞOSが好きかなぁ（ﾎﾞｿ
ｷｬﾗとかじゃなくてなんか、AIぽいのが好きなんです。HALとか・・・(ｵﾀ

479 ：みとこ ◆AEqcy/sQU6 ：02/12/20 11:49

#osdev-j ・・・(ﾎﾞｿ

480 ：デフォルトの名無しさん：02/12/20 14:13

正直な所2ch製のOSなんて誰も使いたくないなぁ。
ひげぽんはMegaBBSとかいちごBBSでﾏﾀｰﾘやったほうがよかったんじゃないかと思う

481 ：デフォルトの名無しさん：02/12/20 14:24

2ch製といっても、作ってるのはひげぽんだからな
別にいいと思うけど。

482 ：デフォルトの名無しさん：02/12/20 14:43

>>480
おまい、2chブラウザとかも使うなよ。

483 ：デフォルトの名無しさん：02/12/20 18:53

でたよ、詭弁の特徴が。

484 ：デフォルトの名無しさん：02/12/20 22:29

なぜ誰も使いたくないと断言できるのか。不思議だ。そういうもんか。

485 ：デフォルトの名無しさん：02/12/21 01:05

monaはオープンソースですが、何か？ｗ

486 ：ひげぽん：02/12/21 01:18

Mona環境でSTLを使えるように環境構築してくれる人募集です。

といってみるテスト
すべて使えるようにならなくていいっす
コレクションが使えるだけで十分です。

string.hで定義されている関数が必要になりそうです。

よろしくおねがいいたします。

487 ：デフォルトの名無しさん：02/12/21 03:31

ところで、
bochs-winで起動させるディスクイメージは
どうやって作ってるの？
WINDOWSで。ddとかだとバグったし・・

488 ：ひげぽん：02/12/21 13:11

>>487
http://uranus.it.swin.edu.au/~jn/linux/rawwrite.htm
rawwrite.exeで作成しています。

この辺のことは、どこかにきちんと記述をしたほうがよさそうですね。
ご指摘ありがとうございます。

489 ：ひげぽん：02/12/21 15:53

>>479
>#osdev-j ・・・(ﾎﾞｿ
osdev-jはレベルが高いですよね・・・
勉強不足を痛感させられる空間ですね。

490 ：みとこ ◆AEqcy/sQU6 ：02/12/21 15:53

じゃひげぽんたんもっと来るれす

491 ： ◆TntnZ0uG.g ：02/12/21 16:09

>>489 超先生来てるよ

492 ：henoheno＠OS板 ◆mXrBwDDzyw ：02/12/21 18:01

>>486
STLの話題を出されたので。

STLの移植に関してですが、STLportはいかがでしょう。
http://pc.2ch.net/test/read.cgi/os/1039075591/337

STLport は SGI STL を移植する方向に持って行ったものから
スタートしたものです。

493 ：ひげぽん：02/12/21 18:05

>>491
相変わらずレベル高し。

タイマー割り込みによりタスク切り替えを実現すべく
インテルのマニュアルを読んでいました。

(1)EFLAGSレジスタのNTフラグをセットする。
(2)現行タスクのバックリンクを次のタスクにする。
(3)(現行TSSビジーを解除?)
(4)iret

(1)(3)のやり方が分かりません。
そもそもそんなもんは不可能だ！等アドバイスいただけないでしょうか。

494 ：ひげぽん：02/12/21 18:10

>>492
ありがとうございます。
>STLの移植に関してですが、STLportはいかがでしょう
ほう、こんなものがあるんですね。

STLは一部でも良いので使えるようになるとうれしいですね。
誰か詳しい人いないかな。

495 ：超先生＠コーディネーター ◆leaf/RYZgY ：02/12/21 18:26

　 ∧＿∧
＜　｀ー´＞-~~~
>(3)(現行TSSビジーを解除?)

NT=1でiretすれば自動的にbusy解除されるはずです。

>(1)EFLAGSレジスタのNTフラグをセットする。

popfd命令でEFLAGSを変更できるはず。

496 ：ひげぽん：02/12/21 18:39

超先生＠コーディネーターさんありがとうございます

pushfd,popfdを
組み合わせれば何とかいけそうな気がしてきました。

497 ：デフォルトの名無しさん：02/12/21 22:32

>>495
ガンダムseedでつか？

498 ：ひげぽん：02/12/21 23:21

NTフラグをセットしてiretしてみました。
bochs君に IRET: TR not valid
と怒られました。
現在調査中です。

499 ：げすきー：02/12/22 05:35

ハナゲを抜いたときの痛さと、
LﾀﾝのＧＰＬ叩きの痛さと

どっちが痛いですか？

500 ：超先生＠OS板 ◆leaf/RYZgY ：02/12/22 06:40

　 ∧＿∧
＜　｀ー´＞-~~~ そういえば。
切り替え先TSSのbusyフラグを立てておかないと、無効TSSで落ちるかも。。。。

ctrl_xfer_pro.cppのBX_CPU_C::iret_protectedを参照。

501 ：デフォルトの名無しさん：02/12/22 07:31

>>どっちが痛いですか？
痛さの単位。１ハナゲ。

どっかの学者が4/1に言ってたっけ。

502 ：デフォルトの名無しさん：02/12/22 07:32

ね、ひょっとしてC++で書かれたカーネルって世界的に見ても、
MONAが先駆？

503 ：ぁゃしぃ肉球苦楽撫：02/12/22 07:45

あのぺーじ、復活させて～。

504 ：デフォルトの名無しさん：02/12/22 11:47

>>502
NT系はC++じゃない？

505 ：ひげぽん：02/12/22 15:09

bochs2.0がリリースされた模様。

506 ：ひげぽん：02/12/22 15:50

超先生＠OS板さん
ご指摘の通り、切り替え先をTSSBusyにしたらOKでした。
いつもいつもありがとうございますm(__)m

ということでタイマ割り込みによりタスクスイッチする実験に
成功いたしました。

アドバイスいただいた方々ありがとうございました。

ところでbochs2.0ですが
文字色が違いますね。
ピンク（実機&bochs1.41)
紫(bochs2.0)

なぜ？

507 ：デフォルトの名無しさん：02/12/22 16:02

>>504
C++かもしれないが、多分殆どCに近い書き方なんじゃ
ないかなあ。C++で書くと一口に言っても、その内容は
ピンきりだからねえ。

508 ：デフォルトの名無しさん：02/12/22 16:13

>>507
そういう意味ではMonaは稀有。

509 ：デフォルトの名無しさん：02/12/22 17:18

EPOCなんかはテンプレートも使っててばりばりにC++で
書かれてる。。

510 ：デフォルトの名無しさん：02/12/22 19:59

ところでそろそろ関連リンクをまとめない？
俺はやらんが。

511 ：デフォルトの名無しさん：02/12/22 20:51

>>507
なぜそう思う？

512 ：デフォルトの名無しさん：02/12/22 21:12

>>510
やってたりします。お楽しみに。

513 ：デフォルトの名無しさん：02/12/22 21:28

>>512
期待age

514 ：ひげぽん：02/12/22 23:45

皆さんのおかげで
タスク管理のテストにだいぶ成功してきました。

そこで本格的にタスク管理の設計に入る前に
どうも自分がきちんと理解できていないメモリについて
勉強をしようと思っています。

メモリについては、はじめて読む486以外では
あまり勉強できていません。

特に、以下のキーワードの理解があいまいで
非常に心許ない状態です。
OSを作るうえで非常に重要だと思うので
参考になる書籍・WEB資料を教えていただけないでしょうか。

■キーワード
・スタック
・CS,DS,ES
・フラットモデル
・セグメント
・ページング
・タスクゲート
・GDT
・ローダー

よろしくお願いいたします。

515 ：FreeDOS教徒：02/12/23 00:12

>>ひげぽん
‥‥ドンマイやね。

【フラットモデル】
あるアプリケーション内でコード、データ、スタックが同一のレジスタですべて
アクセスできること。
要するにセグメントレジスタ不要な環境のこと、らしいですよ。

516 ：デフォルトの名無しさん：02/12/23 00:34

スタック分からないとは．．．本人ですか？>>ひげぽん

オペレーティングシステム
ttp://www.csg.is.titech.ac.jp/~chiba/lecture/#os
とか、どっかの大学の講義資料を見るのがいいと思う。

517 ：ひげぽん：02/12/23 00:50

>>515
どうもです。
そこまでは分かるのですが
どういうメリットがあって、他にどういうモデルがあるかとか
タスクスイッチが絡んだ場合どうなるかとかが知りたいです。

>>516
本人ですよ（笑）
資料ご提示ありがとうございます。

どうも表面的なことは分かるのですが
上記のキーワードは
ちょっと突っ込まれると自信がなくなるやつらです。
人に教えるほどは分かってない状態です。（これで伝わりますでしょうか。)

こいつらの理解が浅いため、Linker&Loadersとか
読むと？？？状態に陥ります。
基礎体力が足りません。

518 ：ひげぽん：02/12/23 00:54

恥は今のうちにかいておきます。

519 ：FreeDOS教徒：02/12/23 10:10

>>ひげぽん
私はWindowsプログラミングをしたことないのでアレなんですが。
「アーキテクチャ徹底解説 Microsoft Windows2000」
なんかが良かった記憶が。

520 ：ひげぽん：02/12/23 11:15

>>519
>「アーキテクチャ徹底解説 Microsoft Windows2000」

ありがとうございます。
本屋で立ち読みしてみます。
今日はいろいろと勉強の日にしようかと思います。

521 ：デフォルトの名無しさん：02/12/23 11:24

>>ひげぽん
スタックについて
ttp://tt.sakura.ne.jp/~suzu/asm/8.html

522 ：ひげぽん：02/12/23 11:53

>>521
ありがとうございます。

フラットモデルについて
CS=DS=SS=ESとすることのようですが、疑問点があります。
どなたかアドバイスをいただけないでしょうか。

プロテクトモードではGDTにより、セグメントを定義できます。
フラットモデルの場合、各レジスタの指すセグメントがまったく同一
（つまりベースもリミットも同じ)という理解で良いんでしょうか。

GDTにはセグメントタイプを指定するところがあるので4つエントリを作成して
それらのエントリはベース・リミットも同一ということでしょうか。

もし仮に上記のようだと仮定した場合、物理メモリ上におかれるコードと
スタックは位置的にどのような関係にあるのでしょうか。

523 ：ひげぽん：02/12/23 12:06

連続書き込みご容赦ください。

スタックオーバーフローという言葉を耳にしますが
スタック領域が足らず、コードやデータを破壊してしまう
ことだと認識しています。

スタックが上方、下方どちらに伸張するかを別にしても
CS=DS=SS=ESの場合、スタックとコードの区分けは誰が管理
しているのでしょうか。
OS、CPU、各アプリケーション？

またタスク切り替え時には、スタックの切り替えが必須ですが
タスクAのスタックとタスクBのスタック
区別・管理するはOSという認識であっていますでしょうか。

この辺のことはおそらく基礎の基礎だと思うのですが
理解できていません、どなたかアドバイスをいただけないでしょうか。

524 ：デフォルトの名無しさん：02/12/23 12:18

>>523
OSが実現したいと思っているメモリ保護モデルを、
CPUはサポートするだけであって、強制するわけじゃあない、
というのはOKですかいな？

なんかCPUに流されてるように見える...

525 ：ひげぽん：02/12/23 12:30

>>524さん
>OSが実現したいと思っているメモリ保護モデルを、
>CPUはサポートするだけであって、強制するわけじゃあない、
>というのはOKですかいな？

OKです。

・どんなメモリ保護モデルがあるのか？
・そのモデルを実現するにはどのような手段があるか？
・ターゲットCPUはどのようなメモリ保護機構を備えているか？

等、次元が違う事柄を混ぜて考えて混乱しているのだと思うのですが
勉強すると>>522 >>523のような疑問がでてきてしまいます。

526 ：デフォルトの名無しさん：02/12/23 13:17

CSとDSとSSのリミットやベースを変えると高級言語の多くの処理系で問題が出てきます
(コード領域の定数やスタック上のデータをデータ領域のデータと同様に扱うため)

ページング機構で各プロセスのメモリ空間自体を分離するのが一般的だと思います
このモデルの利点は(一部の安価なCPUを除きますが)移植性が比較的高いことです
セグメント機構はx86に強依存するので積極的には使われていません
(例外はTOWNS-OSやOSASK、286を意識したWindows3.1のようなOS)

コード領域は読み込み専用ページにして保護
スタックの前後に読み書き不可ページを用意してオーバーフロー、アンダーフローを検知
オーバーフローを検知したら実ページを割り当てスタック伸長
タスクスイッチのスタック切り替えはページテーブル(のアドレスCR3)とESPを切り替える

527 ：ひげぽん：02/12/23 14:09

>>526さん
アドバイスありがとうございます。

>CSとDSとSSのリミットやベースを変えると高級言語の多くの処理系で問題が出てきます
>(コード領域の定数やスタック上のデータをデータ領域のデータと同様に扱うため)

なるほど了解いたしました。

>ページング機構で各プロセスのメモリ空間自体を分離するのが一般的だと思います
はじめて読む486にもページングの解説がありましたので読みなおしてみます。

>コード領域は読み込み専用ページにして保護
>スタックの前後に読み書き不可ページを用意してオーバーフロー、アンダーフローを検知
>オーバーフローを検知したら実ページを割り当てスタック伸長
>タスクスイッチのスタック切り替えはページテーブル(のアドレスCR3)とESPを切り替える

なるほどなるほどページングを利用するとこんなことが出来るのですね。

現在Monaではページングを利用していないのですが
ページングを利用しないときには、タスクスイッチ時の
スタックポインタはOS側が切り替えるという認識であっていますでしょうか。

528 ：デフォルトの名無しさん：02/12/23 14:50

便乗で申し訳ないが
タスク切り替え時のEBPとかはどうなってるのか知りたい。

529 ：ひげぽん：02/12/23 15:17

Monaで
CS,DS,SSすべて、BASE=0,LIMIT=0xFFFFFFFFとしてみました。

bochs君に
[CPU ] can_push(): expand-down: esp-N < limit
と怒られてしまいました。

530 ：デフォルトの名無しさん：02/12/23 16:05

>５２９
>bochs君に
[CPU ] can_push(): expand-down: esp-N < limit
と怒られてしまいました。

espがssのlimit下回ると#GPが発生するみたいですね。（えくすぱんどだうんでは。）

えくすぱんだうんはどこか理解しにくいですね。（へんな気分になる（爆））

531 ：ひげぽん：02/12/23 16:08

>>530
どうもありがとうございます。
ということは、ssのリミットは大きくしてしまうと
それだけでエラーになってしまうということでしょうか。

532 ：デフォルトの名無しさん：02/12/23 16:12

INTEL依存のOS作っている人なら分かると思いますが、
OSといってもソフトウェアなわけで、結局のところハード依存
になってしまうんですよね。
だから、数学的な理論以外ではソフトでは限界なんです。
だから、OS作成にツーな方は、そのうちCPU設計の方に興味が
行きやすいですね。

現にﾘｰナス氏はlinux作成者ですが、半導体メーカに勤めていることが
その理由だと考えられます。

533 ：デフォルトの名無しさん：02/12/23 16:17

>531

esp > ssのlimit であればエラーは起きない筈。
だから、limit = 0xffffffff
ってありえないんですかね？
実はよくしらないっす（汗）

534 ：デフォルトの名無しさん：02/12/23 18:19

☆CPUをつくろうpart1☆

だれかつくってｗ

535 ：デフォルトの名無しさん：02/12/23 18:28

>>529
expand-down
0<-アクセス不可->limit<-アクセス可能->0xffffffff

eapand-up
0<-アクセス可能->limit<-アクセス不可->0xffffffff

536 ：ひげぽん：02/12/23 21:03

>>535
>expand-down
>0<-アクセス不可->limit<-アクセス可能->0xffffffff
>eapand-up
>0<-アクセス可能->limit<-アクセス不可->0xffffffff

ありがとうございます。
expand-upにすれば良いということですね。
...と調べてみたのですが分からなかったので
intelのマニュアルを精読中です。

537 ：デフォルトの名無しさん：02/12/23 21:33

http://mona.sourceforge.jp/index.html
文字化けしてます。

環境は IE 6.0 + SP1.

538 ：デフォルトの名無しさん：02/12/23 21:38

同じく文字化け
Opera 6.05
SJISとＣＳＳの関係か？

539 ：ひげぽん：02/12/23 21:40

すいません。私のアップロードミスです。
直りましたか？

ちなみにこのページは (・∀・)yossy◆FlasH.X1/s さん作です。(感謝)

540 ：537：02/12/23 21:45

IE6.0 + SP1
直った！

ひげぽんがんがれ

541 ：ひげぽん：02/12/23 21:54

METAタグで
text/html; charset=Shift_JIS
を指定して
ファイルの文字コードをSHIFT-JISにしているのに
文字化けが起きていたようなので、
緊急避難的にEUCに変換後アップロードしました。

するとIEは文字コード自動認識でEUCと判断してくれて
OKという状態のようです。

でもこんどはNN4.78で文字化け(泣)

542 ：(・∀・)yossy ◆FlasH.X1/s ：02/12/23 22:01

皆さん、始めまして
秘密裏にMonaWebDesignerになっていた(・∀・)yossy◆FlasH.X1/sです
これからちょくちょく2chにも顔だそうかと思います。

今、MPDN(MonaProjectDeveloperNetwork)という、開発者向け情報のページを作成中です。
お楽しみに。
ちなみに、>512は私です。

543 ：デフォルトの名無しさん：02/12/23 22:04

>>541
sourceforge.jpは、EUC-JP以外ダメっす。
charset=euc-jp指定しましょう。

544 ：ひげぽん：02/12/23 22:15

>>543
アドバイスありがとうございます。
IE6 & NN4.78で確認できますた。

(・∀・)yossy さん本当にありがとうございます。

545 ：デフォルトの名無しさん：02/12/23 22:45

直ったぞ。
Opera 6.05

546 ：ひげぽん：02/12/23 22:47

>>545
ご確認ありがとうございます。

ついでにカウンタも動くようになりました。

547 ：ぁゃしぃ肉球苦楽撫：02/12/23 23:14

あした去勢に逝ってきます

548 ：デフォルトの名無しさん：02/12/23 23:28

>>542
(・∀・)ｲｲﾈ!!

549 ：デフォルトの名無しさん：02/12/23 23:59

現在：　　NWSOS > MEG > MONA
半年後：　MONA > NWSOS > MEG

550 ：ひげぽん：02/12/24 00:34

>>549
>現在：　　NWSOS > MEG > MONA
>半年後：　MONA > NWSOS > MEG

いやそんなことないです(断言)
現実的に考えて、無理です。

現在の私の主観では、ひげぽんが現在レベル2だとすると
LightConeさん、みとこさんはレベル50以上です。
経験・知識・今までの実績すべてにおいてぜんぜんかないません。

まあお二人を追い抜くことを目標にするのはありかもしれませんが（笑）

551 ：ひげぽん：02/12/24 00:37

さて次の目標は「ページングを実現すること」
にします。

幸い「はじめて読む486」に詳しい解説があるようなので
やってみます。

でもメモリに関しては、まだ？なところがたくさんあります。

552 ：デフォルトの名無しさん：02/12/24 01:06

>>534
焼くのが目標なのか、エミュレータを作るのが目標なのか・・・・

553 ：デフォルトの名無しさん：02/12/24 01:09

>>550
御安心下さい。
自作自演レベルは既に50以上ですよ。

554 ：デフォルトの名無しさん：02/12/24 01:43

>>半年後：　MONA > NWSOS > MEG

まともなGUIを配備している唯一のOSはNWSOSだし、
MONAはまだそういう段階ではないので、未知数。
というか比較不能。

カーネルレベルでは、確かにMONAがNWSOSを追い抜く可能性は高いけど
GUIは別。実際、リーナス氏ですら、GUIに関してはとんだ素人だしね。

555 ：デフォルトの名無しさん：02/12/24 01:56

>>553
そういうのﾔﾒﾚ
ﾓﾁﾍﾞｰｼｮﾝｦ下げてどうする。

556 ：みとこ ◆AEqcy/sQU6 ：02/12/24 02:39

見た目にだまされちゃだめ。
現時点のカーネルの完成度は NWSOS > MONA > MEG ですよvv

557 ：みとこ ◆AEqcy/sQU6 ：02/12/24 02:43

慣れないブラウザ使ったんであげちまったっす。
吊ってきまつ。。。

558 ：デフォルトの名無しさん：02/12/24 04:12

>まともなGUIを配備している唯一のOSはNWSOSだし、
NWSOSの各窓には、Windowsのようなデバイスコンテキストみたいなものがあるの？
点を打ったりラインを打ったりするのも、デバイスコンテキスト経由かな？

というか、NWSOSのGUI-APIのドキュメントってどこ？
ぷりーず！

559 ：LightCone ◆sSJBc30S5w ：02/12/24 08:52

>>558
>NWSOSの各窓には、Windowsのようなデバイスコンテキストみたいなものがあるの？
あります。

>点を打ったりラインを打ったりするのも、デバイスコンテキスト経由かな？
そうです。

しかし、Windowsだと、hDC を、全てのGDI関数の第一引数に渡しますが、
NWSOSだと、「カレントDC」をスレッド単位に持っていて、暗黙のうちに
カレントDCに対して描画されます。

>というか、NWSOSのGUI-APIのドキュメントってどこ？
http://homepage2.nifty.com/nowsmart/nwsosapi.htm#NWSOS API
の「グラフィック API」のところに一覧があります。

カレントDCを設定するAPIは、今のところ三種類用意されてます。

BOOL gfSetWholeDC( HWND hWnd ); カレントウィンドウを設定（全体描画）
BOOL gfSetClientDC( HWND hWnd ); カレントウィンドウを設定（クライアント領域）
BOOL gfSetClipDC( HWND hWnd, int clipX, int clipY, int clipSx, int clipSy ); カレントウィンドウを設定（任意領域）

560 ：デフォルトの名無しさん：02/12/24 09:04

仮想デバイスコンテキストなんかも、作れるの？

561 ：LightCone ◆sSJBc30S5w ：02/12/24 09:16

>>560
>仮想デバイスコンテキストなんかも、作れるの？
今のところ作れません。

562 ：LightCone ◆sSJBc30S5w ：02/12/24 09:18

>>560
　ただ、描画している様子を見せたくないと言う事が目的なら、
仮想VRAMを利用できます。

また、独自のグラフィックライブラリを作りたい場合は、

>void gfPutImage( int tx, int ty, int sizeX, int sizeY, BYTE *pImage, EIMAGE_TYPE typeImage ); 指定イメージの描画
>自動形式変換機能搭載

こういうものを利用すると出来ます。

563 ：デフォルトの名無しさん：02/12/24 09:27

＞　ただ、描画している様子を見せたくないと言う事が目的なら、
＞仮想VRAMを利用できます。
ん、あ、例えば、CADなんか作ってると、Windowに収まらない領域なんかへも
きちんと描画しとかないと、毎回描画しなおしなわけで。

裏側に、大きな仮想画用紙を用意しておき、必要な領域だけWindowに転送
するっていうのが欲しかっただけなんだけどね

Windowsってそのへん、明らかに設計ミスってるでしょ？

564 ：デフォルトの名無しさん：02/12/24 09:32

NWSOSのカーネルAPIってどのような手順で呼び出されるのでしょ？
ｘ８６のユーザーモードからカーネルモードへの変換タイミングってどこ？
みたいな感じで。MONAはどうなんだろ？ソースみるか･･･

565 ：LightCone ◆sSJBc30S5w ：02/12/24 09:34

>>563
>裏側に、大きな仮想画用紙を用意しておき、必要な領域だけWindowに転送
>するっていうのが欲しかっただけなんだけどね

今のところそういう設計にはなってませんが、検討してみます。

566 ：LightCone ◆sSJBc30S5w ：02/12/24 09:37

>>564
>NWSOSのカーネルAPIってどのような手順で呼び出されるのでしょ？
>ｘ８６のユーザーモードからカーネルモードへの変換タイミングってどこ？

現状で言えば、NWSOSのAPIは、int 22hをライブラリでラッピングしたもの
です。

int 22h で、ユーザーモード ---> カーネルモードへの切り替えを行って
います。

ただし、この仕様は変更される可能性があるので、必ずライブラリ関数を
呼び出してください。

567 ：デフォルトの名無しさん：02/12/24 09:44

>>563
>Windowsってそのへん、明らかに設計ミスってるでしょ？
メモリに確保したビットマップのDCを取得して描画・転送できます
そのへんもOSにまかせたいという話ならわかりますが
設計ミスとまではいえないのではないでしょうか？

568 ：デフォルトの名無しさん：02/12/24 09:55

>メモリに確保したビットマップのDCを取得して描画・転送できます
>そのへんもOSにまかせたいという話ならわかりますが
>設計ミスとまではいえないのではないでしょうか？
ん？いや、完璧な設計ミスだよ。
画面外の描画もOS内部で引き受けてれば、窓サイズが変化しただとか
他の窓が上にかぶさったときだとか、わざわざアプリにDrawメッセージを
送ることなくOS内部で処理できたんだからね。
スクロールバーで動かしたときも、わざわざアプリに問い合わせる必要も
なかったしね。

そのへん、X-Windowなんかはよく出来てるよ。

569 ：568：02/12/24 10:04

一度、窓でCADなどを設計すれば分かると思うけど、
Drawメッセージが来たからといってクライアントDCにがしがし描画すると
とても使い物にならない。
そこで、MSが薦めるように、アプリ側で巨大な互換DCを作成し、通常はそこに
描画し、Drawメッセージが来たときは、必要な矩形のみをクライアントDCに
BLTしてください･･･と。

けど、これって、OSメーカの設計ミスを
アプリ屋に尻拭いさせてるに過ぎないんだよね。

互換DCへの描画って、グラフィックアクセラレータの恩恵を受けないし、
重いし･･･

Xみたいに描画コマンドをOS内部のワークにキューイングされる仕組みだったら
必要なコマンドをクリップに応じてチョイスし、それをレンダリングするという
ことが可能だった。

OSメーカの設計ミスによる怠慢は、後々ひびく。

570 ：初心者：02/12/24 10:13

ひげぽんさん
私もOSを作ろうとかねてから考えていたものです。
僕CとPascalしか今のところできませんが、「はじめて読む486」を買
いがんばって追いつこうと思いますので、どうか協力させてくださいm(_ _)m
「はじめて読む486」早く買いたいのですが、なにぶん「8086マクロアセンブラ入門」という本を買ったばかりなので、お金がなくて買えません
がんばってください...

571 ：デフォルトの名無しさん：02/12/24 10:17

568-569の話を真に受けるとメモリ食いすぎになりそうでイイ！

572 ：LightCone ◆sSJBc30S5w ：02/12/24 10:17

>>569
ちょっと話の内容がずれますが、

>Xみたいに描画コマンドをOS内部のワークにキューイングされる仕組みだったら

描画コマンドをいったんバッファに入れておいて、バッファが一杯になった
り、gfFlush()(仮)を呼び出したときに描画する、と言う仕様はNWSOSでも
将来やりたいと思っています。

Windowsの話になりますが、

>互換DCへの描画って、グラフィックアクセラレータの恩恵を受けないし、

私もそんな感じがしたことがあります。

WindowsでCADをやるには、GDIを使わずに OpenGL を使った方がいいと思い
ます。DirectX と競争できる程度に速いようですので。

573 ：LightCone ◆sSJBc30S5w ：02/12/24 10:24

>>568
>画面外の描画もOS内部で引き受けてれば、窓サイズが変化しただとか
>他の窓が上にかぶさったときだとか、わざわざアプリにDrawメッセージを
>送ることなくOS内部で処理できたんだからね。

サイズ変更に関してはそれだけではすまないんじゃないでしょうか。

なぜなら、多くのアプリケーションでは、Window-Sizeが変更されたとき、
論理的な描画内容も変更するからです。

例えば、エディタでは、「折り返し」の文字数が変化します。

574 ：568：02/12/24 10:29

>Windowsの話になりますが、
>>互換DCへの描画って、グラフィックアクセラレータの恩恵を受けないし、
>私もそんな感じがしたことがあります。
同感してくれて、どうもありがとう。

>WindowsでCADをやるには、GDIを使わずに OpenGL を使った方がいいと思い
>ます。DirectX と競争できる程度に速いようですので。
んー、DirectXのことは全く知らないけど、OpenGLを使ったからといって
アプリ側が即解決できる問題でもないんだよね。
gl系の描画関数をOS側が全て保持し、OS側がクリップし、ハードレンダかけないと。
OSが気軽にアプリにDrawメッセージ送りつけられても、アプリ側がクリッピングするのって
大変だし、そもそもそんな共通処理をアプリに押し付けるってどうよ？みたいな。

例えば、2chみたいな縦にながーいHTMLをブラウザに表示するにしても、
どうする？CADだったら、ある程度巨大なDCを用意するだけで済んだけど、
2chみたいに長いと（もっと長い例あるけど）、描画コマンドを蓄えて、描画前に
クリップを見積もって・・・・って処理、アプリがせねばならない。IEもやってるように。

このあたりNWSOSがまともにサポートすれば、アドバンテージになるのでは？

575 ：568：02/12/24 10:33

＞568-569の話を真に受けるとメモリ食いすぎになりそうでイイ！
実際には描画単位はもっと細切れにできるんで、RECT配列を作り
クライアント領域との衝突判定をし、必要なぶんだけ描画するのが
望ましいのだけど、例えば、サイズの異なるフォントが混在する文書を
表示するとき、結局、最後まで描画するはめになるのよ。

このあたりは実務を積めば、そうそう、と納得してくれると思うがね。

576 ：ひげぽん：02/12/24 10:33

>>570
こんにちははじめまして。
もしご協力いたけるのであれば
http://mona.sourceforge.jp/
のプロジェクトメンバー募集をごらん頂いて
ひげぽん宛にご連絡ください。

>私もOSを作ろうとかねてから考えていたものです。
考えを実行に移しましょう！！

577 ：デフォルトの名無しさん：02/12/24 10:37

もしかしてScrollDCを知らないとか...

578 ：デフォルトの名無しさん：02/12/24 10:40

>>577
黙ってろ！

579 ：LightCone ◆sSJBc30S5w ：02/12/24 10:40

>>574
>gl系の描画関数をOS側が全て保持し、OS側がクリップし、ハードレンダかけないと。
>OSが気軽にアプリにDrawメッセージ送りつけられても、アプリ側がクリッピングするのって

OpenGL は、描画コマンドを「記憶」させておいて、「再生」できますよね。

580 ：568：02/12/24 10:44

>>もしかしてScrollDCを知らないとか...
スクロールされたあとは、結局、その領域に対して描画せねばならない。
あのAPIはなにも解決してくれない。
結局、アプリ側の描画指定群をOS側で保持してくれないかぎり
どうにも解決できない問題。（もしくはその解決はアプリの責任）

581 ：LightCone ◆sSJBc30S5w ：02/12/24 10:46

#568さん、IRCの、

#osdev-j

で、話しませんか。

ご存知かもしれませんが、IRCは、リアルタイムチャットのプロトコルで、
私は、LimeChat というアプリで利用してます。

582 ：568：02/12/24 10:47

＞OpenGL は、描画コマンドを「記憶」させておいて、「再生」できますよね。
っていうのをアプリに押し付けるのは止めて欲しいというお話。

583 ：LightCone ◆sSJBc30S5w ：02/12/24 10:49

>>582
オブジェクトの「カリング」自体も、OSにやってくれ、ということですか？

584 ：LightCone ◆sSJBc30S5w ：02/12/24 10:52

　Windowサイズ変更時などに、描画コマンドの記憶・再生するのをOSが勝手に
やって欲しいと言う事ですか？

585 ：568：02/12/24 10:52

＞オブジェクトの「カリング」自体も、OSにやってくれ、ということですか？
OpenGL対応のカードならハードウェアで図形ポリゴンのカリングをしてくれるので
OSでやらずしてどこでする？みたいなのり。

586 ：568：02/12/24 10:55

＞　Windowサイズ変更時などに、描画コマンドの記憶・再生するのをOSが勝手に
＞やって欲しいと言う事ですか？
そういうこと。サイズ変更時に発生するテキストの折り返しがやりたければ、
アプリ側が描画コマンドを再構築すればよいだけの話で、そうでなければ
OSが保持している描画コマンドに従ってレンダリングするのみ。

587 ：LightCone ◆sSJBc30S5w ：02/12/24 10:56

>>585
HTMLやワープロデータの描画などで時間がかかるのは、描画自体ではなく、
データの解析と計算にありますよね。

「カリング」で高速化できる一番大きな理由は、解析と計算を省けるから
ですよね。

588 ：LightCone ◆sSJBc30S5w ：02/12/24 10:58

>>586
なるほど。

そういう所までなら、OSで自動化できますね。

#587の様な意味での解析や計算行為の「カリング」はOSには無理ですが。

589 ：デフォルトの名無しさん：02/12/24 14:53

最初から完璧なOSなんか期待してないよ。
ボロくてもいいから出せばいい
それをみんなで良くしていけばいいじゃないか

590 ：デフォルトの名無しさん：02/12/24 15:50

Lたん　＝　にしだ　わた○　　　と...。

591 ：589：02/12/24 16:13

あ、当然俺はこんなの手伝わないけど（ｗ

592 ：デフォルトの名無しさん：02/12/24 17:18

>>589
実はそうはいかなかったり。
設計の段階でボロくやってしまうと後で重大な欠陥が見つかって
その修正に物凄い時間がかかる。
まあﾏﾀｰﾘしませう

593 ：デフォルトの名無しさん：02/12/24 17:20

Linuxなんて酷かったから、修正するのにあんなにかかったもんな。
もっとマトモに設計していればそうでもなかったと思うけど、
マトモに設計してたら誰も寄り付かなかっただろうな。

594 ：初心者：02/12/24 17:26

MonaOSの開発に参加させてもらったのは
みんなのレベルに追いつけるかなぁ～（汗
とりえあえず「はじめて読む486」買いに行こうと思ったら
どこにもない（泣
仕方がないから注文しました...

今年中には無理そうなので、それまでにみんながどんどん進んでいって
置いてきぼりにされそう...

とりあえず全身全霊を込めてがんばります

「8086マクロアセンブラ入門」今手元にこの本があるのですが
この本はどうなんでしょう？何方かお持ちでないでしょうか？
個人的にはこの本すごくわかりにくいような気がするのですが...

595 ：ひげぽん：02/12/24 18:12

>>594　初心者さん

>とりえあえず「はじめて読む486」買いに行こうと思ったら
>どこにもない（泣
>仕方がないから注文しました...

確かになかなか町の本屋さんでは見かけませんねぇ。
この本が一番元を取っているかもしれません。

>今年中には無理そうなので、それまでにみんながどんどん進んでいって
>置いてきぼりにされそう...

いえいえそんなあせることないですよ。
年明けまでにそんなには進まないと思います。

>とりあえず全身全霊を込めてがんばります
一緒にがんばりましょう。

>「8086マクロアセンブラ入門」今手元にこの本があるのですが
>この本はどうなんでしょう？何方かお持ちでないでしょうか？
>個人的にはこの本すごくわかりにくいような気がするのですが...

読んだことなですねぇ。
アセンブラ勉強しなきゃ・・・

596 ：初心者：02/12/24 18:32

とりあえず
キーの入力をストロークするプログラムを作ったｗ（一文字だけだけど）
動いたときすごい感動しました！！

597 ：みとこ ◆AEqcy/sQU6 ：02/12/24 19:18

第二のひげぽんｷﾀｰ？

598 ：ひげぽん：02/12/24 19:39

C++で変な現象が起きていて困っています。

キーボード入力を受け付けるKeyBoardManagerクラスは
シングルトンパターン(インスタンスの唯一性を保証する)で
実装されています。

具体的には、インスタンスを必要とするときは
KeyBoardManager& km = KeyBoardManager::instance();
とinstance()メソッドを介します。

instance()メソッドはこんな感じです。
static KeyBoardManager& instance() {
static KeyBoardManager theInstance;
return theInstance;
}

599 ：ひげぽん：02/12/24 19:39

OSを起動してはじめてinstance()メソッドを
呼ぶとint atexit( void (*func)(void))が呼ばれて
いるようなのです。そのとき引数としてfuncには
~KeyBoardManager()が渡っています。
これって通常の動作なのでしょうか。
何かエラーが起きているのでしょうか。

※ちなみにX86MemoryManagerも同様の実装ですが
このような現象は起きていません。
また以前はこの現象は起きていませんでした。

デバッグしてみると
    static KeyBoardManager theInstance;
のところでatexit()が呼ばれてるようです。

instace() {
  引数なしコンストラクタKeyBoardManager()が終了直後に
  atexit(~KeyBoardMangerへのポインタ)が呼ばれる
}

どなたかアドバイスいただけないでしょうか。

600 ：超先生＠OS板 ◆leaf/RYZgY ：02/12/24 21:12

　 ∧＿∧
＜後ろ頭＞-~~~ それは当然の動作のような。
staticなオブジェクトならプログラム終了時にデストラクタがよばれるよう、
atexitで予めデストラクタ関数が呼ばれるように登録しておく。

逆言えば、atexitを呼ばないX86MemoryManagerが怪しい。
#デストラクタが空っぽなら自動的に省略されるという可能性あり。

601 ：ひげぽん：02/12/24 21:49

超先生ありがとうございます。

>　 ∧＿∧
>＜後ろ頭＞-~~~ それは当然の動作のような

そうなんですね。失礼いたしました。
ということは、OS終了時に後片付けをする場合はatexitを活用するのですね。

ちょっとWEBで調べたところ、通常atexitは登録された関数を
登録と逆順で呼んでくれるそうです。

ただし、Mona内のお話の場合、atexitを実装する責任があるのは
ひげぽんにあるんですかね。

きちんと実装してもメリットがあるかどうかが非常に疑問ですが。

602 ：ひげぽん：02/12/24 22:11

C++もいいかげんきちんと勉強しなきゃいけないですね。
OSを作り始めたころにはじめたも同然なので・・・
アセンブラよりは得意かもしれませんが、精進いたします。

603 ：デフォルトの名無しさん：02/12/24 22:19

BIOS関連の質問ですが、

プロテクトモード以降前に

mov al, 0xD1; classical AT type
out 0x64, al; write output(0xD1), keyboad control port(0x64)
mov al, 0xDF; enable A20 line(0xDF)
out 0x60, al; keyboard read/write port(0x60)

in al, 0x92; PS/2 type
or al, 0x02
out 0x92, al

でA20を有効化しているのですが、そのせいあってか、IDT初期化後sti
するとかならず、キー割込みが入ってしまいます。
A20有効化の後に、in al, 0x60　でフラッシュしても、割り込まれます。

また、int 0x13で読み込んだ後にFDモータをとめるには
どうすればいいんでしょうか？

604 ：デフォルトの名無しさん：02/12/24 22:45

>>604
PICで、割り込みマスクしとけばいいんでは？
モータはFDCにコマンドを送って止めるんではなかったかと。
手元に資料が無いので、詳しい事は自力であたってくれ。

605 ：604：02/12/24 22:45

s/604/603/
すまそ。

606 ：みとこ ◆AEqcy/sQU6 ：02/12/25 14:53

自分で割り込み許可しといて「割り込みが来ます。なんとかしる！」というのはどうかと。

607 ：超先生＠OS板 ◆leaf/RYZgY ：02/12/25 14:56

　 ∧＿∧
＜後ろ頭＞-~~~ KBCのfifoバッファをクリアしないとダメやね。

608 ：ひげぽん：02/12/25 15:12

最近A20関連でそんな事をやったようなやらないような。

609 ：デフォルトの名無しさん：02/12/26 02:06

MonaのDoxygenドキュメントはどこ？

610 ：デフォルトの名無しさん：02/12/26 06:14

質問だけど、超先生がいつも住んでいるOSはなんですか？

611 ：デフォルトの名無しさん：02/12/26 07:34

青村OSかと…

612 ：ひげぽん：02/12/26 13:10

>>609
すいません、現在はWebでは公開していません。
もうまもなくMPDNで公開する予定です。
しばらくお待ちください。

ソースをダウンロードして、Makeすれば
一応ドキュメントが生成されます。(doxygen必須ですが・・・)

613 ：デフォルトの名無しさん：02/12/26 22:50

age

614 ：みとこ ◆AEqcy/sQU6 ：02/12/27 13:55

＞ひげぽんたん

VirtualPCでは一応起動したけど、タスク切り替えだめぽ。。。
http://meg-os.org/2ch/mona.jpg

615 ：ひげぽん：02/12/27 14:05

みとこさん
>VirtualPCでは一応起動したけど、タスク切り替えだめぽ。。。
ご確認ありがとうございます。
タスク切り替えの所で止まってしまうのでしょうか。
もう一つの顔が表示されてない・・・

動作確認できているのは、bochs1.41,bochs2.0,我が家の実機2台

タスク切り替えで何か間違いをやらかしてそうですね。
LDTあたりで。

616 ：ひげぽん：02/12/27 14:13

みとこさん
VirtualPC持っているんですね。
うらやますぃ。
vmware,virtual PC高いですよ。
OS開発者ライセンスないかな。。
mona.sourceforge.jpにバナー貼るから（笑）

617 ：大空寺あゆ：02/12/27 15:18

　　　　＿ _
　l|ﾞi 《l| 　ヽl|　　　　　　　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　ﾉノﾉノﾉ）) 〉　　　　 |　Un_death_too(); /* 挨拶 */
　(（ (ﾘﾟヮﾟﾉlヽ　　　　＜.　TSSにLDTは必須ではないわさ。 >>615
　 ))⊂)l水!つ）　　　　　　|　iret()マクロのiret命令はiretdだと思うんだわさ!
　（　/ 人〉　(　　　　　　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　し'ﾉ

618 ：みとこ ◆AEqcy/sQU6 ：02/12/27 15:23

そもそもタスク切り替えしてないんじゃないかと

619 ：涼宮茜：02/12/27 15:35

　　　　＿,.'⌒)
　　　, ´f二ｺヽ
　　 ! l !ﾉﾘ i l　「そもそも割り込みゲートを使っておきながら
　　ノiﾊl.ﾟｰﾟﾉﾘ　TSSのbacklinkでタスク実行するは設計上のバグですね。
　　　 ⊂)允つ　割り込みハンドラ自体をTSSにしないと」

620 ：みとこ ◆AEqcy/sQU6 ：02/12/27 15:36

TSSってIDTにおけたっけ？
IDTはゲートしか置けない気が

621 ：ひげぽん：02/12/27 16:40

大空寺あゆさん
こんにちは
>TSSにLDTは必須ではないわさ
そのはずなのですが、bochs君がLDTを要求するようなので
ダミーのLDTを作成した次第であります。
こいつが悪さをしたのかなあ？

>iret()マクロのiret命令はiretdだと思うんだわさ
iretではまずいのでしょうか。iretdでmakeしたらasに怒られました。

622 ：涼宮茜 ◆Age/NEMxEc ：02/12/27 16:44

　　　　＿,.'⌒)　>>620
　　　, ´f二ｺヽ　「もちろんIDTにはタスクゲートを置きますよ。
　　 ! l !ﾉﾘ i l　現在の実装だと、一方のタスクが再び実行された時、
　　ノiﾊl.ﾟｰﾟﾉﾘ　ハンドラ内から走り始めてしまいます。
　　　 ⊂)允つ　それだと多重割り込みを受け付ける場合に不味いです」

623 ：ひげぽん：02/12/27 16:49

>>618 みとこさん
>そもそもタスク切り替えしてないんじゃないかと
eflagsレジスタのNTフラグを立てる
切り替え先のTSSの属性をBUSYにする。
backlinkの設定
iret

とタスク切り替えをしているつもりなのですが
間違っているでしょうか。

>涼宮茜さん

>割り込みハンドラ自体をTSSにしないと

最初の動機として、タイマ割り込みでタスクスイッチしたいというのが
ありました。
今採用している方法しか分からないというのが現状です(ToT)
上記の方法をもう少し詳しく教えていただけないでしょうか。m(__)m

624 ：デフォルトの名無しさん：02/12/27 16:57

gasでは
iret(32bit) iretw(16bit) iretl(32bit)

masmでは
iret(16bit) iretd(32bit)

625 ：涼宮茜 ◆Age/NEMxEc ：02/12/27 17:13

　　　　＿,.'⌒)
　　　, ´f二ｺヽ
　　 ! l !ﾉﾘ i l　「そういえば、割り込みハンドラ内でpusha/popaをしていないようですが、
　　ノiﾊl.ﾟｰﾟﾉﾘ　これでは汎用レジスタが破壊されてしまうと思います」
　　　 ⊂)允つ　

void *****_handler()
{
　pusha();

　popa();
　iret();
}

626 ：デフォルトの名無しさん：02/12/27 19:24

>625
割込みではCPUが
push eflags
push cs
push eip

するみたいですが
汎用レジスタは保障されないのかぁ

627 ：ひげぽん：02/12/27 23:29

涼宮茜さん

>pusha/popaをしていないようですが、
>これでは汎用レジスタが破壊されてしまうと思います

アドバイスありがとうございます。
早速取り入れさせていただきます。

628 ：デフォルトの名無しさん：02/12/28 03:55

＞するみたいですが
＞汎用レジスタは保障されないのかぁ
保障されないよ。ハンドラがaxレジスタしか使わない場合などは push ax -> pop ax
で済んでしまうケースもあるってことで、大抵のCPUは汎用レジスタはセーブしない。
$sp相当のCPUすらセーブしないこともしばしば。

629 ：デフォルトの名無しさん：02/12/28 16:05

馬鹿な質問ですが、おゆるしを。。。

TSSを設定するときで、tss->eipに関数のアドレスを入れたいのですが、
(void *)funcとして、入れるとその場でfunc関数が実行してしますいます。
（当たり前のことですが。。。）
そもそもfunc関数の開始アドレスってどうすれば分かるのでしょうか？

630 ：デフォルトの名無しさん：02/12/28 16:58

>>610 >>611

RROSじゃないの?

631 ：デフォルトの名無しさん：02/12/28 23:44

set_tss(tss_t* tss, void (*fn)(void), void* esp);

set_tss(tss, (void*)func, stack);

× (void*)func()
○ (void*)func

632 ：デフォルトの名無しさん：02/12/29 01:49

基本的においらはオープン派が好き。
だから、NWSOSっていうかMONAびいき。

633 ：デフォルトの名無しさん：02/12/29 16:39

いや、L氏に加担するわけじゃないけど、
ソースを公開してしまうと、役に立つかもしれないが、
逆に「そんなものか」と思ってしまい、つまらなくなる。
手品だって種明かしちゃつまらんだろ。

634 ：633：02/12/29 16:41

でも、オープンのいいところは、
バグ報告があるってことで、ものの質的にはよくなるけどね。

635 ：633：02/12/29 23:59

linuxのソースのかなりの部分を占める（？
関数自体を定義するんではなくて、

#define switch_to(prev,next,last) do {\
asm volatile("pushl %%esi\n\t"\
"pushl %%edi\n\t"\
"pushl %%ebp\n\t"\
.......................

についてどう思う？
折れ的には、かなりイケテルように見えるんだが・・・。
普通化か？

636 ：デフォルトの名無しさん：02/12/29 23:59

ｼｸｼﾞｯﾀ...

637 ：デフォルトの名無しさん：02/12/30 00:00

shikujitta...

638 ：超先生＠OS板 ◆leaf/RYZgY ：02/12/30 00:32

>>635
　∧＿∧
＜｀ー´＞-~~~ あまりにも普通という罠。

639 ：LightCone ◆sSJBc30S5w ：02/12/30 00:37

>>635
全くの偶然ですが、NWSOSでも、タスクスイッチはマクロでやってます。
ただし、NWSOSの場合は、NWSSのMACRO,ENDM文でやってますが。

640 ：デフォルトの名無しさん：02/12/30 03:48

年明け早々、両者の出方が気になる。
ひげぽんも正月休利用してガンガン開発を進めるみたいだし、
NWSOSもバージョンアップが予想されるし。

NWSOSはスクリーンショットを見る限り、そろそろファイルエクスプローラ
くらいなら出てきそうな感じだな。

641 ：LightCone ◆sSJBc30S5w ：02/12/30 12:10

>>640
>NWSOSはスクリーンショットを見る限り、そろそろファイルエクスプローラ
>くらいなら出てきそうな感じだな。

ファイルマネージャは、時期としては後になります。
それは設計上の理由からです。

642 ：ひげぽん：02/12/30 12:34

>>640
>ひげぽんも正月休利用してガンガン開発を進めるみたいだし
勉強ばかりで思うように進んでません。。。
しかも風邪ひいてるし
さて徹夜するか・・・(ё_ё)

643 ：デフォルトの名無しさん：02/12/30 19:19

まぁ、ここは相対的には過疎板なんだけど
ＭＯＮＡ－ＯＳって完成度さえ高めればそれなりに普及しそうな予感。
やっぱＦＤブート中におなじみのＡＡが出せるのは、ユーザーの引き込みって
点でキャッチーだと思う。ＰＣ－ＷＥＥＫだとかＡＳＣＩＩ－ＮＥＷＳなんかで
ちょっと取り上げられれば、その存在は一躍ヒーローになる予感

もちろん、ＯＳとしての基本的な機能、性能は備えた上で

644 ：ひげぽん：02/12/30 19:57

>点でキャッチーだと思う。ＰＣ－ＷＥＥＫだとかＡＳＣＩＩ－ＮＥＷＳなんかで
>ちょっと取り上げられれば、その存在は一躍ヒーローになる予感

そんなことはないと思います。
キャッチーといえばMEG-OSですよ。
まいりますた。
MEG-OS
http://meg-os.org/

>もちろん、ＯＳとしての基本的な機能、性能は備えた上で

がんばります。m(__)m

645 ：デフォルトの名無しさん：02/12/30 23:30

ドライバ書かせてくれ。

646 ：ひげぽん：02/12/30 23:40

>>645
ひげぽん宛のメッセージと勝手に解釈してお返事します。

>ドライバ書かせてくれ。
是非書いて頂きたいので、もしご協力いただける場合は
http://mona.sourceforge.jp/をごらん頂き、ひげぽんまで
ご連絡ください。m(__)m

647 ：デフォルトの名無しさん：02/12/31 01:37

>ＭＯＮＡ－ＯＳって完成度さえ高めればそれなりに普及しそうな予感。
「OSの完成度を高める事」って結構難しいと思う。
ある意味、ずっと完成度高めることができるなら、LinuxやWindowsまで
行くことになってしまうけど、そこまでいけるのは極稀。
それができる人材も稀有。

648 ：デフォルトの名無しさん：02/12/31 02:08

>ある意味、ずっと完成度高めることができるなら、LinuxやWindowsまで
>行くことになってしまうけど、そこまでいけるのは極稀。
けど、現実的にNWSOS、MONA、MEG-OSなど、32BitOSが続々と
リリースされてきてるのも現実。特にNWSOSは、VC++が使えるし、
APIエミュ次第では、GUIも含めたWindowsクローンの可能性もある。

一番の大敵は、「どうせWinには追い越せない」などといった弱音だと思われ。

649 ：デフォルトの名無しさん：02/12/31 05:33

MEG-OSも確かにある意味キャッチーだな。
個人的にはひーちゃうけど、「萌え」なフィーリングはなんとなく分かる。

650 ：デフォルトの名無しさん：02/12/31 09:57

>>648
>けど、現実的にNWSOS、MONA、MEG-OSなど、32BitOSが続々と
>リリースされてきてるのも現実。特にNWSOSは、VC++が使えるし、
>APIエミュ次第では、GUIも含めたWindowsクローンの可能性もある。

NWSOSの作者の腕のよさ、才能は考慮されてますか？

NWSOSの出来が良いからと言って、他の新規参入OSがそこまで至る
と短絡的に考えるのはおかしい。

誰かが上手く作ったからと言って、別の誰かもうまく行くと考えるのは
悪い平等主義です。上手く行くのは、限られているんです。

651 ：デフォルトの名無しさん：02/12/31 10:05

>>648
>一番の大敵は、「どうせWinには追い越せない」などといった弱音だと思われ。
それは、NWSOSの作者が、「マイナス思考」である事を意味してる。
マイナス思考は弱音ではない。
マイナス思考であるからこそ、NWSOSの今の姿がある。
最近の日本人は、馬鹿でも間抜けでもプラス思考になってしまって、自分の
力を過信する弊害が出てきている。
マイナス思考のメリットもあることをお忘れなく。

652 ：651：02/12/31 10:07

あるいは、謙遜であるかもしれない。

653 ：デフォルトの名無しさん：02/12/31 12:09

＞NWSOSの出来が良いからと言って、他の新規参入OSがそこまで至る
＞と短絡的に考えるのはおかしい。
けど、MONAの進化速度だとかも考慮に入れると、
OS開発の才能を持ってるのがＬだけだと決め付けるのも短絡的だろ？

654 ：デフォルトの名無しさん：02/12/31 12:15

>>653
>けど、MONAの進化速度だとかも考慮に入れると、
習い事を考えてみ。
入門から標準レベルに行くのは誰でも早い。
そっから後に行けるかどうかが分かれる。
あと、NWSOSの作者の「進化速度」と比較して無いじゃん。
もっと早いよキット。

655 ：デフォルトの名無しさん：02/12/31 12:21

>>653
Monaの状態を1とすると、NWSOSは、1000位のところに有るんだよ。
悪いけど、ひげぽんの最初のレベルがあまりにも低すぎたため、
成長速度が速いかのように思えるだけ。
でも、NWSOSとは全然違うよ。

656 ：デフォルトの名無しさん：02/12/31 12:58

OSASKのK氏は、TOWNS用のPC-9801VXエミュレータを作った経験をもつ。
ttp://www.imasy.or.jp/~kawai/download.html
で、ソースもダウンロードしてみると、そこそこの腕が有ることが
分かると思うが、NWSOS >>>>>> OSASK である現状が何を意味するかを
よく考えねばならない。
果たして、Mona陣営は、V98レベルのものを作れるだろうか、ム板のみんな
もよく検討あれ。

657 ：デフォルトの名無しさん：02/12/31 13:05

NWSOSとMONAの決定的な違いは、OSそのものにも当然あるが、
作者のソフトウェアにおいての基礎体力じゃないかと思う。
（ここでの基礎体力はハード知識、機械語、リンカ、ローダなど。）
L氏は自分で言語処理系を作成できるほどの凄まじい基礎体力を
持っている。だから、そこそこなOSも作成できる。
別に基礎体力をつけてからでないとOSを作成できないわけじゃないけど。
たびたび詰まることになる。L氏が初登場時に言ったように、ひげぽんは
OSを作りながらも、もっと基礎体力をつけるべき。そうすれば、
L氏を1000として、ひげポンは5,600位には到達できると思う。
まあ、少なくとも、２年くらいはかかるけどね。

658 ：デフォルトの名無しさん：02/12/31 13:07

>L氏を1000として、ひげポンは5,600位には到達できると思う。
出来ないに一票。

659 ：デフォルトの名無しさん：02/12/31 13:09

あのなあ、ひげぽんの年齢で基礎知識を学び始めるのはもう手遅れなんだよ。
20も超えれば、できる奴は頭角を表すんだよ。

660 ：デフォルトの名無しさん：02/12/31 13:09

いいすぎたか。。。
３００くらいでどうか。。

661 ：デフォルトの名無しさん：02/12/31 13:14

余り関係ないかもしれないかもだけど。
情報系大学の教授たちがよく言うことだけど、
集積回路や電磁波などの、ハード的なことは後々勉強ということでは
間に合わない（手遅れ）が、、ソフトウェアは文系でも十分間に合う」

ってのはｳｿだったんですか。。。
実際問題、自分も「ほんとに間に合うのか。。」
と思ってはいたのですが。。

662 ：デフォルトの名無しさん：02/12/31 13:14

ひげぽんは、確かに最初のスタートレベルが低かった（OSの分野では）
そのため成長速度が速く見えたのは事実だな。

逆に言えばほとんどゼロからOSの知識を蓄えたという事実と
OSの知識不足を補う、何かがあったからここまで来たのでは？

ひげぽんは仕事をしながらここまで来たという
事実も忘れてはならないと思う。

500位まではあと、半年もすれば行くだろう。

663 ：デフォルトの名無しさん：02/12/31 13:15

>NWSOSとMONAの決定的な違いは、OSそのものにも当然あるが、
>作者のソフトウェアにおいての基礎体力じゃないかと思う。
>（ここでの基礎体力はハード知識、機械語、リンカ、ローダなど。）
>L氏は自分で言語処理系を作成できるほどの凄まじい基礎体力を
>持っている。だから、そこそこなOSも作成できる。
Ｌ氏の専門は、ソフトじゃないのはご存知？
予備知識であれだけの体力があると言う驚愕の事実。

664 ：デフォルトの名無しさん：02/12/31 13:19

>>661
>集積回路や電磁波などの、ハード的なことは後々勉強ということでは
>間に合わない（手遅れ）が、、ソフトウェアは文系でも十分間に合う」
>ってのはｳｿだったんですか。。。
ソフトは表面的に組めるようのは簡単。
でも難しい処理を組んだり、効率の良いロジックを考え出したりするのは、
素質もある。

665 ：デフォルトの名無しさん：02/12/31 13:20

＞６６３

L氏の専門って何？
聞いたところによると、ゲーム業界？

666 ：デフォルトの名無しさん：02/12/31 13:21

>>665
電磁気学とからしい。

667 ：デフォルトの名無しさん：02/12/31 13:23

>>662
>500位まではあと、半年もすれば行くだろう。
行かないな。

668 ：デフォルトの名無しさん：02/12/31 13:25

知識だけの差と考えるのも納得できないな。
プログラムの腕の差って、単純な知識の差だと思うか？

669 ：デフォルトの名無しさん：02/12/31 13:27

しかし。。俺らって無駄にスレ浪費してるな。。

670 ：デフォルトの名無しさん：02/12/31 13:29

「プログラムには作者の魂、情熱が埋め込まれている」

671 ：超先生＠OS板 ◆leaf/RYZgY ：02/12/31 13:33

　∧＿∧
＜｀ー´＞-~~~ ひげぽんて何歳だっけか。
シナリオライターでもプログラムは書ける。

672 ：デフォルトの名無しさん：02/12/31 13:35

冷静な意見を１つ。
http://pc.2ch.net/test/read.cgi/os/1031404041/l50
同じ時間帯にOSASK板でOSASK批判めいた書き込み多数。

かたやこちらではMONA批判めいた書き込み多数。

一方、NWSOS板はまったく静か。
年末の昼間ということを考えれば、これは偶然ではなく。
Lﾀﾝまたは、その陣営が書き込んでいるのではと思われてもしょうがない(ｗ

673 ：デフォルトの名無しさん：02/12/31 13:37

>>671
>シナリオライターでもプログラムは書ける。
「簡単な部分」に絞ればそうです。

674 ：デフォルトの名無しさん：02/12/31 13:40

確か24歳くらいとスレのどこかに書いてあった。
dat落ちしたからわからんが。
L氏、K氏は20代後半の後半。

675 ：デフォルトの名無しさん：02/12/31 13:42

>>672
(ｗ
Lﾀﾝ　ﾊｱﾊｱ

676 ：デフォルトの名無しさん：02/12/31 13:43

ちょっとまて。
L氏がすごいと言うが、井の中の蛙って落ちってことない？
世界は広い

677 ：デフォルトの名無しさん：02/12/31 13:47

>>674
え？そうなの。
基礎体力の差は年齢差という落ちか。
Lﾀﾝﾊｱﾊｱ

678 ：デフォルトの名無しさん：02/12/31 13:50

まあ、L氏がすごいというのは認めるしかない。
相撲で言えば、前頭筆頭ぐらいかな（爆

679 ：LightCone ◆sSJBc30S5w ：02/12/31 13:59

　誰が書いてるのか知りませんが、「予想」してもしょうがないと思いますよ。
待てば分かる事です。結果でしかわからないと思うなあ。

680 ：デフォルトの名無しさん：02/12/31 14:06

L氏の自己評価
Kﾀﾝ、Hﾀﾝの評価を聞いてみたい。
主観でいいよ。

681 ：LightCone ◆sSJBc30S5w ：02/12/31 14:07

>>671
>シナリオライターでもプログラムは書ける。
うーん。
実際には、プログラマの腕の差はあると思いますね。
企業内でも、書き手が交代した際に、
「急にやる気がでて、スイッチがオンになりましたね」
といわれた経験もありますしね。

米国の調査でも、開発効率に数千倍の差がある結果が出たと聞いてます。

682 ：LightCone ◆sSJBc30S5w ：02/12/31 14:08

>>680
ネットでは書けないです、すみません。

683 ：デフォルトの名無しさん：02/12/31 14:11

>>682
なぜ？
書いてしまってよいと思うが。
ぼろくそに書いても褒めてもいい。
それはL氏の意見であって、事実とは異なる場合もあるのだから。

684 ：LightCone ◆sSJBc30S5w ：02/12/31 14:19

>>683
トラブル起こすような事を勧めないで下さい。お願いします。（￣へ￣;

685 ：LightCone ◆sSJBc30S5w ：02/12/31 14:25

スレ汚しですみませんが、一般に知識と暗記は違う意味で使われているの
ですか？
自分の中では、知識＝暗記とほぼ同義だと思ってしまっているんですが。
プログラミングには、暗記は、要らないですよね。

686 ：デフォルトの名無しさん：02/12/31 14:36

ところでニックLIGHTCONEの由来はなんですか？

苦し紛れに解釈すると、
まず、[light=軽い-->ケイ-->啓]
そんで、[Cone=円錐----------------->介（とんがりっぽい（汗））]

ずばり、Lﾀﾝの本名は「啓介」(-_-)y--~~~ﾄﾞｳﾀﾞ

687 ：LightCone ◆sSJBc30S5w ：02/12/31 14:41

　特殊相対性理論の初歩の初歩で一番最初に出てくる４次元ミンコフスキー空間
の中の、時間軸を中心線と、中心線と母船との角度が45度の円錐の事です。
　現在の時空を原点にすると、現在の時空から出た光は常にこの円錐上を通過
することから、「光の通る円錐」と言う意味で、light-cone と名付け
られています。そこから取りました。

688 ：LightCone ◆sSJBc30S5w ：02/12/31 14:43

訂正：ｽﾏｿ
時間軸を中心線とする、中心線と母線との角度が45度の円錐の事です。

689 ：デフォルトの名無しさん：02/12/31 14:51

わざわざ、詳しい説明どうもです。
やっぱ、ニックのつけ方といい、Lﾀﾝすげーわ。

690 ：デフォルトの名無しさん：02/12/31 15:08

このスレはOS開発者を比べっこするのが目的じゃないでしょ。

サンデープログラマっぽい趣味のプログラマがOSなんてスゴソー
なものを作る過程をﾏﾀｰﾘと見守って、一緒に一喜一憂するスレ
だと思うんだが。

691 ：　：02/12/31 20:41

>>690
(・∀・)ｲｲ!!事言った！

692 ：デフォルトの名無しさん：02/12/31 23:43

ひげぽんたん。
来年もがんばってください。

C/C++ライブラリはSourceForgeにC99対応とかってのが
あった気がしますぞ。

693 ：ひげぽん：02/12/31 23:58

ありがとうござます。
くじけない限りがんばります。

C99調べてみます。m(__)m

694 ：デフォルトの名無しさん：03/01/01 01:31

あけおめ。
ひげぽんがんがれ。

695 ：デフォルトの名無しさん：03/01/01 01:34

>>687
(´Д⊂ヽ
何言ってるかわかんないよ～

696 ：デフォルトの名無しさん：03/01/01 01:49

>>695
ブルーバックスでも見るとよろし

697 ：デフォルトの名無しさん：03/01/01 02:16

>>695
ランダウ・リフシッツの訳本でも（略

ほげぽんあけましておめでとう。
今年もがんがってくだちい。

698 ：デフォルトの名無しさん：03/01/01 02:54

め、めぐが！！
http://meg-os.org/

699 ：デフォルトの名無しさん：03/01/01 11:28

まじで開発終了かよ！

700 ：デフォルトの名無しさん：03/01/01 17:05

>699
ネタだろ？
いかにも彼が好きそうな下らんネタだな

701 ：デフォルトの名無しさん：03/01/01 18:47

ちょうど動作報告しようと思ってたトコなのになー。

702 ：デフォルトの名無しさん：03/01/01 18:50

ということでMEG-OS Liteの開発は終了しました。みとこは名無しに戻ります。
裏でヒソーリ開発させてください。←ここ見た？
MEG-OS.ORG is now for sale.

703 ：デフォルトの名無しさん：03/01/01 19:43

>>702
みんな見たんじゃない？
古典的なやり方だし。

704 ：デフォルトの名無しさん：03/01/01 19:56

いや～、上手に騙されたｗ

でも、色々考えた。
やっぱり、プロジェクトとして公開してると
プレッシャーがかかってくる。
ｺｿｰﾘ開発が一番なのだと･･･｡

705 ：デフォルトの名無しさん：03/01/01 21:03

ほげぽん。
プレッシャーに負けるな。

706 ：デフォルトの名無しさん：03/01/02 03:24

↑「ほげぽん」ﾜﾗﾀ

707 ：デフォルトの名無しさん：03/01/02 09:17

けど、MEG-OSも開発を本格化するってことで、
いよいよ２００３は国産OSが火花を争う三国志元年となるわけですな。
（#ま、現状、NWSOSがぶっちぎりなのは置いといて）

'60、OS開発ってのは終わりがないものだと学者が言ってた。
実際、40年たったいま、やっぱ終わってない。

708 ：デフォルトの名無しさん：03/01/02 09:47

>三国志元年
3つのOSはなに？
MEG、NWSOS、???

709 ：デフォルトの名無しさん：03/01/02 10:22

??? = MONA だろ、きっと。
gccで開発できて、sourceforgeでcvs公開されてるんで
開発者はがんがん増えると思われ。

おいらも来年は仕事が少なくなるんで、ﾓﾅに参加する予定。

魅力は発展途上。

710 ：デフォルトの名無しさん：03/01/02 11:43

eota,osaskはどうして忘れられてるんだ?

ttp://www.st.rim.or.jp/~osada/translation/developers/BNL_articles/Issue79-insights-j.html
陰ながら応援しております。

711 ：名無したん ◆AEqcy/sQU6 ：03/01/02 13:32

CGIタイムボム仕掛けて正月休みに入ってる間になんかいろいろ言われてるみたいだけどFDC,RTCのデバドラの骨組みは完成したっす。
基本的なデバドラはだいたい揃ったんでそろそろいい加減カーネルに手入れます。ヽ(｀ー´)ノ
ちなみにこっからFTPはつなげないんでサイトは放置(;´ω｀)

712 ：デフォルトの名無しさん：03/01/02 14:20

っていうかＬはなんでもっと20年近くはやく生まれなかった？
Windowsって'81に開発がスタート。最初に発売したのが'85
窓の重ねができるようになったのが、'87

まぁなんだかんだ、NWSOSってWindows年表でいうと、'90前後だと思われ。

Win3.0が'90だしな。

713 ：デフォルトの名無しさん：03/01/02 14:23

>>712
L氏は確かに凄いがWindows3相当の物を作れるかは疑問
あっちは莫大な予算と大勢のプログラマでやってるんだからね。
それにL氏自身Winの代わりを作ろうとは思ってなさそうだ

714 ：デフォルトの名無しさん：03/01/02 15:15

＞あっちは莫大な予算と大勢のプログラマでやってるんだからね。
まー俺もそう思ってたが、じゃ、Windows3.0にはあって現状のNWSOSに
ないものって何がある？と考えたとき、意外とないよ。
具体的に列挙してみ？数えるほどしかない。

715 ：デフォルトの名無しさん：03/01/02 15:54

Office?

716 ：名無したん ◆AEqcy/sQU6 ：03/01/02 18:32

なんかFDCアクセス数回すると急に応答しなくなってタイムアウトばかり出るんですがどうすればいいんでしょうか？

717 ：デフォルトの名無しさん：03/01/02 18:46

＞Office?
結局、アプリだけがない状況

718 ：デフォルトの名無しさん：03/01/02 18:49

>>717
GDI(プリンタ含む)みたいな仕組みはあるの？
あとOLEもないとOfficeは厳しいな。

719 ：LightCone ◆sSJBc30S5w ：03/01/02 22:23

>>718
>GDI(プリンタ含む)みたいな仕組みはあるの？
まだないです。
NWSOSは、本当に運用しようと、まだまだ不足している部分が多いの
が現状ですが、今後徐々に補充していきたいと思っています。

720 ：LightCone ◆sSJBc30S5w ：03/01/02 22:24

誤字修正:
「本当に運用しようと、」--->「本当に運用しようとすると、」
ｽﾏｿ

721 ：デフォルトの名無しさん：03/01/02 23:20

ある程度使えるようにと、機能の追加に勤しむより、斬新的なカーネル開発に
力を入れたほうがいいと思う。WINDOWSのような万能OSが蔓延している中、
カーネル部分で勝負したほうが、まだ利用価値はあると。。
万能的なものを全てサポートしようとすると中途半端に
なってしまう可能性大だかも。

722 ：デフォルトの名無しさん：03/01/02 23:31

BeOSという前例があるからねぇ～

723 ：デフォルトの名無しさん：03/01/03 08:17

NWSOSでOffice製品群を揃えるビジョンとかはないの？>>Lﾀﾝ

724 ：LightCone ◆sSJBc30S5w ：03/01/03 08:23

>>723
>NWSOSでOffice製品群を揃えるビジョンとかはないの？>>Lﾀﾝ
最近、ワードやエクセルとデータが交換できるようなオープンソースの
Officeもありますので、移植する手も考えています。

725 ：デフォルトの名無しさん：03/01/03 10:08

>最近、ワードやエクセルとデータが交換できるようなオープンソースの
>Officeもありますので、移植する手も考えています。
いや、あれはお勧めしない。多分、OpenOfficeのことでしょ？
使ってみれば分かるけど、MS-Officeに比較してとんでもない起動時間が
かかる。ExcelやWordのようにサクサク動かない。
コミュニティも、改善すると前々から唱えてるけど、一向に改善される気配ないし、
根が深いっぽい。

OpenOfficeはlinuxでもWindowsでも動くけど、どっちもトロい。
一度、ご自分の目でお確かめを。

726 ：超先生＠OS板 ◆leaf/RYZgY ：03/01/03 10:21

>最近、ワードやエクセルとデータが交換できるようなオープンソースの
>Officeもありますので、移植する手も考えています。
　 ∧＿∧
＜　｀ー´＞-~~~
早期にJava VMを実装してThinkFree Officeを動かしたりする手もあり。

727 ：デフォルトの名無しさん：03/01/03 20:14

まわりくどいことせずに
Wineを完全に動かせればいいんじゃ、、

728 ：デフォルトの名無しさん：03/01/03 22:29

ところで、NWSOSでもやっぱり、タスクの生成・管理法に親子関係を
使っているのですか？fork(), exec()みたいなもの。

729 ：超先生＠OS板 ◆leaf/RYZgY ：03/01/03 22:34

　 ∧＿∧
＜後ろ頭＞-~~~ CoWは効率上げるの難しいんだよな・・・。

730 ：デフォルトの名無しさん：03/01/03 22:45

fork(), exec()を使わない、効率的なタスク管理方法ないですかね、、、。
実際問題、効率的とかはあまり関係なく親子関係ってのが伝統的なUNIX
っぽくって嫌なだけですけどね。。。

731 ：LightCone ◆sSJBc30S5w ：03/01/03 22:45

>>728
>NWSOSでもやっぱり、タスクの生成・管理法に親子関係を使っているのですか？

今のところタスクの親子関係はありませんが、各種保護の管理に利用出来そう
なので多方面からメリットとデメリットを考察中です。

また、今のところ、NWSOSには、fork()はなく、
いきなり新タスクを生成する仕組みを採用しています（ExecTask(),
SpawnTask()参照)。

最近、UNIXのソースなどを見るうちに、fork()のメリットが分かってきま
したので（サブスレッドのメリットと、メモリ保護のメリットを足したよう
なものとして利用出来る場合があります）、近いうちにNWSOSでも実装する
予定です。同時に追加予定の、exec()相当APIと、既存のExecTask()APIで、
API名が紛らわしくなるのが気がかりでは有りますが、今のExecTask()は
捨ててもいいかなと思っています（SpawnTask()APIが上位互換なので）。

732 ：LightCone ◆sSJBc30S5w ：03/01/03 22:54

>>730
>実際問題、効率的とかはあまり関係なく親子関係ってのが伝統的なUNIX
>っぽくって嫌なだけですけどね。。。

例えば、「伝統的なUNIXの嫌な部分」とは、waitpid()が、
自分から見て子の関係にあるタスクだけしかできないことや、「wait」しない
とゾンビが残る、みたいなことでしょうか。間違っていたらすみませ
ん（UNIX初心者なので）。

ちなみに、NWSOSでは全く親族関係の無いタスクでも、タスクハンドルだけ
はロックできるので、タスクが不意に死んだとしても安全にステータスを読む事
ができるような仕組みにしてみました。

733 ：LightCone ◆sSJBc30S5w ：03/01/03 22:59

>>726
なるほど、ThinkFree Office は、JavaVMがあれば動くんですか（基本的な
事を知らないので申し訳ないんですが）。

であれば、有志の方に JavaVM を実装（移植?）して欲しい
ところなんですが、、、。(^_^;)

それはそれとして、他にも各種フリーの(?)Officeがあるようですが、
その辺はどうなんでしょう。

734 ：LightCone ◆sSJBc30S5w ：03/01/03 23:03

>>725
なるほど、機会があるときに調べておきます。
貴重なご意見を有難うございました。

735 ：LightCone ◆sSJBc30S5w ：03/01/03 23:07

>>729
>CoWは効率上げるの難しいんだよな・・・。

恐らく、fork()する際の、CopyOnWriteの事だと思うんですが、
NWSOSにfork()を最初に実装する際には、ひとまず効率追求は後回しにする
として、簡単に単純コピーしようと思っています（内部的な改良で上げられる
種類の効率は、徐々に高めたいと思っていますので）。

736 ：デフォルトの名無しさん：03/01/03 23:16

>732
親子関係でのステート管理方法もそうだけど、
fork(), exec()時のオーバーヘッドが大きいからかな。
COWで少しは軽減されてるみたいだけど。
こればっかりはどうしようもないか。
でも、確かに各種保護機能だけはすぐれていると思います。

737 ：デフォルトの名無しさん：03/01/04 07:10

>恐らく、fork()する際の、CopyOnWriteの事だと思うんですが、
ここでいうcopyって、.bssセクションなどのコピーっていう意味かな？

738 ：デフォルトの名無しさん：03/01/04 08:42

NWSOSへの希望

キーボードのオートリピート速度を高速にしてほしー

739 ：LightCone ◆sSJBc30S5w ：03/01/04 08:52

>>737
>ここでいうcopyって、.bssセクションなどのコピーっていう意味かな？

えーと、ご存知かもしれませんが、
CopyOnWriteとは、fork()した時点では、ページテーブルや
ページディレクトリのコピーをするだけにしておいて、物理ページや
スワップ領域を確保せず、アプリがデータ領域などに相当するページに
書き込もうとするとページ例外を発生させて、例外ハンドラ内で
物理ページをマッピングして、実際にコピーを行うような方法のこと
を言います。

.bssセクションの場合は、fork()した時点の親プロセスにおいて、既に書き込み
があれば、.dataセクションと同様の扱いになり、書き込みが無ければ、
実際にアクセスされた時点で0-Fillされたページを割り当てる、という手が使
えると思います。

740 ：LightCone ◆sSJBc30S5w ：03/01/04 08:55

>>738
>キーボードのオートリピート速度を高速にしてほしー

最速に設定しているつもりなんですが、設定できてませんか？
（なんらかの原因でキーボードの種類によっては正しく設定できてないの
かもしれません）

741 ：LightCone ◆sSJBc30S5w ：03/01/04 09:04

>>736
　fork()ならではの技法が存在するので、UNIXアプリを移植するためには、
効率は度外視したとしても、一応はfork()を用意しておいた方がいいと思って
るんです。

NWS-SHELLでは、内部コマンドをサブスレッドで実装していますが、
BASHでは、fork()を使って自分のクローンプロセスを作成して、別プロセス
でやってます。後者の方法は、内部コマンドの起動効率は悪いのですが、
内部コマンドを外部コマンドと全く同じ扱いにできるメリットがあります。

742 ：デフォルトの名無しさん：03/01/04 14:04

>>686
豊

>>700
女じゃなかったの？

743 ：デフォルトの名無しさん：03/01/04 15:04

>fork()ならではの技法が存在するので、UNIXアプリを移植するためには、
>効率は度外視したとしても、
linuxの do_fork() に kprintf() 仕込んで、カーネルコンパイルしなおし
KDE起動してみたとこ、意外にもforkが呼び出される回数って少なかった。

で、再度、kprintf()外すときにlinuxカーネルをフルビルドしたんだけど
gcc内部では一度もforkを呼び出してなかった。

頻度考えると、Lﾀﾝのfork()効率後回しは正解かも。

744 ：デフォルトの名無しさん：03/01/04 15:22

サーバープロセスじゃないとforkはあまりしないような・・・

745 ：デフォルトの名無しさん：03/01/04 15:34

でも、BASHとかのシェルだと、コマンド実行するたびに、

if ((pid=fork()) > 0)
exit(0);
if (pid == 0)
exec("comand");

みたいなことするんでしょ？
fork()しっかり使ってるような。。

746 ：デフォルトの名無しさん：03/01/04 15:37

間違った。

if (pid == 0)
exec("comand");

if ((pid=fork()) > 0)
while (wait(&status) != pid)
/* LOOP */ ;

747 ：LightCone ◆sSJBc30S5w ：03/01/04 17:55

　bashの特徴的なfork()の使い方は、内部コマンドを実行する際に、fork()
だけを使っている事です（exec()は呼ばれません。）。
　ちなみに、現代的にはサブスレッドでやるような処理なんですが、
伝統的なUNIXには、スレッドがサポートされていませんでした。

748 ：デフォルトの名無しさん：03/01/04 18:44

>>L様
tcshはWindowsにも対応しているので
bashだけでなくtcshの方もご覧になるのはいかがでしょうか？
http://www.tcsh.org/

win32\fork.cを見ると、CreateProcess()を使ってfork()が
実装されていたりと色々と面白いですよ。

Mac OS XとかMicrosoft Interixとかでも
bashではなくてtcshが標準的です。

749 ：ひげぽん：03/01/04 19:00

最近OSの勉強ばかりで、あまり進んだように見えないMonaですが
少しずつ前進しております。

Linuxってすごいですねと、しみじみと思います。
遅延書き込みとか、仮想ファイルシステムとか、ドライバインターフェースとか
でもこれって、あとから追加されたものですよね・・・
そう願いたいです。

話題になっているforkですがMonaでは、どうしようかと
ちょうど悩んでいるところでした。(細かいところはまだ不勉強ですが)
プロセスに親子関係を持たせる方向で行こうかな。

750 ：ひげぽん：03/01/04 19:04

公式サイト ttp://mona.sourceforge.jp/
1000Hitを記念して
(・∀・)yossy◆FlasH.X1/sさんの作品を公開いたします。
ttp://mona.sourceforge.jp/Pack.gif

私のモチベーションはこれで上がりました。

751 ：名無したん ◆AEqcy/sQU6 ：03/01/04 19:06

ｶｺ(・∀・)ｲｲ

いいなぁ(；´Д｀)

752 ：デフォルトの名無しさん：03/01/04 19:19

>>750
おめでと。ところでSourceForgeはプロジェクトの削除を認めないから
http://higepos.sourceforge.jp/
が放置されてるのは分かるんですけど、
せめてMonaへのリンクくらい置いておいていただけませんか？

753 ：デフォルトの名無しさん：03/01/04 19:47

>>749
> あとから追加されたものですよね・・・

Linuxのエエところは、その追加や変更に必要な膨大な作業を、
厭わずに全世界のgeeksのパワーでもってやりとげたことだわね。

今はもう各企業のオープンソース対策チームの人たちがやってる
から、感慨深くはないけど。

754 ：ひげぽん：03/01/04 19:53

>>752
>せめてMonaへのリンクくらい置いておいていただけませんか
ご指摘ありがとうございます。
半ば忘れていました。申し訳ありません。
対応いたしました。

755 ：デフォルトの名無しさん：03/01/04 20:03

>>749
http://kernel.org/pub/linux/kernel/Historic/linux-0.01.tar.bz2
有名な最初にリリースされたカーネル
ものすごく小さいから読みやすいし、参考になるかも

756 ：デフォルトの名無しさん：03/01/04 20:26

>>754
素早い対応ありがとうございます。
ただTypoが……。 < Soryy

あと、せっかく置いてあったhigepos.binが隠れて
ちょっと寂しいかな……。

要望ばかりですみませんが、
時間があるときにでもMonaのコンパイルに挑戦してみますんで。

757 ：デフォルトの名無しさん：03/01/04 20:35

>750
(・∀・)yossy◆FlasH.X1/sさん、すごひ。
本格的なパッケージですね。

758 ：henoheno@OS板 ◆mXrBwDDzyw ：03/01/04 20:59

古いLinuxのソースを見るだけならば、ここからどうぞと言うテスト。
ttp://minix-up.sourceforge.jp/cgi-bin/l.cgi/l/li/linux/?only_with_tag=LINUX_0_01

759 ：デフォルトの名無しさん：03/01/04 21:17

Monaの公式サイト、ダウンロードの
"Mon実行方法"って"Mona実行方法"の間違いだよね？
開発に関係なくて申し訳ないが、直したほうがいいかと。

760 ：ひげぽん：03/01/04 21:24

>>755
有用なリンクありがとうございます。助かります。

>>756
>ただTypoが……。 < Soryy
>あと、せっかく置いてあったhigepos.binが隠れて
失礼しました。
あと英文ミスも直しました・・・

>間があるときにでもMonaのコンパイルに挑戦してみますんで
ぜひチャレンジしください。
インストール方法に反映させていただきます。

>>758
これは便利ですね。henohenoさん、ありがとうございます。

761 ：(・∀・)yossy ◆FlasH.X1/s ：03/01/04 21:32

>>751
>>757
ありがとうございます（　´∀｀）
近いうちにアレが使われる日が来る事を願いましょう

>>759
スイマセン、直しますた

762 ：デフォルトの名無しさん：03/01/04 21:37

>>760
あのー、度々で申し訳ないんですけど、
別の間違い方なんですが。。。< Soryr
Sorryです!!

763 ：ひげぽん：03/01/04 21:44

>>762
直しました。今日はどうにかしているようです。
もう、馬鹿かとアホかと・・・
すいませんでした。m(__)m

764 ：デフォルトの名無しさん：03/01/04 22:03

>>763
お疲れ様でした。

ところでちょっと個人的な要望なんですが、
MonaはいきなりGUIにいかずに、
コマンドラインとしても使えるようにしてほしいです。
NWSOSとかOSASKはいきなりGUIにいくのでちょっと……。

コマンドラインを隠すにしても
Win3.1みたいにAutoexec.batで起動させる方法もありますし。

765 ：ひげぽん：03/01/04 22:26

>>764
>MonaはいきなりGUIにいかずに、
>コマンドラインとしても使えるようにしてほしいです。

ご要望ありがとうございます。
当分はCUIオンリーだと思います。
GUI導入時には、上記要望を取り入れられるよう
検討します。

GUIをどれだけカーネルから分離するかも
考えなければいけないですね。

タスク管理
メモリ管理（ページング）
VGA対応
フロッピードライバ
ファイルシステム
プロセスロード(実行形式の決定)
・・・道のりは長い。

766 ：デフォルトの名無しさん：03/01/04 22:31

>>765
ありがとうございます。
お礼にみとこさんから問題報告の上がっていた
VirtualPC(もちろん正規ライセンス品)を寄贈させていただきます。
詳しくはメールで。

767 ：ひげぽん：03/01/04 22:49

>>766さん。
>お礼にみとこさんから問題報告の上がっていた
>VirtualPC(もちろん正規ライセンス品)を寄贈させていただきます。
>詳しくはメールで
えーと、これは本当なのでしょうか。
かなりびっくりしています。osdevjでお話したことある人でしょうか。
とりあえずメール待ってます。

768 ：ひげぽん：03/01/05 00:47

VirtualPCを寄贈してくださった。
匿名希望の方に深く感謝いたします。

Monaをより発展させていくことでしか
ご厚意にこたえることは出来ないのが申し訳ないですが
活用させていただきます。

769 ：デフォルトの名無しさん：03/01/05 12:33

bochsのことですが、bochsout.txtに書かれる内容を常時、
裏コンソールに表示させることはできるのでしょうか？
もし、設定等あったらお願いします。

770 ：デフォルトの名無しさん：03/01/05 13:28

ひげぽんがんばれ！

771 ：デフォルトの名無しさん：03/01/05 13:45

誹謗中傷掲示板のOSね…

772 ：デフォルトの名無しさん：03/01/05 14:45

>>771
???

773 ：デフォルトの名無しさん：03/01/05 14:45

>>772
2ch発のOSと言いたいのだろう

774 ：ひげぽん：03/01/05 14:50

>>769
.bochsrcのLOG設定のところをご覧ください。
#log: /dev/null
#log: bochsout.txt

>>770
ありがとうございます。

775 ：デフォルトの名無しさん：03/01/05 15:18

>774
何度もすいません。
Cygwin上でbochsを動かしているので、/dev/ttyなどは使えません･･･。
出力ターミナルはどこに設定すればいいのでしょうか？

776 ：ひげぽん：03/01/05 15:22

>>775
Windows上でしたか動かしたことがないので、はずしているかもしれませんが
# Give the path of the log file you'd like Bochs debug and misc. verbage
# to be written to. If you really don't want it, make it /dev/null. :^(
と書いてあるので
log: /dev/null
ではないでしょうか。

777 ：sage：03/01/05 19:09

linuxの初期ソース読むなら↓参照にするのもいいかも。
結構大雑把なんだけれども。
http://www.nurs.or.jp/~ogochan/linux/TTECH.html

boot部分もこれ見ながら改良できるかもしれぬし。
例えば603で話題に出てたモータの止め方なんか。

778 ：ひげぽん：03/01/05 19:19

>>777
おもしろですね。
ご紹介ありがとうございます。

779 ：henoheno@OS板 ◆mXrBwDDzyw ：03/01/05 22:16

>>777
記事に合わせて参考URLを並べると以下の通りです（　´∀｀）
(URLもちょっと直しました)

Linux 0.01
ttp://minix-up.sourceforge.jp/cgi-bin/l.cgi/l/li/linux/?hideattic=0&only_with_tag=LINUX_0_01

Linux 0.01 のファイル一覧 (88ファイル)
ttp://minix-up.sourceforge.jp/cgi-bin/l.cgi/l/li/_analysis/CVSUPLOG.txt?rev=1.1

(参考) MINIX 1.5 の src/fs/inode.h
ttp://minix-up.sourceforge.jp/cgi-bin/l.cgi/l/mi/MINIXtest/src/fs/inode.h?rev=1.1&content-type=text/x-cvsweb-markup

May the Source be with you.

780 ：デフォルトの名無しさん：03/01/05 22:20

winでgccでオブジェクトファイルを出力するとデフォルトでpe-i386に
なってしまう。しかもldでもpe-i386で実行可能プログラムが出力。。。
ELFを扱いたいんですが、gccでELF形式のオブジェクトを出力して、
ldでELF形式としてリンクして、ELF形式の実行可能プログラムを出力
させるためにはどうすればいいんですか？（コマンド等）

781 ：デフォルトの名無しさん：03/01/05 22:43

gcc を --target=i386--elf で make しなおす。

782 ：デフォルトの名無しさん：03/01/05 22:51

>781
どうもありがとうございます。
cygwin使ってるんですが、、、
外部用にgccインストするほうがよさげですね。

783 ：デフォルトの名無しさん：03/01/06 00:42

気づいたのですが、WINXP + CYGWIN の環境でELF形式の
プログラムを開発する場合、クロスコンパイル環境の
構築が必要なので何かとめんどくさいですね。
gccの他に、ld, gdbとか色々。。。

784 ：名無したん ◆AEqcy/sQU6 ：03/01/06 08:42

A4に印刷して組み立ててみた。。。

ttp://meg-os.org/2ch/mona.jpg

785 ：(・∀・)yossy ◆FlasH.X1/s ：03/01/06 09:34

>>784
おぉ！いい感じｗ
実寸でやると、多分WinXPの箱とおなじ大きさになるはず

786 ：デフォルトの名無しさん：03/01/06 09:52

MPDNの資料室にある

> [Web] OSASKウェブサイト
> http://www.imasy.org/~kawai/osask/index.html
> OSASK河合さんのページ
川合の間違いですね

はめて読む486の正誤表
http://www.ascii.co.jp/books/support/apc/4-7561-0213-1.html
も入れとくとイイと思う

787 ：デフォルトの名無しさん：03/01/06 12:07

gcc（pe-i386）からgcc（elf32-i386）に変えたところ、
iretのところでこけてしまいます。↓
>>PANIC<< iret: return CS selector null

gcc(elf32-i386)でコンパイル、iret付近のdisassemble.
82:61 popa
5d:61 popa
5e:89 ec mov %ebp,%esp
60:5d pop %ebp
61:cf iret
62:c9 leave
63:c3 ret

gcc(pe-i386)でコンパイル、iret付近のdisassemble.
4b:61 popa
4c:89 ec mov %ebp,%esp
4e:5d pop %ebp
4f:cf iret
50:89 ec mov %ebp,%esp
52:5d pop %ebp
53:c3 ret
54:25 78 20 00 90 and $0x90002078,%eax
59:8d b4 26 00 00 00 00 lea 0x0(%esi,1),%esi

気づくことがあればお願いします。

788 ：超先生＠OS板 ◆leaf/RYZgY ：03/01/06 13:21

>82:61 popa
>5d:61 popa
　 ∧＿∧
＜後ろ頭＞-~~~ popaが2つも入ってるけど・・・。

789 ：787：03/01/06 14:29

すいません（汗）
82:61 popa
↑はペーストミスです。

>>PANIC<< iret: return CS selector null
から復帰させたCSが不正ということなので、
iretの後の、leave（スタックフレーム破棄）が問題なのかと
思ったのですが・・・。
最終出力はバイナリー形式なのですが、
入力オブジェクト形式（gccの出力）を変えると
色々代わってくるんですかね。。。

790 ：超先生＠OS板 ◆leaf/RYZgY ：03/01/06 14:40

　 ∧＿∧
＜後ろ頭＞-~~~ 推測では、形式を変えるとcdecl/stdcallが変わるとか・・・。
関数のprologueをdisassembleすると分かるはず。

791 ：デフォルトの名無しさん：03/01/06 16:21

このままなんとなく続けていくとモノリシックになる罠。

792 ：名無したん ◆AEqcy/sQU6 ：03/01/06 16:23

大丈夫。

NTのマイクロカーネルの方が遥かに大きい。

793 ：デフォルトの名無しさん：03/01/06 20:39

>>789
gcc -S でアセンブリ言語出力吐き出させてディスアセンブル結果と
比較すれば関数のプロローグが変わっているか否かはわかるんじゃない？

794 ：デフォルトの名無しさん：03/01/06 20:44

>>787
>mov %ebp,%esp
>pop %ebp
を
leave
にすれば動きそうな気がしますが…
関数の途中でiretするのはよろしくないんではないかと。
__attribute__((interrupt))使えませんか？

795 ：デフォルトの名無しさん：03/01/06 21:00

>>794
>関数の途中でiretするのはよろしくないんではないかと。

それだ。
関数の入り口と出口でpush,popのバランスが取れているところに
iret 突っ込んじゃったら、関数の入り口でpushされた%espとかを
iretがリターンアドレスと勘違いしちゃうんだろな。

796 ：超先生＠OS板 ◆leaf/RYZgY ：03/01/06 23:10

>>794
　 ∧＿∧
＜後ろ頭＞-~~~ leaveはmov %ebp,%esp pop %ebpと等価だと思うけど。。。

>>795
ちゃんとStackframeを潰しているもよう。

797 ：787：03/01/06 23:34

iretの部分では原因はつかめなかったのですが、

gcc {色々オプション（ライブラリ非依存のための）} -c xxx.c
gcc {色々オプション} -c yyy.c
gcc {色々オプション} -c zzz.c

ld -s（シンボル全削除） --oformat binary xxx.o yyy.o zzz.o

でバイナリ形式を出力した場合、関数のプロローグなどは別として、
入力が何形式であれ、結局バイナリ形式出力なので同じものができると
いうわけではないのでしょうか？

798 ：787：03/01/06 23:54

解決しました！

全く馬鹿馬鹿しい原因でした。。。
-O2最適化オプションが原因でした。
pe-i386では適切に最適化していたようですが、
elf32-i386では余計なことしてたのかなぁ。

799 ：デフォルトの名無しさん：03/01/07 01:10

>>798
最適化のバグが原因で最適化した場合だけ動かないって事たまにはあるけど．．．
大抵は自分で仕込んだバグだったな。

最適かやめて安心してると後で泣きを見るかもしんないよ。

800 ：ひげぽん：03/01/07 01:38

>>784
箱いいですねぇ。

>>786
>> OSASK河合さんのページ
>>川合の間違いですね

すいません、これはひげぽんのミスです。
大変失礼しました。
修正させていただきます。

801 ：名無したん ◆AEqcy/sQU6 ：03/01/07 13:07

対抗してみるテスト
ttp://meg-os.org/2ch/lite.jpg

802 ：デフォルトの名無しさん：03/01/07 19:30

>>801
ﾜﾗﾀ｡

803 ：デフォルトの名無しさん：03/01/07 21:31

しかもMEG-OSの方がしわがなくてきれい

804 ：ひげぽん：03/01/07 21:56

>>801
会社で見て笑いました。(

雑誌UNIX　USER　2月号のBochs2.0特集記事の中の片隅で
Monaプロジェクトがちょこっと紹介されました。ヽ(´ー｀)ノ
これで少しは知名度アップ？？
もちろん雑誌は買いました（笑）

805 ：ひげぽん：03/01/07 22:25

mona.img(41KB)からunixコマンドで
mona.img(1.44MB)を作りたいのですが
どなたか良い方法を教えていただけないでしょうか。
ddコマンドでしょうか？

現状はrawrite.exeでwriteしたあと、readして
イメージファイル(1.44MB)を作成しています。

806 ：名無したん ◆AEqcy/sQU6 ：03/01/07 22:27

>>803
monaは色が濃いのでふやけた予感。

807 ：デフォルトの名無しさん：03/01/07 22:27

>>804
そういうのには見本誌はないの？

808 ：デフォルトの名無しさん：03/01/07 22:32

>>805
dd でサイズを指定して、後ろを埋めちゃえばいいんじゃないかな。

809 ：デフォルトの名無しさん：03/01/07 22:34

>>805
cat mona.img /dev/zero|dd of=mona_fd.img bs=1k count=1440
かなあ？

810 ：ひげぽん：03/01/07 22:35

>>804
Bochsの記事を執筆された方のご厚意での紹介なので
そんなのはないです。紹介されただけで感激です。

>>808
ddでサイズを指定をする場合ってosでしたっけ
やり方が悪いのかうまくいきません。

811 ：ひげぽん：03/01/07 22:45

>>809
>cat mona.img /dev/zero|dd of=mona_fd.img bs=1k count=1440

出来ました。ありがとうございますm(__)m

812 ：Tino ◆sMrLqQHxo6 ：03/01/08 00:05

カーネルがSTLを使ってリライトされそうな予感（ｗ

813 ：ひげぽん：03/01/08 00:30

>>812
の予感による通り（笑）
Tinoさん提供のパッチと手ほどき書により
Monaの実装にSTLが使えるようになりました。！！！！
Tinoさんありがとうございます。m(__)m

これに伴い開発環境の移行をいたしました。
gcc2.95@cygwin→gcc3.2@cygwin

STLの導入で夢が広がりました。
こんなコードが動きます↓

814 ：ひげぽん：03/01/08 00:30

    // string
    std::string str = "---";
    str += "string";
    str += "@mona ";
    str += "is OK";
    str += "---";
    _sys_printf("string: %s\n", str.data());
    _sys_printf("string: str.substr(3, 11): %s\n", str.substr(3, 11).data());

    // list
    std::list<char*> li;
    li.push_back("micoro kernel ");
    li.push_back("operating system with ");
    li.push_back("network suit architecture ");
    li.push_back("\n");
    std::list<char*>::iterator it;
    _sys_printf("list  : iterate->");
    for (it = li.begin(); it != li.end(); it++) {
        _sys_printf("%s", *it);
    }

815 ：ひげぽん：03/01/08 00:31

    // vector
    std::vector<char*> ve;
    ve.push_back("1");
    ve.push_back("2");
    ve.push_back("3");
    ve.push_back("4");
    std::vector<char*>::iterator it2;
    _sys_printf("vector : iterate->");
    for (it2 = ve.begin(); it2 != ve.end(); it2++) {
        _sys_printf("%s ", *it2);
    }

    // argorithm
    std::reverse(ve.begin(), ve.end());
    _sys_printf("\nargorithm : reverse->");
    for (it2 = ve.begin(); it2 != ve.end(); it2++) {
        _sys_printf("%s ", *it2);
    }

    std::fill(ve.begin(), ve.end(), (char*)"7");
    _sys_printf("\nargorithm : fill with \"7\"->");
    for (it2 = ve.begin(); it2 != ve.end(); it2++) {
        _sys_printf("%s ", *it2);
    }

816 ：デフォルトの名無しさん：03/01/08 05:13

数日たったころにバグが出そうなコードですな。。。

817 ：デフォルトの名無しさん：03/01/08 12:02

C＋＋でカーネル書くこと自体が良いのか悪いのかではなく、
色々、未知な領域なので、Cで書くよりは新しいことがいっぱい
で面白そうだ。

ところで、lightconeさんのnwsosカーネルの実行形式はなんなんだろ？
elf or pe ?　もしくは　coff...

818 ：LightCone ◆sSJBc30S5w ：03/01/08 12:17

>>ところで、lightconeさんのnwsosカーネルの実行形式はなんなんだろ？
>>elf or pe ?　もしくは　coff...

　カーネルのソースは、COFF形式またはOMF形式のOBJファイルを作成して
から、自作リンカ(NWSL)で、独自形式(NWSOSのネイティブアプリケーションの
実行形式と同じ）にリンクしています。
　OBJの段階では、COFFでもOMFでもリンクできたと思います。

819 ：817：03/01/08 12:25

>818

そうでしたか。
というより、独自リンカで作成しているので、COFFかOMFでしたね。
今さっき、NWSLの仕様を見て気づきました。ｽﾏｿ。

820 ：デフォルトの名無しさん：03/01/08 14:29

いや～、part2～part4、もうすぐpart5。
色々なものが出来上がりましたね。
これはすごいことだと思います。
さっそく、UNIX　USER　2月号見てきますｗ

821 ：デフォルトの名無しさん：03/01/08 14:56

記事うｐｷﾎﾞﾝﾇ

822 ：デフォルトの名無しさん：03/01/08 19:45

>>821
禿同！

823 ：デフォルトの名無しさん：03/01/08 19:46

誰もC++で書かれたBeOSのことを語らないね、、なんで？
http://www.zdnet.co.jp/macwire/0001/19/c_igeek2.html

FBC問題、、

824 ：デフォルトの名無しさん：03/01/08 20:10

FBC(fragile base calss)

[邦訳] 脆い基本クラス

・オブジェクト(すなわち構造体やクラス)のサイズ
・(publicやprotectedである)「可視の」データまでのオフセット
・vtableの存在とサイズ
・vtable中の仮想関数へのオフセット

あなたのアプリがコンパイルされ、リンクされる時、それ[ダイナミック
ロード・ライブラリ]はこれらすべての情報を記録します。これらのうち
の何かがライブラリ中で変更された場合、コンパイルされたアプリはもは
や動かないという問題。

以上参考までに･･･

825 ：デフォルトの名無しさん：03/01/08 20:18

>>823
思いっきり既出 >>710

826 ：デフォルトの名無しさん：03/01/08 20:21

今Monaがやってる部分はカーネルの中だから
ユーザーアプリのリンクとまったく関係ないので、
FBC問題の影響はありません。

とりあえずマイクロカーネルなんだから、
カーネル内部とは関係なくその上にOSサーバが来て、
その上にユーザーランドが来るので、
そういうことが関係してくるのはユーザーランド以降ですね。

827 ：IP記録実験：03/01/08 21:52

IP記録実験
http://qb.2ch.net/test/read.cgi/accuse/1042013605/

1 名前：ひろゆき ◆3SHRUNYAXA ＠どうやら管理人 ★ 投稿日：03/01/08 17:13 ID:???
そんなわけで、qbサーバでIPの記録実験をはじめましたー。

27 名前：心得をよく読みましょう投稿日：03/01/08 17:20 ID:yL/kYdMc
SETTING.TXT管轄でないということは全鯖導入を視野に、か？

38 名前：ひろゆき ◆3SHRUNYAXA 投稿日：03/01/08 17:22 ID:rLfxQ17l
>>27
鋭いです。

73 名前：ひろゆき ◆3SHRUNYAXA 投稿日：03/01/08 17:27 ID:rLfxQ17l
＞ところで、IPが抜かれて何か今までと変わることってあるのでしょうか？
・今までより、サーバが重くなる。
・裁判所や警察からの照会があった場合にはIPを提出することがある。

828 ：ひげぽん：03/01/08 22:02

>>816
>数日たったころにバグが出そうなコードですな。。。
うう。勉強が足らないようです。STLの本買おうかな。

>>817
>色々、未知な領域なので、Cで書くよりは新しいことがいっぱい
>で面白そうだ
そうですね。面白いです。
STL使えるなんてわくわくです。

>>820
>さっそく、UNIX　USER　2月号見てきますｗ
見て、気に入ったら買ってください（笑）

>>821
>記事うｐｷﾎﾞﾝﾇ
さすがにそれは、まずいと思うのでむりっす。m(__)m

829 ：デフォルトの名無しさん：03/01/08 22:24

> >数日たったころにバグが出そうなコードですな。。。
> うう。勉強が足らないようです。STLの本買おうかな。
そういう意味じゃないと思う。

830 ：デフォルトの名無しさん：03/01/08 22:28

STLは標準っていうくらいだから使えても当たり前で面白みないっす。
逆に言うと使えないと話しにならんってことだが。

とりあえず次はboostでlambdaですな。
こんなのが当たり前のように使われてるカーネル……わくわく
http://www.kmonos.net/alang/boost/classes/lambda.html

831 ：デフォルトの名無しさん：03/01/08 22:36

boostならlambdaの前にshared_ptrだろ
これ使ってJavaみたいにdeleteのないコードにしなきゃ
単なる悪趣味と言っても過言ではないｿﾞ

832 ：ひげぽん：03/01/08 22:38

>> うう。勉強が足らないようです。STLの本買おうかな。
>そういう意味じゃないと思う。

どういう意味でしょうか。
OS作成には使わないほうが良いというアドバイスでしょうか。

833 ：デフォルトの名無しさん：03/01/08 22:56

>>832
STLの書き方を問題にしてるんじゃなくて、
STLを使うこと自体を問題にしてるんだろう

それを受けて >>817 氏が
> C＋＋でカーネル書くこと自体が良いのか悪いのかではなく、
> 色々、未知な領域なので、Cで書くよりは新しいことがいっぱい
> で面白そうだ。
って応援してくださってるんっしょ

834 ：ひげぽん：03/01/08 23:02

>>833
納得しました。ありがとうございます。

835 ：デフォルトの名無しさん：03/01/08 23:05

とりあえずSTLじゃインパクトがなかったみたいなので
次はboostをおながいします

836 ：デフォルトの名無しさん：03/01/08 23:17

オナニーでOS作りましたってだけじゃ注目されない
一流のエンターテイメントを目指すのだ

837 ：デフォルトの名無しさん：03/01/08 23:27

カーネルの実装にSTL使えることは
結構すごいと思うけど

838 ：デフォルトの名無しさん：03/01/08 23:28

いろんな事いうヤシ居るけど、全部真に受けてたらろくなもん出来ないぞ。
エンターテイメントは大事だけど、最低どっか一つ輝く部分があればいい。

欲張りすぎると、どっかのＫがつくＯＳみたいになる

839 ：デフォルトの名無しさん：03/01/09 01:39

>>352
友人から借りた？おいおい。MXで落とせば？

840 ：デフォルトの名無しさん：03/01/09 02:27

>>593
昔からとってたよ。

841 ：IP記録実験：03/01/09 02:48

842 ：デフォルトの名無しさん：03/01/09 03:11

>256
意味ない。

843 ：デフォルトの名無しさん：03/01/09 03:22

1000!!!

844 ：デフォルトの名無しさん：03/01/09 11:59

なんで500も前にレスするですか？

845 ：名無したん ◆AEqcy/sQU6 ：03/01/09 15:20

荒れてきてますﾈ・・・

846 ：デフォルトの名無しさん：03/01/09 18:26

======2==C==H======================================================

　　　　　　　　　２ちゃんねるのお勧めな話題と
　　　　　ネットでの面白い出来事を配送したいと思ってます。。。

===============================読者数： 138720人　発行日：2003/1/9

年末年始ボケがそろそろ収まり始めた今日このごろのひろゆきです。

そんなわけで、年末に予告したIP記録ですが実験を開始しています。

「２ちゃんねる20030107」
こんな感じで各掲示板の最下部に日付が入ってるんですが、
20030107以降になってるところはログ記録実験中ですー。

んじゃ！

────────────────────────Age2ch─
■この書き込みは、Age2chを使って配信されています。
────────────────────────────
Keep your thread alive !
http://pc3.2ch.net/test/read.cgi/software/1041952901/l50
────────────────────────────

847 ：デフォルトの名無しさん：03/01/09 21:13

ひげぽんガンバレ！
応援してます！

848 ：デフォルトの名無しさん：03/01/09 23:01

qb
削除整理、削除要請、削除議論、批判要望

live2
ニュース速報

tmp
ニュース極東、バカニュース、ちくり裏事情、違反の潰し方、薬・違法
少年犯罪、政治思想、ゴーマニズム、ペット苦手、download
ロビー、なんでもあり、厨房、最悪、学歴、人権問題

849 ：デフォルトの名無しさん：03/01/09 23:44

バカが数人紛れ込んできてるな。
ほかでやれよ。

850 ：デフォルトの名無しさん：03/01/09 23:52

>>849
相手にするな。
飽きて出て行くのを待つしかないよ。

851 ：デフォルトの名無しさん：03/01/10 00:55

５６７が良い事言った　　　　　　　　　　

852 ：デフォルトの名無しさん：03/01/10 09:56

>>64
んじゃ、内容証明でも認識しえたってことになりません？

853 ：デフォルトの名無しさん：03/01/10 10:14

某○○は相手が事実を認識しえたと判った段階でレス汁ｗ

854 ：デフォルトの名無しさん：03/01/10 10:48

博之が２ちゃんねる閉鎖を決めました。

855 ：名無したん ◆AEqcy/sQU6 ：03/01/10 10:50

時々動作がおかしくなります。添削キボン(´・ω・｀)
ttp://meg-os.org/2ch/fdc.asm

856 ：LightCone ◆sSJBc30S5w ：03/01/10 10:57

ひょっとして、掲示板の動作が異常？

857 ：デフォルトの名無しさん：03/01/10 11:57

てすと？

858 ：デフォルトの名無しさん：03/01/10 12:21

>>856
ここの板は
> ２ちゃんねる20021219
ですから、
IP収集テストと関係ないはずなんですが、
何なんでしょうね。
http://www.zdnet.co.jp/news/0301/09/njbt_07.html

859 ：デフォルトの名無しさん：03/01/10 12:28

>>858
コピペの内容にIP収集テストの話題が入ってるけど、
IP収集テストによる動作不良かもと思わせる意図があるんだろ。

>>855
そういえば、前にこのスレのリンクから meg-os.org 逝った時に
「不適切なリファラーです」とか何とかいわれたけど、
meg-os.org って２ちゃんとなか悪いんじゃないの？
何でそんなとこにファイルおけるの？

860 ：デフォルトの名無しさん：03/01/10 12:50

>>1　もぅいいじゃないか。
開き直れよ！　俺は変態だ！！って。
変態の何処が悪いんだよ。
男はな、みんな大なり小なり変態なんだよ。
そのことを女の大半が知らないだけなんだよ。

結論として言えることは、女の無知が悪いってことだよ。　

861 ：名無したん ◆AEqcy/sQU6 ：03/01/10 12:54

>>859
ﾘﾌｧﾗﾁｪｯｸに関しては厳しくなったり緩くなっているのでなんとも言えませぬ。
IPとおおよそのｱｸｾｽ日時を晒してくればｴﾗｰﾛｸﾞから原因を推定できますが。

2chと仲悪かったらこんなところにｺﾃﾊｿで書き込みませんyo(藁

862 ：LightCone ◆sSJBc30S5w ：03/01/10 13:01

　他のスレにも、昔の発言に対しての、元発言と全く関連性が無いようなレスが
IP実験開始あたりから頻出しているようです。
　ばれないようにテストしてるのか、それとも、バグかなんかでしょうか？

863 ：名無したん ◆AEqcy/sQU6 ：03/01/10 13:03

>>862
荒らしは放置しましょう。

864 ：デフォルトの名無しさん：03/01/10 13:58

>863
実際のとこどうなの？　荒らしなの？　（スレ違いｽﾏｿ）

865 ：デフォルトの名無しさん：03/01/10 14:08

>>861
ダイアルアップだし、時期も忘れてしまったのだけど、
そういえば、かちゅーしゃからリンクたどっから、リファラが憑いてなかったのかな。

>>864
１００％荒氏でしょ。
でもこのスレに張り付いてるわけでは無さそう。

866 ：名無したん ◆AEqcy/sQU6 ：03/01/10 14:11

>>865
ﾘﾌｧﾗがない場合はﾘﾌｧﾗ関係のｴﾗｰは出ないはず。。。

ﾘﾌｧﾗｴﾗｰが出る主な原因は怪しいﾘﾌｧﾗが漏れてる時なんで。

867 ：超先生＠OS板 ◆leaf/RYZgY ：03/01/10 14:13

　 ∧＿∧
＜後ろ頭＞-~~~ どれどれ書き込みテスト。

868 ：デフォルトの名無しさん：03/01/10 16:40

さぁ拳銃をてに入れて管理人を殺害しよう

869 ：デフォルトの名無しさん：03/01/10 20:42

>>858
すでにIP収集版に入れ替わってますね。。
＞２ちゃんねる20030107a

ところでmonaをCVSでダウンロードすると
既にSTL対応版に入れ替わっていました。
イメージファイルも1.44MBで出力するように修正されています。
さすがひげぽんさん、素早いですね。
(･∀･)ｲｲ!!

>>836
追いかけているだけで十分楽しめていますよ。
次は何が来るのでしょう？(^д^)

870 ：ひげぽん：03/01/10 21:44

>ところでmonaをCVSでダウンロードすると
>既にSTL対応版に入れ替わっていました。
>イメージファイルも1.44MBで出力するように修正されています
>さすがひげぽんさん、素早いですね。

ありがとうございます。でもあまり自分のやった仕事ではないのでもっとがんばります。
ついでに、Makefileも大幅に変更・改善しました。

871 ：デフォルトの名無しさん：03/01/10 23:01

ただ内部告発的なｶｷｺも減ってしまう気もするんだが・・・

872 ：デフォルトの名無しさん：03/01/10 23:07

http://qb.2ch.net/test/read.cgi/accuse/1042131034/

312 名前：ひろゆき ◆3SHRUNYAXA 投稿日：03/01/10 19:59 ID:jWxHxvti
全部にいれてみた。

873 ：デフォルトの名無しさん：03/01/10 23:21

静かですねえ。

874 ：デフォルトの名無しさん：03/01/10 23:28

>>830-831
Monaでboostを試してみたけど
例外とかRTTIとかちゃんと扱えないと無理っぽい
なるべく贅肉を殺ぎ落としたほうが良いカーネル内部で
そこまでするのはやりすぎと思う

それ以前にboostはでか過ぎるし
必要なものだけ切り出すにしても無駄が多いしで
STLで止めといたほうがバランス的にいい

ひげぽんたんもboostには興味はあったんだったら
無視しないでコメントした方が盛り上がると思うよ
http://pc.2ch.net/test/read.cgi/os/1039075591/272

以上、boostの件は決着 >boost厨

875 ：デフォルトの名無しさん：03/01/10 23:38

http://pc3.2ch.net/test/read.cgi/tech/1039513920/
ここの106辺りに興味深いことが書かれてるな

876 ：ひげぽん：03/01/11 00:05

>>874
>Monaでboostを試してみたけど
>例外とかRTTIとかちゃんと扱えないと無理っぽい

調査ありがとうございます。
ここにもできる人がすばらしいです。

例外がないのはきついと思っておりましたが
やはり無理でしたか。

>必要なものだけ切り出すにしても無駄が多いしで
>TLで止めといたほうがバランス的にいい

調査結果から判断するとやはり、このご意見に賛成です。

>ひげぽんたんもboostには興味はあったんだったら
>視しないでコメントした方が盛り上がると思うよ

大変失礼いたしました。
いまは、STLが使用できるようになったので満足しています。
実際にSTLがカーネル実装にどの程度使えるかいろいろ実験しようと
思っています。task構造体の格納にコレクションを使うとか・・・

877 ：デフォルトの名無しさん：03/01/11 00:24

真っ先に帰るのが普通の客なんでないかな??冷やかしの人に裁判沙汰のリスクは
おえないでしょ。
本職はIP位ではへこたれずに留まるだろうけど、暫らくは半端な厨房が通常板へ
なだれ込んで無差別に悪さ(差別コピペ)をする、っつー事になりそう･･･

878 ：デフォルトの名無しさん：03/01/11 00:34

新しいテーマをだして書き込み募集したいんですけどどうしたらいいの？

879 ：デフォルトの名無しさん：03/01/11 01:44

パート2から見て、漏れも勉強したかったんだが、未だにはじめてよむ486が
手に入らず想像ｵﾅｰﾆばっかしてる。
アマゾンでも在庫切れだってさ。。。

880 ：デフォルトの名無しさん：03/01/11 02:08

>>879
漏れはインテルのマニュアルで充分間に合ってる。
印刷するのがめんどいがな。

881 ：デフォルトの名無しさん：03/01/11 02:12

>>879
オンライン書店はamazonだけじゃない。
ttp://www.alles.or.jp/~teru1/washo.html
あとは自分で。

882 ：デフォルトの名無しさん：03/01/11 03:39

IP記録実験 Part3
http://qb.2ch.net/test/read.cgi/accuse/1042131034/

のレスをコピペしているようです。
ム板がちょっとした危機

883 ：デフォルトの名無しさん：03/01/11 09:21

ポリタンはギリギリのところで勝負してるっぽいとこが好きだ

884 ：デフォルトの名無しさん：03/01/11 09:21

まだ聞きたい事あったんだけどな

885 ：デフォルトの名無しさん：03/01/11 09:57

======2==C==H======================================================

　　　　　　　　　２ちゃんねるのお勧めな話題と
　　　　　ネットでの面白い出来事を配送したいと思ってます。。。

===============================読者数： 139038人　発行日：2003/1/10

なにやら、連日メルマガだしてるひろゆきです。

そんなわけで、ログ記録実験ですが、いちいちサーバ指定するのが面倒なので、
全部のサーバに入れてみました。

重くなって落ちたりしてもご愛嬌ってことで。。。

んじゃ！

────────────────────────Age2ch─
■この書き込みは、Age2chを使って配信されています。
────────────────────────────
Keep your thread alive !
http://pc3.2ch.net/test/read.cgi/software/1041952901/l50
────────────────────────────

886 ：デフォルトの名無しさん：03/01/11 10:50

352 名前：ひろゆき ◆3SHRUNYAXA [] 投稿日：03/01/08 18:01 ID:rLfxQ17l
　　　悲しいときー。悲しいときー。
　　　正月に友人からエロゲーを借りて喜んで帰ってきたら、
　　　パソコンが壊れてたー。

　　　昨日ヨドバシカメラで部品買ってきて直しました。

887 ：デフォルトの名無しさん：03/01/11 11:20

誰かipを保存しない匿名掲示板を作って　
　　　
削除依頼があったら意地をはらずに
ほいほい消しちゃっていいからさ

888 ：デフォルトの名無しさん：03/01/11 12:22

テツandトモは仕込んでません

889 ：デフォルトの名無しさん：03/01/11 12:47

>>884
荒氏は無視して普通にレスすればいいじゃん。

890 ：デフォルトの名無しさん：03/01/11 12:55

合流したみたいなので本題をどうぞ

891 ：デフォルトの名無しさん：03/01/11 12:58

>>829
> > >数日たったころにバグが出そうなコードですな。。。
> > うう。勉強が足らないようです。STLの本買おうかな。
> そういう意味じゃないと思う。
そういう意味だと思う。

> std::list<char*> li;
> li.push_back("micoro kernel ");
char*で扱うのは最悪。
1. std::list<const char*>または
2. std::list<std::string>とするべき。

元のだと簡単にバッファオーバーランできる。
格納された文字列を操作するんなら
2にしといた方が無難。
せっかくstd::stringが使えるんだから
char*は可能な限り避けるべき。
そうしないと数日経った頃にバグが出るかも。

> STLの本買おうかな。
Cの知識だからSTLの本には書いてないと思う。

892 ：ひげぽん：03/01/11 13:12

OSに関する話題のほうが少ないなあ。
がんばります。

インテル推奨のタスクスイッチ方法(TSSに対してjmp,call)を使わないで
タスクスイッチする方法を調べています。

調べていたところ
ttp://204.215.248.28/board.jsp?message=1783
ttp://www.tldp.org/HOWTO/KernelAnalysis-HOWTO-6.html
ttp://osdev.neopages.net/tutorials/soft_ts.php

などが見つかりましたが、もうあと一歩です。
手順としては
・レジスタセーブ(push？タスク構造体に？)
・現スタック保存
・レジスタ復帰(pop?タスク構造体から？)
・スタック切り替え(TSS経由)
と、概要はつかめたのですが。

上記と割り込みハンドラ中の切り替え(スタックがカーネルスタック？）
や、eflags,eipなどのタスク初期化時の扱い等、細かい部分が
まだ良く分かりません。
どなたか良い資料等ありましたら教えてください。
ソースもあると大変助かります。

893 ：ひげぽん：03/01/11 13:40

>>891

ご指摘ありがとうございます。

>> std::list<char*> li;
>> li.push_back("micoro kernel ");
>char*で扱うのは最悪。
>1. std::list<const char*>または
>2. std::list<std::string>とするべき。

了解しました。const char*にはすべきだなあと
なんとなく気づいていたのですが放置していました。
おっしゃる通り、stringがよさそうなのでstringにいたします。

894 ：デフォルトの名無しさん：03/01/11 15:35

これはいい！

895 ：デフォルトの名無しさん：03/01/11 15:42

IP記録実験
http://qb.2ch.net/test/read.cgi/accuse/1042013605/

1 名前：ひろゆき ◆3SHRUNYAXA ＠どうやら管理人 ★ 投稿日：03/01/08 17:13 ID:???
そんなわけで、qbサーバでIPの記録実験をはじめましたー。

896 ：デフォルトの名無しさん：03/01/11 16:39

>892

linux詳細カーネルの「プロセスの切り替え」
みたけど、結構複雑です。
FPU, 内部レベルステート、IOビットマップやらデバック情報など･･･。
OSとして例外処理、ページング、タスク管理機構ができあがるまでは、
TSSへJUMP切り替えのほうが無難では？プロセス生成時のステートの扱いの問題もあるし。
色々出来上がった後で、修正すればいいし。

割り込み処理コードはTSSを持たないらしいので（割り込み時のプロセスに
代わっての処理だから。カーネルレベルの話なら、スタック切り替えもない）。

897 ：デフォルトの名無しさん：03/01/11 17:45

後々の移植性とか考えると
ＴＳＳなんか使わないでページングだけで解決した方が無難だと思う。

898 ：デフォルトの名無しさん：03/01/11 18:06

>>892
「良い資料」などないよ。
そこは「考える部分」であって、調べたり、知識を吸収したりする部分
ではない。

899 ：LightCone ◆sSJBc30S5w ：03/01/11 18:14

　「タスクスイッチする方法」を調べるのではなく、「タスクスイッチ」とは
「なんなのか」を突き詰めて考える事をお勧めします。

　「タスクスイッチ」をして、結果的に得たい動作は何なのかが分かれば、
必要な処理が自ずから分かってくると思います。

答えは、CPU内部の状態変数（それが何なのかは勉強の事）を切り替えるだけ
です。

900 ：超先生＠OS板 ◆leaf/RYZgY ：03/01/11 19:28

>>892
　 ∧＿∧
＜後ろ頭＞-~~~ ちょっとだけヒント出しておこう。

　/* task->stackは切り替え先タスクのスタック */
　*(task->stack-?) = ?; /* 汎用レジスタ値(popa用) */
　...
　ebp = task->stack - ?;
　mov esp,ebp
　popa
　iret;
}

901 ：LightCone ◆sSJBc30S5w ：03/01/11 20:17

>>892
頑張って考えてみてください。

902 ：ひげぽん：03/01/11 21:15

>>896
アドバイスありがとうございます。

>TSSへJUMP切り替えのほうが無難では？プロセス生成時のステートの扱いの問題もあるし。
>色々出来上がった後で、修正すればいいし。

なるほど。

現状の問題点・動機としては
・タイマー割り込みによるスケジューリングでタスクスイッチをしたい。
→backlinkの設定、NTフラグ設定、iretで実現しているが、一部タスクスイッチしない実機がある
→これは、果たして正しいタスクスイッチなのか？ありなのか？
→IDTにタスクゲートをおくという手もあるがスケジューリングしたい場合は
タスクスイッチが結局問題になる

・上記の問題点により、だったらタスクスイッチの中身の詳細を自分で把握できた方が
良いかなと考えています。

・最初はTSSへのjmp、callで実装しておき、あとから修正する場合
二度手間になってしまうかもというのもあります。

903 ：ひげぽん：03/01/11 21:16

>>897
>>後々の移植性とか考えると
>>ＴＳＳなんか使わないでページングだけで解決した方が無難だと思う。

私もそう思います。

>>898
>「良い資料」などないよ。
>そこは「考える部分」であって、調べたり、知識を吸収したりする部分
>ではない。

おっしゃる事は良く分かります。
ただ、私の知識・経験不足のため、考えるための材料が不足している。
と強く感じています。
そのための材料集めも含めて、
皆さまのご意見・アドバイスを頂けたらと思います。

>>899 LightConeさん
>　「タスクスイッチする方法」を調べるのではなく、「タスクスイッチ」とは
>「なんなのか」を突き詰めて考える事をお勧めします。

以前にも同様のアドバイスを頂きましたね。
ありがとうございます。m(__)m

今現在、実現したいのは、TSSjmpで実現できるタスクスイッチと
ほぼ同様のタスクスイッチです。

904 ：ひげぽん：03/01/11 21:17

>　「タスクスイッチ」をして、結果的に得たい動作は何なのかが分かれば、
>必要な処理が自ずから分かってくると思います。
>答えは、CPU内部の状態変数（それが何なのかは勉強の事）を切り替えるだけ
>です。

そうですね。概要だけは理解できていると思います。
あとは具体的な詳細部分の方法が理解できたらと思います。

>>900
超先生＠OS板さん
>　 ∧＿∧
>＜後ろ頭＞-~~~ ちょっとだけヒント出しておこう。

ヒントありがとうございます。
考えさせていただきます。

905 ：デフォルトの名無しさん：03/01/11 21:40

TASK_SWITCHの話題中、申し訳ないが、、、
INTEL　CPUで考慮しなければならない（整列しなくてもよいが、整列すると効率的なのも含めて）
アライメントについて教えてください。

linuxなどのソースを見ると、
gdtr, idtrのメモリ配置は align 2で奇数ワード整列しています。
tr, ldtrのほうは align 4でダブルワード整列しています。
ここで謎なのが、GDTのディスクリプタ配列がなぜか align 3...
他にも整列したほうがよいデータ構造があれば教えて欲しいです。

906 ：ひげぽん：03/01/11 21:42

>>905
ページテーブルは4Kの倍数にあわせるとか
どこかで読んだような気がします。

907 ：デフォルトの名無しさん：03/01/11 22:24

>>905
gas(as)のalignのパラメータの解釈はシステムによって異なる
その場合align 3はアドレスの下位三ビットが0になるアドレスに整列するという意味
つまりmasmなどのalign 8と等価

908 ：デフォルトの名無しさん：03/01/11 23:52

905です。
>>ひげぽんさん, 907さん
ありがとうございます。

align 3(gas) = align 8(masm)
ですか！驚きました。

ということになると、
idtr, gdtrでのalign 2(gas)
ってのは下位2bitが0ってことで、align 4(masm)と等価？
奇数ワード整列（addr mod 4 = 2)に反する？？

じゃなければ、そこのところはalign 2(gas) = align 2(masm)なのかな。

909 ：LightCone ◆sSJBc30S5w ：03/01/11 23:54

>>904
>あとは具体的な詳細部分の方法が理解できたらと思います。

やろうとしてることは非常に単純です。
旧・新のタスクのレジスタセットを、それぞれ、A1, A2とすると、

「A1 をどこかに保存し、A2 をどこからか復帰させる」・・・(1)

だけです。

保存場所は、考えなければ成りませんし、それが決まっても、たった一行
で書けてしまう(1)ですが、実装はそこそこ複雑になります。

この辺は、知識よりも、思考力が大きいので、アセンブラプログラムに慣れる
ことが一番早道かもしれません。

なお、これ以上のアドバイスは、ほとんどソースをコピーするようなものに
成ってしまいますので、ひげぽんさんのためにならないと思います。

910 ：LightCone ◆sSJBc30S5w ：03/01/12 00:06

　現代的な保護OSでのタスクスイッチは、タスクのメモリ空間をがらっと変えて
しまいます。
　ですが、カーネルのコードは、「変化する部分」に存在させるわけにも
いかないので、共通空間に配置する必要があります。

　このため、メモリ空間の管理がほぼ完全に成るまではタスクスイッチは
出来ないと考えた方がいいと思います。

　まず、タスク切り替え無しで十分な程度に組みあがることを目標に
したほうがいいんじゃないでしょうか。まだ早すぎると思います。

911 ：超先生＠OS板 ◆leaf/RYZgY ：03/01/12 00:24

　 ∧＿∧
＜後ろ頭＞-~~~ i386アーキテクチャについて詳しく載ってる模様。

Interface 1991年7月号
ttp://www.cqpub.co.jp/interface/contents/1991/199107.htm

912 ：LightCone ◆sSJBc30S5w ：03/01/12 00:45

　えーと、参考にならないかもしれませんが、NWSOSでは、タスク切り替えを
実装した時には、シングルタスクOSとしてかなり完成していました。
　今のMonaの様な初期の段階でいきなりタスク切り替えから入っても、開発が
破綻する可能性が高いと思います。理由は上手く説明できませんが、タスク
切り替えは、他の部位との関連性が強すぎるためです。ご参考までに。

913 ：デフォルトの名無しさん：03/01/12 01:05

私は逆に早めにマルチプロセス/スレッドを意識したコードを書いた方が安全だと思います
シングルスレッドで進めすぎると予測しないデッドロックなどで苦労するかもしれません

タスクスイッチの実験が終わったら一時的に外してもいいわけで
今の時点では好きに進めて問題ないでしょう

>>912
>開発が破綻する可能性が高いと思います。
この手のフレーズが好きなんですね

914 ：LightCone ◆sSJBc30S5w ：03/01/12 01:18

>>913
>シングルスレッドで進めすぎると予測しないデッドロックなどで苦労するかもしれません]

それは有り得ますね。

ただし、最初からマルチスレッドで行くと言う事は、それだけ重荷を
背負った状態で開発を進めなくてはならないことでもあり、デバッグ作業
などが大変に成るかもしれませんが。

なお、後からマルチタスク対応にする開発方針でも、セマフォやロックを
追加するだけで、基本的な対応はできると思います。
ファイルシステムの高次元なロックのようなものは別途必要になりますが。

915 ：デフォルトの名無しさん：03/01/12 01:20

仕事じゃないんだから、余暇を有効に活用するためにも
デスマーチを歓迎すべしだな。

916 ：デフォルトの名無しさん：03/01/12 02:09

>>914
重荷になるってのもあるけど、シングルスレッドで開発を進めながらマルチスレッド化を
目指すには、あらかじめマルチスレッドの落とし穴を知ってなきゃならんからな．．．

一回実験的なＯＳを作ってみてマルチスレッド周りでだめになったら作り直すか、
ＯＳの教科書をよく読んで勉強してからつくるか．．．

まぁ、一回失敗してみるのも勉強になるからいいんでない？

917 ：FreeDOS教徒：03/01/12 02:09

超先生！十年前の雑誌出されても泣くしかありません！
ヽ(｀д´)ノｳﾜﾜｧﾝ!!

918 ：デフォルトの名無しさん：03/01/12 02:18

っていうか、ひろゆきの意図に反してＩＰログが流出したらどうすんの？

919 ：LightCone ◆sSJBc30S5w ：03/01/12 02:19

>>916
>一回実験的なＯＳを作ってみてマルチスレッド周りでだめになったら作り直すか、
>ＯＳの教科書をよく読んで勉強してからつくるか．．．

もう一つ、「頭の中で全て予想してから作る」、と言う方法があります。

この方法だと、教科書を読む必要も無く（書いてない場合も多いので）、
試す事も要りません。

920 ：デフォルトの名無しさん：03/01/12 02:22

いととよう

921 ：LightCone ◆sSJBc30S5w ：03/01/12 02:42

>>916
>あらかじめマルチスレッドの落とし穴を知ってなきゃならんからな．．．

マルチタスクやマルチスレッドの環境では、安全性は、純粋な数学的に
「証明」が必要で、実験的な方法で安全性を100%確認することは無理だ
と思うので、どの開発順序をとったとしても、最初から理論的にマルチ
スレッドの落とし穴については十分知っておく必要があると思いますね。

ちなみにデッドロックについては、確実に回避できる方法も良く知られて
います。

922 ：デフォルトの名無しさん：03/01/12 02:44

>>919

>もう一つ、「頭の中で全て予想してから作る」、と言う方法があります。

無理。っていうか、結局試行錯誤になる罠。
マルチスレッドで生じるさまざまな問題については先人たちも試行錯誤を重ねまくって現在に至ってるからな。

923 ：LightCone ◆sSJBc30S5w ：03/01/12 02:48

>>922
>無理。っていうか、結局試行錯誤になる罠。
>マルチスレッドで生じるさまざまな問題については先人たちも試行錯誤を重ねまくって現在に至ってるからな。

「全て予想する」と言うのは、何もプログラムの細部まで予想すると言う意味
ではなく、最小値と最大値をはっきりさせて、その範囲内で絶対なんらかの
解決策が存在する証明を探すような手順を私は取ってます。

具体的な解決策の詳細は、その時点ではわかりませんが、解決策の有無までは
必ず証明を行っています。

924 ：デフォルトの名無しさん：03/01/12 03:07

>>923
証明を探す為には問題がある事を知ってなきゃならないけど、
排他制御の必要性とか、デッドロックの問題とか、
実際に問題が起きてみないと問題自体の存在に気が付かないっしょ。

結局は試行錯誤しながら、問題を見つけて、それを解きながら作るか、
先人たちの研究の成果を教科書で勉強するかしかないんでない？

925 ：LightCone ◆sSJBc30S5w ：03/01/12 03:13

>>924
>排他制御の必要性とか、デッドロックの問題とか、
>実際に問題が起きてみないと問題自体の存在に気が付かないっしょ。

「排他制御の必要性」や「デッドロックする可能性」は、私の場合は、
何の本も読んでもいませんが、あたりまえのように気付きました。

「デッドロックを回避する一般的な方法」については、本で知りました。

思考実験の力が物凄くあれば、「実験」をする必要が無いのでは
ないでしょうか。でも、私もそこまではないので実験しなきゃならない
凡人ですが。

926 ：LightCone ◆sSJBc30S5w ：03/01/12 03:19

>>924
>先人たちの研究の成果を教科書で勉強するかしかないんでない？

個人的には、研究成果も他人のソースもほとんど見てません、、、。

927 ：デフォルトの名無しさん：03/01/12 03:33

>>925

>「排他制御の必要性」や「デッドロックする可能性」は、私の場合は、
>何の本も読んでもいませんが、あたりまえのように気付きました。
すごいな．．．

漏れなんて、ＤＯＳのＴＳＲ組んでたときから、排他制御してなくて暴走したり、
フラグ立てて排他制御したつもりで、テストとセットがアトミックじゃなくて、やっぱり暴走したり、
失敗しまくってたけどな．．．

928 ：デフォルトの名無しさん：03/01/12 04:22

LightConeさんへ
自分がどうだったか自慢するスレじゃありませんよ
どうやって攻めていくかなんて他人が決める事じゃないと思う。
まぁ先人のアドバイスは大事だと思うが。。。

929 ：デフォルトの名無しさん：03/01/12 05:20

>>917
お金払えばコピーとってもらえるって
ttp://www.cqpub.co.jp/hanbai/bnzaiko.htm#copy
にかいてあるよ。

１ページ１００円＋手数料だけどﾅｰ

930 ：デフォルトの名無しさん：03/01/12 09:55

コピペ職人さん帰省しないの？

931 ：FreeDOS教徒：03/01/12 10:08

>>929
全財産\400しかないオイラに一体どうしろとｗ

932 ：ひげぽん：03/01/12 12:19

>>909 LightConeさん

>「A1 をどこかに保存し、A2 をどこからか復帰させる」・・・(1)

はい、イメージはつかめているつもりです。

>この辺は、知識よりも、思考力が大きいので、アセンブラプログラムに慣れる
>ことが一番早道かもしれません。
>なお、これ以上のアドバイスは、ほとんどソースをコピーするようなものに
>成ってしまいますので、ひげぽんさんのためにならないと思います。

ご配慮いただき、ありがとうございます。
この先は自分で考えるべきですね。

>>912
>>913
なるほど、それぞれのご意見はご参考にさせていただきます。

私としては今後のMonaの方針として

ページングを絡ませたタスクスイッチを実現する。
FDCドライバーを完成後、ファイルシステム導入。
プロセスのロード実現へ。
という道筋で考えているため、現段階でマルチプロセス、マルチスレッドを
視野に入れて開発していこうと考えています

933 ：デフォルトの名無しさん：03/01/12 13:05

スレッド管理は、
「カーネルレベルスレッド」より、「ユーザレベルスレッド」
のほうが個人的には好き。高速だし。ユーザの好きなようにできる。
でも、優先度逆転などの問題が起こりうるようなので、超保護モード
でしたいなら不向き。

934 ：デフォルトの名無しさん：03/01/12 13:08

あ、あくまでも意見ですけど、
カーネル空間とユーザ空間をリンクさせて、APIを関数呼び出しに
したら面白そう。RTOSみたいに。
安定するか、しないかはユーザの責任になるけど、
うまく使えば、WINDOWSやLINUXより高速。

935 ：デフォルトの名無しさん：03/01/12 13:19

C++のオブジェクト指向を駆使して信頼性を確保。
そして、カーネルはスレッド型OSとして記述。

いいとこ取りだ（ﾟ∀ﾟ）

936 ：デフォルトの名無しさん：03/01/12 13:47

>>910
> まず、タスク切り替え無しで十分な程度に組みあがることを目標に
> したほうがいいんじゃないでしょうか。まだ早すぎると思います。
L様に同意

>>932
> 現段階でマルチプロセス、マルチスレッドを
> 視野に入れて開発していこうと考えています
そこまで言うんなら止めないけど、
マルチプロセス、マルチスレッドを視野に入れるんだったら、
SMPのことも頭の片隅に入れとかないと片手落ちだ

P4-3GHz以降ハイパースレッディングが標準装備になることからも
今後SMPがごく普通のマシンにも広がる動きがあるからね
常に最新を追いかけろって言ってんじゃなくて、
「開発時には最新」でも「完成時には陳腐」になってるってこと
新しい技術を甘く見ないほうが良い

937 ：デフォルトの名無しさん：03/01/12 14:09

完成は5年後くらいか？

938 ：FreeDOS教徒：03/01/12 14:19

>>936
SMPとか使う人いるの？俺はそっちのほうが不思議。
なんでCPU１コで十分なのに２コも使うの？

939 ：デフォルトの名無しさん：03/01/12 14:27

>>938
ハイパースレッディングの由来を知らないみたいだね
P4はパイプラインが深すぎて常に余剰が出来るから最適化した結果
見かけ上SMPと同じものになったんだよ
2年もすればP4-3GHzなんて陳腐なマシンになるから
重い処理をするソフトではSMP対応が進むと思う
PowerMacなんてクロック数を誤魔化すためにもう全部SMPだし
# BeOSは時代に先んじ過ぎてたんだな～と痛感

940 ：デフォルトの名無しさん：03/01/12 14:33

>>937
その頃にはIA-32は今の286みたいな立場に追い込まれて
メインストリームはIA-64やx86-64に移行しちゃってる予感

まだDOSが主流で386が早い8086としてしか使われていなかった頃、
Linuxがいち早くプロテクトモードを取り入れたことが
現在の繁栄の遠因にもなってることを考えてみ

5年後に完成するんだったら
初めからIA-64やx86-64を視野に入れとかないと
今のNEC98用OSみたいに破棄されたマシンの再利用にしか
使われなくなっちゃうよ（≒誰も使わない）

941 ：デフォルトの名無しさん：03/01/12 14:45

IA-64やx86-64についてはこのコラムが面白い
http://pcweb.mycom.co.jp/column/sopinion.html

最新号はずばりOSの役割について論じられている
http://pcweb.mycom.co.jp/news/2003/01/09/04.html

942 ：超先生＠OS板 ◆leaf/RYZgY ：03/01/12 14:46

　 ∧＿∧
＜　｀ー´＞-~~~ 面白そうなソフトをﾊｹｰﾝ。ソース付。
こういうトリッキーなソフトはしびれるね。

Fritzのマルチタスクモニタ
MS-DOS用16ビット版のマルチタスクスケジューラ
ttp://www.vector.co.jp/soft/dos/util/se191042.html

943 ：デフォルトの名無しさん：03/01/12 15:20

64bitうんぬんの後に16bitというのはﾜﾗﾀ
なら漏れは8bit（ｗ

簡単な対話部分を作るのはそんなに難しいことじゃないよ。
昔のSharpの8bit機みたいなクリーンコンピュータでも
ROMからマシン語モニタくらいは立ち上がって、
そこからプログラムをロードして実行できたからね。
DOS以上にプロセス管理も糞もないが
そのくらい原始的なことなら悩むまでもなくすぐ出来るでしょ。

そうやって不満があったらちょこちょこ直してけば
DOSレベル、Minixレベルとどんどん進歩していける。
近視眼的だがフルタイムじゃないんだし現実的な方法だと思うけどね。

944 ：デフォルトの名無しさん：03/01/12 15:27

>>892
日本語ですごく分かりやすいサイトを見つけますた。
http://a414s1.it.nanzan-u.ac.jp/seminar/OS/3rd/index.html

945 ：FreeDOS教徒：03/01/12 15:39

>>939
説明さんくすです。今さっきちょろっと見て来ましたが、私のトリ頭では
ハイパースレッディングに対応するには何をすればいいのか分かりません（汗
普及する見込みがあるとしたら、参考にする必要はありそうですね。

>>941
レガシーデバイスしか調べてないので、こういう記事は刺激になります。

946 ：ひげぽん：03/01/12 16:18

そろそろ新スレを立てたほうがよいでしょうか。
それとも誰かが立ててくれたりして（笑）

947 ：(・∀・)yossy ◆FlasH.X1/s ：03/01/12 17:45

>>946
そろそろテンプレ作りません？

948 ：ひげぽん：03/01/12 17:52

おっとご意見ありがとうございます。
どんな感じが良いですかね。

949 ：デフォルトの名無しさん：03/01/12 18:05

>ページングを絡ませたタスクスイッチを実現する。

いきなりこれは結構しんどそう。
まずはWinやUNIXのプロセス内で動くマルチスレッドライブラリ
でも書いてマルチタスクの感触を掴むのが良いと思います。

950 ：デフォルトの名無しさん：03/01/12 19:03

新スレはMonaBBSでいいんでない？

951 ：デフォルトの名無しさん：03/01/12 19:29

>>950
2chの方が人が集まりやすくていいと思う。
荒氏がちょっとうざいけど。

952 ：デフォルトの名無しさん：03/01/12 20:33

俺も知りたいから

953 ：デフォルトの名無しさん：03/01/12 20:37

どーして、そーなる！

954 ：950：03/01/12 20:42

ふむふむ。

955 ：デフォルトの名無しさん：03/01/12 20:46

３つのしもべみたいなもんか。

956 ：挫折・・・誰かテンプレ作って・・・：03/01/12 20:56

現在、MonaOSというOSを開発しています。
ttp://mona.sourceforge.jp/

独自にOSを作っているまたは、作ろうとしている人たちのための
スレッドになればと思います。

前スレ
OSをつくろうpart4
http://pc3.2ch.net/test/read.cgi/tech/1037096449/
OSをつくろうpart3
http://pc3.2ch.net/test/read.cgi/tech/1027080631/
OSをつくろうpart2
http://pc3.2ch.net/test/read.cgi/tech/1024411711/

リンク

専用BBS
ttp://monaos.hp.infoseek.co.jp/cgi-bin/2ch/
最新イメージファイル
ttp://mona.sourceforge.jp/Download.html
開発者向け情報 MPDN
ttp://mona.sourceforge.jp/MPDN/index.html
Monaプロジェクトメンバー
ttp://mona.sourceforge.jp/PJM.html

プロジェクトメンバーに加わりたい方
[email protected] へメールを送信！

957 ：これでいいんでない？：03/01/12 21:07

独自にOSを作っているまたは、作ろうとしている人たちのための
スレッドになればと思います。

プロジェクトページ
ttp://mona.sourceforge.jp/

OSをつくろうpart4
http://pc3.2ch.net/test/read.cgi/tech/1037096449/
OSをつくろうpart3
http://pc3.2ch.net/tech/kako/1027/10270/1027080631.html
OSをつくろうpart2
http://pc3.2ch.net/tech/kako/1024/10244/1024411711.html

プロジェクトメンバーになりたい方は、
[email protected] までメールをどうぞ。

最新のイメージファイルは以下のURLから落とせます。
ttp://mona.sourceforge.jp/Download.html

958 ：ひげぽん：03/01/12 21:29

>>956
>>957
ありがとうございます。
今から新スレ作成します。

959 ：ひげぽん：03/01/12 21:32

スレッド作成できなかった。
誰かかわりに立てていただけませんでしょうか。
かぶるとまずいので、作っていただける人は
ここに書き込み後、スレッドを立てるようにお願いいたします。
-----------------------------------------------------------------
独自にOSを作っているまたは、作ろうとしている人たちのための
スレッドになればと思います。

Monaプロジェクトページ
ttp://mona.sourceforge.jp/

OSをつくろうpart4
http://pc3.2ch.net/test/read.cgi/tech/1037096449/
OSをつくろうpart3
http://pc3.2ch.net/tech/kako/1027/10270/1027080631.html
OSをつくろうpart2
http://pc3.2ch.net/tech/kako/1024/10244/1024411711.html

プロジェクトメンバーになりたい方は、
[email protected] までメールをどうぞ。

最新のイメージファイルは以下のURLから落とせます。
ttp://mona.sourceforge.jp/Download.html

ソースファイルの閲覧はここからできます。
ttp://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/mona/mona_v1.0/

960 ：(・∀・)yossy ◆FlasH.X1/s ：03/01/12 21:41

スレッドタイトルはOSを作ろうpart5でつか？

漏れが立ててきます

961 ：ひげぽん：03/01/12 21:42

よろぴくです。

962 ：(・∀・)yossy ◆FlasH.X1/s ：03/01/12 21:45

立ちますた

963 ：(・∀・)yossy ◆FlasH.X1/s ：03/01/12 21:48

ひげぽんさん2Get（ｗ

こちらのスレッドを消費しきってから移動をお願いします>>ALL

964 ：ひげぽん：03/01/12 21:49

>>yossyさん
ありがとうございます。

>>こちらのスレッドを消費しきってから移動をお願いします>>ALL
了解です。2ゲットごめんなさい。

965 ：デフォルトの名無しさん：03/01/12 22:23

いまもってMinix本は最強の教材だと思う今日この頃。
Bochsの上でいじって勉強しようかな。。。