しかし、マウス操作のみでマインスィーパが可能であるということは、
理論的には「あれもできる、これもできる」という状態なんだろうな、NWSOS。
絵描き帖、メモ帖サンプルなんかも挙がってるし。
もうそろそろHelloWorld勝負なんて逝ってる場合じゃねーだろ、マジで。
NWSOS陣営とて、マインスィーパは通過点程度にしかとらえてないみたいだし。
936>>
RobPikeがその辺論文だしてますね。
簡単ではないってことだねぇ。
「コンピュータグラフィックス 理論と実践」に
GUIインターフェースの項あるね。
GUIデザインすんのも大変だけど、面白そうだね。
ある程度自由度も欲しいし。
>>936 そういやNWSCってMATH COMPILERって名乗ってるのな
NOWSMART C-MATH COMPILER Version 1.99 COPYRIGHT (C) NOWSMARTSOFT 2002
数式を直感的に記述できるような拡張計画とか書いてあるけど、
将来的にそういう付加価値を付けようってことでこの名前があるらしい
ちょっと手ごわいかもよ(w
おいおい、NWSOSマンセーどころかコーンたんマンセーになってきてるよ
柔軟な姿勢を見せただけでこうも評価が変わるとは・・・
しかも敵陣のど真ん中で、正直、あんたすげぇよ
>>924 APIコール単体で考えればせいぜいオーバーヘッド分を取り戻せるかどうか
って所だと思うけど、
カプセル化されたようなプログラムの場合、重複した(無駄な)コールを
念のためにする必要があることも多いんじゃない?
OSにそれがわかれば、コンパイラがCPUに対して行なうように
最適化することもできるんじゃないかな?
例えば同じ場所に同じ点を何回もプロットするようなプログラムが
あったとすると、コンパイラがその意味を知っていれば
1回だけに最適化してくれるかもしれないけど、
そんな高級な事してくれるとはかぎらないというか、責任持てないから
普通そのまま何回もAPI叩くだけじゃない?
そのAPIを管理しているOSなら書き換えが行なわれていなくてそれは無駄だと
知りうる訳で、無駄な処理を端折ることも可能ではないかと思う。
K氏がブリッジにこだわるのはもしかしたらそこら辺の野望もあるような気がする。
なんかそんなような事書いてなかったっけ?
まあ、実際にできるのかは判らないしそこまでいくのかは知らないけど。
全部自作自演だろ
>>940 別に敵対してるわけじゃないだろ?
同盟でもないけど無視でもないってとこだろ?
>>942 確かにどこまで本人なのかよく分からんが
大将同士が直接やり合うなんてネタとして最高じゃん
おまえらさんだって楽しんでるんだろ?
当然(w
でも最近ちょっと気持ち悪い。
北の国の国営放送(うまい表現だよね、これ)みたいで。
>>943 大将同士ならね・・・
さりげに
>>914は鬼!
まあLたんじゃないとはまず考えられないわけだけどさ。
んで肝心の次スッドレはどうする?
川合さんがこっちこないのならcommentへのリンクぐらい欲しいと思われ。
協定はだめぽだからNWSOSスレへのリンクも貼っておいた方がよさげな予感。
実用的かどうかは別として、Windowsでもファイルマッピングオブジェクトを使えば「OSASKの仮想記憶」的なことは可能。
名前のない一時オブジェクトをスワップファイル内に確保できる。
うちみたいにデータ用にATA、スワップ用にSCSIな環境だと、OSASKモデルよりスワップモデルの方が効率がいいかも。
>>919 ではダラダラと書いてしまったけど、端的に言ってしまえば
>>920 さんが書いた通りです。
>>921 すみません、決して川合さんが先に仕掛けたという認識があったわけではないんですが、今までの事は喧嘩両成敗のような感じでなぁなぁで済ませてしまおうという浅ましい意図で
>>919 のような書き方をしてしまいました。
>>942さん
>全部自作自演だろ
僕もそうだろうと思っています。違うかもしれませんが。
なんだか笑っちゃうんですが、扇動するつもりがない僕が扇動者として一流な
どと言われ、かたや自作自演までして扇動しようとしているのに、なんか逆効果
っぽい某氏。自作自演なんて不信感を誘うだけってことにまだ気づいていないん
ですかねえ。まあ、それでもやりたければ止めませんが。
おれもスレが盛り上がらないのはつまらないので、何とか不毛な水掛け論を避けつつ両 OS が競争し合えたらなぁ、と思う次第であります。
950 :
Be名無しさん:02/09/07 12:40
>>948 率直言えば、おまえは、技術力が無いのに偉そうに口ばっかだってこと
だよ。
|| ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄||
|| 荒らしは 。 Λ_Λ イイデスネ
|| 放置! \ (゚ー゚*)
||________⊂⊂ |
∧ ∧ ∧ ∧ ∧ ∧ | ̄ ̄ ̄ ̄|
( ∧ ∧ ( ∧ ∧ ( ∧ ∧ | |
〜(_( ∧ ∧ __( ∧ ∧__( ∧ ∧ ̄ ̄ ̄
〜(_( ∧ ∧_( ∧ ∧_( ∧ ∧ ハーイ
〜(_( ,,)〜(_( ,,)〜(_( ,,)
〜(___ノ 〜(___ノ 〜(___ノ
>>941 486も想定している以上オーバーヘッドも無視できないと思っているのでは?
linuxは486マシンでも平気で動いてはいたが。
API実行の最適化は非同期I/O等では実現しているOSもあるだろうけど、その辺のやりくりはアプリ開発者に求めるという方がK氏っぽい。
>>950 そういうお前がなぜそんなに偉そうなのか漏れにはよくわからない。
950>>
そんなんじゃこれから協力者出ませんよ。
>>953-954 あららら、せっかく柔軟なとこ見せてちょっとは見直したのにこれじゃ水の泡じゃん
で、次スレどうする?(w
自作自演の書き込む勢いは見直しました。
深夜にかけてですから、
人が少ない時間帯に一人で踊ってるのはポイント高いです。
一ついうと、E-mailのとこにsageって入れてください。
じゃないと一瞬でLタンってバレちゃうよ。
959 :
Be名無しさん:02/09/07 15:10
>>958 自作自演じゃないよ。
連続書き込みなだけだ。
>>955 あんた、ものすごい勢いで評価変わるね。
>>959 何となく伝説の西タンを彷彿とさせる書き込みだなあ……
>>960 とんがりタンの書き込みって何気に正直なんだよな
でも人の意見を認めたのは初めて見たので驚いたんだよ
釣り師が多いから悪い面を引き出そうとしてるような気もしたが
どうもそうじゃないみたいだしねぇ
>>961 自分とこに2ch風のBBSを作ったのも同じだしね(藁
>>961 西タンはちゃんと名乗ってただろ
最後までトリップ付けなかったから騙りが後を絶たなかったけどな
>>957 >>956のスレを緩衝材にして安全なOSASKスレ作るとか?
>>961 961 :Be名無しさん :02/09/07 15:23
>>959 何となく伝説の西タンを彷彿とさせる書き込みだなあ……
::::::::::::::::::
あほ
ほんものは もっとはじけてる
L=あの国の人
あそこで述べられていない「メモリ領域のファイルオブジェクト化」は
新規っぽいね。なんか近いのあるとか聞いたこともあるけど。
あとタスクセーブで云々言ってるけど、実用化はまだなんでしょ?
実用化しただけでも新規性は十分にあると思うが。
それに従来からある部品を組み合わせて何らかの新しい機能・便利な機能を持った
システムなり装置なり記録媒体を作ればそれで新規性有りと見なされるぞ。
>>968 OSASK は、どの機能も予定であって、まだ全く実装してないよ。
「タスクセーブ機能」を付けたいって予定なだけ。
みんな、そこで騙されるんだ。
ある程度は出来ているように見せかけるレベルはあるから、
その騙しのテクニックに気付く人が少ないんだよ。
>>968 「メモリとハードディスク間をページ例外を使って入れ替える」
という発想は、どれも同一と見なすべき。
そういう観点で行くと、新規性はない。
カーネルのプログラミングレベルで見たとき、スワップであろうが、
OSASKが目指しているものであろうが、大差ない。
だから既存のOSでも、その気になれば思えばいつでも実装できる。
それから、タスクセーブだが、いくつか複雑な問題があり、どんな
場合でも、矛盾なく安定して実現できるか難しい。
972 :
Be名無しさん:02/09/07 16:52
「タスクセーブ」は、実現できれば便利だと思うが、最低でも
以下のような問題を解決する必要がある。
1. オープンしたファイルが残ったままでタスクセーブしたい場合、
対象のファイルも保存しておかないと復帰できない。
2. 独自の拡張基盤をアプリが直接制御する場合、途中でタスクセーブ
はできない(これは制限としてもいいかもしれないが)。
3. 他のタスクと連携するアプリケーションの片方だけをタスク
セーブできない。復帰時、連携するアプリがなくなってしまい、
混乱が生じる。
例えば、独自にシェルをアプリケーションとして作った場合、
そこから起動したコマンド(タスク)まで含めてタスクセーブ
する必要がある。
タスク一覧表示中のタスクセーブなども危険を伴う可能性あり。
1の例として、例えば、何らかのファイルコンバータを考える。
このコンバータは、丁度今、ファイルAを読み込んで、
新規にファイルBを作成し、それに書き込み中だとする。
この瞬間にこのコンバータのタスクをタスクセーブしたとしよう。
復帰時に、AやBもその状態を保つ必要があるから、どこかにそれら
もバックアップしておかなければならないのではないか。
そうでないなら、誤って、AやBを変更してしまいかねないから。
しかし、仮に、ファイルAが他のアプリが参照も変更もするような
ファイルだったらどうするか。
勝手に保存場所を変更することは出来ない。
かといって、元の位置に残しておくのも危険。
ファイルAやファイルBの位置はそのままにしておいて、
タスクを復帰する前に、誰かに変更されてしまった場合は、
動作保証はせず、しょうがないと見なすのだろうか。
何か良からぬものを召喚してしまったような気が…
>>973 もうちょっと関連サイトが欲しいような気もするけど、何かないかなぁ。
いよいよ1000が近くなってヤバくなってきたら
>>973 で良いと思う。
ペイントソフトなどでタスクセーブできれば便利かもしれない。
しかし、ペイントソフトに、次に起動した時の「共通設定」を
行える機能があったときどうなるか考えてみる。
ちょうど、その設定ファイルを書き換えている途中にタスク
セーブする。
このとき、このペイントソフトは、自動的にシステム中から消されて
いるとする。
そして、同じペイントソフトを、別の新規データの作成のために
起動したとする。
ここでさらに設定ファイルを書き換えたとする。
この状態でさっきタスクセーブしたペイントソフトを復帰したと
すると設定ファイルに致命的な矛盾が生じるだろう。
これを避けるには、設定ファイルを保存中は、タスクセーブできない
ようにしなければならない。一種のクリティカルセクションでも
使う必要があるだろう。
>>972 どこかで、セーブできる範囲とセーブされない「外界」との間に
線を引くしかないよ。たとえローカルファイルシステム内で一貫性を
確保できたからって、ネットワークでつながっているリモートマシン
まで制御できるわけじゃないから。
ちなみに、プロセスの内部状態だけを相手にするなら、タスクセーブ
自体は古典的な技術。多くのLisp処理系にあるdump機能がそれ。
最初の実装がいつかは知らないんだけど、もしLisp Machine OS
あたりで実装されていたのなら、ローカルファイルの管理あたりは
既に何かモデルが出来ているかも。
>>977 >どこかで、セーブできる範囲とセーブされない「外界」との間に
>線を引くしかないよ。
それは、976の例を考えて良く分かった。
従って、972 の 1 のケースは、ファイルを保存するのではなく、
ファイル変更中、参照中には、タスクセーブできない区間である
ことを、OSに知らせる必要があると思う。
一種の「クリティカルセクション」みたいなもの。
>>977 >ちなみに、プロセスの内部状態だけを相手にするなら、タスクセーブ
>自体は古典的な技術。多くのLisp処理系にあるdump機能がそれ。
>最初の実装がいつかは知らないんだけど、もしLisp Machine OS
>あたりで実装されていたのなら、ローカルファイルの管理あたりは
>既に何かモデルが出来ているかも。
なるほど。
内部状態だけなら、メモリイメージと、カーネル内の状態変数や
ハンドルなどをうまく保存するだけでできそうですね。
UZEEEEE! 分けて書くな。
実用化の項だけど、誰もOSASKが実用化したなんていってないだろ(w
勝手に脳内補完しないでくれ。新規性を目指して真っ先に実用化しようと
するのはいけないことなのか?
あと、メモリモジュールやプロセスモジュールを実ファイルとしてアクセスできる
OSって漏れは知らないんだけど、あるの? できるのとやっているのは
違うぞ。それに、例外処理使ってればみんなおなじっつーのはちょっと
強引すぎ。例外処理は実装方法の一つ、って感じだと思う。
>>973 騙されたらしき、消防、厨房、専政を名乗る輩が伝言板にいたような。
「エミュレータOS」というキャッチにひっかる人もいるみたいだし。
>>982 そーいえば、ゲラボでも「エミュレータマニア垂涎のOS」みたいな
キャッチがついてたよ。
爆笑してしまった(w
>>983 つか、それってOSASKが悪いのか(w
>>978 うーん、やはり ML の過去ログくらいしか無いですよね。
今んとこOSASKに関する大抵の情報は川合さんのページから辿れるし、
結局のところ初めに出してもらった
>>973 がスッキリまとまっててベストですね。
ではスレ立てお願いします。