どうしてOSASKのスレがないの？ Part3

夢いっぱい、実装少なめ国産OS、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/test/read.cgi/os/1021123643/l50

OSASKとNWSOSについて蒸し暑く語りたい人はこちら
http://pc.2ch.net/test/read.cgi/os/1031377826/l50

2げっと余裕でした。

乙彼様＞１

>>1
おつ

っていうかさ、Ｋ氏って、
ＯＳＡＳＫのソースコード開いてる時間よりも
ボヤキテキストを開いてる時間の方が
長いんじゃねーか？

そんなことだから、後発のＮＷＳＯＳに機能面で出し抜かれるんだよ。
いくら機能実装を計画性をもってじっくりしたいといってもよ、
マウス座標すら取れねーってどういうことよ？

限度あるだろ。

そういうＬたんは2chに書き込みすぎ（ｗ

>>5
そうなんだよな。
どうせエミュレーションするんだから他のOSのAPI借りてこようと思っても
ネイティブのAPIに根本的な機能がなければラッパーは作れないわけで、
どうしてもやりたいならベタ移植でOS管理外のAPIにするしかないんだよね。

まあいずれはブリッジ仕様に書き換えられて取り込まれるとしても、
それまでは、OSASK独自のタスクセーブとか保護モードとかの機能は、
それらのAPIを使用してたら使えないかもしれないね、よく分からないけど。

・・・まあ、現状ではまだそんなものついてないんだから問題はない。
はやくOSASKで独自の機能を実現したいならネイティブのAPI整備してくれ。
とも言えるんだけど。

slash.dot の OSASK スレ中のレスに対するレスより
>>次に「OSASKの仮想記憶」についてですが、
>>ここで述べられているファイルキャッシュと仮想記憶機構の統合は、
>>遅くとも1988年にはSunOS 4.0で実現されています。
>>また、現行のほとんどのカーネル(SVR4系,BSD系,NT系?,Linux)は
>>既にこのように実装されています(実装が汚いものもありますが…) 。

>　「ファイルキャッシュと仮想記憶機構の統合」についてですが、
>これはそんなに普及しているものなのでしょうか。ちょっと信じられません。
> OSASKでは統合の結果として「スワップファイル」がないという特徴があるのですが、
>これらのOSにはスワップファイルが無いんでしょうか？
>あるような気がしてならないんですが・・・。

普及しまくっています。Windows 98 では、遅まきながらも、目玉機能の一つでした。
「ファイルキャッシュと仮想記憶機構の統合」が「スワップファイル」の有無と結びつくわけでは有りません。

確か、 OSASK で「スワップファイル」が無いのは、メモリという概念が無いからだったと思うのですが…

『川合の「ぼやき」』 より

>　僕たちの予算は300万円でした（実際はプロジェクト管理組織への経費などが割り増しされていますが）。
>これは、150万円を僕の生活費にあてて、150万円をMr.BOWさんに譲与するという意味です。
>もちろん、そういうややこしいいきさつをPMに説明しても分かってもらえないのは目にみえているので、
>申請としては僕一人が300万円の生活費を必要としている、ということになっています。

>　僕たちの予算は240万円でした（実際はプロジェクト管理組織への経費などが割り増しされていますが）。
>おそらく所得税を引いた後の額は200万円程度でしょう。このうちの100万円を僕の生活費にあてて、
>100万円をMr.BOWさんに譲与する予定です。
>もちろん今回も、これらのいきさつに言及しても分かってもらえるわけはないので、全く書いていません。

IPA の方がこれを見たらどう思うのでしょうか？

ダメなら向こうから言ってくるでしょ。
それに契約条件に予算の使い方書いてあるんだからそれに反しないように
使えば問題ないんじゃない？

さすがに予算をまともに使えないほどアホだとも思えんし。

>>8
そういえば「メモリレスアーキテクチャー」とか言っていたかも。
でもK氏本人の弁だしなぁ。

>>9
せめて人件費とか。

>>9
何にせよある程度の体裁を考えないと贈与税など別の面からまずい部分があるかも
しれないので、直接メールしてみよう。9氏、THX!

ってよく考えたらここ見てるんだよね。んじゃあ意味無いからやめとこう(w

>>11
確かに言葉の選び方には慎重になってほしい面はあるんだよな。
いらん誤解を招く元だしさ。

OSASKのAPI並にとは言わないから。

>>9
出来るとすれば、外注費で処理する or 一回受け取って贈与。
一回受け取る方が現実的かもしれん。税金の処理がめんどくさいけど。

make28公開age

こっちのスレ、活気ねぇなぁ…。

とりあえず、スロットとか新機能で何ができるようになるか考えてみない？

IOアクセス制限をコメントアウトすればデバイスドライバも可能なんだろうか？

著作権が切れるの・・・著作者の死後50年・・・MSがどこにも買収されずに倒産してから50年？
っていうか、意匠権か。それでも登録から15年だっけ。

でも、各ソフトウェアのデザインは各著作者のものだし、
GUIの各部品をもって著作物というのは無理がありすぎるような。
せいぜいタスクバー？
でもアイコンを真似る必要ってあるのかな。

と思ったら
http://members.tripod.co.jp/cyberlaw/memo/2000-12-01.htm
こんなの見つけた。
そういえば昔ニュースであったなあ。

で、参考に
http://www.google.co.jp/search?q=GUI+%88%D3%8F%A0%96@

それよりとりあえずは特許の方が恐そうだなあ。
GUI自体の特許は切れてるだろうし、そもそもほとんど意味をなさなかったわけだけど、
たとえばアップルのマウスポインタの加速に関する特許とかなかったっけ？

>>19
個人的にはマネしたものというのはやっぱり別物じゃないかと思うんだけど
どうなんだろうなあ？
○ッキーマウスは○ッキーマウスだから○ッキーマウスなんであって
ただの耳の広いネズミで○ッキーマウスでないなら○ッキーマウスでない
みたいな。
まあこの耳の広いネズミを○ッキーマウスと間違えて買っちゃったりするなら
マズイ気がするけど、○ッキーマウス風ですが○ッキーマウスではない。
と断わっている場合はどうなるんだろう？

まあ基本的には著作者の判断って事になるのかな？

そもそも著作権者以外が著作権をあれこれいうのはおかしいんだけどね。
黙認する権利を侵害してるみたいな。
主張してみたら実は自分に権利が無かったなんてことになったら困るし。

>>20
>マズイ気がするけど、○ッキーマウス風ですが○ッキーマウスではない。
>と断わっている場合はどうなるんだろう？
意図なんかにもよったり、裁判によったりするかもしれませんが
『○ッキーマウスを明らかに気にしている』ので
よっぽど違うことを明記しないといけないかと(日本語変)

GNU's Not Unix!　みたいな話だなあ、、、

　個人的にはこういう文書も欲しいなと。他にもあったら追加して下さい。
よろしくおながいします。

　※思いつきなもので「・obj2bim2 bim2bin2 に変更」という意味も
　　良くわかってません（ ; ´∀｀）


■OSASK 2.8 ソース (src28, make28) リリースノート

●一般公開版 ver 2.8 説明書
ttp://www.imasy.or.jp/~kawai/osask/docat28.html (OSASK/AT)
ttp://www.imasy.or.jp/~kawai/osask/doctw28.html (OSASK/TOWNS)
ttp://www.imasy.or.jp/~kawai/osask/docne28.html (OSASK/NEC98)

●主な変更点
[OSASK 4302,4303]
　・ビルドターゲットとして nec98 が追加されました。
　　現状はNEC98上でビルドできる事が確認できた程度であり、動作確認は
　　あまり行われていません。
　　これにともない、nec98 ディレクトリが追加されました
　・obj2bim2 bim2bin2 に変更
　・標準ライブラリが stdlib6 に変更されました

[OSASK 4303] 著作権記述の一本化
　ソースから copyrigh.txt が削除されました。このファイルは
　もはやメンテナンスされず、古くなっていました。最新の著作権
　情報は document.txt にある通り、一般公開版の copyrigh.txt
　の方をご覧下さい。

前スレdat落ち。速くねぇ？

MINIXｽﾚの123氏、ﾊｯｹﾝ。
123氏が居ればこっちのｽﾚも活気がでてくるかな

＞123氏
乙です。

>>24
向こうはすでに隔離スレになってるからこっちはこっちでﾏﾀｰﾘやれば
いいんでない？

>>24
980越えると早くなるらしい。まあそのうち倉庫に入ると思うけど
しばらく残したい時は定期的に書き込むか早めに移行した方がいいのかな？
まあどこかにスレうｐすればいい話だけど。


しかし98版はえみゅ上で動いたのが唯一Virtual98だけってのが意外だったな。
もっと最近に出た奴の方が動くんじゃないかと思ってたのに。
関係者見てないかな（ｗ

お、乙です（ ; ´∀｀）
私はソース見る暇ないけど、皆さんは読んで下さいね(おぃ)。

>>25
そうだな。
あっちはK氏とL氏の言い合いというか物理知識自慢ｽﾚになってるもんな(w

>>26
>980越えると早くなるらしい。
そうなんだぁ。

98版でもいぢってみようかな。
(小さな動作報告でもした方が良いんかな・・・)

レスもとの原文は >>8 および http://slashdot.jp/article.pl?sid=02/09/06/1332227 参照

>　ご指摘の通り、OSASKにスワップファイルがないのは「メモリという概念が無いから」です。
>そしてこのメモリという概念を無くすことこそ、OSASKにおける「ファイルキャッシュと
>仮想記憶機構の統合」なんです。っていうか、まあ、ファイルキャッシュだけになっちゃって
>仮想記憶が無いといってもいいですが。 OSASKにおける統合は、ファイルキャッシュ制御
>アルゴリズムと仮想記憶制御アルゴリズムをいっしょにしたとかそういうレベルじゃなくて、
>すべてがファイルキャッシュなのです。ファイルキャッシュさえあれば仮想記憶なんていら
>ないじゃないか、という意味の統合です。だからスワップファイルがあるかないかが、OSASKの
>「ファイルキャッシュと仮想記憶機構の統合」を特徴づけていると思います。

「ファイルキャッシュ機構と仮想記憶管理機構の統合」という名称が誤解を招いています。
一般的な OS における「ファイルキャッシュ機構と仮想記憶管理機構の統合」の定義と、
OSASKにおける定義では別物です。
OSASK の場合、統合されているのは、「ファイルシステム」と「仮想記憶機構」とではないでしょうか。
「ファイルキャッシュ」は実装の都合で存在するだけです。
極端にいえば、プロセスにメモリを割り当てず、メモリ読み書きを全てファイルアクセスに置き換えても、
OSASK の理論は変わらないはずです。ほかの OS の場合、必ずメモリ（仮想でも可）が必要です。

他の OS で「ファイルキャッシュと仮想記憶機構の統合」といっているのは、主に次の二点です。
・ファイルアクセス時に（メモリ上の）キャッシュにデータがあるにもかかわらず、プロセスに別のメモリを
割り当ててそこにロードするのは無駄だから、直接キャッシュを読み書きする。主に実行ファイルが対象
・空いている実メモリがあれば、そこをキャッシュとして使う。

あと、いくつか気になった事があります。
「メモリマップトファイル」という表現を時々見ますが、これも「ファイルマップトメモリ」というべきではないでしょうか？
やってる事は一般的な OS の「メモリマップトファイル」と変わらないのですが、ファイルにマップされて
初めて（概念的な）メモリが存在できる事から考えると、メモリにマップする事はありえないはずです。
さらに言うと、メモリアクセスが、ファイルアクセスの一形態に過ぎないのであれば、
「仮想記憶」という概念が消滅します。（メモリは単なるファイルキャッシュに縮退します）
CPU は依然物理メモリを要求しますが、実装の問題に過ぎず、OSASK の理論には影響しません。
特殊な「アプリ」も物理メモリを要求するでしょうが、この場合は特殊なデバイスとみなせます。

これはよけいでした。

>さらに言うと、メモリアクセスが、ファイルアクセスの一形態に過ぎないのであれば、
>「仮想記憶」という概念が消滅します。（メモリは単なるファイルキャッシュに縮退します）
>CPU は依然物理メモリを要求しますが、実装の問題に過ぎず、OSASK の理論には影響しません。
>特殊な「アプリ」も物理メモリを要求するでしょうが、この場合は特殊なデバイスとみなせます。

　いずれにせよ、IA32では、タスク毎のセレクタの最大数が8192個と
いう強い制限がある
（ローカルセレクタ数＋グローバルセレクタ数<=8192）
ので、OSASKのように、確保するメモリブロック毎に別々のセレクタを
割り当てるのであれば、8192個までの制限が出てしまう。

メモリブロックあたりの最小の容量を、1ページ(4KB)だとして、
最悪の場合、
　4(KB)*8192=32(MB)
までしか利用できないことになる。
物理メモリの容量はずっと余っているのにこの制限が出てしまう場合が
有るのだから、考え物ではないか。


　それと、ポインタに必ずセレクタを必要とせざるを得なくなり、
アドレッシング的には、32BITの制限があるのに、48BITのポインタ
を用いなくてはならなくなる。セグメントレジスタへセレクタ値
をロードするのは、汎用レジスタに比べて重い処理である。
ちなみに初代80386では、汎用レジスタへのロードが2クロックなのに
対し、セグメントレジスタへのロードは18クロック必要とする。

　OSASKの「メモリレスアーキテクチャ」の欠点はまだある。

　open,read,write, fopen,fread,fwrite, などで利用する通常の
ファイルは、一つのタスクでオープンするファイルが増えても、
個々のファイルサイズの制限が強くなることは無い。

　しかし、OSASKでは、セレクタでファイルを識別し、
「セレクタ:オフセット」の形がファイルへのアクセスとなる。

しかし、「セレクタ：オフセット」は、いったん、１タスク辺り、
4GBの線形アドレスに一度変換されてから扱われる。

CPU内部の実効アドレス計算式は次のようなものである。
SEL:[OFS] ---> LINEAR_ADDR = SEG_BASE(SEL) + OFS

この計算が行われる時、下方伸張型のセグメント以外では、
OFS >= 0 && OFS < SEG_LIMIT(SEL)
であるかのリミットチェックが入り、もし、範囲外であれば
例外ハンドラが起動する。下方伸張型のセグメントの場合は、
リミットチェックの範囲が逆転するだけで本質的には同じ判定が
行われる。

このアーキテクチャだと、メモリレスアーキテクチャを用いて、
同時に 4GB 以上のファイルを自由にアクセスするのは難しいので
はないか。

-------------------------
OSASKの「メモリレスアーキテクチャ」で、複数の「ファイル」を
開き、同時に高速にアクセスするためには、
どのファイルへのアクセスも、一般保護例外も、ページ例外も
起こさない状態に「同時に」なっている必要がある。
.........(1)

「SEL:[OFS]」をファイルアクセスの基本とするのは、
アプリケーションインターフェイスとして決定されているので、
変更しようが無い。これは、メモリレスアーキテクチャの要であり、
変更できない。
.........(2)

[#34 の続き]

(1)(2)を同時に満たす条件を求めてみよう。

まず、OFSの範囲は、
　0 <= OFS <= SIZE_OF_FILE(SEL) ･････(3)
となる。

IA32アーキテクチャでは、SEL:OFS が例外を起こさない条件は、
通常セグメント: 0<= OFS <= SEG_LIMIT(SEL) ･････(4)
下方伸張セグメント: SEG_LIMIT(SEL)<= OFS <= 0FFFFFFFFH
である。
下方伸張セグメントは、通常セグメントと条件が反対なだけ
なので、一般性を失うことなく、通常セグメントだけを議論すれば
よい。


(3)の範囲のうちの現在アクセスしている領域を、
A<= OFS <=B ･････(5)
に狭めて(1)の条件を少し甘くし（OSASKにとって有利な
条件となる）、この範囲内だけで(4)の条件を満たしていれば
良いとしよう。


それは、Bに対し、
B <= SEG_LIMIT(SEL) ･････(6)
の制約を課することになる。

[#35 の続き]

次に、区間:
[SEG_BASE(SEL), SEG_BASE(SEL)+SEG_LIMIT(SEL)]
は、ファイルに対応する全てのSELで、共通部分を持っていては
ならないから（そうしなければ、データが重なってしまう）、

SEG_LIMIT(SEL)の値("ファイル"SELに対応するセグメントのサイズ)は、

SEG_LIMIT(SEL) <= (4GB / ファイルの個数) ････(7)

でなくてはならない。
-------------------------


(6)と(7)をあわせると、Bに対する制限:
B <= (4GB / ファイルの個数)　　･････(8)
が現れる。

B は、「現在"例外"の発生無しにアクセス可能なファイルポインタ値
の上限」に他ならず、Bの範囲に制限があることは、
個々のファイルのサイズに、 (4GB / ファイルの個数) の制限が出て
しまうことを表す。

#36 で得た結論を少し噛み砕いて言えば、

OSASK の「メモリレスアーキテクチャ」では、一つのタスクで
同時にオープンするファイルが多くなると、
扱えるファイルのサイズが反比例して小さくなっていく、

ということである。

同時にファイルを沢山オープンする状況は、そう多くは無いが、
それでもこの条件は、容易に容認できないのではないか。

特に、OSASKでは、「メモリレス」つまり、メモリもファイル
として扱うのだから、「同時にオープンするファイルの個数」も
無視できないくらいの数になる可能性もあり、深刻な問題が
生じるのではないかと私には思える。

>>36

>次に、区間:
>[SEG_BASE(SEL), SEG_BASE(SEL)+SEG_LIMIT(SEL)]
>は、ファイルに対応する全てのSELで、共通部分を持っていては
>ならないから（そうしなければ、データが重なってしまう）、

こう書いたのを「厳密ではない」と思われた方もいると思います。
この命題をPとします。

正しくは、

「
区間:
[SEG_BASE(SEL)+ACS_MIN(SEL),SEG_BASE(SEL)+ACS_MAX(SEL)]
が一つのタスク内で同時にオープンしている全てのファイルで
共通部分を持っていてはならない。」････(Q)

が正しいのです。

なお、区間、
[ACS_MIN(SEL), ACS_MAX(SEL)]
とは、(5) で定義した、[A,B] のことです。

実は、この区間は、アプリの書き方に依存し、
タスク内で同時にオープンしている任意のファイル間で共通部分を
持って「いないとは限らない」ので、一般には、
(P) の条件が必要となるのです。

#38 の説明でも納得できない人のために。

SEG_BASE(SEL) は、負の値を取れません。
ですから、各ファイルのアクセス中の OFS の範囲が偶然重なっていて、
しかも、重なっている区間が、4GB 近くの付近にある場合を考えてみると
正しいことが納得できるはずです。

「重なり合わないように、セグメントの範囲を定める」
ことは、SEG_BASE に負の値を取れるなら、いくらでも可能です
が、負の値を取れないので、最悪の場合「ずらしきる」ことが出来ません。

>>39
KB単位のバイナリサイズを削ることに腐心している時点で、
4GBなんてファイルは眼中に無いんだよ。
OSASKの方針はシンクライアント専用の携帯機には向いていそうな
気がするんだがねえ。486必須ってのは痛いな。

よく分かってないけど、要するに現状だと32ビットの壁があって、
ファイルは1つのメモリ空間に置ける程度しか同時にアクセスできないらしい。
ってことでいいの？

>>40
そういえばOSASK移植しやすそうなCPUってなんかないのかな？

また長文書きまくって…。LightConeたんはマジで学習能力無いな。
マジでやめてくれ。そんなの１レスにまとまるだろ。
自己顕示欲激しすぎ。

相変わらず人にけち付けるのを生き甲斐としてるよな。
難しく書けばいいってもんじゃないんだぞ。

メモリレスアーキテクチャはラッピングすれば通常のファイルストリームに
なるんですが、それが何か？
アプリがやってるみたいにバッファを使用すればすぐにでも
解決するんですがそれが何か？
32bitCPUにおけるファイルマップトＩ／Ｏの基礎的な制限と
言うだけですがそれが何か？

>>43
　確かに、（どこかで聞いたように）「ラッピングすれば」
通常のファイル入出力になりえますね。

　VIDEOデータの加工ソフトの場合なんかだと、大容量ハードディスク
を全て使い切るようなファイルを扱わないといけないので、
例え 4GB でも十分とはいえないでしょう。
　
　普通のファイル入出力は、使ってるファイルシステムによる
制限はあっても、原理的にはファイルサイズの制限がありません。


　また、他のOSでも、基本設計の変更無しに、API の追加と、
内部コードの少しの修正で、同じ仕組みを追加できると思います。

Ｋ「８０パーセント？冗談じゃありません！現状でオサスクの性能は、１００パーセント出せます！」

シャア「フラットメモリを採用していないようだが？」

Ｋ「そんなものは飾りです！　偉い人には、それがわからんのです！」

>>42
自己顕示欲と関係ないと思いますが。

>>40
なるほど、そういうことなら納得できます。

>>41
>よく分かってないけど、要するに現状だと32ビットの壁があって、
>ファイルは1つのメモリ空間に置ける程度しか同時にアクセスできないらしい。
>ってことでいいの？
そうです。ただし、厳密には、「現状」だけではないことを証明できて
しまってます。このアーキテクチャを保つ限り、細かい改良によっては
直りません。

#36 で、結論が厳密には間違ってました（が本質的には似てます）ので
修正します。

>SEG_LIMIT(SEL) <= (4GB / ファイルの個数) ････(7)
>でなくてはならない。

は、厳密には、

�� SEG_LIMIT(SEL) <= 4GB ･････(7')
SEL

と言う条件で、

>(6)と(7)をあわせると、Bに対する制限:
>B <= (4GB / ファイルの個数)　　･････(8)
>が現れる。

は、
�� B(SEL) <= 4GB ･････(8')
SEL

です。

これは、１タスク内で同時にオープンできるファイルサイズの合計が、
4GB 以内で無ければならない、ということです。

つまり設計に問題があると？

>>45 ワラタ
赤いOSASKは性能が３倍！！

Lightは名乗ってもかわらんなあ。（ｗ
昔も同じこと言ってなかったっけか？
とっくにがいしゅつな話だと思うが、
OSASKはフラット＋セグメントであってセグメントオンリーじゃない。
で、4Gの制限があるのはフラットモデルとて同じこと。

見た目上OSASKに制限がないがために、知らずに4G超えてしまったとしても、
そのアプリに4Gの物理メモリが割り当てられてるわけでも、
一気に4Gロードするわけでもないだろう。

おまけとして、4Gまるまるファイルマッピングできるという利点は
P6以降の36ビットメモリで有利になる可能性もある。
今後さらに扱える物理メモリが増えてもフラットモデルの制限は解けないが、
セグメントモデルはそうじゃない。最高で4G×8192までできる（ｗ

おっと、も一つ根本的なことを忘れてた。
...けど、こんな根本的なこと間違えるわけはないよな・・・

念のために聞くけど、まさか、4Gを超えるファイルは4Gまでしかアクセスできないとか
考えてないよね？

>>32
>OSASKのように、確保するメモリブロック毎に別々のセレクタを
>割り当てるのであれば、8192個までの制限が出てしまう。

　しませんよ？そんな1セグメント＝64KBの時代よりさらにひどい仕様
だれが考えるんですか。

>>33
>　しかし、OSASKでは、セレクタでファイルを識別し、
>「セレクタ:オフセット」の形がファイルへのアクセスとなる。

　なりません。アプリを読めばわかりますが、自分のデータセグメントに
ファイルの一部をマッピングするという方法になっています。
　一つのファイルの複数の部分を別々にマッピングすることもできる仕様なので、
4GB以上隔てたランダムアクセスも心配いりません。4GB一気にアクセスできない
のは従来の方法でも同様でしょう。

>>49
>これは、１タスク内で同時にオープンできるファイルサイズの合計が、
>4GB 以内で無ければならない、ということです。

　将来はマルチセグメントもサポートする、という話でしたよ。

>>49
4G越えファイルは部分的にマッピングすれば問題ないだろうに。

移植性が落ちるから普通は採用しないし、
ページングとの兼ね合いで全体の効率が落ちる可能性は否定しないが、
致命的な設計の問題とまでは思えない。

>>54
>将来はマルチセグメントもサポートする、という話でしたよ。
L様はリニアメモリ空間の事を心配していると思われる。
1.セグメントだと例外発生条件に制限がある
2.したがって実用的なマッピングにはページングによる保護が必要
3.ページングを使う以上結局リニアメモリ空間(4G)に縛られることになる
4.したがってセグメントを採用する価値はあまりない
と言いたいのではないかと推測。
L様の連続書き込みは「機能密度」が低い。

普通のデータならブロック単位毎に扱うんじゃないの？

つうか、物理メモリは限られてるのに
どうやったら同時アクセスなんてできるのだろう？

・・・しかしオブジェクト指向で管理ができないほど、
膨大な通信スロット使って分散処理して、
なおかつ一つのタスクで大量データを同時アクセスする。
って一体どういう処理なんだろうな？

まあ、うちのマシンじゃどんなOS使ってもまともに動きそうもないからどうでもいいや。

>>54

> アプリを読めばわかりますが、自分のデータセグメントに
>ファイルの一部をマッピングするという方法になっています。
>　一つのファイルの複数の部分を別々にマッピングすることもできる仕様なので、
>4GB以上隔てたランダムアクセスも心配いりません。4GB一気にアクセスできない
>のは従来の方法でも同様でしょう。

それは知りませんでした。誤ります。

しかし、それだと本当に、既存のOSのMemory Mapped Fileと
変わらないのではないでしょうか。

てっきり、セグメントの利点を生かして、ガーベッジコレクション
の自動化でもやりたいのかと思ってました。
酷い勘違いでしたよ。でも、今度は逆に、既存のOSに対する
新規性が全く感じられないのですが、Windowsなどとどこが違うか
説明していただけませんか。

例えば、Win32 には、こんなAPIがあります。

MapViewOfFileEx

The MapViewOfFileEx function maps a view of a file into
the address space of the calling process.
This extended function allows the calling process to
specify a suggested memory address for the mapped view.

LPVOID MapViewOfFileEx(
HANDLE hFileMappingObject, // handle to file-mapping object
DWORD dwDesiredAccess, // access mode
DWORD dwFileOffsetHigh, // high-order DWORD of offset
DWORD dwFileOffsetLow, // low-order DWORD of offset
SIZE_T dwNumberOfBytesToMap, // number of bytes to map
LPVOID lpBaseAddress // starting address
);

>>58,59
さんざん既出。
しかし、セレクタにマッピングする事と、リニア空間にマッピングする事の差も想像できないのか。

>>58
つーか>>8を読んでたら無駄なレスしなくてよかったんじゃない？

ちなみに、Win32API でも、１つのファイルの複数の部分を別々
にマッピングできます。完成されたOSなので当然かもしれませんが、
複数プロセスからの同一ファイルをマッピングすることも簡単に出来
ます。

この機能はもちろんいろんな利点はありますが、これを何故、
OSの根本的アーキテクチャとして掲げているのかが疑問なん
です。

それを言い出したら、Win32APIには、パーティション管理から
テープバックアップまで至れり尽せりの機能があるのですが、
それをMSが看板にしている気配は無いですよね。
MSが看板にしているのは、.NET のようなものですね。
過去にも、Direct3Dの宣伝はしても、API仕様の細かすぎる宣伝はして
なかったと思いますが、違いが分かりますよね？

>>60
いえ、#54 で現状のOSASKでは、自分のDSセグメントにしかマッピング
出来ないように理解したのですが、違うのですか。

>>62
そういえば、宣伝不足で誰も使わないから埋もれてしまって
せっかくの技術なのに後の世代に伝えられなかったものって
結構あるんじゃないかと思うけど、
なんかもったいないような気がするんだよね。

>>54
「マルチセグメント」にしても、少なくとも、アーキテクチャの
変更が行われた最新型のCPUを除いては、1タスク辺り、合計4GBの
制限が取れないことはご存知ですよね。

なお、例外を1BYTEアクセスするたびに発生させてエミュレーション
する手法はなしと言う前提で考えてますが。

>>62
OSの根本的アーキテクチャに含まれるのは違いないのではないでしょうか？

WindowsがAPI仕様の細かすぎる宣伝をしないのはユーザー層やビジネスモデルからして当然ですが、
オープンソースの未完成OSにそれを当てはめる事が有意であると考えているのですか？

>>66
「根本的アーキテクチャ」というのは、例えば、
マルチタスクか、シングルタスクか、
16BITか、32BITか、
APIを、DLLで提供するか、直接提供するか、
主要なアプリケーションを全てCOMモデルで書くとか、

そういうことだと思うんですが？？？？

メインメモリを３次キャッシュとして使う発想のOSって何かあったのかな？

お前らなにマジレスしてんだ？
相手しているのは人工知能、NOWSMART-LightConeAgent（NWSLCA）だぞ？

>>67
逆に、

タスク独立な線形アドレス空間を持つFLATモデルか、
タスク共通の線形アドレス空間を持つセグメントモデルか、

とかも根本的アーキテクチャの一つだと思います
（前者のモデルで、さらにセグメントも使えるというのは、
これが、NWSOSの姿です。両方の機能を兼ねています。Win32も
そうです。）。

不思議なのは、このアーキテクチャの変更は大規模になり、
簡単に変更できないのですが、OSASKでは、今の所、後者を
採用している点です。

> ちなみに、Win32API でも、１つのファイルの複数の部分を別々
> にマッピングできます。
これを知っていてOSASKではできないと考えるわけね・・・

ところで、根本的アーキテクチャにアクセス方法は含まれていないと思うんだが。
ファイルシステムは含まれてるが。

>>69
キーワードを検知してお約束の反論を書き込むのは「人工無能」。
よくできた「人工無能」との会話は意外と面白い。

>>71
いえいえ、OSASKでも十分出来るとは思ってますよ。
でも、敢えてOSの特徴として宣伝する理由はどこにあるのかな、と
思うのです。
ファイルシステムも、ある意味では根本的アーキテクチャですが、
最近のLinuxを見ても、多数のファイルシステムを扱えるので、
データ形態のように極々小さな位置付けになってきているように感じ
ます。言わば、ワード形式と、一太郎形式の違いの様な意味しか
なくなりつつあるのではないでしょうか。

つーか、セグメントアレルギーなんだろうな。
Intelも罪な事をするね。

＞＞KB単位のバイナリサイズを削ることに腐心している時点で、
＞＞4GBなんてファイルは眼中に無いんだよ。
＞そんなわけないでしょう？ あなたも決め付けるのがお好きなんですね。
＞上記のレスを読んで、誤解を解決してください。

あ、わりい。通じなかったか。
OSASKで4GBのファイルにアクセスできるかできないかって言えばそりゃ
出来るでしょ。でもさ、OSASKのターゲットアプリの関心ってそっちには
無いんじゃない? 巨大なデータベースをアクセスするエンタープライズOS
じゃなくて、軽快なクライアントOSを目指してるんじゃないの?
そうでなけりゃKB単位のバイナリサイズにこだわるなんて意味ないじゃん。
と、まあ、そういうことが言いたかったわけ。だからGBクラスのファイルが
どうのっていう雑音は気にするなって。

あと、「486必須」というのは俺の言い方が変だった。「i386系」と
読み変えてくれ。携帯機の分野ではi386系は必ずしも主流じゃないから
OSASKの載せられる範囲も限定されるね、ってことが言いたかったわけ。
OSASKが軽いことは疑ってないよ。そういう設計で作ってるんでしょ。

>>74
セグメントはWin32でもLinuxでも普通に使っているという話だと思うよ。

8086のセグメントは当時としてはそれなりに便利だったんだけどね。
高級言語と相性が悪いのは今もかわらないかも。
OSASKもASKA以外では真価が発揮できないなんて事態になりそう。

>>75
どちらかというと、とりあえずはエミュレーションを強化してほしいかもね。
考えるのが面倒な事はエミュレータがなんとかしてくれないのかな？

>>73
すると>>58まででいったい何を知らなくて何に対して謝ったの？

んで「ファイルシステムは含まれてる」というのはミスリードだったな。
スマソ。本家の「7つの柱」にも含まれていないし。
どこで、「OSの根本的アーキテクチャとして掲げている」んだっけ？

>>75
ソースをいじってKBというか数バイトにこだわるのは遊びのようなものだと言ってたような。
基本の設計は汎用OSを目指してるはず。

つか、最近では当たり前になってきた特徴がこれにもあるんだ。
って宣伝するのがなんか変な事なのかな？
世の中には当たり前の事がそうじゃなかったりすることが多いんだし。

それより、良く考えればできる事を簡単にはできない。
って宣伝する方がちょっと妙な気がするね。
まあそれが良心的って見方もできるけど、実際はそういうのって、
サポートが面倒とか責任逃れしたい場合なんじゃないかな？

逆に競争相手に関してそう言うなら単なる売り込み文句にすぎないと思うな。
まあ自分の土俵で言うなら構わないんだけどね。

・・・って、以前だれかがどこかでこれと似てるけどちょっと違う事を
言ってたような気がするな。気のせい？

Lightたんへ

誤: OSASK の設計にはこんな不備がある、こんなOSは糞だ！
正:「私の勘違いかもしれませんが、OSASK のこの部分はあまり良くない気がします」と、OSASK を疑う前にまず自分の知識不足を疑い、謙虚な姿勢でものを尋ねる


誤: NOWSMART-OSならばOSASKには出来ないこんなすごい機能がある！
正: NOWSMART-OS の宣伝をこのスレで行わない


誤: 同じ疑問を何度も何度も何度も何度も書く
正: 一度疑問をぶちまけたら納得ゆくまで議論し、その場で納得する

>>53
>念のために聞くけど、まさか、4Gを超えるファイルは4Gまでしかアクセスできないとか
>考えてないよね？

　これを実現する時、「ウィンドウ領域（ものみ領域）」をずらす
しかないんですよね。

　結局、

1. 少し部分的にアクセスして、
2. 「ずらして」

の繰り返しになりますね（順序は反対でもいいとして）。

「ウィンドウ領域」のサイズを、64KB に設定すると、
まさに、16BIT自体の far ポインタ、huge ポインタを
思い出すんですが、どこが違いますか？
「ウィンドウのサイズが大きくなった」ってことですか？

>>81

>誤: 同じ疑問を何度も何度も何度も何度も書く
>正: 一度疑問をぶちまけたら納得ゆくまで議論し、その場で納得する

経験からすると、議論にならずに直ぐに納得し合える人もいれば、
いつまで経っても分かり合えない場合もあります。

>>82 補足:
　Win32 API での、"File Mapping" は、「使いたいときに使え」
的だから、もし使いにくくても文句はないんです。
　でも、OSASKでは、「今までのメモリの概念を不必要とする大変革」
とまで位置付けているのですから、ありとあらゆる面で「メモリ」
の使いやすさを上回っていなければなりません。そうでなければ、
今までのメモリの概念が不必要にはならないからです。

むしろ、「ファイルアクセスの簡便化」になるんだ、と言う主張
だったとしても、「今までのファイル関数」よりずっと素直で、
高速で、扱いやすい特性が無ければ、おかしな話じゃないですか。

>>80
>つか、最近では当たり前になってきた特徴がこれにもあるんだ。
>って宣伝するのがなんか変な事なのかな？
>世の中には当たり前の事がそうじゃなかったりすることが多いんだし。

今議論している内容は、「メモリレスアーキテクチャ」と命名
されたもので、「最近では当たり前になってきた機能」なんて
いう位置付けには到底思えません。
「今までのメモリの概念を根本的に不必要とする」旨の
主張を見た記憶があります。

>>78

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

「ディスクキャッシュと仮想記憶の統合」

から一部抜粋:


>こんないきさつでOSASK上からメモリという概念は一掃されて、
>メモリレスなアーキテクチャーになったのです。
>メインメモリは超巨大なオンメモリキャッシュ用のバッファで
>しかありません。

>メモリがなくなったからといって、全てのアクセス方法が従来の
>ファイルアクセスのようにまどろっこしくなるわけではありません。
>メモリを確保するときに名前が必要なだけで、あとはメモリとして
>アクセスしていれば、自動的に仮想記憶ファイルが更新されるから
>です(仮想記憶の進化した形なので当然です)。
>このメモリ的なアクセス方法は、仮想記憶へのアクセスだけではなく、
>普通のファイルにも使えます。何といっても、両者にはもう何の差異も
>ないのですから。おかげで、ファイルアクセスは簡単になりました。
>それでいっそのこと従来のファイルアクセスのためのシステムコールも
>撤廃してしまおうかと思ったのですが、それは互換性を損なう恐れが
>あり、OSASKの精神に反するので思いとどまりました。

上記で、

1. 「何といっても、両者にはもう何の差異もないのですから。」
2. 「おかげで、ファイルアクセスは簡単になりました。」

の二文に物凄い違和感を憶えるんです。

メモリアクセスは、「ものみ窓」のようなものは要りません
（x86の16BITアーキテクチャでは必要でしたが）。
ならば、ファイルアクセスに「ものみ窓」が必要なことは、
「何の差異も無い」ことに矛盾しているように思います。

　2.が主張するようには、別段ファイルアクセスは簡単に
なっていないと思います。FLATに全位置にはアクセス出来ずに、
ものみ窓が必要なんですから。fread()でバッファに一旦
読み込むのと、扱いの簡単さは変わらないと思います。

なんか凄い人だね。言葉に縛られているというか。
あえてそうやってOSASKがダメだと言いたいだけだとは思うが。

>>82
昔を思い出して...それで？
フラットモデルを見るたびにZ80の頃、64KBの壁に苦しんだことを思い出すんですが、
どこが違うんですか？
サイズが大きくなっただけですか？

>>84
> ありとあらゆる面で「メモリ」
> の使いやすさを上回っていなければなりません。
今までの人生で不必要になったものが何かありますか？

>>85-86
では一般的でないものを特徴として掲げるのは当然だと思いますが？
たとえ利点だとは思っていなくても、欠陥だと思っていない限り。

>>87
> メモリアクセスは、「ものみ窓」のようなものは要りません（略）
> 「何の差異も無い」ことに矛盾しているように思います。
そうですね。世の中に差異が無いことなんてあったらおかしいですもんね。

> 　2.が主張するようには、別段ファイルアクセスは簡単に（略）
> 読み込むのと、扱いの簡単さは変わらないと思います。
標準的なアクセスではfwriteが不要になるわけですが？
あるいはfseekも。

さらに、扱いの簡単さに入るかどうかはわかりませんが、
物理メモリサイズを気にせずに4Gまでのファイルを丸ごとマッピングできるわけですが？
malloc+freadで物理メモリよりも大きいサイズを処理した場合、
どんなにがんばってもファイルを最後まで走査した時点で
スワップファイルが肥大化することは避けられないと思うのですが？

うがー、LightCone、なんで無駄にレス消費すんだよ！
目立ちたいのはわかったから今すぐ首吊って死ね！！

つうかさ、人の話も少しは聞こうぜ……。ﾊｧ

前のスレでもあったようですが、話の合間合間に他人の騙りが
入ると紛らわしいので、キャップをつけて発言していただけない
でしょうか。

Usage: 名前の後ろに #<任意の文字列> を加える

>>89
>標準的なアクセスではfwriteが不要になるわけですが？
>あるいはfseekも。

　小文字--->大文字変換などのように、ファイルのサイズを
変更せずに簡単なものの繰り返しで処理できるような場合には確かに
有利でしょう。それは認めます。


>さらに、扱いの簡単さに入るかどうかはわかりませんが、
>物理メモリサイズを気にせずに4Gまでのファイルを丸ごとマッピングできるわけですが？
>malloc+freadで物理メモリよりも大きいサイズを処理した場合、
>どんなにがんばってもファイルを最後まで走査した時点で
>スワップファイルが肥大化することは避けられないと思うのですが？

確かに、これは事実だと思います。

しかし、（典型的に巨大なファイルを扱う例として、）
ビデオファイルコンバータなどでは、巨大なファイルを入力し、
形式変換結果を、巨大なファイルへと出力するでしょう。

この際、両方の合計が 4GB を超えることを考慮すると、
ファイル全体をメモリ中にロードしてから処理するという技法を
使わず、小さなバッファに複数回に分けて処理するのが標準的
だと思います。

今日の私の発言で、「合計4GB の壁を越えられない」ことを指摘
したのは、OSASKが想定した方法を尊重したことを「仮に仮定して」
論じたまでです。
　もともと、ファイル全体をロードする技法自体に疑問があったの
です。物理メモリに絶対に全部読み込め切れそうなファイルを除い
ては。

>>89
でも、確かに利点はありますね。
今回の#89さんの指摘で、File Mapping の有効な使用法が
分かりました。
　ファイル全体をメモリに読み込む際に、SWAPファイルの消費を抑え
る効果的なアーキテクチャなんですね。

　しかし、それは、File Mapping に共通した利点であって、
依然、「メモリレスアーキテクチャ」と命名するほどのことかどうかは
未だに疑問です。


　これまでのメモリの概念に対するアドバンテージはなんなんですか？

（　´∀｀）

・・・別に只のスナック菓子にとんがりコーンって名前を付けようが、
それは勝手なんじゃないの？

>>92
「OSASKが想定した方法」ではない
今までの方法では「4GBの壁」を越えることができるんですか？

>>93
> 　しかし、それは、File Mapping に共通した利点であって、
> 依然、「メモリレスアーキテクチャ」と命名するほどのことかどうかは
> 未だに疑問です。
> 　これまでのメモリの概念に対するアドバンテージはなんなんですか？
>>86のリンク先を読んでください。>>29-30も参考になるでしょう。
漏れにはそれを読んだだけの知識しかありませんし、すべてそこに書いてあるはずです。

度々発言して申し訳ないですが、次のような疑問が出ました。

メモリを確保する時、必ずファイルも作成する、ということについてです。

仮に、いきなり、100MB 位のアドレスをアクセスしたら、ファイルサイズも
100MB に増加するのですか？

また、ページングアルゴリズムだと 4KB 単位で状態を管理し、アドレスが
連続ページがスワップファイル上で分散した箇所にあっても構わないのですが、
「メモリレスアーキテクチャ」ではどうなのでしょうか？
　前者の場合は、利用していないページは、SWAPファイルにも、実ページ
にも存在しませんが、後者の場合はどうですか？

>>96
>「OSASKが想定した方法」ではない
>今までの方法では「4GBの壁」を越えることができるんですか？

　メモリにファイル全体をロードしたり、ファイル全体をアドレス空間に
出現させるアルゴリズムを使った時点で、CPUの線形アドレス空間の制限で
ある4GBの壁が扱えうるファイルサイズの上限となってしまうのは、
どんな場合であれ、同様に成立すると思います。

　これを避けるには、逐次、バッファに分割ロードしながらファイルを
取り扱うことが必要になるはずです。なお、このような分割バッファリング
を行う限り、SWAPファイルの巨大化の問題はあまり生じないはずです。


　同様に、どんな、File Mapping アーキテクチャでも、
時々「のぞき窓」の位置をずらしていかない限り、CPUのアドレス空間の制限
が扱えるファイルの制限になると思います。

つうかさ、多少認めたのはいいとして、なぜ一般によく使う4G以下
（もっといえば物理メモリに収まる範囲内）のファイルを処理する
事に対する記述がほとんどないんだよ。

Ｌたんも認めるとおり、メモリマップトファイルを基軸としたOSASKの
ファイルアクセス方法では「通常よく用いられる」ファイルアクセスに
おいて手間も効率もウインドウを指定する従来の方式に比べれば良い。
たとえ4GBを越えてもウインドウを用いる旧来の手法でなんとかできる。

また、従来のメモリマップトファイルとの違いはないと思われる。
なぜなら、メモリレスアーキテクチャがメモリマップトファイルを使った
アクセス方法を指しているわけではなく、メモリ内にある全ての
オブジェクトがファイルとして管理されているというアイデアからきている
からであると漏れは認識している。つーか、Ｋ氏があんだけ何度も
書きまくってるから覚えているというのが正直なところ（ｗ

つーか、なんでこのくらいの日本語が読めないの？
もしくは意図的なミスリードか。

>>99

>Ｌたんも認めるとおり、メモリマップトファイルを基軸としたOSASKの
>ファイルアクセス方法では「通常よく用いられる」ファイルアクセスに
>おいて手間も効率もウインドウを指定する従来の方式に比べれば良い。

はっきりと断言できるほどの効率の向上は現れないのではないですか？

しかも、悪い面ももっているのですから。
fopen,fread,fwrite に類するやり方がサイズに依存せずに
安定して利用可能なことに比べて、サイズを気にしないと利用できない
のですから。そもそも、ファイル全体をロードまたは参照する方式自体
が根本的な弱点を持っているとも言えますし。

つまり、一長一短があるのです。

　Win32 においても、File Mapping の方が特に優れていると言うような
位置付けではないと思います。特に推奨しているわけでもないですし、
旧来のファイルAPIは日本語ヘルプがあるのに、日本語ヘルプも
整備されていないことからも察することができると思います。

　「ミスリード」かどうかは、厳密な基準が無いと思います。

>>99

>つうかさ、多少認めたのはいいとして、なぜ一般によく使う4G以下
>（もっといえば物理メモリに収まる範囲内）のファイルを処理する
>事に対する記述がほとんどないんだよ。

まず、実際には、4GB も空間が取れません。
一番制限がゆるいはずの FLAT モデルでも 2GB 程度。
現在の OSASK では、恐らく、(4GB/タスク数) 程度。

ファイル一個あたりが、数百メガバイトぐらいならざらに遭遇しますが、
こういうファイルを同時に数個開こうとすると、あっというまに、
アドレス空間の壁にぶつかるでしょう。内部で利用するメモリの量も
あることですから。

そして、その「壁」は、自身のコードサイズによっても狭められていくた
め、安定して見積もることが難しいものです。

　とあるコンバータを作った時に、こんな事情で、ファイルサイズの制限が
あったら勿体無い話です。そんなことで使えないくらいなら、最初から、
fread, fwrite で徐々にコンバートしていく手法を取った方が良い
と考えられます。
　
　扱うファイルサイズが、まずそこまで大きくならない場合も
ありますので、全く利用できないアーキテクチャではないと思いますが、
みながみな、好き好んで使うアーキテクチャというわけではないでしょう。

>>97
＞仮に、いきなり、100MB 位のアドレスをアクセスしたら、ファイルサイズも
＞100MB に増加するのですか？
さすがにそれはないだろ。穴空きファイルなんてCP/Mでさえサポート
されてたくらいだぜ。

>>102
穴空きファイル?

>>97

ファイルの一部に実体を持たせない事が可能なファイルシステムは実在します。
河合氏は多分知らないので、 OSASK では本当に 100MB 消費するでしょう。

>>100

OSASK の理論は、メモリとしてアクセスしているものが実は全部ファイルだったと
いっているだけで、ファイルを全てメモリにマップしないといけない訳じゃないはずです。

すなわち、メモリはファイルアクセスの一形態

L 氏は全てのファイルアクセスをメモリアクセスで実現する事を前提にしているから
話が合わない。但し、 河合氏が open, read, write といったファイルアクセスの API をまともに
実装しないと、L 氏の結論が正しくなる。

>>100
> fopen,fread,fwrite に類するやり方がサイズに依存せずに
> 安定して利用可能なことに比べて、サイズを気にしないと利用できない
> のですから。
サイズを気にする？
できればどんな状況ならfread/fwrite（Win32ならFileReadやFileWriteですか）
よりもサイズを気にするときがあるのか例を挙げていただきたい。

> そもそも、ファイル全体をロードまたは参照する方式自体
> が根本的な弱点を持っているとも言えますし。
どんな弱点なんでしょうか？
ファイル全体をロード、参照していることに対しての弱点というのは思い浮かばないのですが。

>>101
FLATモデルでもNTで最高3Gほど取れた気がします。
まあそれでも総合計3Gを超えるファイルに同時にアクセスできないということですが。

> 　とあるコンバータを作った時に、こんな事情で、ファイルサイズの制限が（略）
> と考えられます。
鳴かぬなら殺してしまえと？
別にマップドでも徐々にコンバートすればいいのではないでしょうか？
fread/fwriteで16MBずつコンバートし続けても
マップドで3GBずつコンバートし続けても
結局アプリが細かく書き戻すか、システムが細かく書き戻すかの違いということになって、
ハードウェアから見れば処理はタイミングと回数以外ほとんど変わらないはずです。
するとシステムよりも賢いアプリは存在し得ないので
システムの方が若干にしろ有利になったりもしそうですが。

> みながみな、好き好んで使うアーキテクチャというわけではないでしょう。
そういう時のためにfread/fwriteも存在するそうですが、
>>101のような理由でfread/fwriteを選択するのはちょっとどころではないほど勿体ない気が。

>>104
> 河合氏は多分知らないので、 OSASK では本当に 100MB 消費するでしょう。
よほどの初心者でない限りそれぐらい自力で対策できると思いますが。
IA-32というお手本まであるわけですし、単純にRLEにしてもいいでしょうし。
ちなみにとっくに>>97についてはレスが出ています。>>1のリンクからどうぞ。

スマソ。ミスった。
FileRead/FileWriteじゃなくてReadFile/WriteFile・・・

>>103
穴空きファイル。Unixだと「holeのあるファイル」という。>>104 氏の
言う通り、書かれていないブロックには実体がアロケートされない。
そこを読み出すと全て0に見える。Unixならls -lで見えるサイズは
見掛けのサイズ、ls -sで見えるのが実際に使われてるブロック数。
CP/M-80のカーネル (BDOS) はわずか3.5KBでそういうファイルを
サポートしてた。当時は感心したものだ。

確かにマッピング系では1バイト書き込んだら残りのページサイズ分を読み込む必要がある。
fwrite系ならバッファリングで無駄な読み込みを回避できる。

>>・・・勝手にOSASKの仕様を決めないでください。あなたが決められるのはNWSOSの仕様だけです。
おいおい、OSASKは川合堂ライセンスである以前にGPLライセンスであることも
認めているんだろ？
だったら、OSASKの仕様を決める権利は誰にでもある筈だぜ。
もうOSASKは川合氏のものではないんだ。
GPLが何の略語だか、ご存知だよな。

>>110
確かOSASKの公開版を誰かがGPLで再リリースしてもいいって話だったけど
その時はできるだけ混同しないような名前に変えてくれって言ってなかったっけ？

それにしてもβ版等のライセンスがイマイチ不明なんだよね。

>確かOSASKの公開版を誰かがGPLで再リリースしてもいいって話だったけど
>その時はできるだけ混同しないような名前に変えてくれって言ってなかったっけ？
GPLライセンスが適用されたソフトウェアは、他のどのライセンスにも優先させて
GPLが適用されなければなりません。

>>おいおい、OSASKは川合堂ライセンスである以前にGPLライセンスであることも
>>認めているんだろ？
２種類のライセンスを単一のソフトウェアに適用させることはできません。
「川合堂ライセンスである以前に」もなにも、本人がGPLライセンスとして
公開することを承諾した以上、川合堂ライセンスはその時点で自然消滅します。

GPLライセンスは排他的なのです。

>>112
本人は川合堂ライセンスでしか公開してないでしょ？
川合堂ライセンスによって、ライセンスを書き換えることが可能になってるだけだと思う。

いったんライセンスを書き換えられたパッケージに関しては
以降ずっとそのライセンスが適用されるけど、
元のライセンスのパッケージにまで影響するのはおかしいんじゃない？

PDSをだれかがGPLソフトに組み込んだら以降そのソフトはPDSとして公開できなくなるなんて
そんな話聞いた事がない。

GPLソフトでも他人に著作権の有るGPLコードを排除すれば
(GPLライセンスによってではなく個別に別ライセンスの了解を取れば)
別ライセンスで公開できるって聞いたような気がするけど、なにかと混同してる？

>PDSをだれかがGPLソフトに組み込んだら以降そのソフトはPDSとして公開できなくなるなんて
>そんな話聞いた事がない。
たくさんそんな話、聞いたことあるけど・・・
元がPDSでない場合も含めて。
一度、GPLが適用されると、その適用されたバージョン以降は全てGPL適用。
GPLを適用させた本人も含めて、そのソフトのライセンス形態を変化させることは
不可能だよ。例えば、GPLをやめて再びPDSに戻すことは不可。
このGPL感染に嫌気をさして誕生したライセンスがBSDライセンス。

※川合さん、このあたりのGPLの許諾書を熟読した上で、GPL配布を許可している
のだろうか？もしそうなら、何も問題ないですが。

>>GPLソフトでも他人に著作権の有るGPLコードを排除すれば
そもそも他人に著作権のあるGPLコードなんて現象は絶対にあり得ません。
なん人たりとも、GPLコードに対して著作権を主張することはできません。
なにせ、GPLのPはPublicなんですからね。

>>114
そもそも、
ライセンス（許可）を否定する許可というのが日本の法律上有効なんだろうか？

>>115
GPLはフリーソフトウエアのライセンスであって
PDSのライセンスではないでしょ？

>>112, >>115
ちゃんと調べて書いた方が良いよ。紛糾する前に原典を出しておくね。
* GPLにしても著作権は著作者に帰属する。というより、GPLの有効性は
著作権を基盤にしている。
http://www.gnu.org/licenses/gpl-faq.ja.html#WhoHasThePower
* コードの著作権者は、コードをGPLとそれ以外の複数のライセンスにして
提供することができる。
http://www.gnu.org/licenses/gpl-faq.ja.html#ReleaseUnderGPLAndNF

>>100
＞はっきりと断言できるほどの効率の向上は現れないのではないですか？
でも便利になるし、速度向上はあるんだろ？　じゃあ別に問題ないじゃん。

＞fopen,fread,fwrite に類するやり方がサイズに依存せずに
＞安定して利用可能なことに比べて、サイズを気にしないと利用できない
これらの関数を使ってもバッファをいくつ取るかという問題が根本に
残るから、ファイルサイズがでかくなれば結局やってることは同じ。
でも、ファイルサイズが小さいときに楽できる。

＞旧来のファイルAPIは日本語ヘルプがあるのに、日本語ヘルプも
＞整備されていないことからも察することができると思います。
よかったな、MSは、なくてもいいけど知ってるとものすごい便利な
APIはなぜか日本語化されてないという事があるみたいだぞ（ｗ

>>101
＞現在の OSASK では、恐らく、(4GB/タスク数) 程度。
これはセレクタを自由に使えるようになれば問題ない。

＞ファイル一個あたりが、数百メガバイトぐらいならざらに遭遇しますが、
どういう状況だよ。特殊な状況をさも当然のように書かんといてくれ。
たとえばMP3プレイヤーや単純なグラフィックソフトで読むファイルサイズが
数百MBになったりするのか？　しかも同時に複数開くってどういう状況だよ。

＞　とあるコンバータを作った時に、こんな事情で、ファイルサイズの制限が
＞あったら勿体無い話です。そんなことで使えないくらいなら、最初から、
それはLたんのプログラミング能力もしくは適応能力が低いだけ。
たりなくなったら再マッピングするというほんの少しの処理をかけばいいだけ。
マジでLたんはmmapとか使ったこと無いの？　めちゃくちゃ便利なんだけど。

＞単純なグラフィックソフトで読むファイルサイズが
＞数百MBになったりするのか？　しかも同時に複数開くってどういう状況だよ。
101じゃないけど、
ノンリニア編集とかビデオや音声（WAV）とか、3DCGを扱うと
圧縮してないデータを使うことが多いから
そういう事をやってる人は数百Mバイト〜1Gバイトくらいのファイルは普通に扱うよ。
単純なものしかできません、というのなら「すいませんでした」となりますが。
もちろん、将来的にはできる（予定）だとは思いますが。

ユーザーって「使い」ますが、「作る」人もいるわけで、
巨大なデータを扱う場合もありますからね。

ところで山手線で「Osask」という駅を見た時はびびりましたね。
よくみたら「Oosaki」でした。

>>104
>OSASK の理論は、メモリとしてアクセスしているものが実は全部ファイルだったと
>いっているだけで、ファイルを全てメモリにマップしないといけない訳じゃないはずです。
>すなわち、メモリはファイルアクセスの一形態

川合氏は、
「メモリレスアーキテクチャ」
と命名しています。
　本当はファイルなんだけど、アクセスの手段として、
メモリを介して行うので、OSASKではメモリに書き込むのではなく、
ファイルに書き込む、ということなんだそうです。

これまでの議論で納得したことは、このアーキテクチャが、
Win32APi でいうところの、File Mapping とほぼ同じということ、
ファイルアクセスの形態としてみたとき、SWAPファイルの増加を防ぐ
ことが出来る利点があること、です。
ですから、この、File Mapping アーキテクチャの利点は既に
認めています。


しかし、一番の要（かなめ）である所の、全てのメモリアクセスを、
必ずファイルへのアクセスと「見なす」ことの利点が、未だに分かりま
せん。

File Mapping までは、Win32 API でも、既に随分前から実現されており、
新規性は無いのですが、「メモリ」の概念をなくし、
ファイルを作って（？）、File Mappingの「のぞき窓」としてメモリを
「捉えなおす」ということは、OSASK の新規性と言えると思うんです。

しかし、その利点が分からないんです。

>?120

>＞　とあるコンバータを作った時に、こんな事情で、ファイルサイズの制限が
>＞あったら勿体無い話です。そんなことで使えないくらいなら、最初から、
>それはLたんのプログラミング能力もしくは適応能力が低いだけ。
>たりなくなったら再マッピングするというほんの少しの処理をかけばいいだけ。

結局それが、fread(), fwrite() を用いてバッファにロードしながら、
繰り返し処理していくことと、効率以外は変わりない、ということを
指摘しているのです。

違いは、旧来の方法ではメモリのブロック転送が、一回以上多くなること
です。読んで書き戻す時は、二回余分なブロック転送が必要だと考えられる
からです。

その意味では、File Mapping アーキテクチャは、速度効率は高いと
思います。
File Mapping アーキテクチャには、そういう利点もあるわけです。

しかし、ANSIの標準仕様である、fread(), fwrite() の人気は高く、
Win32 API の、File Mapping アーキテクチャも積極的に使う場面は、
限られているのが現状だと思います。

色んなアクセス法をもっていることはもちろん悪いことでは有りません。
しかし、OSASK は、このアーキテクチャを「メモリレスアーキテクチャ」
と命名し、基本設計の中核と位置付けている所が、納得できません。

1. 「のぞき窓」を介して「ファイルをアクセスする」アーキテクチャがある。
2. そのアーキテクチャは、File Mapping と呼ばれ、昔からあった。
3. そのアーキテクチャは、利点もある。
4. OSASKでは、メモリを確保すると同時にファイルを必ず該当させ、
メモリという概念自体をなくすというアイデアにおいて、新規性がある。
4. しかし、最後のアイデアがもたらすメリットが、納得できない。

というのが今の私の状態です。

>>122
> File Mapping アーキテクチャの利点は既に認めています。
>>123
> 結局それが、fread(), fwrite() を用いてバッファにロードしながら、
> 繰り返し処理していくことと、効率以外は変わりない、ということを
> 指摘しているのです。

> その意味では、File Mapping アーキテクチャは、速度効率は高いと
> 思います。

では>>100-101は何だったんでしょうか？
効率の向上を断言できるほどではないと言ったり、一長一短だと言ったり
fread/fwriteの方がいいと言ったりしているのは。
ひょっとして、「一短」がそのfread/fwriteの人気が高い
ということだとでも言いたいのですか？

それとも>>100-101はまったくの勘違いだったということでしょうか？

>>124
仕様の単純化じゃない？ CPUで言えば直行性のようなものか？
設計の美しさってそういう事を言うんじゃないのかな？

ところで（総てのデバイスを平等に）ファイルで管理しようというのは
元々UNIX的発想のような気がするけどどうなんだろう？

まあ画一的だから使いやすいかというと慣れもあるしそうもいかないけど、
速いし覚える事が少なくていいのだとすれば、それはメリットじゃない？

もちろん従来の仕様で構わないなら無理に宗派替えする必要はなくて
ブリッジ機構を介せば済む事じゃないか？ってずっとK氏は言ってないかな？
>>1のリンク先をチェックしていれば普通にそう読み取れるように思うんだけど、
それで納得できないのが不思議だな。

それが彼の言うところのエミュレータOSだと解釈してる。
単一（ユニ）なコアの上に多様（マルチ）なapiをエミュレートする存在がブリッジ
だと思うんだけど、ただ、そのブリッジの具体的な形が見えてこないのが
ちょっと不安だなあ。
予想ではマルチシェルとでも呼ぶべきようなものになるんじゃないかなと思って
期待してるんだけど、全然違うのかな？

>>125
「速度効率がいい」といっても、最近のCPUでは、メモリのブロック転送の回数
が少々増えた程度では、ディスクアクセスの本質的な速度に大差は
出ないはずだからです。
　ディスクアクセスで一番重いのは、デバイスのアクセス速度と、
デバイスから一般メモリへの転送速度だからです。
　利点があるのは、効率よりも、むしろ、SWAPファイルの増加を抑えられる
場合があることです。

　ようするに、「効率がいいことは効率がいいが、はっきりと誇れるような
差にはならない」であろう、ということです。

　これが、グラフィック描画であれば話は別ですが。

>>126
　もし、標準的なページングアルゴリズムと同等な機能を実装するために、
「穴明きファイル」のようなものが必要だとすれば、一般ファイルには
必要ないファイルの仕様をメモリ用のファイルのためだけに設計しないと
いけなくなるかもしれません。
　それで本当に、仕様や設計が単純になるんでしょうか。
　
　また、アプリケーションプログラミングのインターフェース的に見ても、
新たな慣れとノウハウを必要とする可能性もあります。

川合の「ちょっと一言」でミスを発見しました。
>>111が2つあります。

>>128
一般に、単純化したのなら、複雑な事を自力でやるには逆に面倒になるかもしれないね。
同等な機能が必要なら、素直にエミュレーションに任せればいいんじゃない？
printf とputsの関係みたいな。

まあブリッジ部分まで仕様に含めれば結局同じじゃないかと言う気はするけど、
要は、そもそもprintfのように複雑な仕様のものは移植用にしか必要じゃないんで
わざわざprintfを使わなくてputsで十分って話じゃないかな。

で、現状のそれでも、あの程度のゲームなら問題なく作れるって事じゃないかと？

そもそも、CPUに32bitの壁みたいなものがなければ、
原理的にはそんな事をする必要はないんでしょ？

>>121
さすがにそれはしっとる。ただ、それを一般の人が普通にプログラムする
なんていう風に言われるとありえないぞｺﾞﾙｧという意味で
「どういう状況だよ」と言ったわけであります。わかりにくくて激しくｽﾏｿ。

>>125
確かにそうなんだけど、どちらかというと漏れは少しでも柔和になってる
Lたんがたまらなく良いです。これなら議論できそう。

しかし、みんなメモリマップトファイルってあんまり使わないのね。
UNIX上のアプリって普通に使ってるって聞いたけど…。
ちゅうわけで激しく便利なのでおすすめしまつ。OSASKだけのものじゃない
わけだし。

あと、漏れは「メモリレス」と聞いたらメモリマップトファイルを想像せずに
メモリが３次キャッシュでファイルオンリーな状況を想像するのですが、
これって異常？

test040.lzhをみて思ったのですが、
やはり目玉ではマウスシグナル感度3を使わずに、アイドル時(もしくは定期的に)マウス座標を要求する方が効率がよいのではないでしょうか。

>>129さん
>川合の「ちょっと一言」でミスを発見しました。
>>>111が2つあります。

　すみません。そしてご指摘ありがとうございました。直しました。

>>127
> SWAPファイルの増加を抑えられる
> 場合があることです。
なるほど、これを「効率」に含めていなかったのですね。
含めるべきだと思います。
SWAPファイルに書き込まなくていいわけですから、その分速くなるはずです。
>>125の他の指摘についてはどうなんでしょうか？

>>128
そんなに複雑なルーチン/仕様が必要なんでしょうか？

>>130
> 一般に、単純化したのなら、複雑な事を自力でやるには逆に面倒になるかもしれないね。
そういう意味での単純化にはなっていないような気が。

>>131
そりゃ、漏れだって激しく感動しますたので、
言葉使いだけでもﾁｮﾄ丁寧にしたわけです。（ｗ

またまたとんがりタンの評価が急上昇中age

>>134
だね（ｗ
でも、

>>135
は微妙だね。L様の今後次第というか…。

>>131
Win32だと、複数プロセスでメモリを共有する時に使うという認識のような気がする。
漏れも普段はfopen/fcloseしてます。
mmapの方が効率いいのはわかるんだけどなんか面倒。

>>131
linuxでもコード領域を書き換えたりする場合以外はfopen/fcloseが主だと思う。
パイプとmmapは相性が悪い気がするし。

>>138
ｸﾞｸﾞｰﾙでmmap検索したらｲﾊﾟｰｲ出てきたYO！
少なくともlinux内部ではmmap使いまくりらしいぞ。ホントか？

mmapは普通使うだろ。
仮想記憶があればローダーもmmapみたいなもんだ、というのも有名な話だと思うが。
(通常はただmmap、とはいかないが)

>>139
fs/binfmt_elf.cを見ればわかる。

>>131-139 FYI

○"FreeBSD PRESS No.12" P124-130
　'UNIX Programming' No.16 ソケットの操作(第２回) 野首寛高 より引用

「これまでも、いろいろな場面で read(2) の代わりに mmap(2) を使ってコ
　ピー回数を減らす工夫がおこなわれてきているが、sendfile(2) で更にコピー
　の回数を減らす事ができる。 mmap(2) を使うと直接ユーザー空間へデータを
　読み出せるのだが、送信時にはカーネルのバッファ(mbuf)へのコピーが生
　じる(図１の(2))。これに対して sendfile(2) を使うと、ディスクからのデータを
　直接mbufに書き込めるため、コピー回数をゼロにできる(図２)」

>>123
誰も突っ込まないのか？

>しかし、ANSIの標準仕様である、fread(), fwrite() の人気は高く、

fread, fwrite ANSI C 言語の標準仕様であり、 OS の仕様とは無関係。
mmap と比較すべきは read, write のはず。

fread, fwrite が mmap で実装されていても問題は無い。

>>他の OS で「ファイルキャッシュと仮想記憶機構の統合」といっているのは、主に次の二点です。
>>・ファイルアクセス時に（メモリ上の）キャッシュにデータがあるにもかかわらず、プロセスに別のメモリを
>>割り当ててそこにロードするのは無駄だから、直接キャッシュを読み書きする。主に実行ファイルが対象
>>・空いている実メモリがあれば、そこをキャッシュとして使う。

>　これは僕もそうだと思っていました。多分他の方がOSASKの統合が他と同じだという指摘をなさっている
>場合、OSASKでの統合をこの程度だと思っておられるのでしょう。僕も最近のOSでこれくらいの統合が
>行われているであろうことは、想像はしていました。でもうまく書けていませんでしたが。

遅レスですが…
想像も何も、Microsoft が Windows98 を発表したときに、さも画期的な新機能であるかのように宣伝
していました。当時、ワークステーションの世界ではあたりまえでした。
もちろん、OSASK のではなく、一般的な OS の「ファイルキャッシュと仮想記憶機構の統合」のことです

OSASK の前提とするファイルシステムって、どれをベースにしてるの？
例えば、unix上のファイルをアクセスする場合、パーミッションの関係で
アクセスできない場合もあるし、そのファイルのユーザー取得などもできるけど
OS側がこれらの機能に対応していない場合、アプリ側からはお手上げになってしまう。

あと、ネットワーク上のファイル操作に失敗した場合の挙動とかもちょっと疑問、というか質問が。

>>128
穴空きファイルは全然難しく無いよ。そりゃFATみたいなので管理しようと
したら一気に複雑になるけど。ブロックのテーブルを持つファイルシステム
なら使ってないブロックをnullにしとくだけでしょ。だからCP/Mでさえ実装
できてた。Unixで穴空きファイルを使う最もポピュラーな例のひとつは
オリジナルのdbmライブラリだろう。あんなの20年以上前からあるんじゃない?
旧来のインタフェースなら適当なレコードまでseekして書き込むだけだよ。
何を以って「新たな慣れとノウハウ」なんだ?

>>139
Linuxでも他のUnix系OSでもいいから、strace <適当なコマンド名> |grep mmap
とでもしてみそ。

川合氏のいう、「最初の時点では、アプリケーションには一切メモリが
割り当てられない」というのは、Windowsやlinuxではとっくの昔に実現
されていることだと思われます。

Windowsの場合、プログラムコードも最初は一切、ロードされてません。
IPレジスタが、Diskからロードされてないところに差し掛かって、はじめて、
付近4kbだけロードします。

当然ですが、
static char a[100][1024][1024];
みたいに、100メガバイトの配列が確保されたとしても物理メモリを指定サイズ分、
消費しないばかりか、1バイトも確保されません。
アクセスされてはじめて、その付近、4kbが確保されます。

上記の現象は、VC++やBC++、あるいはlinux上でのGCCで簡単に確認できます。

（ま、もっとも川合氏も、OSASKでしか実現してない機能だとは一言も言ってないが）

OSASKのスロット形式ですが、「ハンドル方式に比較して根本的な欠陥」があります。

通常、ハンドル値とは一意の数字であることを意味します。
PCに電源を投入してから、OSを起動して以後、一意の数字でなければ決定的な欠陥が発生するからです。
それは、既にサービスによって破棄されたハンドル値の不法性を将来に渡って永久に約束するためです。

例えば、あるファイルアクセス権利をハンドルで返却されたとしましょう。
そして、このハンドル経由でこのファイルを閉じたとします。
そこからアプリケーション・プログラマー側のミスで、既に無効になった
ハンドル経由でファイルのアクセスをしてしまったとします。
この時、OS側は確実に拒否できなければなりません。
この機構を実現するには、アプリケーションに返却するハンドル値が二度と同じ
数値にならないことを約束する必要があります。

スロット形式にしてしまうと、ラップ関数でハンドル値返却を実現できるように
見えますが、決して一意の数値（ここではスロット値）を返却するわけでは
ありません。過去に返却したことのあるスロット値を返却する可能性があります。
アプリケーション側のミスで、同じスロット値ではあるけど
既に違うファイルを開いてしまっている（それどころか、全く別のサービスに
そのスロット値が割り当てられてることすらある）場合、ファイルへの違法書き込み
がなされても、アプリ側もOS側も感知することなく潜在的なバグが発生して
しまいます。

>>148
unixのopen(2)もfopen(3)も同様の欠陥があるなあ。
確かにシステム側で一意性を保証してくれたらありがたいけどね。
きちんとやるのは難しいと思うな。

>>148
つうかそれはむしろ「あったらありがたい機能」なんじゃないかと。
欠陥と言うよりは。

>>146
OSASKでは、現状からして今後もFATもサポートするはずですが、
それでも、無理なく「穴明き」ファイルを実現するには、若干
工夫が必要ではないですか？

ただし、そもそも、既存のページング方式で出来るすべての機能を、
本当にサポートする必要があるかどうかをまず検討する必要は有ると思います。

ページング方式では、線形アドレスを直接指定して物理メモリをマッピング
したりしますが、マルチセグメント方式では、一つのセグメントは単一
機能として、別機能には個別にセグメントを用意してしまう手もできない
わけではないからです。しかし、far ポインタ必須となり、効率は落ちま
すが。

>>143
それは指摘が細かいですね。

fread(), fwrite() は、read(), write(), ReadFile(), WriteFile()
などの代名詞だと思ってください。

　UNIX や Windows で実現されていることからして、利点があること
は予想はしていましたが、mmap() や、File Mapping の利点が
具体的に私にも分かって来ました。

　それでも、最初から一番疑問に思っていたことは依然変化が
ありません。

1. 既に他のOSで昔から実現されている機能である。
2. それ自体には利点がある。
3. OSASK ならではの新規性と考えられる部分については、利点が
良く分からない。
4. OS の基本アーキテクチャとして挙げるには、細かすぎる。

>>151
え、OSASKのメインファイルシステムってFATなの? なら大変だ。
あれだけ効率を気にしてるからFATなんてただの互換機能で、
メインfsには何か先進的なアーキテクチャを考えてるんだと
思い込んでいたよ。

FATで他のOSからも見れる穴空きファイルは難しいというより、
他のOSだとエンコーダを挟む必要がでてくるわけだけど、
メモリイメージなんかに限れば他のOSから見る必要があるわけでもなし、
特に問題ないんじゃないの？

>>153
> 　UNIX や Windows で実現されていることからして、利点があること
> は予想はしていましたが、
なら少しは調べてくれ。

>>154（&川合さん）
151にはFAT"も"としか書いてないけど・・・

>>155さん
>151にはFAT"も"としか書いてないけど・・・

　それはそうなんですが、文意からすると、FATをサポートするからFATの範囲を超えるような
ファイルシステムは難しいのでできない(やらない)っていう感じがしませんか？
・・・そういう趣旨なんだと僕は読みましたし、154さんもそう思ったんではないでしょうか。

Lタン個人の疑問、質問に答えるのに回答料金を
取ってOSASKの開発費の足しにするのはどうだろ
う。
Lタン社会人だし、OSASKのオープン開発に協力す
る予定はない（よね？）のだから社会常識として
十分成り立つ話だと思うが．

フリーのOSだからコンサルティング料も無料と
思っている程世間知らずではないよな（それでは
乞食並だ）
どうよ > Lタン

>>156
いや、>>146がFATでは複雑になると言ってるから、
素直にFATサポート上での話と受け取ったけどね。

というかそもそもシームレスなんじゃないの？
だとすると既存のファイルシステムに存在するバラバラな制限を
どうするのかは気になるな。
確か、ファイルがどこに存在するかは普通アプリは知らないんでしょ？

そもそも>>146から>>151ってつながってないような。
「同意」と言いたかったのかな？
なんとなく「穴空きファイルは全然難しく無いよ。」
しか読んでないような気もしなくともないけど。

>>157
立て読み？

>>158
差異はファイルシステムのドライバに一任するのが妥当じゃないかな。

>>153

　知　ら　ず　に　今　ま　で　偉　そ　う　に　

　語　っ　て　た　の　か　よ　…

その自信はどこから来るんだ？　Lたんホントはただのｱﾌｫなんじゃないのか？

>>152

read を あらゆる OS のファイル読み出しルーチンの総称としても、
不具合がないが、fread と read は実装水準が違うのだから
いっしょにしてはいけない。read, write は実装するしないを問題に
するが、fread, fwrite は実装可能不可能が問題になる。

おそらく、OSASK での fread はバッファを使用せず、（read なしで）
直接ファイルにアクセスする実装になるだろう。

>>161
効率を考えるとそれしかないと思う。
バッファの管理がいらなくなるから、readをバッファリングするより簡単かも。
ただ、4G越のファイルの取り扱いはどうする？
マッピングし直すしかないのかな。

効率といえば、なんか総合ベンチマークソフトってないのかな？

思うんだが、川合氏の最適化技術のそのほとんどはWindowsと共存可能っぽい。
Windows互換のｶｰﾈﾙを川合氏に作ってもらえば、世界中のWindowsはもっと
ハッピーになると思うのだが、どうよ？

決して、氏の提案する技術はどれもこれも排他的ではないし、逆にいえば
オリジナルOSにこだわる理由もないと思う。

>>160
如何に少ない情報で、結論を導くかが非常に重要だと思っています。

全ての情報を綿密に調べてからしか結論を導けないのはむしろ、論理
的な思考能力が低い可能性があります。

今回の場合でも、「File Mapping や、mmap() に利点がある」という
命題が真でも偽でも、最終的に OSASK の新規性と思える部分については
メリットが分からない、という結論は同じです。

　思考や論理展開に必要な情報を見極め、ピンポイント的に
必要な部分だけを調査することが出来るかが、非常に重要だと
私は思っています。やたらめったらやみくもに、何でも知ってしまえば
いい、という考え方は誤りに思えます。

>>165
確かに少ない情報から結論を導き出せる「カン」は重要かもしれないけど。

＞全ての情報を綿密に調べてからしか結論を導けないのはむしろ、論理
＞的な思考能力が低い可能性があります。
んな莫迦な、、、論理的な思考能力が低ければ、相反する情報を総合して
結論を導く事なんて出来やしないでしょう。

普通の人にとっては、情報が少なければ意味不明ですが、多すぎても
処理出来なくて、本当の意味がよくわからなくなる事があります。
そうして煙に巻いたり、隠蔽に使われる事もありますね、木は森に隠せと。

　思考や論理展開に必要な情報を見極め、ピンポイント的に
必要な部分だけを「発言」することが出来るかが、非常に重要だと
私は思っています。やたらめったらやみくもに、何でも言ってしまえば
いい、という考え方は誤りかどうかは知りませんが、快く思わない人は
多いように思えます。

>>165さん
>如何に少ない情報で、結論を導くかが非常に重要だと思っています。

　それには異議を唱えさせていただきます。

・一番いいのは、少ない情報で正しい結論を得ることです。
・次にいいのは、多くの情報で正しい結論を得ることです。
・次に駄目なのは、少ない情報で間違った結論を得ることです。
・もっとも駄目なのは、多くの情報で間違った結論を得ることです。

　つまりもし「正しい結論を得ること」ができるという前提があるなら確かに少ない情報で
結論を導けることは価値あることです。先見の明です。しかし誤った結論を出すくらいなら
情報を収集するべきであって、間違ったことを言ってしまった言い訳にはなっていないと
思います。今回の件においては、165さんはメモリマップトについてはもっとよく調べるべき
だったのではないかと僕も感じます。知らなかったから間違えた、というのは言い訳になりません。
間違えるくらいに知らないなら主張するのではなく、質問するべきです。自分が正しいか
間違っているかすら判断できないなら(判断を誤るなら)、もっと調べるべきです。

その必要な情報を見極めてない人がよく言うね。
あんたの得た情報ってなんだ？
みんなに教えられてやっと「メモリレスアーキテクチャ」が何かわかったんだろ？
あんたはそのOSASKの新規性が何かということすらわかってなかったんだよ。
次は新規性が何かわからないような新規性はダメだ、とでも言うか？（ｗ

>思考や論理展開に必要な情報を見極め、
本当は結論（OSASKはだめぽ）を肯定するのに必要な情報を選択してるだけだろ。

>最終的に OSASK の新規性と思える部分については
>メリットが分からない、という結論は同じです。
「分からない」と言うための必要最小限の情報ってどれぐらいよ？

ところで、>>126や川合さんのレスには答えないのか？

情報が内容なのでbochs絡みのネタを幾つか、、、だれか他に居ないのかな？

OSASKのフォーマットの仕方覚えてないんで動作は確認していませんけど^^;
FDCのコマンド4d(format track)ならbochs-1.4以降で実装されている様子ですね。
46はbochs-1.4.1でも実装されていませんけど。
以前OSASKがreadにこっちのコマンド発行していた時は、よくわからないので
e6の処理をそのままコピーして、OSASK本体にvmware用の書き換えをしてみたら
起動はした記憶があります。
・・・ということは画面に対応したパッチと一緒に当てれば2.0以前のバージョンも
試せるって事かな？bochsスレの情報を参考にすればビルドできると思います。

しかし改造bochsでvmware版が動いてくれるということは、
たった１バイト書き換えるだけで再コンパイル無しで動くということで、
ソースが出てないβ版でもすぐに試せるってことなんだよね、便利。

ただ、test40試して見たんだけど、なんかbochsだと表示系が重くて
追いついてない様子ですね、色々やってマウスいじってるとそのうち固まってしまう。
一度　CS:EIP = 00C7:00001D87　というのが出たことがある。
でもウインドウセレクトはできないもののマウス自体は動いてて仮想画面の
スクロールもできるし、countup以外はそのまま動き続けているから、
シグナルが溢れちゃってるだけのかな？よく分からないけど。

そういえばcountup6を複数動かすと途端にカウントスピードが2桁落ちるんだよね。
これもよく分からない、、、というかコレ最近の配布には同梱されてないような？

>>168
ちなみに、私は未だにOSASKの掲げる基本方針に懐疑的なままです。

「メモリレスアーキテクチャ」については、今後も深い理解に達すること
はないと思いますし、その必要も無いと思っています。

また、新しいOSのアーキテクチャについて、そもそも興味が有りません。

既存のアーキテクチャで不満が有りませんので。

Ｌたん、もうやめとけ。はっきり言って端から見てて痛々しいから。
男の負け惜しみや言い訳ほど見苦しい物はないぞ。

議論は上手でも開発は下手だな、Ｋ
開発は上手でも議論は下手だな、Ｌ

で、俺は、Ｌに対する評価のほうが高い。
正確にはモノを見せてなんぼの世界でのごく一般的な評価方法に過ぎないのだが。

Ｋもさ、こんなつまんねーとこで油売ってないで、さっさとＯＳＡＳＫ進めろよ。
え？あんたに言われる筋合いはない？
そんな貴方は、期待しないで勝手に見捨ててください？
そうはいわせねー。ＩＰＡに資金援助を求めている以上、国民としては完全他人では
ないし、完全無関係者でもない。
応援したくもなれば、叱咤したくもなるぞ。

>>173
漏れもL氏に対する評価の方が高い。
OSASK見てると、出来ていないから何とでも言えてるって感じ。

Ｌは少なくともまともな理屈通せっての。
こんなのＬとＫを比較する前の問題だろ。まともな大人の最低条件。

>>173
> そうはいわせねー。ＩＰＡに資金援助を求めている以上、国民としては完全他人では
> ないし、完全無関係者でもない。
なんだただのアフォか。
こんなところで油売ってないで少しは勉強した方がいいぞ。
え？あんたに言われる筋合いはない？
そうはいわせねー。日本に住んでいる以上税金を使ってるわけだから完全他人では
ないし、完全無関係者でもない。（ﾌﾟｯ

>>165
>最終的に OSASK の新規性と思える部分についてはメリットが分からない

　 ∧＿∧ 　 　 　
＜　｀ー´＞y-~~~
K氏の言う「仮想記憶とファイルキャッシュの統合による効率の向上」が、
実際にどれほど効果があるのか疑問、ということかな？
たしかに効率は効率であって、性能でもスループットでもないのだが。

>>170さん
>ちなみに、私は未だにOSASKの掲げる基本方針に懐疑的なままです。

　既存のものに満足できるような人には理解できません。そういう人にはOSASKはすすめません。

>「メモリレスアーキテクチャ」については、今後も深い理解に達すること
>はないと思いますし、その必要も無いと思っています。
>
>また、新しいOSのアーキテクチャについて、そもそも興味が有りません。

　ではなぜしつこく質問したのですか？・・・あなたは無意味なことをなさっています。
お帰りください。そして興味が持てるようになるまで、二度と来ないでください。
今まであなたのいいかげんな質問につきあわされたみなさんにとても失礼だと思います。

つうか、Lたん自分で自分の意見に信頼性がないと言っちゃってるような・・・


どうでもいい話だけど、OSASKが順調（？）に進んでいけば
4Gの制約がいつか問題になりそうだな。
マヌーなコンバータとかのfaqで
「ファイルが2Gを超えているとき、途中で急速にパフォーマンスが落ちる」とか（ｗ

>>178
本物？
こんな時間に・・・

こんな時間に2chでクダまいてるようじゃ開発が進むわけもなく。

まあ、効率効率言って机上で議論してても埓があかないことは多い。
アルゴリズムの計算量の評価とは違って、いろいろな要素が絡み合って
くるのがOSだ。俺のラボでがたがた議論しているのがいたら、
* 「何についての」効率なのか、対象をはっきりさせろ
(4GBのファイルアクセスだって、DBのようなランダムアクセスと
ビデオフィルタのようなシーケンシャルアクセスじゃ全然違うべえ)
* 実装してベンチマークを取れ。local optimizationだけ見て
global pessimizationになったら意味がない。
と言うだろな。
というわけで >>K よ。現状のOSASKで効率に関する懐疑論者を説得するのは
無理だ。せめて実使用に近い環境をエミュレート出来るレベルまで作り
込んだ上で、従来の方式と新方式の両方を実装して性能比較の数値を
出して、初めて議論の材料が出来るわけよ。
そこに至るまではじっと耐えてとにかくコードを書くこった。

あっ、超先生来てるじゃん、、、
前スレの最後のあたり見せたかったな、、、つーか遅いよ（ｗ

>>182
まあそうだし、説得する必要も無いと思うのだが、
実装について、K氏（或いは同程度に全体を把握している人）以外は
指くわえて見てるしかない状況はいつまで続くんだろう？
例えば、98版と一緒にディスク周り分離の布石を打つべきだった
と思うのは俺だけ？
これじゃどうせもう一度機種ごとに書きなおす必要がありそうだし、
二度手間じゃないかな。
どっかのエミュのように、ソースみた人がこれなら俺でもドライバとかを
メンテや拡張できるかな？という構造と支援体制が必要じゃないかと思う。
実際にする人がいるかはともかく。（というか居ないと困る気が？）
β版は勝手にハックもしちゃ駄目というんじゃ、何の為のβ版なのかわからない。
もっと非公式拡張のあるα版ブランチとかがだれでも流せるようにした方が
いいんじゃないかな？名前変えて別個にやれってのでもいいんだけど、
それだと後で取り込む時の障害になったりしないだろうか？

そういえば、当座不足するドライバをLINUXとかのドライバとかで
流用できるようにするって話はどうなったのだろう？

http://www.nifty.ne.jp/forum/fphys/event.html#00520

↑これとか見てると、Light氏の一連の2chでのOSASK指摘カキコは
なにか戦略的な臭いすら感じる。

Light氏が非合理なのは実はfakeなのでは？

非合理というか、逆に自分の常識に合わないものは認めようとしないジジイ
とかっているじゃない？
結論だけ見て内容検討せずにこんなもんは駄目だ。って言う人いるでしょ？
どうせろくでもないんだからそんな事するのは時間の無駄とかいってさ。

で、反論されるからちょっとは見てみるんだけど、欠点ばかり目について、
そこで思考停止しちゃうんで、なかなかメリットを認められないんだよね。

まあ、そういう対決も時として必要だと思うんだけど、別スレに振るべきネタかもね。
ここではなく。

ttp://www.oreilly.co.jp/BOOK/osp/OpenSource_Web_Version/appen_A/appen_A.html

もう一度貼っておこう。
失敗は繰り返さない方が良い。

で、Linus→K
Tanenbaum→L
にdefineしても難なく読める、言ってる事が似てる。
同じようなことやってるのよ、そして終わりは以下略

結果、LinusもTanenbaumもダメだったじゃん。
商業ベースでみたらどっちも散々だな。配布会社もレッドハッドのみ。
技術ベースで見てもlinux系もunix系も、「複数GUIアプリ間連携」という点じゃ、
Win3.1時代のOLEの足元にも及ばない。
自分はたまたま職業もプログラマーなんで、linuxの居心地は最高なんだが
それでもGUIアプリの方が効率よく作業できる大半のユーザーのことを考えたら
複合文書のコピペすらままならない現状のXを見ると、やれやれという感想。

Ｋ氏の未来像とは、ＧＵＩアプリまで含まれているのだろうか？
略語がGraphicalUserInterfaceではあるものの、Windowsの利点は
GUIアプリ間連携をOS側で責任もって本格的に管理した初めてのOSだった点
にもある。

「効率の向上」とは、具体的な問題を、Ai（i=1,2,3,,,N)とおいたとき、
具体的な速度を、F(Ai)、サイズをL(Ai)、
問題 Ai が実際に「出現する頻度」を、確率 Pi（0<=Pi<=1）、
とし、

E(F) = �捻i・F(Ai)
E(L) = �捻i・L(Ai)

のどちらか、または両方が小さくなっていることを言うのですから、
「実際に速く」または、「実際に小さく」なっていなくてはならない
わけです。

その際、問題の出現頻度 Pi が、非常に大きな影響を与えることは、
式の上からも明白ですね。

上の式は、アプリケーションソフトの高速化、コンパクト化について
適用したい時は、一つのアプリケーションソフトを細かい処理の
集合体と見なし、「問題Ai」を「内部処理i」に、Pi をその処理が
単位時間あたりに出現する頻度に置き換えるわけです。

一方、上の式を、「あるOS上で動くアプリケーションの効率」について
論じる時に適用したいときは、「問題Ai」を「アプリケーションi」に、
出現頻度Piを、そのアプリケーションの使用頻度、重要性、などに
置き換えるわけです。


つまり、OSの効率の高さを論じる時、他のOSと比べて効率が高くなる
場合だけに着目するだけでは駄目で、出現頻度Piを見積もって全体的に
評価する必要があるわけですね。

「効率」というのは、「平均効率」でなければならないわけです。

>>188:訂正

>上の式は、アプリケーションソフトの高速化、コンパクト化について
>適用したい時は、一つのアプリケーションソフトを細かい処理の
>集合体と見なし、「問題Ai」を「内部処理i」に、Pi をその処理が
>単位時間あたりに出現する頻度に置き換えるわけです。

Pi は単位時間あたりの頻度ではなく、内部処理iを行う回数を Ni
としたとき、

Pi=Ni/�年i

の間違いですね。すみません。

>>188
その手の話しはこちらでどうぞ、どうせみんな見てますから。

OSASKとNOWSMART-OSを褒めちぎるスレッド
http://pc.2ch.net/test/read.cgi/os/1031377826/

>>187
そうそう、そろそろぐいぐい以外に誰かその辺に明るい人が作ってよ。

今更スワップファイルの話なんだけど、OSASKにはスワップファイルがないわ
けではないよね。ないのは「The スワップファイル」というか、つまりシステ
ム内でひとつまたは数個しかないスワップ用にあらかじめ確保されたファイル
がない。ヒープをアロケートすることはそのヒープ用のスワップファイルを作
成することである。概念的にはまったく同一で、スワップファイルの確保方法
が違うだけ。

あらかじめスワップファイルを（ファイルシステム上に）確保する代表的なOS
としてWindowsしかしらないけど、この場合の利点は、あらかじめ物理メモリ
の量＋そのスワップファイルの量だけのメモリ空間を使うということを決める
ことができる。そうでない場合は、違う手段で空きディスク容量をキープしな
くてはいけない。OSASKでは、ひょっとしたら、ファイルに書き込めるサイズ
の上限が起動時に決められていて、ディスクが不足するようなことはないのか
もしれないけど。

物理メモリが存在しない現実的なマシン構成は想像しにくいけど、（書き込み
可能な）物理ディスクが存在しない現実的なマシン構成は容易に想像できるの
で、メモリレスという物の見方の方向性はあまり賢いとは思えない。

それはたぶんRAMディスクあたりを内部に構成してなんとかするものだと思われ。

つーかキャッシュとスワップの違いって何？

>>193
メモリレスというより、三次キャッシュ扱いでメインメモリレスって言う方が
近いのかな？

つまり
一次キャッシュ(CPU内）
二次キャッシュ(キャッシュメモリ）
三次キャッシュ（主記憶）
四次キャッシュ（4G内補助記憶）
五次キャッシュ（その他の補助記憶）

ってことなんだろうか？

>>180さん
>本物？
>こんな時間に・・・

　たまたま夜中に目が覚めて、ちょっと覗いてみただけです。その後またすぐに寝てしまいましたが。

>>181さん
>こんな時間に2chでクダまいてるようじゃ開発が進むわけもなく。

　別にそんなことはないと僕は思っています。一休みするときに来ていますから。

>>197
それはフルキャッシュアーキテクチャ（ｗ
まあある意味そう考えても正しいのかも知れんが。

> そして主記憶はメモリではなく、ハードディスクなのです。
ってこと。

とりあえずbochsについての情報はここだね。
bochs
http://pc.2ch.net/test/read.cgi/os/1021620622/
しかしK氏の所でもbochs版動かないのならばそっちの理由を調査するべきのような？

うーん、、、全体設計が出来るような人なら別個のOSを作ってるんじゃないかな？
普通β版というのは動作はするけど環境による設計バランスの確認とか
そういうのを調整するために必要なんだと思ってるんだけどな。
例えばあるAPIの制作をコミュニティ内で募集して何人かが設計して、
そのなかの一番評価のいい奴を標準に選ぶとか、そういう事があってもいいと思う。
そんな大げさじゃなくてもこの仕様は困るからこうしてくれとか
絶対こっちの方がいいとかあった場合、言葉でいっても解りにくいし
コードを実際にちょこっと直したほうが伝わりやすいって事とかないだろうか？

一旦リリースされた後だとバグ以外のそういう基本APIのちょっとした仕様上の変更は
難しくなるよね？よくわかってない連中（自分とかｗ)は、また誰かいちゃもん
付けてるだけとしか思わないだろうし、そんな状況でいつ対立するかもしれないような
設計上の協力なんて普通出来る人はいないように思うけど、考えすぎかな？

>>192

>今更スワップファイルの話なんだけど、OSASKにはスワップファイルがないわ
>けではないよね。ないのは「The スワップファイル」というか、つまりシステ
>ム内でひとつまたは数個しかないスワップ用にあらかじめ確保されたファイル
>がない。ヒープをアロケートすることはそのヒープ用のスワップファイルを作
>成することである。概念的にはまったく同一で、スワップファイルの確保方法
>が違うだけ。

「メモリ」という概念が OSASK にはない。これは全然違う。
そのため、「スワップファイル」に相当するものは存在しない。
あるのは、「スワップファイル」と同じ特性をもつ外部記憶装置上のデータだけ。

>>192
後半に付いて

ディスク容量が確保できる上限です。

canvasすげえage

>>186 "LINUX is obsolete"(Andy Tanenbaum, comp.os.minix) 関連

○「IT業界の開拓者たち (2002 脇英世／ソフトバンク パブリッシング )」 より引用

第５章　ユニークな異端の人々　アンドリュー・タネンバウム
「激しい議論の後、MINIXは教育用に機能を意図的に限定したOSで、
　Linuxはユーザーが希望する本物のOSを目指しているため、考え方
　が違うというあたりの結論が出て収束した。この論争でタネンバウム
　が損をしたのは、Linuxを激しく攻撃したことで、かえってLinuxの
　独自性を明確にしてしまったことである。」

>>198
Kさんもキャップを使っていただけないかなぁ・・・と書いてみるテスト・・・
名前の欄に「<名前>#<任意の文字列>」とすると、文字列に応じて「<名前>◆<エンコード後の文字列>」
の様に表示されますので、完全ではありませんが本人確認が少し楽になります。

脇英世って、MS-DOS時代はゲイツ、マンセーだったよね

えっと、K氏が「えせ」をやったように実装した上で設計を確かめたい。
と思う事は在るはずです。
で、そんなあやふやな段階で意見すれば恥かきますから、やりたい人なら
試作版を出して検証してもらいたいと思うんじゃないかと？
そもそもそれがβ版ですよね？

現状ではそれがいちいち許可が必要なので、フリーなライセンスが全然
開発の役にたってないように思えます。
もちろん、正式版として配付された後であれば可能ですが、一旦決まってしまった
ものを変更するというのはなかなか難しいはずです。

先程誰かが掲げていた文献の本文ですけど、
http://www.oreilly.co.jp/BOOK/osp/OpenSource_Web_Version/chapter08/chapter08.htmlの
カーネル空間とユーザ空間のところに書かれてる例のように、
重複するものを作り、盲腸として残すしかないと思います。

とにかく、現状は、実装を見た後ではじめてAPIがわかるという状態なので、
わかった時にはもう設計変更できないし指摘しても無駄、もしくは大変なので
多分殆どの人は消極的になるでしょう。

いや、そうしない為のブリッジだと言われるかもしれませんが、
一体どういうもので本当に同じように使えてオーバーヘッドがないのか、
まだ誰にもわからないわけです。

そもそもそんなことができるのならば、最初からブリッジとして設計してもらえば良くて
その中の優れたものを標準として採用すればいいだけなんじゃないでしょうか？

メモリレスのメモリとは何を指すのか？

もし物理メモリだとしたら、仮想記憶を持つOSであるならどれでもユーザプロ
グラムには物理メモリという概念はない。

もしアドレスを指定してデータを読み書きするメモリ空間を指しているのだと
したら、メモリの概念なしにプログラムは動かないので、本質的に同じ概念を
別の名前で呼んでいるだけである。

www.imasy.or.jp/~kawai/osask/comment.htmlから
＞ソースを出すというのは、僕にとっては面倒なことなのです。
＞バイナリを出すのだって面倒ですが、しかしバグチェックを
＞しないと一般公開が出来ませんから、これはしょうがないです。
＞できればやりたくないわけです。 しかも自分が集中していじって
＞いる部分は頻繁にいじるので、リリースした直後からソースは
＞どんどん変わります。

CVSリポジトリ公開、みたいな方法じゃだめなのかな。(管理システムはCVSじゃ
なくても良いけど)。既出だったらスマソ。
漏れはオープンソースソフトにパッチを投げる時はとりあえずCVSを見に行
って、もう修正されてないかとか調べるけど。
今まさに修正されつつあるけどcommitされてない箇所がわらかんのは仕方
ないけど、commit logを眺めればどのへんが集中的に開発されているのか
わかるし。

>>208

アドレスは全て、外部記憶装置上のファイルにマッピングされていることに
なっています。保存する必要の無いデータについても、モデルの上では
（物理的に）存在しないデバイスにマッピングしています。
全てのアドレス空間が外部記憶装置に従属しており、「メモリ」がそれ自身で
存在できない為、「メモリレス」といっているのです。

K 氏がこのように考えているだけであり、やってる事は従来の OS とまったく同じです。

>>210

メモリイメージがファイルになってるって話だと思ってた。
全部、永続オブジェクト、、みたいな。
明示的に破棄しない限り、ずっとOSASK上に存在する事になるんだと、
勝手に解釈しておりました。
従来とかわらない方式で、MemoryAllocateの文法変えただけって話なの？
つまらん。。

再びwww.imasy.or.jp/~kawai/osask/comment.htmlから
＞いやもちろんCVSでいいですよ、共同開発モデルに移行するとしたら。

CVSは一人で使ってもいいもんですよ。commit権は当面自分だけに
しといて、pserverで公開しておけば、自分の負担は一切無し
(普通にcommitするだけ)で、最新の情報を求める人はKさんを
わずらわせずとも直接CVSを見に行けると。

>>211
いや、永続オブジェクトであってると思う。
208と210は文体などからどうかんがえてもL様の自作自演。

>>211
結局は同じことかと。
ただそこに流れる思想、ひいては実装面を含めるか含めないかという違いだけで。

単純なスワップファイルシステムをもって
OSASKでのプログラムごとのメモリイメージをまとめて一つのファイルで
扱ってるものだとも言えるだろうし。

>>212

どうせなら CVSup にも対応して欲しい

>>211
OSASK はファイルアクセスとメモリアクセスとの区別をなくしているだけのはず。
（やっている事、というより出来る事は従来の OS と同じです。効率については知りませんが）
どのデータを永続オブジェクトとみなすかどうかはアプリケーションソフトの判断次第。
（単なるファイル（=メモリ）も永続オブジェクトといえますが）

>>213
信じるかどうかは別として、
8=9=29=30=31=143=144=161=210

前スレでもそうでしたが、河合氏の字をたびたび間違えていた事を謝罪します。

>>215
本当に謝罪する気があるのかと小一時間（略
×河合
○川合

215では自分がＬ様だということは否定してないし。

後追いで過去の経緯を「見る」だけならこちらをどうぞ
ttp://minix-up.sourceforge.jp/cgi-bin/cvsweb.cgi/LATEST/_OSASK/

自前で作る方向け：ソースを持つて来るMakefile (FreeBSD上でテスト)
ttp://cvs.sf.net/cgi-bin/viewcvs.cgi/cvsknit/cvsknit/defs/OSASK/Attic/Makefile?rev=1.1.2.1

まあ、スナップショットを出してくれというのがそんなに面倒だとすれば、
言う方も気がひけるのは当然なわけで、よっぽどやれる自信がないと
言わないし、言ったらやっぱりやらないわけにはいかないでしょう。
で、多分自分には手が出ないでしょうし。

結局、話は>>183のままなんだけど、
正直既存のものや拡張性に影響を与えずに新たな(試験的？)
apiを追加変更する方法がわからないんだよね。
モジュール化してあればサンプルと同じようにドライバ書け、でいいんだろうけど、
そこまで勝手に進めたらそれこそOSASKじゃない別のOSになってしまうだろうし。
というか全体を把握している人じゃないと無理じゃないかな？

というわけで、とりあえず指くわえてみてます（ｗ
まあ、ディスクドライバとかネットワークとか、その前にRTCとか、なんとかしたい
とは思うけど資料もないし、絶対自分には無理だろうしね、、、
フォントサイズ変えるのとか、高速パレット切り替えで疑似多色とか（時代錯誤？
簡単に出来たらおもしろそうとは思うけど、これはある意味アプリで試せる話だし。

まあ、何が言いたかったかというと、設計が難しくて時間がかかるというならば
もっとネタ振ればいいんじゃないかな？って事、逆に最初から決まってるなら不要。
一人で黙って時間かけてるより誰かにアイデア出させて、自分は他の所やってた方が
早いんじゃないかな？何かの規格のように誰かが反対してなかなか決まらない
ってものでもないだろうし。
でも問題がわからなければ誰も具体的な参考意見なんて出てこないっしょ。

時間かけてやっと決めてから意見がでてやっぱり改訂ということになっても、
年単位のサイクルなんて、今なんとかしたいって思ってる人は待ちきれなくて
不満だろうし、第一、二度手間で、いくら実装なんて簡単だよとは言っても、
やっぱり時間がもったいないよ。

210 です

>保存する必要の無いデータについても、モデルの上では
>（物理的に）存在しないデバイスにマッピングしています。

すみません､表現が誤解を招いていました。
これは、 >>193-194 あたりへのレスあたりを受けたもでのでした。
「保存する必要の無いデータについても」というよりも、「外部記憶装置が無い場合でも」というべきでした。
それと、マッピングの方向は逆でした。


>K 氏がこのように考えているだけであり、やってる事は従来の OS とまったく同じです。
とんでもなく訳わからん表現なので、書き改めます。
↓
K 氏はメモリという概念なしで設計しているが、アドレス空間が存在しないわけではないので、
従来の OS とまったくおなじようにみえる形でプログラムは動作する。


---------------------------------------
何度も間違えているので川合氏に繰り返し謝罪

そりゃそうだ。少なくとも同じCPUの上なんだからそうなるわな。

>K 氏はメモリという概念なしで設計しているが、アドレス空間が存在しないわけではないので、
>従来の OS とまったくおなじようにみえる形でプログラムは動作する。
エミュレータOSなら、従来のOSの模倣もできなくてはいけないので、
その通りだと思われ。
ただ、全てが永続オブジェクトって所に非常に興味をもった。
オブジェクトのシリアライズではなく、永続オブジェクト。面白そう。

ここで何を対象にオブジェクトと呼んでいるのか、つまり粒度が明示されてい
ないのでよく分からないのだが、もしアドレス空間全体が保存可能（常に最新
の状態が自動的に保存されているわけではない点に注意）であることで、その
内部に存在するあらゆるオブジェクトが永続だと言ってるのだとしたら少々残
念である。言い換えると、システム全体の保存とアプリケーション単位の保存
の間にオブジェクト性を特筆するような差異は見出せない。

ところで話が変わるが、UNIX 系 OS のサスペンドにファイルへの保存を追加したのが、
OSASK のタスクセーブという認識であってるだろうか。

サスペンドはOSを再起動した後も動くようには出来てないけど、タスクセーブ
は動く（ようになる）らしい。

>>224
ごめん、頭悪くて意味わかんない。

オブジェクトの単位は、オブジェクト指向言語レベルでのオブジェクト。
そこには、アドレス空間がどうの、って概念はなく、ようは、

Object obj = new Object;

とするだけで、永続化されるってのが興味深い。といってます。

内部のメモリイメージがどうのとか、実装に関しては、俺は興味は無いです。
通常のC++をつかって、C++のシンタックスそのままで、永続化されるメリットは
大きいんではないかな？ってイメージしただけ。
OSレベルで、OODBをサポートしてるみたいなものを想像しますた。

PSEとか永続エンジンを使わず、OSレベルでオブジェクトの永続化をサポート
してれば、面白いとは思います。俺的に。

Lﾀｿは臆病者になってしまった・・・。
ﾗｲﾊﾞﾙ消失。

正直、OSASKにおける「シェルを通して全ての権限をユーザーに与える」
という思想はものすごいと思う。アプリ側の環境をエミュレートさせて
おけばその挙動を制御できるんでしょ？　ウイルス入ってるかもしれない
あやしいアプリを実験するのに面白いと思う（ｗ

で、OSASKはいつになったらGUIへの本格始動をはじめるの？
ともあれ、NWSOS程度のGUI実現はいつごろに？

>>現時点ではCVSを僕が使うことはあるかもしれませんが、
>>pserverで公開はしません。それが負担なのです(作業が多いか
>>どうかというよりも、心理的に気に入らないわけです。
>>誰も見ないかもしれないものをアップロードすることが。
>>いかにも無駄っぽくて)。
ともあれ、SourceForgeかなんかにレポジトリをアップすれば？

http://sourceforge.net/

ここでプロジェクトをサクっと作成して、commitするだけだし。
誰も見てない！なんてことは絶対にありませんよ、OSASKなら。

SourceForgeのユーザーって不特定多数だから、osaskの宣伝にもなるし、
不特定開発者増加の糸口にもメリット多し。

>>230
（Xの）guiなんて、スクリプト(tcl/tk)でちょいちょいとラッピングすればいいじゃん
みたいな考え方では>>187は納得しないんだろうな。

問題は、内部情報を外部とやりとりする規約じゃないの？
機構は、ソケットだろうがシグナルだろうがスロットだろうがポケットだろうがレジストリだろうが
あれば使うでいい気がするけど。

窓だって、それがわからなければマウスなりキーボード乗っ取る羽目になるよね？

>>230
もはやNWSOS見るのもかったるいんで
どれぐらい離れてるか教えてくれ。

ところで、アプリへの入出力って、基本的には総てシェルを介してるってことで
いいんだよね？
親子だと別のチャンネルがあるかもしれないけど。

>>231に同意。
pserverを使う、というのは、「アップロード」じゃないですよ。
自分は普通にcommitするだけです。普段の開発と同じです。
ただ、commitしている経過が外部から見えているというだけです。

>>227
うーん、OODBとして使うためには、少なくとも永続オブジェクト部分と
アプリケーション部分は別々になっていてくれないと困るんじゃないか
なあ。永続オブジェクトの利点は、オブジェクトがそれを作ったり
使ったりするプロセスよりも長生きするところにあるわけで。
今のままじゃ、タスクが作ったインスタンスはそのタスクの中でしか
使えないんだよね?
何か誤解してるかな。

>>236

永続オブジェクト格納用のセグメントを作製すればいいんじゃないか。
タスクが終了しなくても削除せず、毎回再利用すればいい。

>>236

永続オブジェクト格納用のセグメントを作製すればいいんじゃないか。
タスクが終了しても削除せず、毎回再利用すればいい。

237 は間違い

>>227

new だとヒープに出来ちゃうから、 placement new のほうが良くないか。

>>238

その場合、永続オブジェクト同士のポインタはちゃんと同一セグメント内
として解釈されるのかな。あと永続オブジェクトにタスクローカル
オブジェクトへのポインタを格納しようとしたら例外になるかな。
この2つが出来れば簡単に永続オブジェクトプールが作れていいねえ。

>>241
よくわからないけど、スロットは関係ある？

>>241

ポインタは全部スマートポインターを使えばいい。
生ポインターは使うやつが悪いという事で…

>>241

OSASKでは、発想が違うんでは？
基本的に全てのオブジェクトが永続化プールへ格納される。
で、タスク間で、オブジェクト共有したければ、そーいう仕組みを作れば良い。
って事なんじゃないかな？
タスクローカルもタスクグローバルもなにも無い。
全部永続。
で、タスクグローバルにタスクローカルを格納しようとして、例外がほしければ、
そーいう仕組みを実装すれば良い。
どっちにせよ、永続オブジェクトプールは楽に作れそうな気がする。
俺は、メモリレスアーキテクチャは、なかなか良いアイディアだと思ってる。

>マウスシグナルを作っても実際にアプリを書いているのはI.Tak.さんだけなんですか？そりゃああんまりですよ。
修正してmakeし直さないと動かないのでbeta版で対応されてもすぐには試せないのですが。

「トイレのない家」
我が家にはトイレがない。
用をたす場所は各部屋ごとに用意してあるので、アクセスがしやすく、
セキュリティを考えることもできる。
トイレと同じ特性をもっているものであるが、トイレではない。

「「トイレのない家」 ではない家」
各部屋に用意するのは掃除やコスト面などのパフォーマンスが悪い。
最新技術を応用し庭に縄を設置する事にしました。
セキュリティ面については設置者が縄の設置場所を工夫すれば万全です。

>>246-247
きっとこれを書いたﾔｼはうまいたとえだと思っているのだろうけど……。

>>243
そうだな。もともと生ポインタ使わせて完全に透過的にやろうってのは
無理がある。

>>244
うん、俺も、うまくやれば面白くなりそうとは思ってる。

それを踏まえたうえで、永続オブジェクト話。
永続オブジェクトのメリットって、オブジェクトがタスク(プロセス)
から切り離されることと、オブジェクト間の参照がアプリ側で何も
気にせずに保存されること、だと個人的には思ってる。

例えば、あるタスクで永続オブジェクトをたくさん作るとする。
オブジェクト同士は互いにポインタで相手を指しまくってる。
で、そのオブジェクトを触るプログラムを大幅にバージョンアップする。
もちろんオブジェクトの構造も変わる。
で、再コンパイルしたプログラムを立ち上げる。と、以前の
永続オブジェクト達に再びアクセスできる。
とまあ、こんなふうになってて欲しいんだな。

永続オブジェクトだけ別セグメントに出来て、ポインタに透過的に
アクセスできるんだったら、わりと簡単に作れるだろうけどね。
ただタスクの状態が保存されるから永続だ、というのはちと短絡的
かなと思ったんで。

>>246-247
誤爆だね。どこのスレ？（ｗ

>SourceForgeのユーザーって不特定多数だから、osaskの宣伝にもなるし、
>不特定開発者増加の糸口にもメリット多し。
>ふむう・・・。その「宣伝にもなる」とか「開発者増加の糸口」には
>惹かれます。でもソースからOSASKに入ると、「なんだこの汚いソース
>は！」ってことで終わりなんですよね(苦笑)。 OSASKを使ってみて、
>理念を分かって、ついでにアプリも数個は書いてみて、
>それでソースを見れば、
vimだとかgccだとかunix界ではおよそ有名な、っていうかインフラ的
存在のソフトもSourceForgeにアプされてるけど、これらのソースって
「見た目は」めちゃ醜い。でも、そんなの問題ならない筈なのは、彼ら（主に外国人）も
百も承知だし、慣れっこなんでそんなことは杞憂だと思われ

>>249さんの言ってるのは、本格的なOODBっすね。
俺は、そこまで要求していなくて、シリアライズではない真の永続化ってのが
手軽にできる環境は面白そうだなーって思ってるだけっす。
OODBと一言でいってもピンキリですから。

OSデフォルトで、Easyな永続エンジンがあれば、俺はそれで満足です。
本格的なOODBは、ベンダーが作れば良いと思うし、OSはそれが簡単につくれる
土台を提供する、、みたいな、そんなスタンスが良いと思います。

＞「見た目は」めちゃ醜い
めちゃ醜い。
ちゅーか、あれで動いてるんだから、すげーなぁ。

誤解を恐れず言えば、はっきりいってGNUのソースは糞。
マクロ使いまくってもはやC言語と呼べないYO…。

CVSレポジトリをオンラインに公開すれば、Ｋ氏もその他不特定多数の人も
ソースを閲覧する最良の資料として働くのだが･･･
ちなみにＫ氏はいつもどのＯＳで作業しているのだろうか？
unix系Win系、どちらでもオンラインCVSレポジトリアクセスは容易なんで
（コマンドラインからでも可）、お奨めっす

*一応* OSASK-CVS
http://minix-up.sourceforge.jp/cgi-bin/cvsweb.cgi/

↑なんだ、レポジトリ公開がとっくにされてるではありませんか！それも半年以上も昔に。
アップ名義が全部 henoheno さんですが、これってK氏の許可済み？

>>257
MLには流れてたね。どこだか忘れたけど。

□minix-up 上に有るOSASKのCVSリポジトリについて

・minix-up project では MINIX のソースをまとめる
　ためにCVSリポジトリの構築ツール(cvsknit)を作成して
　います。

・cvsknit の汎用化のために複数の open source パッケ
　ージをテスト対象に使っています。OSASKはその一つです。

・テスト結果はデバッグのために、WWWインターフェース
　のみで公開しています。

・2chなどで議論する際は、URLとして以下をお使い下さ
　い。今後は極力URLが変わらないように配慮します。
　ttp://minix-up.sourceforge.jp/cgi-bin/l.cgi/l/os/


>>256 もう少し短くしておきました。

>>257 OSASKのファイルに 8month などと表示されている
　のは以下の履歴に沿って commit date を調整した結果
　であり、私の作業日時ではありません。
　ttp://homepage1.nifty.com/dreaming/osask/history.txt

>>258 [OSASK 3967]

>>259
henoheno = 123 ◆rBwDDzyw ですので。
よろしくお願いします。

そういや、リポジトリがオンラインにある状態で作業したことないなぁ。
123さんはいつもどのように作業してます？update と commit が手軽に出来れば
いいのだけど

http://minix-up.sourceforge.jp/cgi-bin/l.cgi/_OSASKtest05/OSASKtest/winman0.c.diff?r1=1.18&r2=1.19&f=h

↑例えば、このosaskのmain部分の変更（12日前）は、Kさんの作業？それとも123さんの作業？

乙です（　´∀｀）

>>261
それはもうごく普通に・・・
・必要とするブランチを使いたいだけチェックアウトして使います。
・commit前には cvs diff を読みながら commit log を考え、
　commit後には即座にWWW interfaceからも確認して
　それぞれ適切であるかどうかをチェックしています。
・WWWで覗いていて気に入らない部分があればすぐに直します。
・ログを遺すまでもない作業ファイルは Makefile などで半自動で
　commit させています。

>>262
前者に近いですね。
小柳雅明さんによる「リリース版の OSASK ソース + Makefile」のリリース日時です。
コミットログに挿入されているリリース日と、CVS上のタイムスタンプが
基本的に一致している事をご確認下さい。
http://minix-up.sourceforge.jp/cgi-bin/l.cgi/l/os/OSASKtest/winman0.c
http://homepage1.nifty.com/dreaming/osask/history.txt

それと _OSASKtest05 はまたそのうち 06 や 07　に変わりうるので、
URLとしては以下をお使い下さい。
http://minix-up.sourceforge.jp/cgi-bin/l.cgi/l/os/

>>262-263
以下、冗長かもしれません・・・

○ cvsknit は、複数のソースパッケージ (*.tgz や *.lzh) から CVS Repository
　を「編む」ための自動化ツールです。自動織機のような物です。
　http://cvsknit.sourceforge.net/

○コミット日付は何を指すかと言うと、ソースの位置付けをより明確にする
　ために cvsknit が (強引にも、設定した通りに) システム日付を OSASK
　のリリース日時に変更しながら commit した結果です。誰の作業日時でも
　ありません。

　※committerの名称がhenohenoであるのは「たまたま」です。

○winman0.c で言えば、その差分は
　・2002/08/04 に(小柳さんによって) リリースされた OSASK 2.7 から
　・2002/09/06 に(小柳さんによって) リリースされた OSASK 2.8 まで
　に行われた修正内容を意味しています。

○一覧で「7months」とか「12Days」などと表示されているのは、
　「修正が加えられた最後のリリースから本日(※動的)までの経過日数」
　 を意味しています。「あーこのファイル７ヶ月は触られていないな」とか
　「２週間前に修正入ったばかりじゃん」などと読んで下さい（　´∀｀）


雑談が活発になる事を祈っています。

　 　 　 　 　 ＼　　　　　　　　見　　　　　　　　　 大　　/
　　　　　　　 　 ＼　　　　　　 て　　　　∧＿∧　阪　 /
　　　　 　 　 　 　 .＼ 　 　 　 る　γ(⌒)・∀・ ） 人 ./　　　　　　ぅぉぇっぷ
東京人↓　　　 　 　 ＼　　　な .（YYて)ﾉ　　　）　　/　　　　　　 〃⌒ ヽフ
　 ∧＿∧ 東京＞大阪.＼　 っ 　　　 ｜ ｜　| 　 /　　　　　　　/　 　rノ
　（　´∀｀）　　　　 　 　 　 .＼！　　　 （＿_）＿） /　　　　　　　Ο Ο＿）***
　（　　 /,⌒l　 　 　 　 　 　 　 ＼　 　 　 ∧∧∧/　　　　　　『基準超える一般細菌』
　｜　/`（＿）∧＿０.　　 　 　 　 ＼　 ＜ 大　ま ＞ ＵＳＪで、園内３２か所ある冷水器のうち、６か所の
　（＿_）（ﾟ∀ﾟ；　）⊃⌒⊃←大阪人 ＼＜ 　 　 　 ＞飲用水から、水質基準を超える一般細菌が検出された
~~~~~~~~~~~~~~~~~~~~~~~~~~~~　　　　＜ 阪　た ＞ことが大阪市保健所などの調べでわかった。
―――――――――――――――＜　　　 　 ＞―――――――――――――――――――――
　　　　　　　 ＿＿＿　ｵﾗｯ!　　　　　　＜ か　 　 ＞　　　　　　　　　　ﾊﾊﾊ
　　　 ﾄﾞｯｶﾝ |　　 |　出て来い大阪人 　 ∨∨∨＼　　　　　 　 　 ∧＿∧
　 　 ∩∩　 |　 　|　　 | 　∩∩　　　　 /＼　│　／＼　　　 　 　 （　＾∀＾）＜あほか
　　　| | | |　 |　　 |　　 | 　| | | |　　 　 / 　／￣＼　 　 ＼　　　　 （ つ ⊂ ）
　　..(　　,,)　.|　 　|　　 |　(・ｘ・ ）　　 / ─（ ﾟ ∀ ﾟ ）─　　 ＼　　　 .）　 ）　）
　　/　　.つ━━ﾛ|ﾛ ﾄﾞｶﾝ l 　 |Ｕ　 / 　 　.＼＿／　　　　　　＼ 　（_＿）＿）　　　　　（＾∀＾）ｹﾞﾗｹﾞﾗ
〜（ 　 /　　 | 　 ｜ 　 |⊂＿　|〜./　 　 ／　│　＼ 　　　　　　＼『ひったくり全国ワースト１を３年で返上』
　　し'∪　　 |　　 |　　 |　　　∪　/おおさか〜おおさか〜　　　　 ＼太田知事は府内のひったくり発生件数
　　　　 　 　 ￣￣￣￣　　　　　/　 .∧__∧　 　 　　　∧__∧　　　　 ＼が２６年連続で全国最悪という
　　　　　　ｶﾞｯｷｰﾝ　　　　　　　/　　（ ﾟ∀ﾟ ）おおさか（ ﾟ∀ﾟ ）　　　　　 ＼汚名返上の期限を「公約」

CVS 導入を渋るあたり、Linus とどこか似ている。なんつて

>>265
それはOSAKAや





ってツッコミ入れて欲しいのかい？

はーい。
OS赤に早くして欲しいこと。

えせでもいいのでサウンドなるようにしてください。
（チップセットはとりあえず限定でもいいのでサウンドブラスターとか。）
それからハードデスクかCD-ROM読めるようにしてください。
これでmp3プレーヤーがあれば、とりあえず音楽鑑賞できるOSとなるよ。
みんなOS赤使う時間が増えてもっと普及して、発展していくかもね。

まだだめかな？

すでに名称の原形とどめてない…。＞OS赤

くだらんスレになったな。ここは一つ提案なのだが、
・Lightタン
・Daisuke
・超先生
この勇者３名がコテハンで登場していただきたいね。

そういえば、だれかM-MASLでも移植しないかねぇ？

面白そうなのでちょこっち質問。
メモリレスという表現は､物理メモリとは無関係に､
プログラムからはメモリとHDDの区別を特に気にしなくていい､ということなのでしょうか。
メモリ関係はプログラムから隠蔽されてOSが完全に受け持つし、
OS側からもメモリの区別はファイルとして解釈されるというように読みました。

感想としては､実は､思ったほど速くないのでは、です。
実データが出ていないのでどうなるかはわかりませんが､
ハードウェア的な細工がないと思ったとおりにはならないのではないかと。
仮想記憶とファイルシステムとを合致させるために、
OSの作業量がよけいにかかるのではないかと心配します。
（WINよりははるかにましでしょうけれど)
アドレスの展開にコストがかかるのではないかということです。
OSの負担も意外にありそうですし､そっち系が。
そのためのキャッシュなのでしょうが､OSにキャッシュのほとんどが使われてしまうと､
OSASKのメリットが減少するのではとも思いました。
杞憂でしたらごめんなさい。

ともあれ物理層とマッチしたファイルシステムだと確かにエミュレーションなどしやすそうですね。
仮想機器をファイル化する感じなのでしょうし。
是非がんばって作ってもらって､このOSでどれくらいの速度がでるか、
アーキテクチャの比較が行われるのを楽しみにしています。

面白そうなのでちょこっち質問。
メモリレスという表現は､物理メモリとは無関係に､
プログラムからはメモリとHDDの区別を特に気にしなくていい､ということなのでしょうか。
メモリ関係はプログラムから隠蔽されてOSが完全に受け持つし、
OS側からもメモリの区別はファイルとして解釈されるというように読みました。

感想としては､実は､思ったほど速くないのでは、です。
実データが出ていないのでどうなるかはわかりませんが､
ハードウェア的な細工がないと思ったとおりにはならないのではないかと。
仮想記憶とファイルシステムとを合致させるために、
OSの作業量がよけいにかかるのではないかと心配します。
（WINよりははるかにましでしょうけれど)
アドレスの展開にコストがかかるのではないかということです。
OSの負担も意外にありそうですし､そっち系が。
そのためのキャッシュなのでしょうが､OSにキャッシュのほとんどが使われてしまうと､
OSASKのメリットが減少するのではとも思いました。
杞憂でしたらごめんなさい。

ともあれ物理層とマッチしたファイルシステムだと確かにエミュレーションなどしやすそうですね。
仮想機器をファイル化する感じなのでしょうし。
是非がんばって作ってもらって､このOSでどれくらいの速度がでるか、
アーキテクチャの比較が行われるのを楽しみにしています。

あう、２重投稿になっちった。。。ｽﾏｿ

ちなみに思ったより速くないのでは､というのは、
おそらくこのOSのメリットが生かされるであろう､低速PCにおいて、です。
高速PCの潤沢なメモリ､キャッシュがあれば、こういう問題はあまり関係ないので。

アドレスの展開って？
このアーキテクチャ自体では既存のOSと速度はそんなに変わらんと思われ。
んでメモリ＝キャッシュってことのはずなんだけど、
OSがほとんど使用してしまうキャッシュってなんのこと？

>アドレスの展開
再配置のことじゃねーのか？

>>272
UNIXのVMのことが書いてある本を読んでみれば。
そのへんの話は一通り載ってるはず。

おーCVSが公開されてるし！
躁だ逝こう！

cvsのリポジトリ見た感じ、正直、あまり進みがよろしくないねぇ

あれだろ、今までのＭＬとかを読んでると、
どうも川合氏はダイアルアップ環境だから、
cvs pserver にアクセスするのが余計面倒なのでは。

メヌエット使った方がマシ。

じゃあそうしろ。

>どうも川合氏はダイアルアップ環境だから、
>cvs pserver にアクセスするのが余計面倒なのでは。
一言アップする手間の方が余計、面倒だろ？
pserverなら一度ダイアルアップすればloginできるしな。Windowsだろうがunixだろうが

　　　　　キ　　　 　 　 //　　　/::::://O/,|　　 　 　/
　　　　　　ュ　　　　　/　|'''' 　 |::::://O//|　　 　　/
　　　　　　.ッ 　 　 　 ＼ |‐┐ |::://O/ ノ　　 ヾ､/
　　　　　　 ：　　　　　　　|__」　|/ヾ. ／　　　　／
　　　　　　 　 ヽ ／＼　　ヽ___ﾉ　／ . へ、,／　　　　
　　　　　　　 ／　 ×　　　　/ 　{　く　　／
　　　 　 　 く　 ／＿ ＼　　 !､.ノ `ー''"
　　／＼　　　　　　 　''"　 //
　| ＼／､／　　 　 　 　 　 ﾞ′
　|＼ ／|＼￣
　　　＼|

川合堂って会社なの？会社ごっこしてるだけ？
もし後者だとしたらいい年して・・・な気もするが。

会社だけど法人じゃない...のかな...

よく見ると「企業ではありません」って書いてあった。

川合さんはほめるんだよな。たたえるんじゃなくて。
最近だとnishi氏に対する「お手柄です」はｶﾅｰﾘ気になった。特に「お」のあたりが。
さらに、ほめすぎ。ほめ殺ししてるみたいな。
礼もいちいち大袈裟だし。まあ他人行儀。

OSASKは自分のものという意識が強いのかな。
それは間違えていないと思うんだけど、
みんな川合さんのためにやってるわけじゃなくOSASKのためにやってるわけで・・・
単に気を遣いすぎなだけなのかも知らんけど。

言葉の選択も気になる。
特にこれってのは思い出せないけど、
だいたいほめるときやら礼をするときに皮肉っぽい書き方になるんだよな。
なんというか「せいぜいがんばってください」という文章みたいな感じで。
「しっかり〜」にすれば皮肉じゃないことは明らかで
「ま、せいぜい〜」とかにすれば皮肉だとはっきりわかるんだけど、、、
ってなやつ。



と日本語の怪しいヤシが言ってみるテスと

いい年して会社ごっこって言ってもさ、
会社入ってるってだけで、ただしかたなく働いてる人もいるんじゃないの？
もちろんそれだけで給料は入るんだけど。

その点河合さんは、今まさに自分から何かしてるよね。
もちろんこれから先、成功するのか完成するのか分からないけどさ。
先の見えないけど、何か目標があってやってるってうらやましいけど。

仕事にしばられない、そこに何か(未来)あるんじゃないかな。

いくつになっても親の金で生活できる人ってうらやましいねぇ。
普通の人は仕事しなけりゃ生きていけないんだけど。

>>291
あのなぁ、親の金で生活できないから困ってるんだろうが。
過去ＭＬにも出てるんだからよ、推測で話するのやめろよな。

>>291
ﾜﾗﾀ
IPAの話とかは君好みかも。

毎月毎月規則正しく、リリースエンジニアリングを通したソースを
公開されているというのはとてもマターリ（　´∀｀）としていいです
なあ。
（※過去ML読んでいませんが、傾向としては毎月の下旬から
　上旬ごろがリリースのタイミングですNe!）

>>294
確か、月の初めに公開だったような記憶が。

毎月一日にバイナリを一般公開するのが慣例だったような。
予定も全部そうなってるし。

>>295-296
情報どうもです。バイナリは月初めなんですね。
>>294 はリリース版のソースの公開実績の話ですた。

age

sage

OSASK 2.9 age （　´∀｀）

みんな マウス対応アプリ書けやｺﾞﾙｧ!

二重ポストになってしまった様で。
さらに多重投稿するのが怖いので、
これ以上のポストは控えておきます・・・（ ; ´∀｀）

＃なんて2chに書いてみる

>>302
ん？
今日からキャップがより長く表示される様になったのかな？（ ; ´∀｀）
一瞬焦ったじゃないですか。

TanakaOsaskってどうよ？

>>304
本人か・・・？
ぜんぜんディストリビュージョンになってないよコレ・・・。

>>305
そりゃ大して入れるものもないだろうからな。（ｗ
人に紹介するときには便利なんじゃねーか？

（ﾟдﾟ)ｳﾏｰ

>>304
つか、OSASK掲示板の方でも無視だ。
ひそかにひでえな。かなり冷たい･･･。

（ﾟдﾟ)ｳﾏｰ

（ﾟдﾟ)ﾎｼｭｰ

おまえら、よろこべ！
IPA未踏ユース採択内定だそうだ！

ADSLキタ━━━━━━(ﾟ∀ﾟ)━━━━━━!!　

ユース受かったのか。よかったね。
まあ早けりゃ、来月末ぐらいには契約書もらえるんじゃない。

それはよかった。
でもIPA受かったからと言っても何か変わるわけでもないんだよな。（ｗ
川合さんが金の心配なしで開発できるから開発力向上にはなるか？

IPAおめでと━━━━━━(ﾟ∀ﾟ)━━━━━━!!　

>>314
書類を作る手間が増えます。
お役所向けなので結構大変。

こくさんてのはRubyのぱちりっぽいけどRubyほどよくねえんだよ
糞OSなんだよ
ゆめ一杯ってだれもこんなのつかわねぇよ

>>317
おまえは未踏不採択だったんですか？
煽るくらいならsageろ

IPA合格おめでとう。 良かった。

OSASKをOSとASKの2つの成分に分解し、ASKのAをOに変えて逆から読むとKSO。
そしてOSとKSOの前後関係を逆転させるとKSO・OSすなわち糞OSになる。
>>317 はおそらくこの驚くべき事実を指摘しているものと思われる。

　　　　　　　　　ナ ゝ　　　ナ ゝ　/　 　 十＿"　 　 ー;=‐　　　　　　　　　|! |!　 　
　　　　　　　　　　cト　　　　cト　/＾､_ﾉ　 | ､.__　つ　 （.__ 　 ￣￣￣￣ 　 ・ ・　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 　
　　　　　　　　　　　 ,. -─- ､._　　　　　　　　　　　　 　 ,. -─v─- ､._　　　　　＿
　 　 　 　 　 　 ,. ‐'´　　　　　　`‐､　　　　　　　　__, ‐'´　　 　 　 　 　 ヽ, ‐''´~　　 ｀´￣`‐､
　　　　　　　／　　　　　　　　　　　ヽ､_／)ﾉ　　 ≦　　　　　　　　　ヽ‐'´　　　　　　　　　 　 `‐､
　　　　　　/　　　　 ／￣~`'''‐- ､.._　　　ノ　　　≦　　　　　　　　 ≦　　　　　　　　　　　　　　 ヽ
　　　　　　i. 　　　／　　　　　　　　 ￣l　7　　　　１　 ｲ/l/|ﾍ ヽﾍ　≦　　　,　,ﾍ ､　　 　 　 　 　 i
　　　　　　,!ヘ.　/ ‐- ､._　　　u　　　　|/　　　　　 l |/ !　! | ヾ ヾ ヽ_､l　ｲ/l/|/ヽlﾍﾄ､　　　　　　│
.　　　　　 |〃､!ﾐ:　　 -─ゝ、　 　 ＿_ .l 　 　 　 　 ﾚ二ヽ、 ､__∠´＿ |/ |　! |　 | ヾ ヾﾍﾄ､　　　 l
　　　　　　!_ﾋ;　　　 Ｌ(.:)＿ `ｰ'"〈:)_,` /　　　　 　 rｉヽ_(:)_i　　'＿(:)_/ ! ‐;-､ 　 ､__,._-─‐ヽ.　,.-'､
　　　　　　/｀ﾞi　u 　 　 　 ´　　　 ヽ　 !　　　 　 　 !{　　　,!　　 `　　 （ } ' (:)〉　　´(.:)｀i　 　 |//ﾆ !
　　　　_／:::::::!　　　　　　 　 　 　 ,,..ゝ!　　　　　　 ﾞ!　　 ヽ '　　　　　 .ﾞ! 　７　　　 ￣　　　　| ﾄy'/
_,,. -‐ﾍ::::::::::::::ヽ、　　　 r'´~｀''‐､　 ／　　　　　　　 !、　 ‐=ﾆ⊃　 　 /!　 `ヽ"　　　　u　 　 ;-‐i´
　!　 　 ＼::::::::::::::ヽ　　　`ｰ─ '　／　　 　 　 　 　 　 ヽ　　‐-　　 ／　ヽ　 `￣二)　　　 　 /ヽﾄ､
　i､　　 　 ＼:::::::::::::::..､　　~"　／　　　　　　　　　　　　 ヽ.＿__,.／　　//ヽ、　ー　　 　 　 　

>>320-321
(　´_ゝ｀)

>>320-321 は負け犬Ｌクン。

>>323
ちゃいます。

>>323
ゴ、ゴカイダーーーーーーーーーー！！

OSASK OFFあげ

>>322
大体、Mr.K自体、現時点では、NWSOSの方が、OSASKより完成度が高い
ことを認めているのだから、負けているのはOSASKなのは明らか。
将来は知らんけど。

http://yahooo.s2.x-beat.com/

>>327
よかった。生きてらしたんですね。

課金すること自体、今後の趨勢を見失ってないかい？＞NWSOS

>>330
　お金を循環させる社会を作らないとデフレが進行するから社会悪
になっちまう。

　日本人は、サラリーマン的な人が多いので、感覚が鈍ってるん
じゃないか。後先考えずに無償奉仕することがどういう結果になるか
考えない奴が多すぎる。
　「デフレ」の原因を深く考えないと。

んー、本物か釣り師か悩むレスだな・・・

今までのLたんはたとえば>>327にしてもいきなりOSASKとNWSOSの優劣の問題に持ってくるんじゃなくて、
もっとわけのわからない理論展開で振り回してから優劣の問題に持ってきてたような気がするんだよな。
まあ誹謗のネタが切れただけとも考えられるけど。

>>331なんかはあまりに元気がなさすぎる。無難なトンデモとでもいうか。
文体はLたんっぽいといえばそれっぽいけど、もっと異常発振してないとおかしい。

>>332
IP漏れまくりなんだよ。
>>329
なめんなよ、予管理人ども。

>>333
ひょっとして世界で5本の指に入るｽﾊﾟｰﾊｶｰの人ですか？((((　´,_ゝ`)))))ｶﾞﾀｶﾞﾀﾌﾞﾙﾌﾞﾙ

>>333
さりげなくゾロ目レスをかっさらうとは、
さてはおまえスーパーハカーだな？

>>333
なめんなよ、って猫のアレですか！ ((((（´∀｀　)))) ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

>>333
いつまでたってもこういう電波飛ばす奴って減らないなぁ

>>331
強制ｵﾌﾟｰﾝｿｰｽがまずいだけでそれ以外ならなんら問題なし。
MacOSXなんかどう言い訳するつもりだ？

>>338
Macintosh は、ハードウェアと合わせて販売している。
OS自体の値段は無料といっても過言ではない。
他のベンダのOSとの競争も存在しえない。
オープンソースにすれば競争が激化して立ち行かなくなる
デファクトスタンダードの世界とは事情が異なる。

さりげに笑えるのは金の循環とか言うだけの力をNWSOSに認めてる点だが、
>>331はつまりインターネットは社会悪だと言いたいのですね。

>>340
違うんだよ。
インターネット自体は社会悪ではない。
しかし、インターネットのような共産的な技術を開発できるのは、
必ず公的機関に所属しているものか、大学生などに限定されてしまい、
自由主義社会の理念から外れる。
公的機関所属の人の行動は、自由ではないから。

ちなみに、インターネットの技術を強調する人がいるが、民間企業が
やったら、もっと良いものが出来たはず。まるでオモチャの様だ。

>>339
自分で墓穴掘ってるぞ（ｗ
つまり、そういうビジネスモデルを考えれば良いだけのこと。ｵﾌﾟｰﾝｿｰｽが
悪い訳じゃなくて、戦略の一環として使えばよいだけ。ビジネスを確実に
阻害するGPLみたいな強制ライセンスは確かにまずいと思うが。

>>342
インターネットは元は軍事用に開発されたものだったって知っとるか？

>>341
いったいおまいさんはどこの国の住人なんだ？（ｗ
そりゃ金日正大学とかの学生なら自由に行動できないのかも知れんが。
しかも色付きの技術って・・・
ちなみに自由主義社会は共産主義を選択することもできますが何か？

>>342
インターネットの技術って何よ？
ソフトウェアからハードウェアの末端まで技術の塊ですか何か？
昔から民間企業が多数参加していますが何か？

>>343
あなたは企業戦士確定。

>>344
>インターネットの技術って何よ？
>ソフトウェアからハードウェアの末端まで技術の塊ですか何か？
>昔から民間企業が多数参加していますが何か？

　インターネットが、民間では絶対生まれなかっただろうって
言ってるアホがいることに対する反論なんじゃないの。
　実際には、民間がやっていたとしても技術的な困難は全くなかったはずで、
公的機関ならではの箇所があるとすれば、規格統一に関してのみ。

＞公的機関ならではの箇所があるとすれば、規格統一に関してのみ。

これが一番難しい罠（ｗ
これがなければ今みたいな"inter"netにはならなかったか、なったとしても
かなり時間がかかっただろうね。DVDとか見てるとそう思う。

>>346
> 　インターネットが、民間では絶対生まれなかっただろうって
> 言ってるアホがいることに対する反論なんじゃないの。
技術的見地からそんなこと言うヤシはまずいないと思われ・・・
>>342は単に「民間＞＞＞公的機関＝インターネット」って言いたいだけだと思うんだけど。

んで、規格つーか、相互接続が問題になるんじゃねーか？
規格なんかは多くても三つぐらいで収まるだろうけど、
たとえば民間企業がアメリカとの間に光ファイバーの一つも敷いて、それを解放するかな。
国内のネットワーク間ですらボロボロだったのに。
ものすごい勢いで統廃合が進まなきゃ未だにそうだったと思われ。
最悪”近代的”な企業がそれぞれの専用WANを使用して電子メール使ってるような状況になってたかと。

>>348
>最悪”近代的”な企業がそれぞれの専用WANを使用して
>電子メール使ってるような状況になってたかと。
　もし、独占状態でない前提でこうなっていたら、今みたいな情報漏洩の
危険性は無かったかも知れず、むしろ良かったりして。

　今のインターネットは、情報を伝える時に色んな場所を通過するため、
途中に悪い人がいるといくらでも情報を吸い出すことが出来てしまう。
そのために暗号化とかあるけど。

　話は変わるけど、工学の世界では「公的機関」の方が進んでいるわけで
はないということは感じる。そもそも、物凄い基礎理論になれば、
工学ではなく数学の世界になるし。

>>349
今でも専用回線持ってるところは持ってるわけで。
インターネットと競合するものじゃないからなあ。

民間と公的機関どっちが進んでいるかは知らんが、
戦略やらコストやらでどうしても民間＜公的機関に見えるという罠。
役に立ちそうにもない研究でもできるし。
でも公立大学も利益あげる研究を推奨するようになるみたいだなあ・・・

まあそういう（？）ところでOSASKにも生きる道がありそう。
特にMSはUI以外の技術開発は軽視してるみたいだからなあ。

GNU C 移植できちゃうの？
クロスコンパイル？MJD？

つーか、古いTOWNS版GCC&GASを移植するとかした方が
手っとり早い気がするなあ。
まあ結局最新版欲しければ同じ事だろうけど。

というか、本家と仕様を変えるつもりなら、バージョン上がる度に
変更個所洗って移植し直す事になるの？

>>352
それほど最新版を追っかける必要もないけども
どうせ移植するのなら最新版を、ってとこじゃないか？
だからバージョンが上がるたびに追ったりはしないと。


(´-`).｡ｏＯ（ところで別にフロッピ一枚に収められなくてもいいんじゃないかなあ）

binutilsは無視して、gccでnask(だっけ？)のソースを生成出来るようにする方が
簡単な気がする。

インターネット＝いろんな機種で動くOS
専用線ネット＝いろんな機種
TCP/IP＝互換機
って感じなんだろうね。
元々インターネットなんて専用線ネット同士を繋げてやりとり出来るように
しただけのことで、別にTCP/IPなんて利用できる規格の一つでしかない。
でも、専用線ネットの仕様に合わせていちいち変換したりするの面倒で
どうせ独自仕様の部分は共通で使えなくて無駄だから、
標準的にそのまんま動く奴が普及しただけだと思う。

>>354
そもそも-mnocygwin オプション付ければMinGW相当になってcygwin.dll無しで
動くし、いっその事cygwin自体OSASKに移植してしまえって感じだけど。（ｗ

とりあえずOSASK用ライブラリをnewlib仕様とかいうのにすれば
cygwin（というかlinuxでもなんでもいいけど）-gcc上でクロスコンパイル
できないんだろうか？gcc自身も

というか、cygwin環境でOSASKコンパイルできないのは私だけ？
lccは外の別パスに置いてあるんでライブラリの呼び方がよく分からなくて
makefileは見慣れない構造だし。

一時期はWinコンソールをエミュするから
コンパイラを移植する必要はないみたいなこと言ってたのに・・・。

ところでlccってGNUライセンスじゃないっけ。
ちがったか。でもソースは公開してるな。

>>356
それってlcc-winじゃない方のlccじゃないか？
lcc-winはソースは売り物だぞ。
www.cs.virginia.edu/~lcc-win32/
http://www.q-software-solutions.com/lccwin32/buy.php

gcc移植は昔から予定にあったような気も。
コンパイラなかったら移植もしにくいだろうから、
卵と鶏みたいなものかと思われ。

ところでGCCの文字コードの話って何？
国際化関係のライブラリ？

そうじゃなきゃコントロールコードを誤認しなければいい話じゃないの？
先にコントロールコードを処理しておくのは駄目なんだろうか？

NLS対応のような気がする。
プリプロセスか、文字列定数の処理あたりで出て来たのか？
あれだけじゃ話が見えてこないが。

OSの性能ってどうなんだろ。
PC使用用途トップ１０に入る機能だけあればいいよね。
例
1.文字制作、表計算
2.写真画像鑑賞、保存、編集
3.ネット
4.開発
5.エンターテイメント、ゲーム、動画、音楽

これだけ実行出来る環境で、起動速くて安定してればいいんだけどね。
文章と画像鑑賞とネットだけでもいいんだけど、
それだけに最適化して実現したOSって、どのくらいのスペック必要なんだろうね。

>>360
OSASK風に膨らませては。

1a. 高速反応性と特化したUIでテキストを踊る様に書ける環境
　（日本語入力はInput Methodが要るのでフロッピーに収まらない・・・）

>361
いや、漢字直接入力方法がいろいろあるじゃないか（ｗ
慣れれば高速に書けるし、サイズもとらないぞ。

1b. フロッピー一枚で関数電卓
　計算結果はテキストとしてFDに保存もできます

localeの仕組みと漢字変換辞書って統合できないかな？

いや、今使ってる辞書、カタカナ語打つと英単語に変換してくれるんで。

>>364
（･∀･）ｲｲ!

発展させればフリーの多言語翻訳エンジンになるね。
OS作るより遥かに難しそうだけど。(-_-;)

>>362
今日思ったんですが、昔のPalmに当時組み込まれたJ-OS、
あれは確か1MB弱程度だったような気がしたのを思い出しました。

>>366
J-OSというのは当時英語版しか無かったPalm上で日本語の表示と
シンプルな漢字変換および遅延変換を実現させるソフトウェアですね。

さて、彼らが頑張って各種OSのエミュレータ（？）を作ってくれたら、さくっとLinuxに組み込むか。
WINEの開発状況からしてOSのエミュレータ（？）作るの凄く大変そうだけど。









逆に、Linux用のosaskエミュレータを作るってのはどう？

>>368
そういえばトロンのえみゅとかってありそうでないね
スレッドとか機能単独ではあるのかな？
ただBSDソケットがあるからといってBSDじゃないだろうしなあ。

つか今のが本物というわけでもないから、あったらそれはエミュじゃなくて
ファミリーのOSの一種ってことになるんだろうｙか？

>366
そんなこと言い出したらMSX用の、とか言おうとしたけどサイズ忘れたや。(´･ω･`)
まあ近くにあったジャンクワープロの場合
256KBのROM３つでフォントからプログラムまで入ってて、
構造から考えると無圧縮なわけで、、、
ただ、>361の要求を満たすにはそれぐらいのサイズではできそうにないかと。
まあアイディア次第なわけだが。

>>368
その行為に意味があるかどうかは疑問だけどな（ｗ

あの「hi」って何なんだろ？

ｴﾐｭﾚｰｼｮﾝする時は普通ｴﾐｭﾚｰｼｮﾝ対象よりｷｬﾊﾟｼﾃｨの大きな環境でｴﾐｭﾚｰｼｮﾝするのではありませんか？
OSASKには他の何かをｴﾐｭﾚｰｼｮﾝできるｷｬﾊﾟｼﾃｨがあるようにはとても。。。

>>373

そりゃ、「現状では」無理だろ。
K氏もそう

ｽﾏｿ、途中で誤爆した。

そりゃ、「現状では」無理だろ。

K氏も今は、まだまだであると認めている。

ただ、いずれ使えるOSになる日が来るはずなので、
そうなったらきっと、ｴﾐｭできるような環境になるはずだ。


と言いたかった訳だが。

それは何世紀後ですか？
現状では永久にその日は来ないように思われるのですが。。。

すべての勝負は最初の一手で勝敗が決まる物なのですよ。

　お久しぶりです。面白い意見なので、ちょっと茶々を入れてみます。

>現状では永久にその日は来ないように思われるのですが。。。

　そうですか。373さんがそう思うのは自由です。僕はかまいませんよ。僕だっ
て絶対にできるなんてお約束はできませんし。

>すべての勝負は最初の一手で勝敗が決まる物なのですよ。

　これが面白いです。よくわからないのですが、もし最初に間違ったら絶対に修
正がきかないということなんですよね。面白い考え方ですねえ。

　参考までにうかがいたいのですが、どんなことを最初にやっていれば、「でき
そう」に思えるものなんでしょうか？

要はｷｬﾊﾟを広げるのを毎回先延ばししてるから
いつになっても出来ないってことを言いたいじゃないかと？
とりあえず大容量ディスクが使えないとメモリが遊んでるしなあ。

ドライバとかはスロット使えば作れるのかな？

>374
煽りにマジレスｶｺｲｲ!



と。

NPOって。やばくね？
そろそろきたか？ｗ

ちょっと質問。
例えばテキストデータに関しては、エディタの内部形式フォーマットを
そのままファイルフォーマットにしてファイルに直接読み書きするのが
OSASK流なんだよね、確か。

それだと、1文字でも追加書き込みしたらオープン時のファイルサイズを
越えちゃうと思うのは、俺が頭悪いからですか？

それとも、いくら編集してもファイルサイズが変わらないフォーマットが
あるのかな？誰か無知な俺に教えてください。

どうやら季節の変わり目で>380にお迎えが来たようだ。おむかえでゴンス。

>381
編集可能サイズを制限して、ファイルサイズを固定にすればできるだろ。（ｗ

今思ったんだけど、Win2kのNTローダの日本語フォントと
OSASKの日本語フォントが同じっぽい…。

同じ…だと思ったら、微妙に違った(汗

>>382
漏れに迎えかいｗ

お前ら6時からチャット会だそうですが、誰か参加しますか？

参加してるが…リロードめんどいすぎ

>>380
NPOと言ってもたとえば学会だとか、普及会だとかもあるでよ。

>388
henohenoたん？何にしろ乙

>K
381ﾀﾝはつまり、
「ファイルマッピングじゃファイルサイズ変更できないこと考えてないだろヽ(｀Д´)ﾉﾊﾞｰﾔ」
って言いたいんじゃないのかなあ。煽り方がヘタすぎてよくわからんようになってるけど。
漏れも追加書き込みをどうさせる気なのかは知りたいな（ｗ

>K
>テキストエディタみたいにファイルサイズを増減させながらアクセスできるわけです。
そりゃそうだ。
それにも気付かずにそもそも書き込みのできなかった頃の資料ばっかり見てたよヽ(｀Д´)ﾉｳｧｧｧｧﾝ

スレ汚しスマソ

>>381
テキストエディタをどう実装するかは漏れも興味あるな。

内部処理にはベタでテキストを持つわけに行かないから、リストなり
何なりの内部表現になってるんだろう。それがそのままファイルに
マップされてると。
そこで、例えば10MBのファイルの先頭と末尾10バイトづつ残して真ん中を
ごっそり削除したとする。削除直後のメモリイメージでは有効なデータが
領域の先頭と末尾にあるわけだが、これをセーブするとどうなるんだろう。
10MBのままってのは無いだろうから、前に話が出てた穴明きファイルみたいに
して2ブロックだけ使うのか、それともセーブ前にパックして20バイトで
済ますのか。いちいちパックするとなると内部表現そのままファイルという
メリットが薄れるな。

あと、ファイルブロックのキャッシュがディスクに書き込まれるタイミングは
アプリ側で正確に制御できるんだろか。内部表現にはデータ間のポインタが
飛びまくっているだろうが、アトミックにいくつかのポインタを書き換え
なくちゃならないケースがあるはずで、その操作の途中にsyncが入って、かつ
次のsyncまでの間にアプリが死ぬと、もうそのファイルは読めなくなっちゃうな。
そのへん、クレバーな実装が出て来ることに期待。

( ´o`)п <(ホ)(コーヒーブレイク)
http://pc3.2ch.net/test/read.cgi/tech/1027080631/
こんなスレが立ってた。
ざっと見た感じ主にC++で作ってるらしいところが新しい？
OSASKとは思想は全く違うけどちょいと気になるスレ

>>393
とんがりこ〜んタンがたびたび出てくるYO!(w

ver.3.0を試したんだけど、おまえら、この症状を試してくれYO！
FDで起動→F7で壁紙変更→Oyaji(目玉)→Calm2(カレンダ)→ONKAN
ってやると

INT 0x03 Break Point
CS:EIP = 00C7:00002472
EAX = 00000031 ECX = 00080000 EDX = 00000200 EBX = 00007EFC
ESD = 00010CF8 EBP = 00010F00 ESI = 00010CF8 EDI = 00010D80
tss = 00008000 TR = 00000170

のエラーを吐いてマウスの移動は出来るがクリック不可、
目玉だけ動いてるって症状にならねぇ？

FD腐ってるのか、キーボード・マウス・ディスプレィを切り替え機で
共用してるのが悪いのか、詳しいことわかんねぇ。
一応、CPU:P3-500MHz Mem:128MB

>>394

それはまだ確認していないが…

TOWNS版で、S_WORLDを立ち上げた瞬間に、

INT 0x03 Break Point
CS:EIP = 00C7:000007B1
EAX = 00001000 ECX = 00000098 EDX = 00000008 EBX = 00001980
ESD = FFFFFFB8 EBP = 00001800 ESI = 0000081C EDI = 00001900
tss = 00005000 TR = 00000140

を出してきやがった。
ONKANを単体で立ち上げたときは問題なかった。

ちなみに、同じFDにv2.9を入れて使ってみても問題なかった。


お前ら、他にこんなの起こらない?

>>392
ベタでも持てるだろう。でかいテキストの時遅くなるけど。

内部表現＝ファイルフォーマットにこだわることはないと思うよ。
後から効率のいい方法に変えたくなっても、ファイルフォーマットの
互換性がなくなるので出来ないなんて事になりそうだし。

繋がらない・・・ (´･ω･`)ショボーン

皆様の御意見を頂戴していると、さも 2emu が無理だと言っているように、
御見受けすることが出来まちた。

追伸、ｻﾊﾞﾁｬﾝが終わらない

ffs , sfs はいらないなんて発言 信じられません。
総完備だからこそ互換/下位互換の無期無条件放棄の効果が理想的な機構なのに。
要するに君達はアレだね？

その他、反論を御待ち申し上げて御座います。でしゃばってごめんね

笑む獅子光臨！

ircには行かないの？＞笑むたん

すげー
ものすごい勢いで笑むたんだ。

…言葉の意味はよく分からんが、とにかく凄い獅子んだ。

とりあえずGO意外と便利かも？
どうせなら開発環境全部セットのパッケージ誰か出さないかな？

笑むたんくるとなごむねー。
でも、相変わらず発言は分からないYO…。

なんで398と399でトリップが違うの？

偽者ﾊｹｰﾝ

>404
笑むたんだから。

>>395

自己レス。
これは、どうやら窓タイトルの長さ制限にかかってたようだ。

某スレ123です。
　
　ttp://minix-up.sourceforge.jp/cgi-bin/l.cgi にあるOSASKのソースを
チェックアウトしたいという要望をいただいたのですが、あれはSF.jp のCVS
サーバーが管理しているデータではないのでチェックアウトできません。
　
　そこで以下にリポジトリそのものを圧縮して置いておきますので、CVSにも
興味を持っている方はどうぞご自由にお試し下さい。
　　ttp://minix-up.sourceforge.jp/_OSASKtest/
　
　
遊びかた概要
　
　1. Unixマシンを１台用意する (OSASK用のマシンとは別マシンの方が良い)
　2. CVSリポジトリを作り、その中に_OSASKtest06を展開する
　　(例)
　　　$ cd
　　　$ mkdir .CVSROOT
　　　$ cvs -d .CVSROOT init
　　　$ cd ,CVSROOT
　　　$ tar zxf [上のファイル]
　　　$ cd
　3. Unixマシン上でチェックアウトしてみる
　　　$ cvs -d .CVSROOT co _OSASKtest06
　4. Windowsマシン上からチェックアウト・・・する方法は、CVSに慣れた後で
　　色々調べてください（ ; ´∀｀）

　　
　なお、このリポジトリに私に由来するミスが含まれている可能性は否定できません。
　それを検証するためのヒントは以下の通りです。

・もしFreeBSDをお持ちなら、以下の Makefile を空ディレクトリの中に置き、「make fetch」
　と打つと既存のOSASKのソースを全てダウンロードできることでしょう。
　ttp://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cvsknit/cvsknit/defs/OSASK/Makefile

・diff -r [ディレクトリA] [ディレクトリB]
　と打つと、二つのディレクトリの中身を比較できることでしょう。
　
　
Enjoy! （　´∀｀）

>>409
そうだ、リポジトリの方はEUCで文字コードを統一しているので、diff -r すると
ものすごい違いが出ると思われ・・・（　;´∀｀）

遅くなったけど、 OSASK 3.0 ソースage!
ソースの中に changes.txt がついた！

> ●主な変更点 by 小柳 雅明([email protected])
>
> Version 3.0
> [OSASK 5137][OSASK 5142][OSASK 5143][OSASK 5183]
> ・各モジュールをあらかじめ圧縮しておくことにより、OSASK.EXEが小さくなり
> ました。
> ・ブートシーケンスが変更され、リアルメモリの使用量が少なくなりました。
> ・PC/AT版においてキーボードインタフェース周りが変更されました。
> ・起動時に OSASK.EXE に付属するディスクイメージを展開することにより、
> フロッピーディスクがなくても起動可能になりました。
> ・TOWNS版での直接起動ディスク生成がサポートされました。
> ・ビルド時のリンカが obj2bim3 + bim2bin3 + osalink1 にバージョンアップ
> されました。

NOWSMARTもがんばってるっぽいぞ

関係ないけど、Meではアクセサリの中だべや。

またOSAKAか・・

ちゃうねん

>>413
あれはエミュだって。

OSASK-OFF、出欠取ってるよ？
http://www.afis.to/~mone/osask/osask_ml/200211/msg00023.html

age

>417
どうせOSAKA人だよヽ(｀Д´)ﾉﾊﾞｰﾔ

それはそうと、keymosのCopyrightが未だに2001年になってるですよ。もう許さんです。

tachiagare osask

irc　なんか　混んでる

勃起

>>408
123さんへ

えと、自分、普段linuxなんですが、
ふつーにSourceForgeからcheckoutしたいんですが・・・どうすりゃ
よろしいでしょうか？

>>423
　今晩は。

　申し訳ありませんがそれらのデータは SourceForgeの
　(anonymousを含む) cvsサーバー上にありませんので、
　お手元のLinuxマシンでcvsの(サーバー寄りの)
　セットアップに挑戦する必要があります。

　CVSlabに置いてあるデータは全て、私が手元で作成
　したリポジトリそのものを「Webサーバー上に」直置き
　しているものなのです。

　リポジトリの形で手元にあればサイズが小さいわ
　取り出したソースがいつでも捨てられるわで色々
　便利だとは思うのですが、Unixマシンに慣れている
　方にしかお勧めできません。

hoshu

hitonaminiagareya

OSASKﾏﾝｾｰ

OSASK ｷﾀ━━━━(ﾟ∀ﾟ)━━━━ｯ!!
IPA 平成１４年度未踏ソフトウェア創造事業「未踏ユース」 採択
http://www.ipa.go.jp/NBP/14nendo/14youth/gaiyou/02-005.htm

　IPAやOSASKの話はノーコメントで済ませたいのですが、とりあえず、
NWSOSで、スレッド（軽量タスク）の実装に成功しました
（簡単なテストで確認済）。

　ただし、今のところ、BeginThread(), EndThread(), KillThread()
しか用意しておらず、（アプリレベルでの）排他制御やスレッド状態検査
が行えないので、本格的に使うのには無理がありますが。

　あと、同じファイルハンドルに複数のスレッドが同時に書き込めるよ
うに修正しておきました。


　スレッドを使ってシェルの内部コマンドも並列実行できる
ようにして、内部コマンドに対してもパイプを実装したいと
思っています。

>>429
　ゴメン。マジで間違えた。こっちじゃなくて、「OとNを褒めちぎる...」
の方に書くつもりだった。悪気はないです＞OSASK関係者

Lたんは面白いなあ。
「＞OSASK関係者」って書く方が悪気があるように取れるんだが（ｗ
スレの住人を関係者呼ばわりですか？みたいな。
公認であって、公式じゃないんだし。
いや、Lたんにはホントに悪気はないんだろうけどね。

それはそうと、GO-Win計画は止めた方がよさげな気が。
合間をぬって暇なときにﾁｮﾄずつ進めるとかなら悪くはないとは思うんだけど。
最新版を常に公開しとけば需要がありそうだったら手伝うヤシもいるだろうし。

>>431
いっそWinに詳しい誰かに任せちゃったほうがいい気がするんだよね
どうせGPLなんだし。

それよりメディアがFD１枚のみというのなんとかしないとさあ。
ディスク周りは前倒し出来ないのかな？

そういえばHDとかって、とりあえず単にセクタアクセス差し替えるだけじゃだめ？
ファイルシステムとかは面倒だからひとまずFDイメージ状態でさ
仮想的に100台位（ｗ

じゃなかったらスロットに偽装した裏function作るとか

GO-win32計画を本気で進める気なら、
ライセンスにはもう少し気を使わないと、
余計な誤解を生むかもしれない。

とりあえずtolset02.lzhにはソースの入手法を 明 示 する必要がある。
>go_0004sという名前でベータリリースしています。
ではまずい。
書庫は大きくなるけどGO-win32フル版を用意してソース同梱が一番安全。

IPA ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!

しかし、GOって、あのGOグループのイメージが強い…
あ、もしかして「ゴー計画」って読むのかな？

俺としては、フロッピィ2台サポートをしてほしい。
TOWNSや98なら4台すべてサポートしてもらえるとさらにうれしい。

>>433
メールで聞け。じゃまずいんだっけ？
しかしまずソース差分のみのKL-01でリリースするべきだよね。
tolsetにはバンドルするかそれらの入手先を書けばいいのでは？

>>433
問題ないでしょ。
バイナリを持っている人間がソースを入手出来ればいいはず。
ソースを入手する方法が公開されていないのは×

s/433/437/
まあ、ソース同梱すれば一番安全なんだけどね。
同じ所にソースも置いておけば、何の問題も無い。

割り込んですまん。新たなライバルであるMEG-OSのスレを
立ててくれないか？
OSASKスレの住人は度量が広いだろうから、敵に塩を送る
男気がありそうだ。

一応以下が草案。
--------------------
title:
MEG-OSに激しく萌ゆるスレ

本文:
ホームページ
http://meg-os.org/

ライバル達
http://www.imasy.or.jp/~kawai/osask/
http://homepage2.nifty.com/nowsmart/
http://sourceforge.jp/projects/higepos/
http://mona.sourceforge.jp/
--------------------

--------------------
本文２：

☆ DOWNLOAD PAGE
http://meg-os.org/megos/d.i

☆ MEG-OS BBS
http://meg-os.org/bbs/megos/
--------------------
本文３：

参考情報サイト

☆ 日本FreeDOS友の会
http://guriponn.tripod.co.jp/

☆ OS Developer's Site
http://ise-city.no-ip.com/~foo/
--------------------

>>440
「めぐ」ではK氏やL氏にキャラ負けする予感。

しかし、たしかにシングルバイナリでAT/98両対応は萌える。
サイズ肥大化を嫌うK氏には難しい技だ。

　 ∧＿∧
＜　｀ー´＞y-~~~ ほうほう。
boot sequenceがなかなか洗練されてて良いですな。

単体スレ立てるよりも↓の次スレ移行時に統合した方がいいかも。

OSASKとNOWSMART-OSを褒めちぎるスレッド
http://pc.2ch.net/test/read.cgi/os/1031377826/l50

TOPページ以外にはリンク張らないでくださいと ･ﾟ･(ﾉД`)･ﾟ･

>>444
440ではないのですが。
topがJavaScript専用の駄サイトである以上やむを得ないかと。

JSを使用しているだけで駄ｻｲﾄ呼ばわりされる理由が思い当たらないのですが、、、
貴方はCGｻｲﾄにﾃｷｽﾄﾌﾞﾗｳｻﾞでも見れるようにしろとでも言いたいのでしょうか？

とりあえず、OS自身のブラウザで見られるようになるといいな。

今世紀中はむりっぽいですね ･ﾟ･(ﾉД`)･ﾟ･

とりあえずJS用のページはフィルタに引っ掛かってまっしろなんだな。

それにしても、イメージタグとフォームだけ対応みたいな
簡易ブラウザってありそうでみないよなあ。

アクティベーションしないと見られない時点で萎えますた。
駄サイトでつね。

見る人に、
ｱｸﾃｨﾍﾞｰｼｮﾝをするか
今すぐ立ち去るか
を選ぶ権利を与えたのですが。
強制的にｱｸﾃｨﾍﾞｰｼｮﾝするように変更すれば良ｻｲﾄになりますか？

>>451
横から口はさんで悪いけどさ、まず>>450みたいな人にも見て欲しいのか
否かをハッキリさせたら？ >>450みたいな人は来なくていいって態度なら
今のままでいいじゃん。 そうでないのなら、どうすればいいかくらい分るだろ。

全てはサイトのTOPで書いてる通りです。
そもそもｽﾚ違いですな。
くだらん煽りに乗ってｽﾏｿ。

なんというか、注文の多い料理店やね。
どうも色々強制するところがちょっとフリーぽくない感じで多少興ざめだけど
何かあったんですかね？　まあ、好きな人にはいいんじゃないかと。
とりあえず話はここより>>443のスレあたりがいいんだろうか？

なんか誰か対抗しないかな？こっちは動画とかで（ｗ

煽りに乗ったと言うよりかはむしろ煽ってるように見えるが（ｗ
しかし、昔はあんなトップなかったような気がするけど、、、

ついでに言うと、
> もしもあなたの Web Browser がサポートしない場合は今すぐアップグレードをします。
> 特別な理由でこれらをサポートしない場合はサイトポリシーを一読の上ご判断下さい。
これ、意味が分からん。
つうか、トップページが全体的に妙な空気が漂ってる気がするのだが。
どこまでネタなのかもわからんし。わからんヤシには入るなということか？（ｗ

ていうか、リア厨じゃないの？あるいは工房か。
煽りじゃなしにな。
そういう意味で作者に将来性はあると思われ。
ただ、現状では単独スレ建てるほどの面白さはないんじゃないかなあ。

>>440
>ライバル達
それぞれどんな特徴あるの？

>457
上二つは言うまでもなかろう。
下二つは
http://pc3.2ch.net/test/read.cgi/tech/1037096449/
だな。

>>433-439
おいお前ら、go_0005のreadme.txtはいかがですか？
３つそれぞれ内容が違うのでご注意。

　 ∧＿∧
＜　｀ー´＞y-~~~ ふむん。みな、なかなかいいぞよ。
でも、OSASKもNWSOSもHIGEPOSも、ワシが秘蔵している
OSに比べればまだまだじゃな

偽者かよ！

>>461は本物？
超先生は本当にOS作ってるの？

きっと凄い実時間OSなんだろうな。
一説によれば時間そのものさえ制御できて神には必須とか（ｗ

んでやっぱり先着30名には100円で売られるのか。（ｗ

一瞬、MEG-DOSかと思った。
それとも、MEG-DOSを意識してる？>MEG-OS

>>465
よく間違えられますが、既に定着してしまったので今更名称変更できないのです。。。

OSASK~~~~~

OSASK++

TanakaOSASK

（　ﾟдﾟ）<ﾆｮｶﾞｰﾝ

OSASK 3.1 ソースage

OSASKのページからたどれる ML の過去ログの12月分が
見れないのは何故？

>>472
リンク張っていないだけだと思われ
ttp://www.afis.to/%7Emone/osask/osask_ml/200212/
これぐらい試したら？

俺バカ過ぎ。

OSASK ML 5464 に書いてあるけど、OSASKの開発方針を変えようとしている
みたいだね。一言で言うと「独自性より実用性」ってことかな。

俺はかなり賛成。セルフ開発環境、HDD、ネットワークの３つは
なるべく早く対応してもらいたいと思ってる。短期的にそういう方向に
力を注いでも、OSASKなら多くのOSに埋もれてしまわないだろうって
安心感もある。

ただ、メールとチャットくらいできるのが来年度いっぱいってのはちょっと驚いた。
長いな、あと17ヶ月弱か。セルフ開発環境、HDD、ネットワークあたりは
いつ頃になりそうなんだろう？これができるのも来年度いっぱいなのか、
それとも、このへんはもっと早くできるのか。

http://digikei.kir.jp/

OSASKが高速って言うのはマジなの？

自分のマシンでは実感としてWinの方が速く感じるけど。

#osdev-j
プチ祭りage

>>476の選択が渋いな
このスレで宣伝カキコするあたりが、特に。

うーん、ソースコンパイルしようとしてるんだけど
配布そのままのディレクトリだとなかなかうまくいかない
やっぱり全部同じ所にぶち込まないとアレなのかなあ？
どうも混ぜるの好きじゃないんだけれども。

まあセルフ版はまだ階層無理だろうから結局そうなってしまって
こだわっても意味ないかな。

今日めっちゃねむいんやけど・・・・・・（汗

そうか。

ええっ。
AZUCOさんてOSASKスレなんか見てたの？

>>483
( IRCにも来てるよ…

誰？

かと思ったら、AZUCOでｸﾞｸﾞﾙったらトップで出てくる
あのシンプルなのか手抜きなのかわかりにくいサイトの、
A-SATURNなんかを作ってたあのAZUCOか？
やっぱOSASKはエミュ祭りの時に知ったのかね。

>>481
昨日はお世話になりました。
SATURN エミュレータの作者さんだったんですか！？

うーん。SS 本体が紛失して困っていた所なんです。

>>486
シンプルと手抜きだね（w3c信者でもないので・・・・）
OSASKはEmuBOFで知ったけど、プログラム系の話がおもしろそうって事でアンテナは
のばしてるんだけどね。俺もASM使いだし。マインドはKたんと同じ（ｗ
でーサイトわかりにくい？（ｗ

ってOSASKと関係ないから後はメールでも送れ！

>>487
お世話様です。昨日はＫたんと話して、結局話が収束しなかったのは、
俺とＬたんは一般論として話してて、ＫたんはOSASKは・・・という前提で話してたから
って事がわかりました。

ＬたんもＫたんも今後は丁寧に話の前提条件を押さえつつ話をした方が、双方の
時間の節約になるかと（ｗ

シンプルか手抜きかどっちなのか「わかりにくい」という話よ。
まあ「手抜き」にわかりにくいというニュアンスも込めてるんだけどな。
で、何がわかりにくいっておまいさん、
ソフトが何するものか、現状がどうなのか書いてないじゃん。
エミュレータがどんなものかは書いてあるのに。

漏れは昔逝ったとき、もはや残骸だけで公開してないものかと思ったぞ。
もっとも漏れに使う気がなかったからかもしれんが。
ｴﾐｭﾊｾﾂﾒｲﾖﾑﾉｶﾞﾀﾉｼｲ…

どーでもいいけど、>489のようなことこそメールでやった方がいいと思われ。
少なくとも名乗って書くのならな。

>>490
そこまでは言わなくてもいいかと。
ただ、書いてある以上、一体何をどこで話したのかは気になるかな？
478の関係かな？

まあ、千客万来だろうが、一見お断りだろうが、素人質問無用の
ジャンク屋だろうが、そのへんはオーナーの勝手だと思うな。

ソフト公開系のウェブサイトはシンプルかつ手抜きに見えるぐらいの方がわかりやすくて良いと私は思います
OSASKのページは丁寧で親切だけどファイルや情報などを探すのは大変な気がします。

当然オーナーの勝手で良いのですが。

>491
いや、一見さんお断りというのならわかるんだがな。
それならエミュの用語解説なんていらんだろうと。
まあそういう微妙っぽい客層を狙ってるとかならスマソってとこだが。

あと、>489のような内容、というより書き方は
見方によっては人を小馬鹿にしてるようにも取れるってこと。
わかりにくくてスマソ。
「ｗ」が特にね。当事者たちはたぶんそんなことは考えてないだろうけど、
見てる人にとっては・・・と考えるのは漏れが小心者だからでつか？
馴れ合いサイトばっかりｦﾁってきたせいで過敏になってるのかも（鬱

ネタを提供してくれるのはうれしい限りだよ。
ということで誰かIRC要約してうｐしる！

>>490
多分俺と485のエミュに対するスタンスが違うからだと思うな。

俺はエミュはゲームとかソフトを動かす部分以外に興味を持ってるから、そこがメインの
人にはさっぱり説明が足りてないと思う。
というか、俺のニーズではないので、説明する気が最初からない。だりーし。
ソフトを起動すればわかることだし。

次からは、俺の掲示板かメールでよろしく。

起動してみたけど、これOSなんですか？

>>495
【Emu】プログラミング系雑談
http://jbbs.shitaraba.com/computer/bbs/read.cgi?BBS=2820&KEY=1029683432
に回答しました。

以後俺のエミュ関連はこっちでおねがいします。

超OS

保守あげ

499

500げっと

問題になってますよ、河合さん
http://pc.2ch.net/test/read.cgi/os/1039237412/68

>>501さん
ご連絡ありがとうございます。
でも「こちらに来ていただけない＝僕からのレスを期待していない」
と解釈するのが僕のポリシーなので、僕はあちらには出ません。
向こうのスレッドの68さん、読んでいたらこちらかOSASK伝言板へ！

レスを期待しています。
もし反論がありましたら。

哀れな68のためにまとめてやろう。
つーか、こっちに書かないとレスしにくいだろうからな。

今日、OSASKとNASKのソース読んだんです。ソース。
そしたらなんかめちゃくちゃ読みにくいんです。
で、よく見たらなんか関数長いし、ネスト深いし、構造化されてないみたいなんです。
もうね、アホかと。馬鹿かと。
K氏な、プログラマセンス０でプログラミングしてんじゃねーよ、ボケが。
いずれ破綻するよ、破綻。
なんか配列とかポインタの使い方もセンスないし。そんなんでバイナリにこだわってるのか。おめでてーな。
コピペでやったような処理がいっぱいあるの。もう見てらんない。
Kな、アイデアは認めてやるから実装にかかわるなと。
ソースってのはな、もっと美しくあるべきものなんだよ。
他のOSといつ比較されても恥ずかしくない、
美しさだけでほかほかご飯が食べれる、そんな雰囲気がいいんじゃねーか。えせソースは、すっこんでろ。
で、やっと読み慣れてきたと思ったら、大量に、goto、とか書いてあるんです。
そこでまたぶち切れですよ。
あのな、gotoなんてきょうび流行んねーんだよ。ボケが。
得意げな顔して何が、本当のプログラマはgotoを恐れずに使う、だ。
お前は本当にgoto使わなきゃならんのかと問いたい。問い詰めたい。小１時間問い詰めたい。
お前、構造化プログラミングできないだけちゃうんかと。
ソース通の俺から言わせてもらえば今、ソース通の間での最新流行はやっぱり、
コメントなし、これだね。
コメントなくてもわかるソース。これが通の好み。
コメントなしってのは明確なロジックが必要。適切な変数・関数名も。これ。
で、それに高級言語を利用しての構造化。これ最強。
しかしOSASKみたいに汚いとコメントあってもダメダメで、もうだめぽ。
素人には（コメントなしは）お薦め出来ない。
まあお前ら素人は、http://www.pro.or.jp/~fuji/mybooks/cdiag/でも読んで悔い改めなさいってこった。

なんか意図的に曲げられてる気がするが・・・

>505
なるべく藻毎さんの発言を集めたんだが。
曲げられてるんだと思うんだったら指摘しる！

>藻毎さん
なんと読む。

おまえ→おまい→もまい→藻毎

別にGOTOなんて変な使い方でなければ幾ら使ったって構わないし、
読みずらいなんていうのもASKAに対してpascal使いがCのソースの感想
言ってるみたいなものだと思うんだけど、
Ｖ９８のHDD対応を放り出して１から作り直したのがなんでこうなるのか？
って気はするんだよなぁ。
あれってコメントちゃんとしてるしそんなに駄目とも思えないんだけど。

もっとシンプルなOS-9のモジュラーみたいなのを想像していたんだよなぁ。

>>504
うまい。感心した。

>68さんはなぜか向こうのスレで書きますた。
http://pc.2ch.net/test/read.cgi/os/1039237412/150
以下コピペはもったいお化けが出そうなので要約

・つまらない処理で関数を分けろとは言っていない

・長い関数内に繰り返し現れるような機能を抽出して関数として独立させた方が
コードの可読性・保守性が上がるのでは？

・ほぼ同じ機能で中身が違う機能を実装するときなんかは特に上記のことを守らないと
似たようなコード(コピペ)が散逸してますます保守性が下がるのでは？

・ネストの深さに対応するよりもっと他の場所にその力を使うべき

スマソ。リンク間違えた。正しくは
http://pc.2ch.net/test/read.cgi/os/1039237412/105
あと、最後の文は
（ネストの深さに対応する力があるなら）他の場所に〜
と適当に補完きぼんぬ。


しかし言うてスマンが、ついさっき「プログラムの正しい書き方」を学んできた、
というような気が・・・
教科書のコピペでもしてるような気分になったぞ・・・
「関数はどうあるべきか」とか言う見出しがついてそうな（ｗ
いや、もちろん、だからこそ大事なことだとも言えるんだけどね。
もっとも川合さんがそれを忘れてるから
あんなコードを出力してるんだとは思わないけど。

＞長い関数内に繰り返し現れるような機能を抽出して関数として独立させた方が
コードの可読性・保守性が上がるのでは？

Cやアセンブラじゃできないことだが、漏れはよく関数内関数を使うな。
賢いコンパイラならインライン展開してくれるからオーバヘッドは無いし。
(gccの関数内関数ってインライン展開されたっけ?)
トップレベルの関数にしたらローカルな環境をいちいち引数渡ししなきゃ
ならんから却ってわかりにくくなることも。

とりあえずOSASKのソースはRubyのイテレータみたいな考え方とは正反対だね
※知らない人いるかもしれないから断っとくけどC++のイテレータとは別物

ちなみにライバルのLﾀｿはそういうのが好きみたい
http://pc.2ch.net/test/read.cgi/os/1031377826/183
http://pc.2ch.net/test/read.cgi/os/1031377826/198
http://pc3.2ch.net/test/read.cgi/tech/1035086458/435

68が無駄な時間（噛み合わない会話）を過ごさないために書いておくが、

Kたんは世間一般の常識をOSASKで通用させるつもりはない。
OSASKで通用するのはKたんの常識＝OSASKの設計思想、やり方のみ。
それに迎合できない人は、静かに去って欲しい・・・・と思ってると思います。

なので、コードの組み方の一般常識はあると思いますが、それに関しては68の言う事は
もっともだというでしょうが、事、OSASKのコードに関しては、それらのやり方は無意味で
ナンセンスなのです。
ＫたんがASKAを使って書けばわざわざ構造化という名目で関数を分ける必要性自体が
そもそもない・・・・・そういうのは無駄な事でしかない。そういう事なのです。

と、この間の会話で理解したのですが、違う部分があれば指摘よろしくです。

世間一般の常識というのは語弊があるような気が。

誰でも人に見せない書き捨てのプログラムなんかは
自分がやりやすいように書くだろう。
短いプログラムやプログラムの実験なんかも同じ。
川合さんもそれと同じようなことをしただけだと思われ。
単に文字通りオープンソースであるというだけのこと。

迎合できなきゃ自分で変えてもよし、去ってもよし。
手伝ってくれるのなら当然手伝ってくれる人に合わせるぐらいはするよ、と。

普通のやり方では？
普通というか、自然体というか。
あとまあ記憶力が通常の三倍ぐらいあるのかもしれんけど。

＞それに迎合できない人は、静かに去って欲しい・・・・と思ってると思います。
まあ、ブランチでも作って勝手にやってくれ。って感じかもね。
本家で取り込んでも構わないものは取り込むんじゃない？

読んで判らない所があれば書いた本人に聞いて回答した方がはやいし、
まとめればマニュアルになるでしょ？ってとこじゃないかと。
そういうのがなければ、本当はソースにしても問い合わせがあった場合にだけ
出すことにして、いちいち公開せずに済ませたいんじゃないかな？

中二でカーネル破ッ瓜は正直すごいな。

あーん！？いーんじゃねーの、構造化なんて。
構造化ってのは頭の悪いやつでも、ソフトウェア工学についていけるための
救済処置に過ぎねーんだし。
整理整頓に気をつけてる奴ってのは、実は、把握能力の欠如をカバーする
後ろ向きな行為なんだぜ。工業製品なら、当然だが、ことOSASKにとっては
そんなことは関係ない。

ってかさ、不満あるんだったら、OSASKをコピってGPL公開し、勝手に整理整頓して
別プロジェクトとしてブランチする気合が足りねー分際で、偉そうに講釈垂れて
んじゃねーよ。

文句ブーブー野郎様へ

気に入らなければ、OSASKのソースを改造して、sourceforgeのリポジトリに
公開してください

サウンドドライバ　ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!

(ﾟдﾟ)uma計画ってなんじゃらほい？

応援しようぜ、OSASKを！

おれは応援するぜ！
さあみんなも応援しようYO！OSASKを！
すぐに成果を求めるせっかちな野郎、
くりすますが何だ！♂ならOSASKだろ！！

ちょっと無理が…

>>524
泣きたくなるからﾔﾒﾚ。

>>522
バ、バレた！？

>>521
Where?

ひさしぶりに着てみたら荒れてるな

>>ひさしぶりに着てみたら荒れてるな
本題となるOSASKの進行速度があの調子じゃ荒れるだろ。

この場合の荒れてるとは、話題が全然でないと同義でいいのかな？

そういえばwin31風の奴に時計表示が付いてたね。
位置変更してT-OSASKに組み込んだ人とかいないのかな？
本家にも取り込まれるようだから、ついでに
正しいファンクションの作り方というの解説も希望。

所詮厨房とまともに受けてる野郎のOS。
和製OSつったら2chOS(Mona)だろ。

osaskのGUIだめ。CPUパワーあるのいいことに、奥から順番に全部再描画させてる。
何が軽快なOSなんだか。

>>532
多分、エセ実装の呪文で回避されるに１００Ｋ。

>>533
むしろあれを見て本実装と思う方がどうかしてる（ｗ

Ｋ氏なんて、ＯＳＡＳＫのソースコードへのライト量よりも
2chへのライト量のほうが、圧倒的に（以下略）

>>535
ﾜﾗﾀ

それはそれで凄いな。
OSASKのコードはめちゃくちゃ短いことになる（ｗ

>>535
それをいったらLたんは...

K氏は本当にすごいか？
いやすごくないに1票
存在自体がエセ

すごくないというのには1票入れてもいいかもしれんが、
すばらしいというのにも1票入れることになる。
川合さんがエセだとしても、OSASKがエセコードだらけだとしても
「OSASK」はエセではないからな。

いや、OSASKはエセだろ。
ちなみにすばらしくもない。
大体言うことだけは大きく、オープンソースで多人数開発しているのに
Lﾀﾝ(=NWSOS)に余裕負け。

これのどこがすばらしい？
M&Mに抜かれるのは時間の問題かと＞OSASK

ﾐｸﾛだな。

>541
確かにそのうちM&Mにも負けるかもしれんな。
しかし、それがどうしたというんだ？
ヤシらが成功して残るのは一歩か二歩前に進むことだろう。
OSASKが成功して残るのは1mか2m宙に浮くことだ。

>>543
>ヤシらが成功して残るのは一歩か二歩前に進むことだろう。
>OSASKが成功して残るのは1mか2m宙に浮くことだ。

こういう事言う信者が多いけど、根拠が謎なんだよね。
そういう風に見えてるのなら、洗脳された可能性あるよ、まじで。

「1ｍか2ｍ宙に浮く」と言うのが、洗脳っぽいよね。
尊氏は宙に浮くものだからさ。

IPA事業として登録されたなら、その開発スケジュールくらい
トップﾍﾟｰｼﾞに明記するべきでは？＞Kさん

>OSASKはサイズと速度が至上命題です。
であれば、あのGUIの再描画の鈍重っぷりは至上命題として迅速に
解決するべきでは？マイクロソフトだってあんな怠慢なコードは書きませんよ。
差分書き換えなど、ちょっとしたアルゴリズムの工夫で軽くなるのですから。もったいない

>544
そうか。
自分でも何書いてるかよくわからないその文章の意味がわかるとは思わなかったが、
そういう事言う信者が多いとは知らなかったよ。どこ？

まあ、速度とサイズを（メインで）目指すOSは今まであんまりなかっただろうし、
現状少なくとも公開されてる和製OSではただ一つなわけだから、
他のOSと違うものであるのは確かだろう。

OSASK原理主義者の立場から言えば、たとえ結果として
現状の設計のOSASKが他のOSと同じ、あるいはそれより劣っていたとしても
残念ではあるが、別にどうということはない。
単にそれが「OSASK」ではなかったというだけのことだからな。

みなさん、>>547がやってくれるそうです。
期待しましょう。

・・・つかディスクが面倒ならイーサとかでもいいから
なんかドライバやる気ないん？だれか。
うちには資料ないのでbochsでも解析するしか

そういえばサウンドドライバの話ってあれはどういうことなのかな？
試作コードどっかに出てたりするんだろうか？

うーんモグリ信者は辛いよ（ｗ

＞・・・つかディスクが面倒ならイーサとかでもいいから
＞なんかドライバやる気ないん？だれか。
FAT32へのドライバだったら協力できるが、そもそもFAT32自体、OSASKから
してみれば不合格な代物だろ？

＞OSASK原理主義者の立場から言えば、たとえ結果として
趣味的に発展途上のOSをハックしたいというのであれば、
今となってはMONAがあるし。C++で書かれてるぶん、可読性も高いし。
１BitたりともMONAに協力できなくても、ROMしてるだけで楽しめる。

まぁ商用目指してるNWSOSはさらに完成度を高めることで魅力を高めてる。

半端なOSASKは魅力も半端。
速度とサイズの最適化なんて、後でもできるじゃん。
ある意味、OSASKは国家プロジェクトなんだからしっかりして欲しいぞ。

＞FAT32へのドライバだったら協力できるが、そもそもFAT32自体、OSASKから
＞してみれば不合格な代物だろ？
これなんだけど、OSASKの本番ディスクフォーマットってなによ？
ドキュメント見てもどこにもないぞー

>>549
OSASKよりの人？はよく「文句言うなら、コードのひとつでもかけよ」と言うが（個人的には
もっともだと思うが）５４７は単にOSASKの自己矛盾を突いただけで、それだけで、だから
「お前がコードかけよ」となるのはいささか稚拙すぎるように思う。

そういう観点で言えば、549の方が「なんかドライバやる気ないん？誰か」とか、ここに書く
以前に自分がドライバを書けばいいのである。

人をどうこう言う前に、わが身を省みるべきである。

>>553
そんな大層な話ではなく既出の指摘だったように思ったのは
気のせいだったんでしょうね、たぶん。

それにしても、
＞ちょっとしたアルゴリズムの工夫で軽くなるのですから。もったいない
と言えるようなノウハウがある人でやった方が早いんじゃないの？
わかってないのが手をつけたところで、妙な遠慮とか様子見が起きて
足引っ張るだけでは？
まあ何らかの成果があれば助け船もでるんだろうけど。
そもそも全然わからなくてできなければどうすればいいんだ？

>>552
昔のMLでその話が出てた気がする。

だけど、これを実装できるのは川合さんしかいないのでは？
自分も読んで概念はなんとなくは解ったけど、
どう実装したらいいのかは解らない。

　なんだか、OSASK-ML に、JavaVM の実装も OSASK の計画に入っているとか
書いてあるな。
　普通、企業の「計画」ってのは、絶対完成するメドが立つものを言う。

OSASKでは、「希望的な目標」と「計画」を完全に混同してるな。

>>556

>>ていうか、JAVA仮想マシンも作ってもらえませんか？（ｗ
>それはいうまでもなく計画に入っていると思います。
>ただ、川合さん自身が作るとは限りません。
>きっとJava好きな人がなんとかすると思います。

JAVA仮想マシンが、「いうまでもなく計画に入っている」そうな。
どうせ、Windowsエミュレータもこの調子なんだろうな。

OSASK ML より抜粋：

>>>547　　　　(コメント書き込み日：2002/12/29)
>>であれば、あのGUIの再描画の鈍重っぷりは至上命題として迅速に
>>解決するべきでは？マイクロソフトだってあんな怠慢なコードは書きませんよ。
>>差分書き換えなど、ちょっとしたアルゴリズムの工夫で軽くなるのですから。もったいない

>　まあ、全体としてはおっしゃる通りですね。とりあえず言い訳を書きます。
>
>１．僕自身が再描画をそれほど気にしていない。
>２．あのウィンドウシステムはいずれ完全に捨てて作り直すべきだと思うのであまり改良したくない。
>
>この2点に尽きます。
>
>　１．についてですが、547さんはいったいどういう使い方をしているんですか？
>ただウィンドウをわざとたくさん並べてみてそう思っただけなんじゃないですか？
>パソコンの処理量から言えば、再描画が必要になるウィンドウの移動やクローズ、
>切り替えなどは、全体の処理のごくわずかです。
>寄与するのは3%とかそれ以下とかそれくらいでしょう。その3%の改良はもちろ
>んするべきですが、急ぐべきかというと僕はそうは思っていません。
>今後解像度を上げて、ウィンドウを重ならないように配置したり、ウィンドウの
>最小化などをサポートしたりすれば、今のあほすぎるウィンドウシステムでも
>それなりに使えると僕は思っています。

だって。

サイズには異常に拘るのに、速度には無頓着な事が明らかになった。

>>551
後からできる速度とサイズの最適化？
いまどき何をおっしゃるうさぎさん。
後からできることは後からできること。OSASKでもそれは同じ。
今しかできないことがある、というのが川合流。
ついでにOSASK原理主義＝「最小最速のOS」を求める主義
ソース読みたいのならどこにでもいくらでもある。

>553
それは無視してもいい要素だからだろう。
それこそ>551が言うように、後からでもできる。

>556
企業じゃないし。
企業だとしてもソフトウェア会社用語なら、
生きてるうちには完成するだろうと思われるものを言うわけだから、問題はない（ｗ

>>556
>企業じゃないし。
>企業だとしてもソフトウェア会社用語なら、
>生きてるうちには完成するだろうと思われるものを言うわけだから、問題はない（ｗ

はあああ！？

そんな会社すぐに潰れるわ！！　ボケ！

>>559
>今しかできないことがある、というのが川合流。

「今しか出来ない事」が有るのは当然。
その見極めが狂いまくってるのが、川合流、な・ん・だ・よ！！！！！

ボケタリン！！　カス！！

というわけで、今からここは561が
「今しかできないこと -川合流の失敗-」
を題材に小一時間講義するスレになりますた。
さあどうぞ！

>>556
国の計画決定じゃないんだからさあ。
それにしたってマスタープランなんてのは目標レベルの話。
だいたい、予算が付かなきゃ凍結でしょうに。
まあ逆に計画が時代後れになっても予算の関係で強行なんて話も聞くけどね。

>>561
あえて特に言わないけどさあ、そういう批判してなにか得する訳？
優先順位に異議があるならその考えを言った方がいいんでない？

個人的には何故本番環境へのつなぎであるはずのエミュを後回しにするのか？かな。
例えばえみゅでDOSのシステムコールが使えればわざわざOSでエセをやる必要は
ないだろうと。

>>562
>というわけで、今からここは561が
>「今しかできないこと -川合流の失敗-」
>を題材に小一時間講義するスレになりますた。
>さあどうぞ！
講義で是正されるようなものじゃ無かろう。
どうせ、「僕はこれが最高だと思ってるんです。」と返されて終わる。

>>563
>個人的には何故本番環境へのつなぎであるはずのエミュを後回しにするのか？かな。
>例えばえみゅでDOSのシステムコールが使えればわざわざOSでエセをやる必要は
>ないだろうと。

そうしない理由が、なぜか知りたい？
本当は、「後回しにしてるだけ」と言っているのは口先だけの言い訳なんだよ。
真実は、単に技術力が無いだけ。
技術力が無い事で全て説明がついてしまう。

「優先順位が僕としては低い」みたいなことを言うのは言い訳で、
本当は技術力が無いだけなんだよ。

>564
別に川合さんを説得汁とは言ってないぞ。ここは元々そんなスレじゃない。
漏れらが聞きたいんだよ。さあ、改めておながいします！


>565
何はともあれ、OS・アセンブラ・PC98エミュを作ってきたはずの人間に無い
DOSエミュを作る技術力・・・
凄いな。OADGのDOSは化け物か！

まあどんなものを「技術力」というのか、
「無い」というのはどんなレベルを指すのかは知らんが、
確かに川合さんに技術力と設計力がもっとあれば、もっと早く開発は進んでるだろうな。
激しくあたりまえだが（ｗ

>>566
>何はともあれ、OS・アセンブラ・PC98エミュを作ってきたはずの人間に無い
>DOSエミュを作る技術力・・・

それぞれの出来にもよるわな。
OSも中途半端、アセンブラも中途半端。
PC98エミュは知らんけど。

しかも作るのが遅いんだよ。

最低限のものを作る技術力と、評価されるほどのものを作るものでは
開きがあることもお忘れなく。

>567
なら中途半端なDOSエミュを作るのに何の問題があろうか。

> 最低限のものを作る技術力と、評価されるほどのものを作るものでは
> 開きがあることもお忘れなく。
まさに>565が忘れていそうな話ではあるな。

>>541
>M&Mに抜かれるのは時間の問題かと

チョコレートの会社だかとｵﾓﾀ。 >M&M

　いっとくがな、誰もKに、DOSエミュレータを作る技術力が無いなんて、
言ってないぞ。
　そりゃ、作れるに違いない。
　しかしな、OSASKがこの程度に繰るのに、これだけ時間がかかってる
んだ。実際問題、DOSエミュができる時間が有るとは思えない。

　それにな、誰でも時間をかければそれなりのものはできるんだよ。
けどな、一つ一つの精度や便利さとかで差が出るってこった。

　GUIでも、あの程度のものなら簡単。しかし、クリッピングをやろうと
すれば、遥かに技術力が必要になるんだよ。

　まあ、シェルにしたってそうさ。あんな程度なら誰でもできるが、
「まともな」シェルは難しいんだよ。分かったか！！

>>568
>なら中途半端なDOSエミュを作るのに何の問題があろうか。

あほかおまえは。
「中途半端」ってのは、実用的じゃないと言う事なんだよ。
実質何の存在意義も無いようなものを作られてもウザイんだよ！！！！！！

あんだけ偉そうな事言うくらいなんだから、プログラムのお勉強のために
作ってるんじゃなかろうて。

まあ落ち着けよ、カスども（AA略

>570
何がいいたいのかさっぱりだ。ちと英語で言ってくれんか？
...精度に差が出るからなんだ？
誰にでもできるからどうなんだ？
シェルも複雑になれば、それなりに難しいだろうね。で？
技術力がないとして、それがいったいどうしたんだ？
というか、それならますます川合さんに惚れそうだよ。
何しろ「時間のかかるDOSエミュ」に向かわないでOS作ってるんだからね。
OSにしても、「技術力」が必要なところを「ムリして」作らずに
重要だと信じるところから実装してるわけだ。
まったくもって正しい選択だな。
DOSエミュぐらいなら「技術力」のあるヤシが作ってくれるだろうし。


>571
アセンブラもOSも実用可能だが。少なくともバグがあって実行不可能な代物ではない。
でも存在意義はないな。確かに。
ちょうど>571の存在意義がないと言えるのと同じくらいにはない。
で、>571よ。>571にとって自分の存在意義はないのかい？

>>567
あの98エミュはかなりまともです。(音源ボード未対応だけど)

>しかしNASKはCOFFとバイナリモードのサポートがあって27.0KBですよ。
>これが時間さえかければ誰にでもできることなんですか？
　 ∧＿∧
＜後ろ頭＞-~~~ さてさてＫ氏に問う。
サイズを小さくする「技術」とは何か？
それは本質的な設計能力なのか？それとも単なる
コーディング上の"小技"の積み重ねに過ぎないのか。

>>574
うーん、K氏は、ミラクルな魔術師にはなれても金髪の小僧にはなれない
ってところかねえ?

個人的にはOTASKからすぐエミュの移植に掛かっても良かったような気が
するんだよな。妙にアカデミックな方向を目指してしまったから進捗がスローペース
にみえて何もできないファン？がイライラするんじゃないかって感じがする。
エミュの存在があるなら、エセの部分はその為の代用ルーチンということになるから
OSASKの評価とは切り離せたんじゃないかな？

>>574
>それは本質的な設計能力なのか？それとも単なる
>ーディング上の"小技"の積み重ねに過ぎないのか
小技に1票
設計能力があるならあーはならんでしょう。

というかきちんと設計能力があり、時間をかけることが出来れば
もっといいものが早くできる。
それがサイズが小さいかどうかは分からんが・・・

サイズが小さいことは悪いことではないが
そこまでのメリットはないし、胸を張って自慢してもしょうがないと思う。

所詮問題となるのはサイズのオーダーでは？
同じ機能のものを1000KBで作る人はどうかと思うが
200KBで作って、保守性・拡張性が高いのであれば
それもありだと思う。

そろそろ「エセ」逃避はやめて欲しい。

>575
エミュの部分といってもOSASKが単なるエミュにならないためには
APIブリッジが必要で、その設計にやはり同じぐらいの時間はかかると思われ。
その割にAPIブリッジだと設計の善し悪しがAPIほど簡単にはわからないだろうから、
APIから実装したんじゃないかと。

>576
うーん。
サイズが小さいかどうかが「いいもの」の判断基準の一つだと言ってるわけだが・・・
それに、別に"必要な"保守性・拡張性を落としてでもサイズを優先させるとは
言ってないし。同機能でサイズを小さくするということだからな。


あと、どうでもいいことだし、本質からずれるけど、
アマチュアが自分が決めたことを成し遂げたのなら
胸を張って自慢していいと思うぞ。

>>577
>同機能でサイズを小さくするということだからな。
　セクション（セグメント）もマクロも全く扱えない無いアセンブラの
どこが同機能なの。
　行番号デバッグ情報とかにも未対応だし。MMX/SSE/SSE2/3DNow!にも全く
未対応でしょ。浮動少数点命令はどうなの？

　これらは、かなりサイズに影響するよ。命令数の増加だって、ばかに
ならないよ。3DNow!/SSE/SSE2は、結構複雑だしね。全部入れてみてから
比較しないとフェアじゃないよ。

　あと、エラーメッセージも一種類しか出ないし。エラーメッセージを適切に
出すには、メッセージの文字列データ分のサイズの増加には留まらないよ。

>>577
>アマチュアが自分が決めたことを成し遂げたのなら
>胸を張って自慢していいと思うぞ。

アホ。アマの延長にプロがある。

OSASK-ML:
>正直なところを申し上げれば、僕にもはっきりとは分かりません。
>なぜか僕が作ると小さいんです。なぜなんでしょうねえ？
機能が少ないから。

>・・・どうして他の人たちはあんなに大きくなってしまうんですか？
機能が多いから。

>独学で勉強してきて、それなりにプログラムが書けるようになってみたら、
>なんかすごく人とは違うって気が付いたんです。
>だから実はさっぱり分かりません。
>僕としては、うぬぼれかもしれませんが、これこそ設計力の差だと思ってい
>ます。というか小技の積み重ね程度でこれほどの差がつくものでしょうか？

ずばり、うぬぼれです。

小技の積み重ね + 機能の少なさ

で十分あの程度のものなら作れます。

>578
漏れは
「保守性・拡張性などにおいて性能が違っていればある程度大きくてもいいだろう」
と言った>576に対して
「そういうものを犠牲にしてサイズの縮小を目指すということではないのではないだろうか」
と言ったのであって、
「何を言ってるんだいジョン。
例えばNASKは他のアセンブラとはまったく同機能なのにサイズは小さいじゃないかhahaha!」
などと言ったわけではないのですが、何か？


>579
それはしらなんだ。
プログラマに限ってもプロを目指そうともしなかったアマを限定人数分知ってるが、
ヤシらは例外なんですね。


>580
>>558から気になってたんだが・・・・あれはOSASK-MLじゃないぞ。

>>577
というか、最初は単なるエミュでよかったと思うんだよ。
但しOS内蔵で既存のが無くてもスタンドアロンで動くみたいな奴ね。
OSASK計画を意識してエミュを設計すればOS部分は幾らでも
後から拡張できる筈だし、ある程度固まればOSASKとして
独立させることもできたんじゃないかな？
その場合元々のエミュ部分はキラーアプリ化するわけで。

K shi wrote(2002/12/29):
>しかしNASKはCOFFとバイナリモードのサポートがあって27.0KBですよ。

tolset02のdoc_nask.txt(2002/11/10)
>将来的にはCOFFの出力も予定されていますが、今はバイナリモードしかできません。

とが矛盾してますが、バージョンアップしたんすか？

もし、バイナリだけなら、ORG書かないで、リンクしたらどうなる？

K shi wrote(2002/12/30)
>ASKAにはマクロもちゃんとあります。


tolset02のdoc_nask.txt(2002/11/10)
>２．NASMとの違いの要約
> (短所)
> プリプロセッサ命令(マクロ)は使えない。
> その他にもいくつかの制限がある(３．を参照)。
> バイナリモードしかサポートしていない。

どゆこと？？？

TIMESとかは、マクロじゃなくて擬似命令だよ。普通マクロと言えば、
equとか、macro-endmとかのことじゃないの。

Kは、言ってる事に矛盾が多くないか？
みんなどう思うよ？

単に説明更新してないだけでせう
ML追っかけてないとツライねえ

>>584
ああ、ASKAのことか。
なんだ、サイズ比較なんだから、NASK単体機能でなきゃ反則じゃない。
そんな詭弁を言わずに、なんだったら、NASK+ASKA のサイズと他の
アセンブラで比較すれば？

aska.exe : 79KB
nask.ese : 22KB

合計101KBだな（ｗ

おっと、nask.exe は、27KBか。
合計106KBだな。大丈夫かよ。（ｗ

> そんな詭弁
を言わなくてもいいんじゃないかい？
ちゃんと文章読めばわかるようなことを間違えて恥ずかしいからって（ﾌﾟｯ

nask.exeは、圧縮してんじゃないだろうな？
naskset0で、45KBなのに、naskset1で、22KBになってるのはどういうこと
なんだ！？

>590
説明書を一切読まずに使って失敗してクレーム付けた、という経験はないですか？
まあこの場合、はっきりとわかるのはダウンロードページだけっぽいけど。


どうでもいいけど、
> nask.ese
はﾜﾗﾀ
激しくいやな拡張子だ。

>>591
をい、なめてんじゃねえぞ。
UPX圧縮かけて27KBなら、そう断るのが普通だろ！
おまえなあ、自分が作ったものは自分が一番よく知ってるのは当たり前な
ことなのに、知らないことを馬鹿にするなよな。

フェアじゃないという言葉に尽きるな、全く。呆れたよ。。

結論を書いておくぞ。
NASK.ESEは、UPX外すと倍になるから、54KBってとこだ。
んで、これだけだと、マクロが使えないから、フェアな比較だと、
ASKA.ESEのサイズを加算せにゃならん。んで、ASKAも、UPXを外せば、
倍の158KBになるから、合計212KBだな（w

ヲーイ、大丈夫かあ（w

>>589
・・・で、見ての通り、
ちゃんと見ずにいい加減なこと言ってる厨が居るみたいだが
どうすればいいんだ？

サイズに関してはこのスレでも散々ネタになってきたわけで、
あえて断わらなくてもわかるでしょ。
というか一番最小になる状態で比較しなくてどうするんだ？

それでいいならうちのcygwinのas.exeみてみたら581KBあるんだが、なんだろこれ？

>ちゃんと見ずにいい加減なこと言ってる厨が居るみたいだが
>どうすればいいんだ？
そりゃ詭弁だ。

結論は間違ってないと思いますがね。川合さん作のアセンブラは、
結局、MMX/SSE/SSE2サポート無しの状態で、212KBと言う結論。

結論：Kの作るプログラムの密度は低いことが明らかになりますた。

ほう、漏れは川合さんらしい。じゃあそういう風に書いてみよう。

> UPX圧縮かけて27KBなら、そう断るのが普通だろ！
すいません。確かにそうかもしれません。しかし、言い訳させていただけるのなら、
これはダウンロードページにも、ドキュメントにも書かれていることです。
まあドキュメントにはUPXとしか書かれていないので（ダウンロードページにはUPX圧縮と書いてあります）
592さんには意味がわからなかったのかも知れませんが。

...ごめん。やっぱムリ。

おっと、スマソ>591=597ね。
というか、自分がたいていの人間が気付くことを気付かないバカだということに
気付いたからってそんなに興奮するなよ。
気付いただけマシさ！

とりあえずＭＬとか読んでない奴がいるって事はわかったな。
まあそれを前提にするのもどうかとは思うんだけどな。

つか、ASKAってどのぐらい氏の手が入ってるんだ？

>>598
>というか、自分がたいていの人間が気付くことを気付かないバカだということに
>気付いたからってそんなに興奮するなよ。
>気付いただけマシさ！

はいはい。
こちとら、このスレでサイズを測るためだけにダウンロードした
だけなんだよ。ほとんどドキュメントなんて読んでない。
まあ、普通、こんなもの使いたくも無いしな。（ｗ

600はどんなものを使いたいのか気になるなあ。

>>597
>すいません。確かにそうかもしれません。しかし、言い訳させていただけるのなら、
>これはダウンロードページにも、ドキュメントにも書かれていることです。
>まあドキュメントにはUPXとしか書かれていないので（ダウンロードページにはUPX圧縮と書いてあります）

あのな、何も書かなければ、圧縮してない生の状態だと思うだろ、普通。
今の議論では、「プログラミング密度」を考えてたんだから、圧縮した
なら明記せにゃ、議論にならない事は明らかだよ。

圧縮したと書かないことで、ごまかそうとした、に一票。

UPXが何を意味するのか分からないのが馬鹿なのか！？？？
ツールの名前を知ってることが頭のいい事だとでも思ってるのか？

あのな、ツールなんて物は世の中に五万とあって、日進月歩で開発
されてる。自分がたまたま使ってるツールを他人が知らないからと言って、
鬼の首を取ったかのように振舞うなって。

2chは日本最大のネットだから、たまたま知ってる奴が通りかかる確率が
高いだけなんだよ。「みんなが知ってる」わけではないぞ。

>>602
＞今の議論では、「プログラミング密度」を考えてたんだから、圧縮した
そんな話してたんだ、気がつかなくてごめんね。
ASKA込みのサイズの話だからてっきりバックエンドでなく実用ASMの話なのかと。

ASMサイズの話は以前に散々してたと思うのでそれを見てもらえると助かるな。
そもそもサイズ比較でNASKより小さいASMがあるって話で、
調べたらUPX圧縮されてたって事がわかって、
試しにやってみたら軒並み半分になってこりゃいいってことで
以降セット配布の実行ファイルもそうすることになったんじゃなかった？

大体OSASKのBINって圧縮対応だよね？

ま、OSASKのESEファイルは小さい事は小さいな。機能は全然だが（w

>600、>602、>603
おまいさん「フェア」にやりたいんだろ？
「フェア」ってのはドキュメントをロクに読まずにできるものかい？
ドキュメントに「UPX適応」と書かれてても知らないから無視？
UPXだけで検索掛けても大概のトップに出てくるのに、無視？
それとも何か別のものと勘違いでもした？

ツールの名前を知らないから。みんなが知ってることを知らないから。
勘違いしてるから。そんな理由でバカだとは言わない。
少なくとも本気でバカとは言わない。
しかし、書いてあることを無視しておいて
それを人の責任にして中傷を始めるヤシは明らかにバカだ。
心底バカだと思う。違う？

まあ>>591が本気で>>590をバカにしてるように取れたというのならその分については謝ろう。
単に「そう思うんなら調べろよ・・・」ってな感じで呆れてただけだが。

サイズなんてどうでもいいよ。
とりあえず速度面でNWSOSに勝てなきゃ。GUIでね。

ところで、今のOSASKのGUIは全て壊して、再建築するみたいだけど
これってOSASKのGUIアプリの互換性は保たれるの？
ここでいう再構築とは、あくまでもGUIシステム内部のみの問題？

　　　　　　　　　　　/＼　　　　　　　　/＼
　　　　　　　　　　 /　　＼　　　　　　/　　＼
　　　　　　　　　　/　　　　ﾞ'----''"´　　　　ヾ
　　　　　　　　　 /　　　　　　　　　　　　　　　｀:､
　　　　　　　　　/　　　　　　　　　　　　　　　　｀:
　　　　　　　　　|　　　　　　　　　　　　　　　　 　i
　　　　　　　　　|　　　　　　ノ '　　　　 　　　　　 |
　　　　　　　　　|　　　　　 .,___.,　　　　　.,___.,　　 i　　OSASKもうだめぽ
　　　　　　　　　 ､　　　 ''"´｀:､ 　　　　　　 υ /
　　　　　　　　　　｀丶,:' ､.　　. ）___Д____,,.,_,,.;''"
　　　　　　　　　　　/　　　　/　　　　　　　ο

>>607
apiの互換性さえあれば、GUIなんていくらでもかえられるんじゃない？
見た目だけなら今でもいろんなバリエーションあるし。
で、apiについては一新したとしても、旧タイプもapiブリッジでラッピングして
全部残すので心配は要らないんだそうだ。
しかしここら辺ってFAQになってないんだっけ？したほうがええんとちゃう？


関係ないけど、バーを消すのってどうやるんだろう？

Ｋさんのアセンブラが27kbでも、例えばWindows9xに置いてれば
物理的に消費するHDの容量は32kb+αなんだしねぇ。

でも、OSASKも含めて、今、もっとも小さな実行ファイルを実行できる環境は
実はWindowsなんだよ。（断定）

*.comファイルのことね。この*.comファイルは、Windows9xでもWindowsNTでも
きちんと正しく動作するのみならず、I/OポートやBIOSを叩いてもトラップで
再現してくれる。つまりWindowsが現在もサポートする正式な実行ファイル。

http://www.256b.com/
↑たったの256バイトで、レイトレや美麗なフルカラーデモが。

OSASKは2バイトで可能だろうか？
ソース見ると分かるけど、BIOSによるグラフィック初期化や、リアルモードに
マップされたVRAMへの直接アクセスなどを行っている。これらはWindowsの
カーネルがエミュレートすることで実現してるのだけど、OSASKの唱えるエミュOS
って、Windowsのほうがよっぽど実現してるし、簡素なOSなのではないだろうか？

×OSASKは2バイトで可能だろうか？
○OSASKは256バイトで可能だろうか？（いや不可能だ）

ちなみに、linuxではアセンブラでのBIOS叩きはサポートされてない。（当たり前だが）
上記のような256色ビットマップを扱おうとすると、それ専用のライブラリを
リンクせねばならず、その時点で実行ファイルは数十キロバイト長になって
しまった。
OSASKでは試してないが、linuxほど冗長にはならないと思う（アプリサンプル見た感じ）
でも、Windowsがサポートする*.comほどは小さくならないのも明確。
hello-worldなんてつまらないものでサイズ競争するより、
グラフィックデモのほうがサイズ競争としての題材がより実用的かつ適切だと思う（個人的に）

さて、現状、実行サイズ競争で、OSASKはWindowsに負けている。（linuxには勝てるだろうが）
これは、今勝てなければ、将来も勝てないと思う。

>>610
http://www.imasy.or.jp/~kawai/osask/boyaki04.html
まあ32bitコードと16bitコードの比較なら不利だろうけど
T-OS版に負けてるんだよなあ、なんでだろう？

つーか、やっぱWindowsってすげー。

>まあ32bitコードと16bitコードの比較なら不利だろうけど
16BitコードをいまだにきちんとサポートしてるゲイツOSを目の前に
そんな言い訳通用しないのも確かだよなぁ。OSASKも16Bitコードを
サポートすればいいだけの話なんだし、なによりもＫ氏が目指している
サイズ縮小への根本的なアプローチでもあるわけだし。

Windowsが現状、もっとも小さな実行フォーマットを提供するOSってことでOK？
Kさん、頑張って

>>615
まあ、その分OS本体が巨大なんだけどな。

サイズ縮小もいいけど、それなりのリソース拡大を先にしてくれ
って感じもするなあ。

>>616
freeDOSじゃだめ？

普通のプログラマが普通にプログラム組んで実行ファイルのサイズを比較したらどうなるの？
「普通の」ってのが曖昧すぎるから、厳密な話出来ないの分かってるけど、大雑把に言ってさ
Windowsが最下位な気がするけどどうよ？

>>618
そんなこともないだろうけど、環境によって動かないとかがありそうだなあ。
95駄目とかNT駄目とか挙動違うとかDLL足んねーとか。
そういうの考えてたら自前処理になってあんまり小さく出来ないような気がする。
つーか使用ライブラリのサイズ次第かも？
linuxはリンクの指定によって全然違ってくるんだろうなあ。

>>Windowsが最下位な気がするけどどうよ？
いや、俺の知る限り、linux上で走るgnomeだとかKDEのほうが太いよ。
GUI使うにしても、サイズにこだわりたい場合はWindowsの場合、リンカや
コンパイラのオプション一つで16Bitコードを吐き出せるモードが選択可能だし。
こうなると、コンパクトさではWindowsにはかなわない。

>>まあ、その分OS本体が巨大なんだけどな。
けど、Win95以降のカーネルであれば、
IPレジスタが通らないコード領域は、物理メモリにはロードされないから
実行ファイルがでかくても、メモリは圧迫しないんだよ。
使われてない機能は、ロードされない。

ひょっとして、OSASKって実行ファイルが20kbあったら、
物理メモリも20kb消費することが確定なの？

http://www.256b.com/
↑Ｋ氏が主張してたサイズへのこだわりを完全粉砕する結末だな。
彼らの能力をもってしても、OSASKで同じ内容を256バイトに詰め込むのは
不可能だと思われ。

>彼らの能力をもってしても
なんのこっちゃ。（w

>621
その実行される領域が多いんだけどな（ｗ

exeの内容をスワップに書き出さなくなったのは98/2Kからだっけ。
ホントに実装されてんのか？

>>610
まぁ、Ｋ氏のことだ。ＣＯＭ＝ＤＯＳ＝１６Ｂｉｔだと言い張って、
安い言い訳するに清き一票。

ただ、サイズにこだわるなら、x86なんかじゃなく、MIPS16だとかARM系の
CPUを目指したほうがいいかもな。8086もいい線いってるが。
あと、メガデモ連中にCOMが受けてる理由の一つに、やはりVRAMのマッピング
だとかBIOSのエミュなどが、Windowsでサポートされてるからだろ。
ある意味、あれらエミュは、コード圧縮の手段として機能している。

保護例外トラップをうまく使えば、例えば0x1232390にライトした瞬間、
画面が初期化されるだとか、サウンドが初期化されるだとかの機能を実装できる。
もちろん、パフォの都合上、乱用はできないだろうが、OSASKの今後のサイズ戦略として
有用なのでは？

>>612
> これは、今勝てなければ、将来も勝てないと思う。
何故？ 同じことをするエミュレータが付けば済む話なんじゃ？
にしても256Bって凄いね。驚いた。


あと、>>613のリンク先見たり、ここ見たりすると「16bitのほうがサイズは有利」
ってのが暗黙の了解になってるっぽいけど、そもそも それってどうしてなん？
直接 BIOS呼び出せるからってこと？ でも、割り込みでOSコール呼び出せば同じだよね？
「CUIのがサイズは有利」ってのなら良く分かるんだけど。

x86は扱うデータサイズが16ビット以内ですむ場合は
16ビットモードの方が短い命令コードになる不思議な石。

田中プログラム製作工房
まことに残念ながら、お亡くなりになりました｡
ご冥福をお祈りいたします。

なんでＫ氏ってなんでも拡大解釈するんだろ。
.comが万能だなんて、このスレの住人は誰も示唆すらしてないのに。
機能限定、軽量な.com「も」サポートするWindowsとして素直に解釈できないのか？
DOS時代のフォーマットだけど、現役の軽量実行フォーマットでもある。
なんとならば、.comからだってWin32APIを呼び出せるのだから。

64kbの壁があるのだって周知の事実。
けど、それで十分なアプリだってたくさんあると思うぞ。
Ｋ氏の唱える「サイズ軽量・コンパクト路線」って一体、なんなんだ？分からん

＞直接 BIOS呼び出せるからってこと？ でも、割り込みでOSコール呼び出せば同じだよね？
DOS時代のVRAMアドレスを直書きするx86コードでも、
Windowsのカーネルがトラップして、自動的に超高速エミュレートしてくれるから。

DOS時代のWORDだとかEXCELもサクサク動くし、DOSプロンプトの設定次第で
いちいちフル画面にもならないので、いまだに結構ユーザーが多い。
役所やなんかに行くと、その現場を拝めるよ。

　　　　　　　　　　　/＼　　　　　　　　/＼
　　　　　　　　　　 /　　＼　　　　　　/　　＼
　　　　　　　　　　/　　　　ﾞ'----''"´　　　　ヾ
　　　　　　　　　 /　　　　　　　　　　　　　　　｀:､
　　　　　　　　　/　　　　　　　　　　　　　　　　｀:
　　　　　　　　　|　　　　　　　　　　　　　　　　 　i
　　　　　　　　　|　　　　　　ノ '　　　　 　　　　　 |
　　　　　　　　　|　　　　　 .,___.,　　　　　.,___.,　　 i　　OSASKもうだめぽ
　　　　　　　　　 ､　　　 ''"´｀:､ 　　　　　　 υ /
　　　　　　　　　　｀丶,:' ､.　　. ）___Д____,,.,_,,.;''"
　　　　　　　　　　　/　　　　/　　　　　　　ο

256b が3倍になって1kb近くになったら、原作者の美学を壊すから
移植だのやめてほしい。ってか256に収まらないんなら、移植にならないよ。
言葉よく選んで。サイズに意味あるんだから。

http://www.256b.com/

っていうURLの名を汚すなよ、OSASK。

>>630
同意。

あと、DOSエミュレータ内では、*.comフォーマットは、今でも使えるのにも
かかわらず、256バイトに詰め込む一種の「遊び」や、せいぜい遺物の
実行程度にしか利用されていない現状が何を意味するか、Ｋ氏には再考を
願いたい。

　ある程度のコンパクトさは重要でも、開発時間、機能の量、保守性
などとのバランスを考えねばならないということが、大勢の見方で
あることを示唆しているように思われる。

>>630
>64kbの壁があるのだって周知の事実。
>けど、それで十分なアプリだってたくさんあると思うぞ。
>Ｋ氏の唱える「サイズ軽量・コンパクト路線」って一体、なんなんだ？分からん

ずばり、Ｋ氏は、自分が都合が悪くなってきたら言い訳をするタイプなのである。
その結果、「筋が通ってない」ように感じるのだ。

これまでのＫ氏の言動から、「サイズが小さい事」に究極的に拘っていると考え
るのは正しい。サイズが小さいだけで機能の差や速度の差を無視して
「優れている」と言い切ってしまうのがＫ氏流である。

　ならば、サイズが最小である*.COMをサポートしているWindowsの方が
Ｋ氏流には「OSASKよりも優れている」ことになるはずなのだ。

　それが当然の筋であり、それに言い訳をするのは、負け惜しみでしかない。

　Ｋ氏流な見方でも、OSASKには、Windowsより優れている点を見出すことが
出来ない、というのが正しく、客観的な結論である。


　大衆よ、Ｋ氏の詭弁に惑わされるな！

まーOSASKのサイズ戦略を重要課題だと仮定したうえで、気がついた観察なんだが↓
Windowsの*.comの実装って、コンパクト化って点ではひょっとして最強？
16色でいいなら、初期化コードゼロでいきなりVRAMにアクセスしたら色が出たよ。
実際には、エミュレータの初期化、VRAMアクセス時のページ違反 -> VRAM挙動エミュ
というエミュ・メドレーなんだが･･･
パレットの初期化も

mov dx,3c8h
out dx,al

って感じで、out命令の瞬間、Windowsがエミュってるに過ぎないのは
分かるんだが、これもある意味、圧縮API呼び出しと解釈できなくもない。
ライブラリをリンクする必要もないし。で、二度目以降のパレット設定では
dxレジスタへのセットは省けたりして、コードのコンパクト化はさらに進む。

ゲイツＯＳ、マニアのオモチャとしても通用するじゃん。さすが、256バイトで
レイトレできるわけだ。上記ＵＲＬたどっていくと、1024バイトもあるとさらに
大変なもの動いてるね。インベーダどころじゃないよ。
コンパクト合戦で負けてどうするよ

^(-_Д_-)/・・・次のＫ合の一手は「それならDOSエミュを載せればいいだけ」
と見たがどうよ？

>Ｋ氏の唱える「サイズ軽量・コンパクト路線」って一体、なんなんだ？分からん
これはOS自身についての話なんじゃないかな？

アプリについてそれを追及するのは単なる趣味と技術力の表明の為じゃない？
まあOSのサポートがあれば、それに任せられる分アプリのサイズが小さくできる
筈だと考えれば、それがシステム全体のサイズの大きさに釣り合う程あるとは思えない
って事なんでしょう。

というか今だにDOSが一番っぽいっていう結果もなんだかなって感じだけどね。

>>638
あなたは、Ｋ氏ですね。

エミュレータを作る予定だから Win/Linux/DOSに負けてるのを認めない。
もう、アホか、氏ねかと。

>>>Ｋ氏の唱える「サイズ軽量・コンパクト路線」って一体、なんなんだ？分からん
>>これはOS自身についての話なんじゃないかな？
ＯＳ自身のサイズにもこだわってるだろうけど、アプリサイズも異常な
こだわりを見せてたじゃん。実際、「ハロー世界」で異なるＯＳで比較列挙してたし。
ＯＳの実装を工夫することでアプリ側のサイズが無理なくコンパクトになる
というＫ氏の考察は、個人的には懐疑的だったが、２５６バイトデモの存在と
そのカラクリを知ると、これは正しい考察だったと断定せざるをえない。

#しかし皮肉にもそれを証明したのは、WindowsのDOSエミュだったけどね（ﾜﾗ

＞エミュレータを作る予定だから Win/Linux/DOSに負けてるのを認めない。
いや、パフォーマンスも達成せねばならぬこと考えるとDOSエミュは容易ではないよ。
それに、一言でDOSエミュって言うけど、これ間違った言い方だし。
VRAMトラップエミュ、BIOSエミュ、サウンド関連エミュ、マウスエミュ、
結局、PC/AT互換機エミュを作らねばならぬはめに。
これって、OSが肥大化するだけじゃん。

素朴な疑問なんだが、OSASKに詳しい人、俺の質問にマジレスしてくれ。

OSASKの唱えるエミュって、例えばWindows、linux、DOS、PC-98
その他Amigaなど多数の機種のエミュレータをOSレベルでサポートすることを
唱えてるけど、これって既にWindowsだとかlinuxで網羅されてないか？
レジューム機能（エミュ内のRAMやレジスタなど全ての状態のセーブ）だって
サポートされてるエミュがほとんど。画像取り込みだって、PrintScrn一発で
クリップボードに貼り付けられるし。

で、OSASKの自称エミュOSとやらのWindowsやlinuxに対する
アドバンテージってなに？

>>642
要するに、Ｋ氏の主張は二重の矛盾を含んでると言う事。

一つ目は、「エミュを作るから、これで大丈夫」と言ってごまかす事。
もう一つは、「Windows/Linux/DOSエミュが作れる」という自信。

>>643
>で、OSASKの自称エミュOSとやらのWindowsやlinuxに対する
>アドバンテージってなに？
Ｋ氏自信は「高速になる」と主張してる。

しかし、OSASK自身の性能がWindows/Linuxを超えない限りはありえない話
であるという意見が標準見解だと思われ。

>>643
OSASKの目指すエミュレーションと言うのは
エミュ起動->アプリ実行
という手順じゃなくて
ネイティブアプリと同じ感覚でエミュレーション対象のアプリが起動できて、
アプリ間のコピペなんかもできるという風に自分は解釈しているんだが。

実現できればけっこう便利だと思うけど、実装されるのはいつになるか…

>>646
そんなレベルまで行くのは100年はかかると見た。

　VMWare, VirtualPC, Bochs などの方式は、クライアントOSが
進化しようと無修正で対応できるが、
「ネイティブアプリと同様の感覚で起動できる」ような方法を
したいなら、Windowsが進化するたびにOSASKも修正が必要となる。
　Windowsの開発速度は、人海戦術で凄まじいので、追い続ける事は、
絶対無理。
　万が一出来たとしても、常に「後追い」になるため無意味。

>>639
なんでやねん

>>643
と考えるとまずはやっぱりサイズって事なんだろうね。
自分で>>642作れば絶対そんなにでかくならないって思ってるんじゃない？
たしか98エミュは、98DOSの起動FDにエミュ本体が収まった気がするし。

>>646
シェル周りは便利になるといいねえ、まあその前に管理するべきリソースを
増やしてほしいかな？

>>648
エミュレータはオプションだからエミュレータだけ修正すればいいんじゃないの？

>>641
自分に都合の良い結論にならないと理解できないアホってことか

>>648
確かに。
直接起動系のエミュレーションだとwineなんかが有名だけど、
完全エミュレーションには遠いしなあ…

>>651
Ｋ氏がアホと言うのは言い過ぎ。
世の中広くて、上には上がいると言う事。

http://freeweb2.kakiko.com/jjkiknjpg/asgvearg.htm

>>648
ただ、どっかの機種のLinuxカーネルのように
互換機版がリリースされるとすぐさま追従してしまう
って事もあるからなあ。

後追いには違いないけど、新機能が実際に使われるようになるまでには
間があるから、その間に追いつければ問題ないんじゃないかな？

>ただ、どっかの機種のLinuxカーネルのように
>互換機版がリリースされるとすぐさま追従してしまう
>って事もあるからなあ。

Linuxはソースがあるから、他機種に移植できるのは当然。
Windowsのソースはないんだから全然違う。

>>656
つまり、どんなに人海戦術で凄まじくても
ソースがあれば移植できるのは当然ということですか？

>>657
>つまり、どんなに人海戦術で凄まじくても
>ソースがあれば移植できるのは当然ということですか？
ソースがあっても移植できるかどうかは、移植技術が物を言う。
しかし、元のコード量が多くなっても、移植時間が比例して
長くなったりする事はない。

しかし、ソースが無い状態からクローンを作るためには、元の
コード量に比例した工数がかかる。

Win32エミュはWineのソースをベースにして頑張って移植することになるのかな。
結局、ソースが公開されてるエミュを参考にするのが一番近道だと思う。

問題は、川合さんがどこまでやる気かでしょう。
ツールとかユーティリティくらいなら協力できるけど、
エミュレータ-となるとOSASKコミュニティの中でも対応できる人は少ない。

といって、さすがに川合さん一人の手には余るでしょうし、
どれだけ有力な協力者を集められるかでしょうね。

>>658
どちらかというと出来上がりのコード量に比例するんじゃないかな？
何か流用できるものがあればそれは小さく出来そうな気がする。
というか最近の新機能とかってなんだろう？

>>648
エミュが実装するのはwinのAPIまでだよね？きっと。
winのAPIって人海戦術による凄まじい勢いで増えてるの？

(･∀･)ノ windowsのAPIは平均して一日に20個のペースで増えてるよ。

なんか約一名、古代人がいるな。
それはともかく
>>643
エミュOS＝下位互換はエミュとして切り離して新規設計のOSを作ろう
ということだったはず。
サポートとして>>646の言うようなことがあるのと、
そのエミュモジュールの設計に関する意見が混じってるから
わかりにくくなってるだけだと思われ。

漏れは高いお金を出してでかいWindowsを買うとします。

＞それでOSASKとWindowsの比較になるわけですが、勝負になっているんですか？
なってるだろ。あの手のデモは *.com でも、生DOSでは起動できないものが
たくさんあるのを知らんのか？VESAでマニアックな解像度でもWindowsで起動
すれば、下端に隙間が空くけど、ある程度融通を利かせてエミュってくれる。
で、同じマシンで、生DOSだと起動できない。

＞ここではサイズ比較ですよ？分かっていますか？
＞せめて、DOSとOSASKの勝負にしませんか？
だから、Windowsも*.comをネイティブでサポートしてるし、
実際、生DOS以上の機能で起動するんだから、WindowsとOSASKの勝負だろ。
サイズ比較だよ？分かってる？>>K氏
256バイトでもを3倍程度のサイズもあればOSASKに窓表示こみで移植できるとか
寝言は寝て言えYO。*.comファイルも窓表示で多数起動可能だぞ。

　そもそも、どのOSにおいても、インタプリタ言語の中間コードならもっと
小さくできるな。
　ネイティブアプリかどうかなんて、言葉のあやみたいなもの。
　インタプリタ言語のようなものをカーネルに内蔵したら、それが
ネイティブになるのだから。

　だから、機能密度の優秀さはOSの優秀さの物差しにはならないのは自明。
それをウダウダ言うの、いいかげんやめてくれ、Ｋ．ｳｻﾞｲ。

Ｋさんの目には wineはどう写ってるのかな？
うまくいってると見ているのか、いっていないと見ているのか。
いっていないと思っているのなら何が原因だととらえているのか。
OSASKならその原因にどう対処できるのか。

>>666
というか元々、OSのサイズが小さいので機能が著しく劣っているんだろう。
っていう主張に対して機能密度で反論してるんじゃなかったの？
まあ、ちっこいデモ程度ではどちらも趣味レベルの技巧に走ってしまって
比較の意味が無いと思うんだけどね。

それにしてもちっこいけどリソースいっぱい使える仮想マシンとかがあると
面白そうだね。

　万が一、世界一機能密度が高いOSだったとしても、機能の絶対量が、
OSASKのような低レベルであれば使い物にならん。
　改善される気配もない。なぜなら、欠点を指摘されても認めないからだ。

>>669
まあ使い物にならん事の証明は難しいからなあ。
売り物にならない証明なら並べて売ってみればいいだけだけど。

大体、使い物にならないならあえて必死になって主張する必要もなく
単に愚痴がぽろぽろでるだけだと思うなあ。
例えばこの板のOSの大半に言えるけど、アプリが無ぇーとか（ｗ

一番手っとり早いのは使えるソフトを作ってみることかもね？
OSのサポートが使い物にならないから全部自前で持たなきゃ駄目だった。
みたいな奴。足りないところを適当なライブラリを引っ張って突っ込んじゃえば
サイズは膨れるだろうから、同じソフトを別のOSに移植したらこんなに小さいのに
って事をやれば、さすがに認めるんじゃないの？

というか、欠点を指摘されて認めなかったことってなんだろう？
的を射た指摘では、見るかぎりそんな感じはしないんだけどな。
認めても言い訳してすぐには改善しそうもないから
認めないのと同じって事？