OSを作ろうpart8

このエントリーをはてなブックマークに追加
1Be名無しさん
独自にOSを作っているまたは、作ろうとしている人たちのための
スレッドになればと思います。

OSを作ろうpart8
http://pc2.2ch.net/test/read.cgi/tech/1072232112/
OSを作ろうpart7
http://pc2.2ch.net/tech/kako/1066/10669/1066968321.html
OSを作ろうpart6
http://pc2.2ch.net/tech/kako/1052/10525/1052537020.html
OSを作ろうpart5
http://pc2.2ch.net/tech/kako/1042/10423/1042375466.html
OSをつくろうpart4
http://pc3.2ch.net/tech/kako/1037/10370/1037096449.html
OSをつくろうpart3
http://pc3.2ch.net/tech/kako/1027/10270/1027080631.html
OSをつくろうpart2
http://pc3.2ch.net/tech/kako/1024/10244/1024411711.html
2Be名無しさん:04/02/08 14:06
2ゲットー
3Be名無しさん:04/02/08 15:00
monaもついにプログラミング自体の話からOS設計に軸足が移せるようになったのか。
すげえなぁ。

ブートプログラムの作成とかアセンブラの勉強以前から話が始まったからじゃないかな。
OSを作るにはどんなプログラミング作業が必要なのかわかっていなかった。
OSの設計うんぬんよりもまずガチガチのコーディング作業の道筋を知ること自体が主目的だったみたいな。
part2あたりから見るとわかるかも。

#ちなみに俺もOS作ろうとしてたのにひげぽんにあっさり追い抜かれたクチです
#secondブートあたりまでは勝ってたのに 。゚・(ノД`)・゚。
4ひげぽん ◇Ngzcp/NZpA:04/02/08 15:04
お久しぶりです。今年もよろしくお願いいたします。
私に至らない点がある&説明不足であるために皆様に
ご迷惑をおかけしているようで申し訳ないです。

年始の計画もかねてまとめてみました。

今後のMonaの開発の流れ(1-2月)
1月 Thread対応によるカーネルの大幅リライト(スレッド・ページング・システムコール・共有ページ等)
2月 ドライバインタフェース設計・試験実装&スレッドユーティリティ実装(Mutexなど・・)

今後のMonaの流れと方針
当分の間、ユーザープログラム・アプリケーションでバリバリ遊べるという環境は用意できません。
理由はカーネルがあまりに貧弱だからです。カーネルの設計・実装に時間を注ぎます。

もちろんユーザープログラム・アプリケーションに関するご提案や、カーネルを改良したなどありましたら
是非お寄せください。

またDOSのようにシングルタスクでもいいから遊べるものをというご意見も理解できるのですが
現状の力量ではMona以外に更にプロジェクトを抱えるのは不可能なのでご理解いただけると助かります。
5ひげぽん ◇Ngzcp/NZpA:04/02/08 15:05
Mona PJメンバーについて

Monaには過去在籍したメンバーも含めて以下のような種類の方々がいます。

1.過去にコードを提供して下さったが現在は本業が忙しいためアドバイザーのような立場の方。
2.やる気があり参加したが、即貢献できないので勉強中の方。
3.Wikiでアドバイスをくれる方
4.2だったがフェードアウト気味の方。
5.カーネルにある機能が実装されればすぐに参加できる人(ひげぽん実装待ちの人)
6.行方不明の方。

2, 4, 6あたりの方々へのフォローが足りなかったのはひげぽんの責任であり。
今後のPJ運営の反省材料として生かしていきたいと思います。

今後どのようなメンバーに参加していただきたいか?

カーネルの一部・ドライバを書けるまたは、設計できる。
ハードの仕様に詳しい方。
カーネルの設計にWikiやosdev-jで相談にのっていただける方。

以上、長くなりましたが少しでも誤解がとけてよりよいOSが開発できればと考えています。
6ひげぽん ◇Ngzcp/NZpA:04/02/08 15:08
MonaをDOSのように遊べるOSにするということについては、
Monaはマイクロカーネルのマルチタスクを目指しており
その設計と実装がたのしいということが
OS作りの動機の中核となっていますので難しいです。

※現在Monaはユーザーライブラリ整備に軸足を移しつつあります。
7ひげぽん ◇Ngzcp/NZpA:04/02/08 15:14
今日(※2003.01.06)は以下の作業を行いました。

Mona開発環境@Linuxの作業
 gcc3.2.2のビルド・インストール
 nasmのビルドインストール
 monaのビルドができるようになりました。
 SDLのインストール
 qemuのインストール
 Mona@qemuを実行(Mona Loadingで止まる模様)

Thread対応
 プロセス追加・プロセススケジュールの実装とテスト
 プロセススケジュールは実際のタスクスイッチではないので
 ほぼ実装完了。

明日はスレッドスケジューリングと簡単なスレッドの実行までいければ・・・
8Be名無しさん:04/02/08 15:19
ふむ。qemu一応使えたのか。
9Be名無しさん:04/02/08 15:20
10Be名無しさん:04/02/08 15:20
>>7
ウソダァァァァァァァァァァァァァァァァァァァァァァァィイ!

俺のRHL9ではビルドできないyo.

つーことで、バイナリスナップショットも配布きぼん。
11ひげぽん ◇Ngzcp/NZpA:04/02/08 15:22
>>8
qemuは暇を見てCVS板(FDC対応済み)のものを試してみようと思います。

>>9
> http://mona.sourceforge.jp/トップが全然更新されてないのってあまり感じよくないね。死んでるように思われちゃう
確かにおっしゃる通りですねぇ。最近はリリース毎に更新していたのですが
リリースがなかなか出来ないため滞っています。
これも暇を見て更新いたします。

>>10
> 俺のRHL9ではビルドできないyo.
> つーことで、バイナリスナップショットも配布きぼん。
./configure
make
でいけませんでしたか。
バイナリスナップショットですが現在開発中の物は
カーネルリライト中なので全く動きませんのであまり意味がないかと思います。
12Be名無しさん:04/02/08 15:26
ld -n -Ttext 0xA0000000 -e _user_start -static hello.o userlib.o MemoryManager.o -o ../bin/USER.ELF
ld: warning: cannot find entry symbol _user_start; defaulting to a0000000
userlib.o(.text+0x1f7): In function `__static_initialization_and_destruction_0':
user/userlib.cpp:16: undefined reference to `__dso_handle'
userlib.o(.text+0x203):user/userlib.cpp:16: undefined reference to `__cxa_atexit'
make: *** [../bin/USER.ELF] エラー 1
RHL9
13ひげぽん ◇Ngzcp/NZpA:04/02/08 15:28
>>12
gcc --versionした場合のバージョンを教えていただけないでしょうか。
gcc2.9x系ではビルドできないのでそれが原因かもしれません。
14Be名無しさん:04/02/08 15:30
>>12
Linuxでgccを使った場合、
エントリポイントについては、_user_startの先頭の_がいらないっぽい。
残りは、Kernelソースのpurevirtual.cppの中から、該当関数を持ってきてリンクすれば、一応、通る。
それが、正しく動くUSER.ELFになっているかは知らないけど。

Win上でCygwinやMingwで出したバイナリとLinux上のgccの吐き出すバイナリをそれぞれobjdumpで表示してみると
違いが見れるよ。
15ひげぽん ◇Ngzcp/NZpA:04/02/08 15:30
現在(※2004.01.09)の状況は以下の感じです。
スレッド対応が徐々に進み、少しずつ動作するようになって来ました。
現在MemoryManagerのバグ゙をつぶしています。
ttp://wiki.osdev.info/index.php?%5B%5BScreenShot%2FMona%5D%5D

スレッドの対応をしていて感じた事ですが以前STLをカーネルに
導入していたことがありました。
そのときはカーネルがあまりに貧弱で(今でもそうですが)
特にメモリの割り当て解放の処理が怪しかったためSTLの
使用をなくなく一時中断することを決意しました。

カーネルを書いているといわゆるコレクション(コンテナ?)
が欲しいと思うところがたくさんあります。

ex)
  スレッドのディスパッチキュー
  メッセージキュー
  共有ページ管理
16ひげぽん ◇Ngzcp/NZpA:04/02/08 15:31
その部分について今まで以下のような順で
アプローチを取ってきました。

1.STLのコンテナ
2.BSD系フリーUNIXのqueue.h系(侵入的データ構造)
 Interface 2004 2月号Chapter4参照

3.2の改良版で格納対象のオブジェクトをQueueクラスの
 継承クラスにする方法(場合によっては多重継承になる)

4.自前テンプレートコレクションクラスHList, BinaryTree, HashMap

スレッド対応のついでに3⇒4から移行したのですが
私の感覚からすると実装が少し楽になりました。(実際の処理が早くなるかは別として)

教訓としてカーネルを書くにはいわゆるコレクションライブラリも
整えなければいけないことを痛感しました。

ただし自前コレクションライブラリにはメリット・デメリットがあります。

デメリット
  1.信頼性の問題(STLに比べれば信頼性が低い場合もある)
  2.速度の問題(実際に計ったわけではありませんが)

メリット
  動的にメモリを確保している場合、そのポイントと確保量が明確であること
  STLなどは自分で書いたものでないのでどこでメモリがいくら確保それ解放されるかを
  気にしなければいけない場合もあります。(カーネル内で使用するので)
17ひげぽん ◇Ngzcp/NZpA:04/02/08 15:31
Monaでは1のデメリットに関してはがんばる(笑)、2に関しては今は目をつぶるが
後々すぐに入れ替えれることが出来るように一枚インターフェースをかます方法をとっています。

だらだらと書いてしまいましたが、もしこれからOSを書く方がいれば参考になれば幸いです。
18ひげぽん ◇Ngzcp/NZpA:04/02/08 15:32
現在PIT(Programmable Interval Timer)について調べています。
Monaでもタイマを使用していますが、見よう見まねで実装したので
実際のところきちんとした初期化・設定手順が理解できておりません。

現在スレッド対応にあたり、タイマ割り込みの間隔を任意にカーネルで
簡単に切り替えてスケジューリングのテストを行いたいと考えています。

要は setTimerInterval(int xxxms)のような関数をカーネル起動時に呼び出すイメージです。
現在は下記の資料を読んでいるのですが、なにぶんハードに弱くて苦労しています。
良い資料がありましたら教えていただけると助かります。

ttp://community.osdev.info/index.php?%5B%5B%28PIT%298254%5D%5D
ttp://bookweb.kinokuniya.co.jp/htm/4789834336.html
19Be名無しさん:04/02/08 15:34
20Be名無しさん:04/02/08 15:43
>>16
なぜSTLとAPIコンパチにして後々簡単に入れ替えられるようにしとかないの?
使う機能だけでいいのでクラスと関数の名前を同じにするだけなので別に難しいことではない。
これをやった方が良い理由は2つある。

1つ目は他人が使うときの便宜。
広く知られているものに似ていれば使いやすいのは当然。

2つ目はテストの便。
昔、VC++6.0付属のSTLをバリバリに使いまくってアプリを作ったら、
なぜかメモリリークしまくりでしばらく放置するとスワップが溢れるアプリが出来てしまった。
コードをチェックしてもさっぱり原因が分からなかったんだよ。
ところが同じものをmingwでコンパイルしたらリークしなかった。
どうやらVC++6.0付属のSTLのバグらしい。
そこでSTLportに差し替えてみたところVC++6.0でもリークしなくなった。

つまりUnitTestなどをSTLと独自実装と両方でやることでバグが見付けやすくなる。
これ自体はカーネルと関係ないのでCygwin上だけでも出来ること。
21ひげぽん ◇Ngzcp/NZpA:04/02/08 15:52
>>18
貴重な資料ありがとうございます。
ローカルに保存して目を通します。

またPITに関してはOSASK Kさんからもアドバイスを頂きました。
この場を借りてお礼を申し上げます。

>>20
なるほど。
STLのヘッダをみて各コンテナの定義等を参照するして
あらたに同名クラス・関数を実装するということですね。
手間でなければやる価値があると思いました。
22ひげぽん ◇Ngzcp/NZpA:04/02/08 15:55
・頂いたアドバイスを元にタイマの間隔設定関数を作成しました。
・スレッド化の山場loadProcess(ユーザーモード)が動きました。
・スレッド作成がユーザーモードからも出来るように一部のAPIを作成しました。

ロック機構のみ作成・セキュリティの問題・スレッド操作インターフェースがされていない
など問題は山積みですが以下のようなユーザープログラムUSER.ELFをカーネルから
ロードできるようになりました。
簡単なシェルも作成できるかと思います。(都合上ドライバインタフェースの実装が先になりますが)

#include <userlib.h>

int listener();
int disp();
static char buf[32];
static bool come;

int main()
{
  dword id;

  if (!(id = mthread_create((dword)listener))) {
    print("mthread create error\n");
    exit(-1);
  }

  if (mthread_join(id)) {
    print("mthread join error\n");
    exit(-1);
  }
  disp();
}
23ひげぽん ◇Ngzcp/NZpA:04/02/08 15:59
int disp()
{
  for (;;) {
    if (come) {
      print(buf);
      buf[0] = '0';
      come = false;
    }
  }
}

int listener()
{
  Message message;

  for (;;) {
    if (!_receive(&message)) {
      buf[0] = '<';
      buf[1] = (char)message.arg1;
      buf[2] = '>';
      buf[3] = '\0';
      come = true;
    }
  }
}
24Be名無しさん:04/02/08 16:00
>>23
>if (!_receive(&message)) {
だ・か・ら、message.receive()にしろって。
クラスに属さない関数は作るな。
文字列をchar*で扱うな。
メモリ管理部以外でポインタを配列で使うんじゃねーって。
25ひげぽん ◇Ngzcp/NZpA:04/02/08 16:03
>>24
現在のAPIはサンプル実装です。
スレッドがカーネルに実装された一例として急遽作ったものなので
インターフェースが洗練されていないのはご了承ください。
ユーザー側に公開するAPIをどうやってオブジェクト指向で提供するかは
今後
ttp://mona.sourceforge.jp/dynamic/pukiwiki/pukiwiki/pukiwiki.php?%B5%C4%CF%C0%2Fuserlib%2Fmonalibc
で検討していきます。
ご意見がありましたら上記にお寄せいただけると助かります。
26508:04/02/08 16:12
ソース眺めてて気付いたんだけど、これっておかしくない?

void ProcessManager::wakeup()
{
  dword tick = getTick();

  for (dword i = 0; i < waitList_->size(); i++) {
    Process* process = waitList_->get(i);
    if (process->getWakeupTimer() < tick) {
      dispatchList_->add(process);
      waitList_->remove(process);
    }
  }
}
27508:04/02/08 16:13
気になるところは大体読んでみた。
取り敢えず言いたいのは「まずは定石を学ぶべき」という事。
ソース奇麗でスジは良いと思うけど、とにかくカーネルの設計・実装におけるセオリーを知らなさ過ぎる。
そのくせマイクロカーネルだとかスレッドだとかいうのは無茶過ぎる。
今からでも遅くないから他のカーネルを勉強してみるのをオススメします。マジで。
28ひげぽん ◇Ngzcp/NZpA:04/02/08 16:16
>>26
> ソース眺めてて気付いたんだけど、これっておかしくない?
実装ほやほやでテストも満足に出来ていなくて申し訳ないのですが
どこがおかしいでしょうか?

>>27
> そのくせマイクロカーネルだとかスレッドだとかいうのは無茶過ぎる。
> 今からでも遅くないから他のカーネルを勉強してみるのをオススメします。マジで。
貴重なご意見ありがとうございます。
具体的にどのような点で上記強く感じられましたでしょうか?
29Be名無しさん:04/02/08 16:17
>>27
セオリー通り作れば確かに変なところで躓いたりしないが、それで面白いか?
他のヤシはどう思うかわからんが、漏れはつまらん。

一般には成功している流行の手法に、基づいているのだから、
一方的にそれを認めないのはいかがなものか?
実際ソースが読みやすいという部分はこれのお陰だしな。
30508:04/02/08 16:29
>>28
> どこがおかしいでしょうか?
waitListに入っている全てのプロセスについて起床すべきかどうかを調べて、
起床すべきであればwaitListから削除することを意図したコードだろうけど、
あるプロセスがwaitListから削除されたとき、
waitListでそのプロセスの次に入っていたプロセスはとばされる事に成ると思われ。

> 具体的にどのような点で上記強く感じられましたでしょうか?
例えばシステムコールが割り込み禁止で実行されてころとか。

>>29
セオリーを押さえた上で独自の工夫をするのが面白いと思うんだが。
31ひげぽん ◇Ngzcp/NZpA:04/02/08 16:34
>>30
> waitListでそのプロセスの次に入っていたプロセスはとばされる事に成ると思われ。
ああやっちゃってました。申し訳ないです。
完全なバグですね。ありがとうございます。
ループを逆回りすればよさそうですね。

> > 具体的にどのような点で上記強く感じられましたでしょうか?
> 例えばシステムコールが割り込み禁止で実行されてころとか。
システムコール詳細仕様が決まっていないので現在は行われていません。
(どこで割り込みを許可するかの検討がまだ行われておりません)
ttp://mona.sourceforge.jp/dynamic/pukiwiki/pukiwiki/pukiwiki.php?%B5%C4%CF%C0%2F%A5%B7%A5%B9%A5%C6%A5%E0%A5%B3%A1%BC%A5%EB%BB%FE%A4%CB%B3%E4%A4%EA%B9%FE%A4%DF%A4%F2%B5%F6%B2%C4%A4%B9%A4%EB

ただし上記のように検討は済ませてあり、実験がうまくいっているので
技術的には可能です。
32508:04/02/08 16:35
>>31
上記のページを見た感想ですが、
カーネル内における同期の方法などもっと検討しなければいけないのではないでしょうか。
例えばいまのところ見た感じカーネルはプリエンプト可能のようですが、
カーネル内のデータ構造をどうやって保護するのかとか。
それと、タイマ割り込み以外でもプロセススイッチが起こる方が自然です
(今のところビジーウェイトで同期を取っているようですが)。
割り込みとシステムコールの同期も大きな問題です。
こういうところはカーネルの根幹ですから、
もうすこし検証を重ねる必要があると思います。
そのためにももう少し定石を学んでみるのも良いのでは?とわたしなどは思ってしまうわけです。
現状楽しんでやっているのであれば、とやかく言う事でもないのですが、
定石がわかればもっと楽しくなるかも、という可能性もちょっと考えていただければ幸いです。
33ひげぽん ◇Ngzcp/NZpA:04/02/08 16:37
>>32
> こういうところはカーネルの根幹ですから、
> もうすこし検証を重ねる必要があると思います
全く持っておっしゃるとおりです。
うすうす気づいていたのですがずばり指摘されて
重大さに気づいた次第です。(特にカーネルデータ構造保護)

> そのためにももう少し定石を学んでみるのも良いのでは?とわたしなどは思ってしまうわけです。
> 現状楽しんでやっているのであれば、とやかく言う事でもないのですが、
> 定石がわかればもっと楽しくなるかも、という可能性もちょっと考えていただければ幸いです。
カーネル(しょぼいですが)を作っているものとして508さんのOS関係の知識・経験が
私よりはるかに勝っていることは頂いたアドバイスの内容からも感じられました。
そういった方からのアドバイスは大変貴重で非常に参考になります。
本当にありがとうございます。

実際問題、定石はどのように学ぶかが最近の悩みどころであったりします。
ここ1年ほどは他のOSのソースをほとんど見ないように心がけていました。

どうしても読んだソースと似たようなものしか書けなくなるからです。
(一度方法を知ってしまうと自分で考えなくなる性格のようです。)

ソースを見ない代わりにAPIドキュメント等を読んで中身の実装は自分で
考えるなどしています。

508さんは定石はどのように学ばれたのでしょうか?
ソースを読む?実際にOSを作る等。
34Be名無しさん:04/02/08 16:39
MIT/X採用は偉いけど、こういうときに困るね。
35Be名無しさん:04/02/08 16:42
>>33-34
必ずしもソースを見る必要はないです。
OS関連に限ったことではないですが、機能的にどのように変わっているかを把握することがポイントかと。
めったに変わらない部分、すぐに変わる部分。その理由。

チューニングなど、実装的な面だとソースを読む事も必要かもしれませんけどね。
36ひげぽん ◇Ngzcp/NZpA:04/02/08 16:43
>>35
> 必ずしもソースを見る必要はないです。
ソース以外ではどのような情報源で情報を取得されていらっしゃるのでしょうか?

実際にそのOSを使ってみてプログラマの立場(APIを使うものの立場)からみる。

OSの設計の書籍(ex Solarisインターナル)や、Webで公開されているドキュメントでしょうか。
37Be名無しさん:04/02/08 16:44
MINIX本とか。
古いかな…
38Be名無しさん:04/02/08 16:44
Webで見つけるなら、論文やプロジェクトの成果報告、公開仕様書など
大学系のものがころがってる。ほとんど英語だけど。
ぐぐるなら、filetype:pdf をつけると、結構みつけやすい。世の中便利になったものだ。
39ひげぽん ◇Ngzcp/NZpA:04/02/08 16:45
>>37
MINIX本は基礎的なことを学ぶのに役立ちました。
排他とかページングアルゴリズムとか。

>>38
filetype:pdfは知りませんでした。
ありがとうございます。
日本語の研究成果資料なら多少読んだことがあります。
40508:04/02/08 16:46
>>33
わたしの場合は、本とソース読みと自作が平行していました。
本やLinuxや*BSDのソースから得られた知識を自作カーネルで試してみたり、
カーネルを自作する過程で出てきた疑問点を本やソースで解消したりといった感じでした。

ソースを見る事によって影響されてしまうのを心配していらっしゃるようですが、
個人的にはそれほど心配する事も無いように思います。
私の習作カーネルの場合、もちろん細かいところで似てしまう事も多々ありましたが、
ソースの雰囲気や具体的なアルゴリズム、全体としてのアーキテクチャ(無謀にもマイクロカーネル風!!)などは、
参考にしたLinuxや*BSDとは似ても似つかないものとなり、
十分独自色が出ていたと思っています。

ま、どうするかは最終的には個人の問題ですけどね。
ひげぽんさんにとって一番良い方法を見つけて、
それで楽しくプログラミングできるのが一番ですから。
41ひげぽん ◇Ngzcp/NZpA:04/02/08 16:52
現在VESA調査中です。
mode105hで動作確認をしているのですが
VirtualPCで画面切り替えまではうまくいくのですが
その後VRAMアクセスしても画面に何も描画されません。
手持ちの実機2台、bochs、VMWAREでは描画されます。

VESAの手順等に自信がないためよい資料・サイト等ありましたらご教授いただけると幸いです。
なお使用している資料は
ぐりぽんさんの翻訳資料などです

詳細はこちら
ttp://mona.sourceforge.jp/dynamic/pukiwiki/pukiwiki/pukiwiki.php?%B5%C4%CF%C0%2FVESA%C2%D0%B1%FE
42Be名無しさん:04/02/08 16:53
>>41
パレットの設定を I/O で叩くのではなくて、プロテクトモードインターフェースを使用したらどうだろうか?
43ひげぽん ◇Ngzcp/NZpA:04/02/08 16:54
>>42
ありがとうございます。
現在プロテクトモードインターフェース勉強中です。
vbe3.pdfやVBE2.0の資料を斜め読みましたが
コードがないとつらいですねぇ。
44ひげぽん ◇Ngzcp/NZpA:04/02/08 17:00
VESAのリニアフレームバッファが使用できる見込みがついたので(VPCはまだ)
bitbltを実装してみました。

いろいろ探したのですがbitblt関数のI/F例は見つかるのですが
実装例が1つもなかったので無理やり自分で考えて実装しました。

速度が多少速くなるように悪あがきをしましたが
所詮描画系は門外漢なのでよしあしが分かりません。

ちなみに悪あがきは
inline関数を使う。
メンバ変数をループに使わない(Auto変数で)

などでアルゴリズムとかでなし・・・

ttp://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/mona/mona_v1.0/src/test_higepon.cpp?rev=1.90&content-type=text/vnd.viewcvs-markup

ユーザー側に公開するときはbitbltの引数はScreenではなくScreenHandleとするべきでしょうね。
ポインタを公開するわけにも行かないので。

相変わらずプロテクトモードインターフェースの資料が見つからないですねぇ。
45Be名無しさん:04/02/08 17:00
>>44
> 相変わらずプロテクトモードインターフェースの資料が見つからないですねぇ。
Linux kernel ソースのdrivers/video/vesafb.c が参考にならんか?
46ひげぽん ◇Ngzcp/NZpA:04/02/08 17:01
>>45
ありがとうございます。
まだ少ししか読んでみていないですがどうやらそれっぽいですね。
1歩進みました。ありがとうございます。
47ひげぽん ◇Ngzcp/NZpA:04/02/08 17:04
800 * 600の画面サイズに対応したり、jpegが表示できたりといろいろと
有志の方のコードに大変助かっています。
そろそろユーザー側APIの整備をしなくてはならないと考えています。

割とカーネル側に機能が追加されてきているのに対して
ユーザーアプリがそれを使うことが出来ないのは無駄なので。

ただこれはドライバインターフェースにも関わるところなので
設計が難しいですねぇ
48ひげぽん ◇Ngzcp/NZpA:04/02/08 17:04
ユーザーアプリ環境構築・ドライバインターフェースの検討の第一弾として
キーボードドライバのユーザーモードへの追い出しをしています。

キーボードドライバの役割はキーのscancodeを実際のキー情報に分解して
キー情報を欲しがっているプロセスにそれを送信するイメージです。
(キー情報を扱うサーバのようなイメージ)

処理事態はカーネルモードでなくても動くものなので追い出しは割りと簡単かと
ふんでいましたが。そうでもないようです。。。

以下困ったこと
(1)KeyBoardManagerのメンバ変数(キー情報配列) const int []が初期化されて
いなかった。本来であれば'a' 'b'などが入るべきなのに全部ゼロだった。
   ⇒
elfローダーでelfセクションのmemory上のサイズとファイル上のサイズが
等しくないものはゼロクリアすべきと思っていてその領域をゼロクリア
していたのが原因???

(2)keyInfoList_->add(kinfo);時にNULLポインタアクセスを起こす。
   ⇒原因調査中。

簡単な「hello world」よりも少し複雑になっただけで潜在的な
バグが見えてきました。どうもELFローダー周りが怪しいです。
49ひげぽん ◇Ngzcp/NZpA:04/02/08 17:05
キーボードドライバのユーザーモードへの追い出しが成功しました。
キーボードサーバの機能をもう少し洗練する必要がありますが
ひとまず動きました!!

原因:elfプログラムセクションのmemorySizeとfileSizeが異なる場合に

(誤)その領域をmemorySize分ゼロクリアしていた(bssセクション)
(正)memorySizeがゼロ以上のときはメモリにロードする
50ひげぽん ◇Ngzcp/NZpA:04/02/08 17:07
キーボードサーバーはユーザープログラム開発環境でコンパイル・リンクされます。
/src/user/KeyBoardServer.cppがソースファイルになります。

その後makeとすると。
/bin/KEYBDMNG.SVRというELF形式の実行ファイルが作成されます。

こいつを
/tools/fat_write.exeで
mona.imgに書き込みます。詳細は/src/Makefile参照

こいつをカーネルのどこかから。
loadProcess(".", "KEYBDMNG.SVR", true);
3つ目の引数=trueだとユーザーモードプロセスになります。

として読み込むとサーバーが起動されます。

以下キーボードサーバーのソースを張ります。
長くなりますが現在のMonaでどの程度のプログラムなら
動くかという参考になれば幸いです。
51ひげぽん ◇Ngzcp/NZpA:04/02/08 17:08
int main()
{
  /* initilize KeyBoardManager */
  KeyBoardManager* manager = new KeyBoardManager();
  manager->init();

  /* initilize destination list */
  List<char*>* destList = new HList<char*>();

  /* Message loop */
  for (;;) {
    MessageInfo info;

    /* receive */
    if (!Message::receive(&info)) {
      switch(info.header) {
      case MSG_KEY_SCANCODE:
        sendKeyInformation(manager, destList, &info);
        break;

      case MSG_KEY_REGIST_TO_SERVER:
        regist(destList, &info);
        break;

      default:
        /* igonore this message */
        break;
      }
    }
  }
}
52ひげぽん ◇Ngzcp/NZpA:04/02/08 17:09
int sendKeyInformation(KeyBoardManager* manager, List<char*>* destList, MessageInfo* info)
{
  MessageInfo message;
  KeyInfo keyinfo;

  /* scan code to key information */
  byte scancode = info->arg1;
  manager->setKeyScanCode(scancode);
  manager->getKeyInfo(&keyinfo);

  /* create message */
  memset(&message, 0, sizeof(MessageInfo));
  message.arg1 = keyinfo.keycode;
  message.arg2 = keyinfo.modifiers;

  /* send message */
  for (int i = destList->size() - 1; i >= 0; i--) {
    if (Message::send(destList->get(i), &message)) {
      printf("send error to %s", destList->get(i));
      destList->removeAt(i);
    }
  }

  return 0;
}
53ひげぽん ◇Ngzcp/NZpA:04/02/08 17:10
int regist(List<char*>* destList, MessageInfo* info)
{
  char* source = (char*)(info->arg1);
  printf("message is %s", source);
  char* target = new char[strlen(source) + 1];
  strcpy(target, source);
  destList->add(target);
  return 0;
}

ただこれを書いていて前から気になっていたことが
やはりまずいことが分かりました。
sendのあて先はchar*だと全然ダメです。
やはりポートがよいですかね。
54ひげぽん ◇Ngzcp/NZpA:04/02/08 17:11
>>53
プロセス名からpidをlookupするサービスを作って解決しました。

ユーザーモード用に描画の仕組みを用意しました。
APIはC++で用意されていて、cygwinがインストールされていれば
プログラミングが可能です。

今現在下記のようなプログラムが実際にディスクから読み込まれ
動作しています。
Screen screen;
printf("user mode screen (x, y) = (%x, %x)\n", screen.getXResolution(), screen.getYResolution());
printf("you can draw from user mode!! and also use multi thread \n");

word color = Color::bpp24to565(Color::rgb(0x7A, 0x7A, 0xC4));

screen.fillRect16(0, 200, 800, 400, color);

color = Color::bpp24to565(Color::rgb(0x63, 0x63, 0x9F));

for (int x = 0; x < screen.getXResolution(); x++) {
screen.putPixel16(x, 0.5 * x + 300, color);
}
55ひげぽん ◇Ngzcp/NZpA:04/02/08 17:12
Monaで動作するプログラムを作成するには以下の手順をふみます。
※サンプルプログラムは(mona_v1.0/src/user/ディレクトリにあります。)

(1)C++でプログラムのソースを書きます。必ずuserlib.hというヘッダファイルをincludeしてください。
  printf, Screen::putPixel16, fillRect16や。スレッド作成・メッセージsend/receive,string.h系
  どんどん増えています。

(2) MakeFileに自分の書いたプログラムを追加してあげます。
user/MakeFile
hello.cpp用の記述を真似するとよいでしょう。

(3) makeとするとコンパイル・リンクが行われます。

(4) 成功するとELF形式のファイル(Monaでそのまま実行可能)が作成されます。
56ひげぽん ◇Ngzcp/NZpA:04/02/08 17:13
簡易シェルを実装しました。
コマンドラインでコマンドを受け付けて
FDのFAT12からELF形式のファイルを読み込んで実行することが出来ます。

このシェルからJPEG表示プロセス(ユーザーモード)を実行することに
成功しました。

なおMonaのブート後以下のようにプロセスがカーネルでロードされます。

ブート
ビデオモード切替
プロテクトモード移行
キーボードサーバ起動(ユーザーモード):キーボード割込み後の処理・仮想キーコード送信
シェルサーバ起動(ユーザーモード):コマンド受付・プロセス生成

関連ソースは
mona_v1.0/src/user/ShellServer.cpp
mona_v1.0/src/user/KeyBoardServer.cpp
mona_v1.0/src/user/hello.cpp
mona_v1.0/src/user/jpegdemo.cpp

ユーザーモードではScreenクラスを使用することにより
VRAMのアドレスを取得することが出来ます。

またキーボードサーバに自分自身のプロセスを登録することにより
キー情報を取得できます。

がんばればゲームが動きそうですね。
(その前にカーネルのバグをつぶさなければなりませんが)
57Be名無しさん:04/02/08 17:13
おめ。
もう「起動するだけ」とは言わせないw

ageとこ。
58ひげぽん ◇Ngzcp/NZpA:04/02/08 17:23
>>57
ありがとうございます。
簡易シェルはBSキーがきかない、プロセスを非同期で起動するので
表示位置がおかしい。
すぐ落ちる(Access Deniedなど)
バグがいっぱいなので徐々に改善していきます。
59Be名無しさん:04/02/08 17:24
MONAで遊べば
シェルもあるしファイルも読める絵も出せるしJPEGも表示できる。
キー入力も取得できるようだし。
簡単なゲームや、スクリプトエンジンなら動くと思う。
60Be名無しさん:04/02/08 17:27
最近進むの早くない?
爆発傾向?
61Be名無しさん:04/02/08 17:29
いあ。前からこんなペースだろ。
ユーザ側に実装が踏み込んできただけ。
62Be名無しさん:04/02/08 17:29
しかし一時期からここいらの人口は増えんなあ。
monaとかmegの最近の動きから人が増えると面白いんだが。
6360:04/02/08 17:30
>>61
そうか。
地味なところの作業が終わって派手さが出てきた感じかな。
もう少ししたら触ってみようかな。
64Be名無しさん:04/02/08 17:30
おお、さっそく増えそうだ。
6561:04/02/08 17:32
>>63
いや。どうかなぁ。
とりあえず、機能を提供して、ライブラリで上と区切った後に
また下側を直し始めるぽいからなぁ。派手さ、は微妙。
6660:04/02/08 17:33
>>65
サンクス
一通りそろってきた感じに思えて遊べそうかな。
派手さはmegの方があるからね。
67Be名無しさん:04/02/08 17:33
あまりの荒れようで、このスレもう終わりかと心配してました。
久しぶりに活気が出てきて嬉しい限りです。
ひげぽんガンガレ!
68ひげぽん ◇Ngzcp/NZpA:04/02/08 17:35
>>67
ありがとうございます。

今日(※2004.02.06)はマウスドライバを書いていました。
マウスの初期化と、マウス割込み、座標の取得らしきものが
出来ました。

ユーザ−モードでのアクセス違反調査中。
69Be名無しさん:04/02/08 18:00
なんだここ
70Be名無しさん:04/02/08 18:03
マウスサポートということはいよいよGUIかな。
最近進歩がめざましいな。
71ひげぽん ◇Ngzcp/NZpA:04/02/08 18:05
マウスドライバがほぼ完成しました。
割込みとI/O以外はユーザーモードで処理して
ユーザーモードのプロセスがメッセージングによって情報を受けて
座標計算とマウスカーソルの描画(今は■)を行うことが出来ました。

ただ懸念点があってマウス情報の1, 2, 3byte目のうちのどれかが
割込み禁止などで通知が欠けてずれる可能性があるということです。

某ななしさん情報だと1byte目は特定パターンのデータしか来ないので
byte & 0xC8 == 0x08というチェックを入れて
これを1byte目とすればとのことでした。

他のOSはどうしているんだろう?
72Be名無しさん:04/02/08 18:06
マウスデータを取りこぼす程の長時間割り込みを禁止する方が問題ではないかと。
73ひげぽん ◇Ngzcp/NZpA:04/02/08 18:06
>>72
ご返答ありがとうございます。
おっしゃるとおり長時間割込み禁止するのは問題外です。

Monaでは今のところマウスの割り込みの取りこぼしは一度も発生していません。
システムコール中も基本的には割込み禁止ではないので。

ただ可能性としては取りこぼすことも考えられるので
どのようにチェックをすべきかを悩んでいる状態です。
74Be名無しさん:04/02/08 18:08
サルベージ完了あげ
75Be名無しさん:04/02/08 18:08
コピペ大杉。
76Be名無しさん:04/02/08 18:11
>>75
サルベージです。ご容赦ください。
77Be名無しさん:04/02/08 20:04
皇位継承記念あげ
78Be名無しさん:04/02/08 20:12
>>76
乙カレ
79Be名無しさん:04/02/08 20:38
でMonaとやらはどこから取ってこれるんだ?
80Be名無しさん:04/02/08 20:45
・Mona PJ wiki 開発議論の中心
http://mona.sourceforge.jp/dynamic/pukiwiki/pukiwiki/pukiwiki.php?FrontPage

・公式サイト 情報鮮度がWikiよりは落ちる
http://mona.sourceforge.jp/

・今までのリリース
https://sourceforge.jp/projects/mona/files/

・CVSより最新のソースをダウンロード
http://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/mona/mona_v1.0/mona_v1.0.tar.gz?tarball=1
./configure
make

・Monacrosoft
http://mona.s31.xrea.com:8080/modules/news/

・osdev-j
http://wiki.osdev.info/index.php
81Be名無しさん:04/02/08 21:27
>>73
ハードからの割り込みでは割り込み禁止にはせずに、
基本的にドライバのI/O部分ではキューの操作しかせずデータの解釈などは行わない。
マウスの場合はマウスサーバ(gpmdみたいなやつ)がデータを解釈する。
キューが変更されたかどうかは通知する必要があるが、
その部分は割り込みに対するクリティカルセクションではない。

マウスサーバがポインタの描画までする必要はない。
座標を描画サーバ(Xみたいなやつ)に通知するだけ。
描画サーバにマウスサーバの描画オブジェクトを登録しておいて
実際の描画処理を返させても構わない。

これらは全部、取りこぼしがないように非同期に処理するための工夫。
82ひげぽん ◆Ngzcp/NZpA :04/02/08 21:40
>>81
ありがとうございます。
現在のMonaでは
マウス割込み処理でI/O。生の情報をユーザーモードのサーバーに
送信後終了。

サーバー側でデータの解釈・ついでにカーソル描画をしています。

> 描画サーバにマウスサーバの描画オブジェクトを登録しておいて
> 描画処理を返させても構わない。

描画サーバはそろそろ検討しないといけないですね。
Xとやらがどういう仕組みなのかがよく分かっていないです・・・
83Be名無しさん:04/02/08 21:41
> monaApp = new myApplication("HELLO.ELF");
つなぎだろうけどこれはまずいね。
pidを取るための苦肉の策なのは分かるけど。

WindowsではWinMainの引数としてHINSTANCE(pid相当)が渡される。
そういう変態的な特殊起動関数を避けたいという考えものあるだろうけど、
その辺は工夫でどうにでもなるから無問題。
WindowsでもWinMainではなくmainからGUIを起動させるコードを書ける。
84ひげぽん ◆Ngzcp/NZpA :04/02/08 21:45
>>83
> > monaApp = new myApplication("HELLO.ELF");
> つなぎだろうけどこれはまずいね。
> pidを取るための苦肉の策なのは分かるけど。

そうですね。おっしゃるとおりメッセージループに必要なpidを
取得するための仕組みです。

>WindowsではWinMainの引数としてHINSTANCE(pid相当)が渡される。

おっと。これは知りませんでした。いやあ勉強になります。
mainにargc, argv, envpを渡す計画は立てているのですが
そことの両立が微妙ですね。

やはりWinMain相当関数の引数にセットするのが自然でしょうか?
BeOS・OSASKとかはどうなっているのでしょうね。
85Be名無しさん:04/02/08 21:50
>>82
マウスならいいけどLANのパケットとかデータ量が膨大なものを統一的に扱うなら
データを送信までしてしまうモデルはまずい。
ドライバではひたすらキューにだけ溜める。
サーバに対してはキューが変更されたことだけを通知して、
サーバの側でアイドル時にキューを読むようにする。
当然キュー操作はクリティカルセクションだけど、
MutexにWaitForMultipleObject的な機能を追加すると簡単になる。
リエントラントを意識するとデッドロックになりがちで難しいけど、
乗り越えないといけない壁だからね。
86ひげぽん ◆Ngzcp/NZpA :04/02/08 22:08
>>85さん
早速、目から鱗です。
> ドライバではひたすらキューにだけ溜める。
> サーバに対してはキューが変更されたことだけを通知して、
> サーバの側でアイドル時にキューを読むようにする。

なるほどこういう方法もあるのですね。
サーバーとドライバの仲立ちにキューが入ると。
キューの仕組み自体はカーネルにあるので
完全なユーザープロセス(サーバー)からキューアクセスできれば
実現できそうですね。

> 当然キュー操作はクリティカルセクションだけど、
> MutexにWaitForMultipleObject的な機能を追加すると簡単になる。
> リエントラントを意識するとデッドロックになりがちで難しいけど、
> 乗り越えないといけない壁だからね。

この辺が難しいですね。キュー操作に時間がかかっては
意味がないですし。
87Be名無しさん:04/02/08 22:12
>>84
UNIXのような引数のないgetpid()の実装を考えるしかないでしょう。

> WindowsでもWinMainではなくmainからGUIを起動させるコードを書ける。
というケースでも、GetModuleHandle(NULL)がgetpid()相当の働きをする。

Xの場合はインスタンスはpidで管理されているわけではなく、
XOpenDisplay()として取得したDisplay*で弁別している。
イベント処理も↓のような感じ。
Display* display = XOpenDisplay(NULL);
XEvent e;
XNextEvent(*mDisplay, &e);
つまりXの側で管理しています。
8887:04/02/08 22:18
すみません。昔書いた適当なコードから抜粋したので間違っていました。
誤:XNextEvent(*mDisplay, &e);
正:XNextEvent(display, &e);
89Be名無しさん:04/02/08 22:25
>>81
いやー禁止するべきでしょう。
PICの操作があるし。プリエンプションといっても限度がありまつ。

>>86
読み書きポインタの管理はアトミック性無くてもなんとかなります。
データの残量はアトミックに管理しないとえらい事になりますが。
90Be名無しさん:04/02/08 22:42
>>89
> いやー禁止するべきでしょう。
誤解を招く書き方をしてすみません。
すべての処理で一切禁止しないというように読めてしまいますね。
マウスデータの処理までの一連の流れすべてで、というつもりでした。
91ひげぽん ◆Ngzcp/NZpA :04/02/08 23:01
>>87さん

> UNIXのような引数のないgetpid()の実装を考えるしかないでしょう。

早速頂きました。実装します。
気づかなかったです(´ヘ`;)

> > WindowsでもWinMainではなくmainからGUIを起動させるコードを書ける。
> というケースでも、GetModuleHandle(NULL)がgetpid()相当の働きをする。

Windowsであまりプログラムしたことないので知りませんでした。
ありがとうございます。

> XOpenDisplay()として取得したDisplay*で弁別している。
> イベント処理も↓のような感じ。

イメージとしてはpidの場合と一緒ですね。
一意となるキー(ハンドル)基準の操作ということですね。

>>89さん
> 読み書きポインタの管理はアトミック性無くてもなんとかなります。
> データの残量はアトミックに管理しないとえらい事になりますが。

このへんはご自身の経験からの発言と見受けられますが
どのようにして何とかされたのでしょうか?
92Be名無しさん:04/02/08 23:05
カーネル内でsprintfが必要な状況って例えばどんな場合ですか?
文字列クラスは重過ぎるので避けるということであれば、
長さ管理に関してはPASCAL文字列を使った方が良いかもしれません。

[例] "A"
C 文字列 "ABC": 41424300
Pascal 文字列 "\pABC": 03414243

同様に文字列以外の配列でも範囲チェックできます。
template <class t> struct Array
{
  int length;
  t* data;
}

安全性確保のため常に長さをつきまとわせるというだけですが、
Cの関数でも配列と長さを引数で渡すケースは多いのでセットにしてしまうわけです。
9392:04/02/08 23:07
すみません。
> [例] "A"
の"A"は無視してください。
9492:04/02/08 23:10
あと補足ですが、>>92のArrayはlistやvectorのような可変長のものではなく、
普通のchar[]とかint[]のような固定長のものを念頭に置いています。
可変長である必要がないものまでlistやvectorで扱うとオーバーヘッドが大きいので。
95ひげぽん ◆Ngzcp/NZpA :04/02/08 23:31
>>92さん

>カーネル内でsprintfが必要な状況って例えばどんな場合ですか?

あれば便利という感じです。
必須ではないですね。

カーネル内でも簡単な文字列処理をしたいことがあるので。

> 長さ管理に関してはPASCAL文字列を使った方が良いかもしれません。

文字列長と文字列を同じ配列に入れるところがみそでしょうか?
初めてしりました。ありがとうございます。
こういうノウハウはなかなか貴重ですね。
96Be名無しさん:04/02/08 23:49
97Be名無しさん:04/02/08 23:54
>>95
> カーネル内でも簡単な文字列処理をしたいことがあるので。
そのケースに興味があるわけです。

あと受け流されているArray<>の部分は極めて重要な部分です。
バッファ溢れはどんな一流の人が書いたコードでも根絶できない厄介な問題なので、
すべての配列を>>92のArrayのようなもので扱うのはかなり有用な方法です。
コンストラクタや[]を定義して、
int* nums = (int*)malloc(sizeof(int) * 3);
nums[0] = 1;
 ↓
Array<int> nums(3);
nums[0] = 1;
みたいな感じで。面倒かもしれませんがお勧めしておきます。
listやvectorと違って固定長であるのがミソです。

毎回毎回範囲チェックすると遅くなりそうですが、
#ifdefでDEBUGか否かでチェックする・しないを決めて、
DEBUGが定義されていないときの[]のオーバーロードをinlineにすれば
実質オーバーヘッドはないわけです。

配列溢れでは例外が補足しきれないことが多いので、
なぜか挙動がおかしい……と悩むことが多いのですが、
DEBUGを有効にしたものでチェックすれば一発で見つかるわけです。
以前、アプリですが、CからManaged C++に移植してバグに気付いたことがあります。

> 文字列長と文字列を同じ配列に入れるところがみそでしょうか?
ただ256文字に制限されてしまうので、Array<char>の方が実用的ではありますが。
98ひげぽん ◆Ngzcp/NZpA :04/02/09 00:08
87さんから頂いたPID取得ロジックを組み込みました。
System::getPID();
今日はマウスドライバ・サーバーの実装がひと段落しました。
bochsでカーソルが遅いのが気になりますね。
原因として考えられるのは
・send/receiveのオーバーヘッド
・スレッドスケジューリングの問題。
 描画に時間がかかりすぎる?
 タイマ割り込みが実機と違う?
 マウスサーバは優先順位を高くしないとダメ?
・bochsはそういうもの。
>> 97
>> カーネル内でも簡単な文字列処理をしたいことがあるので。
> そのケースに興味があるわけです。
デバッグ出力とかですね。fault・error時に人間にとって
見やすい情報を出力できればよいです。

> Array<int> nums(3);
> nums[0] = 1;
> みたいな感じで。面倒かもしれませんがお勧めしておきます。

ふむ。なるほどだいぶイメージがわいてきました。

> #ifdefでDEBUGか否かでチェックする・しないを決めて、
> DEBUGが定義されていないときの[]のオーバーロードをinlineにすれば
> 実質オーバーヘッドはないわけです。

うぅ。うまいなぁ。これはすごい。
こういうテクニックはプロの仕事ですねぇ。
すばらしいの一言。
レベル高い。
まねします。。
99Be名無しさん:04/02/09 00:16
マジプロジェクトなんだ。びっくり。
100Be名無しさん:04/02/09 00:25
MonaApplicationで必ずPIDがいるのなら、プロセスロード時にメンバ変数にセットってのはだめなの?
101Be名無しさん:04/02/09 00:37
>97
カーネル内の文字列処理ですが、Monaはまだ初期段階の開発中OSですから、
開発者の環境や、ユーザの環境で実行したときのログ取りに使うというのが
一番の目的になると思います。
102ひげぽん ◆Ngzcp/NZpA :04/02/09 00:43
>>100さん

ありがとうございます。
mypid_をメンバ変数として用意しました。

そういえばbochsがマウス初期化のときにaux interfaceテストをすると
死ぬのでコメントアウトしました(感謝某氏)

>>97さん

確認なのですがPascal 文字列とArrayには関連ないですよね。
Arrayの要点としては

固定長配列のかわりにArrayをつかう。
Arrayの[]演算子で範囲チェックする。
ifdefでリリース時は範囲チェックをはずす。

と理解していますがあっていますでしょうか?
103Be名無しさん:04/02/09 00:49
>>98
> 描画に時間がかかりすぎる?
ポインタをただの点にしてしまうことで確認できませんか?
104Be名無しさん:04/02/09 01:03
>>98
> デバッグ出力とかですね。fault・error時に人間にとって
> 見やすい情報を出力できればよいです。
なるほど。

>>101
なるほど……って、あれ?ひげさんじゃない??

>>102
> 確認なのですがPascal 文字列とArrayには関連ないですよね。
長さをbyteにしたArray<char>はPASCAL文字列そのもの、という関連性です。
struct pstring
{
  byte length;
  char* data;
}
※この構造体にPASCAL文字列をmemcpyできます。

長さをbyteにすると256文字制限が出るので、
Array<char>がお勧めということです。
それは文字列に限らないということで話を続けました。
105Be名無しさん:04/02/09 01:04
あとArray<char>を徹底するなら、sprintfなどの引数もchar*ではなく、
Array<char>*を引数に取ることでsnprintfと同じになりますが、
sprintf(Array<char>*, const char*, ...);
(第一引数はハードコードがほとんどなのでconst char*のまま)
それならいっそ継承してクラスにすると良いかもしれません。

class string : Array<char>
{
public:
  int sprintf(const char*, ...);
}

これは単に
sprintf(str, "%d", 2);

str.sprintf("%d", 2);
と書けるというだけで好みのレベルでどうでもいいかもしれませんが。
106Be名無しさん:04/02/09 01:05
あまり関係無いけどWin32のHINSTANCEはプロセス内でしか意味を持たないのでPIDとはちょっと違う
Win16の頃はPIDのかわりに使えたが
107Be名無しさん:04/02/09 01:07
>>98
> こういうテクニックはプロの仕事ですねぇ。
プロと言えば、newやmallocの後に必ずASSERTでチェックしたりもしますが、
そういうチェックもコンストラクタでやって隠蔽できます。

あと効率上、配列をスタックに作る方が良い場合もあるので、
int __nums[3];
Array<int> nums(&nums_data, 3);
のようなコンストラクタを用意すると良いです。

ただこれだとクラスのインスタンスを作るオーバーヘッドが出てしまうので、
以下のようなマクロを使うと良いかもしれません。

#ifdef DEBUG
#define STACK_ARRAY(type, name, size) type __##name[size]; Array<type> name(&__##name, size);
#else
#define STACK_ARRAY(type, name, size) type name[size];
#endif

int buf[3];
 ↓
STACK_ARRAY(int, buf, 3);
※こういうときにうっかりbuf[3]とか書くことがたまにあるので。

面倒ですが、それくらいバッファ溢れは用心した方が良いです。
うっとおしくなれば正規表現置換でマクロから戻せるわけですし。
108107:04/02/09 01:12
うう、ミスってました。
誤:Array<int> nums(&nums_data, 3);
正:Array<int> nums(&__nums, 3);

あと↓の最後のセミコロンはいりませんね。
> STACK_ARRAY(int, buf, 3);
体裁的にセミコロンがあった方が収まりが良ければ
マクロの方から末尾のセミコロンを消すと言う手もあります。
好みのレベルでどうでもいいかもしれませんが。
109Be名無しさん:04/02/09 01:13
>>106
補足ありがとうございます。Display*も同じです。
110Be名無しさん:04/02/09 01:14
ソース本文中に #ifdef DEBUG の嵐は読みずらいと思うな。
マクロでおきかえってのは良いと思う。

malloc とかも良く以下みたいな感じにするし。
#define malloc(p) debug_alloc(__FILE__,__LINE__,p)

もちろんデバグコード抜かない方が良い場合は、
チェックコード入れっぱなしにするんだろうけど。
111104:04/02/09 01:19
すみません、↓はウソです。
> ※この構造体にPASCAL文字列をmemcpyできます。

memcpyできるのは↓でした。
メモリ効率悪いですが。

struct pstring
{
byte length;
char data[256];
}
112Be名無しさん:04/02/09 01:31
>>102
> 固定長配列のかわりにArrayをつかう。
> Arrayの[]演算子で範囲チェックする。
> ifdefでリリース時は範囲チェックをはずす。
はい、そうです。

関数の引数とかもすべてArray<>を前提にしてしまうと(その方が安全)、
STACK_ARRAYのような宣言時のすりかえではきかないので(暗黙にサイズを渡すため)、
#ifdefはArrayクラスのコードの方に書くことを念頭に置いています。
ヒープに確保するのであればオーバーヘッドは大きくないです。

>>110さんの指摘の__FILEや__LINEを埋め込む方がデバッグしやすいですが、
その場合は配列の宣言もマクロで行ってASSERTに渡すと良いでしょう。
113Be名無しさん:04/02/09 01:49
>>92
Array<>って配列をJavaやC#みたいにサイズ込みにするためのもの?
Array<int> a(3); // int[] a = new int[3];
a.length→3
114ひげぽん ◆Ngzcp/NZpA :04/02/09 01:52
>103さん
点にすると多少早くなります。

>104さん
> 長さをbyteにしたArray<char>はPASCAL文字列そのもの、という関連性です。

理解しました。そういうことですか。
PASCAL文字列よりも固定長配列の扱いの部分に目が行ってしまったのので・・・

>>106さん
補足ありがとうございます。

> あと効率上、配列をスタックに作る方が良い場合もあるので、
> int __nums[3];
> Array<int> nums(&nums_data, 3);
> のようなコンストラクタを用意すると良いです。

あーなるほど。すばらしいですねぇ。
Arrayの実装のときにそのまま流用いたしますです。
115ひげぽん ◆Ngzcp/NZpA :04/02/09 01:53
> ただこれだとクラスのインスタンスを作るオーバーヘッドが出てしまうので、
> 以下のようなマクロを使うと良いかもしれません。

うわぁ。頭がパンクしてきました。
ぎりぎりついていってます。
上級テクニック目白押しです。

>>110

> debug_alloc

これはユーザーモードで特に使えそうですね。
まだ不安定なので。

>>112
> はい、そうです。
> 関数の引数とかもすべてArray<>を前提にしてしまうと(その方が安全)、

すばらしいです。Arrayを実装する気です。
ところでArrayにすることでのオーバーヘッドは微々たるものという
イメージなので(範囲チェックを除けば)
116Be名無しさん:04/02/09 01:53
おまいら早く寝なさい
明日の仕事に障りますよ
117Be名無しさん:04/02/09 01:54
>>113
そうですね。
JavaやC#を知っている人はそう考えた方が分かりやすいかもしれません。
main(int argc, char* argv[])とmain(string[] args)の違いですね。
あ、でもmainはあまり例として良くなかったかも。
文字列クラスを作らないとstring[]はArray<Array<char> >になるから……。
118Be名無しさん:04/02/09 01:56
>>116
仕事中です……。
今日は椅子の上で3時間くらい寝れば上出来かな。(泣)
119ひげぽん ◆Ngzcp/NZpA :04/02/09 14:14
template <class T> class Array {
 public:
  Array(dword length) : length_(length), alloc_(true) {
    array_ = new T[length];
  }

  Array(T* array, dword length) : array_(array), length_(length), alloc_(false) {
  }

  virtual ~Array() {
    if (alloc_) {
      delete array_;
    }
  }

 public:
  inline T operator [](dword index) {
#ifdef DEBUG_MODE
    if (index < 0 || index > length_ - 1) {
      g_console->printf("array index outof range %d\n", index);
      for(;;);
    }
#endif
    return array_[index];
  }

 private:
  T* array_;
  dword length_;
  bool alloc_;
};
120ひげぽん ◆Ngzcp/NZpA :04/02/09 14:20
↑でっち上げてみました。
さてどこで使おうかな。
121Be名無しさん:04/02/09 14:58
◆Ngzcp/NZpAは、他にも使ってる人間がいるらしいので計算は簡単だと思われ。

つーか、既存のNewOSも知らないんですか。それで勝手にThe New OSを名乗れるんですよね。無知ですか。そうですか。>某
122Be名無しさん:04/02/09 15:07
仕方無いから「うにゅうOS」へ改名の方向で。(ぇ
123名無したん:04/02/09 15:11
>>121
散々外出の煽りを今更になってわざわざMonaスレでする理由は?
124Be名無しさん:04/02/09 15:15
ところでここは結局Monaスレなのか。
そして世の中では今日は休日なのか。
俺ヒキだから(ry
125Be名無しさん:04/02/09 15:31
>>119
ハンガリー記法って知ってる?
それはともかくサフィックスは流行らないよ。

もっとも最近はハンガリー記法の反動もあってか
あまりメンバ変数にプレフィックスを付けたりしない。

↓のように記号を使わないのが最近の流行。

private:
  int length;

public:
  inline int getLength() { return length; }

> delete array_;
これはまずい。delete[]を使わないとダメ。
126ひげぽん ◆Ngzcp/NZpA :04/02/09 15:37
> ハンガリー記法って知ってる?
いや知らないです。。
> それはともかくサフィックスは流行らないよ
そうなのですか。メンバ変数とローカル変数を区別するために
付けていたのですが、もうふるいのですね。

> delete array_;
> これはまずい。delete[]を使わないとダメ。

うわっ。やってますねぇ。ご指摘ありがとうございます。
127Be名無しさん:04/02/09 15:46
>>126
> いや知らないです。。
ハンガリー記法はMicrosoftが昔推奨していた命名規則。
Win32プログラミングすると最初に面食らう。
[例] m_nLength: m_(メンバ), n(整数←iNt)

だけど、今は推奨されていない。
.NETを逆コンパイルするとハンガリー記法と他の記法が混ざってる。

> メンバ変数とローカル変数を区別するため
メンバであることを明示したいときはわざとthis->を付けるのが流行。
return this->length;

これはIDEの補完機能から広まったとも言える表記法。
とりあえずメンバを出したいときにthis->と打てば漢字変換の候補みたいに出てくるので。
ハンガリー記法が廃れたのも補完で型まで出てきて必要性が薄れた面もある。
128Be名無しさん:04/02/09 15:57
他国産OSに比べてmonaのメリットって何?

2chで好き勝手に文句言ったり要望垂れ流したりマンセーできることくらい?
129Be名無しさん:04/02/09 16:06
>>128
日本語で作者と会話できる。それに尽きる。
OSASKに犬糞崩れの厨房が大挙して押し寄せた理由の1つ。
130Be名無しさん:04/02/09 16:09
>>119
Arrayを実際に使う場合、引数でポインタ渡しをすると混乱するので、
(インスタンスを直接扱う型とポインタで扱う型を区別するべき)
operator=を定義してコピーできるようにしておいた方が良いです。

その場合にコピーをどういう挙動にするか考えてみましょう。
JavaやC#で
int[] a = new int[1];
int[] b = a;
b[0] = 3;
としたらa[0]も3になりますよね。

同様に
Array<int> a(1);
Array<int> b = a;
b[0] = 3;
としたらa[0]も3にすることをお勧めします。

中身までコピーするSTLのlistやvectorとは挙動が違いますが、
言語的な仕様としては最近の流行だからです。

(続く)
131130:04/02/09 16:20
そうなると重大な問題が発生します。

Array<int> GetArray()
{
  Array<int> ret(3);
  ret[0] = ret[1] = ret[2] = 0;
  return ret;
}

という関数があったとして、
this->array = GetArray();
(↑明示的にthisを使うと流儀に関係なくメンバと分かるのが利点ですね)
などとしたらバグります。理由は分かりますよね?
この手のバグはその場でアクセス違反が起きないことが多くて厄介です。
バグを減らすつもりがバグを増やしては本末転倒です。

かと言ってGetArray()の中で
Array<int> ret(new int[3], 3);
などとすると、古いCのライブラリみたいに、
返り値は必ず解放してくださいということになって、
時代遅れの上面倒くさいことになります。

これを避けるためSTLではインスタンスをコピーする仕様だと思われます。
確かにC++的にはスマートですが、オーバーヘッドが大きいです。
もともとカーネルでSTLを避けたのもその辺が一因ですよね?

(続く)
132130:04/02/09 16:38
さてどうしたものでしょう?
もともとJavaやC#の真似をしたということは、
解決策まで真似をするということです。つまりGCです。

STLのlist<int>などではスコープで破棄させて代入ごとにコピーするため
GCがなくてもリークしませんがオーバーヘッドがあります。
引数では参照で回避できますが、効率のため参照を考え始めると面倒です。
かと言ってポインタ渡しをするのは使い方に統一性がありません。
オーバーヘッドもリークもなくすにはGCが必要です。

と言ってもGCには実装がたくさんあって、
Mark & Sweepなんかやっていたらオーバーヘッドが大きくなります。
カーネルがGCでストールするのは論外です。
それを考えると現実的なのはReference Countでしょう。

もともとC++ではスタックに作ればスコープで破棄されますし、
Reference Countでも理想的な手動deleteとほとんど同じ効率です。
循環参照のような問題はありますが、
削除したオブジェクトにアクセスすることがないのと引き換えです。

(続く)
133130:04/02/09 16:54
簡単なリファレンスカウントの実装。
private: int* refCount;
というのを用意します。
alloc_は不要になります。

コンストラクタごとに分類します。

1. Array(int length)
this->refCount = new int();

2. Array(T* array, int length)
this->refCount = NULL;

3. Array(Array<T>& src) ← コピーコンストラクタ
this->refCount = src.refCount;
(*this->refCount)++;
※operator=()も同じ。

(続く)
134130:04/02/09 17:10
virtual ~Array()
{
  if (this->refCount == NULL) return;
  if (*this->refCount == 0) {
    delete this->refCount;
    delete [] this->array;
  } else {
    (*this->refCount)--;
  }
}

ここまで出来れば引数は参照やポインタではなく値渡しでOKです。
void Func(Array<int> arg);

実戦投入する前にテストコードをよーく書いて、
ちゃんと機能しているかを確認してください。
この手のものはWindows上でデバッグできます。
うまくいけば
1. 配列溢れ
2. delete忘れ(メモリリーク)
3. deleteしたオブジェクトへのアクセス(自分でdeleteしないため)
の3大バグから解放されます。(やや誇張)
目に見えるほどのオーバーヘッドもないはずです。

配列でないオブジェクト用のものも作ればほとんどJava気分です。
(boostではshared_ptrと配列用のshared_arrayの区別があるのを参照)
Javaでカーネルを書くのが当初の夢だったんですよね?
工夫でC++をJavaに近付けているわけです。(パチもんですが……)

以上
135ひげぽん ◆Ngzcp/NZpA :04/02/09 22:18
>>127さん
> return this->length;
> これはIDEの補完機能から広まったとも言える表記法

なるほど。メンバ変数が多いとthis->だらけになりそうなのをのぞけば
一番分かりやすいかも知れませんね。

>>128さん
> 他国産OSに比べてmonaのメリットって何?

現時点では特にメリットはないかと思われます(笑)

>>130さん

大変有用な書き込みありがとうございました。
勉強不足ゆえ消化中ですが。
しっかりと生かしたいとおもいます
136ひげぽん ◆Ngzcp/NZpA :04/02/09 22:35
今日はいろいろとバグ修正をしていました。

130さんも書かれている通り例えカーネルのコードであっても
実は部品としてうまく切り出せばWindows上での開発・デバッグが可能です。
その方が断然効率もよく。ある程度汎用性のあるコードを
書く勉強にもなったりします。

さて最近のMonaはユーザーアプリ用にAPIが少しずつそろってきました。

・FDC直接操作open/read/write/close
・ファイル読み込みFileInputStream
・文字列描画printf
・描画(四角形とか点) Screen::bitblt
・VRAM直接操作
・仮想VRAMクラス
・スレッドcreate/join Mutex
・汎用メッセージング機構(プロセス間で通信が可能)
・メッセージングを利用してマウス・キーボード入力情報が取得可能
・プロセス間に共有ページ(メモリウィンドウ)を作成可能
・新規プロセス生成
・簡易シェルから自分の作成した実行形式のファイルを実行可能

実はいろいろと簡単なアプリが作れたりするのかなとは思っているのですが
なかなか手を付けられないですねぇ。
cygwin/linux のgcc, objcopy, ld等のツールがあれば今すぐ
Monaのアプリがかけます。

簡単なサンプル(ゲームなど)を見せられたりしたらよいのでしょうか(多少派手めに)
それとも何か有名なものを移植?
137Be名無しさん:04/02/09 22:39
そりゃあもちろんRogueCloneを
138Be名無しさん:04/02/09 22:40
マインスイーパをキボンヌとか言ってみる
13989:04/02/09 22:49
やたら伸びてるなあ。

>>91
文字だけだとうまいこと説明できないので、
リングバッファでぐぐって下さい。

基本的に読む方と書く方には依存関係がないので、
アトミックである必要がないだけです。
当然複数の場所から同時に書き込まれる・読み込まれる場合は
そこの排他制御は必要になります。
140Be名無しさん:04/02/09 23:09
ちゃんとソースを見たわけではないけど。
移植とか結構いけるんでないかな。VRAM開放されているのが
大きい。
141Be名無しさん:04/02/10 00:27
アプリはC言語で書くのですか?
142Be名無しさん:04/02/10 00:38
今のところCかC++を想定してると思われ。
詳しくはWikiを参照の事。
オブジェクト指向のAPIを提供する事と、
C言語ライブラリの整備が行われている途中。
143ひげぽん ◆Ngzcp/NZpA :04/02/10 01:37
>>89さん
ありがとうございます。>リングバッファ

>>141さん
C++言語を想定しています。
C言語でも可能ですがオブジェクト指向APIを
提供して行く予定ですのでC++をお勧めします。

>>142さん
フォローありがとうございました。

うむ。材料がそろっていても何らかの起爆剤が必要なのですかねぇ。
144Be名無しさん:04/02/10 18:59
この時期にMONAでゲームでも作ってレポート書けば神だと思うんだけどな。
145Be名無しさん:04/02/11 00:17
strtodとかstrtoulとか。その辺に落ちてるの使ってもイーのに。
University of Californiaのはよく見るけど、あれ元々何からのコードなんだろ。
146Be名無しさん:04/02/11 00:52
ライセンスさえ解決すれば、ぱくってきていいと思う。
でも、ライセンスの制限がつくけどライブラリが増えるってのは、
Monaプロジェクト的には、うれしいのかどうかわからない。

このスレ的には、
NICドライバ+TCP/IPプロトコルスタック+2chブラウザをMona上で実現したら神認定
ではないでしょうか。
147Be名無しさん:04/02/11 00:52
148Be名無しさん:04/02/11 01:55
>>145
UCBのだったら何も無い所から作ってるはずだが。

BSDLか(L)GPLならそこらからさくっともらえるが、
MIT/Xつーのはこういうとき不便やね。
149ひげぽん ◆Ngzcp/NZpA :04/02/11 02:44
>>144さん
>>146さん
どちらも神ですねぇ。

> でも、ライセンスの制限がつくけどライブラリが増えるってのは、
> Monaプロジェクト的には、うれしいのかどうかわからない。

カーネルではなくてユーザー側のライブラリであればあまりライセンスにこだわるつもりはありません。
もちろん議論は必要ですが・・・
あとMona APIの背後にそれらのライブラリが隠れている場合は複雑ですかね。

>>147さん
是非登録してください。
作者の私が言うのは変な話ですが敷居は割りと低めなので
たくさんの人がチャレンジしてくれるとうれしいです。

今日は某氏からMonaのレスポンスが悪いとの指摘を受けて
チューニングを開始。

当面の課題は3つ
・gcc最適化オプションで動くようにする
  - O2まではOK(volatileにすべきところが見つかったりしてよかった)
・FDからの読み込みの高速化
  - 詳しい人のサポートがあるとうれしいかも。
・メッセージreceive時にスレッドをブロックするなどのスケジューラ周りの改善。
150ひげぽん ◆Ngzcp/NZpA :04/02/11 02:50
あと。gccインラインアセンブラのマニュアルを紛失してしまいました。

"p"ってどういう意味かわかる人いたら教えてください。
asm volatile("lidt (%0)\n": :"p"(temp));

最適化時にこの辺が怪しいので
151Be名無しさん:04/02/11 09:17
>>148タン
> UCBのだったら何も無い所から作ってるはずだが。
いんや、UCBが他からパクってるって意味でなく。
オリが見た事あるのは全部、特定の関数のソースだけをUCBから拝借してる奴で。
元々UCBがライブラリや他のアプリを作る為にそれらの関数を作ったのか、
それともそれらの関数自体を作りたかったのか。
前者だとして元ネタが何なのかを知らないという意味。
152Be名無しさん:04/02/11 09:24
アセンブリなんてくっさいもの使わないで全部C++にしようYO
153148:04/02/11 11:53
>>150
メモリアドレスらしい。
mとの違いがよくわからん。

-O2で通ればいいんでないかと思ふ。
あとは-fomit-flame-pointer使って、レジスタを有効利用するとか。

>>151
AT&Tのライセンスに縛られないlibcを作るために書き下ろしたはず。
歴史の本を読めばそのへんの話が書いてある。

>>152
では手始めにsetjmp/longjmpをC++だけで書いて見てくれ。
漏れには難しすぎて出来ない。
とか言ってみる。
154Be名無しさん:04/02/11 12:26
>>153タン
歴史の本ね。ありがとー。
155ひげぽん ◆Ngzcp/NZpA :04/02/11 15:05
>>152さん
> アセンブリなんてくっさいもの使わないで全部C++にしようYO

そうですねぇ。私もアセンブラを極力使わない派です。
使わなければいけないところだけで使います。

>>148
> メモリアドレスらしい。
> mとの違いがよくわからん

ありがとうございます。私もそのような状況です。
mだとコンパイルとおるのですが割込み時に死んでしまうので
lidtがうまく動いてないのかも。

> -O2で通ればいいんでないかと思ふ。
> あとは-fomit-flame-pointer使って、レジスタを有効利用するとか。

とりあえず-O2はとおりました。(カーネル・アプリともに)

FDCドライバの最適化が難しそうですねぇ。

そういえばMonaのユーザーアプリでmain関数にあたるものに
Shellから引数を渡せるようになりました。

アプリ登録お待ちしています!
156Be名無しさん:04/02/11 16:12
バイナリ配布汁。
157Be名無しさん:04/02/11 17:11
>>148
> BSDLか(L)GPLならそこらからさくっともらえるが、
> MIT/Xつーのはこういうとき不便やね。
BSDLとMIT/Xを混ぜるのは何の問題もない。実質同じだから。
実際、以前FreeBSDのlibcから持ってきたコードがMonaに入ってたことがあった。
GPL系を混ぜても構わないけど作られたバイナリはGPLになってしまう。
それが嫌なら混ぜられない。
158Be名無しさん:04/02/11 19:05
神待ち
159Be名無しさん:04/02/11 21:42
そういやnewlibってBSDライセンスじゃなかったっけ?
160Be名無しさん:04/02/11 22:07
./Jで鳥取砂丘祭りがある。
負けじとMONAネタ投稿したら面白いかも。
それなりにできているわけだし。
161Be名無しさん:04/02/11 22:57
>>160
その前にリリースしないと。
162Be名無しさん:04/02/11 23:05
/.にはあくまでプレスリリースを出す気持ちでいかないと。過度の期待は禁物
163Be名無しさん:04/02/12 00:47
技術的ネタは食いつき悪いので、
おもろくないと思う。
164Be名無しさん:04/02/12 01:04
OS板>>/.

結構スラドの記事って引用されるから、まともな形になってからリリースしたほうが。
165Be名無しさん:04/02/12 01:11
>>135
> 勉強不足ゆえ消化中ですが。
http://up.isp.2ch.net/up/5bcb3ecbd622.zip
166ひげぽん ◆Ngzcp/NZpA :04/02/12 11:24
>>156さん
> バイナリ配布汁。

非公式版ですが下記からどうぞ。

ttp://wiki.osdev.info/index.php?cmd=read&page=%5B%5BDiskImage%2FMona%5D%5D

>>157さん
>>159さん

以前書いたとおりユーザーモード用のライブラリであれば
特にライセンスにこだわりはありません。

>>165さん
ソース拝見させていただきました。
私なんかより全然進んでいらっしゃるようです。
こちらこそ勉強不足。。。
167ひげぽん ◆Ngzcp/NZpA :04/02/12 11:25
> 当面の課題は3つ
> ・gcc最適化オプションで動くようにする
>   - O2まではOK(volatileにすべきところが見つかったりしてよかった)

-O3も通りました。これからはデフォルトO3でビルドするようにいたします。
インラインアセンブラのエラーの件は某氏のご協力により解決しました。

> ・FDからの読み込みの高速化
>   - 詳しい人のサポートがあるとうれしいかも。

未解決です。FDCDriverのソースを眺めているのですが
全く分かりません。たかだか数十`バイトのELFの読み込みに時間がかかりすぎです。

ソースは↓の通りです。どなたか詳しい方の突込みをお待ちしております。

ttp://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/mona/mona_v1.0/src/FDCDriver.cpp?rev=1.78&content-type=text/vnd.viewcvs-markup

> ・メッセージreceive時にスレッドをブロックするなどのスケジューラ周りの改善

改善しました。
今まではメッセージreceiveを発行したときにメッセージキューがからだった場合
ビジーウェイトしていたのですが、スレッドをブロックするようにしました。
メッセージが到着次第起こされる仕組みです。

これによりCPUが無駄に消費されない&メッセージ受信時に素早く反応できるようになったと思います。
168Be名無しさん:04/02/12 14:33
バイナリキターーーーーーーー
169Be名無しさん:04/02/12 14:45
スクリーンショット希望。
170Be名無しさん:04/02/12 17:15
ひげー QEMUビルドのその後はどうなった?SDL入れたらうまくいったのかね?
171Be名無しさん:04/02/12 18:08
>>167
FDトロイのは1sector毎に読んでるからじゃないの?
毎回シークしてるからじゃね?(´・ω・`)
173ひげぽん ◆Ngzcp/NZpA :04/02/12 18:51
>>170
qemu@cygwinはあきらめました。
Vine Linux上で環境を以前作りました。
VBE対応版はまだ入れていないです。

>>171さん
>>鳥取砂丘さん

> FDトロイのは1sector毎に読んでるからじゃないの?

> 毎回シークしてるからじゃね?(´・ω・`)

ありがとうございます。
なるほど。毎回シークしないというのは連続していたら
シーク省略ですかね。
174ひげぽん ◆Ngzcp/NZpA :04/02/12 19:10
カレントトラックが次の読み込み対象トラックと一緒だったらseek省略
でやってみようかな。
175165:04/02/12 20:05
>>166
> 私なんかより全然進んでいらっしゃるようです。
> こちらこそ勉強不足。。。
延々とArrayの話をした本人だもん。
実装を差し上げるよってことなんですが。
Javaみたいで便利とか思えば使い方も分かるかと。
176Be名無しさん:04/02/12 20:57
>int MonaMain(List<char*>* pekoe);
こういうのこそArrayにすると良い。可変長である必要はない。
ユーザープログラミングではメモリ管理を極力排除できるような構成を意識すべき。
その意味ではSTLやboost的なC++よりManaged C++の方が参考になる。
177Be名無しさん:04/02/12 22:35
きたーーMONA
178Be名無しさん:04/02/12 22:56
>>174
前回時のトラックを覚えさせておいて、
前回と同じトラックだったらシークを省略なのでは?
あと、最低限DOSでいうところのFILES相当のディスクキャッシュを
実装してみては?
179178:04/02/12 23:01
>>178
ミスった。FILESじゃなくて、BUFFERSね。
180Be名無しさん:04/02/12 23:46
>>178
それはFDCの方で管理していたような気がする。
765じゃなくてMB8877だったかな?

ぐぐったらデータシート見付けたので参考に。
ttp://paginas.terra.com.br/informatica/brlivre/minix/docs/outros/uPD765.pdf.gz
181Be名無しさん:04/02/13 01:04
>>180
実際にヘッドをシークさせるパルス信号を出すかどうかというのとは
別の話で、ドライバなりがFDCにSEEKコマンドを発行するかどうかと
いう話ね。
物理的にシークしなかったとしても、いちいちSEEKコマンドを発行したら、
次のREADなりWRITEコマンドの発行が次のセクタのID部にヘッドがかかかる
前までに完了しなくて、1回転するのを待つことになりかねないと思うん
だけどね。
#インターバルにセクタ番号を振る物理フォーマットをすれば間に合う
#かな?
182Be名無しさん:04/02/13 02:34
>>181
そりゃシーク関係ないとおもわれ。
いくらCPU早くても1セクタ毎にリード出していたら
FDCついてこれなくて一回転待たされるぞ。

そのへんの問題を回避するためにセクタ番号飛び飛びにするつーのは実際あった。
読み方によってはかえって遅くなるという…
183Be名無しさん:04/02/13 07:01
>>183
現時点では主に連続読み込みするのはカーネル側っぽいから間に合うかな
と思ったけど、きついかな?
SEEKコマンドの最適化しても遅かったら、マルチセクタ対応にするしか
ないんだろうね。効果的に利用するようにするのは、今のMonaでは簡単
ではないかもしれないけどね(上位層にFDの特性に特化したコードを
入れればそうでもないだろうけど…)。
184ひげぽん ◆Ngzcp/NZpA :04/02/13 14:29
>>165さん
失礼いたしました。
熟読させていただきます。

>>176さん
突っ込まれると思っていました(笑)
すいません。手を抜きました。
カーネルに引数を渡す実装がしたくて
型自体では手を抜きました。
Stringクラスを作ったら改善します。m(__)m

>>178さん
> 前回時のトラックを覚えさせておいて、
> 前回と同じトラックだったらシークを省略なのでは?
ありがとうございます。実装しましたが
まだ遅いようです。
LBA=1〜10の連続読み込み × 10回で12秒ほどかかります。
50KBに12秒は遅すぎですよね
185ひげぽん ◆Ngzcp/NZpA :04/02/13 14:30
> ミスった。FILESじゃなくて、BUFFERSね。
ディスクキャッシュですか。
FDCDriverの読み込み速度の改善には
直接はつながらないですよね。
ファイルシステム側のほうがいいですかね。

>>180さん
> ぐぐったらデータシート見付けたので参考に。
ありがとうございます。

>>183さん
> SEEKコマンドの最適化しても遅かったら、マルチセクタ対応にするしか
> ないんだろうね。効果的に利用するようにするのは、今のMonaでは簡単

マルチセクタですか。うーむ。OSASKとかはFDアクセスが早いので
その辺のテクニックを使っているのですかね。
186ひげぽん ◆Ngzcp/NZpA :04/02/13 14:34
最近の成果

・RTCにより日付・時刻が取得できるようになりました(Dateクラス)
  詳細はsrc/user/clock.cppをご覧ください。

ttp://mona.sourceforge.jp/dynamic/pukiwiki/pukiwiki/pukiwiki.php?Mona%2F%A5%A2%A5%D7%A5%EA%C5%D0%CF%BF%BD%EA
アプリ登録所に登録がありました。
割と本格的にMonaでプログラミングしたよい例といえると思います。
しかもFSサーバなので自分としても大変参考になります。
187ひげぽん ◆Ngzcp/NZpA :04/02/14 00:29
アプリ登録所にサンプルとしてオセロを登録しました。
むかしjavaで書いたやつの移植版です。

制限・特徴
・マウスを用いて人同士の対戦ができます。(コンピュータ対戦部は今回は移植しませんでした。)
・クラスMonaApplicationの実装例です。(Monaではこういうことが出来るよの見本のような感じ)
・GUI部品がないので終了・リセット・UNDO・勝敗表示は出来ません。(機能としてはあるのですが)
・オセロのロジック部と表示部をオブザーバーパターンで分離しているのでC++をサポートしている
 ほかのOSにも割りと簡単に移植できそう。
・描画にはダブルバッファを用いて変更箇所のみ描画しなおしているのでちらつきもありません。

今後カーネルコーディングの暇を見て少しずつパワーアップしていく予定です。
188ひげぽん ◆Ngzcp/NZpA :04/02/14 00:37
2月中はユーザーアプリの作成のサポートと。
サーバー間のメッセージプロトコルを決めるあたりを中心に
作業を進める予定です。

↑で書き忘れたのですがオセロのソースは日本語でコメントを
いっぱい書いたので多少は分かりやすいと思います。

皆様のアプリ登録をお待ちしております。m(__)m
189ひげぽん ◆Ngzcp/NZpA :04/02/14 08:33
無駄なseekをなくして改良したFDCDriverですがまだ遅いようです。

Mona起動時のBIOS利用のカーネル読み込み時とFD読み込みの音が違うなあ
と気づきました。

BIOS利用時は「グッグッ」と読み込みが連続している感じなのですが
FDCDriverの方がたまに「グッ」となるだけです。
なんだか「待ち」をしているような感じです。
190ひげぽん ◆Ngzcp/NZpA :04/02/14 09:37
RDTSC命令を使用してどの部分が遅いか調べてみました。

seek:0x56 ロジックによりコマンド発行せず
dma setup:0x29FB
read command発行:0x129CC
完了割込み待ち:0x9BB8294
result引き取り:0xE532
stop dma:0x4AD
memcpy:0x87B
total:0x9BDCAF1

これにより分かったことはreadコマンドを発行後、完了割込みがくるまで
が大半の時間であるということです。

readコマンドのパラメータの問題なのでしょうか。
うーん。
191Be名無しさん:04/02/14 10:44
つーか、VESAは16bitで十分です。
192Be名無しさん:04/02/14 12:09
>>187
>・オセロのロジック部と表示部をオブザーバーパターンで分離しているので
昔pantora(hajimetyan)が/.で公開して弱くて顰蹙だったオセロと同じこと言ってるな。
ひょっとして「ひげぽん=平初」か?と思ったけど年齢が違うね。
ひげぽん: 25 or 26歳
平初: 22歳
Java厨の思考回路は似てるってことか。
193Be名無しさん:04/02/14 13:46
>>190
そりゃ、いまどきのCPUならドライブから1sec分のデータを読み込んでくる
のを待っている間が大半になるんじゃないかな?
連続読み込みして、前回の完了割込みから今回のREADコマンド発行まで
の時間が、十分に短いかどうかが問題だと思います。
# ソースをもうちょっとよく読んだら、ちょっときついかもしれない。
# 下請けのプロシージャはインライン展開になっているのかな?
# ローカル変数の配列初期化定義もいくら今どきのCPUでもGAP3通過時間
# との闘いという面では、だいぶ不利かも知れないね。
194193:04/02/14 13:54
>>193
ローカル変数→ローカル自動変数
195193:04/02/14 15:07
>>193
必要以上に完了割込み待ちをしているかどうかいう問題もありえるか。
普通の1.44Mドライブの回転速度は、360rpmだったかな?
360rpmだとすると、大雑把には、
(READ待ち時間[s]) = 60/360 / 18
で、9.2592... ms
まぁ、実際にはGAP4などがあるからもうちょっと短いと思うけど…。
196Be名無しさん:04/02/14 15:10
>>187
> #include<OthelloBoard.h>
<>はインクルードパスにあるヘッダを指定するのに使う。
ソースのパスと同じ、または相対参照できるものは""を使う。
あと空白を空けといて。
→ #include "OthelloBoard.h"

> monaApp = new myApplication("OTHELLO.ELF");
> dword myPid = Message::lookup("OTHELLO.ELF");
getpid()を実装したんじゃなかったの?
自分自身の名前をハードコードするようなのは良くない。
サーバのようなものだったらハードコードしても実害ないだろうけど、
そういうのはシステムヘッダに定数として書いておくべきだろう。
#define MOUSE_SERVER "MOUSE.SVR"

サービス名がファイル名そのままなのは考え物。
RegisterClass()みたいに文字列で名前を付けられるようにするべき。

あとothello.cppとOthelloBoard.cppの文字コードや改行コードがまちまちなのも気持ち悪い。
犬糞と行き来してるからか?
改行コードは趣味に合わせるとしか言えないが、文字コードは中立でUTF-8が良い。
どうせ文字列クラスと絡んでUnicodeは避けられないんだから。
197Be名無しさん:04/02/14 15:20
>>196
>犬糞と行き来してるからか?
eucJPなんか犬糞ですら時代遅れになってる。
Fedoraはja_JP.UTF-8に移行してるぞ。
Kondaraが何年も前にやろうとしてはいたがね。
Solarisだとja_JP.UTF-8はとうの昔にサポートされてる。
Windows 2000からはメモ帳ですらUTF-8をサポートしている。
198ひげぽん ◆Ngzcp/NZpA :04/02/14 15:49
>>191さん
> つーか、VESAは16bitで十分です。

現在のMonaは稼動中にビデオモードを変更することは出来ません。
そのため起動時にある優先順位でいくつかのビデオモードがサポート
されているかを調べて行き、最初に見つかったビデオモードに
切り替えるようになっています。

多色が良いという方もいれば16bitで十分という方もいらっしゃって
難しいですね。
稼動中に切り替えることが出来ればこの問題は解決しそうですね。

>>193さん
> そりゃ、いまどきのCPUならドライブから1sec分のデータを読み込んでくる
>のを待っている間が大半になるんじゃないかな

なるほど。そのまっている時間が実際に何msなのかが問題なのですね。

> 前回の完了割込みから今回のREADコマンド発行まで
>の時間が、十分に短いかどうかが問題だと思います

そういうことですか。なんだか納得しました。

> 360rpmだとすると、大雑把には、
> (READ待ち時間[s]) = 60/360 / 18

そうすると結局。最適化してread間の時間を
短くすればよいってことですよね。
スケジューリングとあわせると複雑になりそうですねぇ。
199ひげぽん ◆Ngzcp/NZpA :04/02/14 15:50
>>196さん
ご確認・ご指摘ありがとうございます。

> → #include "OthelloBoard.h"

修正しました。

> monaApp = new myApplication("OTHELLO");
> dword myPid = System::getPID();

> そういうのはシステムヘッダに定数として書いておくべきだろう。
> #define MOUSE_SERVER "MOUSE.SVR"

これはサーバー間のプロトコルが決まり次第ルールを決めたいと思います。

> あとothello.cppとOthelloBoard.cppの文字コードや改行コードがまちまちなのも気持ち悪い。

euc-jp-unixで統一しました。(エディタの都合です)
200Be名無しさん:04/02/14 16:24
>>199
>euc-jp-unixで統一しました。(エディタの都合です)
エディタというのがEmacsのことだったら、最近のだと
* Editing -> I18n -> Mule -> utf-translate-cjk-mode
ってやればUTF-8使えるよ。
そんなの出ない古〜いやつを使ってるならMule-UCS必須だけどね。

文字コードの話を避けているようだけど、
避けるためにこそUTF-8を推薦してるんだけどね。
ロカールとか言語ごとの文字コードとか考えたくないでしょ?
今の段階で考える内容じゃないからね。

char*はUTF-8、文字列クラス内部ではUCS-4というのが最も簡単な実装。
SJISとかEUCだとsubstringで漢字を扱うときにDOS時代に逆行しちゃうぞ。
201ひげぽん ◆Ngzcp/NZpA :04/02/14 16:37
>>200さん
> エディタというのがEmacsのことだったら、最近のだと
> * Editing -> I18n -> Mule -> utf-translate-cjk-mode
> ってやればUTF-8使えるよ。
set-buffer-file-codingsystemで
utf-8は選択できるのですがc-x sの保存時にエラーになったので
euc-jp-unixにしました。(view cvsの都合もよいかなあと)

> 文字コードの話を避けているようだけど、
> 避けるためにこそUTF-8を推薦してるんだけどね。

すいません。避けているわけではないのですが
まだ何も考えていません。

いつの段階で文字コードのことを考えればよいのか
迷うところです。
202Be名無しさん:04/02/14 16:48
>>201
> 保存時にエラーになったので
↓は試しましたか?
>> * Editing -> I18n -> Mule -> utf-translate-cjk-mode

> view cvsの都合もよいかなあと
HTMLのソースで文字コードは指定されていませんよね。

> いつの段階で文字コードのことを考えればよいのか
> 迷うところです。
文字列クラスを作るとき。
new String("漢字")->getLength()
とか
new String("漢字")->substring(1, 1)
がどういう結果になるのが望ましいでしょうか?

ソースが何であれ内部でwcharにしないと自然に扱えませんし、
今から定義するならwchar=UCS-4というのが簡単です。
EUCとかだと変換テーブルとかロカールとか絡んで面倒くさいですよ。
というわけで何も考えなくて済むのはUTF-8。
203Be名無しさん:04/02/14 16:56
少なくともEUC-JPはSJISよりはましだけどね。
gccでSJISだと"表\示"みたいなことになっちゃうからね。
204Be名無しさん:04/02/14 18:11
gcc って L"日本語" とかやってもだめじゃなかったっけ?
205Be名無しさん:04/02/14 18:16
>>204
ダメ。
APIをwchar_t*で扱うようにするのは無謀だから、
全部文字列クラス経由にして隠蔽しないと厳しい。
ソースはchar*で書くにしても文字列クラスのコンストラクタやoperator=とかで
代入時に変換しないとワイドキャラクタは自然に扱えない。
206Be名無しさん:04/02/14 18:43
>>205
結局変換するんだったらEUCでもUTF8でも同じなんじゃねーの?
207Be名無しさん:04/02/14 19:00
>>206
内部的には固定長文字列が良くて、今選ぶなら UCS4 だろ。
したら UTF-8 で入力するのが楽でない?

という話だと思う。
今作ってる辺りなら ASCII だけで良いと思うけどね。
208Be名無しさん:04/02/14 19:08
UCS信者うざいよ
UCSとUTFを同一視すんな
209Be名無しさん:04/02/14 19:13
>>207
でも既に半角カナでAAしてるからね。
AAをハードコードするとSJISになってしまう。
210Be名無しさん:04/02/14 19:16
UTF-8を採用するか否かで勝ち組になるか負け組になるかの瀬戸際だからな。
それは譲れない。
211Be名無しさん:04/02/14 19:26
>>209
MS仕様Unicodeみたいに半角カナ用の文字コードを互換領域に
定義してしまえばSJISになってしまうとは限らない。
212Be名無しさん:04/02/14 19:43
どうでもいいけど、ロケールって言わないですか?

UTF-8を採用しないと、負け組みなのですか。
OSが文字コードに依存しないようにしておけばいいだけじゃないのですか?
213Be名無しさん:04/02/14 20:04
>>212
> OSが文字コードに依存しないようにしておけばいいだけじゃないのですか?
文字列を単に表示にしか使用しないのなら別だけど、
ファイルのパス名などカーネルオブジェクトの名前を表現するために
文字を使用すれば通常は文字列操作が必要になるから文字コードに依
存しないようにするのは無理かと。
214Be名無しさん:04/02/14 20:30
>>212
>どうでもいいけど、ロケールって言わないですか?
それではシュミレーションなんかと同じ
ロカール
215Be名無しさん:04/02/14 20:51
>>213
>ファイルのパス名などカーネルオブジェクト
ファイル操作は全部カーネル外のサーバに押し出したらカーネルとは関係なくなるけどね。
カーネル内部でコード変換とかやったらカーネルが一気に肥大化してしまう。
FATだけ扱うにしてもSJISだからソースをEUCにしたらコード変換が発生してしまう。
そろそろ考えないと、その辺の問題が出てくるよ。
216Be名無しさん:04/02/14 21:01
>>211
今のMonaの実装では、という話。
昔のPCみたいにフォントは1バイトに単純にマップしてあるからね。
ともかくFATにしてもAAにしてもソースEUCではコード変換必須。
SJISとEUCの変換は基本的に計算で出来るがIBM拡張領域とかでテーブル必須だし
3バイトEUCとかを実装しないと不可逆変換になってしまう。
UTF-8にしてもFATでコード変換が発生するのは避けられないけどね。
手抜きするなら当面SJISになるけどgccだと"表\示"みたいな問題は覚悟しないといけない。
217Be名無しさん:04/02/14 21:06
$ find /path/to/mona_v1.0 -exec qkc -e {} \;
OK
218Be名無しさん:04/02/14 21:11
>>217
カーネルのコメント全部英語だし。
それに文字コードに依存するような処理はカーネル外に出すべきだからあまり関係ない。
ユーザーアプリとか作るときに影響がある。
WideStudioではMakefileでソースにプリプロセッサかまして避けている。←sjisfix
219Be名無しさん:04/02/14 21:13
>カーネルのコメント全部英語だし。
外人に見せるために英語にしてるなら尚更SJIS決め打ちはまずいだろ
220Be名無しさん:04/02/14 21:16
>>214
モノシリック
221Be名無しさん:04/02/14 21:18
モノリシック
物知りっ9
by Canna
>>219
卑下の英語って変だろw
TRISPLANよりマシだが。

222Be名無しさん:04/02/14 21:22
VFATも扱うとなると、ロングファイル名はUnicodeで格納されている
から、どっちみちコード変換の機能は必要だね。
N:N対応だとコード変換の種類がN*(N-1)通りになるから、
ネイティブともいえる文字コードを1つ決めて、1:N対応になるように
すればコード変換の種類がN通りですむという話なのではと思う。
で、そのネイティブ文字コードの地位をめぐる争奪戦が繰り広げられよう
としていると。
223Be名無しさん:04/02/14 21:27
多数決をとろう。
224Be名無しさん:04/02/14 21:27
>>222
MSの特許問題でVFATまずくない?
そうなるとUDFかUFS2かext2辺りが必要になるだろうね。
UDFだとUnicodeだし、UFS2やext2だと特に決まりはないけど
普通はEUC-JPで使ってるだろうから、
マウント時にコードを指定して変換するしかないね。
225Be名無しさん:04/02/14 21:29
>>223
あせるな。ひげぽんの降臨を待て。
226222:04/02/14 21:34
>>222
ミスった。5行目のN通り→(N-1)*2通り
227Be名無しさん:04/02/14 22:08
↓の状況から、ひげぽんは本当に何も考えてなかったんだろうね。
>othello.cppとOthelloBoard.cppの文字コードや改行コードがまちまち
今は他のことがやりたいのに突然畳み掛けられて当惑してるんだろう。

だけど今後ますます「今まで考えたこともなかった」ことがどんどん出てくるし
知らないから後回しにすると修正が面倒になるようなことも多くなる。
OSを作るというのは全方位の知識を総動員しないといけないくらい広いから。
ここをどう乗り切るかで今後が占えるとも言える。

刮 目 し て 待 て ! !
228ひげぽん ◆Ngzcp/NZpA :04/02/14 22:11
>>202
>> * Editing -> I18n -> Mule -> utf-translate-cjk-mode

Meadow2を使っています。
utf-から始まるコマンドは見つかりませんでした。
私の力不足の可能性濃厚かも。

>> view cvsの都合もよいかなあと
>HTMLのソースで文字コードは指定されていませんよね。

そのむかしview cvs上でchangeLogが文字化けしたので
eucにした記憶があったのですが勘違いかも知れません。

> new String("漢字")->substring(1, 1)
> がどういう結果になるのが望ましいでしょうか?

文字コードに関しては詳しくないですが。
それはユーザーモード側の話と認識しています。
正確にはライブラリですかね?カーネルと関わるところも
あるかもしれませんが、できるだけユーザーモードに
押し戻したい感じです。(Monaのポリシーとして)
229ひげぽん ◆Ngzcp/NZpA :04/02/14 22:11
文字コード問題ですが。以下のように考えています。
1.カーネルが貧弱なので文字コードを議論する段階ではない。当分ASCIIでよいのでは。
2.ただし将来的にMonaのネイティブ文字コードを考えるのは絶対必要。
3.感触としてはUTF-8かなぁ。
4.ライブラリ等UTF-8のものをどなたか担当していただけるならば大歓迎です。
230Be名無しさん:04/02/14 22:16
>>228
頑張ったところ悪いけどピントがズレまくってますよ。

>それはユーザーモード側の話と認識しています。
カーネルの話はしてないよ。もともとオセロの話だったでしょ。
231Be名無しさん:04/02/14 22:20
>>229
>2.ただし将来的にMonaのネイティブ文字コードを考えるのは絶対必要。
>3.感触としてはUTF-8かなぁ。
この辺、全然分かってない感じ。
ソースを何で書くのかというのと、内部処理に何を使うかは別問題。
極端な話、前者はコンパイル前にプリプロセッサを通せば
Mona側で何もしなくても解決する問題だから。

内部処理にUTF-8みたいな可変長コードを使うのは最悪。
Unicode 3.1でサロゲートが出てきた現在UTF-16でも同じ問題になる。
固定長ならUCS-4しかない。
232Be名無しさん:04/02/14 22:21
> カーネルの話はしてないよ。
それいっちゃ、話の流れ自体がピンとずれまくりじゃない?
Mona って今カーネル作ってるところやん。
233ひげぽん ◆Ngzcp/NZpA :04/02/14 22:23
> >それはユーザーモード側の話と認識しています。
> カーネルの話はしてないよ。もともとオセロの話だったでしょ。

なるほど失礼いたしました。
では。主にユーザーモードでの文字コードの扱いを
決めるということが主題でしょうか。

現在のカーネル作成状況と割ける事件を考えると
文字コード対応したStringやライブラリを用意するよりも
カーネルの機能の増強の方が優先されてしまう時期だと思います。
(直近ではドライバインターフェースなど)

それを受けて以下のまとめになりました。

> 1.カーネルが貧弱なので文字コードを議論する段階ではない。当分ASCIIでよいのでは。
> 2.ただし将来的にMonaのネイティブ文字コードを考えるのは絶対必要。
> 3.感触としてはUTF-8かなぁ。
> 4.ライブラリ等UTF-8のものをどなたか担当していただけるならば大歓迎です。
234Be名無しさん:04/02/14 22:27
>>232
アプリ募集してて、なおかつ、こんなの出来たよ〜って言ったのはひげぽん自身なんだけど
235232:04/02/14 22:29
>>234
日本語扱えないとアプリ組むのもメンドイよ。
つー話?
なら、なんとなく分かる気もする。
236Be名無しさん:04/02/14 22:32
>>233
>現在のカーネル作成状況と割ける事件を考えると
>文字コード対応したStringやライブラリを用意するよりも
>カーネルの機能の増強の方が優先されてしまう時期だと思います。
>(直近ではドライバインターフェースなど)
それはみんな分かってるんじゃ?
たとえば
>>227
>今は他のことがやりたいのに突然畳み掛けられて当惑してるんだろう

だけどJavaを使っているのにUTF-8とかUCS-4のことを知らないのは
勉強不足と言われても仕方ないよ。
Javaでは内部がUTF-16だしcharはuint16_tだってことは知ってるよね?

コード変換のことを知っておかないとDBとのやり取りで文字化けしたりするし、
そんな人の作ったWebサービスとか怖くて使えない。
煽りじゃなくてマジだよ。
237Be名無しさん:04/02/15 01:25
本当に文字コードのことを全然知らないみたいなんで気の毒になって来た。
ググっても小難しい英語の資料とかが多いから簡単に説明しておくか。

もともと各国で別々の文字コードが使われていたけど、
それだと処理を文字コードごとに作りこまないといけなくなるので、
主要な文字コードを単一の文字コードに入れた。これがUnicode。
その際に文字コードは16bitで表現された。つまり65536種類の文字。
1文字2バイトの固定長で表現されるためUCS-2と呼ばれる。

しかし文字単位を16bitにしてしまったため
従来のchar*を使う関数では処理できなくなってしまった。
そのためWin32では同じ関数をA系とW系のペアで提供する羽目になった。

これでは扱いにくいので8bitのcharでUnicodeを扱えるようにしたのがUTF-8。
UCSはコード体系で、UTFは符号化方式を表す。
7bitしか使えないメール用にUTF-7なんてのもある。
つまり本当の体系はUCS-2で、UTF-8は便宜的に作られたもの。

ただしUTF-8は可変長であるため文字列処理には向かない。
文字列処理自体は1文字16bitの固定長配列に変換して行う。
Javaもその考え方に基づいてUCS-2を採用した。
238Be名無しさん:04/02/15 01:36
しかしUCS-2は無理矢理世界中の文字を1つのコード表に詰め込んだため
色々と無理が出てきてしまった。
それにビルマ文字などはみ出してしまった文字も残ってしまった。
そのためコードを32bitに拡張して対応することになった。これがUCS-4。
つまりUCS-2は過去のものになってしまった。

しかし既にUCS-2を採用してしまった処理系は多かったので、
サロゲートという拡張方法でUCS-4を16bit可変長に押し込めたのがUTF-16。
UTF-8は理論上31bitまでの拡張に対応できるようになっているので無問題。
※実際には32bitを使い切るようなことはあり得ないため。

UCS-4登場以降に実装された処理系はUCS-4を採用している。
たとえばglibcがそう。
ただUCS-2からはみ出すような文字は現実的にほとんど使われないので
UTF-16と言ってもUCS-2としてしか使われないのが現状ではある。

ともかくUCSがコード体系でUTFが符号化方式なのは最低限理解しないと、
まともにUnicodeについて考えることは不可能ってこと。
239Be名無しさん:04/02/15 02:09
うにこーどは合成文字とか面倒臭いんだよなあ。
文字コードの問題は考えれば考えるほど面白くないw
interfaceでも文字コードの話してた事無いっけ?
240Be名無しさん:04/02/15 02:23
>>239
合成文字だけじゃなくてbidiなんかも超面倒くさい。
同じ文字コードでも結合状態で字体が変わったりする文字もあるし。
だけどSJISとかEUC-JPだとそもそも表現できる可能性自体もないから、
それよりはましってだけで欠点とかそういうことではない。

もっともそんなの今の段階で考えることではまったくない。
8bitのフォントのコードページを16bitにするだけと考えるべき。
それだけならSJISやEUC-JPでも漢字を表示する部分は大差ないので。
241Be名無しさん:04/02/15 02:50
>>235
日本語を使わなくたって、文字列をOS側と受け渡しするアプリは作りに
くいね。将来、作り直しを迫られるかも知れないからね。
コンパイルし直すだけですむ場合もあるでしょうけど。
242Be名無しさん:04/02/15 10:20
つまりは、UCS-4を主張する人が、
 UCS-4<->EUC-jp(or SJIS)の変換コード
 UCS-4を表示するコード
を書けば、採用されるんじゃないの?
243Be名無しさん:04/02/15 11:02
>>241
どうせ今のMonAPIは仮だからってことで
その辺の問題をあまり深刻に考えてないんだろうね。
アプリ募集のための呼び水のはずのオセロが
逆に「待ち」を推奨してしまう結果になったのは分かってるかな?

>>242
中身ブラックボックスで意味が分からないものを採用するわけないから、
ひげぽんがUTF-8とUCS-4の関係を理解しないと無理かと。
Arrayみたいに勝手にやると飼い殺しになりかねない。
244Be名無しさん:04/02/15 11:33
今の API ってあまりに仮過ぎてバシバシ変わってるやん。
自分で勝手に作くる覚悟で API 変わるって分かってるやつしかアプリなんか作っちゃ駄目だって。

API 変えてる状況で ASCII ってのは悪くない選択だと思うけど。
245ひげぽん ◆Ngzcp/NZpA :04/02/15 16:31
知らないものはしょうがないですがそのままなのもアレなので
ちょっと文字コードについて勉強しました。
以下つけやきばかもしれませんがご容赦ください。

>>231
> 内部処理にUTF-8みたいな可変長コードを使うのは最悪。
> Unicode 3.1でサロゲートが出てきた現在UTF-16でも同じ問題になる。
> 固定長ならUCS-4しかない。

>>238さんも書かれている通り
UCS4は文字コードセットの集合でUTF-16はエンコーディングではないでしょうか?

>>236さん

> だけどJavaを使っているのにUTF-8とかUCS-4のことを知らないのは
> 勉強不足と言われても仕方ないよ。
> Javaでは内部がUTF-16だしcharはuint16_tだってことは知ってるよね?

その通りですね。確かに勉強不足だったので遅まきながら
勉強しました。Java DOCの国際化のところも軽く目を通しました。

>>237
>>238さん
丁寧なご説明ありがとうございます。
別資料でも勉強しましたがより理解が深まりました。
246ひげぽん ◆Ngzcp/NZpA :04/02/15 16:32
浅い勉強で思ったのは。
文字コードセットはUCS-4を採用。
エンコーディングは要検討(UTF-8, UTF-16など)
内部で扱う場合は4byte固定がよいかなあと。

今後Monaで考えるべきことは

4byte固定の体系
エンコーディング決定
ライブラリ開発というところでしょうか?

あとは時期の問題もありますね。方針が決まっていれば
急ぐことではないような気がします。
また作業を別の方にお願いすることも不可能では無いですね
247Be名無しさん:04/02/15 16:51
>また作業を別の方にお願いすることも不可能では無いですね

>>246 さん、あなたにお願いすることも不可能では無いですね
248Be名無しさん:04/02/15 18:22
>>245
> > 内部処理にUTF-8みたいな可変長コードを使うのは最悪。
> > Unicode 3.1でサロゲートが出てきた現在UTF-16でも同じ問題になる。
> > 固定長ならUCS-4しかない。
>
> >>238さんも書かれている通り
> UCS4は文字コードセットの集合でUTF-16はエンコーディングではないでしょうか?

何を反論しておられるのかさっぱり分かりません。
まだ把握しきれていないようですね。

Unicode自体は複数の文字コードセットを統合したものですが、
ISO-2022のようにエスケープシーケンスで切り替えるわけではなく、
Unicodeという単一のコードセットに再編集して一本化したものです。
従ってUCS-4が文字コードセットの集合というのは違います。
UCS-4はそれ自体が単一の文字コードセットです。
群とか面とかのことを文字コードセットの集合だと勘違いしたのかもしれませんが、
あれはコードが巨大なため行列番号を付けて区画整理しただけです。

(続く)
249248:04/02/15 18:26
やっぱやめた
(終わり)
250248:04/02/15 18:28
SJISのようなものだと、"A"は1バイト、"あ"は2バイトという風に、
文字によってサイズが異なってしまいます。
このことを文字コードの「可変長」と表現します。

UCS-4はuint32_tを文字の単位とした場合に、
どんな文字も4バイト固定で表現することが出来ます。
このことを文字コードの「固定長」と表現します。

可変長か固定長かが問題になるのはまさに次のケースです。
1. "あいAB"の文字数は?
2. "あいAB"の2番目の文字から2文字抜くと?
可変長だと文字ごとにバイト数が異なるため、
純粋に文字数を返すのが困難ですが、
固定長だと文字列は文字ごとの配列なので、
単純に処理することが出来ます。

もともとUnicodeは16bitのコード体系であり(UCS-2)、
uint16_tを文字の単位として固定長で表現できました。
これを採用したのがJavaです。
そのためJavaの文字単位charはuint16_t(符号なし16bit整数)で、
"A"でも"あ"でもすべて2バイトの固定長です。

従ってJavaでは上の文字列処理も、
1. 4文字
2. "いA"
と簡単に扱うことが出来るわけです。

(続く)
251248:04/02/15 18:37
>>249は偽者です。

ここで話がややこしくなるのは、後にUnicodeが拡張されて、(ver.3.1)
16bitでは収まらなくなってしまったことです。
そのためUnicodeの文字単位は32bitとなり、
コードセットとしてはUCS-4となりました。

注意しないといけないのは、UCS-4登場以前には、
UTF-16などというものは存在しなかった点です。
それはあくまでUCS-2というコードセットだったのです。

UTFというのは、UCSを直接扱えない場合に、
エンコードして文字単位を変更するための規則です。
UCS-4はuint32_tを文字単位とすれば
エンコードなどせず生のまま扱うことが出来るのです。

Unicode 3.1で拡張されたときには、
既にUCS-2を採用した処理系が存在しました。
そういうものをUCS-4で書き直すのは困難なので、
16bit可変長でUCS-4を表現できるように
UTF-16というものが作られました。

ここに至って、uint16_tが文字の単位となる処理系では、
どんな文字でも2バイトで表現できるという前提が崩れました。
SJISの場合と同じことになってしまったわけです。

(続く)
252ひげぽん ◆Ngzcp/NZpA :04/02/15 18:43
ご指摘の通り間違えました。
×:UCS4は文字コードセットの集合で
○:UCS4は文字コードセットで
253248:04/02/15 18:44
ここまで書けば↓には特に問題ないことがお分かりでしょう。

> > 内部処理にUTF-8みたいな可変長コードを使うのは最悪。
> > Unicode 3.1でサロゲートが出てきた現在UTF-16でも同じ問題になる。
> > 固定長ならUCS-4しかない。

UTF-8を内部処理にまで全面的に採用してしまったら、
文字単位で切り出したりするのが難しくなります。
いちいち順番に追っていきながら、
"A"は1バイト、"あ"は3バイトというように、
数えながら処理する羽目になってしまうのです。

以前(UCS-2)なら16bitあればすべて事足りましたが、
今ではUCS-2はUTF-16という可変長の体系に
強制的に移行する羽目になってしまいましたので、
今から文字処理の単位を定義するのであれば、
UCS-4がそのまま扱えるuint32_tしかないという話です。

ただし本当はそんなに単純ではありません。
>>239-240に書いてあるような難しい処理もあります。
ですが合成文字を文字の単位と考えずに
単なる表示のときの問題だと考えれば後回しにしても構いません。
後で超漢字のような多言語処理を実装したくなってからやれば良い話です。

というわけで>>246の結論と矛盾しませんし、
個人的には>>246の意見に賛成です。

(終了)
254ひげぽん ◆Ngzcp/NZpA :04/02/15 18:57
>>248さん
丁寧な解説ありがとうございます。
ご説明の内容理解できたと思います。

> というわけで>>246の結論と矛盾しませんし、
> 個人的には>>246の意見に賛成です。

これも了解いたしました。ありがとうございます。
255Be名無しさん:04/02/15 19:06
昔、IBMとAppleが共同で新OSを作ろうとして、
Taligent社という会社を設立しました。
その会社が作っていた新OSを"Pink"と言います。
しかし結局は失敗に終わる結果となりました。

なぜこんな話をしたかと言いますと、
Pinkのコードのうちロカールに関係する部分だけが
な、な、なんと、MIT/Xライセンスで公開されているのです!!
http://oss.software.ibm.com/icu/

企業が作っていたOSの次世代ロカール機構ということもあり
あまりにも巨大なライブラリですが、
部分的にでもうまく流用することが出来ればよいと思います。

文字コード処理に関しては、フリーで手に入るものの中で、
文句なしに最高峰のものです。
256ひげぽん ◆Ngzcp/NZpA :04/02/15 19:07
Mona ver.0.1.5をリリースしました。

■ダウンロード
ttps://sourceforge.jp/projects/mona/files/

■リリースの詳細
ttps://sourceforge.jp/projects/mona/document/mona_mona0_1_5_-_Notes/

■現在のMonaの仕様
ttp://mona.sourceforge.jp/dynamic/pukiwiki/pukiwiki/pukiwiki.php?Mona%2F%A5%B9%A5%DA%A5%C3%A5%AF

■動作・不具合報告版
ttp://monaos.hp.infoseek.co.jp/cgi-bin/2ch/test/read.cgi/developmona/1076835760/l50

動作・不具合報告にご協力をお願いいたします。

このスレでアドバイスを下さったすべてのななしさんに
この場を借りてお礼を申し上げます。
ありがとうございます。これからもよろしくお願いいたします。
257Be名無しさん:04/02/15 19:23
>>256
おめでとうございます!
記念あげ

誰かスラドへのタレコミよろしくーー
258Be名無しさん:04/02/15 19:31
リリースキタ─wwヘ√レvv〜(゚∀゚)─wwヘ√レvv〜─ !!
259Be名無しさん:04/02/15 19:31
垂れ込みなのか?
もう一段階、安定してアプリが作れるようにならないと厳しくない?
260Be名無しさん:04/02/15 19:33
>>259
SORAとかおれぺこですら垂れ込まれたんだから大丈夫じゃない?
宣伝して名前くらいは知ってもらわないと。
261Be名無しさん:04/02/15 19:39
>>260
本人にうれしいかどうか聞いてみる?
逆のことをするといやがらせできるかもっ!
262Be名無しさん:04/02/15 19:51
osask、nwsos、meg-osの作者達といった濃ゆい連中にもまれて成長を続け、
ついにここまでのモノに。
263Be名無しさん:04/02/15 20:01
スラドたれこみ賛成
タレこみ方知らないけどね
264Be名無しさん:04/02/15 20:02
超スパルタww
265Be名無しさん:04/02/15 20:02
>>263
↓に必要事項を書き込むだけ。
http://slashdot.jp/submit.pl
266Be名無しさん:04/02/15 20:11
267263:04/02/15 20:15
>>265
サンクス
でも誰かたれこんでくれー。
自信ナシ
268Be名無しさん:04/02/15 20:21
>>261
今回のリリースは>>160-164を踏まえてのものだろう。
だとするとそれを聞くのは無粋ってもんよ!
269Be名無しさん:04/02/15 21:05
リリースキタ─wwヘ√レvv〜(゚∀゚)─wwヘ√レvv〜─ !!
270Be名無しさん:04/02/15 21:18
まじですげぇな。
MONAってもっとしょぼいかと思ってたよ。
これはすげぇ。
271ひげぽん ◆Ngzcp/NZpA :04/02/15 22:11
>>257さん
ありがとうございます。

>>262さん
確かにその方々にはお世話になりましたねぇ。
すごい人たちです。

スラドですが普段あまりみていないのですが
投稿?して頂けるのであれば誇張・誤解の無いようにしていただければ
ありだと思います。
272Be名無しさん:04/02/15 23:50
スラドo(・∀・)oマダー?
273鳥取砂丘?ソーュキサルイハ (゚听)? ■Dream/3P/. :04/02/15 23:58
キュンキュン
偽者(゚听)イクナイ!!
275鳥取砂丘<>Dream/3P/:04/02/16 00:05
ゴメン
276Be名無しさん:04/02/16 00:32
>>262
> osask、nwsos、meg-osの作者達といった濃ゆい連中にもまれて成長を続け、
> ついにここまでのモノに。

禿同
神々にかなり肉薄しているとおもう
277Be名無しさん:04/02/16 01:19
>神々にかなり肉薄しているとおもう
誠実で勉強熱心なのが超スパルタを乗り越えた秘訣だろうね。
Unicodeの件でもすぐに勉強して理解する姿勢を見せたことで
初心を貫き通していることを確認して感動した。
278Be名無しさん:04/02/16 01:43
誠実で勉強熱心かは知らんが。
こんだけ続いたのって、なんか凄い事だなと思う。
めぐり合わせがもの凄く良いんだよな。
ひげぽんは人に恵まれてるよ。
色々な出来事が連鎖して、人が人を呼んでて。
279Be名無しさん:04/02/16 02:22
>色々な出来事が連鎖して、人が人を呼んでて。
そういうのって人徳だと思うなー
280Be名無しさん:04/02/16 06:27
おまいら卑下は叩かないと成長せんぞ。これからもがんがん叩かねば。
281Be名無しさん:04/02/16 14:50
つーか、
Bochsは24bitに対応していても、Xが16bitなので困っておるのですよ。
ブートオプションを渡せるようなkernelにしたらどうですか。GRUBとかもあることだし。
それとディレクトリの構造はどうするの?
俺的にはBeとNeXTを足して2でわった風味がいいけど。
282Be名無しさん:04/02/16 17:12
スラドキタ─wwヘ√レvv〜(゚∀゚)─wwヘ√レvv〜─ !!
http://slashdot.jp/article.pl?sid=04/02/16/0759224&topic=106&mode=thread&threshold=-1
283Be名無しさん:04/02/16 17:22
スラドに載ってるぞ!
すげぇすげぇ
284Be名無しさん:04/02/16 17:47
スラッシュドットから来ました。
正直感動しました。
これからも頑張ってください。
285Be名無しさん:04/02/16 17:54
私もスラッシュドットからきました。

このスレがPart2ぐらいのときにみた記憶があるんですが、それ以来です。







あれは冗談ではなかったんですか?
すごいです・・。
286Be名無しさん:04/02/16 18:24
記念カキコ
287Be名無しさん:04/02/16 19:36
俺も感動しました!
ほんますごいです。
がんばってください!
288Be名無しさん:04/02/16 20:04
さて、これが幾らかでも新しい流れを作れると良いんだけどな。
289Be名無しさん:04/02/16 20:23
こりゃまたずいぶんとKの子がお盛んですね
290Be名無しさん:04/02/16 20:46
>>289
まあ、予想されたことなんですが・・・
291Be名無しさん:04/02/16 21:04
NWSOSの時との扱いの違いが笑える
292Be名無しさん:04/02/16 21:07
売り物って事で不評だった点以外ではあまり変わらんかと。
ネタとしては良し、実用なんてつまらん事を言う奴は氏ね、みたいな。
293Be名無しさん:04/02/16 21:09
Kの子はあれでOSASK方面が荒らし返されないと思ってるのが不思議だよな。
294Be名無しさん:04/02/16 21:23
Mona派とOSASK派の内ゲバが始まったのか?
 _, ._
( ゚ Д゚)中立砂丘
296ひげぽん ◆Ngzcp/NZpA :04/02/16 21:31
>>281さん
> Bochsは24bitに対応していても、Xが16bitなので困っておるのですよ。
> ブートオプションを渡せるようなkernelにしたらどうですか。GRUBとかもあることだし。

はい。将来的にはそうしたいです。
VESA16bitの件ですが、現状では24bitモードに対応しているPCでは
24bitになってしまいますねぇ。
解決する方法は残念ながら現時点ではsecondboot.asmを書き換えて
リビルドしかないです。

> それとディレクトリの構造はどうするの?
> 俺的にはBeとNeXTを足して2でわった風味がいいけど。

まだ白紙状態です。
残念ながら上記二つは触ったことないのでわからないですm(__)m

>>282さん
読みました。より多くの人に知ってもらえてそれが
プラス方向に作用するといいですねぇ。

>>284さん
>>287さん
ありがとうございます。
297Be名無しさん:04/02/16 21:45
ドライブレター丸出しとかパスセパレータが/以外とかはやめてほしい
298Be名無しさん:04/02/16 21:49
最近OSASK派からMona派へ転向する人が目立つが、二度と戻れぬ橋を
渡っているような気がする。
299Be名無しさん:04/02/16 21:54
そんな重いもんじゃねーって。
マからすれば自分が能力を発揮出来る機会があればどこでも良い。
300Be名無しさん:04/02/16 22:06
>>299
意味がちょっと違うんじゃないかな。
Monaのわけのわからない楽しさを味わってしまったら、
OSASKが色あせて見えちゃうぞ!ってことかと。
301Be名無しさん:04/02/16 22:08
まーそういう結果はありえる。
しかしわざわざ言って煩いのを呼ぶのもどうかと。
302Be名無しさん:04/02/16 22:21
OSASKは中高生の課外活動としても適当だけど、Monaの場合は
珍走団の集会に参加するみたいなレベルだから。
世間を知らないお子様には推奨しかねる。
303Be名無しさん:04/02/16 22:31
>>300
ちうか、OSASKは動きがないからの〜。
勢いのある方に人が集まるのは当然だろう。

>>302
OSASKの妙な環境になれた人材つーのも困り者だが。
304Be名無しさん:04/02/16 22:32
Kの某が入り込んだら大変だ
305Be名無しさん:04/02/16 22:41
Kの子ってMonaに敵対してなかったはずだが。
OSASKをハックできるようになりたいって言ってたから、
とりあえずMonaをコンパイルしてBochsで動かしながら
ソースをいじってみろって言われて、
素直に実行してレポートしてたからね。(除くソースいじり)
それ以来、特にMona側と衝突してないから恨みを持ってるとは考えにくい。
306Be名無しさん:04/02/16 22:43
ひげぽんの場合、本人が「スタックって何?」ってな所から始まってるから、
周りの人間も口出ししながら一緒に勉強してくって雰囲気を作りやすいんかね。

>>305
この板のMonaスレの1をミロ。
307Be名無しさん:04/02/16 22:47
>この板のMonaスレの1をミロ。
スレが無視されて逆恨みって線か……
あいつならあり得る。。。
308Be名無しさん:04/02/16 22:48
/.見て来ましたー!
スゲースゲー!
記念下記子
309Be名無しさん:04/02/16 22:57
>>306
> ひげぽんの場合、本人が「スタックって何?」ってな所から始まってるから、
> 周りの人間も口出ししながら一緒に勉強してくって雰囲気を作りやすいんかね。
今でも変わらないよね。
新しい事(Unicodeとか)が出て来ると同じような展開になって、
知らない人は読むだけでもひげぽんと一緒に勉強してる気分になるかも。
310ひげぽん ◆Ngzcp/NZpA :04/02/17 00:46
FD読み込みが遅い原因ぽいモノをつかみました。

LBA1-10 * 20回読み込み22秒に対して

FD読み込みだけに専念(FDC割込み以外マスク)シングルプロセス
で同じ読み込みをしたら5秒でした。

つまりタイムスライスを含めたスケジューラーの問題のようです。
311ひげぽん ◆Ngzcp/NZpA :04/02/17 00:53
そうすると。2月中は
スケジューラ改良
GUIをまったり設計
Screen,FSのインターフェース・メッセージプロトコル検討という
作業内容になりそうです。
312Be名無しさん:04/02/17 02:17
>>256
リリースソースはexportしてCVSディレクトリは取り除いてね。
part5で指摘されてることだけど。

248 名前: henoheno@おさらい ◆mXrBwDDzyw [sage] 投稿日: 03/02/02 23:05
 ソースを公開する際は、"cvs co" のかわりに "cvs export" コマンドで
ソースを取り出したものをお使い下さい。(具体例は >>219)
 exportコマンドを使えば 'CVS' というスペシャルディレクトリとファイルを
含まない、ほぼ純粋なソースを取り出す事ができます。

 下手に "cvs co" を使うとそのユーザーの作業環境が漏れたり、
CVSサーバーの所在が漏れたり、そのソースに他の人が作業した
際に扱い辛くなったり、そのソースを別のリポジトリに追加しようと
した人が泣く事に繋がります。

 なお、最新のファイルをexportする時は "cvs export -D tomorrow "
でどうぞ。
313Be名無しさん:04/02/17 02:20
>>187
「オセロ」の名称はツクダオリジナルの登録商標だから勝手に使うとまずいよ。
一般名詞としては「リバーシ」を使う。
だからWinXP付属のやつも「インターネット リバーシ」ってなってる。
314Be名無しさん:04/02/17 02:52
>>256
user/includeだけど、ヘッダのパスにはすべてのアプリに共通なものだけ置いて、
特定のアプリのヘッダはソースと同じディレクトリに置くのが普通。
315314:04/02/17 03:04
それで共通のヘッダについてだけど、
可能な限り1クラス1ヘッダにした方が親切。
ハックしようとしてまずディレクトリを検索ってなると面倒。

userlib.hにC関数の宣言を書いてuserlib以下の全クラスをincludeすれば、
今のものとソース互換は保たれる。
いちいち1つのヘッダにするほどでもないクラスはuserlib.hに入れてもいいけど。

[例]
include/userlib.h
include/userlib/MonaApplication.h
include/userlib/Date.h
include/userlib/Color.h

collection.hなんかも同様。

C++でヘッダが巨大になって来るとg++はむちゃくちゃコンパイルが遅くなるので、
(QtとGTK+で何かアプリを作ってコンパイル速度を比べると一目瞭然)
クラスごとにヘッダをわけて、利用時には必要なクラスだけincludeするのが普通。
MFCでそうなっていないのはプリコンパイルヘッダのお陰。
もっともgcc 3.4でプリコンパイルヘッダがサポートされるから、
スピードの問題は将来的には気にならなくなるだろうけど。
316Be名無しさん:04/02/17 03:17
int MonaMain(List<char*>* pekoe) {
  monaApp = new myApplication("HELLO.ELF");
  monaApp->main(pekoe);
  return 0;
}

main()も本当はクラスから始めたいけど便宜上こうしてるんだと思うけど、
それならそのままreturnさせた方が自然じゃないですか?

int MonaMain(List<char*>* pekoe) {
  monaApp = new myApplication("HELLO.ELF");
  return monaApp->main(pekoe);
}
317Be名無しさん:04/02/17 03:44
>>256
リリースイメージのバイナリがstripされていませんね。
strip *.ELF *.SVR
とすると不必要なシンボルが取り除かれてバイナリが小さくなります。

Mona特有の制約があるのかな〜と思いつつ試しにstripして動かしてみましたが、
特に問題なく動いているようです。
318Be名無しさん:04/02/17 03:46
どうでもいいことだけど、オセロの画面は8bit時代を彷彿とさせますね。
20年くらい前にBASICから入った人達は郷愁を覚えるかもしれません。
319Be名無しさん:04/02/17 07:38
BASICを移植だ。
  _, ._
( ゚ Д゚)さっきゅんは様子を伺ってゐる
321 ◆7a6JaqYY2A :04/02/17 14:00
つーか、Monaスレ立てた1haVRBは偽物だぞ。
322 ◆SffiloLYWA :04/02/17 14:02
test
323Be名無しさん:04/02/17 21:57
YuiNekoさんというのは、かの逆汗大王のあの人ですか。
意外と色んな人がいるなぁ……。
324ひげぽん ◆Ngzcp/NZpA :04/02/17 22:18
>>312さん
> リリースソースはexportしてCVSディレクトリは取り除いてね。
> part5で指摘されてることだけど。
御指摘ありがとうございます。その通りですね。
同じ間違いをしないようにWikiにまとめておきました。>リリース手順
>>313さん
> 「オセロ」の名称はツクダオリジナルの登録商標だから勝手に使うとまずいよ。
> 一般名詞としては「リバーシ」を使う。

うすうすは気づいていたのですがやはりまずいですよねぇ。
Reversiに変更しました。

>>314さん
貴重なアドバイスをありがとうございます。
src/user/以下
ヘッダ・ソースツリーを大幅に変更しました。

>>316さん
本当ですね。hello.cpp, reversi.cppを修正いたしました。

>>317さん
御指摘ありがとうございます。
どうもサイズが大きいなとは思っていたのですが
失念しておりました。

>>319さん
移植されたら面白いかも。

>>320 鳥取砂丘さん

そちらの様子はどうですか?
>>324
 ∧||∧
(  ⌒ ヽ フロッピーが遅い!ナントカ汁!
 ∪  ノ
  ∪∪
326ひげぽん ◆Ngzcp/NZpA :04/02/17 22:33
>>325 砂丘の人
じゃあ共同チューニングしましょう(ぇ

src/user以下のディレクトリツリーの整理は大変でした。
cvsはちょっとつらいかなぁという感じでした。
subversionだったらもう少し楽ですかね>ファイルの移動
327Be名無しさん:04/02/17 22:45
>>326
> src/user以下のディレクトリツリーの整理は大変でした。
お疲れ様でした。

> cvsはちょっとつらいかなぁという感じでした。
しょっちゅう作り直しに近いようなリファクタリングをするのに
CVSはあまり向いていない気はしないでもないですね。
Linus氏がCVSに縛られるのを嫌がっていたのも分かる気がするかもしれません。
単なるリリース履歴として登録するだけならあまり気にならないのでしょうけど。

> subversionだったらもう少し楽ですかね>ファイルの移動
使った事がないので何とも言えませんが、
自前サーバを用意しないといけないのがネックですかね。
>>326





 _, ._
( ゚ Д゚)
329ひげぽん ◆Ngzcp/NZpA :04/02/17 23:47
>>327さん
ありがとうございます。

> 自前サーバを用意しないといけないのがネックですかね。
そうですね。sf.jp対応してくれないかなぁ。

スケジューラですが。スケジューリングアルゴリズムをいくつか勉強する
ところからはじめようかと思います。

実装面で言うとキュー(readyキューなど)のデータ構造に伝統的なCのリスト構造
にすべきか。templateでcollectionクラスを活用するか迷いますねぇ。
330Be名無しさん:04/02/17 23:53
試しにSFに言ってみよー。
331Be名無しさん:04/02/17 23:56
>>329
>実装面で言うとキュー(readyキューなど)のデータ構造に伝統的なCのリスト構造
>にすべきか。templateでcollectionクラスを活用するか迷いますねぇ。
両方試してみて速い方にすればいいだけでは?
結局ベンチしないと分からないって。
332Be名無しさん:04/02/17 23:58
>>329
>そうですね。sf.jp対応してくれないかなぁ。
>>330
>試しにSFに言ってみよー。
実地でテストして使用感を調べもせずに他力本願でどうする。
使ってみたら想像したのと違ったら対応のための労力はどうなるの?
333ひげぽん ◆Ngzcp/NZpA :04/02/18 00:02
>>330さん
お手数おかけいたします。

>>331さん
実測が一番だとわかっているんですが
2通り実装する覚悟がw
334Be名無しさん:04/02/18 00:08
>>332
>使ってみたら想像したのと違ったら対応のための労力はどうなるの?

わたし、ひげぽんにとって、なんなのよっ!!
ねぇ? ひげぽんにとって、わたしはなんなの……。
単なる、フリーサーバなの?
ねぇ、教えてよっ!! ひげぽんにとって、わたしはなんなの!?

ひげぽんとの空白の時間……。
それを取り戻そうと、わたしは必死だったんだよっ
そして、わたしも変わろうと必死だった。
過去のわたしじゃなく、新しいわたしになろうと必死だった
そうすれば、ひげぽんはわたしに振り向いてくれるんじゃないか……。
フリーサーバのわたしじゃなくて、新しいわたしなら、
ひげぽんは振り向いてくれるんじゃないか、って思ったの……っ
335Be名無しさん:04/02/18 00:11
>>333
>お手数おかけいたします。
>>330は「自分がやる」じゃなくて「お前がやれ」だと思うが。
336Be名無しさん:04/02/18 00:16
>>335
そんなことはないと思うけど。
337Be名無しさん:04/02/18 00:19
>>333
>2通り実装する覚悟がw
捨てる羽目になるのを覚悟でやれって「人月の神話」に書いてあったでしょ。
338Be名無しさん:04/02/18 00:30
>>335
わかっててわざと天然ボケを装うのが卑下の戦略なんだよ
339330:04/02/18 00:50
>>332
まあ言われてみりゃそーだ。

>>335
勿論「お前がやれ」のつもりで言ったw
でもそれが実際に必要な事で、他にやるのがいなければ俺がやるしか無いね。
誰が言ったって大差無いって。手間的にも。

>>338
ひげさんはその辺鮮やかだよね……。
340Be名無しさん:04/02/18 18:49
某家電(量販)店が無償で配布されているオープンソースソフトウェアを自社開発と称して
自店商品の機能向上を謳って抱合せ販売していた模様。
また、この店ではオープンソースソフト単独でも販売し利益を得ていたようです。
開発元には、クレーム等の連絡先として開発者のメールアドレスを勝手に表記されていた為、
問い合わせメールが殺到し開発者のWebページが閉鎖に追い込まれています。(2004/2/16現在)
【店の身勝手で阿呆な言い分】
「これで有名になったんだから良かったと思ったほうがいい」
「ユーザーサポートの費用払ってやってもいい。
 その代わりソフトの権利はウチの会社でもらう。月1000円」
「所詮タダで配ってるソフトだから誰の著作権も何もない、
 ウチでつくってるといえばウチのもんだよ。」
詳しくは下記スレにて熟知せよ。
http://news4.2ch.net/test/read.cgi/news/1077067632/
341Be名無しさん:04/02/18 20:31
>>256
リリースのイメージのSAMPLE.TXTって何ですか?
(日付関連の実装の一部ということは分かりますが)
342Be名無しさん:04/02/18 22:11
>>340
売るのは別にかまわんだろ。
343Be名無しさん:04/02/18 22:15
>>342
そりゃライセンス次第だ
344Be名無しさん:04/02/18 22:16
売る事じゃなくてサポートの連絡先を無関係の人間のところにしたのが問題。
345ひげぽん ◆Ngzcp/NZpA :04/02/18 22:34
>>335さん
>>339さん
失礼いたしました。
時間のあるときにリクエストしてみます。

>>337さん
> 捨てる羽目になるのを覚悟でやれって「人月の神話」に書いてあったでしょ。

そのとおりですね。まあ弱音を吐いてみました(笑)
がんばります。

>>341さん

> リリースのイメージのSAMPLE.TXTって何ですか?

src/syscalls.cppの一部です。
現在時刻の取得をしているところです。RTCですね。

スケジューラ周りのことで悩んでいることがあるのですが
過去の自分の発言を引用します。
346ひげぽん ◆Ngzcp/NZpA :04/02/18 22:35
342 名前: ひげぽん ◆Ngzcp/NZpA 投稿日: 03/11/22 17:41

スレッド周りでいまだ良く理解できていないのがスレッドのスイッチ部分です。
スレッドとは論理的に並列処理可能な実行の最小単位とここで定義したとすると

カーネル空間スレッドを実装した場合、ラウンドロビン方式で
スケジュール&スイッチした場合、当然プロセス空間の切り替えが頻繁に
起こる可能性があるように思えるのです。
(いろいろな空間に属するスレッドたちがただ並んで順番に実行されるだけなので)

スレッドの利点とは、同じプロセス空間に属するスレッド間でのスイッチの場合
プロセス空間の切り替えをしなくてすむので軽いというのがあると思います。

できるだけプロセス空間の切り替えが少なくなるようなスケジューリングポリシーを持って
スケジュールしているということなのでしょうか?
347ひげぽん ◆Ngzcp/NZpA :04/02/18 22:35
引用ここまで

スケジューラーの再設計をしていて思ったのですが
上の様なことを想定して現在のMonaでは

-------------------------------------------------------------------------
プロセススケジューリング(ラウンドロビン)

プロセスの持ち時間だけスレッドスケジューリング(ラウンドロビン)
(同一空間でのスレッドスイッチなので空間切り替えがなくて切り替え処理軽い)
-------------------------------------------------------------------------

ところが今回設計していて思ったのは
プロセスのスケジューリングが邪魔。
同一空間での切り替えにこだわって不必要なスレッドがスケジューリングされそう。
ということでした。

たとえばプロセスAにはI/Oスレッドと通常のスレッドがあるとします。
I/Oはほとんどが「待ち」状態なので待っている間は
CPUを他のスレッドに譲ります。(wait sleep)
348ひげぽん ◆Ngzcp/NZpA :04/02/18 22:36
そのかわりI/O割り込みなどがあった場合は即応答したいので
高い優先度を持って再スケジュールされます。(wake up)

このとき上記のプロセススケジューリングも伴う場合
ひきづられて通常スレッドもなんだか知らないうちに
優先度が上がったように見えます。

もちろんうまく書けばこのようなことは起こらないかもしれませんが。

素直にスレッドのみのスケジューリングにしたほうが
すっきりするような気がしてなりません。

こういう場合の定石とかってあるのでしょうか?
349Be名無しさん:04/02/18 23:42
>>345
> 時間のあるときにリクエストしてみます。
その前にローカルで使って、その上でサポートされたら嬉しい理由を書かないとお話にならない。
使いもせずに推測だけで人に頼むと>>334みたいな気分になるだろ。

自分が逆の立場になって考えてみ。
Monaに理由も書かずに意図が分かりかねる要求をされたりしたら無視するだろ。
350Be名無しさん:04/02/18 23:48
>>345
> src/syscalls.cppの一部です。
それは分かってるんだが↓
>>341 > (日付関連の実装の一部ということは分かりますが)
なぜリリースに何の説明もなく含まれているのかなと思った、ということ。

>>346-348
そういうことを聞きたくて含めたならSAMPLE.TXT内にちゃんと書いて。

>>348
> こういう場合の定石とかってあるのでしょうか?
Solarisですら8から9で実装が大きく変わったのは、
最適な実装は試行錯誤するしかないってことでは。
もちろんSolarisレベルになると数学的なモデルで計算した上で
実装に移るだろうから単なる当てずっぽうの試行錯誤とは雲泥の差がありますが。

理論による定量的な予想と実装した上でのベンチ。
真面目にチューニングしたいならこれしかない。
Lたんがアルゴリズムの分析をしているのは何のためだと思ってる。
351ひげぽん ◆Ngzcp/NZpA :04/02/18 23:57
>>349さん
>> 時間のあるときにリクエストしてみます。
> その前にローカルで使って、その上でサポートされたら嬉しい理由を書かないとお話にならない。
> 使いもせずに推測だけで人に頼むと>>334みたいな気分になるだろ。

あぁすいません。時間のあるときにと書いたのはsubversionを試してみてからと
書くのを忘れてました。誤解させてしまい申し訳ありません。

>>350さん
> なぜリリースに何の説明もなく含まれているのかなと思った、ということ。

TYPE.ELF SAMPLE.TXT
でファイル内容を出力するときのサンプルテキストです。
それ以外の意図はありません。うーん誤解を招きやすかったかも。

> >>346-348
> そういうことを聞きたくて含めたならSAMPLE.TXT内にちゃんと書いて。

とはどういうことでしょうか?

> もちろんSolarisレベルになると数学的なモデルで計算した上で
> 実装に移るだろうから単なる当てずっぽうの試行錯誤とは雲泥の差がありますが。

ありがとうございます。
そうですね。上の方で述べたアドレス空間切り替えの件をどこかの資料で
よんだのですが忘れてしまいました。

とりあえず一般的といわれるアルゴリズムを勉強・選択して実装・計測してみます。
352Be名無しさん:04/02/19 00:00
>>348
MonoのOSとしての特性次第じゃないかな。
ITRONやVxWORKSのようなリアルタイムOSにしたいのか、それとも
Windows NTや普通のLinuxみたいにリアルタイム性はそこそこに、
大容量のリソースを扱える汎用OSにするかなどで違ってくると思う。
もちろん、うまくバランスをとってオールマティーなOSを目指す
ってのもありだと思うが…。
353Be名無しさん:04/02/19 00:01
>>350
こいついつも偉そう!何様!
卑下もよく耐える(藁
354Be名無しさん:04/02/19 00:05
>>351
> TYPE.ELF SAMPLE.TXT
> でファイル内容を出力するときのサンプルテキストです。
> それ以外の意図はありません。うーん誤解を招きやすかったかも。
最初からこう答えずに、スケジューラで悩んでいると書かれたら、
誰だって問題点を明示する意図があったと思うでしょう。

> とはどういうことでしょうか?
前述のようにスケジューラについて悩んでいて、
それもあってサンプルに選んだのであれば、
SAMPLE.TXTに>>346-348のようなことを書けば良かったということ。

>>353
> こいついつも偉そう!何様!
オマエモナー
355Be名無しさん:04/02/19 00:06
>>352
> MonoのOSとしての特性次第じゃないかな。
MonoじゃなくてMona。
MonoはNovellに買収されたXimianが作ってる.NET互換実装。
356Be名無しさん:04/02/19 17:13
卑下はいつまで自作自演を続け(ry
357さ っ き ゅ ん:04/02/19 19:15
  _, ._
( ゚ Д゚)さっきゅんが自作自演に興味をもっていらっしゃるようです。
358ひげぽん ◆Ngzcp/NZpA :04/02/20 20:03
>>352さん
> MonoのOSとしての特性次第じゃないかな。

ありがとうございます。
Monaはどちらかというと汎用OSを目指しています。

>>354さん
いろいろ紛らわしくて申し訳ありませんでした。

アプリ登録所に登録があったMONAFONT.ELFで
勉強していました。

あまりの内容の濃さにカルチャーショックを受けました。
現在消化中です。
359Be名無しさん:04/02/20 23:14
part2から見ています。
最近のMonaの爆発ぶりにはただただ驚いています。
ソースを見る限りカーネルの大部分はおひとりで書かれているようですが
すごいパワーです。part2を見直すとあんなに素人だったのに(笑)

APIも目を通しましたがまだ進化中ながら
オブジェクト指向でわかりやすいと思いました。

これからもがんばってください。
アプリあたりで貢献できたらと思っていますが。

アプリケーション作成方法とかが少しでも分かれば良いですね。
ひげさんにはカーネルに注力してもらいたいので当分先かもしれませんが。
360Be名無しさん:04/02/20 23:33
このあたりがすごい。
Pointer<Screen> scr = new Screen();
Pointer<Font> mona_12 = new Font(MONA_12_MNF);
361Be名無しさん:04/02/21 00:12
>>360
C++なのにJavaみたいってのを狙ってるらしい。
newしてるのにdeleteしなくても良くなる、みたいな。
362Be名無しさん:04/02/21 00:28
MonaOSにMonaFontっていうネタだろ
363Be名無しさん:04/02/21 00:41
Monaも気を付けないといけないね
http://www.itmedia.co.jp/news/articles/0402/20/news049.html
364Be名無しさん:04/02/21 08:57
現状のMONAってユーザランドからのIOとかハードウェア割り込みの
ユーザランドへの通知とか可能なのでしょうか?
365ひげぽん ◆Ngzcp/NZpA :04/02/21 12:03
>>359さん
ありがとうございます。
アプリの作成方法ですが、アプリ登録所のソースを
見ていただくのが良いとおもいます。

画面に文字を表示する方法・絵を書く方法
キーやマウス入力を知る方法などソースを読めば
なんとなくつかめるかと思います。

>>360さん
ほんとにすごいですね。良いソースにあうと刺激を受けます。
Pointerクラスはじっくりと眺めてやっと何を意図するもの
なのか気づきました。

>>363さん
そうですね。
現在のカーネルはセキュリティ的には穴だらけだと思います。
徐々にふさいでいきます。
366ひげぽん ◆Ngzcp/NZpA :04/02/21 12:04
>>364さん
> 現状のMONAってユーザランドからのIOとかハードウェア割り込みの
> ユーザランドへの通知とか可能なのでしょうか?

ユーザーランドからのIOは可能です。(ただし全許可)
まだシステムコール化していないのでご要望があれば
追加します。

将来的には全許可ではなく種々の制限を設ける予定です。

ハードウェアの割込み通知は可能です。
現在マウス・キーボード割り込みをMessenger::sendで
ユーザーモードサーバに通知して処理しています。
(send部分はカーネルのソースに埋め込まれています)
367Be名無しさん:04/02/21 22:17
MONAの面白いところは実機よりエミュレータで動かした方が快適だというところ
368Tino ◆sMrLqQHxo6 :04/02/21 22:24
>>360-361 >>365
狙いに気付いていただいてありがとうございます。

>>362
それを言ったらおしまいです。
369ひげぽん ◆Ngzcp/NZpA :04/02/21 23:58
>>367さん
> MONAの面白いところは実機よりエミュレータで動かした方が快適だというところ

これは気づきませんでした。
開発の中心がエミュレータなのが原因ですね。
まあ。いづれ実機でも快適になります(笑)

>>Tinoさん
大変勉強になりましたこれからもよろしくお願いいたします。


さて今日はスケジューラのアイデアがいまいち湧いてこないので
実装の材料をそろえていました。

イメージとしてはスレッドのキューが優先度の種類分あります。
で、それぞれのキューは双方向リストで実装。
そのキューたちをArray<Queue>で保持という形になります。

Queueクラスを実装してThreadはそれを継承する形にしました。

全てのキューの全てのスレッドに対して何らかの操作を順番にしたいときは
Tinoさんのマクロとそれのまねをした双方向リスト用のマクロで以下のように
書けるようにしました。

FOREACH(Thread, queue, all)
{
    FOREACH_Q(queue, Thread*, thread)
    {
        thread->getThreadInfo();
    }
}
370364:04/02/22 02:36
>>366

全許可なのは、現状を考えるとありがたいです。
何か作ったりしましたら報告します。
371ひげぽん ◆Ngzcp/NZpA :04/02/22 03:13
>>364さん
I/O全許可用のシステムコールを作成しました
(いまいち動作確認できておりませんが・・・)

system_call_get_io(); これを一度呼ぶとI/O全許可されます。
CVS最新版のカーネルで使用可能です。

src/user以下のディレクトリ構成がアプリケーション毎にディレクトリを分けるように
いたしましたので念のためお知らせいたします。
372ひげぽん ◆Ngzcp/NZpA :04/02/22 03:19
補足です。
> 全許可なのは、現状を考えるとありがたいです。
> 何か作ったりしましたら報告します。

仕様が多少流動的であったりして、分かりづらいところもあると思いますが
ここ、もしくはWikiで聞いていただければ出来る限り答えますので
よろしくお願いいたします。

たくさんの方にMonaに触れていただくことでカーネルやAPIのダメなところが
見えると思います。皆様ご協力をお願いいたします。
373Be名無しさん:04/02/22 15:16
&nbspうざい。
374Be名無しさん:04/02/22 17:39
>>228
> Meadow2を使っています。
> utf-から始まるコマンドは見つかりませんでした。
Meadow2は知りませんが、Meadow1ではMule-UCSが必要です。
なお、Mule-UCSの作者はMeadowと同じ宮下さんです。
http://kawacho.don.am/win/meadow/mule-ucs/mule-ucs.html
375Be名無しさん:04/02/22 17:45
ひげぽんってJavaでもC++でもEclipseを使ってるのかと思ってた。。。
376ひげぽん ◆Ngzcp/NZpA :04/02/22 17:49
>>373さん
私の張ったソースでしょうか?

>>374さん
ありがとうございます。
.emacsでコメントアウトされている
(require 'un-define)
(setq bitmap-alterable-charset 'tibetan-1-column)
(require 'jisx0213)

を生かしたらUTF-8なども使えるようになりました。
netinstallしたときにデフォルトで入っていたようです。
ありがとうございました!!
377375:04/02/22 17:51
>>376
単純な興味なんだけど、どうしてEclipseを使わないの?
仕事でEclipseとか使うんじゃ?
378ひげぽん ◆Ngzcp/NZpA :04/02/22 18:04
>>375さん
仕事ではjavaはやらないですねぇ(笑)

eclipseへの移行も考えましたがマシンパワーと
eclipseがでたのが、秀丸→Meadowの移行した直後だったので
なんとなくMeadowのままです。
379Be名無しさん:04/02/22 18:10
380Be名無しさん:04/02/22 18:18
相互リンク

OSを作ろうpart9(本スレ)
http://pc2.2ch.net/test/read.cgi/tech/1076217479/l50

【集え!!】OSを作ろうpart9【低学歴】(オチスレ)
http://pc2.2ch.net/test/read.cgi/tech/1076215520/l50

OSを作ろうpart8(OS板出張所)
http://pc.2ch.net/test/read.cgi/os/1076216434/l50
381Be名無しさん:04/02/22 18:21
OS作りで得た知識とかってリアルの方では役立ってんの?
382Be名無しさん:04/02/22 18:36
アセンブラの知識くらいは役に立つんじゃない?
383Be名無しさん :04/02/22 19:24
XBOX風の外見のOS作って
384ひげぽん ◆Ngzcp/NZpA :04/02/22 22:26
>>379さん
改宗は徐々に行われると思いますw

>>381さん
コンスタントにコードを書くということで多少は技量が
上がったという程度くらいしか直接は役にはたたないですね。

>>383さん
外見は自由に変えられるようにしたいですね。

今日もだらだらとスケジューラについて考えていました。

全然関係ないですが、タイマ割込み間隔を設定するときに
outportb(0x43, 0x36);とやってから値をレジスタに書き込むのですが

outportb(0x43, 0x34);とやっているソースを見たことがあります。
これって何か違うのでしょうか。
本当にMonaって10ms毎に割込み来ているのかなぁ。
385381:04/02/22 22:37
>>384
「OS作り始めてから女の子にモテモテです」
ってんなら試してみようかと思ったんだけどなぁ。
やっぱやめとこ。
長続きもしないだろうし。
386ひげぽん ◆Ngzcp/NZpA :04/02/22 22:38
夢のまた夢ですが。
Monaでネットワークが使えるようになったらいろいろ広がるでしょうねぇ。

NICのドライバをどなたかが書いてくれたりしたら一気にいろいろと加速して
Monaからここに書き込みができるようになったらいいなぁ。

万が一ドライバを書いても良いと思う方がいた場合、Monaのどういう部分が
障害になるのかなあと考えたりします。

動的にモジュールをロードできない。
カーネルとドライバの標準インタフェースが決まっていない。

とかですかね。
387ひげぽん ◆Ngzcp/NZpA :04/02/22 22:46
>>381さん
> 「OS作り始めてから女の子にモテモテです」

そりゃもう。。。。ノーコメントです。
388ひげぽんの彼女:04/02/22 23:03
ひげぽんOS作り始めてからかっこよくなった
マジおすすめ
389Be名無しさん:04/02/22 23:17
ひげぽんさんOS作るのって難しいですか?
OS作るのに興味はあるんですが…
390ひげぽん ◆Ngzcp/NZpA :04/02/22 23:21
>>389さん
> ひげぽんさんOS作るのって難しいですか?
> OS作るのに興味はあるんですが…

まだ作り上げたわけではないのですが難しくはないと思います。
ブートコードは他のOSのをとりあえず借用していけば
いろいろと遊べるようになると思います。

OSを作るにはいろいろと部品を作らなければいけなくて
地味な作業が続く時期があると思いますがそれを乗り越えれば
すごく楽しいですよ。
391Be名無しさん:04/02/22 23:34
392Be名無しさん:04/02/23 02:45
>>384
mode2と3か。
ATでインターバルタイマとして使うならほとんど同じ。
PICに食わせるので0x34の方がいいと思うが。
とりあえず明確な違いは、出力の波形が違うので、
一回目の割り込みが入るタイミングが違う。

不安ならTSCで割り込み周期計ってみればいいのでは?
基準が正確にわからんので、多少の誤差が出るけど。
393Be名無しさん:04/02/23 08:54
多言語対応の話が出ていたので、なんとなくはってみる。
http://www.aist.go.jp/aist_j/press_release/pr2004/pr20040219/pr20040219.html
394Be名無しさん:04/02/23 13:52
駄レスでごめん。
たまたまブラっとこの板覗いたら、あんたらこんな事してたんだね?
俺はさっぱり判らんけど、何だか凄そうなんで開発頑張ってください。
期待してます。
395Be名無しさん:04/02/23 17:19
高級感ある外見がいいんじゃない?Mac的なグラフィックだと嬉しい。
396Be名無しさん:04/02/23 17:27
エ~ シンプルなほうがいい...
397ひげぽん ◆Ngzcp/NZpA :04/02/23 20:10
>>392さん
> mode2と3か。
> ATでインターバルタイマとして使うならほとんど同じ。

なるほど。ありがとうございます。

> 不安ならTSCで割り込み周期計ってみればいいのでは?
> 基準が正確にわからんので、多少の誤差が出るけど。

RDTSCの事だと思うのですが。おっしゃるとおり時間の
基準が分からないのですよね。

タイマのほうですが0x34で設定した時ハングする実機があったように
思うのですが、もう一度実験してみます。
ハングしたのは
ttp://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/mona/mona_v1.0/src/pic.cpp?rev=1.13&content-type=text/vnd.viewcvs-markup

のvoid setTimerInterval(dword ms) を呼び出したときです。
398ひげぽん ◆Ngzcp/NZpA :04/02/23 20:37
MonaのCVS最新版をダウンロードしてビルドする可能性がある方々に
お知らせいたします。

スケジューラ再構築とそれに伴うシステムコール群の書換のため
当分の間にカーネルがまともに動かなくなります。

ユーザー側のAPIは、変更がないように進めますので
当分の間は先日リリースした0.1.5をご使用いただきますようお願いいたします。
399Be名無しさん:04/02/23 22:19
>>397
少なくてもIntelのCPUなら、内部クロックに同期しているはずです。
つまり、例えば3.2GHzのPen4なら、約3200000000進みます。
Intelのマニュアル Vol.3 15.7を参照してみてください。
400Be名無しさん:04/02/23 22:21
ネットワークドライバの開発って難しいのかな?
俺には無理だけど・・・
誰か手を挙げたらがぜん盛り上がると思われ。
401ひげぽん ◆Ngzcp/NZpA :04/02/23 22:32
>>399さん
ありがとうございます。
マニュアル読んでみます。

スケジューラにArrayを組み込んでみたがどうも根本的に
何かを間違っている予感がしてきました。
Arrayに格納する中身と[]演算子の関係を勘違いしているっぽいです。
402Tino ◆sMrLqQHxo6 :04/02/23 22:44
>>401
-- src/include/collection.h
> inline T operator [](dword index)
[]演算子の返り値をT&にしないと代入できなくなります。
意図的に読み取り専用にしているのであれば値返しで構わないですけど。
403ひげぽん ◆Ngzcp/NZpA :04/02/23 22:51
>>Tinoさん
ありがとうございます!!

ご指摘の通りでした。
恥ずかしながら参照型をきちんと理解できていないのが原因でした。m(__)m

コンパイラが一時アドレスを使用しています的なwaringを吐いていたの
ずっと悩んでいました。
一歩進みました。
404Tino ◆sMrLqQHxo6 :04/02/23 23:01
>>403
参照型は結構ハマります。以下余談。

たとえば定石として、関数に引数として値をセットしたい変数を渡す場合、
参照型ではなくポインタで渡すことが推奨されます。
△ void change_value(int& v); … (1)
◎ void change_value(int* v); … (2)
なぜかというと、呼び出している部分を見ても
引数が変更されることが分からないからです。
(1)の場合: int a; change_value(a);
(2)の場合: int a; change_value(&a);

そのためC#では参照型の引数に渡すときは、
呼び出し側でも参照を明示するようになっています。
void change_value(ref int v);
(呼び出し側) int v; change_value(ref v);

引数に参照型を使うときはconstのときだけです。
これは巨大なクラスを渡す場合のオーバーヘッドを避けるためです。
constなので、当然、引数の値は変更されないことが前提です。

constと言えば、引数で渡す文字列を変更しない場合は、
char*ではなくconst char*にしておくべきです。
たとえば以下のようにするのが定石です。
char* strcpy(char* dest, const char* src);
意識的にconst char*が使われていないようなので、
総洗いしてみることをお勧めします。
405Tino ◆sMrLqQHxo6 :04/02/23 23:06
はっきり言って参照とかポインタとかconstとかの使い分けは面倒くさいので、
それらをPointer, Array, Stringに押し込めて、
他の部分で意識しなくて済むようなスタイルを考えています。
MONAFONT.ELFは実験的にそういう方針で書いてみました。
shadowさんにMonaged C++と言われたものです。(w
406ひげぽん ◆Ngzcp/NZpA :04/02/23 23:14
>>Tinoさん
> そのためC#では参照型の引数に渡すときは、
> 呼び出し側でも参照を明示するようになっています。

なるほど。確かにconst以外ではあまり見かけませんね。

> char* strcpy(char* dest, const char* src);
> 意識的にconst char*が使われていないようなので、
> 総洗いしてみることをお勧めします。

ご指摘ありがとうございます。
ユーザーライブリ・カーネル側どちらも見てみます。

スケジューラもWin上でテストしてからやればよかったと後悔気味・・・
407ひげぽん ◆Ngzcp/NZpA :04/02/23 23:16
> はっきり言って参照とかポインタとかconstとかの使い分けは面倒くさいので、
> それらをPointer, Array, Stringに押し込めて、
> 他の部分で意識しなくて済むようなスタイルを考えています。

確かに面倒ですよね。気をつけているつもりでも・・・
TinoさんのMONAFONT.ELFは、私の知るC++のお作法ではなくて
すごく新鮮でした。Monaged C++広めますか?w
408ひげぽん ◆Ngzcp/NZpA :04/02/23 23:34
Array<Queue> runq[10];

Queueはprev,nextをもつ構造体

runqは内部にQueueの配列を持っている。[]演算子をオーバーロードしているので
runq[n]とやれば内部のQueueの配列のn番目の要素にアクセスできる。

Queueを操作する場合、Queueへのポインタでアクセスすることがあります。
Queue a;
a.next = &a;
↑こんな感じで

では &(mona[3])とした場合、内部の配列の3番目のQueueへのポインタを返すように
したい場合は&演算子をオーバーロードすればよいのでしょうか?
混乱中・・・

C++の入門書でも読むべきか・・・
409ひげぽん ◆Ngzcp/NZpA :04/02/23 23:46
とりあえずWin32で実験してみます。

>>400
> ネットワークドライバの開発って難しいのかな?
> 俺には無理だけど・・・
> 誰か手を挙げたらがぜん盛り上がると思われ。

そうですね。難しさは想像できないですねぇ。
割り込みがシビアで取りこぼしたらまずいとかはありそうですねぇ。

ドライバは他のOSのが流用で来たらいいんですがそれなりに
NICに関して知識がないと厳しいですよね。
410Tino ◆sMrLqQHxo6 :04/02/23 23:47
>>408
ArrayにQueueを入れるのは変です。
Queueそれ自体がコレクションクラスだからです。

Queueは先入れ先出しなので、
配列中の任意の場所にアクセスする必要があるのは、
Queueを使う場所ではないと思われます。

任意の場所にアクセスするためにはキューをフリーズさせます。
具体的にはtoArray()のような関数を用意して、
その時点のキューの内容をArrayにコピーするというような、
コレクションの変換を伴うべきです。

[イメージ]
Queue<int> q;
q.enqueue(2);
q.enqueue(5);
Array<int> a = q.toArray();

同様に可変長のListをフリーズさせるときに、
toArray()でArrayに吐き出させると良いでしょう。
411ひげぽん ◆Ngzcp/NZpA :04/02/23 23:56
すいません説明不足だったようです。以下のようなことを狙っています

class Thread : public Queueとしておいて

Array<Thread> runq(4);// 優先度の数は一定

runq[0]: 優先度0のRun Queue
runq[1]: 優先度1のRun Queue
runq[2]: 優先度2のRun Queue
runq[3]: 優先度3のRun Queue

つまりカーネルは優先度の数だけRun Queueをもちます。
各Run Queueはスレッドを任意個保持できます。(そのため双方向リンクリストにしてあります)
412Tino ◆sMrLqQHxo6 :04/02/24 00:37
>>411
名前的にQueueというのは先入れ先出し汎用コレクションを連想するのが普通なので、
そのものずばりQueueという名前はコレクション用に取っておいて、
差し出がましいようですが名前を変えた方が良いように思います。
nextとprevで管理されているリンクリストの要素ならNodeとかが普通かと思います。
繰り返しますがQueueというのは先入れ先出しのものなので、
任意の要素を上から扱うようなことはしません。

それはともかく、この場合、参照をポインタに変更できないのが問題というわけですね。
src/Process.cppを見たところ、
> void Queue::remove(Queue* p)
のように操作はポインタが基本になっているので、
Array<Thread*> runq(4);
のようにしてはいかがでしょうか。

Monaged C++の絡みでWikiに書きましたが、型の段階で使用法を限定して、
自動変数でしか扱わないものと、ポインタでしか扱わないものとに分けると、
この手の混乱が少なくなると思います。

またこういった場合、removeされたQueue*が宙ぶらりんになる危険性があるので
Pointerによる参照カウントが絡んできますが、それはまあ、先走りでしょう……。
413ひげぽん ◆Ngzcp/NZpA :04/02/24 00:38
Array, Queueそれぞれの単体でのテストをcygwin上で行って
意図する動作であることを確認できました。

組み合わせたらSegment faultしたので、その辺で間違っているのでしょう。
今日は力尽きたので明日がんばります。
tools/arrayqueuetest/aq.cpp
414Be名無しさん:04/02/24 01:38
>>397
PICのIMR設定してからPITさわった方がよろしいのではないかと。
初期状態のIMRがどうなってるか忘れたけど、そこでハングするということは
変なタイミングで割り込みが来ているような気がする。
415Be名無しさん:04/02/24 01:51
>>326
>subversionだったらもう少し楽ですかね>ファイルの移動
ver.1.0.0が出たよ
ttp://slashdot.jp/article.pl?sid=04/02/23/154210&topic=104&mode=thread&threshold=-1

dev-jの人もコメントしてるね
416Tino ◆sMrLqQHxo6 :04/02/24 03:01
>>413
問題があるのは以下の部分です。
61:  FOREACH(Queue, value, runq)
62:  {
63:    Queue::initialize(&value);

基本的にFOREACHは代入しているだけです。
Queue value = runq[0];
というのと同じです。
この時点で別インスタンスなので、
&valueに対して操作しても意味がありません。

仮にFOREACHが参照を使うようになっているとしても、
Queue& value = runq[0];
今度はポインタが取れなくなってしまいます。×&value

もともとC#のforeachでイテレータに値型を指定すると
読み取り専用になって代入できない仕様になっているので、
それと同じように値が変えられないようにしてみました。
※なお、Perlでは参照扱いになるので代入できます。
417Tino ◆sMrLqQHxo6 :04/02/24 03:02
ここで先ほど書いたように、特定の型に対してはポインタだけで扱う、
という方針が意味を持ってきます。(これをMC++風と仮称しておきます)

57:  Array<Queue*> runq(10);
と書き換えるとQueueのインスタンスが作られないので
直後にfor (int i = 0; i < 10; i++) runq[i] = new Queue();
を書き加えておきます。

61:  FOREACH(Queue*, value, runq)
のように書き換えて、63行目の&valueをvalueにすると、
とりあえずこの部分は想定通りの動きをします。
69行目も61行目と同じようにすれば良いのですが、問題は71行目です。
71:    FOREACH_Q(value, Queue, hoge)

MC++風ではポインタだけで扱う型に対して、
自動変数だけで扱う型も想定していて、
可能な限りチャンポンで使わないようにします。
自動変数に対してポインタを取るのがそのチャンポンです。
従ってQueue top; ……(&top)というような部分は、
Queue* top = new Queue(); ……(top)のように書くことを推奨します。

そうすると全面書き換えになるので、
Wikiのコーディングテクニックのページに差分(aq.diff)を置いておきました。
扱い方を統一的にすることで、見通しが良くなったと思います。
418Tino ◆sMrLqQHxo6 :04/02/24 03:11
Array<Queue*> runq(10);
for (int i = 0; i < 10; i++) runq[i] = new Queue();

↑の書き方は冗長に見えるかもしれませんが、
考え方は↓のJavaと同じことです。
※JavaのStringは自動変数に出来ないことを参照。

String[] a = new String[10];
for (int i = 0; i < 10; i++) a[i] = new String();

いちいち書くと面倒なら、マクロを作ると良いでしょう。

#define ALLOC_ARRAY(type, name, length) Array<type*> name; \
  for (int __##name = 0; __##name < length; __##name++) name[__##name] = new type()

[使い方] ALLOC_ARRAY(Queue, runq, 4);
419364:04/02/24 03:17
>>366 >>371
まともにご挨拶もしてないのに丁寧な対応ありがとうございます。
今後ともよろしくお願いします。

>>386 >>400 >>409
NICドライバ作ってる人たぶん全国に何人か居ると思うけれど
みんな、成果物ができないと言い出しにくいクチなのかな<自分を含め
NICドライバ点呼してみるテスト

あとNICドライバ待ちでプロトコルスタック書いてる人(書きたい人)も
居るかも
420364:04/02/24 03:25
↑ミスタイプ「NICドライバ組んでる人点呼してみるテスト」でした。

NICドライバについて
状況:ne2kの資料集めが終わり、初期化手順と(もっとも簡単な)使い方をチェック中です。
ne2kな理由:とりあえずエミュレータでNICを使えるようにしたい&資料多め
方向性:プロトコルスタックとNICドライバ実装したくて和製OSをチョイスしてました。
MONAの為に書き下ろすというより、NICドライバの実装テストプラットフォームとして
MONAを活用させていただきたいです。
とりあえず動くものができればそれを元に、MONA風味にアレンジしていただいても結構ですし、
他の方がプロトコルスタックやNICドライバの、もう一つの実装をされても
作成は個人的には続ける予定です。
個人的には、逆に無理に統合するよりインターフェイスさえ規定すれば
複数のスタックがあってもよいと思います。

ドライバと言えない段階の実行ファイルサンプルは1週間〜10日程度で
初回版をお見せできればうれしいです。(社会人ですので時間が限られます)
421Tino ◆sMrLqQHxo6 :04/02/24 03:26
あと不思議に思ったのは、Queueのstatic関数はすべて第一引数にQueue*を取ることです。
関数ポインタを取ってみると分かりますが、C++の非static関数というのは、
暗黙の第一引数としてインスタンスが渡される関数です。
つまりメンバにする条件を完全に満たしていて、staticにする意図が分かりません。

試しに書き換えてみました。
特に問題ないように見えます。
こちらも前述のWikiのページに添付してあります。(aq.zip)

うー、さすがにもうつらいんで、風呂入って寝ます……
422Be名無しさん:04/02/24 09:40
( rtl8139の書きかけコードならちょっとだけ…
423Be名無しさん:04/02/24 09:52
N氏ハッケソ
424鳥取砂丘 ◆Dream/3P/. :04/02/24 20:14
  _
  /〜ヽ
 (。・-・) 保守プリン
 ゚し-J゚
425ひげぽん ◆Ngzcp/NZpA :04/02/24 20:26
>>Tinoさん
入れ違いになってしまったようで、申し訳ありません。
丁寧な御説明ありがとうございます。

> 名前的にQueueというのは先入れ先出し汎用コレクションを連想するのが普通なので、
> そのものずばりQueueという名前はコレクション用に取っておいて、
> 差し出がましいようですが名前を変えた方が良いように思います。

仰るとおりですね。Process.cppで使用するQueue->Nodeと名前を変えました。

> Queue value = runq[0];
> というのと同じです。
> この時点で別インスタンスなので、
> &valueに対して操作しても意味がありません。

その通りです。すいません・・・

> 従ってQueue top; ……(&top)というような部分は、
> Queue* top = new Queue(); ……(top)のように書くことを推奨します。

なるほど。たしかに↑の方が意図することがわかりやすいですね。

> Array<Queue*> runq(10);
> for (int i = 0; i < 10; i++) runq[i] = new Queue();

はい。分かります。
426ひげぽん ◆Ngzcp/NZpA :04/02/24 20:27
> あと不思議に思ったのは、Queueのstatic関数はすべて第一引数にQueue*を取ることです。
> 関数ポインタを取ってみると分かりますが、C++の非static関数というのは、

すいません。Queueを最初は構造体と想定していた元ネタ(過去の自分のコード)を
そのまま使おうと思って意味の分からないことをしてしまいました。
おはずかしい・・・

> 特に問題ないように見えます。
> こちらも前述のWikiのページに添付してあります。(aq.zip)
> うー、さすがにもうつらいんで、風呂入って寝ます……

添付ファイル確認させていただきました。
ありがとうございます。
私の至らなさで多大な御迷惑をおかけして申し訳ありません。
あまり無理をなさらないでください。。

>>414さん
> PICのIMR設定してからPITさわった方がよろしいのではないかと。
> 初期状態のIMRがどうなってるか忘れたけど、そこでハングするということは
>変なタイミングで割り込みが来ているような気がする。

なるほど。たしかにPITを触った後、マスク処理をしています>現在
一応、割り込みを全面禁止にしてから作業しているので大丈夫かとは思いますが
初期化の順番は関係あるかもしれませんね。

> ver.1.0.0が出たよ
>
ttp://slashdot.jp/article.pl?sid=04/02/23/154210&topic=104&mode=thread&threshold=-1

でましたねぇ。apacheを使ってネットワーク越しの作業というのは一度実験してみたいですね。
427ひげぽん ◆Ngzcp/NZpA :04/02/24 20:27
>>364さん
> まともにご挨拶もしてないのに丁寧な対応ありがとうございます。
> 今後ともよろしくお願いします。

こちらこそよろしくお願いいたします。

> NICドライバ点呼してみるテスト
> 1

NICドライバー開発者さんようこそーーー。

> MONAの為に書き下ろすというより、NICドライバの実装テストプラットフォームとして
> MONAを活用させていただきたいです。

ありがとうございます。非常にうれしいです。
しょぼいカーネルですがぜひぜひ活用してください。
またドライバの開発の障害となるものがカーネルにあったり
不足している機能がありましたらどんどん言ってください。

可能な限り対応させていただきます。

> ドライバと言えない段階の実行ファイルサンプルは1週間~10日程度で
> 初回版をお見せできればうれしいです。(社会人ですので時間が限られます)

お互い社会人ですが、無理がない程度にがんばりましょう!!
428ひげぽん ◆Ngzcp/NZpA :04/02/24 23:20
Tinoさんのおかげでスケジューラの簡単な実験が出来ました。

これからシステムコールの再構成に入ります。
以前はプロセス・スレッドがほぼ対等な立場だったため
実装が入り組んでありえないことをなっていたのを
スレッド中心の実装にしました。

パラーメータのチューニングが必要かとは思いますが
とりあえず早く動く状態にしようと思います。
429Be名無しさん:04/02/24 23:48
理解遅いんだけど。
もしかしてMONAでネットワークが使えるってことかーーーー?
430Be名無しさん:04/02/24 23:57
デバードーラとかプロートコルンス-タックンとか用意されれば。

もしかするとOSASKより早いかも。人集まってるし。
Lタンはよく分からないタイミングで馬力を発揮するので侮れないけど
あまり気合入れてOSやる気も無いらしいから、
和製じゃ一番早く用意されるんじゃね?
431Be名無しさん:04/02/25 00:09
それってすごいことだ
GUIとネットワーク
432Tino ◆sMrLqQHxo6 :04/02/25 23:26
>>407
> TinoさんのMONAFONT.ELFは、私の知るC++のお作法ではなくて
> すごく新鮮でした。Monaged C++広めますか?w
お返事遅くなりました。
決して無視していたわけではなくて、
調子に乗ってWindows Formsっぽいものを作っていました。
イベント処理すら出来ないへっぽこですが……。
433ひげぽん ◆Ngzcp/NZpA :04/02/26 01:06
>>Tinoさん
確認しました。ありがとうございます!!
まだソースは追いきれていませんがきっと宝の山だと思うので
明日にでも目を通します。

カーネル側も気合を入れないとユーザーアプリを作ってくださる方々の
要求にこたえられなくなるかもしれませんね。
がんばらなくては。まずはスケジューラの安定です。
434Be名無しさん:04/02/26 20:46
以前からこのスレを見てるんだが、最近活発だからさらにネタふりを。

ひげさんはMONAの開発をがんばってもらうとして
何らかの形でMONAに協力したいと思う人は結構いると思う。
でもどういう形で参加したいかが分からない(漏れみたいなやつ)がほとんどだと思われる

そこでスキル・志向別にこんなのやったらという案を書いてみた。

・結構できるひと(技術的なアドバイスをできるななしたん、Tinoさんレベル)
 ひげさんへのアドバイス等、今までどおりのアプローチ

・ある程度プログラミングはできるけどカーネルはさっぱり分からないよな人
 MONAで簡単なアプリ・ゲームを書いてみて、その過程で分からないことを
 このスレでレポートする。
 そうすればこれから始めようと思う人たちの助けになるし、APIの不備とかが発覚するかも

・実はOSを作ってみたいと思っているひと
 MONAのソースを順々に読んでいって簡単なレポートをこのスレでする。
 分からないことがあれば、このスレの達人たちがアドバイスをくれるかもしれない。
 1ソース毎にみんなで解析するのも面白いかも。

・MONAは知らないけど、Windows, Unixは詳しいよな人
 Windows, UnixからインパクトのあるフリーソフトをMONAに移植してみよう。
 その過程をここでレポートしたりすると面白いかもしれない。

・プログラムとかまったく分からないなひと
 次回MONAリリース時には動作報告というかたちで参加する
 実はこれは結構助かるのではないかと漏れは思う

だらだらと書いてしまったがどうでもいいと思う人はどうか無視してくれ。
漏れは4番目でやってみる
435Be名無しさん:04/02/26 21:02
>>434
面白いね!
>漏れは4番目でやってみる
Hurdみたいにカーネルの上にPOSIXサーバを作ると移植は何でもOKかも。
カーネルをいじらなかったらライセンス縛りとか関係ないしね。
436Be名無しさん:04/02/26 21:05
>>435
HURDって言えば、FATFS.ELFを見てsettransを思い出した
マイクロカーネル的にはいい線行ってるかも
織場もHURDを引き合いに出してたっけ
437Be名無しさん:04/02/26 21:35
>>434
良いね。
動作報告で貢献できそう。
5台もあるし。

>MONAで簡単なアプリ・ゲームを書いてみて、その過程で分からないことを
>このスレでレポートする。

これがスレにレポートされたら簡単なゲームでもやってみよう。
かなりへたれだけどw
438Be名無しさん:04/02/26 21:49
>>432
GUI実装ってそんなに簡単なのか。
それともTinoという人物が天才なのか。

とにかくGUI on MONAおめでとーーーーーーーーーー
439Tino ◆sMrLqQHxo6 :04/02/26 22:21
>>438
私が作ったものはまだウィンドウが出るだけでGUIと呼べる代物ではないですから、
そんなにすごいことではないですよ。

いずれ、ひげぽんさんがGUIに取り掛かるときに
参考になるようなものを用意できたら、と思って作っているものなので、
ひげぽんさんが取り掛かる正式なGUIは、
また一味違ったものになるのではないかと思います。
そうなるのはカーネルが一段落してからでしょうけどね。

それはともかく、今も改良を進めているところです。
>>379さんの影響を受けて(?)Eclipseを使ってみました。
私はJavaを使う機会がなかったのでEclipseをちゃんと使ったことがありませんでしたが、
プラグインでC++も使えると言うことで試してみました。
噂通りの凄いソフトですね。こういうのを作る人こそ天才と言うんじゃないでしょうか。

>>378
Eclipseの起動はVS.NET並みに重いのですが、
起動してしまえばVS.NETよりサクサク動きました。
SWTのお陰でJavaで作られていることすら忘れそうです。
もっとも私がVS.NETの重さに慣れているという面もあるでしょうけど。

ところで以前、ライセンスがひげぽんさんの個人名で出ていることについて、
協力者の扱いをどうするかという話があったようですが、
MonoのMIT/X11コピーライトがうまく書いてあるのに気付きました。
> Copyright (c) 2001, 2002, 2003 Ximian, Inc and the individuals listed
> on the ChangeLog entries.
440Be名無しさん:04/02/26 23:30
>>439
ChangeLogをマメに付けていれば一番いい方法ですな。
commit logすらまともに書いていない漏れには無理な方法だ…

ところでviewcvs経由で見るとChangeLogが化けまくるのはうちの環境のせいですか?
441Be名無しさん:04/02/26 23:59
>>440
ChangeLogは、UTF-8です。
1.123まで、SJISだったみたいです。
Sorceforge.jpでは、euc-jpがデフォルトだった気がします<Web文書
442Be名無しさん:04/02/27 00:21
>>441
HTMLには書いてないけどApacheがこんなヘッダを返してるね。
> HTTP/1.1 200 OK
> Date: Thu, 26 Feb 2004 15:19:34 GMT
> Server: Apache/1.3.26 (Unix) Debian GNU/Linux PHP/4.1.2
> Connection: close
> Content-Type: text/html; charset=euc-jp
443ひげぽん ◆Ngzcp/NZpA :04/02/27 00:22
>>434さん
興味深い提案いただきありがとうございます。

正直言って、どれが実現しても非常にうれしいともにありがたいです。
出来る限りサポートいたしますので是非実現して欲しいです。

>>439(Tino)さん
> いずれ、ひげぽんさんがGUIに取り掛かるときに
> 参考になるようなものを用意できたら、と思って作っているものなので、
> ひげぽんさんが取り掛かる正式なGUIは、
> また一味違ったものになるのではないかと思います。

こんばんは。すいません。まだソース見れてないです。

ところでTinoさんはかなりの腕前と見ておりますので
正直私が位置から勉強してつくるGUIよりもいい物を作られる
のではないかと思っています。

> 私はJavaを使う機会がなかったのでEclipseをちゃんと使ったことがありませんでしたが、
> プラグインでC++も使えると言うことで試してみました

そんなに快適ですか。うむむ。
444ひげぽん ◆Ngzcp/NZpA :04/02/27 00:22
> Copyright (c) 2001, 2002, 2003 Ximian, Inc and the individuals listed
> on the ChangeLog entries.

お。これいただこうかな。
Incってここではどういう意味なんですかね。

>>440さん
> ところでviewcvs経由で見るとChangeLogが化けまくるのはうちの環境のせいですか?

申し訳ありません。UTF-8にしてみて戻すの忘れてました・・・
euc-jp-unixに戻しました
445Be名無しさん:04/02/27 00:32
>>444
不幸なゾロ目ゲットおめ!(なのか?

>Incってここではどういう意味なんですかね。
普通に"incorporated"で「会社」の意味
"Co., Ltd."とかってよく見るでしょ
あれと同じ
だから個人では不要

>申し訳ありません。UTF-8にしてみて戻すの忘れてました・・・
>euc-jp-unixに戻しました
Apacheの設定がeuc-jpになってるからどうしようもないね
446ひげぽん ◆Ngzcp/NZpA :04/02/27 00:51
>>445さん
ありがとうございます。↓な感じにしました。
Copyright (c) 2002,2003, 2004 Higepon and the individuals listed on the ChangeLog entries.

>>438さん
> とにかくGUI on MONAおめでとーーーーーーーーーー
ありがとうございます。
447Be名無しさん:04/02/27 01:32
>>446
どんどん年を付け足すのもあれだから2002-2004ってした方が良いと思うけど
448Tino ◆sMrLqQHxo6 :04/02/27 06:18
> こんばんは。すいません。まだソース見れてないです。
そんなに大したものでもないですから。
とか言いながら調子に乗ってWikiにページを作ってみました。

> ところでTinoさんはかなりの腕前と見ておりますので
> 正直私が位置から勉強してつくるGUIよりもいい物を作られる
> のではないかと思っています。
Monaはひげぽんさんが勉強しながらカーネルを作ったことに意義があると思いますが、
それはGUIでも同じことではないかと思っています。

私の場合、3年前くらいに、勉強しながらGUIを作ったりしていました。
今はそのときの残骸をかき集めているような感じです。(w

> そんなに快適ですか。うむむ。
C++だとJavaほどの強力なサポートは得られないので微妙かもしれません。
とりあえずWikiにスクリーンショットを載せておきました。
449Be名無しさん:04/02/27 13:45
MASMでIPLって書けないんでしょうか?
当方、アセンブリの勉強をして、後にIPL書いて遊ぼうかと思ってまして。
NASMは、できるのは分かっておりますが、MASMがどうも分からない。
まぁ、com形式で、コードセグメントうまく設定すればできるのかと、乏しい知識で思ったり思わなかったり。

ってかバイナリ直で吐けないような気が・・・。
.comか.exeからの抽出が必要かな?
450Be名無しさん:04/02/27 14:45
>>449
org 0で作って.comにすればいけるんでは?
あれ生バイナリだし。
451ひげぽん ◆Ngzcp/NZpA :04/02/27 21:24
>>447さん

ありがとうございます。徐々に直していきます。

>>448(Tino)さん

> とか言いながら調子に乗ってWikiにページを作ってみました。

ありがとうございます。SDKは素直に便利だと思いました。
GUIの方は、ソースを斜め読みして勉強中です。

> Monaはひげぽんさんが勉強しながらカーネルを作ったことに意義があると思いますが、
> それはGUIでも同じことではないかと思っています。

確かにそうですね。
GUI方面に興味が行くかどうかは今現在はまだ分かりませんが。
勉強は続けたいですね。

> C++だとJavaほどの強力なサポートは得られないので微妙かもしれません。
> とりあえずWikiにスクリーンショットを載せておきました。

なるほど。私の開発環境は結構非力なのが痛いですね。
Meadowで十分といっていると時代に取り残されるかもしれませんが・・・
452Be名無しさん:04/02/27 21:57
>>450
色々と調べてみました。
んでMASM、VC.net買おうかと思っていたのですが98DDKがマイクロソフトのホームページに
密かにあったのでもらったったけど、何かいいのかどうか分からない。
とにかくこれから勉強してきます。
453Be名無しさん:04/02/27 22:25
NASMで池
454Be名無しさん:04/02/27 22:50
>>452
おまけmasmは32bitコード専用だったような気がする。
exe2bin(なつかしい名前だ)もないし。
455452:04/02/27 23:14
分かりました。ありがとうございました。もう逝きます。

>ひげぽんさん
適当に頑張って下さい。
456Be名無しさん:04/02/27 23:24
>>434の企画案に答えて
MONA版Hello World

#include <userlib.h>
int MonaMain(List<char*>* pekoe)
{
printf("Hello World");
return 0;
}

Makefileとかの詳しい解説って必要かなぁ(コピーしただけだけど)
457456:04/02/27 23:26
スマソ空白がつぶれた
458ひげぽん ◆Ngzcp/NZpA :04/02/28 00:51
>>455さん
ありがとうございます。

>>456さん
おぉ。始まりましたね。ありがとうございます。
いろんな人たちがMonaで遊んでくれるといいですね。

スケジューラの実装ではまり中です。
FDC割り込みが来たらwakeしているのですがどうもスタックがずれているような
印象を受けています。
うまくいっているメッセージ到着のwakeと基本的には同じなのになんでだろう。
459Be名無しさん:04/02/28 05:01
さて
debugコマンドでOSでも作るか
460鳥取砂丘 ◆Dream/3P/. :04/02/28 05:03
(゚∀゚)ニヤニヤ
461Be名無しさん:04/02/28 05:12
何故にpekoe
462459:04/02/28 05:18
本気だっぺ
463Be名無しさん:04/02/28 10:28
>>462
昔はDOSもMASMも持ってなかったから(C言語なんて尚更)
MONのAで16KBくらいのゲームを作ったりしたことあったっけ。
16KBでもかなりきつかった記憶が……
Z80と違って16進数のコードがいつまで経っても覚えられなかった
今でも覚えてるのはNOPの0x90くらいか……
464Be名無しさん:04/02/28 10:29
>>461
MonaMainのこと?俺もそう思った。
465Be名無しさん:04/02/28 10:34
>>364(= >>419 >>420) さんに、>>422さんがネットワークで、
TinoさんでGUIでしょ、もう凄すぎ。

ついでに>>435 さんに >>436 さんのようにOSサーバが出来たら…

漏れは >>434 さんの書き込みの5番目で頑張ってみまつ。
466Be名無しさん:04/02/28 14:32
VFSの実装はいつごろ?
467Be名無しさん:04/02/28 14:42
>>463
>MONのAで16KBくらいのゲームを作ったりしたことあったっけ。
MONのAってMONAですか?
468鳥取砂丘 ◆Dream/3P/. :04/02/28 14:58
>MONのAってMONAですか?
何もかもがみな懐k(ry
469鳥取砂丘 ◆Dream/3P/. :04/02/28 15:13
>>461
MonaPekoeへの伏線( ̄ー ̄)ニヤソ
470某スレ253:04/02/28 15:41
>>468
しまったー同じネタを使ってしまった!!
http://pc.2ch.net/test/read.cgi/os/1075632569/253
471Be名無しさん:04/02/28 15:53
>>470
ヤマト?
472Be名無しさん:04/02/28 16:00
>>471
正解
473Be名無しさん:04/02/28 16:09
>>470
ネタ被ってる上に微妙に間違えるとは(藁

今の少年達は古代とか沖田とか言ってもピンと来ないんだろうな。
474Be名無しさん:04/02/28 16:13
>>473
今の世代で沖田っていえば沖田総司かな。
大河の影響なのか新撰組流行ってるっぽいし。
ヤマトの歴代艦長の苗字は新撰組から取ってるだけだが。
475Be名無しさん:04/02/28 16:18
>>747
なんか脇役で斎藤とか色々いたような。
まあスレ違いだからやめとこ。
476Be名無しさん:04/02/28 16:49
>>475
あさっての方向へレスつけてんじゃねぇよヴォケ!
何が>>747だ、>>474だろうが!

_| ̄|○
477Be名無しさん:04/02/28 17:44
やっとはじめて読む486,MINIX本,Interface7月号が手に入った。
さてどれから読もうか?
478Be名無しさん:04/02/28 17:59
Tinoさんすごいな
一体何者
479Be名無しさん:04/02/28 18:19
>>478
パナウェーブ研究所の会長か何かだったかと。
480Tino ◆sMrLqQHxo6 :04/02/28 19:24
>>478
ありがとうございます。
でも私なんかまだまだです。
初めてQtを日本語化した方を見てすごいなぁと思います。

>>479
違います。訓令式ではないですよ。(w
481Be名無しさん:04/02/28 20:14
>初めてQtを日本語化した方
某神様でつか?
482Tino ◆sMrLqQHxo6 :04/02/28 20:34
>>481
よくご存知ですね。
483Be名無しさん:04/02/28 20:47
>>481
>>482
その神様興味あり。
どういう人?
ひげぽなり、このスレを見ている人に影響を与えるかもよ。
484452:04/02/28 20:48
逝く前にひとつ。

98DDKにEXE2BINも付いていました。
んで、.COMにすると、やはりバイナリ直書きでした。
これを.BINに変えて、ブートシグネィチャ付加してbochsで起動してブートできました。
ただし一番最初のジャンプ命令はどうやるか分からなかったけど、とにかく動作はしました。
IPLはMASMでも書けるようです。

んでは、逝きます

485Tino ◆sMrLqQHxo6 :04/02/28 21:06
>>483
UNIXやJavaの達人です。
でも今は本業が忙しくてあまり趣味のプログラミングは出来ないみたいですね。
私もネット上で遠巻きに見ていただけで親しいというわけではないです。
486Be名無しさん:04/02/28 21:12
>>485
サンクス
その人の書いたソースとかある?
487Tino ◆sMrLqQHxo6 :04/02/28 21:22
>>486
ありますがスレ違いですし、
個人のことを書いて良いかも気になるので、
KDEの神様で調べていただけないでしょうか?
488Be名無しさん:04/02/28 22:20
KDEの神様で調べたらロマンスの神様とかが引っかかった・・・
でもTinoのGUIに期待
489ひげぽん ◆Ngzcp/NZpA :04/02/28 23:22
>>310
> FD読み込みが遅い原因ぽいモノをつかみました。
> LBA1-10 * 20回読み込み22秒に対して
> FD読み込みだけに専念(FDC割込み以外マスク)シングルプロセス
> で同じ読み込みをしたら5秒でした。

上記現象ですが。
スケジューラを改良して(全書換して)、実験してみました。
FDCからの割り込みを待つときは
FDCDriver::waitInterrupt()を呼び出してCPUを他のスレッドに譲ります。

そして割込みがくるとScheduler::wakeup()でただちに
実行可能かつ優先度が高くなります。

計測の結果 LBA1-10 * 20回読み込み5秒でした!!

ただしスケジューラーが安定せず以下の課題があります。

・VMWAREでうごかない
・汎用メッセージ到着によるwakupとの共存ができない(バグ)

思えばプロセス・スレッド周りの再実装(書換え)は5回目くらいですが
デバッグが大変です。実機ONLYだったらもっと大変だろうなぁ。
490Be名無しさん:04/02/29 00:57
NICドライバを作っている2人の人たちはどうなったんだろう。
ソースを見せろとは言わないがどんな感じか
ここに書いてもらえると盛り上がると思う。

隠れた達人が多いのでアドバイスがもらえるかもしれない。
挫折しそうならソース公開して誰かに引き継ぐというのも面白いかも。
491Be名無しさん:04/02/29 01:00
bochsで動くようになったの?
ってか最新のbochsって、どこからダウンロードするの?
まさか自分でコンパイルすれと言うこと?
どちみちどこからダウンロードするのか教えていただきたいく存じます。
一応cygwinはあるから、自分でコンパイルでもいいですわ
492Be名無しさん:04/02/29 01:07
すいません、2.1.1ありました。
動きました。逝ってくる
493Be名無しさん:04/02/29 01:24
あのフロッピーイメージにMONAGUI.ELFを追加したいのですが、どうやるのでしょうか?
DiskExplorerではできませんでした。
激しくGUIを試したいので、お寝がいします。
494Tino ◆sMrLqQHxo6 :04/02/29 02:11
>>488
ありがとうございます。

>>493
私はひげぽんさんのfat_writeを使っていますが、
上書きできないようなので毎回ディスクイメージを作っています。

やり方
1. Mona WikiのMona/アプリ登録所でMonaSDKをダウンロード
2. 展開する
3. 中にあるbinディレクトリにMONAGUI.ELFをコピー
4. cygwinでbinディレクトリに入ってmake
5. mona.imgというファイルが出来るので完成

make時にはbinディレクトリにある.ELFファイルをすべて追加するので、
他のアプリや自作アプリなどを含んだイメージを作るのにも使えます。

他の方法としては、時間がかかるのであまりお勧めしませんが、
Mona-0.1.5リリースのフロッピーイメージを本物のフロッピーに書き込んで、
フロッピーのAPPディレクトリにMONAGUI.ELFをコピーして、
フロッピーからイメージを作成するという方法もないわけではありません。
私はイメージの入出力にはrawwriteを使っています。
http://uranus.it.swin.edu.au/~jn/linux/rawwrite.htm
495Be名無しさん:04/02/29 02:31
>>493
あと念のため補足しておきますが、
MonaGUIはまだウィンドウを表示するだけの代物で、
スクリーンショット以上の動作はしませんから、
GUIとして遊ぶというイメージだとがっかりされると思います。

もちろん私自身、Monaで遊んでみたいというのが
こうしたものを作っている動機ですので、
ご期待に沿えるように頑張りたいと思います。
496Tino ◆sMrLqQHxo6 :04/02/29 02:33
名乗り忘れましたが>>495は私です。
ついでなので私がアプリを開発するときに使っている方法を書いておきます。

MonaGUI-20040226のMakefileに書いてありますが、
ELFファイルのリンク処理の後にSDKのbinディレクトリにコピーして、
binディレクトリでmakeさせる処理を付け足しています。
そうするとアプリのコンパイル後に自動的にイメージが更新されます。

最近Eclipseを使い出したのですが、
EclipseではC++を使っているときはMakefileをmakeするだけなので、
キーボードショートカット(デフォルトのCTRL+Bを慣れたF5に変更しています)を押すと
フロッピーイメージが自動的に作られるようにしています。
Virtual PCやbochsではそのイメージを参照するようにしておくと、
コンパイル後にそれらを起動させることで動作確認が出来ます。
VS.NET 2003でPocket PCアプリを作るのを真似してみました。

問題点としては、コンパイル時にエミュを動かしておくと
イメージ作成のときに書き込みエラーになってしまうので、
コンパイル時にはエミュを落とさないといけない点です。
エミュ側でフロッピーのマウントを解除するという方法もありますが、
MonaのFDドライバが挿抜をうまく認識しないことがあるようなので、
念のためエミュを切っておいてコンパイル完了後に起動させています。

その場合、MonaにAUTOEXEC.BATみたいなのがあれば便利だと思いました。
シェルサーバを改造すればすぐ出来るかもしれませんが……。
497Be名無しさん:04/02/29 02:50
>tino様
あらら、こんなに詳しくすみませんでした。
アプリを簡単に追加するユーティリティがないということですね。
激しく作りたいが、スキルが激しくないし、FAT12のフォーマットもどう探しても見つからないし・・・。


ちなみに私は、フロッピーにイメージを書いて、MONAGUI.ELFを追加して
再度イメージを吸い取ってやりました。無事にbochsで動作いたしました。

本格的にGUIが動作するようになれば、面白くなりそうですね。
正直どうやっているのだろうという疑問がありますが、
ソース読んでも私のレベルではどうにもならないと思いました。

ではでは、時間をとらせて申し訳ありませんでした。
498Tino ◆sMrLqQHxo6 :04/02/29 03:20
>>497
つい先ほどGakuさんがアプリ登録所に書き込まれた情報によると、
まさにそのものの情報とイメージ操作ツールを作っておられるそうです。
詳しいことはアプリ登録所の一番下(FATFS.ELFのスクリーンショットの下)をどうぞ。
私も知らなかったのですが、素晴らしいですね。
499Be名無しさん:04/02/29 09:46
EDITDISK(DiskExplorer)で、できなかったっけ?
MonaGUIは、特別なのかな?
それとも、ベースのイメージが変わった?
500499:04/02/29 09:52
>>497
手元にきちんと動く古いソースがあったから試したけど、
EDITDISKで、問題なくMonaGUIをイメージに書き込んでBochsで起動できましたよ。
501Be名無しさん:04/02/29 13:48
>>500
EDITDISKで開くとき、どれを選べば良いのでしょうか?
色々試してみたのですが、全部エラーが出て終わってしまいます。
EDITDISKのヴァージョンの問題でしょうか。
502Be名無しさん:04/02/29 13:50
>>501
開くイメージファイル指定してplain imageで良い筈……。
503Be名無しさん:04/02/29 13:58
>>502
すみません。できました。
バージョンを最新のしたら逝けました・・・ごめんなさい。
Vectorにヤラレタ・・・鬱
504Be名無しさん:04/02/29 14:43
>>503
一応おめでとー。
Vectorめ、オンドゥルルラギッタンディスカー!
505Be名無しさん:04/02/29 14:44
>>504
そこまで言うほどでもない
506Be名無しさん:04/02/29 15:15
「オンドゥルルラギッタンディスカー」って、ずっとクトゥルー神話辺りのネタと思ってた。
507ひげぽん ◆Ngzcp/NZpA :04/02/29 18:20
bochsで動作したようで、よかったです。
Tinoさんフォローありがとうございました!!

スケジューラの改良によりFDCDriverの割込み対応が
Vmwareでも動作するようになりました。

覚書として原因をかいておきます。
1.FDCにreadコマンド発行
2.read完了の割込みを待つために割り込みが来るまでCPUを他のスレッドに明け渡す
3.FDCからの割込み到着をトリガーとしてスレッドを起こす。

上記のような流れになるのですがVmwareは高速なため1と2の間に割り込みが
来てしまいスレッドが2度と起き上がらないということになっていました。
508364:04/02/29 23:22
>>427 >>490
NICドライバ(まで今しばらくのもの)作成中のものでつ
といっても、
最初にご用意してるのはユーザランドからNIC叩いて
プロミスキャスモードに設定して流れてくるデータを標準出力にダンプ
っていう感じのコマンドを作成中です。
予定より実装が遅くなってしまってます。
(1日時間がとればできるつもりができてません。現在10%〜20%ぐらい?
ネットワーク対応とはこれができてもまだまだ言えない状態だと思いますが
まずはNICがMONAから叩ける準備ということで、暇をみつけてがんがります。
まだOSのAPI関連までは到達していませんので、OSサイドからの補助が必要になったら
おながいします。

>>409
パフォーマンスを考えない場合はNICの処理はそんなにシビアではありません。
というのもTCPスタックやUDPを使うアプリケーション側に再送処理が仕込んで
あるからです。
取りこぼした場合もそれなりに動いてくれるはずで、特にBochs等フリーのPC等
ハードをエミュレーションするエミュレータを使ってみるとわかります。
のちのちチューニングしていけばすむことで、まずはNICのチップをどう叩くのか?
っていうこととアプリケーションから見たインターフェイスが重要だと思われます。
509ひげぽん ◆Ngzcp/NZpA :04/02/29 23:23
土日に片付けようと思っていたスケジューラのバグがどうしても
分からず、持ち越しになりました。
Monaは起動するのですがENTERを押しっぱなしにしたりするとfault0dが
起こるというものです。
どこで発生しているのかがつかみきれず挫折気味。
2,3日かけてうまくいかないようであればしばらく違う作業したほうが
よいかも。
510ひげぽん ◆Ngzcp/NZpA :04/02/29 23:44
>>364さん
> まずはNICがMONAから叩ける準備ということで、暇をみつけてがんがります。
> まだOSのAPI関連までは到達していませんので、OSサイドからの補助が必要になったら
> おながいします。

出来るだけすぐに対応させていただきます。
ただ力量がないので即対応が出来ないかもしれないので
こんな機能が必要になるかもしれないと予想がついていれば是非教えてください。

> のちのちチューニングしていけばすむことで、まずはNICのチップをどう叩くのか?
> っていうこととアプリケーションから見たインターフェイスが重要だと思われます。

なるほど。少し安心しました。>パフォーマンス。
すこしはその辺勉強しないといけませんね。>インターフェース
何か入門書でも読んでみよう。
511 ◆CFYAAAAAds :04/03/01 00:30
むこうの方でNIC書こうと思ってる香具師でつ。
一応、トラ技2001年1月号にNE2000の石の叩き方が詳しく乗っているので
もし手に入るのでしたら参考までに。

ただ、100BASE-T主流なんで現在NE2000って現役なんかな?
ネットワーク知識はどうも3年前で止まってるので…
512364:04/03/01 00:38
>>510 ひげぽんさん

>出来るだけすぐに対応させていただきます。
>ただ力量がないので即対応が出来ないかもしれないので
>こんな機能が必要になるかもしれないと予想がついていれば是非教えてください。

ハードウェア叩くプログラムは作ってますが、NICのドライバや
プロトコルスタックは初めて実装します。
あと、実は恥ずかしながらまだ、MONAについてキチンと(使うところ以外)
読んでませんので何が必要で、何が足りないか?
という点では私もまだわかりません。
その上で、とりあえず、ユーザランドからのIOと割り込みの通知があれば
とりあえず動くものができると思い、
>364
の書き込みになった次第です。
今後ともよろしくお願いします。
513鳥取砂丘 ◆Dream/3P/. :04/03/01 00:43
  _
  /〜ヽ
 (。・-・) 。oO( >>511 「むこう」じゃこっちの人には通じないような・・・
 ゚し-J゚
514 ◆CFYAAAAAds :04/03/01 00:51
  /〜ヽ
 (。・-・) 。oO( ウチ新参者やからよーわからんもーん。とりあえずNICガソバル
 ゚し-J゚
515364:04/03/01 00:53
>>511
◆CFYAAAAAds さん
ありがとうございます。2001年1月号ですね。
1999年7月号以外マークしてませんでした。
他のOSのソースを見ようにも綺麗に書いてありそうなものに限って
GPLが多いですね。(RTEMSとかEthernutとか)
見ちゃいけないってことは無いのでしょうけれど、
あまりに影響されるのも良くないかなと。
(初期化部分は大差が無いはずですが…

NE2000は現役とはいえません。
構造的にCPUパワーを食うところが嫌われているのでしょう。
ただ、BochsがNE2000互換なのでNE2000互換という側面と、
もともと私が作ろうと思っていたものがNE2000で十分だったという側面が
あります。
現在、NE2000互換のハードウェアの入手性は地方では(私は福岡ですが)
控えめに表現しても、あまり良くありません。
まだNE2000互換もとれてないので、なんともいえませんが、MONAを実機で
ネットワーク対応する算段も別途考えてはいます。
ちょっと前のものですが、
ttp://www.bi.a.u-tokyo.ac.jp/~uaa/gomitext/2001/20010807.html
この方の文書が参考になるかもしれません。
IntelとRTL8139、Prismシリーズで市場の何割かカバーできそうな気もします。
516 ◆CFYAAAAAds :04/03/01 01:18
なるほど、やっぱしNE2000は過去のものなんですね。
2001年1月号あたりまでそっち系の仕事をしてたんですが、最近さっぱりな状態なので…
私も勉強してみます。(本業が忙しくて時間裂けないかもしれないけど…)

99年7月号の記事内容からして2001年1月号は焼き直し+αって感じみたいですね。
とりあえず「第3章EthernetインターフェースLSIの概要」と「第4章RLT8019ASの概要と使い方」
があるので、石のアクセス手順とかレジスタの説明とかは役に立つかと思います。
517ひげぽん ◆Ngzcp/NZpA :04/03/01 23:11
>>511さん
> 一応、トラ技2001年1月号にNE2000の石の叩き方が詳しく乗っているので
> もし手に入るのでしたら参考までに。

ありがとうございます。大変助かります。
大きな書店で探してみます。

>>512さん
> その上で、とりあえず、ユーザランドからのIOと割り込みの通知があれば
> とりあえず動くものができると思い、

なるほど了解いたしました。
こちらこそよろしくお願いいたします。
518ひげぽん ◆Ngzcp/NZpA :04/03/01 23:19
今回のバグはなかなか手ごわいです。
今日の成果は

・バグがVirtual PCでほぼ100%再現することを発見
・fault0d(↑のバグ)が発生しないようにするには
  syscalls.cppの431行目あたり
bool isProcessChange = g_scheduler->schedule3();
⇒bool isProcessChange = true;
  とすると回避できることを発見。

  ただし!!何故これで回避できるかがさっぱり分からないという状態です。。。

  処理としては該当部の手前でwaitでThreadをrunq->waitqへと移動
  schedule3()再スケジュール(Schedule3は非常に単純にしてあります。)
  ThreadOperation::switchThread()でスレッド切り替え。

とやっているだけです。
いろいろと疑っているのですがいまだ解決せず。
どうも進捗率が悪くなってきました。

デバッグのためにダンプ表示もいろいろとしているのですが
もう一息?といった感じです。
ttp://mona.sourceforge.jp/dynamic/pukiwiki/pukiwiki/pukiwiki.php?plugin=attach&pcmd=open&file=schedulerfault0d.png&refer=%B5%C4%CF%C0%2F%A5%C7%A5%D0%A5%C3%A5%B0
519Be名無しさん:04/03/01 23:22
NE2000の叩き方なら、RTL8019ASでぐぐるといっぱい引っかかると思われ。
520ひげぽん ◆Ngzcp/NZpA :04/03/02 00:44
>>518
タイマ割り込みが途中から来なくなっていることが発覚。。
どうして気づかなかったんだ>自分

処理そのものは実行されていたので(タスクの実行・切り替え)タイマ割り込みが
きていないとは・・・

どこかでeflagsが壊れているのだろう・・・
いやFD読み込みは出来ているのでマスクが壊れた??

ただいま大混乱中。
521ひげぽん ◆Ngzcp/NZpA :04/03/02 00:51
マスクいじってた・・・
今日の作業が無駄になったかもしれないという驚愕の事実。
ショックが大きい。
522ひげぽん ◆Ngzcp/NZpA :04/03/02 00:58
結局分かったことは。

・タイマ割り込みが来ていなかったことと↑のバグは関係ない。
・タイマ割り込みが来てもこなくてもwait/wakeup処理によってfault0dが発生する。
523Be名無しさん:04/03/02 00:58
>>521
まぁ、そんな日もあるさ
524364:04/03/02 03:32
予定より遅くなってますが一応現状の報告をします。
MONAのユーザランドからIO直に叩いて自分の(.bochsrcにて記述した)
MACアドレスを読み出して表示はできています。
実際のパケット送受信にはもうちょっと時間がかかりそうです。

私が詰まった、RTL8019とBochsのNICの違いは
RTL8019のデータシートとBochsのne2k.ccとを見比べるとわかりますが、
CONFIG1〜CONFIG4というMACアドレスが入るレジスタがBochsには無いことです。
気にせず、起動直後のNICのバッファを頭から読み出せばMACアドレスが入っています。

懸案事項
○実機だとタイミングの問題があるかもしれません。(未検証です。)
○初期化もずいぶんサボっています。(実機だとNICにBIOSがあればそっちで面倒みてくれるかな?)
525Be名無しさん:04/03/02 13:08
>>524
ne2kのNICにBIOSなんて期待しちゃいけません。
NetworkBoot(not PXE)のROMが載ってることもあるが、
そこから起動しない限り、初期化なんてやってくれません。
526Be名無しさん:04/03/02 17:16
>>524
データシートならこっちだ。
ttp://www.national.com/ds/DP/DP8390D.pdf
RTL8019ASのは余計なことばっかり書いてあるので、あんまりよろしくないです。
ちなみにCONFIG1〜4は蟹の拡張機能なので、Bochsの実装が正解。
527364:04/03/02 19:56
>>525-526
情報サンクスでつ。助かりました。
Bochsの方がNE2000との互換性では上だとは思ってましたが、
手元に石があったりしたため
ついRTL8019のデータシートを見てしまいました。

今、DP8390のデータシートを印刷しようと思って
会社帰りにネットカフェです。しかし出力代がちょっと高いですね。
今日はUSBメモリを買って帰ってkinkosで出力してみます。
このデータシートはパッとみてみていい感じですね。
ちょっと予定より遅くなりますが、ある程度読んでみたいですね。
(土日一回はさめばなんとかなるという予定の立て方が無謀だったのかも。
528Be名無しさん:04/03/02 20:14
>>527
会社でダウソして印刷してしまえばタダじゃん
529Be名無しさん:04/03/02 20:40
そういえば会社での私的な用途へのインターネット使用率が7*%だったっけな
530ひげぽん ◆Ngzcp/NZpA :04/03/02 22:30
>>523さん
ありがとうございます。

>>364さん
> 予定より遅くなってますが一応現状の報告をします。
> MONAのユーザランドからIO直に叩いて自分の(.bochsrcにて記述した)
> MACアドレスを読み出して表示はできています。
> 実際のパケット送受信にはもうちょっと時間がかかりそうです。

ご報告ありがとうございます。
すばらしいです!!!
MACアドレス取得だけでも大きな一歩です。

私のほうは、今日もスケジューラのバグがつぶせませんでした。
あまりに長期戦になるとへこたれるので明日からしばらく違うことに
挑戦しようと思います。
531ひげぽん ◆Ngzcp/NZpA :04/03/02 23:30
といっているそばから。
現在のバグスケジューラ版にcvs tagでタグを付けておいて
今のスケジューラ周りのコードを全部捨ててもう一度書き直してみます。

書き直す過程で何か発覚すれば戻るもよし新実装でいくもよし
という方針で行きます。

それでも直らなかったら0.1.5にロールバックです。
532Be名無しさん:04/03/03 00:05
>>531
一度、やろうとしてることを整理してみてはどうだろうか。
 0.1.5からどういう変更をしたいのか。
 そのために必要なものは何か。
などなど。
533 ◆CFYAAAAAds :04/03/03 02:12
漏れも明日データシート会社で印刷してきまつ。
トラ技みるからにはpage1:01h〜06hらしいけど
RSAR0,RSAR1に00h〜1fh指定しろと書いてありますた。

NICで遊びたいのに仕事年末進行が…
bochsとかは週末…
534Be名無しさん:04/03/03 20:38
やっぱりOSを作成するのに適しているのはGCCのみかい?
例えばVC++とかだったらどうなるんだろうかと。
まぁddコマンドなど、かなり便利なものがはじめからついているUNIX、LINUXのほうがええか。
535Be名無しさん:04/03/03 22:35
別にVC++でも変わらんかと。
gccだといざという時にソース読めるというのはあるけど。
ddはOSを選ぶ理由になる程の差じゃないな。
536Be名無しさん:04/03/03 23:17
>>535
そうですか。
天球べりマッチ
537ひげぽん ◆Ngzcp/NZpA :04/03/04 00:39
>>532さん
アドバイスありがとうございます。
ver.0.1.5で一番の不満点はFDの読み込みの遅さでした。
調査したところFDCからの割り込みに即応答して次のreadコマンドを
発行をしてないことが原因と分かりました。

スケジューラの問題であることが発覚したので実装が汚かったのもあって
上記を解消するためにスケジューラを全部書き換えることにしました。

またスケジューラを書き換える際に、プロセス・スレッドの生成の
仕組みもリライトしなければいけませんでした。
(前のスケジューラに依存している部分があったので)
538364:04/03/04 00:41
>>530 ひげぽんさん
ありがとうございます。
乙でつ
ひげぽんさんのネットワーク対応したいという発言が無かったら
(今でもはやくはありませんが)もっとゆっくり実装していたと思います。
ここ2日ぐらいいじれてないところですけれど、
ひげぽんさんみたいに継続していけるといいでつ。

>>528 さん 529さん
私の会社はプライベートの印刷をするには厳しいところです。
技術ってことで入った職場ですが、上流工程主体(開発はやってない)ので
データシート見てたりするだけでも仕事と関係ないことはバレバレですし。

>>533
仕事との両立って言うほどのことじゃないかもしれないですけれど、
時間とるの難しいですね。乙でつ
私も今日いきなり、来週いっぱいの出張を入れられてしまいました。
お互い、無理せぬ程度に進めていきましょう。
539ひげぽん ◆Ngzcp/NZpA :04/03/04 00:45
スケジューラの実装では優先度つきかつ2つ以上のrun queueをもつ
ものを欲張って実装しましたが、起動中やShellなどでfault0d, invalid op code
などの例外が出るようになってしまいました。

問題を単純化して不具合箇所を見つけるために、本日
1つのrun queueと、1つのwait queueをもつ単純なら
ラウンドロビンのスケジューラーに書き直しました。

その結果多少安定しましたが、invalid op codeや
0.1.5までは安定して動いていたShellやアプリがメモリアクセス違反を
相変わらず起こっている状態です。
たとえば起動後Shellでenterキーを押しっぱなしにしていると
アクセス違反や例外が発生します。
ver.0.1.5では起こるのはみたことありませんでした。
540ひげぽん ◆Ngzcp/NZpA :04/03/04 00:51
今疑っているのは
・システムコールのネスト
プロセスロードシステムコール⇒FDC割込み待ちシステムコールによりスタックがずれてinvalid opコード?

くらいです。

ある程度エラーは再現するのですがエラー箇所がまちまちだったり
タイマ割込み・FDC割込み・システムコールと処理が切れてしまうので
どうも追いきれていない状況です。

なるべく早く解決しないと、364さんのがんばりやTinoさんのGUIに
遅れをとってしまいます。

人が見れば明らかだけど過信してものすごいミスをしているんだろうなぁ>自分
541364:04/03/04 00:54
>>533 ◆CFYAAAAAdsさん
情報サンクスでつ。
トラ技、当時は読んでましたが、今は手元に無いので、データシートやら
他の人のソースや、Bochsのソースを頼りに進めてきました。
現状ではMACアドレスの後にはNE2kを表す0x57が読み出されてます。

現状報告の補足ですが、
あと、NE2K側のメモリを読めてるということは、
もうちょい適切なパラメータ書き込んであげれば
(MACと同じメモリに入るので)
Etherフレームを受信できるということですね。

今日USBメモリ買ったので明晩以降データシートを読んでみます。
542ひげぽん ◆Ngzcp/NZpA :04/03/04 00:56
>>364さん
お疲れ様です。

> ひげぽんさんのネットワーク対応したいという発言が無かったら
>(今でもはやくはありませんが)もっとゆっくり実装していたと思います。

もしいい形できっかけになれたならそれはうれしいです。

あの発言は、自分の作ったOSからIRCとか2chへの書き込みとかが
出来たらなあと。という気持ちからのでたものです。
もし出来たら感動して泣いてしまうかも(笑)

> ここ2日ぐらいいじれてないところですけれど、
> ひげぽんさんみたいに継続していけるといいでつ。

スケジューラにまいりすぎてちょっと継続の危機ですが
364さんのようにMonaに興味を持っていじってくれている人たちがいる
というのがやる気の源になっています。
543Be名無しさん:04/03/04 01:25
>>ひげ
ソースとか全く見てないから、適当かもしれんが、
ポインタ関係でミスってる予感・・・。
544 ◆CFYAAAAAds :04/03/04 01:34
うひゃー、かなり仕事テンパり気味ー。

データシート印刷したのに会社に忘れてきちゃった…
2ページ印刷すると製本できる感じで折れるのでいい感じのpdf。

>>538
仕事しつつOSも触るってことは、やっぱしOSいじったりやプログラムが好きなんだなーって感じですよね。
漏れも最近仕事ばっかりだったので、つい最近ここを見つけて昔の創作意欲が湧いてきたという感じ。
でも仕事には勝てませぬ…。

>>541
EtherFrame読めるところまで行くと次はIPとTCPでつまずきそうな感じがする…
いまだに漏れはIP,TCPパケットの中身でわからない部分があったりしまつ。


とりあえず漏れは時間とってエミュ環境そろえるところから…(氏
545Be名無しさん:04/03/04 21:56
>>537
FDCからの割り込みに即応答して次のreadコマンドを発行するのは、誰?
 ユーザプロセス(OSサーバ含む)ならば、優先度と再スケジューリングの問題ではないでしょうか。
 カーネルならば、割り込み処理の問題だと思います。

546Be名無しさん:04/03/04 22:16
>>539
queueを単純化するよりも、各処理の機能と手順を明確化するほうが先じゃないでしょうか?
ソース読む時間がなくて明確なアドバイスはできませんが、
たとえば、
 FDC割り込み→レジスタ退避→割り込み処理→現行プロセスをキューにつなぐ→次プロセスをキューから取り出す→次プロセス
の流れだとして、各部分の機能がはっきりしていれば、矢印部分でのシステムパラメータやスタック内部が
どうなっていないといけないかが予測できるはずです。あとは、予測したものと実際のものを単純にチェックするだけ。
仕様バグには通用しませんけどね。
547Be名無しさん:04/03/05 00:10
bochsのGDBスタブを使ってみてはどうでしょうか。
548ひげぽん ◆Ngzcp/NZpA :04/03/05 01:07
>>543さん
よくポインタミスしますw
>>545さん
> FDCからの割り込みに即応答して次のreadコマンドを発行するのは、誰?

FDCDriverの機能をシステムコールを介して利用しているプロセスです。

> ユーザプロセス(OSサーバ含む)ならば、優先度と再スケジューリングの問題ではないでしょうか。
> カーネルならば、割り込み処理の問題だと思います。

どうも動作を確認していると。もっとプリミティブなところで
エラーが起きているような印象を受けます。

>>546さん
> queueを単純化するよりも、各処理の機能と手順を明確化するほうが先じゃないでしょうか?
はいおっしゃるとおりだと思います。
各処理の明確化をするのが手間なほど実装を進めてしまったので
queueを単純化することで逃げています。

処理の明確化は今日進めていましたが基本の流れが
以前のバージョンのMonaとあまりかわらないので各実装部分で
何かやらかしているのかもしれません。
549ひげぽん ◆Ngzcp/NZpA :04/03/05 01:14
> 各部分の機能がはっきりしていれば、矢印部分でのシステムパラメータやスタック内部が
> どうなっていないといけないかが予測できるはずです。あとは、予測したものと実際のものを単純にチェックするだけ。

これもおっしゃる通りで実践しようとしているのですが
エラーがでる箇所が起動するたびに全く異なるプロセス・eipだったり
エラーがでないで普通にアプリが起動する場合があるので
実際のエラーが出る直前の各パラメータが捕まえにくくなっています。

>>547さん
> bochsのGDBスタブを使ってみてはどうでしょうか。

実は現在のエラーはbochs, Vmwareではまったく出ず
Virtual PC、実機で再現しております。
bochsで再現すればかなり有益な情報がえられるのですが・・・

皆様貴重なアドバイスありがとうございました。
550Be名無しさん:04/03/05 20:38
>>549
今のアプローチは、バグの発見と修正という形だと思うんですが、
きちんと動く部分を増やしていくアプローチはどうでしょうか?
551Be名無しさん:04/03/05 21:19
>>550
スケジューラはプリエンティブなマルチタスクOSの根幹の部分だから、
後回しにすると更に大変なことになるのでは?
552Be名無しさん:04/03/05 21:49
>>551
全体的に後回しでなくて、バグの位置がつかみにくいなら、
スケジューラや関連部分を細かい部品に分けて、それぞれをきちんと動くように作っていくって事です。
がんがんコードを書き換えていくだけだと、バグが増えて減っての繰り返しになるんで。
553Be名無しさん:04/03/05 23:38
>>550
Unit Testですね。
以前話題に出ていたYAGNIも含めてXP(eXtreme Programmingの方)を勉強してみては。
Wikiにも参考図書として載っているようですし。>>ひげぽん
554Be名無しさん:04/03/06 00:42
なんとなくタイミング依存ぽいですが、排他制御ミスってませんか?
根拠ないけど。
555ひげぽん ◆Ngzcp/NZpA :04/03/06 23:17
不具合の一因と思われる箇所を特定できました。
このバグは0.1.5から内在していたものようです。

・詳細
TSSに適切なesp0がセットされていなかった。
esp0のセットはユーザーモードスレッドへのスイッチの際に行っていました。
⇒ユーザーモードスレッドはカーネルスレッドを必要とするため。

ところが以下の場合にesp0をセットするのを忘れていました。
カーネルスレッドA, ユーザーモードスレッドBとすると。

Aが実行中
スレッドスイッチA⇒B
Bはシステムコール中でカーネルモード中(esp0をセットすべきなのにしていなかった)
システムコール終了ユーザーモードへ
次のシステムコールで違うスレッド用のesp0を使用して死亡

なぜ0.1.5では再現しなかったか?
再スケジュールの仕組みが貧弱で上記のような切り替えが「たまたま」なかった。
556ひげぽん ◆Ngzcp/NZpA :04/03/06 23:19
>>553さん
> Unit Testですね。
> 以前話題に出ていたYAGNIも含めてXP(eXtreme Programmingの方)を勉強してみては。
> Wikiにも参考図書として載っているようですし。>>ひげぽん

アドバイスありがとうございます。上記おっしゃることはよく理解できます。
特にUnitテストやテストファーストのメリットは自分でも体験したことがあります。

ただし今回のようなOSの根幹に関わる部分は事前テストや単体機能でのテストが
不可能な場合があると認識しています。

・事前にUnitテストできる部分
スケジューラ用データ構造Nodeオブジェクトと操作関数
スケジューラ(次のスレッドの決定ロジック等)

・テストできない点
スレッド生成・切り替え
システムコール・割込みを含めた処理

今回のようにどうがんばってちょっとずつ動くモノを足すということができない場合
ある程度の苦労がしょうがないのかなと思いました。
557ひげぽん ◆Ngzcp/NZpA :04/03/06 23:19
今回のバグ箇所発見が遅れた反省点を次回に生かすとすれば以下の点です。
・効率的なデバッグ手法を利用する(ログ・ダンプ等)

・新規に追加した機能でなく以前からある機能も疑う

>>554さん
> なんとなくタイミング依存ぽいですが、排他制御ミスってませんか?
> 根拠ないけど。

上記も疑いました。おかげでいろいろと処理を見直すことが出来ました。

今回の件、アドバイスを下さった皆様ソースまで見ていただいた皆様
本当にありがとうございました。
558Be名無しさん:04/03/06 23:46
>>556
>・テストできない点
>スレッド生成・切り替え
>システムコール・割込みを含めた処理
Cygwinでしか出来ないと思ってない?
カーネルにテストコード書けるでしょ。
VM上でUnit Testすればいいじゃん。
559Be名無しさん:04/03/06 23:52
>>557
>・効率的なデバッグ手法を利用する(ログ・ダンプ等)
そういうのは自分で見るんだろうけど、
答えを先に決めてチェックすればVM上でUnit Testできるでしょ。
560Be名無しさん:04/03/07 00:07
>>558
>>559
そのカーネルがうごかないから困ってるんじゃないの?
スケジューラとかスレッド生成がおかしかったらカーネル動かない。
⇒カーネルでUnit Testできない
561ひげぽん ◆Ngzcp/NZpA :04/03/07 00:13
バグが1つ解消したのでFDの読み込みをテストしました。

計測の結果 LBA1-10 * 20回読み込み5秒でした

また通常起動時の*.SVRの起動も体感できるほど早くなりました。

実はテストのために多重スケジューラをやめて一本のRunキューのままですが
しばらくはスケジューラを触りたくないので(飽きたので)
いずれスケジューラを変更します。

ちょっと話題を変えていままでOSの動作確認をエミュレータを使ってきましたが
よく使うエミュレータについて、ひげぽんの個人的な経験で
ちょっとメリット・デメリットと使いどころを書いてみようと思います。(参考になれば幸いです。)

・bochs2.1 CVS

 メリット
  ・VESAがいい感じ
  ・実機だったら再起動するような間違いを起こしたときにカーネル側でダンプしなくても
   レジスタの状態がわかる。EIP情報等はかなり役立つ。
   
 デメリット
  ・極端に遅い
  ・最近のリリース版は勝手に再起動する?(オプションの問題かなあ。)
 
 使いどころ
  ・IPLなど再起動を繰り返すような場面
  
562ひげぽん ◆Ngzcp/NZpA :04/03/07 00:14
・Vmware4.05(匿名希望さん寄贈感謝)

 メリット
  ・早い
  ・デバッグモードがあるらしい
  
 デメリット
  ・FDCがおかしい(受け付けないパラメータがある)
  ・特定アドレスに対するpushができない
  ・対応しているVESAの画面モードが少ない
  
 使いどころ
  普段の動作確認

・VirtualPC 5.1(匿名希望さん寄贈感謝)

 メリット
  ・早い
  
 デメリット
  ・特に不満無し
  
 使いどころ
  普段の動作確認
  個人的には一番実機に近いとの印象を持っています。
563ひげぽん ◆Ngzcp/NZpA :04/03/07 00:18
中程度の変更をカーネルに行った場合は
所持している全てのエミュレータで動作確認。
大規模の変更を行った場合は+実機で動作確認しています。

>>558さん
>>559さん
ありがとうございます。
VM上でのUNITテストが出来る場合もたくさんありますが
今回の場合はUNITテスト環境の土台になる部分を変更したので
テストは難しいと思いました。
564Be名無しさん:04/03/07 00:24
>>560
カーネルが動かない=Test失敗 と、考えるのはだめなのか?
UnitTestもたくさんあるツールのうちのひとつだから、使う人しだいだね。
565Be名無しさん:04/03/07 01:46
バグ修正おめーーーー。

次回リリースの目玉はやはりGUIとネットワーク?
566Be名無しさん:04/03/07 13:21
>>565
GUIのテストバージョンがWikiにアップされているよ
どうもまだ安定してないようだが
こればっかりは正式リリースを待つしかない

ネットワークはどうだろ。MACアドレスを取るのと実際に動かすのと
どれくらい大変さが違うかよくワカラネ
567Be名無しさん:04/03/07 13:27
MONAに移植したらおもしろそうなもの

ゲームエミュレータ
コンパイラとか開発環境
vi互換のエディタとか
シェル
568Be名無しさん:04/03/07 16:22
libcの移植?が進んでいるみたいだけど
サンプルアプリとかないの、そのまま使えるのかとか
569Be名無しさん:04/03/07 17:15
>>566
ドライバとしてはそれなりに動くレベルだが。
その上が大変だからのう。

ライセンスの問題が無いプロトコルスタックを探してきて
おいしくいただいてしまうのが一番お手軽だが。
570Be名無しさん:04/03/07 18:36
>>566
> どうもまだ安定してないようだが
お騒がせしております。
色々な要因が複合しているようです。
GUI側の問題なのかMona側の問題なのか調査中です。
571Tino ◆sMrLqQHxo6 :04/03/07 18:37
あ、すみません。>>570は私です。
572Be名無しさん:04/03/07 23:56
>>570
親切にどうも。がんばってください。
実はかなり期待しています。
573 ◆CFYAAAAAds :04/03/08 01:19
>>596
前に石でぐぐってみそって言われたときに発見してたんだが、
ちゃんとL4あたりまで書いてあるんで使えそうな気はする。
ttp://homepage3.nifty.com/maum/sonota1.htm

「これらを利用や改造をしてもらっても一向に構いません」とかいてあるけど
新OS用で利用するならきっちりメールしてもOKもらえると思う。

あいかわらず仕事忙しいんで最近はここ、ROMばかりです…
GUIも時間とれたら見てみたいなぁ
574Tino ◆sMrLqQHxo6 :04/03/08 01:34
>>572
ありがとうございます。
手元にはいくつかバグを直してウインドウを動かせるものが出来ましたが、
sf.jpが落ちているようなので復旧後アップしたいと思います。

>>573
ネットワーク周り期待しています。
575 ◆CFYAAAAAds :04/03/08 01:42
ウチに期待するとGWになってもできるかどうか…
とりあえず3月に出現中のコワイトクイサキを倒すのが先決らしいです。
勇者のノートパソコンで倒せるかなー?

4月はOS周りいじり月間にしたいところ…
576Be名無しさん:04/03/08 02:18
>>573
H8用のプロトコルスタックは、メモリけちるために処理はしょってる場合があるので、
そのへん気をつけた方がよろしいかと。
577364:04/03/08 03:31
>> 542 ひげぽんさん
ありがとうございます。
もちろんいい形でのきっかけです。
名乗らずひっそりと個人的に実装しようかと考えておりましのたで、
そのままでしたら、そうとうゆっくりとやっていたと思います。
それはそうと、スケジューラの方おつかれさまです。

>>566 さん
>>569 さん
569さんの仰るとおりですが、バッファリングをキチンとしていないので、
そこんところ考えないといけないですね。
あと、プロトコルスタックだけではなく、NICドライバももらってきた方が
(整合性から)良かったのかもしれません。

NIC関連進捗について
明日から出張等で15日までPCに触れなくなります。
ですので、今日あたり、何かしら(バイナリやらソースやら)
アップしたかったのですが、ちょっと余裕がありませんでした。
ごめんなさいです。
578Be名無しさん:04/03/08 13:42
579くれくれ房:04/03/09 14:16
マウスのハードウェア制御の資料(URL)をください。
580Be名無しさん:04/03/09 14:17
581くれくれ房:04/03/09 14:21
そこ逝ったけど、見つけられるキーワードが分からなかった。
英語でもいいのでプリーズ
582Be名無しさん:04/03/09 14:38
dev-jにあったわ。逝って来る。
583ひげぽん ◆Ngzcp/NZpA :04/03/09 20:52
>>364さん
> それはそうと、スケジューラの方おつかれさまです。

ありがとうございます。はまりました。。
今月号のInterfaceはタイムリーな話題なので買ってみました。
まだ読んでいないですが。

> ですので、今日あたり、何かしら(バイナリやらソースやら)
> アップしたかったのですが、ちょっと余裕がありませんでした。
> ごめんなさいです。

お気になさらずゆっくり取り組んでいただければよいと思います。
出張とか大変ですよね。。

スケジューラが1段落したので不安定なファイルシステム等々を
どうにかしようと奮闘中です。

そういえばTinoさんのGUIがボタンが押せたりウィンドウが
ぐりぐり動かせたりするのですがちょっと感動しました。
言い方がわるいかもしれませんが本物のGUIな感じです。
584Tino ◆sMrLqQHxo6 :04/03/09 20:55
>>583
今はプロセスごとに描画しているので同時に動かすとハリボテ感ありありですが、
最終的にはサーバー化して本物にしたいです。
585ひげぽん ◆Ngzcp/NZpA :04/03/11 20:20
>>584 Tinoさん
いやあ。あのレベルに私が到達するのはまだ先のようです。

自前のFAT操作コードがやっつけ仕事の品質の悪く
いろいろと問題になっていたので某氏作成のFAT操作コードを
Monaに取り込む作業をしていました。

ユーザーモードからのFileInputStreamによるファイル読み込み
プロセスロード関数などが前より安定して動作しています。

また、アプリケーション開発者や最新のカーネルを触りたい方のために
↓開発中の中でも比較的安定したものをリリースする場を作りました。

ttp://mona.sourceforge.jp/dynamic/pukiwiki/pukiwiki/pukiwiki.php?Mona%2F%B3%AB%C8%AF%C8%C7
586Be名無しさん:04/03/11 21:24
Mona GUI試してみたいい感じ!!
このウィンドウのみためは何に似せているんだろう

ボタンとかぐりぐり動くのが本格的なのでオリジナルデザインだと面白いかも
587Be名無しさん:04/03/11 21:38
>>586
> ウィンドウのみため
Beっぽい奴?
588586:04/03/11 23:46
>>587
Beか。
Mac OSXみたいなのはどうよ?
589 ◆CFYAAAAAds :04/03/12 01:25
本職年度末進行中…
なるべくお泊りは避けたいんだけどなぁ…

NIC、興味津々なのに昼休みとかですら睡眠時間なんでさぱーり。

現在ココのNIC停滞中?
590Be名無しさん:04/03/12 02:03
>>589
>>577
> 明日から出張等で15日までPCに触れなくなります。
だと。
つまりアンタの独壇場だ!
591Tino ◆sMrLqQHxo6 :04/03/12 09:40
>>585
色々とご対処ありがとうございます。
MonaGUIは3/10に0.1リリースなどと書いたものの延期してしましたが、
仕事が立て込んでしまって日曜日くらいまで触れそうもないです。
せっかく開発者向けリリースが出ましたので、
MonaGUI-0.1はMona-0.1.6.1向けにしたいと思います。

細かいことですが、x.x.x.1みたいなのは
表面にはあまり見えないような細かいバグ修正に使うので、
今回のようなAPIの変更を伴うような修正には適さないと思います。
一般的にマイナーバージョン(0.xのxの部分)でAPI互換性を示します。

ですがまだ途中なので、0.2.0とするのも問題ですから、
こういうときは0.2.0α1とか、0.1.90だとかが分かりやすいと思います。

枝番があまり細かいと、ずっとウォッチしているような人以外には、
あれ、前のバージョン何だっけ?
という印象しか与えかねないです。
592Tino ◆sMrLqQHxo6 :04/03/12 09:47
>>586
> Mona GUI試してみたいい感じ!!
ありがとうございます。

> このウィンドウのみためは何に似せているんだろう
既に>>587さんから回答がありましたがBeです。

> ボタンとかぐりぐり動くのが本格的なのでオリジナルデザインだと面白いかも
Wikiのロードマップに書きましたが、ver.0.5でテーマをサポートする予定です。
Be風は非矩形ウインドウのテストを兼ねた暫定です。

>>588
> Mac OSXみたいなのはどうよ?
Aqua風のものを公開してAppleから公開停止要請が来た前例がいくつかあるので
一般公開するもので使用するのはまずいみたいです。
593Be名無しさん:04/03/12 13:49
ひょっとしてそろそろWabaとかうごくんじゃない?
とかおもったり
594Be名無しさん:04/03/12 14:03
あのくらいはmonaだってmegトンだって動くだろ。
595Be名無しさん:04/03/12 14:33
あれもう動くの
移植待ち?

GUIとWabaの関係がよく分からないな
どこまでOSに依存しているんだっけ
OSASKに移植されているよね
596Be名無しさん:04/03/12 15:49
ソース見れば。
OSに依存する部分が多い少ないと言うより、
むき出しになっているから全部自分で書ける。
osaskくらいのは動きそうな気がするけどどうかな。
試しに>>593が挑戦だ。
597Be名無しさん:04/03/12 15:56
ごめんぷろぐらむできない厨房
WEBサイト構築ぐらいなら手伝えるけど
598Be名無しさん:04/03/12 17:07
VESA 16bit マダァ?
599ひげぽん ◆Ngzcp/NZpA :04/03/12 20:06
>>591 Tinoさん
> 色々とご対処ありがとうございます。

おかげさまでカーネルが安定しました。
こちらこそありがとうございます。

> 仕事が立て込んでしまって日曜日くらいまで触れそうもないです。

了解しました。お体にお気をつけ下さい。

> こういうときは0.2.0α1とか、0.1.90だとかが分かりやすいと思います。

迷ったのですが、↓のようにしてみましたいかがでしょうか。
mona-0.1.7-image.zip

>>593さん
> ひょっとしてそろそろWabaとかうごくんじゃない?
> とかおもったり

おお。気づきませんでした。
もし動いたらアプリケーション開発の敷居が低くなって
よいかもしれませんね。

>>598さん
> VESA 16bit マダァ?

VESAの16bppのことでしょうか?
起動中の画面モード切替をサポートしていないので
次回リリース時には、なんらかの対応をするようにいたします。
600Be名無しさん:04/03/12 21:41
MlcStdio.hとかってファイル名があまり良くないと思う
こんな基本的なもののファイル名を変えてどうするのって感じ
libc/stdio.hみたいにディレクトリを掘って
コンパイル時には-Iでパスを通して
#include <stdio.h>と書けるようにするべき
601 ◆nl7ClMRWE6 :04/03/12 21:49
なぁに、libc/stdio.hからMlcStdio.hをincludeすればいいのサ!
いや意味は無いんだけどね。
おいらも一般的なファイル名使った方が良いと思う。
何か理由あるのかな?
602Be名無しさん:04/03/12 21:55
>>599
16bitサポ−ト
Danke.
603Be名無しさん:04/03/12 22:07
>>600
完全に仕様をみたしてない(みたせない)から、変えた。
素のstdioを名乗るのは、気が引けたので。
604Be名無しさん:04/03/12 22:07
>>600-601
DOS厨UNIX厨は(・∀・)カエレ!!
605 ◆nl7ClMRWE6 :04/03/12 22:19
>>603
そっすか。

>>604
なんでdos厨unix厨なんだよう。
606604:04/03/12 22:39
>なんでdos厨unix厨なんだよう。

いや、言ってみたかっただけ。
607Be名無しさん:04/03/12 22:54
この前実機で動かした。pen330MHzくらいかな。
あまりにもフロッピーの読み込みが遅くて死ぬかと思った。
今改造しているらしいが。
もうちょっと頑張ってください。
bochsに負けているので。まぁエミュOSってのも悪くないが。
608Be名無しさん:04/03/12 23:22
>>607
v0.1.5 ?

0.1.5 って、たしか、プロセスが皆してメッセージ待ちにビジーウェイトしてタイムスライス使い切ってたんじゃなかったっけ?
今 CVS にあるやつは SYSTEM_CALL_MTHREAD_YIELD_M でタイムスライス放棄してるように見えるので、大分違うんじゃないかな?
609ひげぽん ◆Ngzcp/NZpA :04/03/13 00:26
>>607さん
> あまりにもフロッピーの読み込みが遅くて死ぬかと思った。
> 今改造しているらしいが。
> もうちょっと頑張ってください。

お試しいただきありがとうございます。
フロッピー読み込みの遅さは当方でも認識しており最優先で対応いたしました。
もしお手間でなければ下記より最新版イメージファイルをD/Lしていただき
改善されているかお試しいただけないでしょうか。
ttp://mona.sourceforge.jp/dynamic/pukiwiki/pukiwiki/pukiwiki.php?Mona%2F%B3%AB%C8%AF%C8%C7

>>608さん
フォローありがとうございます。
自分以外でそこまでカーネルの動きを具体的に把握されている方がいらっしゃたので
ちょっとびっくりしています。
もし気になる点がありましたらご指摘いただけると助かります。
610607:04/03/13 01:22
あぁ?
っと確か数日前にダウンロードした記憶があるがね。
まぁそのうちやってみるわ。
ってかそのパソコン俺のじゃないからあまりできないわ。
まぁ俺の発言など、ほぼ無視してくれても委員だけどね。
ゴミと同類ですから。
611Be名無しさん:04/03/13 07:45
>>603
そういう問題じゃないだろ。
それ以前にあんた誰よ?影?
612 ◆CFYAAAAAds :04/03/13 10:21
金曜日にお泊りはやめてほしいところ…
そして寝て起きてから夜もお仕事。

>>590
漏れも自宅PCは同じような状態OTL
4月には活動開始できる予定…
613Be名無しさん:04/03/13 11:48
POSIXサーバまだー?
614Be名無しさん:04/03/13 13:43
MonaってC++で開発しているということは、ライブラリファイルは存在してるの?
誰が作っているの?何言語で。
615Be名無しさん:04/03/13 15:16
影ポソがD言語で作ってるんだよ
616Be名無しさん:04/03/13 16:49
>>615
D言語の仕様は読んでない。
617Be名無しさん:04/03/13 17:15
隊長、
「C++で開発している」→「ライブラリが存在」
という繋がりがよく分かりません!
618Be名無しさん:04/03/13 18:25
libstdc++のことじゃねーの?
スラドでもそのこと言ってた香具師がいたし。
http://slashdot.jp/comments.pl?sid=158023&cid=497658

newとdeleteを独自実装してiostreamとか使わなかったらいらないわけだが。
http://slashdot.jp/comments.pl?sid=158023&cid=497695
619614:04/03/13 19:13
C++で書いたソースをコンパイルするときに、IntelのCPUで動くように直でバイナリ吐けるんですか?ということです。
普通ELF形式だとか、WinならEXE形式とかに変換されるやないですか。

そこら辺は俺の勉強不足から来るものだろうとは思うから、逝ってきます。
620Be名無しさん:04/03/13 19:28
>>619
髭師
621Be名無しさん:04/03/13 19:28
>>614
そんなのMonaをmakeしてみてMakefileのldのところを見れば分かるわけだが。
622Be名無しさん:04/03/13 19:35
>>619
first boot, second bootまではアセ。
そっからCやC++の関数へジャンプとかじゃね?
シンボル情報だのを取り除いた生のバイナリを作るのは普通に可能。
623Be名無しさん:04/03/13 22:07
>>616
匿名で、しかも乱暴な口調で書き込むと評価落とすぞ
ひげぽんがなぜあれだけ馬鹿丁寧なのか考えてみろや
624Be名無しさん:04/03/13 22:19
shadowタンの愛想無い書き込みに>>623タンがマジ切れです。
人からの暖かいレスに飢えているようです。
誰か>>623タンに可愛らしいAA付きで突っ込みを入れてあげて下さい。
625Be名無しさん:04/03/13 22:22
>>623
                プシィー
           ; 、 、; , ; 、 、
           '⌒`、lili,'⌒`
   (`γ')        |lili|
   冫/"    ,..-ー―,lili,―-、
..  / ;;|    /;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;ヽ
   | ;;;;ヽ,  /;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;l    / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
   | ;;;;;;`ー';;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;(,,゚Д゚)l  < そう、目クジラを立てるな
   `、_______,,,....つ--つ   \___________
    `ー‐---、,,,____    ,.,., ,.,,,ノ
            "'''''''''''し'''J
626Be名無しさん:04/03/13 23:07
>>623
(・∀・)ニヤニヤ(・∀・)ニヤニヤ(・∀・)ニヤニヤ(・∀・)ニヤニヤ
・∀)ニヤニヤ                 >>623(゜Д゜)             ニヤニヤ(∀・
(    )ニヤニヤ(    )ニヤニヤ(    )ニヤニヤ(    )ニヤニヤ
627ぬるぽん:04/03/13 23:36
暇なんで2ちゃんねら向けのぬるぽOSってのを作ってみるわ
628Tino ◆sMrLqQHxo6 :04/03/14 13:06
>>599
> 迷ったのですが、↓のようにしてみましたいかがでしょうか。
> mona-0.1.7-image.zip

1. 次がどこへ向かっているかが分かりにくい
2. 同じマイナーバージョンの系列で一般向けと開発向けを混在させるのは好ましくない
3. APIの互換性がないのに同じマイナーバージョンを付けるのは好ましくない

まず前提として、次回の一般リリースを0.2.0と定めているかどうか、が焦点になります。
0.1.90とか0.2.0α1とかの名前の付け方は、
0.2.0に向かったプレビューという意味合いを持たせているため、
「これが安定すれば0.2.0が出るのだな」
という見通しをユーザーに与えるという狙いがあります。

おそらく、スケジューラ、ドライバ、FAT、libcのすべてが揃って、
GUIもそこそこ使えるようなものを0.2.0として出したいのではないかとお察ししますが、
個人的にはFAT周りが安定したことが大きかったので、
0.1.7相当のものを0.2.0として出しても良かったと思いますが。

もっと言うと、前回の大々的リリースが0.1.5だったのですが、
あまり知らない人からこの番号を見れば、
単なる保守リリースにしか見えないでしょう。
そういう観点からは、0.1.5は0.2.0で、0.1.7は0.3.0と名乗っても
まったくおかしくないと感じます。
※今から変えてくださいという意味ではありませんので念のため
>独自にOSを作っているまたは、作ろうとしている人たちのための
>スレッドになればと思います。
さっきゅんのスレッドハケーンわはー!
630Be名無しさん:04/03/14 19:02
>>263
乱暴だった?それは、悪かった。

よく考えると、C++のライブラリは作ってなかった。
そろそろ、C++の勉強もかねて、作ってみたほうがいいかなぁ。
Monaged C++までの道のりは険しい。
631Tino ◆sMrLqQHxo6 :04/03/14 21:21
>>628
> 0.1.7相当のものを0.2.0として出しても良かったと思いますが。
とか言いながら0.1.7の挙動に悩みまくってしまいましたが、
これが安定すれば0.2.0としても結構いけている気がします。
GUIについても0.1.5で行き詰っている点が突破できます。
そういう意味で0.1.7を0.2.0α1として扱うのは悪くないかもしれません。

どこに問題があるのか切り分けるのに四苦八苦してしまいましたので、
GUIに関してはMonaがもうちょっと安定してから進めることにします。
というわけでまたまたMonaGUI-0.1のリリースを延期しますが
悪しからずご了承くださいませ。

>>630
> Monaged C++までの道のりは険しい。
最近は入門用としても使われるようになってきたC#をC++に移しただけですので、
C++のスタイルとしては特殊でも考え方自体はそう難しいものではないはずです。
問題は、私が勝手に作り上げたスタイルなので資料がないことなのですが、
その辺はMonaGUIのサンプルとC#との比較などで溝を埋めたいと思います。
632Be名無しさん:04/03/14 21:57
C#はすばらしいよな。
633Be名無しさん:04/03/14 22:07
ほんとすばらしいな
634Be名無しさん:04/03/15 16:52
Monaってモナーのことでつか?
635Be名無しさん:04/03/15 16:55
ホムペ見ましたカックイイ
ガンガってください
636Be名無しさん:04/03/15 17:07
藻まえら凄すぎ
637Be名無しさん:04/03/15 18:05
株公開できれば一山当てれそうな予感。
638Be名無しさん:04/03/15 18:13
ん?
どっかに晒されたのか?
639Be名無しさん:04/03/15 18:15
もしかして2chに晒されたとか
640Be名無しさん:04/03/15 18:16
ガクガク(((( ;゚Д゚))))ブルブル
641Be名無しさん:04/03/15 18:26
ここで全部晒されてる!
http://pc.2ch.net/test/read.cgi/os/1076216434/l50
642Be名無しさん:04/03/15 20:52
そりゃまた酷いな
643Be名無しさん:04/03/15 21:22
スレ丸ごとなんて信じらんねえよ。
644ひげぽん ◆Ngzcp/NZpA :04/03/15 23:59
>>614さん
> MonaってC++で開発しているということは、ライブラリファイルは存在してるの?
> 誰が作っているの?何言語で。
ライブラリはC++言語でMonaPJメンバやその他の人々が作成しています。
libuser.aがライブラリです。

>>628 Tinoさん

> 1. 次がどこへ向かっているかが分かりにくい
> 2. 同じマイナーバージョンの系列で一般向けと開発向けを混在させるのは好ましくない
> 3. APIの互換性がないのに同じマイナーバージョンを付けるのは好ましくない

なるほど。

> おそらく、スケジューラ、ドライバ、FAT、libcのすべてが揃って、
> GUIもそこそこ使えるようなものを0.2.0として出したいのではないかとお察ししますが、

その通りです。
アドバイスありがとうございます。
αが全角文字だったのでファイル名は↓のようにしましたがいかがでしょうか?何度もすいません。
mona-0.2.0alpha1-image.zip

> どこに問題があるのか切り分けるのに四苦八苦してしまいましたので、
> GUIに関してはMonaがもうちょっと安定してから進めることにします。
> というわけでまたまたMonaGUI-0.1のリリースを延期しますが
ご迷惑をおかけして申し訳ありません。
Wikiにも書きましたが不具合の原因となった場所を特定できました。
本当に単純ミスで反省しています・・・

というわけで前回リリースの0.1.5程度の安定感がやっと戻って
かつ、スケジューラがの調整で少しはやくなった感じです。
645ひげぽん ◆Ngzcp/NZpA :04/03/17 23:06
メッセージsend/receiveのあて先・送信元の単位を
プロセス→スレッドに変更して実装しなおしました。

スレッドレベルで送受信が行えることにより
サーバーとの細かなやりとりができるようにとの意図です。

開発版リリースはmona-0.2.0alpha2-image.zipです。
ttp://mona.sourceforge.jp/dynamic/pukiwiki/pukiwiki/pukiwiki.php?Mona%2F%B3%AB%C8%AF%C8%C7

またうれしい出来事として364さんから
MonaでMACアドレスを取得出来るバージョンのソースとバイナリをご提供いただきました。
現在bochsで動作が確認できています。

動作の様子はこちら
ttp://mona.sourceforge.jp/dynamic/pukiwiki/pukiwiki/pukiwiki.php?%B5%C4%CF%C0%2FNIC%A5%C9%A5%E9%A5%A4%A5%D0
646Be名無しさん:04/03/18 00:06
>>364
MACアドレス取得おめー
小さい1歩だが今までにない展開で楽しみ
647Tino ◆sMrLqQHxo6 :04/03/18 00:23
>>644
> αが全角文字だったのでファイル名は↓のようにしましたがいかがでしょうか?何度もすいません。
> mona-0.2.0alpha1-image.zip
こちらこそ色々とうるさくてすみません。
もちろん全角文字はまずいので、これが普通だと思います。

色々な方針があるとは思いますが、α表記を使う場合、
新機能追加が終わった時点でβに移行して、
目立ったバグがなくなった時点でRCに移行して、
それで問題ないようならリリースするというのが一般的です。
そういう方針でリリースする場合、
0.2.0以降は、αとかは設けずに、バグ修正などを0.2.1, 0.2.2などに盛り込みます。
API互換性を破壊しないような機能追加なども0.2.x系列で問題ないです。

今の段階では新機能追加がメインになると思いますので、
0.2.0リリース後にブランチさせて0.3系列に移行することになると思いますが、
バグ修正などで0.2.1を出す場合は0.3系列をそのまま持って来ずに、
0.2系列に対して新規バグ修正をバックポートするような形が一般的です。
いわゆるSTABLEとCURRENTのブランチのスタイルです。

その他のよく使われる流儀として、LinuxやGIMPなどが採用している、
マイナーバージョンの偶数はSTABLE、奇数はCURRENTというのもあって、
これだとCURRENTもαとかβとかではなく具体的な数字になる面もありますが、
規模が小さい段階でブランチを全面に出しても実質あまり意味がない気がするので、
今の体制には合わないかな、という気はします。

> ご迷惑をおかけして申し訳ありません。
とんでもありません。こちらこそ最近何も出来なくて申し訳ありません。
648Tino ◆sMrLqQHxo6 :04/03/18 00:30
>>645
> 開発版リリースはmona-0.2.0alpha2-image.zipです。
私が死んでいる間に色々と進んでいるようで嬉しいやら申し訳ないやら。

0.2.0α2ベースで開発をするためにmakeしてみましたが、
0.1.7と同様にMlcCtype.hとMlcCtype.cppが抜けているようです。
CVSから取ってきて追加したところ今度はfat_writeでFDC.DRVがなくてエラーになりました。
リリースイメージを見たところFDC.DRVは0.2.0α2には含まれていないようなので
単純にコメントアウトしたところmakeはうまくいきました。
動作もOKです。いい感じです。:-)

あ、別に責めているわけではありませんよ。
α版なんて普通そんなものなので。
649Tino ◆sMrLqQHxo6 :04/03/18 01:20
>>496
> その場合、MonaにAUTOEXEC.BATみたいなのがあれば便利だと思いました。
> シェルサーバを改造すればすぐ出来るかもしれませんが……。
個人的には結構重要だったので、パッチを作ってWikiに置いておきました。
650364:04/03/18 02:11
>> 645 ひげぽんさん
おつかれさまです。
体裁を整えて公開していただきありがとうございます。
今後ともよろしくお願いします。

また、WikiにはBochs以外の例としてtwoOStwoで動かした例を
記載してみました。

>> 646さん
サンクスです。今後ともマターリがんがります。
楽しみにしていただけると嬉しいです。

>>649 Tinoさん
おつかれさまです。
ベータで商用なエミュレータtwoOStwoにてMACアドレスゲットのテストを
しようとしましたが、キーボードサーバ、マウスサーバがkillされてしまい、
お手上げでした。今回はShellを直接いじって起動する際、
コンパイル時に決めたアプリを起動するようにしていましたが、
タイムリーなパッチありがとうございます。
651Tino ◆sMrLqQHxo6 :04/03/18 02:18
>>650
すみません。バグも混入させてしまったみたいです。
ご利用の際には以下の空行チェックを外していただければ幸いです。
if (strlen(command) < 1) {
  /* command is empty */
  printf("%s", PROMPT);
  position_ = 0;
  return;
}
652Tino ◆sMrLqQHxo6 :04/03/18 02:55
度々すみません。
>>651
> ご利用の際には以下の空行チェックを外していただければ幸いです。
と書きましたが、問題はここではなくて、
AUTOEXEC.BATを読み込むことで悪影響が出た結果のようでした。
というわけで申し訳ありませんがパッチのご利用は見送っていただければ幸いです。
チェック不足のための勇み足でご迷惑をお掛けしたことをお詫びします。
653Tino ◆sMrLqQHxo6 :04/03/18 04:25
原因が分かりました。
byte data = new data[len];
delete [] data;
とする間にdata++などとしてポインタをいじっていました。
そのためdeleteの際にメモリ内容が破壊されていたみたいです。
何て初歩的な……。アホ過ぎました。情けないです……。_| ̄|○

あとShellServerをよく読むとHListを使う必要がなかったことも分かりました。
というわけでまともなパッチを再度アップしておきました。
お騒がせして本当に申し訳ありませんでした。
654ひげぽん ◆Ngzcp/NZpA :04/03/18 22:35
申し訳ありません。cvsの操作でミスをした可能性がありますので
調べてみます。

> 動作もOKです。いい感じです。:-)

ありがとうございます。多少安定したかなと自分でも思っています。

> あ、別に責めているわけではありませんよ。
> α版なんて普通そんなものなので。

ありがとうございます。
でも使っていただく方に迷惑がかからぬよう次回から気をつけます。

>> その場合、MonaにAUTOEXEC.BATみたいなのがあれば便利だと思いました。
>> シェルサーバを改造すればすぐ出来るかもしれませんが……。
> 個人的には結構重要だったので、パッチを作ってWikiに置いておきました。

ありがとうございます。パッチ取り込ませていただきました。
すごく便利ですね。すばらしいです。
一点だけ変更しました。
AUTOEXEC.BATだとDOS互換とも取れなくもないので
ファイル名をAUTOEXEC.TXTとしました
655ひげぽん ◆Ngzcp/NZpA :04/03/18 22:36
>>364さん
> 体裁を整えて公開していただきありがとうございます。
>今後ともよろしくお願いします。

お疲れさまです、今後ともよろしくお願いいたします。

> また、WikiにはBochs以外の例としてtwoOStwoで動かした例を
> 記載してみました。

拝見しました。最近良い事ばかりでうれしい限りです。
最新バージョンのtwoOStwoがでたらカーネルの動作を確かめてみます。
656Be名無しさん:04/03/18 22:53
.txtとするくらいなら拡張子いらないんじゃないの?
657Be名無しさん:04/03/18 22:59
>>654
>AUTOEXEC.BATだとDOS互換とも取れなくもないので
>ファイル名をAUTOEXEC.TXTとしました
それがいいんだって。DOSから知ってる香具師にはうれしい。
658Be名無しさん:04/03/18 23:01
>>657
同意
そういう所はオリジナリティを見せる所ではない
逆に変なこだわりを感じてキモい
.TXTなんて尚更センスなさ過ぎ
659Be名無しさん:04/03/18 23:08
どうせ説明するときに
- AUTOEXEC.TXT=DOSのAUTOEXEC.BATみたいなやつ
- SYSCONF.TXT=DOSのCONFIG.SYSみたいなやつ
って書く羽目になる悪寒。
660Be名無しさん:04/03/18 23:23
DOS流儀なんてPOSIXみたいな一種の標準だからな。
誰もDOS互換なんて思わないだろうし、思われて何が困るか不思議っちゃ不思議。
前からDOSみたいに遊ばせろ〜って騒いでた香具師がいたくらいだから。
661Be名無しさん:04/03/18 23:24
影たんも互換じゃないからとか言ってヘッダ名を変なのにしてたけど
そーゆーのは感心しない
662Be名無しさん:04/03/18 23:29
ReactOS互換にすればいいじゃない。
663Be名無しさん:04/03/18 23:37
ヘッダに関しては他のOS用とソースが一文字も違わず、
マクロで条件コンパイルする必要も無い事を目指すにはそうなるって話で。
そもそも中身が違うってんなら名前違うのは仕方が無い。
見ればどれがcstdlib相当かは分かるし、そんなに問題は無い。

3文字の拡張子って形でファイルタイプを表現するなら、.txtは適切じゃないような。
バッチファイルだから.batで良い。
コウモリが飛び回るアプリを.batとする予定があるとか、
別の奴用に予約してあるなら別だけど。
664Be名無しさん:04/03/18 23:39
>>663
>ヘッダに関しては他のOS用とソースが一文字も違わず、
>マクロで条件コンパイルする必要も無い事を目指すにはそうなるって話で。
じゃ関数名も変えろ。クラスでラップしろ。
K&R一部準拠で何が悪い?
665ひげぽん ◆Ngzcp/NZpA :04/03/18 23:55
>>656さん
>>657さん
>>658さん
>>659さん
>>660さん
>>661さん

すみません。ファイル命名センスがないのはよく分かっています(笑)
このへんは好みになってしまいますが
私がDOSをバックグラウンドにもっていないのに
なんだかそんなファイル名なのが違和感があった次第です。
別にそんなことを気にしなくてもという人がおおければ
元に戻してもいいかな後も思っています。

もしオリジナルファイル名でMonaらしいファイル名が
ありましたら喜んで変えます。
666Be名無しさん:04/03/19 00:07
>>664
いやいや、関数名だけは標準と一緒で、ちょっと変更した時に不具合あれば
includeするファイル名を見る所で「あ、これって完全に仕様みたしてはいないんだった」
という事実を思い出させてくれる絶妙なバランス感覚が……。
いや基本的に同意なんだけどね。

>>665
バッチファイルだから.batか.batchで良いんじゃないでしょうか。
667Be名無しさん:04/03/19 00:22
あ。ていうか、おめ。 >ひげ氏
668364:04/03/19 00:37
>>651-653 Tinoさん
おつかれさまです。
ありがとうございます。
今のところ、自分の作成中のコマンド実行することが多いので、
本家にも採用されて、今後便利だと思います。
configのほうも、svrファイル書き込まないようにMakefileコメントアウトとか
してましたが、その必要も無くなり、AUTOEXECとあわせると、よりPCよりのOS
と同じ感じで作業ができて嬉しいです。

>>654-655 ひげぽんさん
パッチ取り込み乙でつ。
こちらこそ今後ともよろしくお願いします。
twoOStwoで動くまではBochs依存のコードかと思いましたが、
とりあえず安心して、次のステップに進みたいです。

669364:04/03/19 00:43
>>668
主語が省かれて微妙に分かりにくかったです。

NICの初期化部分は〜
>twoOStwoで動くまではBochs依存のコードかと思いましたが、
ということです。
670Be名無しさん:04/03/19 00:55
>>627
ガッ
671Be名無しさん:04/03/19 01:46
>>666
自己満足
672Be名無しさん:04/03/19 01:52
Java認証テストじゃないんだからさ。
Wabaみたいに名乗らざるを得ないわけじゃない。
他人に使いやすいかどうかだろ。
673Be名無しさん:04/03/19 01:59
NWSOSみたいに_stdio.hとかの方がまだまし。
674Be名無しさん:04/03/19 02:09
マルチプラットフォームで書くときにstdio.hごときで#ifdef使わせるなよ。
675 ◆nl7ClMRWE6 :04/03/19 02:13
>>673
よくご存知で。
一文字名前違えば大して事情は変わらないっす。
まあ自分でstdio.h用意するって発想するようになってから
標準関数をラッパで置き換えるような事をしやすくはなったんですが。
ソースが公開されてると基本的にいらない手間ですけど。
676Be名無しさん:04/03/19 02:29
自分で何も新しい発想が生めない香具師が
名前変えて独自性に酔ってるだけだろ。
677Be名無しさん:04/03/19 02:38
>>676
そんな事は無いと思うが……。
ていうかそんな事で陶酔出来る幸せな奴見た事無いぞ。
ネットでもリアルでも。
678Be名無しさん:04/03/19 02:52
準拠しないことの言い訳で名前を変えてしまうというのがまずいのは
準拠しようと言う努力を放棄したことを明言しているところだろう。
別に完全準拠を目指せとは言わないが、
天上の高みを目指す気持ちを捨てたものに光はない。
679Be名無しさん:04/03/19 02:58
>>678
>光はない。
自分で影って名乗ってんじゃん(ゲラ
680Be名無しさん:04/03/19 03:01
>>679
よくそんな皮肉が思いつくな。とんでもねぇ。呆れた。
でも言い返せないから座布団10枚!
681Be名無しさん:04/03/19 03:04
おまいらくだらないこと言ってないでWikiの一言見たか!?
お祝いですよ!!age
682Be名無しさん:04/03/19 03:15
つまりアレだろ。
>>388って事だろ。
683Be名無しさん:04/03/19 03:21
>>682
よく見てるな。座布団10枚!
684Be名無しさん:04/03/19 03:26
このスレはハイテンションに座布団を乱発しつつひげ氏を祝うスレになりました。
というところで寝る。
685Be名無しさん:04/03/19 09:47
ひげおめ
686Be名無しさん:04/03/19 10:04
687Be名無しさん:04/03/19 10:14
>>686
僻みか?(プ
688Be名無しさん:04/03/19 10:24
>>687
卑下オナーニとかっつってた香具師じゃね?
オナーニじゃなくて残念だったね。(ゲラ
689Be名無しさん:04/03/19 10:30
嫁が2ちゃんねらーか
690Be名無しさん:04/03/19 10:31
なるほど、やっと謎が解けた。
以前MASKが結婚がどうたらって仄めかしてたのは卑下のことだったか。
てっきりK周辺のことかと思ってたよ。(あり得ねーと思ったが)
691Be名無しさん:04/03/19 10:33
エリナ?
692Be名無しさん:04/03/19 10:41
キンジョウ・ウォン
693Be名無しさん:04/03/19 10:44
>>692
マニアック過ぎ
694Be名無しさん:04/03/19 10:50
僕の髪が 肩までのびて
君と同じになったら
695Be名無しさん:04/03/19 10:51
カクカク ,; ヘ⌒ヽフ  ブヒブヒ
    / (  ・ω・)) -=3
 ε//   し ヘ⌒ヽフ   ブヒーッ
  ( (  __ノ(   ?)) -=3
   し しー し─J
696Be名無しさん:04/03/19 11:11
>>694
古過ぎ。

>>695
スレタイ変えないとな(w
697Be名無しさん:04/03/19 11:13
何を作るの?ボク分かんない。
698Be名無しさん:04/03/19 11:17
次スレはこれでいいの?
子供を作ろうpart9
699Be名無しさん:04/03/19 11:19
>>698
もう少しひねれ。はっきり言い過ぎ。
700Be名無しさん:04/03/19 11:24
700getずざー
701Be名無しさん:04/03/19 11:28
確か卑下って麺食いだっつってたよね
702Be名無しさん:04/03/19 11:33
>>690
それはまた別の奴だ。
703Be名無しさん:04/03/19 11:36
ひげぽんおめでとう!
704Be名無しさん:04/03/19 11:46
>>701
できちゃったケコーソ
705Be名無しさん:04/03/19 11:52
>>704
何でもいいじゃん。とりあえず祝っとけ。
706Be名無しさん:04/03/19 11:57
そだね。
めでたい!
おまいら昼間から揃いも揃って2chかよ。つくづくお
めでてー香具師らだな。2chやってる暇あったら職
でも探したらどうだ?その方が少しは社会の為だ
と思わんか?どうだ?ん?そんな事よりもう昼だ。
うまい棒食いてぇな。うん。じゃあな。あばよ。
708Be名無しさん:04/03/19 12:16
シス管が怖いと思いつつ、会社アドレスの鬼彼と年始メール。
変な言葉は使わないけど、思い切り私用メールだからな。
鬼彼は「僕しか見ないから大丈夫」って言うけど、
シス管のこととかわかってなさそうだからな・・・。ま、いいや。
709Be名無しさん:04/03/19 13:31
みんなで祝おう!!おめでとー
710Be名無しさん:04/03/19 13:36
スレが伸びてると思ったらそういうことか!!
ひげぽんおめでとう!
711Be名無しさん:04/03/19 13:44
おめれとーーーー
712Be名無しさん:04/03/19 13:47
うわ、マジびっくり
でもおめでとう
713Be名無しさん:04/03/19 13:49
いやー、めでたい、めでたい!!
714Be名無しさん:04/03/19 13:53
゚・*:.。. .。.:*・゜゚・*:.。. .。.:*・゜゚・*・゜゚・*:.。. .・゜゚・*:.。. .。.:*
\(^▽^)/ご成婚おめでとうございま−す♪
゚・*:.。. .。.:*・゜゚・*:.。. .。.:*・゜゚・*・゜゚・*:.。. .・゜゚・*:.。. .。.:*
715Be名無しさん:04/03/19 14:01
>>696
>古過ぎ。
昔は定番だったんだけどね、お祝いに歌っとくよ♪

僕の髪が 肩までのびて 君と同じになったら
約束どおり 町の教会で 結婚しようよ MMMM
古いギターを ボロンと鳴らそう 白いチャペルが見えたら
仲間を呼んで 花をもらおう 結婚しようよ MMMM
もうすぐ春が ペンキを肩に お花畑の中を 散歩に来るよ
そしたら君は 窓をあけて エクボを見せる 僕のために
僕は君を さらいにくるよ 結婚しようよ MMMM
雨が上がって 雲の切れ間に お陽様(ひさま)さんが 見えたら
ひざっこぞうを たたいてみるよ 結婚しようよ MMMM
二人で買った 緑のシャツを 僕のおうちのベランダに 並べて干そう
結婚しようよ 僕の髪は もうすぐ肩まで とどくよ
716Be名無しさん:04/03/19 15:03
ひげぽんさんおめでとうございます!

# /.Jにタレコ…む?
717Be名無しさん:04/03/19 15:06
このホストでは、しばらくスレッドが立てられません。
またの機会にどうぞ。。。


ホスト
子供を作ろう
名前: Be名無しさん
E-mail: sage
内容:
子供を作っているまたは、作ろうとしている人たちのための
スレッドになればと思います。
- http://mona.sourceforge.jp/dynamic/pukiwiki/pukiwiki/pukiwiki.php?今日の一言(不定期更新)

・ 私事で恐縮ですが。結婚しました。 -- ひげぽん 2004-03-18 (木) 23:06:49

おめー

分からないことがあったら2ちゃんねるガイドへ。。。

アクセス規制・プロキシー制限等規制は、2ちゃんねるビューアを使うと回避できることがあります。
718Be名無しさん:04/03/19 15:53
>>717
マジで立てようとしたのかYO!(w
BBS_THREAD_TATESUGI=64

この板で一回スレ立てたら数ヶ月は立てられないんじゃないかな
720Be名無しさん:04/03/19 16:03
代理立てしました

子供を作ろう
http://pc.2ch.net/test/read.cgi/os/1079679774/
721Be名無しさん:04/03/19 16:08
>>720
乙!
ケコーソ関連ネタはそっちに移動してね>ALL
722Be名無しさん:04/03/19 16:17
>>720
さいごに
-

おめー
-
って入れて欲しかったけどまぁいいかw
723Be名無しさん:04/03/19 16:18
> おめー

Σ(l|l゚Д゚) すいません、てっきり本文外だと思いました
724Be名無しさん:04/03/19 17:19
マジでスレ立ってるしΣ(゚д゚;)
725ひげぽん ◆Ngzcp/NZpA :04/03/19 20:47
>>お祝いの言葉を下さった方々
ありがとうございます。
今後ともよろしくお願いいたします。

>>666さん
> バッチファイルだから.batか.batchで良いんじゃないでしょうか。

そうですね。.batでもよいかなと思い始めました。

>>364さん
> パッチ取り込み乙でつ。
> twoOStwoで動くまではBochs依存のコードかと思いましたが、
> とりあえず安心して、次のステップに進みたいです。

お疲れ様です。順調なようで何よりです。
726ひげぽん ◆Ngzcp/NZpA :04/03/20 00:27
現在オブジェクトマネージャ実装に向けて構想中です。

私の思うオブジェクトマネージャとは
・オブジェクトの生成・破棄
・オブジェクトの参照の管理
・名前空間によるオブジェクト参照の提供(ハンドルのようなもの?)
・オブジェクトに対する操作(read/writeなど)
などのサービスを提供するものです。

またここで言うオブジェクトとは
カーネル内のプロセス・スレッド・ファイル・Mutex・共有メモリなどに使われているデータを
保持する構造体(またはクラス)を指します。

イメージとしては
mm->open("/fs/disk0/hoge/hoge.txt", ...)とか。

mm->create("/type/UserProces", ...)みたいな感じです。

オブジェクトマネージャが1プロセスとして実装されることを目指していますが
実装してみないとなんともいえなそうです。
727ひげぽん ◆Ngzcp/NZpA :04/03/20 00:27
今悩んでいるのが動的な「型」の追加の方法です。
どういうことかというとオブジェクトマネージャを使用して
オブジェクトを生成するとき、ユーザーは

「xxxxという型のオブジェクトを生成して」とお願いします。
ex) Processオブジェクトを生成して mm->create("type/Process", ...)

この場合はオブジェクトマネージャがデフォルトで知っている型なので問題ないのですが
動的な型の追加ができた方が便利かなと思っています。

実際にNTでは出来るようなのでなんらか方法があるとは思うのですが
いまいちアイデアが浮かばず停滞気味です。

オブジェクトマネージャの議論はこちら↓
ttp://mona.sourceforge.jp/dynamic/pukiwiki/pukiwiki/pukiwiki.php?%B5%C4%CF%C0%2F%A5%AA%A5%D6%A5%B8%A5%A7%A5%AF%A5%C8%A5%DE%A5%CD%A1%BC%A5%B8%A5%E3
728Be名無しさん:04/03/20 02:59
>>727
>実際にNTでは出来るようなのでなんらか方法があるとは思うのですが
COMのことだったら言語非依存のABIを決めて作るからできるわけ。
だからActiveXで何か作るときはATLを使った特殊な作り方をする。
それが面倒くさいからVMを間に挟んだ上で
ふつうにベタ書きしたクラスで作れるようにしたのが.NET。
そこまでしないと出来ることじゃないよ。
BeOSなんかはその辺のC++の限界にぶち当たったわけだし。
729Be名無しさん:04/03/20 03:37
ともかく普通にコンパイルしたC++のクラスを動的に扱うのは無理。
独自コンパイラとVMを作るくらいの手間がいる。
実態は全部Cレベルの構造体にバラすような感じ。
730ひげぽん ◆Ngzcp/NZpA :04/03/20 23:58
>>728さん
>>729さん
アドバイスありがとうございます。
クラスの動的な操作はやはり無理があったようです。

今やりたいこと・自分の技量で出来ることを
もう一度きちんと検討してみます。m(__)m
731Be名無しさん:04/03/21 03:54
>>730 毎日学校帰りに串に4つか5つか唐揚げ刺さったの、100円でさ、食ってるんだけど

大丈夫かね?w
732通りすがり:04/03/21 13:45
頑張ってください!
733Be名無しさん:04/03/21 19:43
  Mona     GUI     まだ?
  ∧_∧   ∧_∧    ∧_∧
 ( ・∀・)  ( ・∀・)   ( ・∀・)
⊂ ⊂  )  ( U  つ  ⊂__へ つ
 < < <    ) ) )     (_)|
 (_(_)  (__)_)    彡(__)
734Be名無しさん:04/03/21 20:10
MonaGUIはIKARIYAと名称が変わりました
あしからず
735Be名無しさん:04/03/21 20:27
だめだこりゃ
736Be名無しさん:04/03/21 21:51
MONAへの移植指令がでたぞ byいかりや
ttp://ponk.jp/el/index.php?page=9
737Be名無しさん:04/03/21 21:53
>>shadowタン
ユーザ予備軍の意見は放置プレイで、
実際のユーザからの不満が出てから考えるというのもアリ。
738Be名無しさん:04/03/21 21:57
>>737
禿同
卑下もいろいろ叩かれたがモノを作り上げて黙らせた
実際に使われるようになるまでは苦しいと思うががんがれ!
739Tino ◆sMrLqQHxo6 :04/03/22 00:44
>>733-735
放置して誠に申し訳ありません。
仕事に追われてMonaGUIどころかネットすら出来ない状況でした。
今も書類が残ってるし後ろに上司がいるのでまた後ほど……
740Be名無しさん:04/03/22 00:56
>>739
仕事乙。
741Be名無しさん:04/03/22 02:01
>>738
卑下の凄いところは一見罵詈雑言に見える発言でも
内容があったら誠実に対応してきたところ。
Monaの内容にも反映されている。
七誌で暴言を書き込んで無視したりしない。
742Be名無しさん:04/03/22 21:44
        / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
        | ひげぽんageeeee!!
   \   \
          ̄ ̄ ̄|/ ̄ ̄ ̄ ̄ ̄ ̄ ̄
      \ ヘ⌒ヽフ
       (  ・ω・)
        ⊂  つ
 ̄  ̄   ε(つ ノ ト  ̄  ̄  ̄
         (ノ    オ
       /       \
  /       :    オ
     /    || .   ォ  \
     /     | :   ォ  \
    /       .
           | .   ォ
           | | : .
           |:  .
           || .
743Be名無しさん:04/03/22 22:24
>>739
もつかれ〜
MONA GUI期待してます。
744Be名無しさん:04/03/22 22:26
 ひげたん     Tinoたん     shadowタン
  ∧_∧   ∧_∧    ∧_∧
 ( ・∀・)  ( ・∀・)   ( ・∀・)
⊂ ⊂  )  ( U  つ  ⊂__へ つ
 < < <    ) ) )     (_)|
 (_(_)  (__)_)    彡(__)
                 がんが
745ひげぽん ◆Ngzcp/NZpA :04/03/22 22:59
>>732さん
ありがとうございます。

>>739 Tinoさん
デスマーチお疲れ様です。

>>736さん
> ttp://ponk.jp/el/index.php?page=9

↑のページいいですよね。
構造をみた感じ割と簡単に移植できそうな感じがしました。

>>744さん
ありがとうございます。

今日はIDManagerというクラスを追加しました。

カーネル内オブジェクトへの参照をユーザー側に
渡す代わりに、ID(ハンドル)を渡して操作対象を結び付けます。

スレッド生成・joinで試験実装を行いました。
746Be名無しさん:04/03/22 23:28
>>745
なんとなく昔祭りになってたOSASKのスロット論争を思い出した
747Be名無しさん:04/03/22 23:36
>>746
おまいも転向組か!
748Be名無しさん:04/03/23 22:51
勉強会読んだよ
漏れも勉強しようかな
Tinoタンやっぱりすごい人なんだね
749Be名無しさん:04/03/24 00:31
>>747
実際MONAとOSASKには今どれくらい差があるんだ?
750Be名無しさん:04/03/24 02:22
Window System の開発経験者って、必要だったりする?
751Tino ◆sMrLqQHxo6 :04/03/24 06:41
>>740 >>743 >>744 >>745
ありがとうございます。

>>748
最近手も足も出ない状態でお恥ずかしい限りです。
ようやく長いトンネルの出口が見え始めました。
設定ファイルの名前問題が解決すると同時に動き始めたいです。

>>750
素晴らしいです。
752Be名無しさん:04/03/24 20:13
設定ファイルがMONA.CFGに落ち着いたみたいだね
MONA.CFGでVESA関連の指定が出来るようにするのをキボンヌ
753Be名無しさん:04/03/24 20:22
VESA_WIDTH=800
VESA_HEIGHT=600
VESA_BPP=16
こんな感じ

iniファイルみたいにセクションを設けるといいかもしんない
[VESA]
WIDTH=800
HEIGHT=600
BPP=16
754Be名無しさん:04/03/24 20:38
起動メッセージの最初にバージョンを表示したらいいと思った
開発版をあれこれいじってると何使ってるか混乱する

Mona ver.0.2.0alpha5
Copyright (c) 2002-2004 higepon
Setting PIC ...
こんな感じ
755Be名無しさん:04/03/24 20:48
>>753
Win3.1のwin.iniみたいでワラタ。
でもいいかもしれない。
756Be名無しさん:04/03/24 21:02
いまどきプレーンテキストですか?
757Be名無しさん:04/03/24 21:18
流行ならXMLだろうけど
さすがにカーネルに入れたらG氏に怒られるだろ
後でカーネル分離を考えるつなぎってことで
758Tino ◆sMrLqQHxo6 :04/03/24 21:28
>>751
> 設定ファイルの名前問題が解決すると同時に動き始めたいです。
とりあえずWikiに0.2.0α5用のSDKを上げておきました。
759ひげぽん ◆Ngzcp/NZpA :04/03/24 22:36
>>748さん
そうですね。
前からすごいことは知っていましたがソースを
詳しく読んでもっとすごいことに気づきました。

>>750さん
もしよろしければ気づいた点など
アドバイスいただければ幸いです。

>>751, 758 Tinoさん
お疲れ様です。
Mona SDKリリースありがとうございました。

>>754さん
ご提案ありがとうございます。
次回開発版リリースより表示されるようになります。

>>753さん
> VESA_WIDTH=800
ご提案ありがとうございます。
残念ながら現時点では上記のような設定は出来ません。

画面モード切替には必ずカーネルのリコンパイルが伴います。

理由は画面モード切替をリアルモードで行っているからです。
=プロテクトモードで画面モード切り替えをサポートしていない。

プロテクトモードでの画面モード切替方法は
・VBE プロテクトモードインターフェースを使用
・仮想86モードを使用
の2通りがありますがどちらもサポートされておりません。
760Be名無しさん:04/03/24 23:18
ttp://ponk.jp/el/index.php?page=9

の作者が光臨している!!!

そしてWaba for Monaの開発が始まっている。

次回のリリースが楽しみだ。
761750:04/03/25 04:34
おもしろそうだし、お役に立てるなら、よろこんで。

昔いた会社で覚えてしまった X11R5のMITオリジナルコード をベースとした
アドバイスなら、いろいろ出来ると思います。ネタが古いのは申し訳ないですけど。
それと、今月いっぱいは仕事が忙しいので、来月にならないとちょっと時間とれないかも。

ついでに、時間が取れたら、3Dエンジンライブラリでも創ったりするかも。
762Be名無しさん:04/03/25 10:42
ところでKONOXの開発者って中学生らしいな。
763Be名無しさん:04/03/25 15:18
>>762
マジカヨ
最近の中学生は凄いな
764Be名無しさん:04/03/25 21:34
>>762
>>763
自作自演はやめてくれ

マジレスすると中学生でもあれくらい余裕だろ
きちんと続けていいものが作ることが出来たら
またこい
765Be名無しさん:04/03/25 22:09
>>764
つまり、DQN-OSとはいっしょにするなと?
766ひげぽん ◆Ngzcp/NZpA :04/03/25 22:21
>>760さん
両ニュースともにとてもうれしいです。
本当に次回リリースが楽しみです。

>>750さん
> アドバイスなら、いろいろ出来ると思います。ネタが古いのは申し訳ないですけど。
> それと、今月いっぱいは仕事が忙しいので、来月にならないとちょっと時間とれないかも。
> ついでに、時間が取れたら、3Dエンジンライブラリでも創ったりするかも。

ありがとうございます。
3Dエンジンとても楽しみです。
是非Wikiにも一度お立ち寄りください。

>>762さん
すごいですねぇ。一体何歳年下なんだろう・・・
767Be名無しさん:04/03/25 23:36
>>759 ひげぽん ◆Ngzcp/NZpA
>プロテクトモードでの画面モード切替方法は
>・VBE プロテクトモードインターフェースを使用
>・仮想86モードを使用
>の2通りがありますがどちらもサポートされておりません。

でもVBEプロテクトモードインターフェースってFunction 05h/07h/09hしか提供されていないみたいだよね。
この場合欲しいのはFunction 02hなわけで。
やっぱり仮想86モードしかないのかな。
768Be名無しさん:04/03/26 00:31
リアルモードでファイル読めばいいじゃん。
769Tino ◆sMrLqQHxo6 :04/03/26 03:56
ようやくMonaGUIで安定して日本語が表示できるようになりました。
時間がないのでFDイメージとスクリーンショットだけですがWikiに上げておきました。
http://mona.sourceforge.jp/dynamic/pukiwiki/pukiwiki/pukiwiki.php?Tino%2FMonaGUI

散々注文を付けて申し訳ありませんでした。>ひげぽんさん
お陰様でイメージしていた動作を得ることができました。
本当にありがとうございました。

年度末の忙しさで開発が20日も停滞してしまって
あぼーんかとやきもきさせてしまって申し訳ありませんでした。>スレの皆さん

今もまだゆとりがあるとは言えない状態なので
ソースやサンプルなどのリリースはもうしばらくお待ちください。
今月中に0.1に漕ぎ着けたいとは思っています。
770Be名無しさん:04/03/26 11:20
>>769
うおおおおおおおおおおおおおおおおおおおおおおおっっっっっ!
すげぇ!
771Be名無しさん:04/03/26 11:22
キタ━━━━━(´_ゝ`)━━━━━!!!!

#VGA表示もできたらいいよね。急ぎはしないけど。
772Be名無しさん:04/03/26 14:14
大きいAA使ってもおもしろいと思う…
           _,,,,,,___,,,,,--,,_
         _,-,_i_ ,      l-ノヽ
.       / \ ヽ  i,  _l,,/  ~''-,_
      /___,,,,,,_,,,-''~~'''''-''~-'''''''''-,~/i,_
.     ,_i'-,,,,_,,-'::::::::::::::::::::::::::::::::::::::::::~'ヽ,_l
.     / '''''/::::::::::::::::::::::::::::::::::::::::::::::::::::::::::ヽ.,,
     / ./:::::::::::::::://::::::::::i::i;::::::l:::::ヽ:::::::::::::::ヽヽ
    l_//:::::::::::::/:/::/::::::::ll:l l::::::l::::::ヽ::::::::::::::::ヽ.ヽ
     ,ノ/:::::::::::::/:/://:::::;:/l:l l:::::l.l:::::::l:::;::::::::ヽ:::l ~'i
     l.l:l::::::::::::/:// /::/l:/ l:l  ll:::l .l::;:::l:::l::::::::::l:::l
.     l|.l::::::::::// / l::/_/-.l/ ~''l'l:l,,,_l:ll::lヽl:::::::::l.l:l
     ,l-l::::::::/_,,,l,-l/ /___   ___   l '~~l.l::::::/ l|
.   /::::ヽ::::/l =====   ===== /ll::::/:ヽl     
.  /:::;-''i:ヽl::l  ////      //// l::l/~''-;ヽ   <モナーOS期待してます
  /;;-''  .ヽl::::l,_     ___    /:l    ~''ヽ    
 /''    _..,l::::l-ヽ,,_  ヽ,,_____ノ  _,,-'''l::::l~~''''--,,,_
  _,,,,-''''~  .l::::l.-==/~''i--,,,,,,,--,'~-'' l::::l 
 ヽ      l::::l_,-〈  ~''''人'~ ヽ''- l:::l 
. /\      l:::l  ヽ  .(⌒)  l   l::l
/         .l::l  ヽ,_,ノ'~'''~ヽ,_ノ   .l:l
          l|    /  l  ヽ   l!
        / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
       /
       /         GIGABYTE
773Be名無しさん:04/03/27 00:15
>>769
おお。なんかBeOS風味ですね。
774ひげぽん ◆Ngzcp/NZpA :04/03/27 01:38
>>767さん
ご指摘ありがとうございます。
私より全然詳しいようで、アドバイスありがとうございます。
残る選択肢は仮想86ということですね。

>>768さん
確かにその方法であれば完璧に、要件をみたしているとは思うのですが
ちょっとそこまでの体力がありません。m(__)m
申し訳ありません。

>>769 Tinoさん

おめでとうございます!?

実機・エミュレータで動作確認をさせていただきましたが
快適に動いています。

> 散々注文を付けて申し訳ありませんでした。>ひげぽんさん
> お陰様でイメージしていた動作を得ることができました。
> 本当にありがとうございました。

とんでもないです。
独りよがりのAPIが如何に使いづらいかがよく分かりました。
おかげさまで多少使いやすくなったと思います。
指摘だけでなく改善案までいただけたので大変勉強になりました。

>>772さん
ありがとうございます。
775ひげぽん ◆Ngzcp/NZpA :04/03/27 01:42
>>767さん
ご指摘ありがとうございます。
私より全然詳しいようで、アドバイスありがとうございます。
残る選択肢は仮想86ということですね。

>>768さん
確かにその方法であれば完璧に、要件をみたしているとは思うのですが
ちょっとそこまでの体力がありません。m(__)m
申し訳ありません。

>>769 Tinoさん

おめでとうございます!?

実機・エミュレータで動作確認をさせていただきましたが
快適に動いています。

> 散々注文を付けて申し訳ありませんでした。>ひげぽんさん
> お陰様でイメージしていた動作を得ることができました。
> 本当にありがとうございました。

とんでもないです。
独りよがりのAPIが如何に使いづらいかがよく分かりました。
おかげさまで多少使いやすくなったと思います。
指摘だけでなく改善案までいただけたので大変勉強になりました。

>>772さん
ありがとうございます。
776ひげぽん ◆Ngzcp/NZpA :04/03/27 01:43
2重投稿すいません。m(__)m ブラウザの挙動がおかしかったです。

Mona/開発版 mona-0.2.0alpha6-image.zipをリリースしました。

・プロセス生成時に物理ページ返却 mona_v1.0.tar.gz
・VRAMマッピングロジックミス修正
・FD交換検出APIの改良
・Message::lookupMain Thread(const char* name)追加
・MSG_SERVER_START_OKがくるまで次のサーバーを起動しない
・userlib: Memory MapクラスがI/F変更
・MACアドレス取得 src/user/NICにソース追加

ダウンロードは↓
ttp://mona.sourceforge.jp/dynamic/pukiwiki/pukiwiki/pukiwiki.php?Mona%2F%B3%AB%C8%AF%C8%C7

共有メモリ確保方法の詳細は↓

ttp://mona.sourceforge.jp/dynamic/pukiwiki/pukiwiki/pukiwiki.php?Mona%2F%A5%A2%A5%D7%A5%EA%BC%C1%CC%E4%BD%EA

※開発版リリースにはMONA GUIはまだ含まれていません。ご了承ください。
777Be名無しさん:04/03/27 12:23

                      \ │ /
                       / ̄\  / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
                     ─( ゚ ∀ ゚ )<  Monaはひとつ!
                       \_/  \_________
                      / │ \
            .              巛 ノノノノ巛         ∩ ∧ ∧∩
  (\   '´ Vヽヽ /)∩∧ ∧∩   ∧ ∧ | |( ゚∋゚ )| | ∩∧_∧ ∩ \( ゚∀゚ )/   / ̄ >
  \\ソiノ=ω=ヾ) / ヽ( ゚∀゚ )/ (ヽ*゚ー゚)')\ \// ヽ( ・∀・ )/  |    /.  ∩|(゚U゚)|∩
    \(ヽリ゚ ヮ゚ノ ')   |   〈  ヽ   ノ  |   |    |     |   |    |   ヽ y  ノ
      ( <髭> )   / /\_」 〜(  ノ  /\ /ヽ   /  ∧  |   / /\」     ) (  )
     /lliく/_|〉リ     ̄        し'J  / /\ .\∠/  \ \ / /       (  ∪
    (/  し'ノ\)              ミ/   \__ミ       ̄ ̄         ∪

カーネル全般  ヒゲタン
GUI   Tinoタン
FAT   Gタン
ネトワーク  364タン
glibc   影タン
Waba ベイサイドタン
ゲーム移植  ttp://ponk.jp/el/index.php?page= の作者タン
WEB構築・管理  yossyタン
778Be名無しさん:04/03/27 12:37
つまりamona吸収合併かね
779Be名無しさん:04/03/27 18:32
周辺機器メーカーの方MONA用ドライバ
提供汁、って言いに逝ってもOK?
780Be名無しさん:04/03/27 18:36
それにしてもこのスレOS板に移転して良かったな・・・
781Be名無しさん:04/03/27 19:08
>>779
株式公開してからだろう。
782Be名無しさん:04/03/27 19:36
>>764
KONOX、ZAKOS と OSの大安売りだな。
漏れが厨房の時はファミコンばっかりしてたよ。
パソコンなんてものも滅多に見かけなかった気がする。
何か時代の流れを感じた。
  _
  /〜ヽ
 (。・-・) 。oO( 大安のOS瓜・・・?
 ゚し-J゚
784Be名無しさん:04/03/27 19:52
>>777
ラッキーセブンおめ

やっと当初予想されてたような開発ラッシュになってきたね
予想より半年〜1年くらい遅かったけど
やっぱり0.1.5でのユーザーアプリ解禁が転換期だろうね
シングルタスクでもいいからとりあえずユーザーアプリを解禁しろって人達は
このことを言ってたんじゃないかと思った
785Be名無しさん:04/03/28 00:47
まあZAKOSはほとんどネタなんだが。継続するつもりもあんまりない。
KONOXを生暖かく見守る路線で(ぉ
786Be名無しさん:04/03/28 01:02
Linux上で動くOSはMonaX? Monux?
787Be名無しさん:04/03/28 01:03
韓国向けにNidaX
788Be名無しさん:04/03/28 01:27
>>784
そりゃムリってモンだろ。
物には順序がある。
使い物にならないディスクアクセス、使い物にならないメモリ管理でユーザアプリを公開しても意味なしだったろう。
789Be名無しさん:04/03/28 12:20
>>788
そんなもんアプリ側で自前実装
それでカーネルに還元
これこそバザール
790Be名無しさん:04/03/28 12:23
>そんなもんアプリ側で自前実装
>それでカーネルに還元
実際、FATのコードでそうなった。
791Be名無しさん:04/03/28 12:28
>実際、FATのコードでそうなった。
NICでは現在進行形だね。

そもそも人に自分と同じことを要求しても無理ってもの。
カーネル共同開発者が云々って愚痴があったけど、
それぞれやりたい事が出来るようにするのがマネジメント。
今でもカーネル共同開発者はいないけど良い意味で盛り上がってる。
ま、終わりよければすべて良しってことで、この件はお開き。
792Be名無しさん:04/03/28 12:58
で、KONOX開発者は有望な人材なのか?
Lと比べても知識にかなり偏りがあるようだが…
793ひげぽん ◆Ngzcp/NZpA :04/03/28 13:57
>>777さん
笑いました。最近盛り上がってきていてモチベーションがあがってきました。

>>779さん
冗談かと思いますが(笑)
時期尚早だと思います。ドライバインターフェースがきちんと定まっていないので。

>>780さん
そうですね。
サルベージをしてくださった方に深く感謝いたします。

Monaに今までアプリ・サーバーを提供してくださった方々もしくはその予定がある方々に
アンケートご協力のお願いです。

次回リリースに向けて現状を把握したいので以下のURLでお答えいただけないでしょうか。

ttp://mona.sourceforge.jp/dynamic/pukiwiki/pukiwiki/pukiwiki.php?Mona%2F%A5%EA%A5%EA%A1%BC%A5%B9%A5%E1%A5%E2

お忙しいところ貴重なお時間を割いていただくことになりますがご協力のほどよろしくお願いいたします。
794Be名無しさん:04/03/28 14:26
>>780
ム板は壊滅したからな。ちょうど良い時期に移転したもんだと思った。
795Be名無しさん:04/03/28 14:44
Waba for Monaもう動作してるっぽ
おめーーーーーーーーー
796Be名無しさん:04/03/28 18:42
>>730
cltnがまさにそれを目指してVM+コンパイラを作ってんじゃ?
彼はMonaPJのメンバーだし、技術提携もありだべ。
797Be名無しさん:04/03/28 19:20
ヒゲタンも神々の仲間入りかな?
まだ天使レベル?
798Be名無しさん:04/03/28 20:11
>>797
もはや神だろうね。それを取り囲む人々が天使か。
そういやMASKも大天使長に出世してたな。
799Be名無しさん:04/03/29 00:19
わたすは哀れな乞食だす
知識クレクレ
800Be名無しさん:04/03/29 00:21
     ∧__∧
     (   ;)
      /  ヽ
     .と_と__)
    (; ・∀・)    ドキドキ
  oノ∧つ⊂)
  ( ( ;・∀・)
  ∪( ∪ ∪
    と__)__)
801Be名無しさん:04/03/29 02:18
>>800
キリ番ゲットおめ!
802Be名無しさん:04/03/29 05:06
>>791
お開きのところ悪いけどちょっとだけ。
さっきゅんのおれぺこでの手腕は鮮やかとしか言いようがない。
一気にユーザーアプリが動くまでに進化した感じ。
これは今までのOS作成で培った経験と、
Monaに対して言われたDOS遊びのニーズとを汲み取った結果か。
あとはCygwinで動くクロスコンパイラが出てくれば
開発者がどっと流れ込む予感。
803>>779名無しさん:04/03/29 19:46
>>793
まだドライバインターフェースが定まっていないとは……;
知りませんでした。
まあ定まり次第、各社に提供汁、って言いに逝きますんで。

定まったら皮切りに 最強のRoland製DTM音源、SC-8850の
ドライバを . __∧__  Rolandに提供汁、って言って
みます。   |(現時点で) |   まぁ、作ってくれるかは謎ですが。
          ̄ ̄ ̄ ̄ ̄
804Be名無しさん:04/03/29 23:29
宣伝隊の切り込み隊長さんでつか。
DTM音源ならシリアルドライバがあればとりあえず16トラック使えるんじゃなかったっけ?
806ひげぽん ◆Ngzcp/NZpA :04/03/30 22:47
>>795さん
そうですね。うれしいです。

>>803さん
> まだドライバインターフェースが定まっていないとは……;
> 知りませんでした。
> まあ定まり次第、各社に提供汁、って言いに逝きますんで。

そうですね。ドライバインターフェースを決めなければなりませんね。
言いに行ってくれるんですか?(笑)

>>805 さっきゅんの人さん
> DTM音源ならシリアルドライバがあればとりあえず16トラック使えるんじゃなかったっけ?

アドバイスありがとうございます。
自分の作ったOSから音が出たらうれしいでしょうねぇ。
807ひげぽん ◆Ngzcp/NZpA :04/03/31 00:22
今日の一言にも書きましたが方向性で悩み中です。
次回リリースの次に何に手を付けるのがベストか。

本当に最小・最低限の機能がそろってきたので
これからどちらに行くのがいいのか迷います。

ドライバインターフェースを決めるべきか。
サーバー群の整備か。
APIの整備か。
カーネルの洗練か。
カーネル新機能追加か。
1からリライトか。
64bitへ移行か。
808Be名無しさん:04/03/31 00:30
ひげちゃんが挫折したqemuのwin上ビルドに成功した人が
809ひげぽん ◆Ngzcp/NZpA :04/03/31 00:33
>>808さん
すばらしいですね。
Monaはうまく動きませんでした。(ログを吐いてすぐ終了してしまう)
Linux上での0.5.2ではVesa not surpportedまで動いているので
もう少し様子を見てみようかと思います。>Win版qemu
810Be名無しさん:04/03/31 00:36
おお、テスト乙。CD-ROMサポートとかもまだみたいだしOSのテスト用途には
まだ不適みたいっすね。今後が楽しみ
811ひげぽん ◆Ngzcp/NZpA :04/03/31 01:01
>>810さん
お疲れ様です。
どこかにレポートをあげた方がいいんでしょうか?
しばらく様子見が良いかな。

qemuとは別件ですが
mona-0.2.0alpha7をリリースしました。

・NIC/getmac.cpp→NIC/ne2k/getmac.cppディレクトリ変更
・strncpy2関数追加 by shadowさん
・Waba for Mona004を取り込みHello Worldが動作!! by baysideさん
・同期API Mutex追加
・ファイル書き込みAPI FileOutputStream追加
・inp/outp 8/16/32作成 outportb/inportbは統一のため名称変更


ダウンロードはこちらからお願いします。

ttp://mona.sourceforge.jp/dynamic/pukiwiki/pukiwiki/pukiwiki.php?Mona%2F%B3%AB%C8%AF%C8%C7
812Be名無しさん:04/03/31 02:38
コンパイルできねー

make[2]: Entering directory `/home/joe/src/mona_v1.0/src/user/HelloWorld'
g++ -nostdlib -fno-exceptions -fno-rtti -fno-builtin -Wall -c -g -O3 -I. -I../include -I../include/userlib -I../../share -c hello.cpp
hello.cpp: function 内の `int MonaMain(List<char*>*)':
hello.cpp:102: 警告: no return statement in function returning non-void
ld -n -Ttext 0xA0000000 -e _user_start -static -luser hello.o -L../lib -o ../../../bin/HELLO.ELF
ld: warning: cannot find entry symbol _user_start; defaulting to 00000000a0000000
hello.o(.text+0xd): In function `MonaMain':
/home/joe/src/mona_v1.0/src/user/HelloWorld/hello.cpp:49: undefined reference to `MemoryMap::getInstance()'
hello.o(.text+0x20):/home/joe/src/mona_v1.0/src/user/HelloWorld/hello.cpp:52: undefined reference to `MemoryMap::create(unsigned int)'
hello.o(.text+0x36):/home/joe/src/mona_v1.0/src/user/HelloWorld/hello.cpp:60: undefined reference to `MemoryMap::getSize(unsigned int) const'
…(中略)
hello.o(.text+0x1ed):/home/joe/src/mona_v1.0/src/user/HelloWorld/hello.cpp:57: undefined reference to `exit'
make[2]: *** [../../../bin/HELLO.ELF] エラー 1
make[2]: Leaving directory `/home/joe/src/mona_v1.0/src/user/HelloWorld'
make[1]: *** [hello] エラー 2
make[1]: Leaving directory `/home/joe/src/mona_v1.0/src/user'
make: *** [userapp] エラー 2

Debian sid
gcc 3.3.3
813Be名無しさん:04/03/31 10:44
16bit VESA希望
814Be名無しさん:04/03/31 13:24
ファイル列挙キボンヌ
DIRすら出来ない時点でおれぺこの勝ち
815Be名無しさん:04/03/31 13:43
DIR?
816Be名無しさん:04/03/31 13:46
コマンド名はlsでよろ
817Be名無しさん:04/03/31 13:53
DIRだったらシェルの内部コマンド、
lsだったらLS.ELFって別にした方が良いと思う。
っていうかDOSで.EXEが省略できるように、
.ELFもいちいち打たなくて良いようにした方がいいと思う。
818Be名無しさん:04/03/31 13:55
>>807
当面は必要に迫られたことだけやってたら良いと思う。
YAGNIってことで。
819ねり@偵察猫:04/03/31 14:18
>>817
|ー゚)φ メモメモ
820Be名無しさん:04/03/31 14:20
なんか変なのが来た!
821ねり@偵察猫:04/03/31 14:44
|彡 サッ
822Tino ◆sMrLqQHxo6 :04/03/31 18:07
>>770 >>773 >>774 >>777
ありがとうございます。

>>768 >>771 >>775
設定ファイルで切り替えられればVGAをサポートするのも面白いですね。
とんでもなく暇になったらリアルモードをいじってみたい気もします。

>>793
少しは休めるかと思ったのですが全然駄目でした。
MonaGUI-0.1の今日中のリリースは不可能となってしまい申し訳ありません。
このままずるずると先延ばしにするのは不本意ですので、
明日は仮病でサボってMonaGUIの開発に集中することにします。
アンケートなどは明日までお待ちください。
823 ◆CFYAAAAAds :04/03/31 21:14
とりあえずは仕事一段落で復活。
OPERAのタブに入れて毎日見てはいたんだが途中から変なページ飛ばされてそれっきりだったので
今ようやく過去ログ見終わったです。

でもその前に部屋掃除しないとPC取り出せない罠(氏
824 ◆CFYAAAAAds :04/03/31 21:48
MONA実行方法を読みつつbochs環境ととのえてみたけど
VESA not supported. sorry kernel stop.
と出て実行できない…

とりあえず必死こいて動作環境+開発環境ととのえてまつ。
825ひげぽん ◆Ngzcp/NZpA :04/03/31 22:04
>>824さん
もしよろしかったらどこかに対応版bochsをおきましょうか?
826ひげぽん ◆Ngzcp/NZpA :04/03/31 23:35
>>812さん

申し訳ありません。
現在こちらで環境がないため試せませんでしたが

libuser.aのリンクがうまくいっていないようです。

どなたかお分かりになる方がいましたらご指摘いただけると助かります。

>>813さん

ご要望ありがとうございます。
開発版リリースで16bit版も欲しいということでしょうか?

>>814さん

ご要望ありがとうございます。
次回リリースにおきましてFATFSでその機能が
実現されるかもしれませんのでしばしお待ちください。
827ひげぽん ◆Ngzcp/NZpA :04/03/31 23:35
>>817さん

ご要望ありがとうございます。
.ELF省略可能対応しました。
次回αリリースに盛り込まれます。

>>818さん
ありがとうございます。

とりあえずリクエストのあるものと
コンソールあたりを触ってみる予定です。

>>822 Tinoさん

お疲れ様です。大丈夫ですか・・・

> MonaGUI-0.1の今日中のリリースは不可能となってしまい申し訳ありません。
> このままずるずると先延ばしにするのは不本意ですので、
> 明日は仮病でサボってMonaGUIの開発に集中することにします。
> アンケートなどは明日までお待ちください。

了解いたしました。
くれぐれもご無理をなさらぬようにしてください。

>>824さん

お疲れ様です。
--enable-vbe?でビルドすると幸せになれます。>bochs
828 ◆CFYAAAAAds :04/04/01 00:19
スマソ、いろいろ割り込みがあったんでさっき以来すすんでおりませぬ。
実際問題環境整えても実機で動かしてみないとNICのテストって大変だろうなぁと思いつつ
今日のところは寝ます。(明日新人くるし遅刻できないし)

>>825
実はいまだにbochsまわりよくわかってないので、もしして頂けるならうれしいです。
829ひげぽん ◆Ngzcp/NZpA :04/04/01 00:30
>>828さん
Mona PJ Wikiの今日の一言にURLを張っておきました。
お手数ですがD/Lしたらお知らせください。
けします。
830Be名無しさん:04/04/01 03:02
>>824
286対応表明?
831830:04/04/01 03:02
アンカーずれたorz
832Be名無しさん:04/04/01 03:25
833Be名無しさん:04/04/01 10:09
VGABIOS-elpin-2.40はVESA非対応です。
834Be名無しさん:04/04/01 13:33
OS作ってどうするの?
835ねり:04/04/01 13:41
疑問に思ったら負けだよ
836Be名無しさん:04/04/01 15:08
>>834
それじゃマイクロソフト社に電話して、同じこと言ってください。
それか「XPがあるのに、なんでロングホーン作ってるの?」って。
837>>779:04/04/01 15:12
言い忘れたが・・・・・・
シリアルドライバで16トラック再生できてもSC-8850は
使いこなせない。だから、ドライバインターフェースが出来たら
ドライバ提供汁、って言いに逝くって言ってるんだ。

詳ιぃ情報は下から。
http://www.roland.co.jp/zoomup/9905_SC8850/index.html
838Be名無しさん:04/04/01 15:17
前にRTL8139の話が出てきていたけどさ、RealtekのWebページに、
RTL8139のサンプルプログラムがあったけどあれって役に立たないのかね。

という情報をおいていきます。
839Be名無しさん:04/04/01 15:23
つーかプロトコルスタックどうする気よ?
WindowsみたいにBSDからパクるしかないだろ

$ strings /cygdrive/c/WINDOWS/system32/ftp.exe
...
@(#) Copyright (c) 1983 The Regents of the University of California.
All rights reserved.

$ strings /cygdrive/c/WINDOWS/system32/nslookup.exe | grep Berkeley
@(#)nslookup.c 5.39 (Berkeley) 6/24/90
@(#)commands.l 5.13 (Berkeley) 7/24/90
@(#)debug.c 5.22 (Berkeley) 6/29/90
@(#)list.c 5.20 (Berkeley) 6/1/90
@(#)subr.c 5.22 (Berkeley) 8/3/90
@(#)skip.c 5.9 (Berkeley) 8/3/90
@(#)getinfo.c 5.22 (Berkeley) 6/1/90
@(#)send.c 5.17 (Berkeley) 6/29/90
840Be名無しさん:04/04/01 16:21
>>837
否定的なわけじゃないけど、企業に一個人用のOSにドライバ提供しる!って
言っても無駄なような希ガス。
841Be名無しさん:04/04/01 17:04
先の話になるかもしれませんが、音楽や画像などのフォーマットはライセンスフリーの
OGGやPNGなどにして欲しいと思っています。

どうでしょうか?
842Be名無しさん:04/04/01 17:21
それはアプリケーション次第では。
OS自体は特にファイル形式に依存する事は無いと思う。
それともOS標準の事かな(WindowsとWindowsMediaみたいな?)
843Be名無しさん:04/04/01 17:36
>>832
おお、それですーーーー
よく見付かったねーーーー
844841:04/04/01 17:45
>>842
はい。そうです。
OS標準搭載アプリケーションに対応して欲しいと思っています。
845Be名無しさん:04/04/01 17:50
その辺の話ってOSASKで2年くらい前に散々言い合ったやつだね
846Be名無しさん:04/04/01 17:59
そういうソフトを標準搭載するときになったら考えましょうや。
もっと別の形式が出てるかもしんないし。
847Be名無しさん:04/04/01 18:06
>>845
そうなんですか。知りませんでした
無知ですみませんでした

>>846
そうですね。
よりよいフォーマットが開発されるかもしれませんからね (^_^)

参考になりました。ありがとうございました
848841:04/04/01 18:10
>>847
これは私の書き込みです。
名前入れるの忘れてしまいました。 _| ̄|○
849Be名無しさん:04/04/01 19:32
>>840
お金積めば大概作ってくれます。
それなりの金額とドライバに関する仕様書も必要ですが。

まあ現実的な所で、「ドライバ書きたいので資料下さい」ですな。
850Be名無しさん:04/04/01 20:28
>>817
NWSOSのWikiにlsが掲載されたね
851 ◆CFYAAAAAds :04/04/01 23:28
>>829
ありがとうございます。
とりあえず慣れるまでいじってみます。
852ひげぽん ◆Ngzcp/NZpA :04/04/02 00:25
>>838さん
情報ありがとうございました。

>>839さん
プロトコルスッタクは勉強のために全部自分で自作される方と
移植される方がいるかと思いますがどちらもかまわないと思います。

>>841さん

画像フォーマットに関しましては846さんと同意見です。

>>851さん
おやくに立てて何よりです。
ファイルは消しておきました。

Linuxでのビルドエラーに対応しました。
次回開発リリースで反映されます。
Wikiでアドバイスを下さったななしさんありがとうございました。
853ひげぽん ◆Ngzcp/NZpA :04/04/02 00:57
mona-0.2.0alpha8をリリースしました

・JPEGDEMO外部ファイル読み込み対応 thx! nikqさん

 使い方 JPEGDEMO NEKO.JPG

・シェル:.ELFを省略可能にした。

・Makefile 修正 Linuxビルド対応 thx!ななしさん

・FDCのモータ制御のバグ修正

・File Output Stream appendモード追加 thx! Gakuさん
854Be名無しさん:04/04/02 01:16
そろそろMona上でもGOが動きそうだね。
エディタさえ揃えばセルフ開発出来るかも!?
855838:04/04/02 01:38
>>852
本当はそんな風に思っていないだろ(・∀・)
856Be名無しさん:04/04/02 01:51
>>855
裏と表がないと社会人は務まらないだろ(・∀・)
857Be名無しさん:04/04/02 02:02
前から気になってたんだけどTotalL Memoryってtypo?
858Be名無しさん:04/04/02 02:28
たるる
859Tino ◆sMrLqQHxo6 :04/04/02 03:33
今日一日頑張ったのですが、
新しい仕様の共有メモリがうまく使いこなせず挫折しました。_| ̄|○

リリースが遅れて申し訳ありません。
現状は、3月26日に出したスナップショットより後退してしまって、
まともに動かなくなってしまいました……。
860841 ◆iCl2ZebZN6 :04/04/02 04:41
>>852
了解しました。
ひげぽんタソ、開発に携わっている方々、 がんばってください
861Be名無しさん:04/04/02 04:59
>>859
イ`
862ひげぽん ◆Ngzcp/NZpA :04/04/02 20:17
>>854さん

動いたらうれしいですね。
確かにメジャーなアプリケーションとしてエディタが
あったら面白いと思います。Mona GUIでの実装になると思います。

>>838さん

そんなことないですよ。
RTL8139で実験されている方もいらっしゃるのでとても助かります。

>>857さん
ご指摘ありがとうございます。修正いたしました。

>>859 Tinoさん

ご指摘の件,MemoryMapクラスのコンストラクタが呼ばれていないため
発生いたしました。
取り急ぎ修正し、α9をリリースいたしました。
ご迷惑をおかけいたしました。

>>860さん
ありがとうございます。
863Tino ◆sMrLqQHxo6 :04/04/02 21:12
>>861
ありがとうございます。

>>862
ありがとうございます。
Wikiにも書きましたが、メンバをstaticにすると、
今回のようなAPI変更の影響を受けなくなります。
864Be名無しさん:04/04/02 21:26
>>863
Mona GUIへの期待がすごく高まっていて
大変だとは思うけど、是非続けていいものをつくってください。

Mona GUIの出来でMonaの今後が決まるといってもいいすぎではないと思うので
865Tino ◆sMrLqQHxo6 :04/04/02 21:35
>>864
ありがとうございます。頑張ります。
866Be名無しさん:04/04/02 22:16
Mona ネットワーク対応マダーーー
    __                            。   ___
   B■Λ  。                        \ B■∧
    (,,゚Д゚) /                          (^(´∀` )
━━ (|  つ ━━━━━━━━━━━━━━━━━━ ヽ    ) ━━━
  | ̄ ̄ ̄ ̄ ̄|                        | ̄ ̄ ̄ ̄ ̄|
  |        |                        |          |
867Be名無しさん:04/04/02 22:53
>>865
がんがー
868Be名無しさん:04/04/02 23:08
うーん、ドライバー作る以前に現在の割り込みまわりの作りこみ不足を何とかしないと、厳しいなぁ。
869ひげぽん ◆Ngzcp/NZpA :04/04/02 23:13
>>868さん
動的な登録とかでしょうか?
具体的に必要な機能を挙げていただけると助かります。

確かに割り込みまわりは初期からほとんどいじっていないので
まずいかもしれません。
870Be名無しさん:04/04/03 00:27
実機でマウスが動いてくれない・・・
871ひげぽん ◆Ngzcp/NZpA :04/04/03 00:44
>>870さん
実機確認ありがとうございます。
起動時にマウスのエラーコードが出ていますでしょうか?
872Be名無しさん:04/04/03 00:52
>>870
USBマウスだとダメだよ
873Be名無しさん:04/04/03 01:01
>>869
とりあえず、動的な割り込み処理は必須でしょうし、割り込み共有の処理も欲しいし、異常割り込みに対してのプロテクト処理も欲しいところですね。
まぁ、何はともあれ動的な制御と現在各割り込み処理内部で行われている8259に対しての処理の部分の分離、とか。

後は、spin lock周りの拡充もして欲しいところ。


もっと詳しい人の助言がほしいところだなぁ。私では畑違いなので助言をするには限界がある。
874gamix ◆WqDg2zGb9A :04/04/03 04:08
364でつ

>> 838さん
ありがとうございます。1つ目のNICでプロトコルスタックが動いたら
次にチャレンジする候補になると思います。
(サンプルコードを参考にする方が他のOSのドライバを参考にするより
 同じようなコードになった場合のライセンス関係が問題なさそうだからです。
 )

>>839さん 852 862 ひげぽんさん
Etherフレームの送受信が安定しはじめてからスタックについてはまた考えますが
勉強のために作りたいとはいえ、その前に構造を確認する意味で一度移植するのも
良いかも知れないと考え直しています。
具体的にはInterface誌2004年4月号の
組み込みTCP/IPプロトコル・スタックTINET
(BSDのスタックをマイコンとNE2Kにポーティング)などです。

>>866さん
マジレスすると、あなたの書き込みで久々に書き込むことになりました。
状況を報告しますと、Etherフレームの読み込みやってるところです。
一応、Etherフレームの読み書きまではできそうな感じがしてきていますが、
一般に言われるネットワーク対応というものにはかなりの隔たりがある、
素材や、資料的な意味合いのモノを作っているところです。
私の方は少しづつ進めばいいなと思っていますが、
他の方の実装にも期待です。

◆CFYAAAAAds さん
乙&おかえりなさいでつ。
こちらは期末より期首の方がどちらかというとキツイですね。
お互いがんばりましょう。
875Tino ◆sMrLqQHxo6 :04/04/03 07:28
>>867
ありがとうございます。

Monaに恋焦がれて幾星霜……
ようやく最初の到達点が見えてきました。

とか言いながら遅くなったり浮気したりしてて大袈裟ですが、
なんとか0.1.0RC1のリリースに漕ぎ着けました。
http://mona.sourceforge.jp/dynamic/pukiwiki/pukiwiki/pukiwiki.php?Tino%2FMonaGUI%2F-0.1

まだまだ機能的には全然足りないのですが、
とりあえずフィーチャーフリーズにしますので、
新機能追加は一旦停止して問題がないか様子を見たいと思います。
Wikiに書いてあるロードマップとのずれが生じていますが、
0.1.0リリース以降改めて調整させていただきたいと思います。
876Be名無しさん:04/04/03 11:11
だれと浮気したの

Hした?
877Be名無しさん:04/04/03 11:20
遅レススマソ
>>871

エラーは出ていません。
実機はnotePC(thinkpad 600)。
やはりPS/2のマウス以外は認識しないのでしょうか?
878877:04/04/03 11:21
追記:
肝心なことを書き忘れていました。
MonaOSのバージョンは0.2.0alpha10です。
879Be名無しさん:04/04/03 11:26
               --- カラアゲを作ろう ---
880Be名無しさん:04/04/03 12:57
gamixタソおつかれ。

Mona GUIがだいぶ形になってきたので移植がんがー
881S.R. ◆CFYAAAAAds :04/04/03 13:49
適当なコテハンをつけてみるテスト。
土日作業と行きたいところだけど別件でイベント企画してため作業できませぬ。

>gamixさん
Interface2004年4月号にも情報があるのですね。
ちょっと立ち読みしてみたいと思います。
とりあえずはトラ技2001年1月号を元に私は作ってみます。

#先にコンパイル環境を(氏
882Be名無しさん:04/04/03 14:59
国産OSだからPC-98で動作きぼん
883Be名無しさん:04/04/03 15:01
osaskとかメグナントカは98で動くよん。
884Be名無しさん:04/04/03 15:16
Mona Ver2.0.0alpha6を
実機で確認したところ、
Mouse init error=8が出て
マウスが正常に動作しません。

やっぱり、AT時代のPS/2よりでっかいコネクタに
マウス刺しているから駄目?
error 8
歴史の重みに耐え切れません

解説
歴史のあまりの重さにmonaが悲鳴を上げています。
肩の荷を降ろしてあげてください。
886Be名無しさん:04/04/03 15:59
ワロタ
887Tino ◆sMrLqQHxo6 :04/04/03 16:03
>>876
おれぺこです。
相手が人間じゃないのでHは無理です。
888Be名無しさん:04/04/03 16:08
ダッチタンでもHは可n
889Be名無しさん:04/04/03 16:08
>>887
Hな動画欲しい?
石原さとみ風。(名前あってる?)

4MBある。
890Be名無しさん:04/04/03 16:09
>>889
  ま た お 前 か !
891Tino ◆sMrLqQHxo6 :04/04/03 16:20
>>889
もうエロビデオって歳じゃないです。
エロくなくても美人を見てるほうが幸せです。
892877:04/04/03 16:24
デスクトップの方でα10動かしたら
Mouse init error=8
と出ました。
マウスはPS/2接続なんですが、光学式です(あまり関係ないか?)。
同じ症状の方が居るようですが何か共通点でもあるのでしょうか?

893Be名無しさん:04/04/03 16:34
Mouse init error 8

>>ひげぽん
カーネルのソース見たけどKBCからのデータが複数バイトで来るときに、IN(0x64)&0x1==0x1のチェックは
始めの1バイトの前だけでいいんだよ。2バイト目以降はチェックしない。
894Be名無しさん:04/04/03 16:48
>>888
メグタソだったら萌え〜できたのにね
895ひげぽん ◆Ngzcp/NZpA :04/04/03 20:03
>>873さん
ありがとうございました。
次回メジャーリリースには間に合わないかもしれませんが
必ず対応させていただきます。

>>874 gamixさん
移植の件楽しみです。
是非がんばってください。

>>875 Tinoさん
RC1リリースおめでとうございます。
早速いくつも質問してしまいすいませんでした。

>>877さん 884さん
ご報告ありがとうございます。
マウス周りではまだいろいろと問題がありそうなので
改善させていただきます。(USBは厳しいかもしれませんが)

>>893さん
ありがとうございます!!
試してみます。m(__)m
896Be名無しさん:04/04/03 20:25
Tinoタンおつかれ。

Mona GUIの使い方が分かるようなサンプルがあるといいな。
初心者向けのはラベル・ボタンがあったので分かるが
中級者・上級者向けのサンプルがあるといいと思った。

例えばゲームとか本格的なアプリとか。
あと将来実装予定は含めず現在のMona GUIでできることできない事が
評価何かでまとまっていると分かりやすいかな。

走すれば質問しなくてもある程度判断できると思うので。
897ひげぽん ◆Ngzcp/NZpA :04/04/03 20:31
>>893さん
> カーネルのソース見たけどKBCからのデータが複数バイトで来るときに、IN(0x64)&0x1==0x1のチェックは
> 始めの1バイトの前だけでいいんだよ。2バイト目以降はチェックしない。

上記はihandlers.cppのMouseHandler()でのデータ受信のことでしょうか?
それともtest_higepon.cppのint Mouse::init()のことでしょうか?
898Be名無しさん:04/04/03 22:13
実機での動作報告(α10)

キーボードが反応してくれなくてコマンドが打ち込めない。
キーボードはPS/2接続日本語 109キーです。
899893:04/04/03 23:06
>>897
test_higepon.cppのことです。
900Tino ◆sMrLqQHxo6 :04/04/03 23:25
>>896
ご意見ありがとうございます。

> Mona GUIの使い方が分かるようなサンプルがあるといいな。
はい、まったく同感です。
もともと↓に書きましたようにサンプルを豊富に揃えるつもりでしたが、
http://mona.sourceforge.jp/dynamic/pukiwiki/pukiwiki/pukiwiki.php?Tino%2FMonaGUI
>> サンプルがリファレンス代わりになるくらい充実させないと、まずいかなあ
ここ最近あまりに忙しくてMonaGUI自体の開発すら滞ってしまったため、
止むを得ずリリースを先にすることにした次第です。

> 例えばゲームとか本格的なアプリとか。
はい、同感です。
まだMonaGUIでは本格的なものを作れるほど成熟していませんが、
このくらいのものなら作れるという目安を示すと言う意味で、
電卓やマインスイーパなら今のMonaGUIでも作れそうなので、
時間があったら取り組みたいとは思っていました。

> あと将来実装予定は含めず現在のMona GUIでできることできない事が
> 評価何かでまとまっていると分かりやすいかな。
なるほど、出来ることをまとめるという発想はありませんでした。
もっとも出来ないことが多すぎて将来の話になっているのが現状です。
とりあえず将来実装予定になっていることは、
今のMonaGUIでは出来ないことを意味しています。(泣)
901896:04/04/03 23:31
サンプルがあれば、きっといろいろとアプリが登場すると思うので
がんばってください。
  _
  /〜ヽ
 (。・-・) 。oO( さんぷるぷるぷるぷりんぷりん♪
 ゚し-J゚
903Be名無しさん:04/04/03 23:53
Mona GUIすげーな。
jpeg表示も出来るのか

これは一種の祭りでしょ。
次のMonaのリリースまでにどれだけアプリをそろえるかが鍵とみた。
904Be名無しさん:04/04/04 00:44
久々に来てみたらすごいことになってますね。
これほどのものを作れる人たちを本当に尊敬します。

ソースを見て理解できればもっと楽しいんだろうなあ。
905Be名無しさん:04/04/04 09:39
そうそう、リリースの際にはSourceForgeでプロジェクトのニュースも出すと良いよ。
運が良ければSF.jpのトップでも取り上げてくれるし。
906893:04/04/04 12:36
最低限のマウス有効化は
byte data;
outp8(0x64, 0x20);
if (waitReadable()) {
return 3;
}
data = inp8(0x60);

outp8(0x64, 0x60);
if (waitWritable()) {
return 4;
}

outp8(0x60, data & (~0x30) | 0x3);
if (!waitReadable()) {
inp8(0x60);
}

outp8(0x64, 0xd4);
if (waitWritable()) {
return 10;
}
outp8(0x60, 0xf4);
if (!waitReadable()) {
inp8(0x60);
}
だけあれば有効になる。
907ひげぽん ◆Ngzcp/NZpA :04/04/04 13:11
>>898さん
ご報告ありがとうございます。
後述のマウス認識問題が片付きましたら取り組ませていただきます。
動作報告等ご協力いただければ幸いです。

>>893さん
ご親切にありがとうございます。
ちょうどマウス初期化見直しをしていたときなので大変助かりました。
893さんのコードをそのまま流用したところ手持ちの実機・エミューレータで
動作したのでα11リリースに含めさせていただきました。

>>904さん
ありがとうございます。
ソースですが大半がC++で書かれています。
少しずつ読んでいけば理解できるかもしれません。

>>905さん
> そうそう、リリースの際にはSourceForgeでプロジェクトのニュースも出すと良いよ。
> 運が良ければSF.jpのトップでも取り上げてくれるし。

ありがとうございます。リリース時の作業として追加いたしました。
このあいだのスラッシュドットでの投稿でアクセスが急増した経験もありますので
リリース時にはプロジェクトニュースを出して見ます。

α11をリリースしました

mona-0.2.0alpha11
・Randomクラス追加:乱数生成
・マウス初期化見直し thx 893さん

マウスが認識されてない問題をご報告いただいていた方は
お手数ですが改善されているかご確認・ご報告いただけると助かります。
908Be名無しさん:04/04/04 17:51
           \γ⌒ヽ
             \γ⌒ヽ
               \γ⌒ヽ
                \γ⌒ヽ
                  \γ⌒ヽ
                   \γ⌒ヽ
                     \γ⌒ヽ
                      \γ⌒ヽ
                        \,,_⊂゙⌒゙、∩
                         \⊂(。Д。)gamixタン、S.R.タン
                           \ ∨∨ Monaから2chへの書き込み実現して!
                            \
                              \
                               \

909877=898:04/04/04 18:04
>>907
乙カレー

α11動作報告
マウス動きました(Thinkpad600&自作機)
そして、キーボードも反応しました。
対応有難うございます。
910ひげぽん ◆Ngzcp/NZpA :04/04/04 18:08
早速のご確認ありがとうございました。
キーボードも反応したようで一石二鳥ですね!

すべて893さんのおかげです。
ありがとうございました。
911Be名無しさん:04/04/04 20:04
久々に見にいってみたらム板のつくろうスレが死んでるから終了したのかと思ったらOS板でやってたのね・・・
今後もがんばってください
912Be名無しさん:04/04/04 20:24
Mona GUIのサンプルアプリケーション

マ━(゚∀゚)━( ゚∀)━( ゚)━( )━(゚ )━(∀゚ )━(゚∀゚)━ダ????
913Tino ◆sMrLqQHxo6 :04/04/04 21:13
>>912
すみませんが、RC2で大幅な改造をすることになったので、
ちょっとサンプルにまで手が出ない状態です。
914Be名無しさん:04/04/04 21:15
>大幅な改造

キター
915Tino ◆sMrLqQHxo6 :04/04/04 21:19
>>914
改造と言っても機能拡張は大したことなくて、
http://mona.sourceforge.jp/dynamic/pukiwiki/pukiwiki/pukiwiki.php?Tino%2FMonaGUI%2F-0.1
Mona全体のソース大整理に合わせる部分が結構手間がかかりそうです。
http://mona.sourceforge.jp/dynamic/pukiwiki/pukiwiki/pukiwiki.php?%B5%C4%CF%C0%2F%A5%BD%A1%BC%A5%B9%A5%C4%A5%EA%A1%BC
916Be名無しさん:04/04/05 22:17
このスレWeekdayは休業か。
仕事ガンガってください
917Be名無しさん:04/04/05 22:27
平日は他スレに浮気
587 名前:Tino ◆sMrLqQHxo6 投稿日:04/04/05 22:07
>>586
キタ━━━━(゚∀゚)━━━━ッ!!
918ひげぽん ◆Ngzcp/NZpA :04/04/05 22:30
浮気
キタ━━━━ヽ('∀`)ノ━━━━!!!!

今日はソースツリー整理中です。
Mona GUIサンプルがんばってみます。
919Be名無しさん:04/04/05 22:50
>>917
ウホッ
920Tino ◆sMrLqQHxo6 :04/04/05 22:51
>>917
AMD64ってすっごく期待してて新しいマシンを買うのを控えてたんですよ。
そしたらAthlon64がリリースされてもWindowsのリリースが延期されてしまって
最近UN*X関連を使わないから買う気がなくなってしまって、
結局ケチってAthlonXP 2400+で新調してしまいました。
そんなときにおれぺこを見て凄いなあって素直に感心してしまいまして、
経済的に実機が買えなくても何か近付ける方法はないかな、と思ったもので。
昔UN*X関係をちょこっといじってた知識が役に立った感じです。

個人的にはLinuxよりFreeBSD、CygwinよりInterixの方が好きです。
単純に個人的な趣味なので別に優位性を主張する気はないですが。
ldがELFを扱えないようでMonaがInterixでコンパイルできないのが辛い所です。

>>918
お疲れ様です。
多分今晩中に終わらないと思いますが私の方もRC2の実装頑張ります。
921Be名無しさん:04/04/05 22:55
言い訳するTinoタンかわいいw




冗談です。がんがってください
|ー゚) ソォーッ
923Tino ◆sMrLqQHxo6 :04/04/05 23:00
>>921
ありがとうございます。
Tinoさんのおかげで開発がずっと楽になって大助かりです。
Windowsで手軽に開発できる64bitOSになっちゃいました(*`-`)σ)'∀`)
925Tino ◆sMrLqQHxo6 :04/04/05 23:07
>>924
それは何よりです。
926TAKA:04/04/05 23:27
MonaをビルドしてBochsで実行したのですが、
VESA not supported. sorry Kernel Stop
と言われてしまいます。皆さんの話を聞く限り実行できているようですが
どうしてでしょうか?
Bochsのバージョンは2.1.1でちゃんとVGA-BIOS-elpin2.40も入っています。

それはさておき、Monaを解析して疑問点が2つほど出てきたのですが

まず一つ目はsecondboot.asmの最後。
cstart.cppにジャンプするコードで jmp 0x200になっていますが
なぜこれできちんとした位置にジャンプできるのかわかりません。
jmpに即値を与えると相対ジャンプになるので前々から何でこれで
うまくいくんだろうと思います。

二つ目がMemoryManager.cppのallocateの部分。この関数はメモリ領域の
リストをたどって、求めるサイズと同じかそれ以上のメモリ領域を探しています。
このとき、見つかったメモリ領域が求めるサイズより大きければ分割することに
なりますが、サイズの比較が current->size と realSizeになっています。
current->sizeには実際に確保された(求められた)サイズが保存されているので
関数の引数で与えられた size と比較するのが正しいのではと思います。

というか、解析しているうちに新しいバージョンが出ちゃったんだよなー・・・
また初めから見ていかなきゃ・・・
927Be名無しさん:04/04/05 23:49
928Zakky ◆54q7Px4hDk :04/04/05 23:51
えと。alpha11でマウス動作しました。
929ひげぽん ◆Ngzcp/NZpA :04/04/06 00:25
>>920さん
お疲れ様です。
Monaももう少ししたら64bit移行するかもしれません。
下調べとマシンの調達が完了すればですが。

> 多分今晩中に終わらないと思いますが私の方もRC2の実装頑張ります。

よろしくお願いいたします。

>>926さん
bochsでMonaを実行するためには以下の条件が必要です。

・--enable-vbeオプションでbochsをビルドする(cygwinなどで)
・VESAに対応したVGABIOS-lgpl-latestを使う

> jmpに即値を与えると相対ジャンプになるので前々から何でこれで
> うまくいくんだろうと思います。

Monaのブートは・・・
忘れました。すいません。
アセンブラは苦手です(いいのか・・・)

> current->sizeには実際に確保された(求められた)サイズが保存されているので
> 関数の引数で与えられた size と比較するのが正しいのではと思います。

うろ覚えですが
current->sizeにはヘッダサイズが含まれていない仕様だった
思います。

>Zakkyさん
ご確認ありがとうございました。
Z-Slashいつもチェックしています。
930TAKA(926):04/04/06 11:36
>>929
>>926 のMemoryManagerですが一晩ぐっすり寝て考えてみました。
やっぱりcurrent->size と realSizeの比較で正しいです。

例えば、current->size = 1024 で求めるメモリ領域が1022のとき、
>>926 で言ったようにcurrent->size と 求められた大きさで比較すると
current->size の方が大きくなり、メモリブロックの分割をしなければなりません。
ところでこの場合は初めの1022バイトをとってしまうと、2バイトしか残らず
メモリブロックのヘッダーを書き込むことが出来ません。
このようなわけで realSize と比較することが正しいということになります。
こういうところはきちんと考えなければいけませんね。

ところで、PageManager.cppでページテーブルの領域を確保するとき
実際に必要なページテーブルの大きさの2倍の領域を確保していますね。
4キロバイトのアライメントにあわせるのが目的だと思いますが、
実際に必要な領域 + 4キロバイトで十分だと思います。
931ひげぽん ◆Ngzcp/NZpA :04/04/06 22:03
>>930さん
> 実際に必要なページテーブルの大きさの2倍の領域を確保していますね。
> 4キロバイトのアライメントにあわせるのが目的だと思いますが、
>実際に必要な領域 + 4キロバイトで十分だと思います

こんばんは。
実際に必要な領域が4KBなので 4 * 2 = 8KBになっています。

本来であればメモリをビットマップなどで別管理して
メモリを無駄に使わないという実装が望ましいと思いますが
まだ手を付けていません。
932ひげぽん ◆Ngzcp/NZpA :04/04/06 22:04
最近の作業内容として挙げていました、ソースツリーの変更にですが
Tinoさん, shadowさんのご協力で本日完了しました。

お気づきの点がありましたらご指摘いただければ幸いです。
明日いっぱい様子を見て特に何も無ければCVS importで
新しいツリーとして開発を再開いたします。

■主な変更点
・./configure -> make -> make installの手順になった
・/APP, /SERVER ディレクトリがそれぞれ /APPS, /SERVERSディレクトリに変更になりました。
     影響を受けるwabaのソースは修正済みです。
・userlib.h, libuser.aがそれぞれ monapi.h, libmonapi.aと名前が変更になりました。
・monapi.hをincludeする際は using namespace MonAPI;の記述が必要。
   MonaGUIみたいに名前が被るので意図的にusing namespaceを避ける場合は
   すべてのクラスの前にMonAPI::を前置して使う。【例】 MonAPI::System::getThreadID()

■ソースツリー変更の経緯と変更点詳細

 ttp://mona.sourceforge.jp/dynamic/pukiwiki/pukiwiki/pukiwiki.php?%B5%C4%CF%C0%2F%A5%BD%A1%BC%A5%B9%A5%C4%A5%EA%A1%BC

■新ソースツリー(仮)のダウンロード

 ttp://mona.sourceforge.jp/dynamic/pukiwiki/pukiwiki/pukiwiki.php?plugin=attach&openfile=MonaTree10For0.2.0beta1.tar.bz2&refer=%B5%C4%CF%C0%2F%A5%BD%A1%BC%A5%B9%A5%C4%A5%EA%A1%BC
 340KB
933Be名無しさん:04/04/06 23:36
>>932
ひげぽんをはじめ開発者の方々
お疲れ様です

いつの日かMonaMagazineが販売されたらなと思ってみる。
934ひげぽん ◆Ngzcp/NZpA :04/04/07 00:32
>>933さん
こんばんは、お疲れ様です。

> いつの日かMonaMagazineが販売されたらなと思ってみる。

あー。3秒くらい妄想しました。
夢のまた夢ですががんばります。
935Be名無しさん:04/04/07 08:32
つまらない質問で申し訳ありません
http://mona.sourceforge.jp/MonaShell.html
に従いMonaを起動してみました。
使用したversionも http://mona.sourceforge.jp/Mona.img です。
すると boot して「(.o'v'o)」の様な表示がひたすら表示される
(ユーザはなにもできない)
ようですがこれで正しいのでしょうか?

あと、Mona は VMWare 3.x では動作しない あるいは
動作確認が されていないということでよろしいのでしょうか?
VMWare 3.1.1 で実行したところ
mona loading とは表示されましたが,
http://mona.sourceforge.jp/MonaShell.html
の猫(?)は表されず, ひたすら「0212 2200 ...」と表示されます.
(もし必要なら, 上記の数字を全て載せますが)

あと, 全然 関係ありませんが ひげぽんさんがんばってください
応援しています:)
936Zakky ◆54q7Px4hDk :04/04/07 09:35
>>935
そのバージョンでは恐らく正常な動作だと思います。

最新のリリース版は0.1.5で、
https://sourceforge.jp/projects/mona/files/
からダウンロードできます。
937Be名無しさん:04/04/07 13:16
ひげぽん始めみんながんがれ〜〜

開発が進むと凄いハァハァしてま

将来、市販されてるマシンにMONAがプリインストールされることを願って応援してま♪
938935:04/04/07 17:14
>>936
ありがとうございました
0.1.5 で動かしてみました。
mona.bochs は ver.up しなくていいのですよね?

boachs と VMWare 3.1.1 とも
"VESA not supported. sorry kernel stop." と表示されました。

(止まってしまいますが) boot しているようですね。
939Be名無しさん:04/04/07 18:43
>>935
>VESA not supported. sorry kernel stop

ガイシュツ
このスレで2回は質問されている。
940Be名無しさん:04/04/07 19:28
bochsが動かないと言ってる人が多過ぎだけど
情報が古いのと混ざって交錯してて分かりにくいってのもあるか

ここでまとめといた方が良さそうだねage

bochsは自分でコンパイルせずに↓を使う
http://prdownloads.sourceforge.net/bochs/bochs-2.1.1.win32-bin.zip?download
これを展開してC:\Program Files\bochs-2.1.1に入れておく

Monaの楽々bochs起動ファイルを取ってくる
http://mona.sourceforge.jp/dynamic/pukiwiki/pukiwiki/pukiwiki.php?cmd=read&page=Mona%2FBochs%C0%DF%C4%EA

どこでも好きなところに展開して、その中にmona.imgを入れる
mona.imgは好きなバージョンをぶち込めば良い
最新のMonaを使いたい人は↓のmona.imgを使う
http://mona.sourceforge.jp/dynamic/pukiwiki/pukiwiki/pukiwiki.php?Mona%2F%B3%AB%C8%AF%C8%C7

それであとはstart.batをクリックすればbochsでMonaが動く
ただシェルにdirが実装されてないから何が出来るか分からないのが問題
その辺何とかしてホスィ
941ひげぽん ◆Ngzcp/NZpA :04/04/07 23:59
>>935さん
ありがとうございます。

>>Zakkyさん
フォローありがとうございました。

>>937さん
応援ありがとうございます。

>>939さん
>>940さん

フォローありがとうございます。
940さんの手順でMonaが起動できることを当方でも確認しました。

> ただシェルにdirが実装されてないから何が出来るか分からないのが問題
> その辺何とかしてホスィ

入れ違いになってしまいました。実装いたしましたのでお試しください。
942ひげぽん ◆Ngzcp/NZpA :04/04/08 00:00


βリリースのお知らせです。
0.2.0beta1をリリースしました。
変更点は以下の通りです。

・ソースツリーの大幅な変更
  Tinoさん、shadowさんありがとうございました。
・シェル内部コマンド DIR/LS/CDを追加

・Random.nextDouble()を追加。

なお0.2.0beta1ではWABA.ELFが正常に動作しません。
Monaカーネル側の問題と思われます。
現在調査中ですの今しばらくお待ちください。

ダウンロードは↓からどうぞ
ttp://mona.sourceforge.jp/dynamic/pukiwiki/pukiwiki/pukiwiki.php?Mona%2F%B3%AB%C8%AF%C8%C7
943750:04/04/08 03:49
いまだに忙しくて、Monaを動かす暇がない...。
944Be名無しさん:04/04/08 05:50
                    , -=- -─‐-、  
                   _ ´-─ ¬く  ̄  ̄ミ- 、
                ,,,,/    _==-ミァ-─‐-、 \''''''''''''ー--、,,,,,_
            _,,,,-''"/  , ‐''"         \ \、_,,,ー''ゞ" `ゞ、
            -' "  /  /     /   |      \ ヽ     /"`
       _,,-''''''"""''''' / /  /   / /    ||  |  i  ヽ i    /
       ´"''、.    i /  / /  / / /    ||  ||  |│ |ノス  /
          '、   |//  / /___, -一ァ|  /! |ト、|│ | | く」/
            '、  |,-‐¬  ---┘'7 |!  ハ! |,、-┼十|!/\/\
          , -‐ ''"  し' '´_ /,ィ二l |ト、/!ヽト、\_ヽ!|!l\:..  /
       ,r/      __   ,イ|リ ヾハ! ヽ!  ,ィ⌒ヾミリノ/:::... \
      / ||ヽ  -'     / ̄ )` __      |ヒノ:} '` ,;\/\/
    ,r '   ヾ、  ,-、____ , イ ̄,r==-      ==-'  レ' /|  |
  / ヽ    `ーソ  ' | |ト、,ヘ ′""          "" / / || |
. /    \_  /  | ハ ヽ`゙'ヘ       ' '     / / | |  |  <がんばってくださいな
           /   / / |  ヽ 川\      0     //! |  | |  |
        /    / / 八  \川| |`ト- .. __ , イ‐ァヘ |  | ||  |!
      /    / / /  \  \ 「`ー- 、    /  .〉  ト、|  ヽ、
     ,イ    /-─=¬ニヘ、_  \   厂\ 厂ヽ /!|   | `ー=ヘ
 -‐  ̄ /─ '  ̄     ├- ヽ\  \ノ\ \ 人 ハ!ヽ ||  |-┤ ヽ
      /          /!‐-- | |\   ト、_`ヽ oヽ  ト、!  ||  |‐┤- ヽ
  // 〉      __ /  ├‐-  ||  | 川-‐  | |  厂7! ハ!  ├:┤  ̄ヽ
  / / ー ─    ̄       ├‐- リ  || ハ!ヘ   | |  ト┤|/′ ヾ,┤   ゙i_
  ‐ '              〉‐-    | / /\ .|o | /ヽ/(′    ∨     \
945935:04/04/08 19:57
>>940
ありがとうございます
無事 shell までこぎ着けました。
猫のJPG も表示されて良い感じでした
946ひげぽん ◆Ngzcp/NZpA :04/04/08 21:03
http://www.volny.cz/xnavara/qemu.zip

上のqemuでMonaが起動しました。VESAもうまく行っているようです。
ただ起動後のサーバー読み込み・起動で止まってしまうので
FDCあたりで躓いているようです。(詳しくは調べてないです。)

qemuの最新版では動いたりするのでしょうか?
947Be名無しさん:04/04/08 21:18
QEMUのCVS版で0.2.0beta1を試してみましたが、Mona loading...で止まります。
何故かFilip氏版(>>946のもの)でも手元の環境では止まりました。
948Be名無しさん:04/04/08 21:20
あ、すいません。HDDとしてmona.imgを読ませていたのが問題だったようです。Filip氏版、CVS双方で
loading /SERVERS/KEYBDMNG.SVR....OK
までいけました。
949ひげぽん ◆Ngzcp/NZpA :04/04/08 21:23
>>947さん
ありがとうございます。
シェルに入力等できましたでしょうか?
950Be名無しさん:04/04/08 21:26
ダメでした。今のところQEMUのWin32版はFDを読めればいーなー、というぐらいの実装具合のようなので
更新待ちですね。というかひげ氏ついでにお願いします。
951ひげぽん ◆Ngzcp/NZpA :04/04/08 21:29
>>950
ありがとうございます。
手持ちのqemuでもう一度実行したところ...OKとサーバーの読み込みが
成功しているのでFDCはうまく動いているかもしれません。

Monaの問題かもしれないのでちょっと調べて見ます。
ダメだったらすぐあきらめます。
952Be名無しさん:04/04/08 21:33
>>951
ちょっと確認なんですが、起動
> qemu.exe -L . -m 32 --fda mona.img
でいいんですよね? mona.imgのアーカイブはSFからつい先ほど落としてきたものです。
953ひげぽん ◆Ngzcp/NZpA :04/04/08 21:36
こちらは↓でやっています。

qemu.exe -L . --fda mona.img
954947:04/04/08 21:52
やはり結果は変わりませんでした。
ひとまず、最新CVS版のQEMUバイナリを手近なところにUPしました(UPしてからosdevに付ければよかったと思った)。
http://reactos-j.sourceforge.jp/up/img/017.zip
>>946のFilip氏版で加えられたのと同じ修正(キーボード関連、BIOS?)とHALTによるCPU節約が実装されているので
平常時の負荷がかなり下がっているようです。
955ひげぽん ◆Ngzcp/NZpA :04/04/08 22:07
>>947さん
バイナリありがとうございます。

qemuである程度動作するようになりました。
とあるタイミングでタイマ割り込みがマスクされてしまうようでしたので
とりあえずカーネルを修正しておきました。(CVS最新版)

ただマウスの初期化に失敗しているようで
マウス割り込みがずれてしまい、マウスが使えないです。
このあたりどなたかフォローいただけると助かります。

それにしてもqemuは速いですね!
956Be名無しさん:04/04/09 01:05
Monaでネットワーク機能はどこまでいっているの?
もしかしてMACアドレス取得までは追えてたんだけど。

次回リリースでパケットの送受信できたりするとうれしい。
957gamix ◆WqDg2zGb9A :04/04/09 01:20
>>956さん
ありがとうございます。
 
パケットの受信を実装中です。(割り込みなしでポーリング版)
リリース時期によるかもしれません。
送信は…おって報告します。
958S.R. ◆CFYAAAAAds :04/04/09 01:23
スマソ、漏れの方は去年度の仕事片付けで何も手ついてないです。
土日にようやく時間が取れるので成果物ができればいいなぁと思いまつ。

と、qemuとかまた知らない単語でてきてるーよ…
959gamix ◆WqDg2zGb9A :04/04/09 01:31
>>958 S.R.さん
乙でつ
それそれ今年度以前に昨年度の仕事ですね。頭痛い。
こちらもあんまり時間が取れず、一日数行づつ書き足して言ってる状態です。

qemuはOS板qemuスレによるとBochsより5倍ぐらい速いエミュレータです。
Bochsのような箱丸ごとだけではなく
IA32のコードをLinux上のユーザモードで実行したりして、Wineと一緒に使えば
PPCなLinuxでもWindows、IA32のバイナリが…とかそういう使いかたもできます。
(逆にARMエミュレーションとかもできるはず)
どちらかというと箱丸ごとよりもCPUに重点が置かれ、JIT的な動作らしいですね。

それはそうと、ここではqemuがWindows上でも動き始めたので話題になってるのですが、
NICについてはまだWin32上では未実装のようなので私は気にしていません。
960Be名無しさん:04/04/09 02:18
おお、QEMU本当に早いですねぇ。
QEMU ROSのF神版という奴と、最新Mona Kernelの組み合わせでブートしてみたんですが、
Bochsとは次元の違う速さ!
まぢで良いですねぇ。

あと、VesaConsole::VesaScreen::scrollUpですがコピーする場合比較して、同じだったら
コピーしないほうが1.5倍くらい早いですよ。

とか、どうでも良いようなことを書いて逃げてみる。
961gamix ◆WqDg2zGb9A :04/04/09 02:39
>>958 959 960さん
QEMU使って見ました。確かに速いですね。

気になったのでQEMUのhw/pc.cを見ると
static uint32_t ne2000_io[NE2000_NB_MAX] = { 0x300, 0x320, 0x340, 0x360, 0x280, 0x380 };
static int ne2000_irq[NE2000_NB_MAX] = { 9, 10, 11, 3, 4, 5 };
とありましたのでIOアドレスGETMAC側でIOアドレスを0x280にして
>>953 ひげぽんさん
を参考にして
qemu -L . --fda mona.img --macaddr AA:BB:CC:DD:EE:FF
として、GETMAC.ELF起動すると
すごい負荷がかかってQEMUのプロセスが応答無しになりました。
以上報告でした。
962Be名無しさん:04/04/09 16:30
QEMU対応版のイメージどこ
963Be名無しさん:04/04/09 20:14
>>926さん
> jmpに即値を与えると相対ジャンプになるので前々から何でこれで
> うまくいくんだろうと思います。
記述は絶対値ですがコンパイルされると相対値になります。
964ひげぽん ◆Ngzcp/NZpA :04/04/09 22:01
>>957さん
パケット受信楽しみです。

>>960さん
VesaConsoleご指摘の点改善してみました。
ありがとうございます。

>>961さん
なるほど。qemuって他OSではネットワーク通っているんでしょうか?

>>962さん
リリースしました。

>>963さん
フォローありがとうございます。
965ひげぽん ◆Ngzcp/NZpA :04/04/09 22:03
βリリースのお知らせです。
0.2.0beta2をリリースしました。
変更点は以下の通りです。

・qemu対応 マウスはnikqさんパッチを取り込み
・スレッドダンプのシステムコール作成
・Mona GUIでPSコマンド作成
・スクロールちょっぴり高速化 thx! 名無しさん

ダウンロードは↓からどうぞ
ttp://mona.sourceforge.jp/dynamic/pukiwiki/pukiwiki/pukiwiki.php?Mona%2F%B3%AB%C8%AF%C8%C7
966Be名無しさん:04/04/09 22:05
ウェ━━━━━(OwO)━━━━━イ!!!
967Be名無しさん:04/04/09 23:00
キタ━━━━ヽ(`エ´*)ノ━━━━!!!!

PSかっこいい Mona GUIすごいね
968Be名無しさん:04/04/09 23:13
Mona GUIきれいだねー。デザインがイイ

NOIZ2BG.ELFとか。GUI版移植したらNWSOSのfireみたいでかっこいいかも
969Be名無しさん:04/04/10 01:31
IDE周りで妄想したこと書き込んでも良いですか?
970Be名無しさん:04/04/10 01:34
板違いですのでお帰りください
971Be名無しさん:04/04/10 01:39
いや、Monaの設計上の話なんだが。
972Be名無しさん:04/04/10 01:45
ここはOS板です
妄想を語り合う板ではありません
お引取り願いします
973Be名無しさん:04/04/10 01:49
>>1
のテンプレをパワーアップして

次スレを立てて。(プロバイダ規制中)
974Be名無しさん:04/04/10 01:53
975Be名無しさん:04/04/10 02:04
>>974
それちがう。
976Be名無しさん:04/04/10 03:10
977Be名無しさん:04/04/10 03:12
埋め
978Be名無しさん:04/04/10 03:13
.埋め
979Be名無しさん:04/04/10 03:15
980Be名無しさん:04/04/10 03:16
981Be名無しさん:04/04/10 03:19
結局どのスレにするのよ。
982Be名無しさん:04/04/10 03:19
あと残り18ですよ
983Be名無しさん:04/04/10 03:20
じっれったいなぁもう
984Be名無しさん:04/04/10 03:24
    ひげぽん ◇Ngzcp/NZpA

こいつ誰だったの?
985Be名無しさん:04/04/10 03:26
986Be名無しさん:04/04/10 03:29
子供を作ろうが(悲
987Be名無しさん:04/04/10 03:34
(´∇`)ヒゲポソ ◇2HImExsoWc

こいつも謎だった
988Be名無しさん:04/04/10 03:37
振り返ってみるとみんないい想い出だ
989Be名無しさん:04/04/10 03:40
産め
990Be名無しさん:04/04/10 03:41
  産め産め
991Be名無しさん:04/04/10 03:41
生め
992Be名無しさん:04/04/10 03:42
生め産め
993Be名無しさん:04/04/10 03:43
宇目
994Be名無しさん:04/04/10 03:43
うめ
995Be名無しさん:04/04/10 03:44
生め
996Be名無しさん:04/04/10 03:44
産め
997Be名無しさん:04/04/10 03:45
ひげぽん ◆Ngzcp/NZpA = (´∇`)ヒゲポソ ◇2HImExsoWc = ひげぽん ◇Ngzcp/NZpA

だったのか?
998Be名無しさん:04/04/10 03:46
全ては闇の中へ。。。
999Be名無しさん:04/04/10 03:47
もう残りわずか
1000鳥取砂丘 ◆Dream/3P/. :04/04/10 03:57
(´・ω・`)
10011001
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。