OSASKｽｯﾄﾞﾚ Part4

OSASKスレPart4ですが何か。

OSASK: http://www.imasy.or.jp/~kawai/osask/
川合さんからのレス: http://www.imasy.or.jp/~kawai/osask/comment.html

過去ログ
Part1: http://pc.2ch.net/os/kako/989/989544577.html
Part2: http://pc.2ch.net/os/kako/1021/10211/1021123643.html
Part3: http://pc.2ch.net/test/read.cgi/os/1031404041/l50

参考スレ
【第三勢力】和製OSここにあり！【超ﾏｲﾅｰ】
http://pc.2ch.net/test/read.cgi/os/1039237412/l50

・「川合さんからのレス」って？
ちょっぴりシャイな川合さんはあまり2chには出てこずに
自分のサイトにレスを書き残しています。
たまに見ないと話についていけなくなるかも。

・IPAに援助されてるってことは国民のｹﾂ税（略
http://www.ipa.go.jp/でも見てﾏﾀｰﾘしる。

・川合の言ってることは＃＠☆△◇■！
Q&A・開発方針・新規に作りはじめた理由・意見と回答・ぼやきの「よくある誤解」
ぐらい読んでおいてもバチはあたりません。

>>1さんｻﾝｸｽ！

938 ：川合の次の一手は？ ：03/01/17 14:19
(Q)まさか僕がOSASK開発で生計を立てようとしているように見えますか？
(Q)まさか僕がOSASK開発で生計を立てようとしているように見えますか？
(Q)まさか僕がOSASK開発で生計を立てようとしているように見えますか？

(A)今はOSASK開発で生計が立っているといえるでしょう。
(A)今はOSASK開発で生計が立っているといえるでしょう。
(A)今はOSASK開発で生計が立っているといえるでしょう。

とりあえず小学生並みの読解力を自慢されても困るぞ。＞4

4 ：Be名無しさん ：03/01/17 23:06
938 ：川合の次の一手は？ ：03/01/17 14:19
(Q)まさか僕がOSASK開発で生計を立てようとしているように見えますか？
(Q)まさか僕がOSASK開発で生計を立てようとしているように見えますか？
(Q)まさか僕がOSASK開発で生計を立てようとしているように見えますか？

(A)今はOSASK開発で生計が立っているといえるでしょう。
(A)今はOSASK開発で生計が立っているといえるでしょう。
(A)今はOSASK開発で生計が立っているといえるでしょう。



5 ：Be名無しさん ：03/01/17 23:18
とりあえず小学生並みの読解力を自慢されても困るぞ。＞4


1 KB [ ２ちゃんねるも使っている完全帯域保証専用サーバ Big-Server.com ] 30,000円/月
--------------------------------------------------------------------------------

新着レスの表示

とりあえず小学生並みの読解力を自慢されても困るぞ。＞4
とりあえず小学生並みの読解力を自慢されても困るぞ。＞4
とりあえず小学生並みの読解力を自慢されても困るぞ。＞4

(Q)まさか僕がOSASK開発で生計を立てようとしているように見えますか？
(A)今はOSASK開発で生計が立っているといえるでしょう。

↑さすがの川合さんも、ノーリアクションですね。

>>8
きのう、うちんとこの研究室でも、Ｋがその王手をどうかわすか？で
みんなで予想してた。当たった人は松屋牛丼なんだが。

>9
すげーな。一度その研究室見てみたい。アホ面が並んでるんだろうな。
まあ「王手」だと思ってるのが>9だけだったりしそうだが。

>8
レスが欲しいならOSASK掲示板にでも書いてくれば？

いくら王手で完全に詰んでいても、反論して自分ひとりだけ「切り抜けたつもり」
になるに一票。

なんでIPA未踏の金で生計立てちゃいけないの？
もともとあれはそういう企画だろ

Kﾀﾝ、前スレの

888 ：Be名無しさん ：03/01/11 22:38
そろそろ、ちょっと一言のページを分けてほしいな。

ってやつ、漏れもｷﾎﾞﾝﾇ

あらためて声を大にして言う事でもないが、状況を飲み込めない
世間知らずの人が滞在しているようなので書いとこう。

Ｋ氏がOSASKで未踏ユースに応募して資金を得た事は、今後社会的に
見て大きなアドバンテージになり得るよ。

>>14
　超漢字及びその他のTRONも、日本の「公式なOS」なのだが、自由競争
の元ではそういう名目は役に立たない事が証明済み。

>>14
漏れ、過去の未踏採択者なんだけどさ。
採択されるとメリットは無くはない。漏れの人生も少しは変わった。しかし、社会的に大きなアドバンテージになるほど、IPA未踏が高い認知度を持っているとは感じないな。
世間の認識は、他の文科経産系の助成と大きく違わないし、そういった助成で作られているOSなんてのはゴマンとある。

旅っ中！よりはマシだぜ

>>16
コメントどうも。
１６の内容程度の認識でも、かなり有効だと思うよ。

>>18
　社会的「認識」が高いことよりも、「使い物になるかどうか」
とか「特徴」の方がずっと普及には重要じゃないの？

　Linux は、最初「社会的」に認知されていなくても、
どんどん成長していったが、そういう「自分の力」で発展して
いったものは後々強い。現在でも水面下でどんどん力を増しているし。

　逆に、援助や助成などといったもので仕立てようとしても、失敗
する例は数多し。

>>19 の意見を全否定するものではないが。
この場が存在するまでには、
DARPAを始めとする各種の助成があった
ってことも忘れてはいかんと思うな。
「自分の力」と「助成」は両方必要ってこった。

(Q)まさか僕がOSASK開発で生計を立てようとしているように見えますか？
(A)今はOSASK開発で生計が立っているといえるでしょう。

なんでIPA未踏の金で生計立てちゃいけないの？
もともとあれはそういう企画だろ

↑ってか、問題になってるのは、Ｋのイイワケの娯楽性だろ？

＞きのう、うちんとこの研究室でも、Ｋがその王手をどうかわすか？で
＞みんなで予想してた。当たった人は松屋牛丼なんだが。
川合って答えにくい質問に対しては何気にシカトしてスキップし、
他の簡単な質問に文字数を多く割いて煙に巻く政治家タイプなんで
そうやってかわすと思うよ。当たったら牛丼、俺におごれ（ぉぃ

結局金貰ってんだからって趣味には参加されないんだよ。
まぁ、中にはいるんだろうけどさ。

仮にOSASKに対して、例えば全体の1/3の貢献度を果たした場合、
IPAから支給される1/3のお金は貰えるのかな？もちろん、Ｋ氏もその
貢献度を認めたうえで。

24は不自由な日本語のインターネットですね。姦酷の方ですか？

> 　きっと何か誤解されていると思います。 888さんの書き込みのとき、「ちょっと一言」のページ
> は140KBほどあり、確かにわけるべきだと思ったので僕は分けました。今はその結果として「ち
> ょっと一言」のページは50KBほどです。だから今すぐにまた分けるつもりはありません。 13さん
> は、どういう風に分けてほしいのでしょうか？

そうだったの・・・？Σ（´д｀；）
いつもチェックしてたけど気付かなかったYO!

ちょっと別話だけど、いつになってもいいんで、
現行スレのコメントをページの上の方に置てもらえるといいな・・・。
そうしとけば下の方がロード中でも大丈夫だし・・・

>>25
開発者としてもらうのは無理だから、
もらった後山分けになるだろうね。

(Q)まさか僕がOSASK開発で生計を立てようとしているように見えますか？
(A)今はOSASK開発で生計が立っているといえるでしょう。

Mr.K
>この方針を曲げなければお金をくれないというなら、僕はもらいません。
>今回は僕がやりたいこととIPAがやってほしいことが一致したから採択されたのであって、
>僕の方針が変わったわけではありません。
>今回は僕がやりたいこととIPAがやってほしいことが
>一致したから採択されたのであって、僕の方針が変わったわけではありません。

IPA officialpage:
http://www.ipa.go.jp/NBP/14nendo/14youth/gaiyou/02-005.htm
>採択理由
>テーマ申請自体はレガシーハードで動かそうというやたらと
>後向きの計画だったが、前向きの計画に変更してもらった。

>「しようとする」と「している」は違うということは分かっておられますか？
つまり、当分しばらくは「趣味」ではなく「生計」であるということですな>>OSASK

マジで、ここにいる香具師はみんな学生？
少なくとも公的な機関に一応でも認められたという客観的な事実が
どれだけ社会にとって信用に値するか知らないのだろうか…。

どんだけすごいものでも他人に認められないと普通の人からは
見向きもされないぞ。特にお堅い企業なんかはね。

逆に認められてもそれがいいものとは限らないのも成り立つので、
ここで頑張らないと見放されるね。確実に。
Ｌたんもそろそろ引きこもって荒らしなんてしてないで創造的なことしたら？

>>32
OSASKがお堅い企業や普通の人から認められる「危険性」があるからこそ、
徹底的に真実をさらけ出さねばならない。

>>33
だから、公的機関に認められても失敗してる例がいっぱいあるって書いてあるだろ。
19とか嫁。実力がないのなら認めれてもすぐに失敗するって。

だいたい、真実をさらけ出すとかいって29みたいな書き込みをｱﾌｫみたいに
繰り返すことが前向きなこととは到底思えないけどな（ｗ

>>34
>実力がないのなら認めれてもすぐに失敗するって。
　結局最後は失敗するなら、バブル的に投資されるのを
未然に防ぐ事も重要じゃない？

　予想がはずれてその結果どうしようもなくなったのが、不良債権
で、未だに片付いてないんだから。日本は評価や査定がいいかげん
過ぎるからこうなった。今でも変わってない。

だから、喪前らみたいな社会的に認められてない香具師らがこんな所で
いくら騒いでも見向きもしないって。何か問題あると思うなら自分の
立場を明確にした上で問題点を論理的に指摘してちゃんとIPAにメール出せ。
それをここに報告すればいいだろ。

だいたい、クソの役にもたたないような研究が死ぬほど金になったりする事例が
いくつあると思ってんだ？　悪いがこんな所で鼻息荒くしてる喪前がそれを
判断できるとは到底思えないぞ。

ベンチャーは基本的に数打ちゃ当たる方式。
そういう海とも山とも付かぬ研究に金を出すベンチャーキャピタル市場が
アメリカでどれだけの規模あるのか分かって無い奴なんていくらなんでも
いないよな。あんだけマスコミで騒いだ後だしな。

free software isn't written without money.

三百万がそんなに妬ましいでつか？

>>38
結局ここで騒いでるヤシらは所詮そんなもんだろ。
あとはＫに個人的に恨みのあるＬとか。

Mr.K
>この方針を曲げなければお金をくれないというなら、僕はもらいません。
>今回は僕がやりたいこととIPAがやってほしいことが一致したから採択されたのであって、
>僕の方針が変わったわけではありません。
>今回は僕がやりたいこととIPAがやってほしいことが
>一致したから採択されたのであって、僕の方針が変わったわけではありません。

IPA officialpage:
http://www.ipa.go.jp/NBP/14nendo/14youth/gaiyou/02-005.htm
>採択理由
>テーマ申請自体はレガシーハードで動かそうというやたらと
>後向きの計画だったが、前向きの計画に変更してもらった。

↑ＩＰＡに選択されるために方針を変えることなど、微塵もないといいつつ
Ｋはレガシーハードで動かそうという重要な案件を、変更してしまったんだろ？
ＩＰＡ的にはそれで問題ないかもしれないけど、Ｋの言動的には問題あるだろ？

税金だのカネだの妬みが問題になってるのではなく、
Ｋがカネを調達するために、ＯＳＡＳＫの重要方針の一つを折ってまで
ＩＰＡに適応したことが問題。

>40
貴公、失礼ながら企業等の然るべき組織内でプレゼンされた経験はお有りかな？
まあないであろうと思うから訊くわけだが。

それにこれはせいぜい短期の達成目標の提示であり、運動の大方針の提示ではなかろうが。
まあＫのことだからPC98のなんちゃらをサポートします、などといういかにもマズーな
プレゼンを打ち、それではあんまりだからプロジェクト自体の質的な進展に繋がる目標を
出し直させられたというところではないのか。
これは衷心から思うんだが、IPAというのは随分懐が深いな。

K氏はいちいちこの掲示版にレスつけないでもっと開発の方に力を注いだ方が
よいのではと思ったりもするのだが。久しぶりに2chのosaskスレ見てみたがどうも
なぁ・・・。
何時の間にかIPAから支援されてたりするし。この機会を掲示版へのレスで潰す
事もないと思うが。私にとってosaskを興味深いと感じた事はosを作るには何か
必要でどういった流れで開発をしていくのかと言う事が少し理解できた事。
分野が違うのでosに関する事柄は良く知らないがそういった立場で見て面白いと
思った。比較的小さいし。ただ標準的なCのライブラリが無かった頃なので
ちょっとした時間を使ってアプリを作るには大変だったが今は改善されたのかな。
OS作りをある意味疑似体験できた点が面白かった。
・・・いづれは商業ベースに載せることを考えておいた方が良い。というかその考え
方が必要だと思う。それは別にosaskや方針の悪口を言っているのではなくて、
何て言うのかな、ある程度のモノを作ろうとした時に何を作にしても必要な考え方だと
思うよ。趣味で僕が必要な物を作るんだっていうことも分かるけれども、何て
いうのかな、それだと難しい判断を迫られる時が来るかもしれない。
研究者や技術屋っぽいのかな。悪い事じゃないけれどProjectとしてスタートした
ならProjectを成功させる責任があるんじゃないかな。勿論明確に意識するしない
にせよ、「僕のもの」っていう考えを持つのはどうかな。
プロジェクトとして多くの人が参加すると言う時点で多分共有している価値観みた
いな物になるんじゃないかな。そうした時自ら開発するのではなく誰かに任せる
とかいう度胸もないと。
そうした時に何が目的でadvantageは何かって事を再考したりね。

結論は、やはりＫ氏の判断は正しいということか…

>>40
明らかに無知な書き込みを連続してると、自分のバカっぷりをさらけ出す
だけだからやめとけば？　何がそんなに気に入らないのか知らないけど。
さすがに反論のための反論は意味がない上、間違ってると痛々しいよ。

>>43
いや、それは言い過ぎかと（ｗ

結局、ねたみうらみ程度でしか昇華出来ないんだもんなぁ。
日本人がプロジェクトやると、足引っ張る奴ばかりだと言ったのは
確か坂村翁の言葉だったっけな。

OSASK 3.2 ソース (src32, make32) age
流し読みされたい方は例によっていつものところへどうぞ。
ttp://minix-up.sourceforge.jp/cgi-bin/l.cgi/l/os/osask/

公開しているCVSリポジトリからcheckoutし、特定のタグで
ビルドに成功された方がいらしたらそれをお知らせ下さい。
（私はOSASKの開発環境を揃えておりませんので）
ttp://minix-up.sourceforge.jp/CVSlab/

文字コードは全てEUC/LFになっています。

>確か坂村翁の言葉だったっけな。
あの無能な学者の負け犬セリフを引用するのもどうかと。

>47
少なくとも47より優秀だから可。

>>そのかわり徹底してその価値観を貫きます。
>>自分が使うことを第一に考え、妥協しないで設計・開発しています。
具体的にはどのようなアプリが動くことを想定したOSの設計・開発価値観ですか？

>あの無能な学者の負け犬セリフを引用するのもどうかと。

いまじゃ学者は卒業して、営業マンののような仕事ばっかしてる
けどな(W

関係者の1/3に支持され、1/3にこき下ろされ、1/3に無視されれば
そのプロジェクトは成功してるらしいが、
OSASKはそういう基準ではまあまあうまくいってるのかな？
スレ的にはOSASK特有の話題があんまりないのがつらいけど。

>>35
で、その危険性を判断して未然に潰すかどうかを判断するのが
神であるあなたなのですね？（ｗ
そうだ！世の中にはバカしかいない！
選ばれた人々が管理してやらなければならないのだ！

とりあえず、他のOSでは実現不能なOSASKならではの「特徴」ってなに？
川合さんは新規性なんて二の次、自分が欲しいと思ってるOSがないから作ってる、
と述べてる。
でも、これって、他のOSにはない特徴をOSASKで実現することの裏返し。

効率といっても、現状、サイズ合戦でもWindowsに負けてるとのことですし、
で、あればOSASKならではの特徴はなに？と問いたくなるのも自然です。

>OSASKならではの「特徴」

＜後ろ頭＞y-~~~ 486機+CFで軽快に動き、古いマシンが活用できる。
・・・とはいえ、Pentium133MHzクラスのマシンが1万円で買える時代。

>＜後ろ頭＞y-~~~ 486機+CFで軽快に動き、古いマシンが活用できる。
>・・・とはいえ、Pentium133MHzクラスのマシンが1万円で買える時代。

値段っていうか、ファンレスCPUの携帯機上で走らせることに意味があるかと。
であれば、PalmだとかWinCEがあるしなー。
Palmの場合、メモリ保護機能がないのでアプリがタコだと平気で落ちる。
候補としてWinCEか？WORDもEXCELもとりあえずサクサク動く。

となると、Ｋﾀﾝが求めてるものってなに？

Ｋは「自分の望んでるＯＳがない！」と言えるほど他のＯＳをきちんと吟味してるのかなー？
linuxは? RT-linuxは？ BSDは？ tronは？ solarisは？ Palmは？ WinCEは？ itronは？ BeOSは？

ひょっとしたら、上記OSの中に「こ、これだ！自分があったらいいと思ったOSは！」というのが
あるかもしれないし、仮になかったとしても、OSASK設計の基本方針に好影響を与えるのでは？

自分の欲しいOSを作る = 他のOSにはない特徴のOSを作る

自然に上のようなイコールが成立すると思われ
で、Ｋ氏のいう「他にはない自分の欲しいモノ」とはなにか？
はボクも知りたい。
Ｋ氏の主張に「軽快さ」が一つとして挙げられてるけど、それは例えば
RT-LINUXやPalmでは満たされないのか？など。

PC-9821の256色モード関係の資料。
http://www2.muroran-it.ac.jp/circle/mpc/old/pc98dos/256mode/256mode.html

OSASKは、NESエミュとかを入れてアピールするべきだと思う。
そうすれば手伝ってくれる人も増えるんじゃないかな？

>>45
MONAOSでは、開発者は日本人だけどこんなに批判されてないよ。
http://pc3.2ch.net/test/read.cgi/tech/1042375466/

なぜOSASKが、足を引っ張られるように、批判が多いかって言うと
全部エミュレートで実現するって、ものすごい事言っているわりには
全然OSがバージョンアップしない、出来ている個所も、まだすべてえせ状態。

Windows上のソフトをエミュレートなって、今の開発スピードでは
あと10年経っても無理なんじゃない、だからもっと速くOSASKを作り上げて
速く実現出来るようにした方がいいよって言っても。

もうしばらくお待ちくださいね、今、
大まかな仕様をどうするか考えているところなので
近いうちに発表しますので、みなさん、良い意見があったら聞かせてくださいね。
とは絶対にいわず。

今のOSASKが嫌なら、どうぞ自分で作ってくださいよ。
私は私自身のために、このOSを作ってるんです、
IPAにだって、私が行ってプレゼンして認められて、資金をいただいたのです。
あなたの意見なんて、聞けるわけがないじゃないですか、
OSASKは機能は少ないけど、低スペックでも速度が速く動くように作ってるんです。
だから、機能が欲しいなら、今あるOSか自分で作ってくださいと、
言ちゃうからでしょう。

>>59
たったそれだけですぐに逆ギレするのは議論に慣れてない日本人だけ。

>>60
#59に書いてあることは、自分の見解とも一致してる。

本質は議論の慣れ不慣れと関係なく、「言ってる事が まっすぐ かどうか」
の問題だと思う。

>>61
意味不明。Kはまっすぐというなら何処までもまっすぐな気がするぞ。
無意味に馴れ合っているよりは、できる奴が好きなだけいじって良いという
スタンスが漏れは結構お気に入り。

Kの思考の大部分はよくわからんが、ここだけは共感。

>59
なんか双方の意見がかなり実際と異なってるような気もするが、まあいいや。
つまり自分の意見が通らないからダダをこねて誹謗してるということか？
それほど自分の意見にそんなに自信があるのならまさに自分で作れと。

つーか、受け入れられない提案に
なあなあで答えるよりはっきり拒絶した方がいいと思うが。
「えせを今すぐやめろ！」とか言われて「前向きに検討します」みたく答えて
意見を流すのはけっきょく同じ事。ファンの層が少々変わるだけ。
ヘタな意見を受け入れて妥協の産物を作るのはもっての他だろうしね。
納得のできる意見が取り入れられてることはOSASK-ML見てれば確かだし。


煽りがでるのはそれが妬みや自己中で動いてるからじゃなくて、
単に見解の相違というヤシでないか？
量的にもOSASK-川合さんは正常範囲に収まってると思われ。

>>63
　しかし、#59の内容に、「受け入れる」「受け入れない」で差は
出ないと思われ。

　指摘に対する返答がYes/Noのいずれであっても、受け答えが
まずくなければ、余り批判されない。変な返答が多いから叩かれる。

>64
変な返答って？
それなりに納得できる返答をしてると思うが。
まあそれで納得できる連中は初めから納得してるだろうし、
納得できない連中はほとんど納得できないだろうとは思うけど。
だから説得力が弱いという気はする。そういうこと？

不満をうまくそらすことができない、あるいは
そういった発言の本質を今一つ捉えていないという意味なら同意。
「開発スピードをageろ」というのは本質的には「開発スピードが遅い」という不満
であって、それに対して例えば状況をアナウンスすることで不満を和らげるべきだ
ということなら確かにそういうことはあると思う。
かと言って完全にこなすのも非常に難しいことだろうが。
（ある程度まではやれてると思う。少なくとも漏れには真似できない）

返答といえば・・・OSASKの大きな特徴としてたサイズのコンパクトさが
Windowsに負けているという現状に対するＫさんのレスポンスはまだですか？

>>64
Kの返答のどこが変なのかマジで分からないので、具体例を挙げてくれ。

確かに厨の感情を逆なでするような表現をたまに見掛けるが、
内容がおかしいことは無いと思うんだが。

>68
もうずいぶん前に出てますが、何か？
っていうかhello worldの時点で.comには負けてるんだが。

>>66
「コンパクトさがWindowsに負けている」と言っている奴に確認したいんだが、
それはWinの256Bプログラムのことを言っているんだよな？
で、その話が出たときにKが「移植すると2,3倍になる」とか言っていた
そのあたりの事に基づいてる主張と言うことで良いんだな？
実際にまだ勝負したわけではないんだよな？
Helloworldやらを除いては。

>>実際にまだ勝負したわけではないんだよな？
一応、勝負するまでもなく理論的にもOSASKだとWindowsの2〜3倍になる。
*.comのあのコンパクトさを保つためには、
豊富なモードを揃えているSVGA-RAMのx86リアルモードエミュを
OS側で実装せねばならない。パレット設定APIを用意するだとかでは手遅れで
I/O命令をエミュるくらいの気合がないと、WindowsのDOSエミュにはサイズ面
で勝てない。

WindowsのDOSエミュの魅力は
物理的に8BitColorまでしかないハードウェアでも、32BitColorのSVGA設定を
要求する *.com が減色されるものの GDI の機構でそれなりにエミュされて動作する」
という点らしい。同じ環境で、MS-DOSで実行すると、当然だが要求時にエラーコードが
返却されて終了。

>>67
具体例は、59にも出てる。

「速く開発した方がいい」というのは、暗に「開発力が遅い」ことを指摘
するのが本意であるのに対し、「早く作るのは僕の方針に合わない」みたい
なのが「変」だということ。早く作って損なわけはあるまいて。

話者A：
「Windows上のソフトをエミュレートなんて、今の開発スピードでは
あと10年経っても無理なんじゃない、だから（できる証拠を示すためにも）
もっと速くOSASKを作り上げて速く実現出来るようにした方がいいよ」

K氏:
「今のOSASKが嫌なら、どうぞ自分で作ってくださいよ。私は私自身のために、
このOSを作ってるんです。」

後の文章が前の文章に対する「正常な受け答え」になってるでしょうか？

>>72

　　　　　　必　　死　　だ　　な　。

ふうむ。漏れにはその間の槍鳥が脳内補完されてしまうのだが（ｗ
たしかに始まりと終わりがそういうやりとりになることはあった。
でもそれはまるで「おはよう」に対して「さようなら」と返した、と怒ってるような気もするぞ。
具体例というより実際例を挙げてほすぃ。
そうじゃない例なら例えば前スレ>567の
> しかも作るのが遅いんだよ。
に対して
> 作るのが遅いというのは、全面的におっしゃる通りです。
というレスがあった。

つーか、それだけのやりとりでもそんなには間違えてないかと。
「開発力が遅い」とだけ指摘されてもどうしようもない。
自分の開発方法を公開して黙らせるか何かアイディアを出させてもいいと思うけどね。
まあそんなありがたい言い方で来るようなヤシに何を言ってもムダだろう、
と考えても不思議じゃないが。

新たなライバルが、満を持して公開されました。

関連スレ
http://pc.2ch.net/test/read.cgi/os/1043054172/l50
記事
http://biztech.nikkeibp.co.jp/wcs/leaf/CID/onair/biztech/comp/226861
ホームページ
http://www.ssspc.org/ssspc/index-j.html

>70
もっとレスがほしいなら、invader.comを作ればいいんじゃないか？

>>68 爆

>>75

かなり前から既出ですが何か？

なあ、一つ聞いていいか？
.comってWindows用のプログラムなのか？　漏れはてっきりMS-DOSの実行ファイル
だと思っていたわけだが。

MS-DOSの実行ファイルって.EXEだろ？

でもって、バインドアドレスを103決めうちにして、ヘッダ除去された
実行形式版が.COMファイルだろう・・・。

つまり生バイナリーがCOM。どちらともMS-DOSの実行形式ファイル。

オフセット0x100番地ね・・

COMはCP/Mの実行形式だハゲども

正直、芸が細かくて漏れ好み。＞82

>.comってWindows用のプログラムなのか？　漏れはてっきりMS-DOSの実行ファイル
>だと思っていたわけだが。
前出のように、Win32APIを叩くことができるし、生DOSでは動作しない
プログラムもWin上だと動いたりするので、もはや名実ともにMS-DOSフォーマットとは
言いがたいかと。なによりも、MS-DOSじゃ動かんし。
ヒネクレ言葉遊びとは違うと思われ

>>70
いや、「勝負してないからまだ勝ち負けは分からない」と言いたいん
じゃないくて、予想に基づく意見なんだということを確認したかった
だけなので、そんなに力説しなくて良いよ。

で、そうするとcom形式では640KBの壁だかのために歯が立たないような
中規模、大規模なプログラムではOSASKの実行ファイルの方が小さくなるだろう
と「予想」できるから、「中規模、大規模ならサイズ競争は Windowsの負け」
といえると思うんだがどうだ？

この予想は確かにまだ判断材料が少なすぎるが、helloworldなり
invaderなりで、OSASKの実行ファイルとWinの(comでない)実行ファイルを
比べれば悪くない見積りだと思うんだが。

>>72
いたって正常だと思うんですが。
これの、どこが異常ですか？
煽りじゃなくて真面目に質問しています。

>中規模、大規模なプログラムではOSASKの実行ファイルの方が小さくなるだろう
>と「予想」できるから、「中規模、大規模ならサイズ競争は Windowsの負け」
それもどうかなー。Windowsだと豊富なDLLが用意されてるから、かなり大規模な
ソフト作っても本体そのものは200kb前後に収まるんだよね。
例えば、シェアウェアレベルのGUIメーラーだとか、GUIスケジューラーだとか。

というか、実行サイズの軽量化って結局、複数アプリで使用されがちな共有一般
コンポーネントを、OS提供者がどれだけ豊富に提供できるか？にかかってると思う。
で、これは15年前のWindows3.0前夜にマイクロソフトが必死になって努力していたってわけ。

最大公約数的な共有ライブラリコードを提供することで、複数アプリが使いまわせば
使いまわすほど、全体としては効率的になるんだし。

実行ファイルのコンパクトさの追求なんて、シングルタスクOSならともかく
マルチタスクOSにおいては、あまりにも近視眼的評価と言えるのではないだろうか？

加えて、サイズ合戦したければ、WindowsにはCOMだとかDOS-EXEだとかの
選択肢「も」あるんだし。grepだとか、自分はいまだに自作DOSアプリ毎日使ってるよ。

>>87
OS自体の肥大化も防いで、さらに実行ファイルもコンパクトであれば
それはそれで意味あるんじゃないか？　KはPCでもPDAでも組み込み？でも
同じOS使えれば便利みたいなこと書いてなかったっけ。

OSASKも16bitの実行形式をサポートすればいい線行くかもしれないが、
今更意味があるんだろうか(;´Д`)

>87
> コンポーネントを、OS提供者がどれだけ豊富に提供できるか？にかかってると思う。
それだけじゃない、と言う話じゃないか？
最大公約数はある程度とうぜんだとして、
もっと効率のよくなるAPIを探求しようとしてるんだと思うが。
つーか、OSASKはどんどんバージョンアップできるんだし、
勝つために勝負してるんだから、負けてたら何か対応を考えるでしょ。

>>89
あなたは、非常に高い確率でＫ氏と断定できる。

>>勝つために勝負してるんだから、負けてたら何か対応を考えるでしょ。
「負けてないから対応を考えてない」といいたいのだろうが、
あなたは単に、自分の都合のいいように、
「負けていないと思い込んでしまう性格」
なだけじゃないかと思えてしまうのは俺だけか。

「探し物とくとくページ」
ごめんなさい。みんなに見て欲しいので投稿させて下さい。
【健康・美容】
http://momolin.fc2web.com/007kenko.biyo-01.htm
今度、うちで出している商品がTVに出る事になりました
1月25日(土)日本ＴＶ あさ天サタデー 知っ得のコーナー
1月27日(月)毎日放送　あさやん
詳しくはこちらから
http://momolin.fc2web.com/007kenko.biyo-01.htm
【健康・美容】関連の商品です

女性の悩み　結婚・出会い・ダイエット・シミ・そばかす・バスト・日頃の悩みなども掲載
・噂のコスメ無料サンプル送付中 らくらく簡単ダイエット決定版 無理なガマンにさようなら
・便秘でお悩みの女性限定　美容情報 女性必見　応募者全員無料体験　ご招待
・１日１本で若返り、赤ちゃんのプリプリ肌に いつでもナチュラルな若々しさと健康的な美しさを保つためのノウハウが満載
・薄毛・抜毛・多毛にお悩みの方にもご覧下さい

唾液でわかる排卵期チェッカー　赤ちゃんが欲しい人　必見 !
『妊娠レッスン-赤ちゃんが欲しいすべてのカップルへ』をプレゼント

本格カウンセリングサービス　一人で悩んでいませんか?
あなたのココロを強力サポート　「ココロノマド」をご利用ください

表記のURLで開き難い時は
[yahoo] [infoseek] [google]の検索サイトにて「探し物　とくとく」「探し物　ダイエット」「探し物　健康」「探し物　美容」で検索
タイトル「探し物とくとくページ」をクリックしてね　きっと、あなたの欲しいもの見つかるはず
【WEB電子商取引関連】
http://momolin.fc2web.com/001web.denshi-01.htm
【コンピュータ・家電】
http://momolin.fc2web.com/008computer.kaden-01.htm
【ソフトウェア・PC周辺機器】
http://momolin.fc2web.com/030softwar-01.htm

>>91は新手の荒らしですか？

スクリプトは無視の方向で

ボク・・・決起した・・・

そう, OSASK への反旗を・・・

ファミコンエミュでいいから早く入れてくれ

Lです。
香ばしいです。

OSASK vs OSAKA の構図

OSAKA は 2ch の住民がよろこんぶ物
OSASK は 川合氏の誇りの中で固執して唯我独尊な物

兎に角、勝手に作らしてくれ！と言うのがＫ氏
要望が叶わない住民は、＼(＞ε＜)／ うわぁ〜ん

|・。・)

いまだ100げっちゅ

⊂(・゜・⊂⌒｀つ≡≡≡

　　　|
　　　|　　 　　　　ﾝ?　　　　 　　(´´
　　　|　　　　　　 　　　　　　）　　　　　　　(´⌒(´
　　 人　　　　⊂（・゜・⊂⌒｀つ≡≡≡(´⌒;;;≡≡≡
　　(　 )　　　　　　|￣￣￣￣￣￣ (´⌒(´⌒;;￣￣
　　 ￣　　　　　　 |　　ｽﾞｻﾞｰｰｰｰｰｯ
　　　　　　　　　　 |


　　　|
　　　|
　　　|　ﾌﾟﾗｰﾝ
　 　 |　
　（ / ⌒ヽ　　　　　|￣￣￣￣￣￣￣
　　| | 　　|　　　　　|
　　∪ / ﾉ　　.　　　|
　　ﾉ ﾉ ﾉ　　　　　　|
　.（_/_/　　　 　　　|

　　　　　　　　 |
　　　　　　　　 |
　　　　　　（ / ⌒ヽ
　　　　　　　| | 　　|
　　　　　　　∪ ）　）
　　　　　　　 |　|　|
　　　　　　　 ∪∩
　　 　　　　　　 | | ））ｸﾞｲｸﾞｲ
　　 (＼＿／）　| |
　 　（＃｀∀´）／/
　 ／ 　　　　/　　　　＜MEGﾀﾝはどこ？
/ /|　　　　/

　　 ||　　　　　⊂⊃
　　 ||　　　　∧　∧
　　 ||　　　 （　 ⌒ ヽ
　∧||∧　　　∪　　ﾉ
（　 ⌒ ヽ　彡　　Ｖ
　∪　　ﾉ　　ﾌﾜｰﾘ
　　∪∪

うわあああんだよぅ ヽ(｀д´)ノ

　　 ||　　　　　⊂⊃
　　 ||　　　　∧　∧
　　 ||　　　 （　 ⌒/
　∧||∧　　　∪ /　/ヽ
（　 ⌒ ヽ　彡　　　/　ﾉ
　∪　　ﾉ　　 　　　Ｖ
　　∪∪
　　　　　　　　 ∧ ∧,〜 　頑張れMEG-OS！
　　　　　　　　( （⌒￣ `ヽ　　　　＿
　　　　　　　　　 ＼　 ＼　`ー'"´, -'⌒ヽ
　　　　　　　　　/∠＿,ノ　　　 _/_
　　　　　　　　 /（　ノ　ヽ､＿/´ 　＼
　　　　　　　､（ 'ﾉ（　　　　　く　　　　 `ヽ､
　　　　　　／`　 　＼＿＿＿_>＼＿＿_ノ
　　　　 ／　　　　　　 /＿_〉　　　　 `､＿_>
　　　／　　　　　　 ￣￣￣￣￣￣￣￣￣
　 ／

>>90
節穴さんして川合さんと漏れの身の潔白を晴らしてもいいが、
その認定になんの意味があるんだ？

> >>勝つために勝負してるんだから、負けてたら何か対応を考えるでしょ。
> 「負けてないから対応を考えてない」といいたいのだろうが、
> あなたは単に、自分の都合のいいように、
>「負けていないと思い込んでしまう性格」
> なだけじゃないかと思えてしまうのは俺だけか。

負けたら負けたできっちりそれを分析して次に生かさなければならない。
逆に言えば次があるんだから、負けを認めるのにそれほど躊躇はなかろう。
256Bに関して言えば川合さんはすでに負けを認めてるし、
エミュに任せるという一応の対応策も発表してる。

Windowsに負けを認めていないのをもって
「負けていないと思い込んでしまう性格」
と言いたいのならそれはそれで別に構わんよ。
もっとも漏れは川合さんがめけを認めていないのが、プライドによるものなのか、
性格によるものなのかどうかは知らんが、双方ともに理屈は正しいと思うし、
第一そんなことどうでもいい話だとも思ってるけども。

>>90
どう考えても違うだろ。
89は勝ち負けと言っているが、勝ち負けとかシェアとか関係なく
基本的には個人的な満足の為と言ってなかったか？
だとすれば、それが納得できる範囲であれば、
負けてようがそんなに気にならないだろう。
まあ本人の要求水準は外角高めのような気がするが、
それにあくまでこだわる完璧主義ならエセなんてやらんだろう。

だからこそ、なんでも勝ってないと気が済まなくて、現状に不満な人は
自分でなんとかすればいいだろうし、無理して使ってもらわなくて結構。
みたいな話なんだろ？
そう言うと今度はまたﾁｷﾝがｹﾂ税云々言いだすんだろうな
いー加減スレも共有ライブラリ化して欲しいものだなあ。

まあ俺的にはディスク周りのサポート強化まで様子見だな。
結局、下手にOSのウリを求めてエセで派手さを優先したのが、
狙い通り注目を集めることにはなったけど、反面弱点にもなるので
負けず嫌いのどっかの誰かの反感を買ってるってとこじゃないだろうか？

>>105-106
レスが複数あったので一瞬Ｌたんかとオモターよ(;´Д`)

とりあえず、HDDとかBIOSで出来る物はそれこそエセでいいんで
サポートして欲しいなぁ。

OSASKは将来的にはRT-LINUXやPALMよりも軽いばかりではなく、
ほぼ極限まで軽いOSになる自信がKくんにはあるらしい。
自分もRT-LINUXに関しては触ったことがないのでなんともいえないけど、
Kくんの自信は一体、どこから出てくるのだろうか？激しく疑問だ。

*.comとのコンパクト＆機能合戦に敗北したことを棚に上げるのだろうか？

極限を目指すならば、とりあえずWindowsくらいには軽量化で勝っておかないと
モノの順序として成り立たないのでは？
(※もっとも将来的にも含めると、*.comをOSASK上で動作させることが可能かも
しれず、その場合は実用上、軽量化に成功すると思われるけど、やはりOSASKネイティブの
実行フォーマットでもコンパクト化は必要なのでは？）

>>108
そういや、ＫってCOMは未だにDOS扱いしてるんだろ？
256bが、PC-98の生DOSで動かなくても、Windows95入れれば動くのを確認。
PC/AT用に書かれたカリカリのアセンブラコードも、VESAを利用したコードも
PC-98であろうが、Windowsなら動く。

でも、Ｋは「あほくさ。あれはMS-DOSですよ」と敗北を認めない。

Kﾀﾝ自身はcomそのものは素晴らしいと評価してたんだけど、
なぜかWindowsの実行ファイルとは別物と評価してましたな。

KﾀﾝはOSASKの弱点を指摘して欲しいとのことだったけど、
弱点どころか、今まで「軽量」であるという長点までもが
実はみんなが動作しているWindowsには及ばなかったというオチになってしまう。

彼自身、OSASKの弱点を指摘することでOSASKそのものを強化できると
期待しているみたいなので、敢えてここでOSASKの実行フォーマットは
Windowsに比べれば「肥大」であるという弱点を明確に指摘しておきたい。

Windowsであれば、256バイトに収まるものが、OSASKだと数倍程度に
膨れ上がるとK氏自身も考察しているのだし。

>>109-110
まだやってるのか… 延々同じネタ繰り返して楽しいの？

>>108
RT-Linxuはいいけどさ、PalmとOSASKを比べるのはさすがに無茶じゃねーの？（ﾜﾗ

「一見、遠回りに見えて、実際は近道だった」ってこともあるし、
「一見、近道に見えて、実際は遠回りだった」ってこともあるし、

特に、未知なるもの（機能は似ていたとしても、現存物の亜種じゃない）を開発
する時は、上記の言葉を肝に銘じておくべき。

なんかKﾀﾝよりも「軽さ」に執着してるヤシがいるな（藁

>>112
ｵﾏｴﾓﾅｰ

>>104
応援ありがちょー。がんばるょぅヽ(｀ー´)ノ

なんつーか、本当に2chっていいよな。

>まだやってるのか… 延々同じネタ繰り返して楽しいの？
てか、Ｋﾀﾝが軽量化を唱える一方、Windowsごときに負けてては
話が先に進まず、無限Loopでは

>>それとも、Windowsは.COMだけしかサポートしなくていいと割り切れば、OSを1MBくらいにまで縮小できるんですか？
>>(そんなインストールオプションがあるなんて僕はきいたことがありませんが)。
WinXP以降は可能です。設定で「カーネルコードをswap可能にする」という状態にして
本当に .comだけしか起動してない状況になると、モニター見れば分かりますが、2MB以下の消費量にまで
低下します。
で、さらにBOOT-GUIのOFFにした状態で、プロンプトから.comを起動すれば
消費メモリは1M以下っす。

ただ、使われてないコードは4kb単位でがんがんDiskにswap-outされてしまうので
動作の快適さまではいまいちですが。

でも、例にあがってる256ﾊﾞｲﾄものなら、swapしないしー。

いくら、OSの実行サイズが小さくなっても、OSコードのswapが実装されれば
使われてないコードはメモリに残らないので、OS本体のスリム化よりもWinXPの
カーネルが実装したような工夫のほうが汎用的、根本的な解決になるかと。

↑そだね。確かにXPって、linuxとの軽量化戦争でそれなりの勝利を収めたと
思われる。linuxもカーネルのswap計画があるけど、元々、カーネルコードは
swapされないことを前提に設計されてるため、すぐには難しいらしいし。

詳しくは知らないけど、OSASKのカーネルってswap可能なの（もしくは将来的には
swap可能な設計なの？）

なぁ、128MのRAMが\2500切ってるこの時代に
1Mで起動できることになんの意味があるんだ？
1Mで起動できなくても、ユーザーが使ってるうちに1M程度で動くほうが
重要なのでは？
XPな場合、128MBあったらカーネルの占める割合は1%未満なんだし
残りは可能なかぎりアプリケーションエリアとして活用できる設計なら
実用上、なんら問題ないと思うのだが。

80GBのHDが1万代で購入可能な時代になぜswapを気にする？
標準では512MBのswap設定だし、0.6%程度、それでRAMが軽量になるなら
いいのでは？

見ろ！

http://www.ipa.go.jp/NBP/14nendo/14youth/gaiyou/02-005.htm

お前らOFFには行きますか？

>>119
＞1Mで起動できることになんの意味があるんだ？
とりあえずダウンロード楽でいいんじゃないのか？
気軽にバージョンアップとか出来そうだし。
まあバージョン不整合とかがなければの話だけどね。その辺が心配だなあ。

＞1Mで起動できなくても、ユーザーが使ってるうちに1M程度で動くほうが
どちらかというとメモリは有るだけ有効利用する代わりに、ユーザーに追加の
余計なメモリを使わせないで済む設計のほうがいいと思うな。
それが共有API化の意義ってものじゃないの？
ただ、タスクスイッチの度にスワップが起きるなんてのはやめてね。
要はDOSでコンベンショナル幾ら空けたとか言ってて、よくみてみたら
上に逃がしてただけみたいな話で遅くなるだけだし。

だから実行バイナリのサイズなんかより、スワップ等も考慮した占有サイズで
比較してみるべきじゃないかって気がする。UNIX系他はどうなんだろう？
まあOSASKの実装状況からいって、善戦できてれば御の字じゃないのかな？
もし勝てるようになればOSのサイズ差は本当に無駄って事になるね。

まあ大したコスト差じゃないと考えるならそれでいいんじゃない？
コストより物理拡張無しに動くって事が嬉しいんだけど、その恩恵を受けるのは
レガシーハードを活用したい人で、そういう資産が無い人が、おれのハードは
リソース潤沢に持ってるので関係ないっていうのは当然かもね。
でもそれがパフォーマンスの足を引っ張る訳じゃないと思うんだけどな。

だからそんな人がサイズを気にして何を必死に訴えたいのだろう。
窓の宣伝？

>>122
またＫ氏か？

>123
面白いことを言うね。また？

むしろまたＬ氏じゃないのか？

ところで今って多色とハイレゾ対応をやってるのかな？
それで疑似多色モードの話なんだけど、
タイリングもいいけど、98の画像ビューアとかでよくやってた
画面やパレット書き換えによるフラッシュ表示はどうなんだろうか？
確かベクターにあるGIFMやGIF16とかに詳しい解説が有った気がする。

カーネルやシェア・モジュールのswapを組み込んでしまえば、
OS本体のサイズ軽量化競争って不毛であるばかりか、無意味じゃん。

現状のOSASKが60kb前後だと主張されてもねぇ。
ネット対応もUSB対応もビデオカードアクセラレートもサウンドボードも対応
してない状況で、カーネルサイズのお話しても仕方ないのでは？

で、OSASKが上記必須事項を実装していくにしたがって、カーネルサイズは
1MB前後にまで膨れる見積もり。これはlinuxで実証されてしまってる。

このとき、カーネルswap機構がないと、ここ最近のように
「linuxはWindowsに比較してメモリ食いだ」となってしまう。

で、OSASK陣営、っていうかＫ氏に提案なのだが、
「PCをブートしてから、2chのOSASKスレッドを開くまでの時間」で比較してみない？
今のところ、Windows+IEが最速で、そこから5,6倍のノロさで linux + w3m ってのが相場。
（もっともlinuxの場合、実はもうちょっと最適化できるのだけど）

結局、ユーザーの快適度って「サクサク目的を達成する」ことにあると思う。
で、この提案はそのOSの使いやすさを図る目安として妥当だと思うし、
OSASKがこのラインをクリアしてしまえば、説得力も違うのでは？

2chってほとんどテキストのみだしね。
今、OSASKからカキコしてますー、っていい感じじゃん？

> 現状のOSASKが60kb前後だと主張されてもねぇ。

> で、OSASKが上記必須事項を実装していくにしたがって、カーネルサイズは
> 1MB前後にまで膨れる見積もり。これはlinuxで実証されてしまってる。

すごいな。三国人も真っ青だ。

linuxのカーネルは元々リアルモードにて、570kb未満のカーネルコードを
読み込み、その後、プロテクトモードへ移行して、さらにコピーしてた。
リーナス氏は、このブートソースのコメントに
「linuxは簡素であるから、未来永劫、570kbというサイズは十分なサイズのはずだ」
としていた。

果たせるかな、その後、linuxのカーネルは膨れ上がり、'97には遂にこの570kbの
制限では足りなくなってきた。

さて、osaskの60kbというカーネルサイズは、どこまで膨れ上がるか？
HDアクセスすら未実装で、カーネルと呼ぶにも恥ずかしい機能しか搭載してない
ジャンク・バイナリをして、現状は簡素であると言えるだろうか？

必要な機能を実装した上で小さい状態をもって、「簡素」と呼ぶにふさわしい。

> 将来的にも1MB程度になる見込みなので(ぼやきの2002.02.12を見てください)、
> 将来的にも1MB程度になる見込みなので(ぼやきの2002.02.12を見てください)、
> 将来的にも1MB程度になる見込みなので(ぼやきの2002.02.12を見てください)、
> 将来的にも1MB程度になる見込みなので(ぼやきの2002.02.12を見てください)、
> 将来的にも1MB程度になる見込みなので(ぼやきの2002.02.12を見てください)、

×レス
○レスから引用

どうでもいいけど、さっさと潰れかけの imasy から抜けなよ、Kさん。
ウェブいきなり消えるかもしれんぞ。

アセンブラ、オンリーのOSってやっぱり速いの？
プログラムの保守は別として。

>134
Menuetでも見れくれば？

> 将来的にも1MB程度になる見込みなので(ぼやきの2002.02.12を見てください)、
だめじゃん。それじゃWinXPよりも肥大だよ。
ちなみにMicrosoftのX-BOXは、WinNTカーネルが搭載されてるんだけど
512kbで起動する。そのかわりswapしないんだけどね。
この512kbにはワークエリアも含まれてるので、実行サイズはもっと小さい筈。
ゲーム機は64MBしか詰んでないからね。OSも詰める必要があったんだろうけど。

その2002.02.12のボヤキどうりだったら、OSASKはカスタマイズドWinNTカーネル
に比べて2倍以上も肥大ってことになるな。

>135
たしかに、アセンブラのみですね。。
アセンブラでの構築の効率化方法そして時間（これが一番問題）があれば、
アセンブラのみで作るもの面白そう。
使うアセンブラ選びが超重要そう。。。

しかし！作成するOSの隅々までアセンブラレベル（場合によっては機械語レベル？
で把握できるので、デバドラとの協調を取りやすいとか、わずらわしい、
コンパイラの仕様を気にしなくていいので、気持ちがいい。

＞なんで興味がないのかというと、重そうだからです(もちろん、
＞重いだけあってそれなりに美しくなりますが)。 パレット書き換えは
＞それほど重くならないと思われますが、この方法だと各パレットの
＞色分解能が向上するだけで、画面上で使える色数が向上するわけ
＞ではありません。
そりゃ空間軸に並べるか時間軸に並べるかの違いだけどさ、VGAの
画面だったら解像度が断然違うと思うんだよな。それに併用すれば
当然色数が向上する事になるんじゃない？
あと、VRAM依存じゃない仮想デスクトップも必要だと思うなあ。
まあ、クリッピング問題をなんとかする時のついででもいいから
考えておいて欲しい。

>ちなみにMicrosoftのX-BOXは、WinNTカーネルが搭載されてるんだけど
>512kbで起動する。
スレッド、プロセスの最大数を設定することによって256KBでも起動しますがなにか？

＞しかしどちらもhtmlファイルをHDD(OSASKではとりあえずFD)に入れておいて、
＞それで表示させるという手もあるでしょう。
＞そうだとするととりあえず、あとはhtmlビュワーを作るだけですね。
このhtml-Viewerなんだけど、これアプリとしてではなくOS側に実装しないと
まずくない？（効率面で）
ブラウザを複数アプリが複数開くことなんてざらだし、その場合、OS側に
実装させてしまったほうが（もしくはディフォルト設定でそのようなDLLが
ロードされている状態）効率的だと思われ。

それにHTML-Viewerじゃねぇ。
やっぱカキコできないと。
2chに一つ書き込むにも、日本語IME、GUIモジュール、複数種類のフォントのロード、
テキストボックスの構築、httpプロトコルの送受信など、様々なプログラムが連携して
初めて実現できるので、ただ単にHTML-Viewerだけじゃ比較にはならんと思うぞ。

2chのCGIは一部、JAVA-SCRIPTも吐き出すので、それ専用の言語パーサーも
搭載しなきゃね。
w3mはJAVA-SCRIPTも実行できるけど、テキスト表示のみだし。

確かに掲示板である2chへの読み書きができれば、OSASKも実用的かと。
「説得力は関係ない」なんて言葉遊びは止めましょうよ＞Ｋ氏
実際、ネットの掲示板に読み書きできないＯＳなんて、あなた自身、満足でき
ないのだから。それとさ、説得力は関係あるぞ。開発者をより多く集めることが
できれば、OSASKの発展も加速するのでは？

ヒネクレは厳禁。っていうか誤解の元なのは百も承知では？

んじゃ、141任せた。

誤解するのは>141みたいなのだけだから問題はない。
好きでOS作るためだけに、はいつくばっててめえの汚い尻の穴舐めなきゃならんのか？

しかしブラウザが使えるようになって欲しいというのはﾄﾞｳｲ。
OSと同時進行で行けば問題点がわかりやすくてよさげ。
まあ開発力が持たんだろうけど。
ところでWin（たぶんXP）+IEより超漢字+BBBの方が速そうな気もするが。
BBBの性能は無視しておいて。

ブラウザならNWSOSのほうが速くできそうな予感。
なんとなくね。

>>140
IEもどきはどうなんだろうと思うけど、要は拡張コンソールだあね。
キャラクタonlyの時はエスケープ制御でやってたのが、タグに
変わっただけとも考えられるかな？

とりあえず見た目的にはまず可変フォントサイズ、ピッチの実現だなあ。
まあ見るだけじゃインパクトとしてはちょっと弱いかもね、、、
ただオフラインモードもあるわけで比較としてはありじゃない？
ポストするのは文章書いてからの話だし。

しかし、ＦＤでやるって言うのは読み出し速度を考えると
どう考えても不利じゃないだろうか？
NICのドライバなんて資料次第でさくさく書けないだろうか？
・・・というか他から流用可能にする話はどうなったの？
プロトコルはサブセットでよければ８bitでも動くみたいだから
いくらでもエセで手抜き出来るだろうし、それでもマルチタスク
OSの力でパフォーマンスもそんなに悪くならないのでは？

パソコンの三種の神器って、ワープロ、表計算、グループウェア。
実際、普通に会社で過ごしてると、上記３種のアプリは、もうないとやってられない。

でも、個人的にはその3種の神器を上回るソフトがブラウザだと思ってる。
なんだかんだ、パソコンのほとんどの用途ってブラウザで占める割合が多い。

OSASKも最初の本格的なアプリはブラウザを目標にするのは悪くないと思う。
川合氏の唱える快適感は、実際にブラウザを使ってみないことには分からないし
それまでは比較の意味はないと思うしね。

今のosaskの開発速度では何も期待できない。
w3m相当のブラウザが1年以内にosaskで動くわけないじゃん。

仮に実現できるとしても、せいぜい、nwsosかmonaだろ？

Ｋ氏はUSBなどの対応をどのレベルで実現することを想定しているのだろうか？
あれって、時間内処理がシビアだから、linuxもWindowsもカーネルで対応せざる
を得なかった経緯があるのだけど、OSASKだと、さっくり実装できたり
するんでしょうか？（現存のUSB対応するだけでもかなりコードが太るらしいけど）

お前らオフですよ？

>>147
EOTAも候補かもしれず。

【予備知識】

EOTAに移植されたアプリケーションの一部
http://home.interlink.or.jp/~s-nakani/doc/application.html
http://s-nakani.hp.infoseek.co.jp/eota/index.html

オフ会どうよ？

>>今のosaskの開発速度では何も期待できない。
>>w3m相当のブラウザが1年以内にosaskで動くわけないじゃん。
>>仮に実現できるとしても、せいぜい、nwsosかmonaだろ？
まぁ、HDにすらまともにアクセスできないのではな。
そういう意味じゃ、nwsosもmonaも同じかと思われ。

けど、OSASKとは違って
後者二つのOSはなぜか漠然とした未来っていうか希望が見えるんだよな。
そう思う、具体的な根拠だとか理由ってのは、特にないんだけどさ。

なんでだろ？

>具体的な根拠だとか理由

＜後ろ姿＞y-~~~ おそらくその答えはたった１つ。
高級言語か否か。

ASKAってAXレジスタだとかがしがし使ってるみたいだけど、
x86のことしか考えてないっぽいところがねぇ。
Intel自身、将来的にはx86を捨てる予定なんだし。

やっぱカーネルもせめてC言語で記述しておかないと、厳しいよ。

osaskに未来を感じない理由は、川合氏のビジョンに夢がないから。
\39800のPCで、CPU 2.0GHz HD 80Gb WinXP RAM 256M のスペックが購入できる今、
川合氏のビジョンはあまりにも後ろ向きすぎる。
既存の古いPCでいくらOSASKがサクサク動いても、例えばMP3のエンコードなんかも
サクサク動くわけではないからね。

川合氏は、「新規性なんてどうでもいい」なんて言ってるけどさ、
やっぱOSASKならではのオリジナリティがなければ夢も実用もないと思うんだよね。

高級言語か否かなんて、開発者の問題でしょ？ユーザーとしては、カーネルが
どんな言語で記述されていようが、気にならないし、関係ない。

>>152
オフ会、部屋が寒かったぜ

ＫってＮＷＳＯＳを指して、「なんか、Windowsを追いかけてるようで独自性が
なくてつまらない」みたいなニュアンスなこと、どっかでわめいてなかったっけ？

新規性なんてどうでもいいのかな？
どうでもいいというのは、言葉の勢いで出てしまったと好意的に解釈したと
しても、要は、Ｋ本人が納得し欲するＯＳを作ることのほうが優先順位が
高いということなのかな？

その癖、他人のＯＳには夢だないだの余計なお世話やきなんだな。
おっと、俺はＬﾀﾝでもなければ信者でもないぜ。ちょっと客観的に批判してみただけ。

俺は、いろんなマニアックなＯＳをインストールしては、うひょひょ動いた！みたいな
ＯＳ厨に過ぎないんで、馬耳東風程度に聞いておいてくれや。

＞おっと、俺はＬﾀﾝでもなければ信者でもないぜ。ちょっと客観的に批判してみただけ。

ものすごく主観的な気がするのは漏れだけか？（ｗ
いや別に批判が悪いとかいっているわけじゃなくて。単に思っただけ。

WinXPになってから、比較的ブート時間が快適、高速になったけど、
さらに最適化するツールがあることが判明。

http://home.att.ne.jp/yellow/hide_n/index.html

↑このページに紹介されているBootVisというのがそれらしいです。
早速、試してみたけど、我が家のマシンのXPブート時間は1/3に！！

#話逸れますが、
WinXPのテキストベース・シングルユーザー・カーネルで起動すると
OSASKのFD起動とほぼ同等。（厳密に計測できないのだけどね、っていうのは
コマンドラインに打てる状態になっても、HDががしゃがしゃ言ってる時間が５秒
ほどあるから）

HDと比較するのはどうだろう…。

それよりも何かの拍子にXPって起動も終了も死ぬほど遅くなるのは
激しくやめて欲しい。あーなるとWindows2000より遅くなるから
XPの意味がない。起動遅くてもWindows2000の方が安定してるから
漏れは好きだな。

>HDと比較するのはどうだろう…。
OSASKにHDアクセス機能がない以上、比較されても仕方ないのでは？
っていうか、なぜいまだにOSASKにHDアクセス機能がないのか不思議だ。
自分の場合、FAT32アクセスは4.5日で実装できたのだが。（もちろんBIOSなし）
NTFSだと、もうちょっとだけ難しいのだけどね。

カラオケBOXのセットボックスだったんだけどね、その仕事。
日本円換算で５８０万の仕事だったんで、
５８０万くれたらOSASKにも実装してあげるよ。

そういえば昔、NWSOSにカラオケボックスのオファーが来てた
名前を晒したりと怪しかったが結局ネタだったんだろうか

開発開始から数年もたっているOSがHDひとつアクセスできないのは
いろいろ問題だろ？
ていうか、川合氏ってちゃんとOSASKで暮らしてるのか？

ぶーぶー言いながら、なんだかんだWindowsの住み心地の良さが
OSASKの開発を鈍らせてるんじゃないか？

＞WinXPになってから、比較的ブート時間が快適、高速になったけど、
＞さらに最適化するツールがあることが判明。
俺の買ってきたばかりのWinXPマシンは、レジューム機能搭載なら
電源入れてBIOS終了後、７秒で起動したからいいや。
128MBのみ有効にすると3秒！1,2,3で起動。まぁ純粋にHDの速さなのだが。
っていうか、ここまで速いとBIOSのほうが鈍臭い。

OSASKってBIOSを書き換える計画はないの？起動の速さじゃWinXPと大差ないし。
あのBIOS、ウザくない？
BIOS-ROMにOSASKを書き込むくらいの気合があれば、Windowsと大差ないよ。

>>165
買ってきたばかりのXPマシンは速いのよ。それはもう恐ろしく。
何故か使って半年〜１年もすると死ぬほど遅くなったりするのね…。何故？
仕事用マシンだからソフト追加してないんだけどなぁ。

あと、XPで128MBって使い物になる？

>>165
BIOSについて勉強しる．．．

ROM 　りーどおんりー（<--ここ発音良く。）めもりー


はぁ。。。。

>>168
最近のBIOSはほとんどFlashROMですが何か？

ボクのBIOSはDIPスイッチだよ ヽ(｀ー´)ノ

>>169
最近でもないけどな。
でも、OS が勝手に BIOS 書き換えるってのがｽｺﾞくないか?

>>170
NEC98ユーザですか？
ってーか、98とATのシングルバイナリを実現された神に
こんな質問は愚問かな。

っても、やっぱりディップスイッチだったのはRX/RAまでで、
386になったDS/DAあたりはディップスイッチレスだったはずだが。

まいーや。とりあえず漏れとｹｺｰｿしてくれ!!

>>172
RAは386ですが何か？
あとRSなんてのもありましたが。

>>172
(((( ;ﾟДﾟ)))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

>>174
あんた男なの女なの？
HPや経歴を考えても女としか思えないんだが。

>>175
ネット初心者でつか？ヽ(｀ー´)ノ

>>176
ネット歴たったの10年だからな。
あんたより初心者だと思うよ。(w

ょぅ初心者！ヽ(｀ー´)ノ

実務年数や*年齢*は努力じゃ覆せない。

おいおい、ここはナンパ掲示板じゃねーぞ

>OSとアプリとデータの全てをコンパクトフラッシュに入れて持ち歩くのは、
>もう想像するだけで快適ですよ。
言いたいことは分かるのだけど、コンパクトフラッシュって10万回書き込み程度の
寿命があるんで、難しいよ。
あと、最近のハードウェアってHD書き込みの方が速いんで。
コンパクトフラッシュをどこに刺すかにもよるけど、HDの場合、HDに書いたつもりでも
HD内臓のバッファRAM（1MB〜8MB程度）に書き込んだに過ぎないケースもあるので
HDって意外と軽快。

コンパクトフラッシュ最大の欠点は、CPUをブロックすることかと。
HDとは違い、DMAによるバックグラウンド転送ができず、結果的にCPUを
ポーリングに費やしてしまう。

まぁ、コンパクトフラッシュで起動するそのスマートさっていうかスタイルには
あこがれるけど、それはlinuxで実現してるしね。
Windowsであれば、WinCEが実現してるよ。

Windowsのインストールサイズを肥大化されてる、その原因はただ単に
豊富なフォントの種類が原因だったりする。これらを必要なフォントだけに絞れば
WinXPでも512MB程度には余裕で圧縮可能かと。

>>172
うちのFAはソフトウェアディップスイッチのくせに
ハードウェアディップスイッチがいくつかありますが何か?

＞ROM 　りーどおんりー（<--ここ発音良く。）めもりー
＞はぁ。。。。
片田舎のカラオケ屋の店員は黙ってろよ

現状、PC/ATのBIOSが、本当にROMである可能性は1%たりともあり得ない。

で、OSASKがBIOS-ROMに入ったら、それはそれでいかすな。
昔とは違って、エミュがあるんでBIOS-ROMの開発もいけるんでないの？

>うちのFAはソフトウェアディップスイッチのくせに
PC98FA ?
壁に穴開けたっての、ネタだろ？たけ

>>181
> コンパクトフラッシュ最大の欠点は、CPUをブロックすることかと。
> HDとは違い、DMAによるバックグラウンド転送ができず、結果的にCPUを
> ポーリングに費やしてしまう。

それはものすごく単純に「CF-ATAPI化キット」なんかが
今はまだUltraDMAに対応していないというだけの話では？
実際のところ対応してるのかしていないのかは知らんけど。


書き込み回数の問題ってのはどうだろう。
仮にOSASKのOS領域のSWAPがゼロになったとして、
さらに書き込み回数を押さえたとしたら
平均して一日10回ぐらいで納まらないかな？
つーか100回だとして1000日、逆に一年持てばいいとして、
一日300回弱の書き込みが可能になるわけだが。


最大の問題は新型の高速不揮発性メモリだな。DRAMに取って替わるとかいう・・・

>>183
そのエミュはCPUだけでなくBIOSのエミュレーションもやってるわけで。
各モデルのマザーボード用のOSASKを開発するのか?

>>でも、OS が勝手に BIOS 書き換えるってのがｽｺﾞくないか?
最近、WindowsからもBIOS-ROM書き換えるユーティリティあるよ。
ってか、BIOSの型番をgoogleと、BIOSのアップデートサービスがある。
まぁ書き換え中に電源切ったりすると、そのPC/ATは死ぬけどな。
BIOS-ROM換装すれば話は別だが。

電源入れたら、即、OSASKのロゴが出たら俺も協力するよ。
ピー！ってBeep音してから、1秒でOSASK-GUIがブートしたらある意味、雑誌連中も
騒ぐぜ。っていうかWinXPのレジュームが極めて強力な今、ブート速度で競うなら
BIOS-ROMからその勝負は始まってるといえるのでは？

DIPスイッチの意味を取り違ってる人ハケーン

＞平均して一日10回ぐらいで納まらないかな？
収まるわけないじゃん。アプリががしがしセーブしたらそれまで。
メモ帳とかで簡単なテキストでも、こまめにセーブするユーザーが使ったら
危険。

結局、紫外線に対する耐久度の問題なので、部分アクセスしても
広域に寿命をすり減らしてしまう。特に最近は集積度が高まってるために
融通が利かない。

ROM化してLANのBoot-ROMに、というのはどうだ？
蟹チップ搭載カードにはソケットあるみたいだし。
ROMサイズは64Kバイトだから、今のOSASKでも少し削ればバッチリ！（ｗ

>>187
> 最近、WindowsからもBIOS-ROM書き換えるユーティリティあるよ。

それは、OS が勝手に書き換えてるわけじゃなくてマザーボードのメーカーが
開発した Windows 用のフラッシュユーティリティだろ。

>>189
危険だけど、死ぬほど遅延書き込みすればOK。きっとOSASKならやるだろ（ｗ
それはともかく、確か松下がほぼ制限の無い半導体の開発に成功したはずだから
2〜3年もすれば普及するでしょ。無問題。

ﾁｮﾄコンパクトフラッシュについて調べてきたよ。
>>185の
> それはものすごく単純に「CF-ATAPI化キット」なんかが
> 今はまだUltraDMAに対応していないというだけの話では？
は間違いだったよ。スマソ。
CFはATA互換のバス持ってて、CF-ATAPI化キットなんていうのは
特に何もせずに直接繋げてるだけらしい。
んでまあ当然のようにPIOぐらいしか対応してない。
しかしこの接続キットのたぐいってのはぼったくりが多いな、と。
転送速度はHagiwaraの高速版で2500KB/sec程度。
普通なら1000KB/secもいかない。
ただし、シークタイムはゼロ。
参考にhttp://www.ircube.jp/main/icf/


>>189
OSなんだから別にアプリが何をしようと
実際にディスクに書き込まなきゃいいだけでないか？
そういうのにぴったりっぽいメモリマップドファイルとか。
つーか、紫外線って何だよ。紫外線って。

あ、も一つ参考に
http://www.kyoto-sr.co.jp/products/fugue/techinfo/ffs-intro.html

>そういうのにぴったりっぽいメモリマップドファイルとか。
>つーか、紫外線って何だよ。紫外線って。
最近、減ってきたけど、フラッシュメモリへの書き込みに微弱近接紫外線を
使ってたことを言ってるのでは？（てか、寿命あるものは紫外線なり熱線当てて
その耐久度があるゆえに、いつかお亡くなりになるわけで）

ｷﾀ━━━━(ﾟ∀ﾟ)━━━━ｯ!!
一ヶ月以内にATAサポートのﾖｶｰﾝ

ていうか、３年くらい前にビルゲイツが基調講演で、
「Windowsも将来的にはフラッシュからのクイックブート（のみ）をサポートする」
と力説してた。
っていうのは、ROMとしてプリインストールすることによってlinux機を牽制すると
同時に、CD-ROMインストールを排除したいという違法コピー対策にも効果的であると。

Win9x系やlinux系はともかく、WinNT系はBIOSを叩いてないクリーンOSなので
意外と簡単に実現できることもゲイツは語っていた。
ゲイツの言い分は、BIOS経由でしかサポートされてないデバイスが多いため
急な移行は難航していると逝ってたな。けど、その後、各デバイスはWDMへの以降が
急激に進んだため、名実ともにBIOS不要な状況になってきたのも事実。
実際、WinXPにしたため、使えなくなったデバイスが莫大にある！というトラブルあんまりないしな。

＞ていうか、３年くらい前にビルゲイツが基調講演で、
＞「Windowsも将来的にはフラッシュからのクイックブート（のみ）をサポートする」
正直、クイックブートなんてしないから、いらない機能かな。
WindowsもXPになってようやく安定してきたし、unix同様、リブートすることなんて
滅多になくなってきた。CPUがidleだったら、勝手に電源落ちてくれるし。リジュームだって
電源落ちる直前の状態にまで、メモリ１G詰んでても、10秒で復活するしな。

というかね、シャットダウンを頻繁に必要とするOSってどうよ？
携帯系だって、リブートはしたくないね。
リブートではなくてリジュームでしょ？
さっ！と電源切れて、さっと電源入れたときに、前の状態でなければやってられない。

2000の方が安定シトル。

>>2000の方が安定シトル。
正確にはWin2kのドライバ群のほうが安定している！だろ？

ドライバの安定度が、OSの安定度を決定するという宿命を断ち切らないとね。
どのOSにも言えることだけど

>>199
XPはOSにも絶対問題あると思う。そうでないと使ってて起動や終了が遅くなったり、
CPU100%使うようなアプリ動かしてると新しいプロセス起動できなくなるなんていう
ことは考えられない気がする。

デバドラの安定度がOSの安定度になるのは速度のためだから仕方ないでしょ。

というか、リブレットでもWinXPがプリインストールされてる時代だし。
リブレットそのものがHDレスになればいいだけの問題では？
何もOSASKでの実現を待つまでもなく、Winが実現してくれる。

つーかさ、WinCEのシェア拡大を阻んでいる最大の原因は、Win2kだとかの
モバイル化が進んでいるからだと、良く記事のネタにされてるじゃん。

モバイル特化OSって、死語なんだよね。
それ専用のOSこしらえるより、既存Winをカスタマイズしてしまったほうが
安上がり。

●モー娘。裏画像専用２ちゃんねるリニューアルオープン●

入場の仕方は以下の通りです

☆このスレのいちばん下にある「名前」の欄に半角小文字で「fusianasan」と入力します
☆「E-mail」欄に、次の様に入力します
小学生なら　low　中学生は　middle　高校生は　high　と入れる。
　　 （年齢別の画像専用だそうです）
☆「内容」欄に見たいメンバー名を次の様に入力します
　後藤真希　　 gocchin　　　　矢口真里 marippe 　　　　安倍なつみ　　nacchi
　紺野あさ美 konkon 　　　　　加護亜依 aibon　　　 　　　新垣里沙 kone
　辻望美 nono　　　　　　　　　 高橋愛　　 ora　　　　　　　市井沙耶香　　kaasan
　石川梨華 charmy　　　　　　 吉澤ひとみ yossy 　　　　中澤裕子 30
　小川麻琴 mako 　　　　　　　飯田圭織 kaorin
☆最後に「書き込む」をクリックすれば完了です

↑矢口って数年前までガングロ系で眼中なかったんだけど、
この前、ミニモニのＰＶ見たらいつのまにか、ホッペの肌のツヤが磨かれてかわいくなってた。

って、そんな話ではない。
XPはBIOSを叩いてないOSだからカーネルサイズもかなりのものだが、
OSAKはBIOSを利用しているのだろうか？
どちらにせよ、BIOSにOSASK書き込めたらおもろそう。
BIOSのメモリチェックとかって不要だよね。（設定で不要にできるんだけどさ）

＞モバイル特化OS
むしろ特化しないのがOSASKだろ？　意味わかんね。

>>203
現在のところ、BIOSは一切触ってないはず.
USBデバイスからのブートとかのために
BIOS経由での読み出し書き込みもサポートするつもりはあるってさ.

　BIOS-ROMを書き換えること自体は物理的には可能だけど、BIOSは、
チップセットの初期化や、メモリのWAITの設定、FD/HD/CDからのブート
なども担当してるわけで、OSが勝手に乗っ取っていいようなものじゃない。

　特に、チップセットの設定などは、PC/AT の共通規格にはない場合も
あるかもしれない。

　また、自作機の場合、マザーボードのハード的なバグをBIOSでソフト的に吸収
している場合もある。

とはいえ速度的には大きな魅力なんだよなぁ。
M/Bメーカーが何かうまいことしてくれないかな。

Fastboot BIOS とかあるだろ。復旧度はどうかしらんが

WinXP、30MBインストール可能。
ただしGUIを外してな。
内訳機能は、httpサーバ、CGI用のperl、telnetサーバ、dhcpサーバ、
カーネル、CUIシェル（tabで補完効くんでDOSプロンプトというよりunix系のshellに近い）

本当はFD数枚程度にまで収まるらしい。
WinNTの初代最高責任者、デビッド・カトラーってサイズ狂だったな。
20年前、たった256kbのRAMしかないDECのミニコンにunixクローンを作り
あげてしまう人だし。OSASKって256kbじゃ起動すらできないのでは？

話は別だけど、Win2k時代にたった4cm立方体のサーバーPCを
発売してたメーカもあったけな。etherの口しかない。telnetで入れなかったら
そのPCはご臨終。

意外と知られてないけど、JRの切符の自動販売機ってWinNTのシェアが広い。
これもCUIインストールなんだけど、FD2枚でWinNT3.5カーネルがインストール
されている。エンベディッド・エディションってのをメーカー向けにMSは卸してた。
ここでもお茶目なカトラーは、「なんで1枚にできないんだ！」と。
部下の返答は、「日本のpc-98のFDは1.2MBしかないのです。1.44MBだったら1枚に
収まります」だとさ。呆れた。

余談だが、最近のWinXPの起動速度は異常。ってか、普段、linuxな人なら
分かると思うが、家庭用の通常のデスクトップPCで、片っ端からデバイスの
初期化応答をしていれば、最低、起動時間はlinux程度にはかかる筈。
単純にコードの質というよりは、ハードウェアの反応速度の問題で律速に
なる筈なんだが、WinXPはあり得ない速度で起動する。
（※かと思えばあり得ないノロノロ起動になることもあるから不思議だ）

事情、詳しい人、情報よろ。

ポケットポストペットとかPDAでOSASK動いたらいいのに・・。
容易に移植できないという罠。
モバイル市場でのx86のシェアってそんなに広くないのでは。

>209
MSX用UNIXのUZIXは32KBしか使わないわけだが（ｗ
つか、制限ある中で制限内に収めるのは
サイズ狂だからできたというわけじゃないだろ。
ところでなんで>209は呆れてるんだ？よくわからん。


XPの起動が速いのは>208+最適化の結果だったはずだが。
レガシーデバイスが削減されてるというのもあるだろうけど。

この中で、BeOSのインストール時のデバイス認識速度見たことあるヤシいる？

NWSOSがBochsに対応したことで、
K氏の努力がある程度成果を挙げていたことが判明した模様

386とかだとC++で普通にプログラムを書いても意外と遅いからね

＞NWSOSがBochsに対応したことで、
＞K氏の努力がある程度成果を挙げていたことが判明した模様
ん？どういう成果？

>>216
L様スレ嫁

>215
意外でもなんでもないけどな。

>>L様スレ嫁
読んだけど分からん

>>219
飛び火してるこっちはどうかな？
http://pc.2ch.net/test/read.cgi/os/1021620622/135-

やっぱりOSASKは恐ろしく軽かったと。

当たり前のようでいて皮肉な話だな。
まあ実際のところどれぐらいの差なのかはわからんけど。

age

で、オフ会ってどうだったの？
だれかレポートでも公開してくれないかなぁ〜

>当たり前のようでいて皮肉な話だな。
>まあ実際のところどれぐらいの差なのかはわからんけど。
いや、どうも低解像度以上にしたときにエミュレータが極端に遅くなるっぽい。
NWSOSの壁紙表示すら、もたついてる。
あの手のものは、単純な memory-copyに過ぎないはずなので。

エミュ同梱で初めてNWSOSを目撃。エミュだとのろいというので、これを契機に
ネイティブNWSOSを実感した感じ、衝撃ではなかったけど、
「おいおい、OSASKなにやってんの？」という感じだった。

今年もはや二月になったけど、じゃ新年あけてこの一ヶ月でOSASKは
どういう機能が実装されたの？と尋ねるたとき、それに見合う機能は実装
されてるのだろうか？

>>226
VESA対応じゃ見合わない機能なのか？

とりあえず、OSASK陣営はNWSOS＠BOCHSが遅い事件で
鬼の首を取ったようなさわぎっぷりだが

結局その後のLﾀﾝの改善ですぐにはやくなったじゃん

OSを高級言語で組んでおけばアルゴリズムの改善も
すぐにできるという証明だと思うけど。

なんか、OSASK陣営って妙に閉鎖的なコミュニティだよね。
OSASK=Kﾀﾝ=神　みたいな。

もっと批判的な眼を持った人がいたほうがよいと思う。

>>154
超先生に問う。
OSASK,MONA,NWSOS

主観的な意見でよいので
一番未来のあるOSはどれだと思いますか。

※「未来のある」の定義は超先生の解釈にお任せします。

>228
言うヤシが絶対いると思ったが、

　い　っ　た　い　ど　こ　で　だ　れ　が　騒　い　で　た　ん　だ　？

で、今回の話でNWSOSがどこか改善されたの？

>>228
あなたは某氏ですか？

ROM 　りーどおんりー（<--ここ発音良く。）めもりー
はぁ。。。。
ROM 　りーどおんりー（<--ここ発音良く。）めもりー
はぁ。。。。
ROM 　りーどおんりー（<--ここ発音良く。）めもりー
はぁ。。。。
ROM 　りーどおんりー（<--ここ発音良く。）めもりー
はぁ。。。。
ROM 　りーどおんりー（<--ここ発音良く。）めもりー
はぁ。。。。

>>初期化応答をしていれば、最低、起動時間はlinux程度にはかかる筈。
いちいち一つのデバイスに対して、結果が返ってくるまでCPUをポーリング
させているlinuxが時代遅れなだけ。Win95並。
WinXPでは、可能な組み合わせに関しては、同時に初期化問い合わせコードを実行、
初期化の段階からして複数のスレッドでチェックを行っている。
例えばモデムの初期化なんかは、結果が返却されるまでに２〜３秒ほどかかるのが
普通で、linuxなんかは、そこでじーっと２〜３秒ポーリングするのだけど、
WinXPは、別のデバイスで並列で初期化可能なものは、並列で発行させてしまう。

Ether,AGP(PCI),モデム,USB(接続されていれば、そのデバイスの初期化）など
全て別スレッドを立てて初期化を行っている。

WinXPといわず、実はWinNTのsp6を充てると起動時がマルチプロセスになって
根本的な高速化が行われてる。

>228
高級言語では改善しやすい != 低級言語では改善しにくい

>230
とりあえず文字列表示は速くしたらしいな。

Ｋさんが普段使っているＯＳはWindowsですか？linuxですか？
アプリケーションは主に何を使ってますか？

自分は、OSはWindowsで、主に使うアプリケーションは
IE、VC++コンパイラ、DOS窓、grep、秀丸、WORD、EXCEL、
HTMLエディタ、DVDプレイヤー、mp3エンコーダー、mp3プレイヤ

でした。DOS窓がアプリに入るか？といえば無理がありますが、カーネル開発から
見ればDOS窓のようなシェル環境もアプリと見なせるので、敢えて列挙しました。

ROM 　りーどおんりー（<--ここ発音良く。）めもりー
はぁ。。。。
ROM 　りーどおんりー（<--ここ発音良く。）めもりー
はぁ。。。。
ROM 　りーどおんりー（<--ここ発音良く。）めもりー
はぁ。。。。
ROM 　りーどおんりー（<--ここ発音良く。）めもりー
はぁ。。。。
ROM 　りーどおんりー（<--ここ発音良く。）めもりー
はぁ。。。。

236 ：Be名無しさん ：03/02/02 09:50
ROM 　りーどおんりー（<--ここ発音良く。）めもりー
はぁ。。。。
ROM 　りーどおんりー（<--ここ発音良く。）めもりー
はぁ。。。。
ROM 　りーどおんりー（<--ここ発音良く。）めもりー
はぁ。。。。
ROM 　りーどおんりー（<--ここ発音良く。）めもりー
はぁ。。。。
ROM 　りーどおんりー（<--ここ発音良く。）めもりー
はぁ。。。。

うちのFAはソフトウェアディップスイッチのくせに
ハードウェアディップスイッチがいくつかありますが何か?
うちのFAはソフトウェアディップスイッチのくせに
ハードウェアディップスイッチがいくつかありますが何か?
うちのFAはソフトウェアディップスイッチのくせに
ハードウェアディップスイッチがいくつかありますが何か?
うちのFAはソフトウェアディップスイッチのくせに
ハードウェアディップスイッチがいくつかありますが何か?

>>236-238
わかったから静かにしてれ

174 ：ひろゆき＠暫定管理人 ★：03/01/31 23:29 ID:???
最近、Web現代っつーサイトでゲームのレビューしてるひろゆきです。
なんか本職よりこっちのほうがおもしれーなぁ、なんて思っちゃう今日この頃です。。。

さてさて、本題に入りますが。
今春２ちゃんねる閉鎖しますです。
いろいろ外部からの圧力があったり、、、
マスコミ等のメディアが五月蝿かったりで。。。
最近は裁判でも負けまくりだし。。。
ぶっちゃけた話、疲れたってことです。。。
詳しいことについては、メルマガやら電２やらで公開すると思います。

んじゃ！

-----------------------
↑4月までに2chも終了するらしいので、OSASKも2ch風BBSを作るのらー。

>>239
まぁまぁ、荒らしは放置でﾏﾀｰﾘと。
っていうか、いちいち反応すんな、ネット初心者。

>240
激しくネタの予感！
1/31に書かれて何の騒ぎもないわけがないと思われ。

>>241
釣られすぎ。放置でﾏﾀｰﾘと。

ネタって。
やれやれ、これだから過疎板の住人は（以下略）

つーか2chのメルマガ入ってる人がこの板にはいないってことだね。
ま、Ｋくんからして、linuxすら知らない疎い人っぽいしな。
お似合いだよ

（ ´_ゝ｀）ﾌｰﾝ

起動時スクリプト実行可 age

だけど、実際のとこ、ひろゆきって裁判所に
どれくらい絞られてるの？数百万単位だよな？

それとも、裁判所の判決の結果で、今後もガシガシ訴訟が起きることを
危惧して閉鎖することにしたのだろうか？

ここはひどい釣り堀のインターネットですね。

子供生んだあとの椎名林檎って妙に色っぽくない？特にあの着物ＰＶ。
あれも林檎本人が2chを意識したらしーよ。
2ch自意識過剰なのはKﾀﾝとタメ張るくらいだとか。

2chが消えて一番得するのは、自意識過剰から解放される
KﾀﾝやLﾀﾝみたいな人種とみたがどうよ？

ここはひどい日本語のインターネットですね。

とりあえず自分の意見が普通にスルーされて悔しいからって荒らすのはやめれ。
見苦しいから。

> http://pc.2ch.net/test/read.cgi/os/1039075591/637

狙ってたとしても狙ってなかったとしても、
OSASKとNWSOSの組みかたの違いというのがはっきりとわかる話だな。
NWSOSはレンガを積んで隙間を最初っから作らないようにするのに対して、
OSASKは隙間を気にせず丈夫な骨組みだけを作るようにしてるわけだ。




と、ネタを提供してみるテスト。

でさあ、折角の多色対応なのに対応アプリが全然でてこないのは何故？
新規でも開発環境が整備されて色々落とす必要とか無くなったみたいだけど、
なにか足りないものとか問題があるのだろうか？
それとも単に時期的にみんな忙しいのかな？

そういえば非定型とか半透明の窓も見てみたいな。
あとタイトル長とか仕様外の旧版アプリとかを起動しようとすると
例外で落とすようになってるけど、今は回復手段がないので
そろそろエラートラップなんとかしてほしいかも？

>>251
NWSOS: とりあえず動くものを作ってから細部を改善していくやり方。
OSASK: 初めから寸分の狂いもなく完璧なものを積み上げていくやり方。

のような印象を持ってますた

>>252
> でさあ、折角の多色対応なのに対応アプリが全然でてこないのは何故？

今の所、VRAM直アクセスしかできないからじゃないか?
文字表示とか線描画とかもできるようになれば、いろいろ出てくるかも。

>251
そういう面もあるかと。
今回の話でも、NWSOSは速度という「細部」を後から改善してるわけで。
OSASKも、8dot整列制限の速さというものがOSASKの目指した速さだと考えたら
確かにそうなる。
でも長期的には>251のような位置づけになるんじゃないか？
NWSOSがどういうつもりで開発してるのか今一つわからいけど、OSASK相対で言えば。
OSASKはそもそも「エセ」だし（ｗ


ところでおまいら、どれぐらいのPCが低スペックだと思いますか？
漏れはLﾀﾝがPen233だとか言い出したのでﾋﾞｸｰﾘしたクチ。

>255
> 漏れはLﾀﾝがPen233だとか言い出したのでﾋﾞｸｰﾘしたクチ。

ああ、もちろんPen233が低スペックだということに異論はないけど、
NWSOSの程度から考えたらﾋﾞｸｰﾘした、ということ。
もちろんもちろん、今後どうするつもりか知らんから
NWSOSは重いんでダメだとか言う気はないよ。
みんなが適正だと考えるスペックはどんなものかな、と。

Lib50のPen95かな

123◆mXrBwDDzyw はおまぬけにもトリップをさらしてしまいました。
そこでトリップを変えまつのでお知らせします。

（　´∀｀）。。。。（すっかり雑談スレになってしまった・・・）

ボクもとりっぷ漏れちゃったょぅヽ(｀ー´)人(｀皿´)ノ

>>259
自爆じゃなかったの？

>Ｋはこのハードウェアの仕様を分かってて高速な手法をわざわざ選んで実装した
>API仕様の優位性

「OS」はそもそもhardwareを「抽象化」するものだが、
OSASKは「分割」するものと考えた方がいい。(悪く言えばmultitask monitor)

>>229
＜後ろ頭＞y-~~
高級言語=移植性に富むという点でMONAに1票。
NWSOSはややassemblerの比率が大めか。

>>260
硬い事言うなょぅ。禿るょぅ ヽ(｀ー´)ノシ(つД｀)

1 2 3 必 死 だ な

そもそも、プレーン方式など捨てる！というのがOS設計者のあるべき
コスト感覚だと思う。
そうすれば「8dot単位であれば効率が良い」などという場面もなくなり、
一つのコードで、最適な解を、最短手順で達成できる。

でも、おそらくＫ氏はこのカキコの一行目の前提を受け付けられない性格。
個人的に乱暴なこと言えば、「FM-TOWNSやPC-98への対応など捨ててしまえば」
というのが感想なんだけどね。ま、あくまでも感想であって、Ｋ氏への要望とか
そういうんではないので、聞き流す程度で読んでね。
でもね、その手のエミュレータも出てるような過去ハードは本当に捨てても
良いよ思うよ。だって、過去のソフト動かすにしても、現在、そこらへんで売ってる
安いハードでエミュったほうが、実機よりも速く動作するんだしさ。

（過去のハード捨てる）!=（過去のソフトも捨てる）

もちろん、ここでいうエミュってのはOSASK上で動作するエミュっていう意味ね。

VGAの選択こそまさにコスト的な物だと思われ。
あるべき姿と実際は違う・・・
あるべき姿というのなら個別にドライバ書くべきだろう。
VESAは切り捨てすぎる。

「8dot単位であれば（開発）効率がいい」というのが前提かと。

うちのFAはソフトウェアディップスイッチのくせに
ハードウェアディップスイッチがいくつかありますが何か?

239 ：Be名無しさん ：03/02/02 17:17
>>236-238
わかったから静かにしてれ

----------------------------------------
↑いったい、なんの抗争？

>>264
というか、安物買う位ならホコリかぶって捨ててある高かったハードで遊びたいなあ。
軽いソフトでも、今から普通につくられるものをそのまま動かすには現役のOSが必要だし。
まあlinuxとかもある訳だけど、システム更新して追従するのは、マイナー構成だと
自分でOS作ってるようなもので大変じゃないかな。で金太郎飴ばかりもてはやされると。

要は今のソフトが動かないから性能はどうであれ捨てられるんだよね。
昔のソフト動かすならエミュでいいんだが、ハード的に退化してしまって
完全には無理な部分とか、ロストテクノロジーが意外とあるような気がするなあ。
負け組ハードの宿命なのかもしれないけど、葬り去るには惜しい技術をそこから
発掘するのも無駄ではないと思うし、意外とそういうところから画期的な解が
見つかったりするかも？

＞昔のソフト動かすならエミュでいいんだが、ハード的に退化してしまって
＞完全には無理な部分とか、ロストテクノロジーが意外とあるような気がするなあ。
そのロスとテクノロジーって具体的にはどこ？エミュじゃ無理な部分ってある？

＞というか、安物買う位ならホコリかぶって捨ててある高かったハードで遊びたいなあ。
そういう遊び方もあるけど、たったそれだけの理由で、最新のビデオカードで
すら、8ピクセル単位でしかWindowの位置やサイズが指定できないAPI仕様に
なっている現状ってどう？

古いハードは捨てちまえという考えが基本。
モノは大切にすべきだが、大切にするのはソフトだけで十分。
MSXだって、エミュでいろんなソフトが甦ってる。ハードなしでね。

外国でも頑張ってるみたいよ
http://slashdot.jp/article.pl?sid=03/02/03/221257&topic=1&mode=thread&threshold=-1

>>262
(；´-`)つるつる（謎

>>271
ボクのお知り合いさんな気がするょぅ。うどん好きかょぅ？

>>272
うどんより女が好き

>>273
えうー。じゃあ別人さん？(；´Д｀)

>>274
そもそも271コピペだし（ｗ
http://pc.2ch.net/test/read.cgi/os/1039237412/215

ﾓｳｺﾈｰｮｩヽ(｀д´)ノ

>>276
禿げるって言ったの自分じゃんかよ〜

「OSASK」を見る度に「大阪」と読んでしまう。

>>269
なんか言ってる事矛盾してない？
エミュでなんとかするならハードに由来する制限などなくなる訳で
おまえが持っているハードの事情なんて関係ないというなら
それでいいんじゃない？そんなのエミュれば動くんだからね。
だけど、それを切り捨てろっていうのはそのエミュをやめろって事じゃない？

今はそんなエミュ機能がほとんど出来てないから、ハードの制限がほぼそのまま
というだけの話じゃないの？>>266も言うように動作範囲の広いVGAを優先しただけ？
でも今回追加されたVESAのフルカラーモードだとそういう制限はないという話だけど、
どうなの？　それだと何か作ってくれるのかな？

要するにハードを考慮して書けば速いよって話で、別にそうでなくても究極的には
エミュがインテリジェントにそこまで最適化をやってくれれば、オリジナルより
速く実行できるなんてものもあるかもしれない。でも予めハードを意識して
機能を最大限使っているようなものはまず無理だと思うね。
だからそれを制約があるハードでエミュるには代償がそれなりに必要。
そういう場合にこそ速さでなんとかなるものは力業で何とかなるだろうね。
だから捨てちゃえという話はあるけど、問題はそれで補えない部分。
積んでないデバイスとかはそれこそ代替で我慢するしかないし、その場合
たとえば精度とかノイズとかは、まず全く同じには出来ないでしょう？

まあ用途によっては取るに足らない制限かもしれない。
ただ、たとえばプロテクトなんてのはそういう違いを突いて成り立つものが
ある訳で、そういう場合はお手上げなんじゃないかな？
…それにしてもなんでこんなにうちの互換機の時計狂うんだろうなあ？

というわけで、完璧なエミュなんてものを知っているなら教えて欲しいな。

まあ餅血

みんないろいろ思惑持ってるけど、やっぱ過去ハードは捨てるべきかと。
本当に意味がない。

1GHzのマシンでOSASKを動かし、その上で、過去ハードであるPC-98やFM-TOWNSの
エミュを動かせばいーじゃん。実機よりも高速な上、FM-TOWNS上の使い慣れた
テキストエディタなどのソフトも、さらに快適に動作。

279のエミュでカバーできない部分って微々たるもんだし、その微々たる部分は
実機で使えばいい。何もOSASKをその微々たるもののために、カバーする必要もなしかと。

OSASKが走るターゲットとして、過去ハードを捨てても構わないかと。
だって、その過去ハードのエミュがOSASK上で動けばいいんだし。

このあたり、Ｋ氏本人、自分の唱えたOSASKの大きなメリットを
自ら見落としてるんじゃない？

うーん。なんか違うな。
少なくとも8ドットのは
過去のハードを動かすためにやってるんじゃなくて、
過去のハードで動かすためにやってるわけだろう？
微妙な違いかも知れんけど。

利点はあるわけよ。
遊んでる98/Townsの多さとか、
1GHzマシン上のOSASKで（将来的に）エミュがヴいヴい動きますよ便利ですよ、と言うのと
死に掛けていたハードウェアででもOSASKがヴいヴい動いていますよ軽いですよ、
と言うのとの説得力の違いとか。
それに比べれば、（一時的な）8ドット制限なんて・・・ということにならんかな？

>>281
エミュで殆どカバーできるという主張はいいけど
しかし、だとすれば捨てろという主張は結論ありきで、説得力がないよ。

速さで10秒が1秒になるのは大きいけど、1秒が0.1秒になるのなんて微々たる事じゃん
エミュでカバーできない部分って微々たるもんだし、その微々たる部分は
最新ハードで使えばいい。何も思い入れのあるハードをその微々たるものの
ために、捨てる必要もなしかと。

…でまあ現状はそんな微々たるものの為にOSのサポートが打ち切られて
ソフトが動かず、それが大きな障害になってどんどん捨てられている訳だが。

だから捨てて欲しければ、どうやっても最新ハードでしか1秒では動かないような
キラーソフトを、そうしたい人がどんどん（OSASKで）動くようにすればいいんじゃ
ないの？

それでも、それが使えるなら10秒掛かってもいいなんて酔狂な人は居るだろうけど、
それをサポートするのに特別の手間がかかるの？それじゃエミュOSって意味がないね
だって、どうせまた新しいハードがでてきたら以前のそれをエミュらなきゃ
いけないんだよ？だったらそれを前倒ししたっていいじゃん、手間なら別だけど。
まあ手間を掛けるならソフト側の修正とかで制限つきなら３秒になったりするかもね。

現ハードを前提にしたソフトは新ハードでは動かなくていいと言うならあれだけど、
それは過去ハードを前提にしたソフトは現ハードでは動かなくていいということで
エミュ否定ってことだね。

エミュレータOSを目指すといいますが、
そのOSASK上で動作するエミュを作る労力は、
普通にエミュを作るのと大して変わらないと思う。
この調子だと、現在の代表的なOSに対応する頃には、そのOSは時代遅れでしかも
IA32の時代は終わっていて、根本からOSASKを作り直す必要が出てくると思う。

また、レガシーハードを活用したければ、それ相応の枯れたOSを使うだけで十分だと思う。
それがそのマシンの能力なのだから。

ただ極限に小さく速いOSを作るという技術的な面白さには惹かれるので、
実用には遠いコンセプトだと思うけど、期待しています。

うーむ。
ﾁｮﾄぐぐってみたらOSASKをエミュレータOSとして紹介してるヤシ多すぎるぞ(ﾟДﾟ)ｺﾞﾙｧ

>284
とりあえず
http://www.imasy.or.jp/~kawai/osask/boyaki12.htmlを嫁

>>285
エミュレータ専用OSではない事はわかります。
とはいえ、
http://www.imasy.or.jp/~kawai/osask/osask_qa.html
にて
Ｑ：既存のOSとそっくりになるんですか。では、ソフトも使えるのですか？
Ａ：使えます。エミュレーションという機能があり、
その機能のおかげで今までのソフトウェア資産が生かせます。
Windowsそっくりな画面で操作しているときにWindowsのソフトが使えるのは当然として、
Linuxのソフト や、MacOSのソフトも使えるでしょう。

とOSASKでは各種エミュレーションが実現する事を前提としているようですし、
分かりやすくエミュレータOSでも良いのではないでしょうか？

>一言
「エミュが揃ってるOS」と言うのは「マルチタスクのOS」と言って
紹介するぐらいのひどい紹介だと思われ・・・
「エミュが作りやすいOS」とか言うのなら実際はどう（するつもり）なのかは
ともかく、紹介としてはいいだろうけど。

で、多いと書いたけど実際にはそんなにないかな？
しかし、例えば
> エミュレータを実行しやすいOSとして開発中の、複数の他OS用アプリを動作させるベースとなるOSASK OS
や
> Windowsやlinuxの実行ファイルを動かしてしまおうというエミュレーターOSです。
なんてのは明らかにニュアンスが違う気がするんだが。

「エミュレータOS」がエミュレータのため（だけ）のOSじゃないというのはわかってるけど、
どうしてもそういうOSを連想してしまう・・・スマソ。


>286
それはどちらかと言えばエミュ全般の話では？
OSASK自体はそれを互換のために前提としてはいるけど、
実際にはネイティブアプリをできるだけメインに考えてるはずだし。

でも、IPAの審査員の方にも「レガシーハード対応などの後ろ向きな姿勢」という
旨を指摘されたんですよね？

これに関しては、どう思います。

>>287
理念から行くとそうなんですけど、一般の人からみたら
エミュレータが一番期待するところでしょうから、
そう紹介されるのも無理はないと思います。
どんなに内部アーキテクチャが優れていても、世の中が求めるのは
どれだけ優れたアプリが動くか、という点に集約されますし。
＃世の中は関係ないですか？

＞実際にはネイティブアプリをできるだけメインに考えてるはずだし。
最終的にはそうですが、WindowsがDOSエミュにこだわったように、
OSASKも最初は既存のアプリの動作が絶対条件だと思います。
正直、ネイティブアプリだけでOSASKが他OSと比べて魅力的になるのは、
現時点では何年かかっても不可能のように思います。

とはいえ、エミュがなくてもFDから起動して5秒でブラウジングができれば、
限定されますけど、かなり魅力かも(笑)。
ただ、OSよりもまともで軽いブラウザを作る方が大変そう。。。

>287
スマソ、185じゃなくて285だった・・・

>288
そもそもIPAはOSASKにあまり独自性を見出していないという罠

>289
エミュが求められるのはわかるけど、
それだけを求めるとOSASKである必要性がなくならないか？と。
軽くて速い「エミュOS」と言うのなら、それは確かによさげだけど、
単にエミュが標準でたくさんあるような「エミュOS」と言うのなら
逆にOSASKを貶めているような気さえする。

> 正直、ネイティブアプリだけでOSASKが他OSと比べて魅力的になるのは、
> 現時点では何年かかっても不可能のように思います。
エミュでそれができるということはネイティブでも
どうにかすればできるということだから、何年とまではいかないかと。
エミュを作ってる間においしいアプリだけ持ってこれるわけで。。。
まあ「数」という魅力を補うにはエミュが最短経路だろうけど。

FM-TOWNSのキーボードの親指シフトの問題点を、実機で使う上での
メリットとして挙げてるけど、そんなキーボード、Windowsだったら使えるじゃん。
当然、PC/ATとして使える筈。

http://www.oyayubi-user.gr.jp/product.htm
↑USB接続で今も販売は続行されてるし。っていうか、うちの職場にも
一人だけ親指シフト・キーボードを問題なく使い続けてる人もいるよ。

レガシーハード実機を使う理由にはならないよ。

実機よりもエミュのほうが高速に動作し、実機ならではのテクノロジー・メリットが
ないのならば、「エミュ万能」でいいんでない？
いくら既存の旧型機といっても、24時間常時使ってると毎月\4000のコストかかるし、
特に10年くらい前のマシンって今の最新型のPC/ATに比較するとさらに倍くらいの
電力を消費するものがあるしね。
CPU遅くても、電力食ってランニングコストも馬鹿にならないんで、
CPU速いPC/ATを買ったほうがいいよ。
FM-TOWNSのソフト使いたいときも、いまどきのハードなら３個、４個の仮想TOWNS
くらい朝メシ前だし。

だったら、OSASKもレガシー捨てて現行ハード重視戦略でいいんでない？
8dot単位どうのこうの言ってる場合じゃないかと。

>>291
ひそかに感動。


#ところで、マウススピードが速くなったらしいが、Canvasで絵をかくと
#カクカクした感じになると気づいたのは俺だけ？

＞#ところで、マウススピードが速くなったらしいが、Canvasで絵をかくと
＞#カクカクした感じになると気づいたのは俺だけ？
マウスの速度をアップさせても繊細な動きが可能なのはWindowsの特権。
linuxにせよFreeBSDにせよ、X86FreeなどのGUIでマウスの速度上げると
やはりカクカクしてしまう。

原理的にOSに依存することなく可能な筈なんだが、なぜWindowsだけ
マウスカーソルが繊細なのかは原因は不明。ま、ソフト的な問題なのは
間違いないのだけどね。

Townsや98といった死にかけのレガシーハードで
OSASKを動かすというけど、
OSASKが完成する頃には完全にレガシーハードが死んで、
遺骨すら見つからない（特にTowns）罠。

フォントまわりはﾒｸﾞﾀｿが一番優れてるって事でFA？(｀ー´)

だんだん不毛な論議になってきましたが、気を取り直して。

>>290
言いたいのは、
*最初は*アプリを揃えるためにはエミュが重要ということです。

有用なソフトが多い
↓
使う人が多くなる
↓
ソフト開発者が増える
↓
さらにソフトが増える

の循環があってはじめてネイティブアプリが自然に生まれると思うのです。

おいしいアプリを１つ２つ持ってきても、
その開発者たちだけの内輪コミュニティで終わるのでは？

結局>>284に戻るのですが、そのOSASKの成功に不可欠と思われる
エミュはできるのかなあ？と。
またWindowsのエミュにしてもNative API(NT)レベルかその上のKERNEL32等のレベルなのか等
で全く性質が変わると思いますし。
私もよく分かっていませんが、そのあたりどうなるか興味があります。

>>294
Winはドライバが面倒見ているので、ついてくるのです。
XFree86はアプリケーションで面倒見ているので、制御が回って来ない限り、
マウスの処理ができません。
もすこしなんとかしてもらいたい所ではあるが…

とりあえずWinのドライバ・エミュレーション機能は早く欲しいです。
（まだそれを言うには早すぎるのかも知れませんけど）
今はグラフィック周りでVESAを使うくらいなのでよいでしょうが
これから様々なハードウェアを動かすようになると、
全てをネイティブなドライバでカバーするのは不可能ですし、
ヘタをするとOSASKのためにハードを買うハメになります。
これでは従来のハードを生かすどころの話ではありません。

エミュレーションにおけるオーバーヘッドは昨今のハードウェアの
性能を考えると現実的なレベルに抑えられるのではないかと考えますが、
そもそもドライバのインストールにもWin自体のエミュレーションが必要そう
なので難しいかな…

>>PC-9821やAT互換機系は後になってパックドピクセルの良さを分かって
>>あせって標準に採用したようなものです。
話、それるけど
PC/AT が、パックドピクセルを標準VGAとして策定、発売されたのが'87です。
FM−TOWNSよりも前。
ただ、解像度が320x200までというきつい制限があったけどね。


>>それで、なんでレガシー「でも」動くという方針にそこまでして反対なのですか？
多分、レガシーを意識すると、32BitColor対応だとかが困難になるからでは？
例えば、32BitカラーOSASKアプリケーションを、8Bitカラーしかサポート
されてないハードで実行するとどうなるの？

OSASK/AT version 3.3, 公開

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

>>300
OFFではタイリングされて結構きれいに見えてたよ。

Windows板がアラビア文字みたいになっちゃてるけど
もしかして、俺だけ?

http://www.agemasukudasai.com/bloom/

>300
> 例えば、32BitカラーOSASKアプリケーションを、8Bitカラーしかサポート
> されてないハードで実行するとどうなるの？

おまいさんは今までどんなOS使ってのかと。


>303
うん。

川合さんの性格が、以前は聖者のようだったのが、最近は普通の人間になった気がする。
いや、今のが普通で、むしろ前がありえないくらいにいい人すぎたんだけど、
2chでいろいろ言われてだんだんいらいらしてきてるのかもしれない。

だんだん知名度が増してきて要望とか言う人は増えてきたんだけど、
自分で「やってみよう」って、はじめの一歩を踏み出す人が少ないのも
彼に失望を感じさせてるんじゃないかって気がするな。

で、とりあえず私も第一歩を踏み出そうとドキュメント読んでます。

>「はじめの一歩」を踏み出す人が少ないのも
では私も踏み出しますか。。。

// 川合堂-1
//

OsaskMain(){}

// 　川合堂-1
// 　first.h

#define OsaskMain main

//　　川合堂-1
// first.c

#include "first.h"

OsaskMain(){}

>>307-309

これ使え
http://www.imasy.or.jp/~kawai/osask/developers.html#tolset04

>>308

mainだと、CRT0呼びに行くからダメなんだよ
名前はなんでもいいけど、適当に変えないとダメ

>>310

introa11が正解だってさ

> mainだと、CRT0呼びに行くからダメなんだよ
>名前はなんでもいいけど、適当に変えないとダメ

>>307-309 はCygwin標準のコンパイラしかなかったので、なんとなく
やっただけ。

introa11入手してみた。cc1もmakeもその他必要なツール全部入って
いたよ。

// 川合堂ライセンス-01
// ahe.c

#include <guigui00.h>

#define AUTO_MALLOC 0

void OsaskMain()
{
　　　　struct LIB_WINDOW *window;
　　　　struct LIB_TEXTBOX *wintitle, *textbox;
　　　　int i;

　　　　lib_init(AUTO_MALLOC);
　　　　window = lib_openwindow(AUTO_MALLOC, 0x0200, 600, 400);
　　　　textbox = lib_opentextbox(0x0000, AUTO_MALLOC, 0, 12, 1, 16, 16,
　　　　　　　　window, 0x00c0, 0);
　　　　for (i = 0; i < 30; i++) {
　　　　　　　　lib_putstring_ASCII(0x0000, 0, 0, textbox, 0, 0, "ahe\n");
　　　　}
　　　　lib_waitsignal(0x0001, 0, 0);
}
====================

makeできて動いたが、想定とは違う表示になった。
もっと精進せねば。。。

>>313がんがれ

>だんだん知名度が増してきて要望とか言う人は増えてきたんだけど、
>自分で「やってみよう」って、はじめの一歩を踏み出す人が少ないのも
>彼に失望を感じさせてるんじゃないかって気がするな。
当たり前じゃん。ユーザーレベルな意見なんだから。
なんで自分で「やってみよう」でなければならんのよ。
っていうか、OSに対する要望を自分で実現しなければならないのなら、
そのOSを購入する理由がないじゃん。

OSASKの体験版をinstallしてみて、気に入ったら、きちんと金は払うから
ユーザーは要望をガンガン出すべきでしょ。

つまりは、お客とメーカーの関係。

ただ、川合氏はOSASKで商売する気はないらしい。自分が住むためのOSを
作っており、他人にとやかく言われるモノに関しては、自分と合致したもののみ
受け付けるという姿勢。

OSASKはオープンソース。
だから自分の不満点をAddOnできるのが、特徴。
でも、オープンソースというのは、その性質上、一点に集中する傾向があり
またそのほうが効率的でもある。その端的な例がlinux。
どうせ不満な点があるのだったら、linuxに追加してしまったほうがなにかと都合が良い。

川合氏の挙げるOSASKに関する予定項目は、どれもこれもlinuxで既に実装されソースまで
公開されてるテクノロジーのみである。なぜならば、linuxもまた、実質的には
メモリレス・アーキテクチャなのだから。

（私感であり、敬語などは略↓）

32BitColorにすると、たちまちラインだとかが描画できないのであれば、
それは32BitColorに対応したとは言えない。
むしろOSとしての設計の線形性の欠如を露呈している。

したがって、OSASKが32BitColorに対応するには、誰かがそれなりの労力を必要とする。
これは、過去のハード（も）サポートしているというより、
過去のハードをサポートするあまり、現行のハードの性能の全てを発揮、引き出せずにいるという
弊害を出している。

過去ハードのサポートは、ノーリスクではなく、
また現行ハードの豊富なリソースをスポイルしてしまう可能性もある。

過去ハードのサポートの切捨ては、現行ハードの能力を存分に引き出すことを
続伸し、結果的には、エミュレータとしての性能も高めることができ、過去のソフトを
過去の環境以上の状態で復刻、利用することができる。

（同じく私感であり、敬語などは略↓）

8BitColorしかない環境では、15BitColorを保持していたFM-TOWNSなどの
ソフトはエミュレータをもってしても再現は一部不可能である。
一方、8年くらい昔のレガシーハードでも大抵は32BitColorの物理デバイスを持っている。

***仮にWindowsのようにレガシーハードを積極的にサポートするとしても***

仮に8BitColorをサポートするとしても、Windowsのように内部での取り扱いは
あくまでも32BitColorとして取り扱い、DIBの時点で8BitColorもしくは4BitColorへ
OSが適切に減色する設計が望ましかったのではないだろうか？

こうすることによって、32BitColorのライン、図形描画ルーチンを一種類だけ
用意するだけで、8BitColor物理デバイスへの減色によるレガシーハード・サポートが
可能だった筈。

レガシーハードをサポートするにも、OSASKの設計方法は、Windowsのそれに比較して
あまりにも計画性、直交性が低すぎ、またOS開発者、アプリ開発者、両者へ負担を強いる。

>315-316
今更何を言ってるのかと。
じゃあなんでお前ここに居るのかと。

>318
8ビットカラーでのTownsエミュって何のこっちゃ？
「エミュの限界」の話？
設計はポリシーの問題だろうから、まあ正しくもあるツッコミだと思うけど。
しかし激しくうらやましい8年前の環境ですね。

突然質問スミマセン

　OSASKの遅延書込み(月に一度だけ、ディスクを入れて、、等)
ってどんな「しくみ」になってるの？

　(1)内部CVS？　みたいなしくみ？
　(2)手順型パラメトリックＣＡＤ*1 みたいなしくみ？
　(3)どっちでもない、全然想像外のものかなあ？

　広い意味では(1)(2)どっちでもフル・ジャーナリングということですが、、

質問自体、見当外れだったら、再度スミマセン

*1 参考　http://www.cim.pe.u-tokyo.ac.jp/~suzuki/papers/gakujutsu99.pdfの
２．２　パラメトリックス・フィーチャーモデリング機構

>> 317-318
レガシィハードを捨てろって話かな？
しかし、書いてる事が間違ってるぞ？

> 32BitColorのライン、図形描画ルーチンを一種類だけ用意するだけで
その辺置いておいても、この設計はまずいのでは？
32Bit しかサポートしないのでは酷すぎる。

>>1
http://homepage3.nifty.com/digikei/
全部無料だよ

欲しいものは自分でプロジェクト作ってやってって言うけど
OSASKでインターネットを数ヶ月後には、
簡単で良いからWebサーフィンしたいと思ったらで出来るのかな？

必要なものは
「ネットワーク接続プログラム」　　　　→　さっぱりだけど今のOSASKで作れるかな？
「ドライバ（LAN、Modem）」、
「driverを読み込むためのシステム」　→　今はないから直接ハードアクセス？
そしてブラウザソフト

確かに作り始めれば、何が必要で何が足りないか分かって来そうではあるけど
明らかに、Windowsなんかと比べると対応ライブラリが少なすぎますね。
もちろん、多く対応していれば作る、作れるとは限らないですよね。

OSASKがOSとして、どこまで対応してくれるのか　→　川合さんが。
大まかに細かく示してくれると、もっと良く分かりやすくなるんだけど。
（開発スピードが早いだけが良いってものでもないんだけど、遅いよりは早い方がいい訳だし）
もちろん、川合さん自身がこういうの欲しいんだけど、っていうリストを上げてくれても良いではないかな？

// 川合堂ライセンス-01
// ahe.c ver2

#include <guigui00.h>

#define AUTO_MALLOC 0

void OsaskMain()
{
　　　　struct LIB_WINDOW *window;
　　　　struct LIB_TEXTBOX *textbox;
　　　　int i, width, height;

　　　　lib_init(AUTO_MALLOC);
　　　　window = lib_openwindow(AUTO_MALLOC, 0x0200, 600, 400);
　　　　textbox = lib_opentextbox(0x0000, AUTO_MALLOC, 0, 12, 1, 16, 16,
　　　　　　　　window, 0x00c0, 0);
　　　　width = height = 0;
　　　　for (i = 0; i < 20; i++) {
　　　　　　　　lib_putstring_ASCII(0x0000, width, height, textbox,
　　　　　　　　0, 0, "ahe");
　　　　　　　　width = width + 30;
　　　　　　　　height = height + 16;
　　　　　　　　lib_waitsignaltime(0x0007, 0, 0, 0, 1, 0);
　　　　}
}

addp03.lzhのosaskgoフォルダ内のファイルを全部２枚目のフロッ
ピーにコピー。MAKE0とMAKE1をhelloc4→aheに弛緩。osat33iのフ
ロッピーで起動、２枚目に入れ換えInsert。pokon33の内容が代わっ
たらOSASKGO.BINをEnter。入力待ちになったらmake0, 続いてmake1。
これでahe.binが出来た。しかし、OSASKGO.BINを閉じてahe.binを
実行すると

INT 0x0D General Protect
　　・
　　・
　　・

になる。止まる前に表示するのも想定とは違う。
lib_putstring_ASCII()の使い方が間違っているのか。

>>323
とりあえず標準Ｃライブラリを移植すれば。

>>325
念のために言っておくけど、
テキストボックス関連で指定する座標はキャラクタ単位だよ。
ドット単位じゃないよ。

>>326
ライブラリってguigui00.libってのがあるけど、
Ｃライブラリってどうやって作ればいいの？

ライブラリのようなプログラム作るのに基本となる部分は
サイズの鬼（川合さん）に作って頂いた方が良いかと思うんですが…。

>ですから実画面が32bitカラーモードでも、8bitカラーグラフィックボックスで済むならそっちを使った方が速いということは十分にありえます。
最近のハードでは全くありえません。

>つまり最新マシンもレガシーマシンもどっちも速くなります
最新マシンでは、例えばラインや図形ポリゴン描画は32BitColorに特化してるため
最初から32BitColorでラインを書いていれば、CPUの消費パワーは事実上ゼロです。
(#ハードがライン描画している間にCPUは別の仕事ができます）

ところが、8Bitをサポートしてしまうと、ハードで描画できない上に
色変換をCPUで処理せねばならず、足かせになります。

試しに、Windowsをsafeモードなり、4BitColorなりのモードで起動してみると
分かりますが、諸々の色変換がかかってしまうため、ブラウザなど起動すると
体感的にもたってきます。

テキストボックスの座標指定がキャラクタ単位って、
APIの設計能力を疑ってしまう仕様ですね（ﾌﾟ

アルファベットみたいに、文字幅可変な場合はどうする気ですか？（ﾌﾟﾌﾟ

川合氏は、OSASKの完成度が高まったら、商品として出荷する
予定はありますか？

>>332
もちろんGPUでも、人気があれば売れるから
そう言う話が企業から来たら、販売して欲しいし、川合氏にも印税入れて欲しい。
もちろん可愛い氏が会社として販売してもOKだと思う。

「それがぼくには楽しかったから」
全世界を巻き込んだOSASK革命の真実
って本も出して欲しい。

GPU?

GPU　→　×
GPL　→　○

I'm sorry.　(･人･）

osaskってエミューレータOSっていってるのにエミュレーションなんて
何もまだできないじゃん...
それを特徴として書くのはどうなんでしょう？

Wineがどれだけの労力と時間をかけてここまで到達ができたかを
考えれば、Windowsエミュレーションだけでも5年以上先なんでは（というか存続してる？

>>336
OSASK計画は5年前から存在してるんで（今とはまったく別物だけど）、
5年後に存在していてもまったくおかしくはないと思う。

>336
将来的にエミュレートするという目標と
エミュレータOSという性格を書くのがダメだと？

>一言
>　ご自分の無知をそれほどお笑いになる事はありませんよ。
激しくﾜﾗﾀ ﾜﾙ(･∀･)ｲｲ!

しかし、>>318の
Windowsのように内部での取り扱いは
> あくまでも32BitColorとして取り扱い、DIBの時点で8BitColorもしくは4BitColorへ
> OSが適切に減色する設計が望ましかったのではないだろうか？
ってのはWindowsのカーネル内部での扱い、という意味だと思われ。
8ビットカラーでのAPIアクセスでも
Windowsはそれを32ビットカラーに変換して取り扱う、という意味かと。
たぶん勘違いしてるような・・・

しかし、そうだとすると道理でメモリ食うわけだ・・・

> >>325
>念のために言っておくけど、
>テキストボックス関連で指定する座標はキャラクタ単位だよ。
>ドット単位じゃないよ。

も、もちろんボケただけさ、知ってたさ。

>>328

関数を作って、
cc -c abc.c
とコンパイルだけしてabc.oを作り
ar rc libabc.a abc.o
ranlib libabc.a
とする。arのオプションはrc以外にもcqかruかその他かもしれない。
必要に応じて定数やプロトタイプ宣言もヘッダにする。

これはCygwinとかのUNIX系の場合。OSASKの場合はわからない。
*.a→*.lib、*.o→*.objか。他にもコマンド名が違うと思われ。

Makefileのguigui.libを組み立てている箇所を読むべし。

// 川合堂ライセンス-01
// ahe.c ver3

#include <guigui00.h>

#define AUTO_MALLOC 0

void OsaskMain()
{
struct LIB_WINDOW *window;
struct LIB_TEXTBOX *textbox;
int i, width, height;

lib_init(AUTO_MALLOC);
window = lib_openwindow(AUTO_MALLOC, 0x0200, 600, 400);
textbox = lib_opentextbox(0x0000, AUTO_MALLOC, 0, 12, 1, 16, 16,
window, 0x00c0, 0);
width = height = 0;
for (i = 0; i < 20; i++) {
lib_putstring_ASCII(0x0000, width, height, textbox,
0, 0, "ahe");
width = width++;
height = height++;
lib_waitsignaltime(0x0007, 0, 0, 0, 1, 0);
}
}

上は字下げを全角スペースにするのを忘れた。。。。

このように書き換えたら想定どおりに表示するようになたよ！
２０個表示した所でINT 0x0D General Protectになるけど、
これは画面の大きさにあわせて制限すれば良いのかな。

331に誰も釣られないのが激しくﾜﾗﾀ。
あんまりかわいそうなので、漏れが釣られときます。
で、普通のテキストエディタって幅が一定だよね？

>>342
ソースとか出しすぎて、『うぜ〜』
といわれない程度に頑張れ、応援してるよ。

おれはプロポーショナルフォント環境のOSからノンプロポーショナル
フォント環境のOSに以降したので、そのほうが新しいと思っている。

>344

diff/patchで出せって事？

(´・ω・｀)http://homepage3.nifty.com/digikei/
なんだ？ここは

ソースを以下に貼り付けるのはどうでしょう

OsaskWiKi
ttp://remo.s10.xrea.com/osawiki/pukiwiki.php

'>' や ' ' が行頭につければ、崩れずにちゃんと表示
されるはずです（　´∀｀）

>>342
あとはテキストボックスの大きさかな？

ブラウザをある程度作った人がOSに機能を要求しなきゃ・・・って。
いまどきなら、OSメーカーがHTMLブラウザコンポーネントを提供すべき基礎的要素だろ。

ともあれ、この一ヶ月のOSASKの進捗実績ってどのURLに行けば見れるの？（IPAかな？それともそんなものないの？）

>>350
やー。なら、オマエが作れ。

ってのがオチです。
ただ、HTMLコンポーネントは利用されがちで、共有されることも分かりきってるので
OS設計者である川合氏が実装するのが、もっとも安全なのも確かだけどね

ところで、カーネルとしての性能はOSASKとlinuxどっちが上なの？

新たにコミュニティとして参加したい場合、OSASKへ参加する場合の
メリットをちょっと知りたくって。いくらボランティアとはいえ、個人的に
確保できる時間なんて限られてるしね。

個人的な選択肢は MONA,NWS-OS,LINUX,MEG,OSASK などなんだけどね。
遊ぶにも下調べが必要ってこと。

>>352
とりあえずインストールして遊んでみたら？
まず雰囲気が肌に合うかどうかもけっこう重要だし。

「ＯＳに該当機能がなければ、貴方がどうぞ作ってくれ」っておかしい。
ＯＳＡＳＫがサクサク動くという噂を聞きつけて、軽快なlynxライクなブラウザ
を期待して寄ってきた、プログラミング不能な一般ユーザーはどうする気？

あとね、自分の場合はプログラマーだけど、
例えば「高速道路を作りたいけど、コンクリートがない」てな場合に
じゃ「あなたがコンクリートを作ってください」はナシでしょ。
あと「貴方が高速道路を作り始めたらコンクリートの生産もこちらで考えます」
ってのも順序が逆かと。

やはり、OS側が提供すべきインフラは*先に*提供すべきかと。

そのインフラは実際に提供されても当分は誰からも使用されないかもしれない。
けど、そのインフラがあると聞きつけて何か作ろう、あるいは既に完成したものを
移植してみようという人が、将来的に現れるかもしれない。

>>354
まぁまぁまぁ。素直にWindowsで遊べや。
プログラミングを楽しむなら、Windowsでもlinuxでも同じこと。
macはプログラマー向けの環境がいまいちマイナーなのできついのだけど、
何もマイナーなOSで遊ばんでもいいだろ。

というか、さすがにK一人ではあれもこれもできんだろ（ｗ

>>354
そう思ってしまうあなたはきっとまだ対象ユーザではないんでしょう。
今のところ、(a)K氏の主張に共感して、かつ(b)OSに近い層までいじれる
プログラマ、というのが一番有力な(来て欲しい)ターゲットなんでは。
(現時点で、プログラミング不能な一般ユーザを対象にしているとは
誰も主張してないと思うが)

問題は、上記の(a)と(b)の積集合があまり大きくなさそうなところ
だが… まあ半分個人プロジェクトなんだし、まったりと進めれば
いいんじゃないかな。

sage間違えた…

>>348
の言うようにするのはイイと思うな
diff…ってんじゃなくて、あんまり汚すなってこと
活発化に繋がってイイとは思うんだけれども。

>354
ﾊｧ？
それはユーザの責任だろう。
プログラマはユーザの奴隷じゃねえ！
おまいさんはそんなユーザの言うことに何でも応えてるのか？

ってか、例えば農業でも始めようかと考えて畑を作ってるときに、
「高速道路を作りたい」なんて言われても協力できないだろう？
農協を作りたいのですが、と言われたら協力もするだろうけども。

それにあれを作れ、これを作れなんてのは結局インフラを作ってる最中である
現状に関する限り、優先順位を変えろっていうことだからな。
インフラも作らずにアプリばっかり作ってたのならそういう主張もありだと思うが・・・

361よ、気持ちは分かるが餅突け。釣られとるぞ。
大方、最近ここが活気づいてきたのを快く思わない誰かの仕業だろう。

川合氏に提案ですが、ぜひともOSASKのCVSのネット公開リポジトリを
よろしく願いたい。既にどなたかが、確か、リポジトリに公開した覚えが
ありますが、これって本家ではないんですよね？

本家はＣＶＳ公開しないらしいので。
こっちで我慢の事。

ttp://www.google.co.jp/search?q=OSASK+CVS&ie=UTF-8&oe=UTF-8&hl=ja&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=

http://minix-up.sourceforge.jp/cgi-bin/l.cgi/_OSASKtest09/osask/
↑ここがOSASKのCVSらしい。
というか、川合氏もこのリポジトリをワークにすればよいだけでは？
普通、毎日寝る前に、commit でしょ。

tapi0.ask の中の　TAPI_syscmd()の中で　eaxレジスタの中身を見て
switch-case分岐してるとこがあって、eaxレジスタとのif分岐が実に
15箇所も羅列しているとこがあるけど、これは、テーブルジャンプした
ほうが速度的に有利なのでは？
この関数はコマンド受信箇所なんで最適化する価値ありだと思うんだけど。

んー、Microsoftならこの手の分岐羅列は迷わずテーブル化してるんだけどね。
そんかわり、無駄なメモリ喰うけど。でもテーブル化しておけば
受信コマンドの種類が将来的に増加しても、コード速度劣化はゼロなんで
是非お勧めなんだがな。

それはASKAがswitch文使えないからだと、思うんだな。

>それはASKAがswitch文使えないからだと、思うんだな。
いや、それは違うな。シンボルテーブルを作るだけの問題なので、
C,C++,ASM,ASKAを問わない、人的レベルなスキルの問題。

VC++な場合、switch内のcaseの値を全て調べて、最小値と最大値が
0xfe以下の場合、局所ジャンプテーブルを自動生成し、call命令一発で
目的の場所へジャンプする最適化が行われていた。が、メモリ読み込みが
下手すると100cycle以上かかるケースもあるので、今ではひたすら cmp命令の
羅列。

486ならともかく、Pentiumなら、現状のOSASKのようにcmp命令羅列が速度的に
は勝利する。MicrosoftのVC++.netのカンファレンスでは、caseが30個以内で
あれば、cmp命令展開するらしく、本当に頻度の高いcaseはなるべく前方に
記述してくれという非公式アドバイスもあった。

どのCPUをターゲットにするかで最適化手段はまるで変わってくる。

つまり366はただの知ったかぶりということか？

どっちが間違っているとかではなく場合によって異なると>>368さんは言っている
テーブルアクセスのキャッシュミスのペナルティが高いにしても
条件分岐羅列は分岐予測ミスのペナルティが予測されるし
条件分岐羅列で命令数が増えればトレースキャッシュミスの確率も上がる可能性もあるし

コマンド番号が連続していればテーブル化が各CPUでバランスがいい気はするが
いずれにしろ実際に計測しないと意味無しだな。

こんばんは、再び登場。
ひととおり、OSASKのソースを大雑把に閲覧。
ASKAの癖はちょっとだけ強かったけど、コメントを頼りに把握。

はっきり言ってしまおう。
「APIにコマンド番号渡しにしてしまった時点から、
便宜性、最適化戦争でWindowsに負けている」

特にAPI呼び出しが頻繁なアプリでは、OSASKは永遠にWindowsに勝てない。
これは、368で示したテーブルか？cmp羅列か？という近視眼的な問題ではなく
大域的なOS設計の時点で、とんでもないミスを犯してしまっている。

Microsoft社のOS設計陣が15年前に犯してしまった、
同じミスを川合氏も犯してしまった。

その回答は・・・また明日。おやすみ。

>>371
コマンド列をキューに格納するので保護レベル変更回数を抑えられるというのは古いCPUでは有利では？
エラー時にキューを進めるコマンド等がないと真価を発揮し無そうだが

>371
明日かよ！気になるじゃねーか！ヽ(`Д´)ﾉ
というツッコミはともかく、
最適化と便宜性でOSASKのAPI呼び出しはWin32APIとは少なくとも同程度だと思うんだが。

といっても近眼視的な見方だと叱られそうだけど、
増える可能性のあるオーバーヘッドと言えばfarなcallおよびテーブルを参照する時間と、
データキャッシュの消費ぐらい。
テーブルの参照とデータキャッシュの消費はWindowsでもないわけではないし。
一方減る可能性のあるオーバーヘッドは>372とcallの回数減。
（最近のプロセッサだと相対的に特権レベル変更処理が軽くなっただけかと。）

便宜性ではWin32APIと同じように呼び出せるし、
APIをデータとして置いておくこともできる。。。。


というわけで明日を待ちます。(´・ω・`)

>>368
そうなんだ。知らなかった。昔に比べてCPUとメモリの速度の差が
拡がったって事？

ところで、そのジャンプテーブルの置き場って普通どこなの？
他のデータを置くのと同じ場所に置くのなら本当にメモリアクセスが発生して
ボトルネックになりそうなのは分かる。でも、分岐が行われるコードの
すぐ近くに配置しておけば、キャッシュが効いて100cycleかかるなんてこと
なさそうだけど、どうなの？

>>つまり366はただの知ったかぶりということか？
ま、OSASKのカーネルを実際にコンパイルさせて、プロファイリングしたわけでも
ないので、知ったかぶりといわれても否定はしないが、
じゃ、例えば
http://minix-up.sourceforge.jp/cgi-bin/l.cgi/_OSASKtest11/osask/winman0.c?rev=1.24&content-type=text/x-cvsweb-markup&sortby=date
このソースの　OsaskMain() 内部にあるシグナルハンドラ内にある
switch-caseなどを見てみよう。
486、Pentium問わず、さすがにこのシグナル・ハンドラはひどいかと。
とても、速度優先のコードとは思えない。
マウスからのシグナル、0x73756f6dなど例外はあるものの、
折角、受け取る定数値が密集しているのだから、関数テーブルの余地はあったし
これをすることによる手間なんてないこと考えると、意味不明なコード。
（確かにサイズ的なメリットは分かるけど、犠牲にする速度的パフォーマンス
はもっと痛いかと。/* from mouse */ に到達するまで50箇所近い分岐命令があるし、
コンパイラによっては50回、ジャンプさせられるし。
その果て、実質、そのハンドリングで実行する内容は微々たるものだし。

仮実装でもあり得ない実装。

http://minix-up.sourceforge.jp/cgi-bin/l.cgi/_OSASKtest11/osask/winman0.c?rev=1.24&content-type=text/x-cvsweb-markup&sortby=date

OSASKのGUIモジュールのソース見てて再描画など苦労して頑張ってるみたいで
ふと思ったのだけど、
#defineMAX_WINDOWS 80// 8.1KB
という行からして、現状、Windowは最大で80個ってことだよね？
ということは、表示優先度も80種類あると。（等しい優先順位はあり得ない）
で、Zバッファを導入してはいかがでしょ？
1ﾋﾟｸｾﾙ1バイト。1024*768だったら、768kbのメモリを消費してしまうので
OSASKの方針に沿うかどうかは別問題かもしれんけど、速度は大幅にアップだよ。
WMO_WINDOW構造体に、draw_priorityとかいうcharなメンバを一つだけ増やして
描画するときは、いつもZバッファにもdraw_priorityをコピーしとく。
overrapwin() 見てみたらただの矩形検知関数じゃん。大雑把すぎる。
でもZバッファを導入すれば、例えば一番奥にある隠れてるWindowが消えた程度では
誰にも再描画が発行されてないということもあり得る。

移動にしても、移動した部分のZバッファ比較だけをすれば、
再描画すべきWindowも正確に列挙できる。

Z-Bufferを保持することのメリットはなにも、描画だけではないよ。
例えば、マウスのクリックが発生した座標のz-bufferの値が53であれば、
それに対応するWMO_WINDOWがメッセージの送信先が即座に分かる。

window[]に全てのWindowのリストが連結されてるみたいだけど、これとは別に
prio_window[ MAX_WINDOWS ]みたいなプライオリティ直結のリストを
もう一つ用意。で prio_window[ me->priority ] = me; みたいに常に
プライオリティに対応する自分自身のポインタをリスト（配列）に通知しておけば
クリックからx86命令換算で20命令以内に目的のWMO_WINDOWをgetできる。

Z buffer 速いか？
ウインドウ描画で気になるのはどれだけのメモリにアクセスするか？
やろ。
なら、面積分メモリ食うかつアクセスする Z buffer は遅い。
と思うが。

>>375
switchしてるからテーブルジャンプになってるんじゃないの？
バイナリを調べたわけじゃないからわからないけど。

>375
> 折角、受け取る定数値が密集しているのだから、関数テーブルの余地はあったし
> これをすることによる手間なんてないこと考えると、意味不明なコード。
値がけっこうふらついてるから
関数テーブルと組み合わせるなら、無駄に大きいテーブルか
ifと細かなテーブルの組み合わせになりそうな。

> とても、速度優先のコードとは思えない。
そもそも速度優先のコードでもないんじゃないかと思われ。

OSASK 3.3 ソースage・・・ん？

> Version 3.3(2002/2)
> [OSASK 5592][OSASK 5608][OSASK 5635]
> ・時計表示がサポートされました(TOWNS版)。
> ・時計表示位置が修正されました(PC-AT版/TOWNS版)。
> ・go_0009 で生成した .BIN ファイルが、go_0009 を閉じなく
> ても開けるようになりました。
> ・VESA 2.0を使用して、8bit color, 16bit color, 32bit color
> の高解像度画面が使用できるようになりました(PC-AT版のみ)。
> ・16bitグラフィックボックスが使えるようになりました。
> ・32bitグラフィックボックスが使えるようになりました。
> ・ankfont0をバージョンアップして、聖人さんのグラフィックキャラク
> ターを導入しました。

>>371
河合さんからレスついてたよ。これについてもコメントきぼん。

>Z buffer 速いか？
>ウインドウ描画で気になるのはどれだけのメモリにアクセスするか？やろ。
良く分からんが、z-bufferが速いんではなく、窓描画のメモリアクセスを
劇的に回避するためのz-bufferでは？
今のosaskの窓システムって、ちょっとかすっただけで全部描画しなおしてるし、
完全に隠れてる窓も無駄に描画しなおしてる。これこそがメモリアクセス浪費かと。

z-buffer でなくても「全部描画」の回避は可能。
と思うんだが。
376 は大分 z-buffer を押してたようなので。
そうなんかーと。

ツリーじゃ駄目なん？

>>363-365
OSASKの既存のソースパッケージからCVSリポジトリを
再構成して公開している者です。活用いただき恐悦至極。

>>363
本家にはまだありません。

>>364
本家のプログラムソースは >>364 さんの想像される形で
リビジョン管理されていません。

念のため先ほどＫ氏に確認しましたが、現状はＫ氏は
OSASKの開発にリビジョン管理システムを使用されてい
ません。(cvsもrcsも)

>>365
元になるのがそのリポジトリでなくても良いのですが、
将来的にそんな体制になると良いですよね。

なお、OSASKの実装にあたってＫ氏がどんな風に「渡り
を打って」行ったのか興味のある人は OSASK 0.8 以前
のソースも見たくなるかもしれませんが、今のところリク
エスト数が少ないとのことでそれは公開されていません。

>>371に明日は来なかったのかと心配に。
明日が今日という可能性もあるからいいっか。

ついでに動作報告。
いくつかのマシンでver 3.0以外キーボード入力を受け付けないな
と思ってたらキーボードを換えると無事に動作するようになりますた。
動かなかったのは2.8/3.1/3.3の各バージョンで、
pokon出てフリーズしているように見えます。
ただし、いっしょにつながってるPS/2マウスによってはそんなキーボードでも動きます。
（ver 3.3でのみ調査）

>>386
＞現状はＫ氏はOSASKの開発にリビジョン管理システムを使用されていません。(cvsもrcsも)

すげえ。漏れにはそんな度胸ねぇな。
commitしないとなんか中途半端で夜も眠れねえ。
ついでに、ユニットテスト通さなきゃ恐くてcommitもできねぇヘタレだ。
K氏は自分では自動化テストやってんのかな。CVSには無いみたいだが。

>念のため先ほどＫ氏に確認しましたが、現状はＫ氏は
>OSASKの開発にリビジョン管理システムを使用されてい
>ません。(cvsもrcsも)
batファイルがリジポジトリにあるとこを見ると、
川合氏はDOS（Win)派なのだろうか？
となると、cvsやrcsではなく、MicrosoftVisualSourceSafe(VSS)を使ってる
可能性も高い。

オンラインOSASKのリポジトリからcheckoutしても、64kのISDN環境で5分も
かからないし、updateしても数秒程度なので、できればＫ氏も同一のリポジトリ
使うのが好ましいのだが〜henohenoちゃんが定期更新してくれるから
ソース眺める分には困らないのかな。

とりあえず、osaskにリポジトリあるの知らなかったんでただいま閲覧中。

テキストエディタのスクロールバー実装記念age

>すげえ。漏れにはそんな度胸ねぇな。
>commitしないとなんか中途半端で夜も眠れねえ。
>ついでに、ユニットテスト通さなきゃ恐くてcommitもできねぇヘタレだ。
ほんとにヘタレだね。

本物のプログラマは、（以下略)……

>391
ﾜﾗﾀ




で、>>371はどこ行った。
レス考えてる最中？それとも反論できなくなったのか？
気になってしょうがないぞ(ﾟДﾟ)ｺﾞﾙﾘﾔｧｯｯ

明後日になってしまったが登場。

>>うむ、371さんの観点で負けていてもいいですよ。しかし誰が何と言おうと今の
>>OSASKはWindowsと同等かそれ以上に軽いです(ただし表示部分を除く)。
話を簡単にするため、話題はAPI実行に限定します。また、OSASKの現状ではなく、Ｋ氏の設計方針に従った場合の将来的なものを前提にします。

自分の観点ではなく、極めて客観的な観点です。自分個人の観点という生易しいものではありません。今のＫ氏の設計方針のままではOSASKはWindowsの遥か未満にすら及ばない
鈍足、かつ機能的にも遠く及ばないことが決定しています。

おそらくＫ氏の言及している比較相手は、Windows3.0以前のそれではないだろうか？

ご存知のとおり、現状のWindowsはAPIのそのほとんどはOLEなりCOMオブジェクトなりで
提供されています。初期化時に QueryInterface で、そのサービスへのジャンプアドレ
スが、そのプロセス内のメモリへコピーされ、有事には x86命令でいうところのメモリ参照far-call命令一つで、ターゲットとなるAPIのサブルーチンへジャンプします。

一方、OSASKの場合は、アプリ側がAPIコマンド番号をレジスタに格納したり、またAPI側がeaxレジスタに格納されたコマンド番号から参照すべきテーブルアドレスを求め、さらにジャンプ先のアドレスを求めてからさらにcallなりjmpせねばなりません。
さらに、「どのAPIを呼び出すか？」というだけのためにeaxレジスタを一つ消費してしまいます。これはAPIへのパラメータ渡しの重要な転送手段を一つ失います。
Windowsであればスタックに詰む必要のなかったAPIも、OSASKではスタックに詰まざるをえない状況がありえます。

今のOSASKの方針のままでは、速度効率面ではせいぜいスタブ経由呼び出し方式を
採用しているlinuxと引き分けるのがせいぜいでしょう。

完敗しているのは速度面だけではありません。
機能面ではもっともっと深刻です。が、これに関しては明日。

　

>>394

もう一つのオープンソースのMONAはどうかと
問うてみる。
まだ未成熟なのでコメントのしようがないかな。

>394
>機能面ではもっともっと深刻です。が、これに関しては明日。
一瞬、明日が、明白に見えた。

>394
OLEとかCOMってアプリが直接に間接far-callするのか・・・
でもそんなにOLEやらCOMって使ってるのかな。
確かにでっかいアプリになれば使ってるのはあるけど、
大抵の、少なくとも今ある大抵のアプリは
スタック渡しのnear-callなAPIを使ってるような気も。

> 一方、OSASKの場合は、アプリ側がAPIコマンド番号をレジスタに格納したり、
> またAPI側がeaxレジスタに格納されたコマンド番号から参照すべきテーブルアドレスを求め、
> さらにジャンプ先のアドレスを求めてからさらにcallなりjmpせねばなりません。
はeaxじゃなくてebxだよね？
API配列へのポインタの。

オーバーヘッドは実際どれぐらいになるかてきとーに試算してみたけど、
・分岐予測ミスに20clk
・命令は1clk
・Winがレジスタ渡しのfar-callなAPI
・OSASKがテーブルによるAPI検索
・両者が同じAPI
・OSASKでビッグコール（勝手に命名）はせず、API式はスタックに積む
・レジスタ渡しに使えるレジスタは3つ
という条件でループ内で複数のAPIを呼ぶとき、
一回のAPI呼び出しに27clkほど余計にかかる計算になる。
（push+mov+push+push+予測ミス+pop+pop+pop）
これってそんなに言うほど重いかな？軽くはないだろうけど、
APIの仕事量を考えたら必ずしも追いつけないというわけでもないような。
far-callはけっこう重いみたいだから、
ビッグコールだけでもすぐに追いつけるだろうし（Winがnearだとﾁｮﾄ難しいけど）。

>397
スマソ、APIの引数分と終端コマンドもスタックに積む必要があるから、
その分の1+3命令のpushと戻ってきた後のスタック削除のlea1つ追加して
32clkということで。
なんか間違えてるような気と、
かなりわかりにくそうな文章を書いてる気がﾌﾟﾝﾌﾟﾝするけど（ﾟεﾟ）ｷﾆｼﾅｲ!

この部分の論破は？
> TLBのヒット率
> キャッシュの利用効率
> タスクセーブ

ファイルも増えてきたし、FDとはいえ
そろそろディレクトリの概念が欲しくなってきた気がする……

ただ、ファイルシステムにもかかわる問題だから、実装は難しいのかな。

＜後ろ頭＞y-~~ ディレクトリ以前に、FDDのドライバとファイルシステムは分離したんだろか。

日本人でもOS作ってる方々がいらしゃったんですね。
ほっとしました。OSASK頑張ってください。

WS市場で、窓やlinuxから締め出された負け組みなりの敵観察ってことで、
てきとーに聞いてやってください。

「APIを従来のインデックス番号渡し＆int命令経由にしたのでは、
db製品群がまともなパフォーマンスを出せない」
確か、当時MSに移籍したばかりのカトラー氏が最初に手がけた仕事がOLEの構築だったと
曖昧ながら記憶してます。

ただ、OLEが速度面でもっと恐ろしい真価を発揮するのは、明日、371が書くことかな？
Win95前夜ごろ、MSは正気とは思えない、だけど合理的な手を打ち出してくるのです（ドキュメント風）

多分、OSがアプリケーションのコード/データ領域に「ちょっかい」を出してまで
速度を稼いだ最初のOSがWindows3.1だと思うのですが、
その点はあまり脚光を浴びてないようです。

も、一つ、余計なコメントレス。

＞でもそんなにOLEやらCOMって使ってるのかな。
＞確かにでっかいアプリになれば使ってるのはあるけど、
MSの遠大なる策?!により
知らぬ間に使ってます。コモン・ダイアログはもちろん、stdlib.libなど
旧ライブラリも、ある時期のSDKを境にCOM経由で使われてます。
printf("hello");としたら、既にあなたはCOMを使ってます（byデビッド・カトラー）
（ただし、VC++の設定でstaticにリンクするように指示する場合はその限りでは
ありません。ですが、staticにリンクしてしまうと、かえってOS全体に負担を
かけてしまうことがあるのです･･･ん？逆じゃない？と思った方がもしいましたら後日説明します）

自分はSUNな連中ではないが、OLEの威力をちょっと紹介。
（OLE相当のものって、結局、solarisには実装されなかったですね）

APIにステートが存在する場合、queryテーブルを書き換えることで
直接ジャンプが可能な点が強力。
例えば、あるデバイスのopenメソッドにて、通常であれば
実際にopenするのだけど、ある状態がbusy状態であった場合、
実際にはopenせず、その要求があった旨のみをリストに登録して
一時的に保留することは良くある。

この場合、openメソッド内にてswitch-caseで全ての状態で分岐するのではなく
状態変更時にアプリ内にあるqueryテーブルを書き換えることで、ショートカット・
ジャンプをすることが可能。

同じAPIでもAPI側のその時点での都合によってジャンプテーブルが書き換わる
ことによって、挙動を変化させることができる上、このジャンプテーブルは
アプリ内にあるので、アプリごとに振る舞いを変化させることができる。

また、API側のワークエリアを、アプリ側に持たせたことによって
アプリ側が必要だと感じた分だけ、COMオブジェクトの窓口を用意すればよく、
OS側（API側）は、いちいちワークエリア予備予約を気にする必要がない。

確かにlinuxでdbっていったらせいぜいpostgreくらいしか聞かないなー。
oracleも出してるけど、ベンチではWinNTやsolarisに及ばないし。
APIの洗練さというか練りこみがやはり商用OSだと異なるんだろうな。
（ただ、NTの優位はスタンドアロンという条件がつくが）

http://minix-up.sourceforge.jp/cgi-bin/l.cgi/_OSASKtest11/osask/?sortby=date#dirlist

なんか、OSASKのソース更新履歴見ると、
papi0.ask tapi0.askだとかの、カーネルのコアとなる部分が
半年近くも1バイトも更新されてないんだけど、ちゃんと更新は反映されてるのだろうか？

>>371
>>399の部分の話は？　漏れも気になる。

あと、

＞Windowsであればスタックに詰む必要のなかったAPIも、OSASKではスタックに詰まざるをえない状況がありえます。

の部分は余計と思われ。Windowsではスタック渡ししかしてないので
仮定の話は意味がないと思う。

>>371はWinNTのｼｽﾃﾑｺｰﾙやWin9XのVxDｺｰﾙを知らないんだろうか・・・

WinのAPIは、第一段階では、DLLを呼び出します。

最初に突入する入り口と「システムコール」は別で、DLLの中から必要に
応じて「システムコール」が呼び出されるということです。

DLLのアドレスは、THUNK TABLE に実行段階で書き込まれますので、
そのアドレスを読み出して間接near callします(少なくとも、
第一段階では、far call でも、intでもありません。)。
この性質は、必要ないなら、システムコールを呼び出さずにAPIに
必要な処理を行ってしまえるので、OpenGL系の処理速度が要求される
APIで利用されているようです。


厳密に言うと二種類あります。
例えば、XXXX という名前のAPIがあったとすると、

1. call ds:[pfnThunkXXXX] ;(near アドレスのdword 値)

2. call ThunkXXXX ;表面上は普通の関数の様に見える

別の場所にこういうテーブルが作られている。
ThunkXXXX : jmp ds:[pfnThunkXXXX]


その後、システムに問い合わせが必要なものは、内部から
「システムコール」が呼び出されます。各種COMが利用される場合も
あります。

ちなみに、DirectXは、COMです。

共振しませんか?

ってか。

「正気とは思えない、だけど合理的な手」＝404の書いたこと
という認識であってる？

あっているかどうかは知らないが 自分の認識では
「OLEの実態として一般的とは思えないが間違っているとも思わない」＝404の書いたこと

>>WinNTのｼｽﾃﾑｺｰﾙやWin9XのVxDｺｰﾙを知らないんだろうか・・・
その手のコールは、今となってはもう使われてない、ってかVxDってMS自ら
破棄指令が出てる死語だしね。
実際、OLEが出る前であれば、システムコールという概念はあったけど
今のWindowsは全てOLEで完結するようリライトされてるので、OLEの中から
システムコールを呼び出すことは稀。DirectXもOLE（ってかCOM)だけど
それ単体で完結してるし。

#互換性保つために現状でもシステムコールは全て存在してるだけ。

>>414
x86のｼｽﾃﾑｱｰｷﾃｸﾁｬ少しは勉強した方がいいよ

＞はeaxじゃなくてebxだよね？
＞API配列へのポインタの。
漏れもつっこもうと思ったが
結局、そのAPI配列の中身は所詮
API番号を格納してしまう点を指摘してるのだと思われ。

それにOSASAKが提案している、引数エリアの使いまわしも
単に用意する側のAPIの型の仕様次第では、OS問わず使いまわせる
一般的なテクニックかと。

＞最初に突入する入り口と「システムコール」は別で、DLLの中から必要に
＞応じて「システムコール」が呼び出されるということです。
Win95って結局、そういう古いケースが除去しきれてないと、
周りの専門家がMSに指摘してたけど、今はDLL内で完結し、必要であれば
ドライバと直接会話するのがトレンド。

Win98以降はCOM成熟期で、APIって事実上存在しなくなったとも言われてる。

＞x86のｼｽﾃﾑｱｰｷﾃｸﾁｬ少しは勉強した方がいいよ
って、当時のMSも皮肉で言われたもんだな。。。（遠い目）

結論：OSASKは結局、APIはIndex渡し。型チェックなし。

371の発言、一部訂正（揚げ足取りのつもりではないっす）

×有事には x86命令でいうところのメモリ参照far-call命令一つで、ターゲットとなるAPIのサブルーチンへジャンプします。
○有事には x86命令でいうところのメモリ参照near-call命令一つで、ターゲットとなるAPIのサブルーチンへジャンプします。

一応、near-callなんで371氏の言及以上にOLE呼び出しは軽快ということで。

＞複数のファンクションを一回のfar-callで呼びだす、
＞というテクニックは実現不可能
420さん指摘のようにWindowsのOLEで用意されてるサービスであれば
そもそもnear-callですし、なにも複数のファンクションをfar-callで
呼び出すテクニックなんてそもそも不要なのではないでしょうか？

>>しかしその場合は、変化するパラメータ部分だけを書き換えればいいのです。
>>レジスタ渡しのように、全部のパラメータを再代入させる必要はありません。
パラメータが長いサービスの場合は、引数構造体の先頭アドレスだけを知らせるという
仕様にしてしまえば、パラメータを少しづつ変えてAPIコールするということも
可能なので、OSASKの特徴とはいえないと思います。

ともあれ、OLEがneracallである以上、API配列は意味がないと思います。
単純にnearcallな機械語コードを並べるだけのほうが効率的かと。

http://minix-up.sourceforge.jp/cgi-bin/l.cgi/_OSASKtest11/osask/?sortby=date#dirlist

なんか、OSASKのソース更新履歴見ると、
papi0.ask tapi0.askだとかの、カーネルのコアとなる部分が
半年近くも1バイトも更新されてないんだけど、ちゃんと更新は反映されてるのだろうか？

　Windowsの様にAPIの第一段階のインターフェースを、DLL(runtime時に関数
アドレス書き換えの near call)にしておけば、API内部でシステムコールを呼
ぼうが、直接ドライバを呼ぼうが、glFlush()が呼び出されるまでバッファリン
グしようが、アプリケーションコードには影響がない。

　だから、OSの開発の初期段階で、API内部に無駄が多いような実装をしていた
としても、アプリのバイナリ無修正で、徐々に高速化することができる。

　高速化しようとするとどうしても手間がかかる場合が多いので、
後々の修正に耐えうるようになっているような、この設計方針は適切。

（「高速化できる可能性を残している」ことが重要。）

CPUに応じてintとsysenterを切り替えるとかね
実際のシステムコールは隠蔽したほうが無難

というか、MSが10年前に提示したCOMインターフェイスを上回る
速度効率性・機能性の両立を果たした呼び出し機構ってお目にかかれたことがない。
OSASKの呼び出しのAPI呼び出し配列って、結局、far-call越しにしているが故に
得した気分になるのであって、Windowsのようにnear-callな場合は、無意味。
APIに渡す引数の差分更新->連続呼び出しも、別にOSASKの特権ってわけでないし。

ってか、素直にCOMインターフェイス相当のものをOSASKで設計していれば
エセ実装だからといって、cmp羅列という醜態状態はスキップできたのだし。

だんだん話題がヘンな方向に向かってるような気もするな。
向かわせたいのか。

とりあえず、
---------------------
OSASKでの今の仕様によれば、APIを呼ぶときには
メモリ上に置いたコマンド列の先頭ポインタをebxに代入して
pioneer0 (0x00C7:0x00000000)を呼ぶ。
このとき他のレジスタはふつう変化しない。
コマンド列には必ず終端コマンドを最後に付けておく必要があるが、
一度に複数のコマンドを発行することができる。
---------------------
というのはわかってるよな。

> もしかしたら「速度を必要とするような部分ではたいていループになっており、
> そしてその場合はパラメータを少しずつ変えながらAPI-callしていくので、
> この例のように事前にstaticな構造体を用意しておく方法は使えないはずだ」
> とおっしゃるかもしれません。しかしその場合は、
> 変化するパラメータ部分だけを書き換えればいいのです。
> レジスタ渡しのように、全部のパラメータを再代入させる必要はありません。

ちゃんと読めよおまいら・・・・OSASKでできるというだけで
OSASKの特権だとか特徴だとか一言も言ってないじゃねーか。

↑426

そのコマンドってのが厄介。
あと、API呼び出した結果によって分岐することがザラなんで
なかなかAPIを配列にすることができない。
例えばOpenに失敗したらDialog出して、「失敗しました」という通知を出したい時も、
API群をあらかじめ配列に並べることはできない。だから実質、細切れに単一API
呼び出しになる可能性が非常に高い。結局、far-callの連続。

そもそも、Win32のアプリケーション内でのnear-call命令の羅列が
「複数コマンドの発行手続き」と見なせる以上、OSASKの優位性がまるでない。

>>> レジスタ渡しのように、全部のパラメータを再代入させる必要はありません。
>>ちゃんと読めよおまいら・・・・OSASKでできるというだけで
>>OSASKの特権だとか特徴だとか一言も言ってないじゃねーか。

そもそも「全部のパラメータを再代入させる必要のあるOS」って
Windows、linux含めて、どこに存在するの？

>429
誰に聞いてるの？

>>423はLﾀﾝなのか・・・？

>428
失敗したらそこでコマンド実行が止まったような気がするが。
そこまでebxが進んでるから、値でわかる。
つーか、いくらなんでもそんな仕様はありえないよ。
失敗したらどうにもならないなんてな。

> そもそも、Win32のアプリケーション内でのnear-call命令の羅列が
> 「複数コマンドの発行手続き」と見なせる以上、OSASKの優位性がまるでない。

別に「複数コマンドの発行手続き」そのものをやりたかったわけじゃないと思うが。
ただ、少なくとも速度面での優位性は薄いと思う。
タスクスィッチのときのTLBミスキャッシュなんて
APIの呼び出し回数とそれにかかる時間からみたら気にしなくてもいいのではないかと・・・

>423はLﾀﾝ

いわゆる電磁気マニアです。
コンピュータのほうはサブで、これがメインです。

やっぱり、離散系は楽なのかなぁ。

どうでもいいんだが、あの仕様は実はプロトコルっぽくなってて
すぐにネットワーク上にとばせそうだなーとか誰も思わんのか？
もしかして漏れしかXみたいだなとか思ってないのか。そうですか。

＞あと、API呼び出した結果によって分岐することがザラなんで
＞なかなかAPIを配列にすることができない。

非常に頻繁に起こり、かつ非常にコストのかかるグラフィック呼び出し
あたりは簡単に配列化できそうだと思ったりするのは素人考えですか。
そうですか。

関係ないけど
Windowsでもメタファイルを使えばDraw系APIを連続実行できる
使い物になるかどうかは微妙だが

>どうでもいいんだが、あの仕様は実はプロトコルっぽくなってて
>すぐにネットワーク上にとばせそうだなーとか誰も思わんのか？
hand shake が必要な局面では、役に立たない。

>>タスクスィッチのときのTLBミスキャッシュなんて
ところで、OSASKってAPI呼び出し時にタスクスィッチって発生するの？

　BochsエミュレータでNWSOSがOSASKに比べて遅く感じる原因をいろいろ探っ
てみたんだけど、

1. Bochsにおいては、今のところNWSOSが扱っている画面解像度の方が、OSASK
より大きいが、実機と違い、Bochsは、解像度が大きいと重くなるという性質を
持っている。だけど、解像度を同じにしても、OSASKの方がまだ早いので、これ
だけが原因ではない。

2. （Bochsにおいては、）今のところNWSOSはVESA、OSASKはVGAを使って
いるが、同じドット数を描画するのに、VESAは、VGAより多くメモリ転送を必要
とするため。なお、単純なメモリ量だけで8/3倍だが、VGAの場合、3PLANE同時
アクセスするハードウェアも標準で装備されている。

3. TLBのミスヒット。Bochsでは、CR2へのMOV命令(TLBフラッシュ)を実行
すると直ちに1024 DWORDの初期化処理が起きる。それに加えてミスヒットも
起きるので、TLBのフラッシュ回数が多いとかなり重たくなると考えられる。

　テストしたバージョンのNWSOSでは、ページディレクトリ(=>TLB)を秒間200回
程度切り替えていた。Bochsのソースをいじって調査した所、OSASKでは、そも
そもページディレクトリは一つしか持ってないらしく、同じ値を秒間数度再代入
していた。これは、NWSOSは、メモリ空間全体をページングで切り替えているの
に対し、OSASKでは、切り替えを行わず、セグメントでタスク間保護をしている
ためだと思われる。

セグメントで切り替えると、確かにTLBの効率は上がる事は上がると思う
（でも、将来的にセグメント切り替え方式で行けるかどうかはちょっと
疑問ではある。ちなみに、WindowsやLinuxは、切り替え回数は
最適化されているだろうけど、本質的にはNWSOSと同じ方式だと思う）。

>Windowsの様にAPIの第一段階のインターフェースを、DLL(runtime時に関数
>アドレス書き換えの near call)にしておけば、API内部でシステムコールを呼
>ぼうが、直接ドライバを呼ぼうが、glFlush()が呼び出されるまでバッファリン
>グしようが、アプリケーションコードには影響がない。
そうそう、そのとおり。
OSASKみたいに、いくらAPI呼び出し群を一塊にできるからって、far-callされたり
linuxみたいに、int命令が発行されたんでは、速度面でWindowsに勝てる理由がまるでない。

ましてやindex番号、は？なにそれって感じで。
例えばユーザーアプリがAPIを新規に作成したい場合、どの番号使えばいいの？
仮にindex番号がshort型としても、65536種類のAPIしか増やせないし、
この場合のジャンプテーブルのサイズも馬鹿にならない。

※ちなみにWindowsの場合、MS以外の2ndパーティが作ったAPIを数えると
数百万種類のオーダーとのこと。これら全て、OS内部にテーブルで持つつもり
なのだろうか？

>439
> ましてやindex番号、は？なにそれって感じで。
> 例えばユーザーアプリがAPIを新規に作成したい場合、どの番号使えばいいの？
> 仮にindex番号がshort型としても、65536種類のAPIしか増やせないし、
> この場合のジャンプテーブルのサイズも馬鹿にならない。

は？なにそれ

>※ちなみにWindowsの場合、MS以外の2ndパーティが作ったAPIを数えると
>数百万種類のオーダーとのこと。

ちなみに、これは、本当ですか？

Visual C++ 付属の WIN32API.CSV というファイルにAPIと各種定数の
一覧があるのですが、全体で 11000 個ほどです。Direct3Dなども含んで
います。定数等を覗いたAPI数は、確か5000位でした。

なお、ジャンプテーブルよりも、API名称保持のための文字列の方が大きいです
し、ジャンプテーブルの変わりにTHUNKテーブルが各アプリごとに必要に
なるので、必要メモリの観点からは、恐らくWindowsの方が不利だと思います。

>>441 誤字訂正
>定数等を覗いた---->定数などを除いた
ｽﾏｿ

>数百万種類のオーダーとのこと。
DLLでexportされたシンボルの数の事でしょう

>なお、ジャンプテーブルよりも、API名称保持のための文字列の方が大きいです
>し、ジャンプテーブルの変わりにTHUNKテーブルが各アプリごとに必要に
>なるので、必要メモリの観点からは、恐らくWindowsの方が不利だと思います。
Windowsのimportテーブルはロード時以外は不要なので
上手く構築すれば名前の部分だけスワップアウトします
このへんの性能はCOMが良好なのですが
タイプライブラリやレジストリも考えると微妙

>※ちなみにWindowsの場合、MS以外の2ndパーティが作ったAPIを数えると
>数百万種類のオーダーとのこと。
>>ちなみに、これは、本当ですか？
いや、嘘だろ。俺は数千万と聞いている。実際、数えること不可能だろうけど。
例えばAdobeのacrobatやら、Flashやら、WordやExecelや、一太郎やらロータスなど
大手メーカのソフトをインストールするだけでAPI数が激増する。
IEコンポーネントだけでも、ちょっとバージョンアップするたび新規APIが増えてるしな。

>>ジャンプテーブルの変わりにTHUNKテーブルが各アプリごとに必要になるので、
けど、そのアプリが起動してない場合は、テーブルをロードする必要がないので
API数が莫大だからといって、ランタイム時に負荷がかかることはないよ。
っていうか、MSはそれを見越して、OLE概念を10年以上も前に発足したんだし。

はー、読み疲れた。
つまり現状だと、cmp命令を能なく並べているOSASKカーネルは、
Windowsに速度面で激しく負けているどころか、比較勝負すらできない
段階であるという認識でOK?

>445
> けど、そのアプリが起動してない場合は、テーブルをロードする必要がないので
> API数が莫大だからといって、ランタイム時に負荷がかかることはないよ。
> っていうか、MSはそれを見越して、OLE概念を10年以上も前に発足したんだし。

なんのこっちゃ？
見越すもなにも自然の摂理だと思われ・・・

>hand shake が必要な局面では、役に立たない。
これは突っ込む所じゃないんだろうな。

>446
勝負してみたら？
現状ならOSASKが勝ってもまったくおかしくない、
というより確実に勝てると思うが。

いろいろ、みんなの見解読んでると、Ｋさんはもっと周囲のＯＳの
常識を勉強すべきだと思った。（ま、ｵﾚﾓﾅｰなんだけど、自分の場合はＯＳ作ってるわけじゃないんで）

ところで、Lﾀﾝがハンドル変えて出没してるけど、なんでハンドル変えたの？

共振がL氏のツボにはまったらしい

>>451
ちゅうより、単に略してみたら、誰かが、、、。

>450
半分ぐらい同意するけど、
今回の話からその教訓を導き出すのは難しいような（今回の話に限らないのならスマソ）。


>>403
> （ただし、VC++の設定でstaticにリンクするように指示する場合はその限りでは
> ありません。ですが、staticにリンクしてしまうと、かえってOS全体に負担を
> かけてしまうことがあるのです･･･ん？逆じゃない？と思った方がもしいましたら後日説明します）

逆っつうか、どっちも大して変わらんような気がする漏れのために説明おながいします。
メモリ的にはstaticの方が負担がかかるわけだけどそんな話じゃないわな・・・

おい、Lﾀﾝ。こんなとこで油うってないで、はやく次期NWSOSをリリースしる！

おい、LC共振回路ﾀﾝ。こんなとこで油うってないで、はやく次期NWSOSをリリースしる！

>>438
OSASK@BochsでVESA使えなかったっけ？

まあ仮にそれでTLB周りが原因だと判明しても実機でどうなのかというのが大事なわけだけど。

せめて、速度性能では勝とうよ>>OSASK

（´-`）oO○（たぶん一人ほどDLLとシステムAPIをごっちゃにしちゃってるのがいるんだけど言うべきだろうか）

>>406, >>422
CVSはファイルのタイムスタンプが変化していても内容が
全く同一である場合、デフォルトではコミットを行いません。

すぐ横にあるpokon0.c については25個のパッケージを展開
する中で順次別のものが取り出されたわけですが、その２つは
ここ最近の６個のパッケージに全く同じファイルが含まれていた、
という認識でOKです。

検証されたい場合、ソースの原典はこちらから入手可能です
(Makefile入りOSASKカーネル)
http://homepage1.nifty.com/dreaming/osask/makepast.html

CVSの挙動についてはご確認下さい。

リリース毎にどこに重点が置かれていたか
確認されたいならば、このあたりをどうぞ
http://minix-up.sourceforge.jp/cgi-bin/l.cgi/_OSASKtest11/_analysis/CVSUPLOG.txt?rev=1.25

>>458
Windowsの一般アプリの場合はdllがシステムAPIだと考えても良いのでは？
ただ3rd-partyDLLを含めたりOSASKのシステムコールと単純比較するのが妥当かどうかはわからないが

>>459
つまるところ、OSASKのカーネルはここ半年間、1バイトも変化してないってこと？
いろいろ作業の優先順位などあるのは分かるけど、Ｋさん、もっと頑張らなきゃ。（´-`）

>460
>>439のようなヤシの話だよ。
というか、みんなDOSの亡霊でも見たのかな？

>>461
知らない事、ろくに調べていない事について安易に述べる
というのは自分を見ている様で感心できません（ ;´∀｀）

少なくともそれがどんな性質のものであるかと、その間どこ
にＫ氏の労力が注がれているかを確認すべきです。

3.3に関しては、changes.txt や最後のリンクのこのあたり
はいかがでしょうか。

A pcat/vesa16.ask
A pcat/vesa32.ask
A pcat/vesa8.ask

＃A = ファイルの新規追加

vesa*.ask は素直に凄い。
コード読んだだけでは分からなかったけど、このvesa*.askは
VRAMに対して直接描画するルーチン群なのだろうか？

463さんはhenohenoさんですか？

OSASKの更新状況拝見しました。
えと、やはり、カーネル関連というか、
そのあたりの更新が全くないのが気になります。
APIブリッジやエミュレータ部分などの工事跡も（少なくとも私には）見受けられません
でしたし。

ここ半年は開発環境の整備が中心だったようだから

開発環境の整備って。。。具体的には、どんな作業。
mingwの移植だとかは、にくたまﾀﾝが強力に推し進めてたし、
botchsは、元からあったエミュ環境だし。

Ｋ氏よりも周りの温度のほうが高いんでない？

>>467

碁。

ん？にくたま　くん？

「さいたま」　が
http://saita.ma/
でＵＲＬを取得したよ。maはモロッコ。

にくたまｸﾝも
http://nikqta.ma/

にするとクールかもしれない。

>467
知りたいのならヒストリーでも見れば？
こんなところで自分の愚かさをひけらかしてないで。

>>467
MinGWのクロス開発はやったけど、移植はやってない.
移植は主にKさんと,henohenoさんとか,
ku-minさんとか,あの辺ですよ.

>>469 ttp://nikta.ma/ とか,ちょっといいかも〜

>知りたいのならヒストリーでも見れば？
>こんなところで自分の愚かさをひけらかしてないで。

（´-`）oO○（まぁ、そう必死にならずに。確かに本体がおろそかになってるのは言えてますし）

>Ｋ氏よりも周りの温度のほうが高いんでない？

むしろＫたんの思うつぼだと思われ。

>>467 , >>471
　MinGWの移植はＫ氏の仕事です。
　henohenoと当時のku-min氏は、Ｋ氏がMinGW gcc
を移植する元にしたgccと、移植されたgcc(=GO)との
差分を実在させようとしました。

　上記は2002年の11月あたりの事で、このときＫ氏は
gccをOSASKに移植する作業に没頭しており、GOは正式
リリース直前でした。

　空白は埋まりましたか？（　´∀｀）

>>465 = 472?
お暇であればMINIXのfs/inode.h(の参考日時)や
EOTAでもご覧になって、少し落ち着いて下さい。

OSASK、なにも知らないけど、セルフ開発は可能なのかな？
つまり、エディト -> コンパイル -> 実行

(#って、実行はできるか）

>371ﾀﾝはデスマーチにでも入って日付が2/13日から進まなくなっちゃったのかな？
川合さんも姿を見せないし・・・

>472
エセ実装も済ませてとりわけて問題のないプログラムを
触る理由がないと思われ。
それより大事なモノがある。というかほぼ予定通りの話なわけだが。

>エセ実装も済ませてとりわけて問題のないプログラムを
彼のいう「エセ実装」とはどういう意味だろうか？

(1)将来的に変更されるため、アプリ・バイナリ互換ではないOS拡張
(2)内部構造が変わるだけで、アプリ側からは性能以外は特に感知する必要のないOS拡張（バイナリ互換）

(2)であることを願う。APIが増えたり、最適化されるぶんには問題ないし。
APIブリッジというのが、パフォーマンスの低下を引き起こさないか、
心配ではありますが。

──────────────OSASK────────────────
　　＿＿＿＿＿＿＿＿＿＿.,へ.,i＼＿＿＿＿
　━━━━━━　　￣￣￣ i　　ﾉ　`ヽ､_　　　　　─　　　　　　　　　　　　　　　 　 .┃┃┃
　　　＿＿＿＿＿＿＿＿＿ﾉ':　　'　ゝ､:;,｀＼　　　─　 /　./　 /　　/　 /　 /　　/　┃┃┃
ーー--------ーー--ーー/　　　o　　　　　 ヽ,　　＿ノ　ノ|　ノ|　ノ|　ノ|　ノ|　ノ|　　・ .・ .・
─────────o ﾞ;'｡Ｏ`,;､　ﾟ　○　　　　ﾞ;,
￣￣￣￣￣￣￣￣￣;`∴;'・γ;ヾ、υ　　　　　 l￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
━━━━━━━━━;━i､;；`ﾞγﾞi °｡・＊　　 /━━━━━━━━━━━━━━━━━━
　　　__＿＿＿＿＿＿__ " ヾ;"∵ノ　　　　　　／　　　　　　　＿＿＿＿＿＿＿＿＿＿___
￣￣￣￣￣￣￣￣￣￣￣`ｰ-,,...ノ　　　　"⌒￣￣`ヽ、￣￣￣￣￣
　￣￣￣￣￣--------＿＿/　　　　　　　　　　＿　　　｀)───＿＿＿＿＿＿￣￣￣￣ >>371
　　　　　　　　　　　　　　　　 i'　､;,　　　　　　　／─｀`ヾ_ノ───────────
＝＝＝＝＝＝＝＝＝＝　；'ﾞl`;,　　　　　　　'´!＝＝＝ ,.､＝＝＝＝＝ ＿＿＿＿,,.....----ー ﾆﾆ
　￣￣￣￣￣￣￣　;;:,＿＿__i__､;;_,;ヾ　　　　 ﾉ,;　　　／　￣｀`ー-ｰ^`'´
───────・｡" ＼;∴`;;';:;�煤�,i　　　 i'￣l──ーy　,ノーー--､
　￣￣￣￣￣￣￣`￣．＼;:';;';;・;';ζ`　　　 ﾞ;,、l;;;;;;;;;;;;;("_ノ;;;γiヾヽ;;ﾉ──----､,,＿＿
　＿＿＿＿＿＿＿ ───`ー-‘i;`　　　　 ﾉ,'`ヽ､　￣´￣ヽ､ノノﾉ　　　　　　　　　　　 ￣￣
　　　　　　　　　　　　　　　　　 lヽ、　　　　　＼_,,､, ヽ､,,_　　＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
￣￣￣￣￣￣￣￣￣￣￣￣ﾞi　 ＼　　　　　　　i-､　　)￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　━━━━━━━━━━━ﾞ;、　｀ﾞー--､　　 /━｀~´━━━━━━━━━━━━━━━━
============--------ーーー ヽ、　 `i--ヽ_ノ----===--------====----===ーーーー===
￣￣￣　＿＿＿＿＿＿＿＿＿＿ 〉　　i＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣　 !、_ノ　　　　　　　　　　　　　　　￣￣￣￣￣￣￣￣￣￣￣

　　　　　　　　 　　 ＼　│　／
　　　　　　　　　　　　／￣＼
　　　　　　　　　　─（ ﾟ ∀ ﾟ ）─
　　　　　　　　　　　　＼＿／
　　　　　　　　　　　／　│　＼　　　　　　　　　　　　 ﾉﾉﾉﾉ　　-＿__
　　　　　　　　　　　　　　 ∩　　∧∧　∩　　　　　 (ﾟ∈ﾟ　)　　─_＿___　______￣
　　　　　　　　∩.∧ ∧∩ ＼　（ ﾟ∀ﾟ） /　　　　　 丿＼ﾉ⌒＼　　____　___
　　　　　　　　　（ ﾟ∀ﾟ ）/.　.｜　　　　/　　　　 ∀彡／＼　/ヽミ　__　__＿
　　　　　　　　 ｜　　　〈　　 ｜　　　｜　　　　　　　　　 /∨＼ノ＼　　＝＿
　　　　　　　　 /　／＼_」　　/　／＼」　　　　　　　　　/／.＼／ヽﾐ　≡＝-
　　　　　　　　 ￣　　　　　 / ／　　　　　　　　　　　　ﾐ丿　-__￣___________　<<nikq「ボクも入れて」
　　　　　　　　　　　　　　　￣


　　　　　　　　 　　 ＼　│　／
　　　　　　　　　　　　／￣＼
　　　　　　　　　　─（ ﾟ ∀ ﾟ ）─ 　　
　　　　　　　　　　　　＼＿／　　　 　 ミ 、　　　 　　　ﾉ彡
　　　　　　　　　　　／　│　＼　 　 　 ＼＼　ﾉﾉﾉﾉ　//
　　　　　　　　　　　　　　 ∩　　∧∧　∩＼( ﾟ∀ﾟ )/ /
　　　　　　　　∩.∧ ∧∩ ＼　（ ﾟ∀ﾟ） /　　| ＼ﾉ 　/
　　　　　　　　　（ ﾟ∀ﾟ ）/.　.｜　　　　/　 　 |　　　 |
　　　　　　　　 ｜　　　〈　　 ｜　　　｜　　 / ＼／ |
　　　　　　　　 /　／＼_」　　/　／＼」　　/　／ ＼ |
　　　　　　　　 ￣　　　　　 / ／　　　　　/／ 　　　 ミnikq:「わーい」
　　　　　　　　　　　　　　　￣ 　 　　　　ﾐ丿

>477
アプリから見れば(2)、OSから見れば(1)ということもありえるんじゃないかと。
そのためのAPIブリッジってことだし。
切り捨てはしないとか言ってたような。

というか広島OFFだなあ。参加者いる？

>>475
自分で試したら良いんじゃない？
ついでにリポートきぼん。
おれも知りたいし。

＞そのためのAPIブリッジってことだし。
よー分からんけど、これってCOMオブジェクトのQueryInterfaceによる
メソッドのすり替えの継承、更新で実現されてることと、何か違うの？

nikqくん、、、。AAセンス、おもしろいですねぇ
さいたまー、にくたまー

概念と実装を混同しているﾔｼがいるな。

>482
むしろ、何が同じなの？
あるいはWindowsとLinuxって何か違うの？

APIブリッジの正体が見えてこないのが問題か

>>あるいはWindowsとLinuxって何か違うの？
前者はGUIを前提にしたカーネルであるに対して
後者はCUIしか前提にしていないPOSIX準拠なカーネルである点。
Linuxに限らず、unix系は全て当てはまる。
それゆえ、複数プロセスからのGUIコマンドを受け付けることができないので
X-Windowみたいに、サーバーを一つ設けて、そこで各クライアント・プロセスと
窓口を設置することでしか、GUIを実現することができなかった。

GUIでのパフォーマンスでunix陣営が苦渋を舐め続けている理由。


>>あるいはWindowsとLinuxって何か違うの？
一例しか挙げてないが、もっと根本的に違うものがもっとたくさんある。

最近、AAも趣向凝らしてるなぁ・・・と、それはさておき

vesa32になぜかクリッピングを全く考慮していない
ラインルーチンがあるのだけど、これはなぜでしょうか？

思うんですが、OSASKのGraphic-BOXに対するサービス群のみを豊富にし、
vesaドライバはせいぜいBitBLTの対応だけで十分ではないでしょうか？
それと、どこにもドキュメントが見つからなかったのですが、
vesaでVRAMをアクセスしているときに、カーネルからスレッドもしくは
プロセスが切り替わったりする可能性はあるのでしょうか？ないのでしょうか？

このへんの仕様も気になります。

nikqうぜーぞ。

>>488
　(cvswebでもviewcvsでも) ファイル名をクリックしてから
該当リビジョンの「annotate」という文字をクリックすれば
行番号がわかります。また、どの時点でどこが修正され
たかを行単位に把握できます。
　深く語りたい時にどうぞ(行番号をまじえて話す等)。

例
ttp://minix-up.sourceforge.jp/cgi-bin/l.cgi/_OSASKtest11/osask/pcat/vesa32.ask?annotate=1.1
ttp://minix-up.sourceforge.jp/cgi-bin/l.cgi/_OSASKtest11/osask/tapi0.ask?annotate=1.5

API呼び出しに関する効率合戦の結果は結局、どうなったんでしょ？

とりあえず、Windowsでなら自分でも実際に試せるので試してみました。

nop命令を一つ実行して０を返却するだけのAPIを自作＆実行してみて、正確な消費クロックを
計測してみました。

do_nothing proc near
　nop
xor eax,eax
ret
do_nothing endp

上記プロシージャを一つだけ持つCOMオブジェクトを作成し、
rdtsc命令を両者で挟み込むように実行してみたところ、
平均して13cycleでした。（RDTSC実行分除く）
ただ、稀に一回の実行に10000cycleほど消費することがありますが、これは単に
スレッド切り替えなりプロセス切り替えが発生したことが予想されます。
計測は10個展開×100の1000回呼び出しを平均したものです。
つまりloop処理も含まれた結果なので、実際にはAPI呼び出しコストとは
いえない試験ともいえます。
（結論から言うと、COMオブジェクト呼び出しは、一度、QueryInterfaceさえ
してしまえば、単なるnearコールに過ぎないといえます）

※計測にはQueryInterfaceなどの時間は一切含まれてません
※rdtsc命令とは、CPUがリセットされてからの正確な経過クロック数が edx:eax
の64bit値が返却される、x86のope-codeです。詳細はintelの公式ページを
参照してください。

仮説を伴わない検証など、何の意味もないと思われるが。

たとえば、getoptみたいなCOMオブジェクトがあったとする。これは
プログラム起動時に１回だけしか呼ばれないため、QueryInterfaceの
コストが無視できない。また、このモジュールはほとんどのコンソール
プログラムで使用されており、決して例外的なケースではない。

何が言いたいかというと、10×100の平均というのは実際上のどういう
状況を想定していて、それが実際のプログラムにどのくらい当てはまる
のかという部分が全くないのではないかと。

一見尤もらしいけど明らかに意味の薄い比較だと思うが、諸氏やＫは
どう考えているのだろうか。

>
prog ﾄﾞｳｽﾙﾖ

で、どうやればユーザーモードからカーネルモードにnear callできるか教えてよ

>>で、どうやればユーザーモードからカーネルモードにnear callできるか教えてよ
MSDNで調べればすぐに分かる。

>>492
とりあえず、491氏の示してくれたrdtsc命令を使ってQueryInterface()の
コストを計測。

int t = get_rdsc();
if( S_OK != pDirectDraw->QueryInterface(IID_IDirectDraw2,(LPVOID*)&g_pDD) ){
return( false );
}
int s = get_rdtsc() - t;

とりあえず、もっともメソッドが多いCOMオブジェクトだといわれてる
DirectX関連のCOMオブジェクトのQueryを調べてみたら、4000cycle前後だった。
10MHzの8086でも0.0004秒で終了する。（内部で32Bit命令使ってたらそうも行かないかもしれないですが）

IID_IDirectDraw2　のメソッドは数百種類にも及ぶので、おそらく4000cycleも
単純なメモリ間テーブルコピーだと思われます。

初期化のコストとしては無視できるかと。（その後、永続的にnear-callが
できるみたいですし）

話の流れが片方（Win)だけで、にっちもさっちも逝かないんで
OSASKも誰か調べればいいだけの話では？
とりあえず、492は、OSASKでのコスト調査を。
話によれば、rdtsc命令とやらはCPU命令なんだからOSASKでも調べられるはず。

>>496
システム用に一つCOMオブジェクトがあり、その中にgetoptメソッドがある
状況だと4000+αcycleかかるってことだよな？
OSASKのfar-jump+テーブルジャンプが呼び出しに100cycleかかったとして
１回だけだとコストは4000vs100。基準にもよるが、これだけ見ると
無視してもいいものか。

比較するならもう少し別の見方を考えた方がよい気がする。

>>495
漏れMSDN入ってないんで命令だけ教えてくれよ
もちろんnear retでユーザーモードに戻れるんだよな？

>>497
Ｋあたりがやってくれると面白いんだが。

それと498は単純化しちゃうと比較が間違ってるんじゃないかという話。
比較するんならテキストエディタとか動画圧縮とかゲームとかのジャンルで
比較しないと意味がない気がする。もしくはそれで使われてるAPIの分布を
損なわないようなテストプログラム作って比較するとか。

>>401
分離していない様に見えますが何か。

> 742 名前： 超先生@OS板 ◆OS/dd1Xc 投稿日： 02/04/30 00:12
> 　∧＿∧
> ＜；｀ш´＞y-~~~ OSASKのソースを見たんだが。>fdcdrv0.ask
> 見事なまでにFDドライバとFATファイルシステムドライバが融合しとる(激汗
> ・・・・これ以上はノーコメント。

この発言の頃の fdcdrv0.ask と、OSASK 3.3 の fdcdrv0.ask との差分は：
ttp://minix-up.sourceforge.jp/cgi-bin/l.cgi/_OSASKtest11/osask/pcat/fdcdrv0.ask.diff?tr1=1.6&r1=text&tr2=1.10&r2=text&f=h
(Long coloredにするともう少し読みやすいでしょう)

>システム用に一つCOMオブジェクトがあり、その中にgetoptメソッドがある
>状況だと4000+αcycleかかるってことだよな？
getoptメソッドなんて知らんが、4000もかかるのはごく一部のCOMでは？

それと496がどういう条件で調べたか分からんが、
既にCOMオブジェクトが存在するか否かで、QueryInterfaceのコストは極端に
変化する。そのgetoptとやらが、二つ以上のモジュールで共有されているのなら
二回目以降はQueryInterfaceのコストは、マッピングされるだけなので
数万メソッドあるようなCOMオブジェクトでも、ほとんど瞬間に終了する。
ってか、そのための参照カウントだしな。

>>もちろんnear retでユーザーモードに戻れるんだよな？
Windowsだとかsolarisのような近代的なOSでは、そもそもAPI呼び出し
ごときで、保護モードに移行することがごくごく稀なのだよ。
FileOpen系などもnearコールで完結。
COMオブジェクトは、ファイルオープン要求があった旨のみ、自らの
ワークエリアに保持し、実際にファイル内容が書き込まれるのは、
定期的にプロセスが回ってくるファイルデバイス・デーモンが
要求のあったユーザープロセスを監視、書き込む時のみ。

APIといっても、内部ワークエリアの書き換えのみで実現可能なものは
nearコールで済ませる。これは、Windowsでは最近10年の常識。
仮にAPIのコードがバグってても、そのプロセスが死ぬだけ。
APIコードとてソフトウェアだからバグがあることを前提にせねばならず、
なるべくユーザープロセスで済ませるのが安全性・効率性からも合理的。

>>498
　　cycle単位で表すと確かに大きな差に見えるけど、秒単位では、496の言うように
　　とっても短いわけで、結局ユーザの感じる「速さ」は繰り返し呼ばれるときの
　　パフォーマンスに依る。
というのが 496 の言いたいことなんじゃない？

で、実際起動時にQueryInterfaceされるAPIの数ってどのくらいなんだろう？
（そんな事はありえないけど）getopt唯一つなら、当然無視して良いはずで、
1000個くらいで微妙に影響が出るくらいかな。
10万個くらいなら、「QueryInterfaceが足を引っ張っている」と言えそう。

とりあえず、参考として、
「一つのAPIを連続して呼び出したときの平均コスト」
を出してみては？>>OSASK陣営な人々。

>仮にAPIのコードがバグってても、そのプロセスが死ぬだけ。
で、重要なプロセスが死んだ後に残されたアプリは何をしろと？

5×100で4回測定中もっともよい結果を抽出
Winを想定したnear-call（ebx/esi/edi/ebpをpush/popで保存）で平均17clk
OSASKを想定したfar-call（ebx以外のレジスタをpush/popで保存・ベクタテーブル方式）で平均21clk
ただし、OSASK側は5コマンドをパックしたものと想定
1つだけに限定するとWin16clk、OSASK54clk。

ってもうね、アホかとバカかと。
お前らの持ってるプロセッサは高クロックの32ビット8086なのかと。

というわけでものすごい勢いでものすごい適当に
クロック差を計測するプログラム作ってみたけど必要か？
rdtsc使用、Windows用。しかし、CSって0x137固定でいいのか？
誰か教えてくだちい。
ちなみに上の結果は無印Pentiumで計測。

関係ないけど、DLLのイメージベースかぶった時どうするんだっけ？

正直、それほどAPIを呼び出すプログラムが想像できん。
動画にしてもせいぜい一秒間に60回更新すれば凄いほうだろし。
データベースはAPIを使うというけど、実際どんなAPIをどれぐらいの種類で何回使うわけで？
実際に計る前にそういう検討もすべきなんじゃないのかと思われ。
いや、ひょっとしたらもいらが知らないだけで常識なのかもしれないけどさ・・・

>506
あぼ〜ん。

>508
再配置。と普通に答えても(･∀･)ｲｲ？

>>507
OSASK側ではレジスタのpush/popは要らないんじゃない？

>>データベースはAPIを使うというけど、実際どんなAPIをどれぐらいの種類で何回使うわけで？
基幹産業だとかに使われてるSQLサーバだとかは、1秒間に数千万回オーダーで
呼び出されると考えて差し支えないかと。実際、IBMやMicrosoftやOracleなど
各社が提示しているベンチマークは、そんな感じだし。
ただ、一つのカードの取り出しに一つのAPIで済むことはあり得ないので
実際には、もう一桁上の回数呼び出しが必要かと。

ちなみにlinuxがWinNTなどと違い、基幹産業SQLには使えず、中規模程度で
甘んじてる理由は、純粋に１回あたりのAPI呼び出しのトランザクションが
ネック。

そもそも10年前、MS-SQLが基幹には重くて使えないと言われてた理由が
クライアントからAPIを呼び出す時にfar-callだとかint経由で
毎回、毎回、APIを呼び出していたのが発端。
IBMみたいに、SQLに特化したハードを、安価な値段で提供していたぶん、
MS-SQLはOLEが普及するまでは、日の目に当たらなかった。

そいや、超先生の姿を最近、見かけないですなー。どうなすった。

>511
スマソ、両方とも呼ばれる方（API）でのpush/popでつ。
Win版ではeax/ecx/edxをAPIが破壊可能として、
誰も保存してないので、ﾁｮﾄOSASKに不利なコードかも。

APIはすべてのレジスタを使用しなければならないような
忙しいファンクションを想定しているので、
Win32APIの規約上必要なebx/esi/edi/ebpの保護を入れておきますた。

OSASKの方は、コマンド実行のたびにpush/popするのはｲﾔﾝな気がしたので
far-callの入り口と出口にpush/popを置いたけど、
実際のOSASKだとコマンドごとに必要な分だけ置いた方が速いってなことになるかも。
コマンドの方ではさらに何の気なしにpush ebxを置いてるので、
もう少し工夫の余地はありそう・・・

>512
ということはPC上でのそれほどシビアでないデータベースでも
ほとんどAPI呼び出しばっかりってことか。

・・・でもデータベースの実装なんて当分先の話だよな。
データベースに出会えばそれ用のAPIセットができるかもしれないし・・・
なんかそう考えてると馬鹿らしくなってｷﾀ。


あんまり必要ないだろうけど作ったプログラムうｐして屁こいて寝るよ。
ttp://ruffnex.oc.to/ipusiron/upload/3136.zip
たぶんWindowsなら使える。コンソール専用。
表示は上から順に
[Win向けコードその1]
[その2]
[その3]
[コード1回のみ呼び出し版]
[OSASK向けコードその1（pushad/popad版）]
[その2]
[コード一回のみ呼び出し版（pushad/popad）]
[対比用の何もしないコード]
実行回数は100回で「一回のみ」と書いていないのはそれぞれ5回呼び出し。
実行してどうなっても知らない。K-01ライセンス。御矢炭

>・・・でもデータベースの実装なんて当分先の話だよな。
>データベースに出会えばそれ用のAPIセットができるかもしれないし・・・
>なんかそう考えてると馬鹿らしくなってｷﾀ。
SQLにしてもデータベースはごくごく基本的なAPIセットしかなく、
その全仕様を満たすデータベースソフトは、勤勉な人なら大学生でも作れます。
おそらく勉強さえすれば、507さんも作れることでしょう。

ただ、仕様のみならず性能も満たすとなると、OSから意識的に作らねばならず
現状、512が挙げたようなMSやORACLEなどの大手数社に限られてきます。
GPLなオープンソース・データベースもありますが、性能ではまるで勝負にならない
のが現状です。

逆に言えば、OSASKの現時点でのAPI呼び出しがWindowsなどに負けている、
もしくは引き分けたのでは、将来的にデータベースの移植話のメリットがないのです。
これは、軽快さを大きな特徴の一つとしているOSASKにとっては重要な課題です。

例えばウェブブラウザとか、そういう身近なのはどうなんだろう？
ネットにアクセスして、ちょっと複雑めのhtmlをレンダリングして、Javascript走らせてとか。

>>518
このあたりの実際的部分でどれだけ軽いかはかなり重要だけど、
OSASKがそこまでいかないと比較できないのからなあ…

はじめまして、NWSOS信者ともうします。教祖様はもちろん、Light様です。

当然、OSASKから見れば、私なんかは異教徒の邪教?!（笑）かもしれませんが、
そこはそこ、やはり、より良いOSがあれば改宗もあり得ますので
いろいろとよろしくです。

さて、ウェブブラウザの話が上がってますがー
実は自分もブラウザを作っていたりしますー。
とはいっても、havascriptも走らない代物ですが。
現状、NWSOSで開発を進めてますが、比較する目的などがあれば
OSASKへの移植も考えてみます。

ブラウザを作ってみて分かるのですが、やはり画像展開->表示が軽快さの
ポイントです。これらコモンとなる処理は、APIもしくはDLLとして保持しておき
その一つのDLLをカリカリにチューニングするというのが、月並みではあるけど
軽快さのコツだと思います。（結局、他力本願 ^^;)

じゃ、ばいばい。

http://www.amazon.co.jp/exec/obidos/ASIN/4254127103/qid%3D989907873/sr%3D1-1/249-4280798-4004360

GUIライブラリの仕組み―ソフトウェア設計のケーススタディ 情報科学こんせぷつ
千葉 滋 (著), 野崎 昭弘 (編集), 疋田 輝雄 (編集), 岩野 和生 (編集), 黒川 利明 (編集), 竹内 郁雄 (編集)

↑OSASKのGUI設計に参考になるかもです〜

osask＝絵に描いた餅。
しかもデッサンが狂ってる。
そんな感じがするのは漏れだけ？

>>522
そう喪前だけ。

>>522
それいうならまだ絵を描いてる段階だろ。

>>517
＞逆に言えば、OSASKの現時点でのAPI呼び出しがWindowsなどに負けている、
＞もしくは引き分けたのでは、将来的にデータベースの移植話のメリットがないのです。
＞これは、軽快さを大きな特徴の一つとしているOSASKにとっては重要な課題です。

OSASKってターゲットとしてはクライアントOSじゃないの?
パーソナルな用途で、例えばPostgresやMySQLじゃだめだ、
APIから変えなくちゃ、みたいなDBの使い方ってあんまり
なさそうな気がするのだけれど…
漏れ、数百人規模で使う業務用のDBとかインハウスで組んでたけど、
それでも秒間100トランザクション、レコード数1000万くらいだったかな。
多分Postgresでも出来なくはなかったと思う。

そもそもOracleがOSASKに移植されたとして買うヤシいるのか?

相互リンク
　　　
LightCone様をお慕い申し上げるスレ
http://pc.2ch.net/test/read.cgi/os/1039075591/l50

EOTAについて話そう
http://pc.2ch.net/test/read.cgi/os/1016784945/l10

OSASKｽｯﾄﾞﾚ Part4
http://pc.2ch.net/test/read.cgi/os/1042810549/l50

>>525
クライアントOSだから、WinNTに軽快さで負けても構わないというわけでもないのでは？
確かに秒間100程度なら、Postgres程度で十分すぎるほど間に合うし、
farコールだのnearコールだの競う必要もないのも分かりますがー

>>そもそもOracleがOSASKに移植されたとして買うヤシいるのか?
もし、本当にOSASKがWinよりも軽快だったらOracle自身が購入するかと。
Oracleもlinux参入時はかなり派手だったが、結局、パフォーマンスで
悩んでいる。DOS時代にOracleのOS作ってた開発人は根こそぎMSに移籍したのだから
OS自社開発は考えられない。（じゃなきゃlinuxには手を出さなかったはずだし :P)

他意にもデータベースはAPI呼び出しを酷使するベンチとして
見られるので、この分野で負けるのはいろいろと厳しいかと。
いわばOS性能の試金石。

ただ、データベースってファイルのロック機構だとかその他、総合的な
要素で決まるものなので、API呼び出しの優劣だけで勝負が決まるほど簡単なものではありません。

■■わりきり学園■■

コギャルから熟女まで

素敵な出会い

ゲイ、レズビアンなどコンテンツ豊富

http://www.geocities.jp/kgy919/deai.html

>>527
＞もし、本当にOSASKがWinよりも軽快だったらOracle自身が購入するかと。
あーなるほど。そういう道もありか。
とにかく軽さを追求したOSとしてね。

まあ、データベースに使うなら軽さを云々する前に安定しないと話にならん
わけだが。あとスケーラビリティと。(OSASKはマルチプロセッサ対応は
視野に入れてるのかな)。

>[OSASK 5734]
> PCMCIAのCFやSCSIのデバイスやUSBデバイスやネットワークドライブ
> やATAPIデバイスや、TOWNS版やNEC98版は、時間がないので後回しです
> 。

えと・・・川合さんはいったい何を作る気なんでしょうか・・・

CF-BOOT
OSロード専門OSってところかな、ブートローダーからの呼び出しも可能で
売りは、手軽さと高速性。
入れるところは、MBRじゃなくて、HDDのブートセクタ。
ブートセレクタ(GrubとかLiloかな)は起動が遅くなるのでいやだけど、でも他のOSにも興味がある…とかいう人向けだとか
FDを使う事も可能だが、もっと高速なデバイスを視野に入れてるとか…
ttp://www.imasy.org/~kawai/osask/boyaki.html#021230
なんかどうぞ

あんまり外部に出てない話題なので、ちょっと一言かなんかでcommentしてくれたら嬉しい

APIとて、ハングする可能性が十分にあるバグありソフトウェアとみなし、
可能なかぎり、ユーザープロセスで実行させてしまうのが、安全性が高める
ことができる、というのが、MSの方針。

APIが思わず、NULL経由アクセスしても、プロセスごと死んでしまえば
システムは感知せず放置可能。（というか、システムはプロセスが腐ってるか
どうか、知ることが不能。Windowsではプロセス・シグナル送っても反応が
なければ、ハングしてるだろう？と推測できる程度）

もちろん、設計方針次第なので、どちらがよろしいかは不明。
ただ、APIそのものも疑惑の対象とする性悪説は、セキュリティの基本かと。

http://www.amazon.co.jp/exec/obidos/ASIN/4254127103/qid%3D989907873/sr%3D1-1/249-4280798-4004360

GUIライブラリの仕組み―ソフトウェア設計のケーススタディ 情報科学こんせぷつ
千葉 滋 (著), 野崎 昭弘 (編集), 疋田 輝雄 (編集), 岩野 和生 (編集), 黒川 利明 (編集), 竹内 郁雄 (編集)

↑川合さん、読んでいただけましたか？
窓同士が重なり合ったときの再描画の最適化など、興味深いトピックが
いくつもあるので、なかなか読み応えのある資料かと思います

>>532
で、腐ってるAPIが死んだ後に残されたアプリはどうなるの？

>>で、腐ってるAPIが死んだ後に残されたアプリはどうなるの？
532ではないですが、まじめにレス。
Windowsの方針では、「APIが死んだら、アプリも心中して放置」なのです。
厳密には、OLEなどで定義されたAPIもアプリも同一プロセス内での出来事なので
「一つのアプリケーション・プロセスが、不法な実行した」に過ぎず
カーネルから見れば、管理箱の中での出来事に過ぎないのです。

マイクロソフトが、バグゼロを目指しているのは、int命令でドライバなどから
呼び出される旧APIだとか原始的なAPIのみです。
今日のWindowsではアプリケーションがHDなどのファイルアクセス要求も
エミュレータに過ぎません。

昔のPCソフトがエミュレータ内でバグって、
その上のWindowsだとかまでシステムごと落ちることがありますか？という問題。

随　分　安　定　し　た　シ　ス　テ　ム　な　ん　で　す　ね

>随　分　安　定　し　た　シ　ス　テ　ム　な　ん　で　す　ね
てか、linuxもWinも、落ちるときってよほどのことじゃない？
両者ともに、ドライババグ以外に落ちる理由ないだろ？

＞APIルーチンにエントリーする際にはさまざまなプロローグコードを通り、
＞さまざまなエピローグコードを経たあとでアプリに戻ります。
複数のファンクションを一度に呼び出せても、結局、各々は上記
プロローグやらエピローグやらを通過せざるをえないと思うのですが。

＞10万クロックの処理呼び出しに対して、10とか100クロック程度の差が問題になるとは思いませんので。
問題にされてるのは、SQLへのqueryなど各々の消費クロックがそれほどでもない
細切れなAPI呼び出しが、頻繁にある状況下だと思うのですが。
なんで、そんな10万クロックもかかるようなAPIを引き合いに出して、
比較無意味なケースを挙げてくるんですか？そのような場合は、明らかに無意味じゃないですか？

＞そしてアプリを再起動することなくAPIの交換が可能になるぶんだけ(しかもその交換をアプリに検出させずに行なえる)、
＞OSASKの方法のほうが拡張性という観点ではずっとよいと思います。
OLEでもInterfaceを継承すれば、アプリを再起動することなくAPIの交換が可能です。
拡張性の観点で、よいも悪いもないように見受けられます。

Windowsを語るのに一方はNTを前提として、一方は9xを前提として話してたんじゃ
いっこうに埒があかないと思われるが、どうか。

>538
> 問題にされてるのは、SQLへのqueryなど各々の消費クロックがそれほどでもない
> 細切れなAPI呼び出しが、頻繁にある状況下だと思うのですが。
どうしてそういう状況にならざるを得ないのか、
そういう状況がどれだけ重要か、を教えるべきだと思うが、どうか。

>>531
ブートのフックってところかな？
川合さんがやったみたいにBIOSの設定するだけでいいじゃんってのは禁句か？

それに今回の対応デバイスって結局int13対応デバイスなんじゃ・・・
しかし1ヶ月かけてBIOS使ってセクタ読んでシグネチャ見るだけのプログラム
作るとは思えないしなあ・・・

＞OLEでもInterfaceを継承すれば、アプリを再起動することなくAPIの交換が可能です。
＞拡張性の観点で、よいも悪いもないように見受けられます。
マジで？　そうか、間接nearコールだからOKなのか。

OSASKって別にあのFARコール方式だけを使わなきゃならないと言う道理は
無いんだから、連続してAPIコールが起こりそうなグラフィックAPIだけ
今まで通りにしてDBとかその辺で使いそうなAPIだけ（ファイル関係？）
nearコール形式にすればいいんじゃねーの？

>>541
嘘じゃない？　API交換なんてどうやってやんの？

[OSASK 5669] 拡張汎用BIOS構想.
を忘れてますた。
これでもわからないようなら、OSASK掲示板いきませう
ttp://www.afis.to/~mone/osask/osask_ml/200302/msg00002.html

>>543
関数ポインタテーブルのジャンプアドレス書き換えればできそう。
そういう使い方を想定しているかどうかは知らないけど。

>544
ｻﾝｸｽｺ
いや、もちろんそれは読んだんだけど、
>>530みたいなものを除くのであれば拡張汎用BIOSなんて必要なくなるんじゃないかと。

> ブート対応デバイス：標準FDD、標準ATAデバイス（含むHDD化CF）
って普通にBIOSブートできるだろうし。

となると結局選択できないブートセレクタか何かになっちゃうわけで、
そのメリットとなるとFDDにブータブルでないディスク入れてある時にでも
HDDのOSが起動するってことぐらいしかないような。

・・・確かにOSASK掲示板逝った方がいいかな？

＞嘘じゃない？　API交換なんてどうやってやんの？
■■わりきり学園■■

コギャルから熟女まで

素敵な出会い

ゲイ、レズビアンなどコンテンツ豊富

http://www.geocities.jp/kgy919/deai.html

荒らしてる犯人が思わず尻尾を出しましたなｗ
クッキーはOFFりましょう


>>マジで？　そうか、間接nearコールだからOKなのか。
これに関しては、よほどコールがシビアな状況であればアプリケーションに
組み込んでしまい、最適化を施したほうがいいかもしれません。
データベース・クライアント全てが静的リンクしてしまうと、メモリ的に
厳しくなり、またキャッシュ妨害の元になりかねないので微妙なとこでは
ありますが･･

APIコールがshortかfarかは、深刻な問題にはなりかねないと思います。

>>547

それっきり出てこないと、更に疑われる。
私は肉球さんはそんな悪人ではないと信じています。

>>548
>APIコールがshortかfarかは、深刻な問題にはなりかねないと思います。
深刻な問題にはならない　のか、　深刻な問題になりかねない　のかどっちなんだYO！
……まあ文脈から判断するに、問題にはならない　ってことか。

いくらなんでもnikq氏にここを荒らす理由があるとは思えないが…

逆に、nicq氏を貶めるための騙りだとしたらかなり悪質だな。

真実はいつも闇の中

>>547=548だろ トリップ違うし
早朝からｼﾞｻｸｼﾞｴﾝとは健康的な荒らしだ

はやりのインテリスクリプトでは？

おお、いつの間にこんなスレッドが出来てしかも４つ目！
更に意外にただの馬鹿は少ないんですね。
OSASKの仕様を良く確認・理解せずに勘違いした事を言う人や
既存のOSの常識をOSASKに当てはめようとしている人は
後を絶たないようですが、何も知らずにただ、
「エミュレーターOSって言っても全然エミュ無いじゃん。はよ作って」
とかいうクレクレ君は居ないようで。

筋トレから帰ってきたら騙りが。
朝４時なんて早朝、爆睡してましたよ。

>>547=548
早朝からお疲れ様です。
IRCの#OSASKに居るよねアンタ。誰？

>>556
俺じゃないよ。

>>547-548

とりあえず、この騙り君の仮称は「深夜君」で。

>>558
「早朝君」にしないか？
まあそんなヤシの仮称などどっちでもいいが。

>558-559
すぐ上で自白してるじゃないか。

はて。
short jmp は -127 〜 +128 にしか飛べませんが
IRCから呼ばれたので出現してみる。よけいなお世話かも。

×逆に、nicq氏を貶めるための騙りだとしたらかなり悪質だな。
○逆に、nikq氏を貶めるための騙りだとしたらかなり悪質だな。

そいや、超先生の姿を最近、見かけないですなー。どうなすった。

EOTAについて話そう
http://pc.2ch.net/test/read.cgi/os/1016784945/48-

562 名前：Be名無しさん ：03/02/20 04:06
×逆に、nicq氏を貶めるための騙りだとしたらかなり悪質だな。
○逆に、nikq氏を貶めるための騙りだとしたらかなり悪質だな。


548 ：Be名無しさん ：03/02/19 04:37
荒らしてる犯人が思わず尻尾を出しましたなｗ
クッキーはOFFりましょう


547 ：nikq ◆jG/Re6aTC. ：03/02/19 04:16
＞嘘じゃない？　API交換なんてどうやってやんの？
■■わりきり学園■■

時刻に注目。

そんな夜中にご苦労様です

>×逆に、nicq氏を貶めるための騙りだとしたらかなり悪質だな。
>○逆に、nikq氏を貶めるための騙りだとしたらかなり悪質だな。

誤字脱字に敏感なヤシと言えば、、、、、

OSASKの完成後のバージョンアップについて考えてみた。
製品のソフトの多くは必ずバージョンアップがある。
OSもまた然り。そしてそのOS上で動くソフトもバージョンアップを
余儀なくされる。バージョンアップは実はメーカーが儲けるための
手段の一つである。OSASKではどうだろう？
作っている人間が（現在の所）儲ける気が無い。
よって無意味なバージョンアップは極力抑えられる。
うーん。グッドだ。

ふー、二日連続の妻とのセックスはしんどかった。
はよ、俺様の肉タマにセーシを補給せねば。

＞もし、本当にOSASKがWinよりも軽快だったらOracle自身が購入するかと。
＞Oracleもlinux参入時はかなり派手だったが、結局、パフォーマンスで
＞悩んでいる
んな、ことはない。オラクルはlinuxのカーネルに手を入れることで
ランダムアクセスに強いシステムをOSごと提供しており、また
そのトランザクション競争では、NTに遥かに勝ってる。

ってかさ、N台ネット・クロス時のベンチの計り方が、
MSってイカサマなんだよ。それぞれスタンドアロンな状態で計ったものをｎ台分って
ことでｎ倍したものを、そのまんま性能として出してる。あほか？
と思ってたけど、あほだったは俺で、MSの狙いは、「我々のふざけたベンチ結果
を鵜呑みしてしまう愚客こそが、我が顧客としておいしいのだ」だとさ。

[読売新聞社説]
http://www.yomiuri.co.jp/08/20030220ig91.htm

linuxへの移行への警鐘と、MSへの疑惑。

＞筋トレから帰ってきたら騙りが。
＞朝４時なんて早朝、爆睡してましたよ

nikqはメガネのガリヲタ！体重42kmで筋トレ中！
しかも朝４時に起きられないデブヲタ！
キモイ！

参考リンク　http://www.nikq.net/docs/0301/01_mustache.htm

スレを読まずにカキコ

こうやって日本のソフトウェア産業は潰されていくのだな・・・

インド行くか

>>571
関係ないレスでスレ消費すんなアホが

void OsaskMain()
{
　are:
　　　　goto kore;
　kore:
　　　　goto are;
}

>>573=niqk=万年童貞ガリヲタ
煽りにいちいち突っかかってんじゃんねえよﾀｺｶｽ

void NiqkMain()
{
　　kill(gariwota);
　　kintore();
　　age();
}

void kintore()
{
　　　　put("pupupu");
}

>574

compile error: "goto kore" 前方参照が含まれています

世界が滅亡するのが先か？OSASKが完成するのが先か？

本日、現地時間10:10ニューヨーク石油施設爆発。死者多数
FBIは第二次同時多発テロであるかは不明としている。
やや古い情報だが、読売新聞の写真↓
http://www.yomiuri.co.jp/00/20030221i116.htm

ちなみに今ここでカキコしてるヤシはOSASK派以外のキチガイ。

>>579
ガリヲタ市ね
お前もOSASKを語れ

＞ガリヲタ市ね
＞お前もOSASKを語れ
だから、オマエ誰よ？しつけーから消えろ！

ところで、golibはtolsetに含めないの？
今の付属ライブラリだけじゃ正直厳しいんで、あの関数群が一般に使えると
かなり違うと思うんだけどどうなんだろ？
利用する上で何か説明が必要な癖とか問題が有るのかな？
それとも<stdio.h>とか一般的な物に再編した後でって事なのかな？

ひょっとして、山羊と肉タマってタメ？

　　　　　 /＼
　　　 　 /　　＼
　　　 ／　　　　 ＼　　　　　＿＿＿＿＿＿＿＿
　　 /　　 　/=ヽ　 ＼　 　／
　　|　　　　 ・　・　　 |　＜ 分けわかんねー事言ってんじゃねーぶっ頃すぞおめーら
　　|　　　　 ）●（　　|　　＼＿＿＿＿＿＿＿＿
　　＼　　 　 ー　 　ﾉ
　　　 ＼＿＿＿_／ 　　　
　　　　／　　　　 ＼
　　　/ /＼　　　/￣＼
　＿|￣￣ ＼　/　 ヽ　＼_
　＼￣￣￣￣￣￣ ＼＿_）
　　||＼　　　　　　　　　　　　＼
　　||＼||￣￣￣￣￣￣￣||￣
　　||　 ||￣￣￣￣￣￣￣||
　　||　 ||　　　 　　　 　 　　||

ｱｿﾊﾟｿﾏｿｰｰwww

言いたいことだけ言って荒らすなよな。
APi議論はどうなったんだ？

>APi議論はどうなったんだ？
それは「OSASKはWindowsに勝てない」で終わっただろ。

まず呼び出しの点で、far-callな時点で終わってる。
本当に速度を要求したければ、APIではなくstaticでアプリケーションに
リンクしてくれ！という川合の矛盾指摘。そもそも、それならばどのOSでもできるし
全てのコンポーネントがそんな姿勢をとれば、メモリが圧迫。
APIの連続呼び出しにしても、shortによるジャンプ群には速度的には適わない。
引数をちょっとづつ変化しながら呼び出す用途でも、引数構造体へのポインタを
引数にするような実装にすればOS問わず可能。

つまりAPI議論に関して、「OSASKがWindowsに勝てる要素ゼロ」

機能・効率、両面でOSASKは劣ってる。
WindowsのOLE呼び出しが15clk前後であることも、このスレの住人が
計測済み。

shortってナニ？

>>588
そんな貴方にLSI-C(86)試食版をプレゼソト。
smodel限定。言ってよし。short-medium-far。
いや、ﾌﾟﾌﾟﾌ、short-medium-largeですた。
ガリヲタは早く市ね！
ﾊﾟﾝﾊﾟﾊﾟﾝﾊﾟﾊﾟﾝﾊﾟ　びゅーーーーー！！！！！
筋トレ　ガリヲタ　体重43km　ﾌﾟﾌﾟﾌﾟ

あぼーん

あぼーん

二十投稿ｽﾏｿ

587の頭の事だろ

niqkの足のことらろ

山羊の足のことらろ

ポンポコポン、ｂｕｙａ−−−−−−−−！！！

>587
> 引数をちょっとづつ変化しながら呼び出す用途でも、引数構造体へのポインタを
> 引数にするような実装にすればOS問わず可能。
すれば、というのであればそもそも何の話もできないぞ。

それから15clkって何の数字だ。
効率面については「TLBのヒット率」については何も計測されていないし、
論議もしていない。機能面の議論も３の連中と共に立ち消えになったはずだが。

もちろん、「TLBのヒット率」がそれほどメリットあるとは思わないが、
そもそもfar-callでの呼び出しにしても実際の想定場面を検討せずに
怪しげなプログラムでnear-callに負けたと言われても説得力ないぞ。
議論はまだ終わってない。始まってないというべきか。

そもそもCOMは純粋なnear-callではないしなぁ

なんつーかさ、ハードウェアアクセスする最深部の事を比較に入れてないのは
おかしくない？　API呼び出しの15stepだけじゃなくて、実際にシステム
プロセスがタスクチェンジしてハードウェアアクセスする部分まで含めないと
意味がないと思うのだが。

587的にはこのへんはどうなのよ？
よくOSのことを知ってそうなので教えて欲しいのだが。

>API呼び出しの15stepだけじゃなくて、実際にシステム
>プロセスがタスクチェンジしてハードウェアアクセスする部分まで含めないと
>意味がないと思うのだが。
API呼び出しごときでタスクチェンジが発生するOSって
いまどき前時代的すぎるんじゃないか？

>win32の場合、アプリはnear-callするためのベクタをメモリのあちこちに
>勝手に保存できますが、システムはどこにベクタがあるのか、どうやって知るのでしょうか？
>書き換えるべき場所が分からなければ、動的なAPI交換は絶望的に思えますが？
QueryInterface()時にWin32カーネルはベクタを知ります。
ちなみに冒頭に「win32の場合」とありますが、正確にはwin32-apiという概念は
今となってはほとんどありません。COMなりOLEなりが、Win32APIを呼び出すことが
あり得ても、アプリケーションがWin32APIを呼び出すことは稀です。

また、アプリはnear-callではなくshort-short-callです。２回間接ジャンプです。
ただ、コンパイラの最適化、もしくはアセンブラで記述すれば、最初のジャンプテーブル
アドレスはレジスタに保存できるため、同じ系列のインターフェイス・メソッドを
連続で呼び出す時は、若干の最適化が可能です。

古いからとか新しいからとかではなくて実際にどうなのかが知りたいんだが…。

要は、WindowsはAPI呼び出しで溜めといた実際のAPIコール（つーかファイル
書き込みなら書き込みバッファみたいなものか？）をシステムプロセスが
回ってきたときに一気に書き込んでいることでいることでパフォーマンスを
上げてるわけでしょ？

一つのプロセスだけじゃなくて複数のプロセスからの要求を一回のチェンジで
全部処理できると考えれば、確かにパフォーマンスは良い気がするけど、
その代わりアプリ側からそのメモリに自由に書き込めるということだから、
セキュリティ的にあまり良くない気はする。スケジューリングもうまく
やらないと一つのプロセスが大量に書き込み／読み込みしたら他のプロセスに
時間が回ってこないとかありそう。

あと、そういうのってリアルタイム性に問題あったりしないのかなぁ。

>staticリンクの方がコードの局在性が向上して高速化できますし、
>またstaticリンクするとなれば、
>そのファンクションの中の不必要なエラーチェックなどを廃して、
>さらに高速化できると思いますが。
単一サービスに複数のアプリが要求するケースだとstaticリンクでは不可能です。
例えばhttpクライアントのサービスなどです。
とあるアプリが、httpに対してwrite要求を行ったとします。
この時、httpクライアントがbusyであるかidleであるかによって挙動が
変わりますが、staticで本当に閉じた空間だとその状態が把握できません。
そこで、通常は、ライト要求があったことのみをそのCOMオブジェクト内に記憶
しておき、しかる後に、一定時間おきに発火するhttpクライアトデーモンが、
Queryされている全てのプロセス、アドレスを監視し、スケジューリングなどの
処理を行いつつ調停を図ります。
staticリンクだとどのアドレスにリクエストが格納されているか知る手段がないため
このような調停処理は不可能です。
かといってアプリケーションがhttpクライアントに対して直接要求するためには
安全性を図るためにも別プロセスである必要があり、このジャンプコストは
頻度を考えると現実的ではありません。

>602
やっぱり今のプログラムでもKernelやUser、Shellの各DLLを呼び出すんじゃないのか？
で、それをWin32API（アプリケーションインターフェース）と
呼ぶのは間違ってないと思うんだけど、どうなんでしょ？

あと、short-short-callってのは
call **ptr
ってこと？それとも
間接call先での間接分岐？

>604
そのときはfar-callの普通のAPIでいいんじゃないでしょうか？
クライアントを直接呼び出すのも悪くないような気もします。
もちろん、一括処理が行われさえすれば、という条件ですが。
ジャンプコスト・・・おそらく50clk/回もない・・・で困るほど
シビアな、あるいは頻繁な呼び出しというのはあるんでしょうか。
また、時限式のデーモンが間に挟まる時点で
そのようなわずかな時間にこだわる必要はさらに薄まるはずです。
どうでしょう。


ただ、ループ中にどのコマンドを使うかを決め、
かつコマンドのデーモンからのレスを待たずに連続して行う必要があるプログラムで
50clk/回が問題になるようなシビアなものがあったとするなら、
アプリが自分でコマンドをまとめるなりしなければ速度的に問題が出るでしょうから
コマンドをまとめるルーチンがアプリケーション側と
クライアント側にそれぞれ存在することになってしまいますね。
10命令程度のプログラムで十分でしょうから、問題ではないわけですが。

x86でshortといったら普通は符号付き8bit相対の事で
callでは使えないはず

どこかの業界用語かもしれないから
間違っているとは言い切れないが

脳内用語を公共の掲示板で平然と使われても困るのだが・・・

"short-short-call"が絶妙。
short/medium/farじゃなくて
small/medium/largeだっつーの

業界標準ではshortは16bit。longは32bit。
x86基準だと、どうだか。

でもここはｵｻｽｸスレ

短短呼呼

>>610
アセンブラではCPU毎に違うし
C/C++では処理系依存だし
Java/C#ではlongはたしか64bitだよね

どこの標準？

>>613
すんまそん、i386SX時代の話をしてました。
どんどばーんどんどばーんどんどばーんどんどばーんどんどばーん
どんどばーんどんどばーんどんどばーんどんどばーんどんどばーんどんどばーん

どんどばーん

>>614=香具師

そして誰も反応しなくなった。。。

OSASKでエロゲーしてぇぇぇ

漏れもしてEEEE！

インテル、パソコンのBIOSに代わる仕組みを発表
http://japan.cnet.com/news/ent/story/0,2000047623,20052420,00.htm

インテルがBIOS代替のシステムを発表
http://slashdot.jp/articles/03/02/25/0510206.shtml?topic=70

ルータの設定画面みたいになるのかな

現在 Linux に奮闘中
startx をやると Can't Open Display になるの、どうするの？

>>621
Xの設定をする。

スレ違い。

>>621

GOをLinuxに移植したらすれ違いを許したる！

age

そんなことより１よ、ちょっと聞いてくれよ。
最近、猫飼い始めたんです。猫。
そしたらなんかめちゃくちゃ愛らしくてたまらないんです。
で、よく見たらなんか手にnikqとか付いてて、触るとプニプニプニプニするんです。
もうね、アホかと。馬鹿かと。
お前な、プニプニ如きで普段萌えないこの俺を萌えさせてんじゃねーよ、ボケが。
プニプニだよ、プニプニプニプニ。
なんか触りすぎると爪とか出てくるし。かわいい顔して主人に反撃か。おめでてーな。
俺の顔見て、「うにゃ〜ん」とか言ってんの。もう見てらんない。
お前な、猫缶やるからもっと言ってくださいと。
猫科の動物ってのはな、もっと殺伐としてるべきなんだよ。
物陰に隠れた獲物といつ殺し合いが始まってもおかしくない、
喰うか喰われるか、そんな雰囲気がいいんじゃねーか。nikqプニプニ野郎は、すっこんでろ。
で、やっと落ち着いたかと思ったら、猫の奴が、餌袋の前でゴロゴロゴロゴロ言ってるんです。
そこでまたぶち萌えですよ。
あのな、ゴロゴロなんてきょうび流行んねーんだよ。ボケが。
物欲しげな顔して何が、ゴロゴロゴロゴロ、だ。
お前は本当に餌がもらいたいのかと問いたい。問い詰めたい。小１時間問い詰めたい。
お前、ただ俺を萌えさせたいだけちゃうんかと。

>>625
かんじのべんきょうすれよ。

>>626
ほっとけよ

OSASKで音楽(CD)とMP3が聞けるようになったら、
真面目に考えようかな。

CD聞けるようにするのはATAドライバ書いたらすぐにでもすべきだよな。
いきなり一つ使い道ができる。

最近、LightConeOSのほうが盛り上がってるな。
軽い軽いといいつつ、ケースｂｙケースでWindowsのほうが軽快な場面も多々ある
という事実が、希望を失い、しょーもないラクガキ荒らしにあっていると思われ。

Ｋ氏はWindowsの基礎部分を徹底的に研究し、その弱点を見極め、OSASKを
根本的に設計しなおすべき岐路に立たされてるのだと自覚すべき。

>630は自分の書いた文章を見直し、その非論理性を見極め、主張を
論理から根本的に見直すべき�`に立たされているのだと自覚すべき。

>630,631
こういう低稚なカキコしかできねーの？ｵﾜｯﾀﾅ、OSASK。

what's 低稚？

新しい2ch語(・∀・)誕生？

>633
http://www.google.com/search?hl=ja&ie=UTF-8&oe=UTF-8&q=%E4%BD%8E%E7%A8%9A&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=lang_ja

せっかくのネタだがOS板では盛り上がりに欠けるな・・・。

632は天然だろうな。
OSASKよりも君の方がよっぽど可哀想だ。

せめて632は「人のふり見て我がふり直せ」という言葉を噛み締めよう。
これが最近2chなれしてきたＬぼんの台詞でないことを祈りまつ。

>637
あっさり釣られるなよ。
釣りと煽りと荒らしは放置！

>637
あっさり釣られるなよ。
釣りと煽りと荒らしは放置！

>638-639
632よ、そんなに悔しいのか（ｗ

>640
スマソ、普通にミスってた（ｗ

>641
よかった。637は釣られたとは思わなかったけど、
書いた後640は確実に釣られたと思ってたから（ｗ

６３１〜６４２　== 低稚

OSを作ってみよう
http://pc.2ch.net/test/read.cgi/os/1046271176/l50

「OSASKのLRU管理アルゴリズムについて説明してほしい」です。

#ここでいいのですか？　Kさん。

＜後ろ頭＞y-~~ OSASKの流儀から言って、おそらくは
アクセス統計を「調査」するのではなく、アプリに「自己申告」させる─

なんでKﾀﾝ、わざわざこっちに呼ぶんだ？
あっちでやるとか、ぼやきで書いてもよさそうなものだが。

あっち
http://pc2.2ch.net/test/read.cgi/tech/1042375466/l50

うまい方法というか、当たり前の方法な気もするよ。
漏れでも思い付いた。OSなんか作ってないのにね。
もっとも後から言うのなら誰でもできることだし、
ものすごくあいまいで、できるかどうか確かめもしなかったから
考えなかったのと同じようなものだけど。

漏れが考えてたのはタスクスィッチのときにPを設定する・・・ってな感じで。
次のタスクスィッチのときまでのPの値から次のPの初期設定を求めさせる、とか。
その初期設定の予言がうまくいけば、
他のタスクにメモリ全部奪われてても先読みその他で効率よく再開できる、なんて
思ったけどあんまり大した負荷じゃねーかな。それで回避できる仕事量なんざ。
LRU使うんだったらアクティブLRU-遊び[P=0や無効ページ]-スワップ行きLRUってな感じか。
LRUなんていらない、とか思ってたけど、よくよく考えたら
一つのアプリがすべての物理メモリ食っちゃうこともあるもんなあ・・・

ひょっとしてまったく的外れな話してる？漏れ
え？これ？オナニーだよ、スマソ。

おなにーは他人に見せちゃダメだって学校のせんせーがゆってたょぅ。。。

しょうがないのさ。情報公開の時代だからね。

しかし、あっちを詳しく見てるとまったく的外れ、
というか漏れがバカなこと書いただけな気がしてきたよ。
何かみんなして活発に議論してるのかと思ったら一人で突っ走ってるだけじゃねーか。
スレ汚しになっちった。激しくスマソ。

>>645とか

ぼやきページにレスついてるよ

>>650
見てきたYO！
ちょっと一言　のページにレスがついてたYO！

XF86Setupが言うこと聞きません！
ＯＳＡＳＫの方がなんぼかましですわ

OSASK ver3.4

寂れてるね、ここＫの城下町。

新Ver出たのにこれかよ・・・マジ廃れてるね

>>656
USBマウスやキーボードが使えれば気軽に試せるんだがなぁ。
と、ここまで脊椎反射でレス書いた所で、何かのエミュ上で動くかも知れない
という思いつきが。　試してみるか。

>>657
Bochsで動くし〜

>>658
thx。試してみる。

>>645
L殿
　もしかすると此処じゃなくて、http://www.imasy.org/~mone/osask/index.cgi　
じゃないかと思われ

>660
ここでいいんだよ。
>>1-2を参照しる！

>>660
すでにレスはついているので、多分L様が忙しいだけなんじゃないかと。

ふと思ったんだが…
未踏の応募手続き位一人で出来ないの？

>>663
あんた社長の戦術に文句をつける気ですか。

>>664
あの書き方だと、3割やるから手伝えと言う風に見えるんで。
一人でこなせない量じゃないと思うが。

>665
他に見え方があったら教えてほしいが。
一人でこなせるというのと一人でこなすというのは別だろうが。ヴォケが。

とか言いたくなったけど、まあ[OSASK 3300]でも読んでなさいってこった。
すでに読んだのならスマソが。

>>あんた社長の戦術に文句をつける気ですか。
文句ではなく、問われるべき質問。。。

>>667
偽？
ミス？

>>668
#667は、偽者です。

>>669
偽物なら偽物らしくcornにしといて欲しいよな。

トリップ変えるだけで精一杯だったんだよ
そう責めるな

667 ：LightCone ◆ife9Xca53U ：03/03/08 16:50
669 ：LightCone ◆sSJBc30S5w ：03/03/08 18:41

その差、1時間50分ってとこか？

ヲタスレ発見！
ヲタスレ発見！

ヲタスレ発見！

ヲタスレ発見！

ヲタスレ発見！ヲタスレ発見！
========================================================
(´ﾟ, Å,.｡｀)　＜niqk！LightCone！ていうかOSASKのPC98版作れ

全然、関係ないのですが、niqk（肉タマ）の名前の由来ってなんですか？

>>６７４
本当に関係ねー質問でスレ汚してどーすんだよ？
逝ってよし。

>>675
スマソ。
お詫びにこれあげる。

http://www.eropix.com/_vip/00_00vip.html

これってどうなの？

ttp://slashdot.jp/article.pl?sid=03/03/11/0349236&topic=12&mode=thread

少なくとも名前はネタっぽけど

そういう海外の小型OS開発を見てると、
OSASKって全然、開発が遅いよな。
だいたいさ、Ｋって、2chを見るときどーせWindows使ってるんだろ？
さっさと、OSASKにwebブラウザ載せればいーじゃん。

SVGAサーバをインストールしたとたん画面が点滅して、以後ログインできなくなっちゃったよ〜（；_；）ｼｸｼｸ
またLinux削除でした。Viper2は呪いですか？
もう一個の古い富士通ＰＣはPnPでＯＫですわ

>>678
どうやってつくるのー？？？

未踏に坂村健PMきたぜ

坂村ﾀﾝはいいね。ある意味では似たようなこともやってるわけだから、
OSASKを認めてくれれば、それ自体が一つの評価になる。
まあ一番やっかいなPMな気もするが。

（＾＾）

誰かがベースを書いてネットに公開して
オープンに資料作りなんてのはできないんだろか？＞IPAへの提出資料
wikiみたいなのでできたら中心になるヤシの負担も減るし、
よりよいのができる可能性もあるんじゃないか、とふと思った。

CVSリポジトリ見てても、進行、相変わらず全然進んで無いじゃん。
いくらなんでも、やばいんじゃない的な small-diff

>>684
　ソースコードをWebベースで書いて、それを見た
他の誰かがWebベースでパッチを作れたら面白い
ですよね。

>>685
「何だよ〜今月はマルチプラットフォーム対応や
　足回りが主かよ〜」などと、具体的にぼやいた
　方がいいと思います ;-)

Ｋ氏の2chに費やした時間 : OSASKに費やした時間 = 10 : 1

>687
レス数から逆算するとものすごいプログラマになりますが、何か？

１０：１じゃすまないんじゃないかな。

ぐうの音も出ないな＞かわい

相手にされてないだけのような。

低脳君を相手にしてもな．．

しかし、「CFでブートできない」と言っちゃうと
CF2IDEのようなデバイスを知らないのか、と思われる可能性もありそうだがなあ。

そもそも未踏という趣旨にそういうツールの類が通るのかどうか。
どちらかと言えば研究開発を謳うようなプロジェクトが通ってるような気がする。
KHBIOSには研究面や新技術という面での説得力がOSASKより薄いわけで。
すでに大半が決まってるから
極端に言えば後は力技だけでなんとかできそうな、と思われてしまいそうだし。

CFのサイズにこだわるのも、将来的にCFの容量が大きくなれば？
ということでKHBIOSにまで「後ろ向き」な印象も与えてしまうかも。

KHBIOSで行くなら
> ATA、PCカードIDE、ATAPI、USBなど多種多様なデバイスを
> 統一的に扱える新しいファンクションの設計とBIOSとしての試作
> ・異なるアクセス方法、セクタサイズなどを持った様々なデバイスを
> 統一的かつ自由に扱えるインターフェースの設計
> ・設計したインターフェースをPCのBIOSをオーバーライドする形で実装し、
> テストする

ってな感じで行った方がよくないかな。
逆に押しが弱いか？今のBIOSのままでもブート不可能なわけじゃないからなあ。


と、あえてこっちに書いてみる。

>>693
ブートローダーとして考えれば、GRUBの改良版が通ってるから、
全く不可能というわけでは無いと思うが、

ただ、その方面で実績があったから通ったのかも知れないし、
肝心のPMは任期切れでいなくなったけど。

実は現在の OSASK のパフォーマンスアップに不満があって、
CF も繋がらないような古いマシンはターゲットから外すという
目論見じゃないよな。

もしそうならKは天才だな

まぁまぁ、独断場はそれぐらいにしてさっさとやりましょうや&12345;
なにかききたいことない？

(´-`).｡ｏＯ(こっちに誘導してやった方がいいのかな）

マウス対応アプリ イイ！

拡張子ＭＭＬが相変わらず内臓スピーカからなのが惜しまれるでしょうな。

>>700
イヤホンさせば普通にイヤホンから出るけど…？

>>701
ノートパソコンじゃないの？

というより、>>700は何処から音が出ればいいの？

>>703
700の内臓スピーカーってのはビープ音のことと思われ。
普通のスピーカーから出てほしいのでは？

>>704
ふうん。

というか、OSの仕事なの？それは

どうでもいい話かもしれんが

TOWNSのICメモリーカードスロットではCFとかは読めない
(アクセスランプがつきっぱなしになってハング)、
って噂をよく見かけるのだが。

にくたまにくたま〜♪

>>708
そんなあなたに>>625（ｗ

>>706
HTMLパーサーよりはOSの仕事ではないかと。
ドライバの問題もあるし。

また早朝君かよ…

>>708-709
もう来るなよ。基地外。

なんでＫ氏よりもnikq氏の方が人気あるんだ？

>>704
ピンポーン！ＳＢ互換ですわ
あのピコピコ音は何？前に一度スピーカー付けて聞いたけど音がでかい。
もう付けてないけど〜。

ぼくたんの母板は、うぐぅ〜

DOS窓で動くからと言って、PureなDOSで動くとは限らない
bcc32.exeでコンパイルしたコンソールなexeが純なDOSだと動かない。。。なんで？
なんかコンパイルオプションない？

bcc32.exe /?

>>715
DMCかOpenWatcom使え。
Bcc32は16bitコードを吐けない。

>>927
>>862が書いてるように、BCB6買おうと思ってるなら、
年内にBCB7が出るみたいだからそれを買えば？
BCB.NETについては知らない。いつ出るかも分からない。

激しく誤爆ｽﾏｿ。

>>717
誰と会話してんの？

＜血液型A型の一般的な特徴＞（見せかけのもっともらしさ（偽善）に騙されるな！！）
●とにかく神経質で気が小さい、了見が狭い(臆病、二言目には「世間」(「世間」と言っても、一部のＡ型を中心とした一部の人間の動向に過ぎない））
●他人に異常に干渉して自分たちの古いシキタリを押し付け、それから少しでも外れる奴に対しては好戦的でファイト満々な態度をとり、かなりキモイ（自己中心、硬直的でデリカシーがない）
●妙に気位が高く、自分が馬鹿にされるとカッと怒るくせに平気で他人を馬鹿にしようとする（ただし、相手を表面的・形式的にしか判断できず(早合点・誤解の名人)、実際にはたいてい、内面的・実質的に負けていることが多い）
●権力・強者には平身低頭だが、弱者に対しては八つ当たり等していじめる（強い者にはへつらい、弱い者に対してはいじめる(特に人が見ていない場合））
●あら探しだけは名人級でウザく、とにかく否定的（例え10の長所があっても褒めることをせず、たった１つの短所を見つけては貶す）
●基本的に悲観主義でマイナス思考に支配されているため性格が鬱陶しい（根暗）
●何でも「右へ習え」で、単独では何もできない（群れでしか行動できないヘタレ）
●少数派の異質・異文化を理解しようとせず、あるいは理解を示さず、排斥する(差別主義者、狭量、視野が狭い、多数派＝正しい　と信じて疑わない）
●集団によるいじめのリーダーとなり皆を先導する(陰湿かつ陰険で狡猾）
●他人の悪口・陰口を好むと同時に、自分は他人からどう見られているか、人の目を異常に気にする（自分がそうだから容易に他人を信用できない、ポーズだけで中身を伴っていない、世間体命）
●たとえ友達が多くても、いずれも浅い付き合いでしかなく、心の友達はおらず孤独（心の感度が低く、包容力がなく、冷酷だから）
●頭が硬く融通が利かないためストレスを溜め込みやすく、また短気で、地雷持ちが多い（不合理な馬鹿）
●たとえ後で自分の誤りに気づいても、素直に謝れず強引に筋を通し、こじつけの言い訳ばかりする（もう腹を切るしかない！)
●男は、女々しいあるいは女の腐ったみたいな考えのやつが多い(例：「俺のほうが男前やのに、なんでや！（あの野郎の足を引っ張ってやる！！）」）

だからなによ

おや、OSASKってまだあったんだ。
すっかり、OS開発ラッシュから取り残された感があるね。

>>722
そうなん？
そこそこ進んではいるみたいだけどね。
ただ、KHBIOSと言うのはよく分からないな。
今の所自分は全然必要を感じないんだが、
実際に使えば便利だと思うのかもしれないし。
今のところ積極的なのはK氏だけなんじゃないか？
だから、誰かにCFプレゼントして納得するかどうか試す、
というのは悪くない考えだと思う。

さいたま・にくたま〜♪

みんなで♂ろうぜ♪
おれも♂っこむ♪
めざすさきは、ただ一つ〜♪
♀があったら、入れてみたい〜♪

ミートボールはサイゼリヤ！

同一フロッピィで3機種から起動可能な
IPL公開記念age