【C】Poneytail(仮称)OSスレッド01【未踏】

1 ：05/01/11 〜 最終レス ：2012/06/05

公式サイト:http://www.tirasweel.net/ponytail/
未踏について:http://www.ipa.go.jp/jinzai/esp/2004mito2/koubokekka.html
関連スレ:http://pc5.2ch.net/test/read.cgi/os/1093825736/l50
2004年度未踏ソフトウェア創造事業採択プロジェクト
テーマ:CLIを実装する次世代オペレーティングシステムの開発
C#でアプリを作成できるOS？ランタイムはMono譲り？未踏の血税で開発中！

2 ：

２

3 ：

ム板でいつもやらかす厨がいるんだけど#はスレタイに入らない
C♯って入れないとダメだよ
C＃じゃなくてC♯ね

4 ：

　　　　　　　　　ヘ　 o ,　　　 ── / 　 ＿_, 　 /　　＿,　　 /_/_/ 　 　 　 ＿_, 　 /
　 　 　 　 　　/　　＼ ´　　　── /　 　 　 　 /　 　─'　　/　 　 ＿　　　　　　　/　
　　 　 　 　 _/　　　　＼ 　 ＿＿ /　　 ＿＿_/ 　 ＿＿＿/　　　　　/　　 ＿＿_/
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 ￣￣￣
　　　　　　　　　　　　　　　　　　　　＿　, ― ､
　　　　　　　　　　　　　 　 　　,−'　　｀　 　　 ￣ヽ_
　　　　　　　　　　　　　 　 　,'　　　　　　　　　　　　ヽ
　　　　　　　　　　　　　 　　(　　　｀ｰ'ｰ'ヽ｀ｰ'ｰ'ヽ　　）　　　　　 　　
　　　　　　　　　　　　　　　（　 ノ　''''''　　　'''''':::::::ヽ　 ）
　　　　　　　　　　　　　　　（ . ）（●）,　　　､（●）､.:(　）　＋
　　　　　　　　　　　　　　　（　)　　 ,,ﾉ(､_, )ヽ､,,　.::::（　）　 　 ＜４様が華麗に４get！
　　　　　　　　　　　　　　　. ヽ ）　　 ｀-=ﾆ=- '　.:::::::|ﾉ　　+
　　　　　　　　　　　　　　　　　 ＼　　｀ﾆﾆ´　 .:::::／　　　　　　+
　　　　　　　　　　　　　　　,,.....イ.ヽヽ、ﾆ__ ーーノﾞ-､.
　　　　　　　　　　　　　　　:　 　| 　';　＼_____ ノ.| ヽ　i

5 ：

開発者です。
紹介文にたいする簡単なコメント。
・C#でアプリは作れませんが、
・C#で作ったアプリを動かせます。
　・WinかLinuxでコンパイルしてください。
　・別にC++でもVB.NETでもJ#でも可。
・ランタイムは独自開発です。
・クラスライブラリはMonoのものを使っています。
・未踏に採択されています。がんばります。
次のコメントで特徴なんか書いてみます。

6 ：

Ponytail の他の OS と激しく違うところです。
・IL （.NET中間言語） を解釈実行します。
・アプリを含むすべてのプログラムが特権レベルで動作します。
・すべてのプログラムが同じアドレス空間を共有します。
いまはこんなところです。やみくもに予定とか書いても仕方ない気がしますし。
>>1さん乙です。
またーり楽しんで頂ければ幸いです。>ALL

7 ：

ライセンスとかどうなるんでしょう？（予定でもいいので）
商用を視野に入れているとかですか？

8 ：

バイナリは無償で配布自由にしようかと。
ソースはクローズですが、恩返しの意味も込めて
これからOS開発する人に役に立ちそうな部分は公開したいと思ってます。
商用は、、、なんというか、商用になれるレベルにしたいってとこまでしか思い描けませんね〜

9 ：

バイナリは無償配布との事ですが、Reflectorとか使っていいのでしょうか？
つい最近もMVPがHS+をILDASMして問題化しましたが、、、

10 ：

Reflector使えますね。いま自分のライブラリをReflectorで精査してますし。
使ってくださいとは言えませんが、事実使えてしまうので止めても無駄かなと思います。
ただ、それでリバースエンジニアリングしたものを無断で再公開とかはやめてほしいなあ。
ところでMVPとHS+ってなんでしょう？　ILDASMは IL DisASseMbler ですよね。

11 ：

>>10
MVPはMS認定のmost valuable people
HS+はOffice2003のHomeStyle+
http://pc5.2ch.net/test/read.cgi/tech/1103381010/68

12 ：

早速MSILスレで晒されてる
http://pc5.2ch.net/test/read.cgi/tech/1095947017/l50

13 ：

>>6
なるほど。
JavaOSとは．．．
・classファイルを実行可能
・すべてのプログラムが特権レベルで動く
・すべてのプログラムが同じアドレス空間を共有する
JITで出来るバイナリが十分良質であれば、特権レベル切り替え・ページングに伴うオーバーヘッドがなくなる分、
理論的には早くなり、メモリ保護はネイティブインターフェイスを禁止することで行うと言った所だったと思います。
.NETかJavaかの違いがあるとはいえ、JavaOSと違いが見えてきません。
この既知の技術に対しての相違点等があれば、差し支えない限りでお聞きしたいです。

14 ：

JavaOSとPonytailの違いは、すべてJavaと.NETの違いということになると思います。
つまりコンセプトについてはJavaOSとあまり違いません。

15 ：

結局JavaOSは一般に入手可能なものがフリーで公開されることはありませんでしたからね。
そういう意味で一般に公開するものとしての存在意義は充分あると思います。
頑張ってください。

16 ：

>>15
でもそれだけのために未踏が通るとも思えない。
コンセプト実証品ではあっても実務への応用が望めそうもないから。
OSそのものというよりも、組み込みレベルでも.NETを使えるような技術を作って、
後々はITRONとかの上にも載るようなKVMみたいなものに応用するとか
そういうビジョンまで提示したのだろうか。

17 ：

あ、>>11さんありがとうございます。
そんなことがあったんですね。
逆解析にたいする脆弱性はJavaでも似たようなもんですし、これからの課題なんでしょうか。
ちなみにMSはインターネットを利用することで解決しようとしているみたいですね。
>>15
ありがとうございます。
>>16
いえ、究極的にはそれだけです。
未踏は、成果物でIPAが儲けるわけではないので、応用面だけで評価するのはちょっとずれてる気がします。

18 ：

>>17
OSASKのときには応用面が問題になったと記憶しています。
それで結局ユースで妥協したけど後が続かなかった筈。

19 ：

>>15
JavaOSモドキ的なJNode
http://jnode.sourceforge.net/portal/
>>16
そこがやはり気になるところですね。
>>17
なんらかのあっと驚く改善点・着眼点などを隠し持たれていることを期待しています。

20 ：

>>17
VS.NET付属のDotFuscatorはそれほど強力ではありませんが、
有償のバージョンだとかなり効果があるみたいです。
しかしMS製品のアセンブリはfuscatorをかけたりしてません。
逆解析が簡単なのは諸刃の剣でパクった側も晒されることを意味するので、
見ることは出来てもパクるにパクれないという状態になって、
実際はあまり大きな問題にならないと割り切ってるように見えます。
内々に使われて公開されないようなツールに使いまわされると手が出ませんが、
そんなのは企業内違法コピーと同じで撲滅はほとんど無理でしょうし。

21 ：

作り始めたのマジで去年のCマガからなんで、詳しくなくてごめんなさい。そんなことがあったんですね。
OSASKに限らず他の独自OS全般に言えることだと思うのですが、
普及のためには結局"開発者"を奪い合う必要がありますよね。
シェアも奪い合いですが、それよりも開発者を排他するのが大きいと思います。
この問題があるかぎり、独自OSはけっきょくパイの奪い合いであり普及はしないと思うのです。
そして僕がPonytailにあり既存のOSにはない、機能以外での有利な点として、この開発者の問題があります。
.NET (IL) にすれば、開発に参加して頂ける方は Ponytail のためだけの時間を割く必要はありません。
また、もし他のチームが Pure IL 型OSを作り、それが Ponytail を超えたときでも、作ったものは無駄にならないはずです。
なので、
・Ponytail が成功して普及すれば御の字　（がんばるけど、でも客観的には無謀ですよね）
・Ponytail が失敗してもノウハウは生きる
・どちらにしろアプリ資産はWinその他で動く
・.NETが滅亡するとちょっと困るけど、それでも中間言語を直接ホストするのは珍しいから役には立つだろう
ということです。

22 ：

>>19
あ、やっぱりあったんだ。散々調べたのですけど、見つけられませんでした。
まあなんていうか、Javaのもあっていいと思います。
それどころか.NETのOSもPonytail以外にもあっていいと思います。
いろいろな新しい方式のOSがあって、そのうち運良く上手くいったものを使ってエンドユーザが幸せになれればそれが一番ですよね。
そうなったときは大成功したOSが脚光を浴びますけど、草葉の陰で消えていったものにも価値があることには変わりないと思います。

23 ：

>>21-22
実際に採択されるという事はご自身は気づいていなくても、
なんらか魅力的な部分があったと思いますし、これからです。
どのような物になるか開発成果を期待しています。

24 ：

>>21
＞.NET (IL) にすれば、開発に参加して頂ける方は Ponytail のためだけの時間を割く必要はありません。
これは本当に重要。
どこの馬の骨とも知れないOSでしか動かないプログラムを作ったって村の英雄が関の山。
はっきり言って労力が報われることはない自己満足の世界。
ライブラリを作るなら最低限Windows、可能ならUNIXでも動くように作って、
独自OSとは無関係に使用してもメリットがあるものでないと意味がない。
更に独自ライブラリ自体に使わせるほどの魅力を持たせるのは難しいから
普及しているもののサブセットを実装するのが現実的。
JavaはSunが権利を握ってサードパーティーが独自に動きにくい現状では
.NETがもっともそれに近い位置にある。
MSがJavaの当て付けにECMAに提出してMonoが頑張ったのが大きい。

25 ：

>>24 村田英雄? 逝ってしまいましたが…

26 ：

マジレス。
他のOS資産の流用なんてみんな考えること。
OSASKはエミュレータOSを売りにして他のOS資産の流用を宣伝文句にしていたが
現状は「エミュレータOS」とは程遠いと思われ。
他の和製OSでも互換ライブラリとか箱庭環境とか試みはあったけど全て頓挫。
初期の段階からOS自体に実装していかないとダメだろうね。
その意味ではReactOSが最右翼か。
.NETに限定した互換だと抽象度が高いしMonoの資産があるので
ReactOSよりも手に届く位置にあるとは思う。
あと>>25はいまいちです。50点

27 ：

OSを作ろうpart10より経緯を抜粋
951 名前： Be名無しさん 投稿日： 04/08/28 16:26
このスレの荒れようを見て新人が現れる事は期待できまい（藁
957 名前： Be名無しさん 投稿日： 04/08/29 00:44
>>951
作ってまつよ。
32bit保護モード、PE形式ロード、キーボード入力、800x600x24(32)フレームバッファの取得できました。
ついさっきマルチスレッドにできてちょっと嬉しかったです。
何書き込めばいいからよく分かんないし、まだ一人でコツコツやってたいのでひきこもりしてるんですが、なんか書く？
Monaコードには非常にお世話になってるから何か恩返しできればしたい。
958 名前： Be名無しさん 投稿日： 04/08/29 00:50
>>957
次からは君が主役だ！
とりあえず次スレ建てて乗っ取っちゃっていいよ。
出来るならね。（ｗ
959 名前： Be名無しさん 投稿日： 04/08/29 00:56
>>957
Monaのどんなとこがどんな風に役立ったかを書いてるだけでも充分に恩返しになると思う

28 ：

962 名前： Be名無しさん 投稿日： 04/08/29 03:51
>>957
タスクスイッチやタスクスケジューラ部分はMonaと同じ？少しアレンジしてみたとか？
もう少し語って。
963 名前： Be名無しさん 投稿日： 04/08/29 05:04
>>962
多分全然違います。そこらへんは全く参考にしてないので。
タスクはいまのところ全く扱っていません。全部スレッド。
メモリ空間も物理メモリまんまです。
とりあえずはメモリ関係よりキーボードとかFDCのが問題・・・。
キーボードはCマガと同じようにしてるんですが、実機で動かすとスキャンコードがKBバッファに残ったままになっちゃう。うーん。
964 名前： Be名無しさん [sage] 投稿日： 04/08/29 08:42
>>963
yukkyたんなの？
965 名前： 954 [sage] 投稿日： 04/08/29 09:49
>>963
ということは、殆どオリジナルっぽいってことですよね
というか次スレの中心人物にならない？
そりゃ煽られたり色々面倒な事もあると思いますけど・・・

29 ：

971 名前： Be名無しさん [sage] 投稿日： 04/08/29 15:49
>>964
yukkyさんではないです。
>>965
ちょっと事情があって、一番強調したい部分についてはしばらく公開できなさそうなので
それまで（あと３ヶ月ちょいかな）まったりやっていいんならてくてく書き込みしようかな。
別にスレの中心になるつもりはないかな〜。
OSって起動だけなら割と簡単ぽいので、いろんな人にチャレンジして欲しいし、
そういうときにこのスレッドはなるべく自由に書き込めた方がいいかなと思うから。
976 名前： Be名無しさん [sage] 投稿日： 04/08/29 17:01
>>971
やりやすいようにすればいいよ
がんばってねー
977 名前： Be名無しさん [sage] 投稿日： 04/08/29 19:02
>>976　ありがとー

30 ：

＞ちょっと事情があって、一番強調したい部分についてはしばらく公開できなさそうなので
＞それまで（あと３ヶ月ちょいかな）まったりやっていいんならてくてく書き込みしようかな。
なるほど、こういうこと（未踏、CLIなど）だったのですね。
作ろうスレでMonaの立ち回りに関するレスがありましたが
匿名を通すために未踏に申請なんかできませんし、
MonaにもMona.NETとか似たような構想はあったみたいですが
遊びで本気には見えないし公認プロジェクトですらないですから、
そういう差が超えられない壁になっているように見受けられます。

31 ：

>>30
957たんはWin32環境の作業に必要な知識は一通りマスターしているように見える。
技術的に可能な範囲を見極めてスマートに作業を進める実力はあるようだから、
人に聞きながら試行錯誤暗中模索のひげぽん氏とは同列には比べられないだろう。
デバイス制御とかに苦労してるみたいだけど畑違いというだけのことだし。

32 ：

>>17
未踏後の位置付けが微妙なのは確かだと思います。
商用で活路が見出せるのであれば他人がとやかく言うことではありませんが、
そうでない場合は持ち腐れになってしまうのではないかと危惧します。
かと言って営利無しでクローズなまま他人を巻き込んで発展していくのは厳しいでしょう。
そうなると記憶の片隅にでも留めて貰うためにはオープンソース化は避けられなくなりそうです。
いずれにしても今は未踏の範囲で成果を出すことに集中するのが第一で、
その後に考えれば良い事ではありますけど。

33 ：

>>31
泥沼を必至でかいくぐって来た卑下を生暖かくヲチしてたから
そういう要領の良さが目に付くんだろ

34 ：

卑下の場合は自爆っぽいからなぁ
自分からわざわざ面倒な方向に突っ込んで行ったりとか

35 ：

>>23
ありがとうございます。
>>24
理想を言えば、ReactOSみたいにWinのアプリを動かすとすごいんですけどね〜。
MSの.NET考えた人と、Monoの人たちには本当に感謝しています。

36 ：

>>35
ソース隠しても何かに違反しないの?

37 ：

>>30
そうです。
未踏に出したあとで類似のが発表されると、主観的にはいいんですけど、ちょっと立場が無いかなと思いました。
でも未踏はあくまでおまけです。未踏に採択されてもされなくてもPonytailは作っていたと思います。
Mona.NETの作者の方は結構すごいと感じました。
てっきりildasmとか掛けるのかと思っていたら、アセンブリ解析してたんですね。
今後C#で記述されたローダが必要になるので、PEAnalyzerLibの利用を検討してたりしました。
>>31
デバイスはOSはじめるまでノータッチでしたから…。
「Win使えばドライバあるじゃん」という典型的なWin派の思考ｗ
Linuxも使えることは使えますが、メインはWinですね。

38 ：

>>36
MonaはMIT/Xなので流用分は隠しもオッケー
MonoもクラスライブラリもMIT/Xなので流用分は隠してもオッケー
MonoのコンパイラとVMはGPLだけど
セルフコンパイルしないからコンパイラは関係ないし
ランタイムは独自実装らしいからVMも関係ない
MonaはGPLだったのがパクリ上等だろって横槍でMIT/Xに変更されたし
MonoのクラスライブラリもLGPLだったのがインテルの横槍でMIT/Xになった

39 ：

>>32
一番危険なのは就職して時間がなくなってしまったときですね。
そのときはオープンにしようか……まあ悩んでます。
どちらにしろ、名声とかお金のためにやっているわけではないので、
今はまだ自分だけのOSにしたいという気持ちがあります。
>>36
MonoはコンパイラがGPLでランタイムはLGPLなんですが、
クラスライブラリはMIT X11っぽいので隠しても平気…なはず。
どっちにしろクラスライブラリには一切手を加えてないので隠すモノもないです。
Monoをダウンロードしてmscorlib.dllをビルドすれば、それをPonytailで使えます。
総じて、オープンソースを利用させていただいて、もし改良するようなことがあれば
その部分はきちんとコードなりノウハウを公開することで恩返しをしたいと考えています。

40 ：

>>38
パクりたければ勝手にパクれば？ってときにMIT/Xに変更されることが多いなあ。
そういえばMesaもLGPLからMIT/Xに変更されたっけ。
これは確かXFree86-4へのマージのためだったからパクりとは関係ないけど。
逆にWineは独自ライセンスからMIT/Xにしてパクり上等みたいに構えてたら、
企業が勝手に細かい修正をしたのを使ってフィードバックしないのに切れてLGPLになった。

41 ：

で。
Poneytail使うと他の.NET環境と比較してどんなメリットがある予定なの？
そこが採択のポイントかと。

42 ：

>>39
＞一番危険なのは就職して時間がなくなってしまったときですね。
これはひげぽん氏を見ればわかるように最大の問題ですね。
＞そのときはオープンにしようか……まあ悩んでます。
自分の作ったものが飯の種になれば一番良いのですけどね。
うまくベンチャー設立に結び付いたりとか。
＞どちらにしろ、名声とかお金のためにやっているわけではないので、
素晴らしいです。
でも稼がないと生きていけないのが現実の厳しさです。
就職するとどうしても仕事が中心になってしまいますし、
自分のやりたいことでベンチャーを成功させるのは並大抵ではないですから。
＞今はまだ自分だけのOSにしたいという気持ちがあります。
そうですね。
・船頭多くして船山に上る
なんてことになったら本末転倒ですから。

43 ：

>>42
>・船頭多くして船山に上る
Monaがまさにそれっぽい
色んな人が色んなものを持ち寄ってくる
取り込んだものも卑下が消化して取り込むわけじゃないから
後で混乱の元になったりする
かと言って卑下一人でも迷走してしまうから
寄せ集めが悪いかというとそうでもないのが困ったちゃん
もっとも実力とか性格とかに起因してるから一般化できないんだけども

44 ：

mcs動かない。当然か。

45 ：

Ponytailにあるもっとも大きなメリットは、ほぼ.NET言語とC言語との違いです。
それらの言語間にある数々の隔たりは説明するまでもないと思います。
他の.NET環境、この場合はWinを想定します、との違いは、
・プロセス境界の有無
・プロセス特権レベル
・メモリ管理機構
・セキュリティ
が大きく違います。

46 ：

なんか大物動く?
ところで957氏,小手半にしたらどうだ?

47 ：

>>45は>>41さんへのレスです。続き。
プロセス境界はありませんので、たとえばnew FileStream()を他のプロセスにそのまま渡せます。
すべてのプロセスがRing 0なので、コンテキスト切り替えコストがとても減ります。
メモリはすべてGCです。これはなかなかシビアなので一概に利点ではないかもしれません。
セキュリティは例外とセキュリティ機構に分けられます。
たとえばバッファオーバーフローのたぐいはなくなりますよね。

48 ：

http://www.japanesegirlfriend.com/free/ponytail/ponytail51.jpg
ポニィテェル

49 ：

>>43
卑下の話はやめれや

50 ：

>>49
口調変化ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!

51 ：

>>44,46
IO周りを全然詰めていないのでたぶんほぼ動きません。
まだ "application" を動かせる段階ではないです。
公開のためにとりあえず標準出力だけ作ったという感じなので。
ただ、Managed C++ を使うとインラインアセンブラを書けますので、
頑張れば独自OSを起動できたりしますがｗ
＃この特徴を使ってドライバ書く予定です。

52 ：

>>51
see >>50

53 ：

>>51
トリップくらいは付けたら？
>>49みたいに他人になりすまされて滅茶苦茶書かれるよ？
ひょっとしてトリップのことを知らない？
名前の後に
#適当な文字列(8文字まで)
をつけると一方向ハッシュされて表示される。
「適当な文字列」を見破られない限り他人になりすまされなくなる。
例: 957#ponytail
このレスの名前欄にそう入れたから見てみてね
もちろんこんなのだとすぐバレるからダメだけど
ちなみにハッシュの算出方法はこんな感じ
$key = "ponytail";
$salt = substr($key . "H.", 1, 2);
$salt =~ s/[^\.-z]/\./go;
$salt =~ tr/:;<=>?@[\\]^_`/ABCDEFGabcdef/;
print substr(crypt($key, $salt), -10);

54 ：

PCが突然起動しなくなってびっくり。
>>50>>52>>53
>>49さんくらいはブラックジョークとして笑えましたが、
おっしゃるように付けておくことにしますね。
あとでサイトにも掲載しておきます。

55 ：

>>54
>>48は?

56 ：

>>48
どんなコメントを求められているのでしょう？ｗ
ま、荒らしにならない程度なら許容するのが2chでしょうね〜。

57 ：

monaってどうなったの？

58 ：

>>57
ここスレ違いだから、続きはこっちでやれや
OSを作ろうpart11　Mona専用
http://pc5.2ch.net/test/read.cgi/os/1098713480/l50

59 ：

どうでもいいけどPoneytailじゃなくてPonytailなんだね

60 ：

もしかして,最初はCLIOSにするつもりだった?
stringsして発見

61 ：

>>59
スレタイのponeyはスペルミス

62 ：

>>60
(CLIÉ + Aperios) / 2 みたいな響きでソニーチックだね

63 ：

>>60
ぉ、するどいですね〜。
開発するときのコードは今でも clios です。cli + os ですね。
ただ、あまりにそのまんまのわりには、覚えてもらいやすいとかそういったメリットがないなあと。
Ponytailは今度はあまりに脈絡なさ過ぎるだろうと思うので微妙なんですよね〜。
名前って難しい。。。
>>62
そそ。他にはクリオネにも似てますよね。

64 ：

>>63
CLIOSいいと思うけど

65 ：

MonoってManaged C++サポートしてたっけ?
MonoとMSの.netで動く大物アプリってある?

66 ：

>>51
＞ただ、Managed C++ を使うとインラインアセンブラを書けますので、
＞頑張れば独自OSを起動できたりしますがｗ
↑と
>>65
＞MonoってManaged C++サポートしてたっけ?
↑の絡みが気になる。

67 ：

>>66
Macとかでデバドラとかかけるのかと言う話。Monaスレ嫁

68 ：

>>67
Monaスレ読んだけど誰がMacでデバドラ書こうとしてるんだ？
脈絡がさっぱり分からないぞ。
Managed C++でデバドラを書こうとしているのは957でMonaともMacとも関係ない。
Monaスレの話は
1. 卑下がMacMiniに興味を持ったという話（買うと決まったわけではない）
2. G3に興味を持った無関係の第三者の話
3. secondbootをC#で書いたらMacでコンパイルできるのかという話
がごっちゃになってるけどドライバの話もManaged C++の話も出てはいない。
もちろんMonoでManaged C++をコンパイルすることは無理。
WindowsでコンパイルしたManaged C++のバイナリがMonoで動くかなんて試したことないけど無理でしょ。

69 ：

>>65
>MonoってManaged C++サポートしてたっけ?
してない。
>MonoとMSの.netで動く大物アプリってある?
Windows FormsのGUIアプリだとMono側の対応が不完全なので
大物小物に限らずまともに動かない。
でもWindows Formsを使わなければ結構実用的に動く。
現状のMonoはCUIアプリとWebアプリのためのもの。
GUIはGTK#推奨だがWindowsで動かそうとすると厄介なので論外。

70 ：

MonoがManaged C++をサポートしてないとなると
やっぱり>>51の↓の部分が気になる
＞ただ、Managed C++ を使うとインラインアセンブラを書けますので、
＞頑張れば独自OSを起動できたりしますがｗ

71 ：

リングゼロで動いてメモリを共有できるからって　いうじゃなぁい
それって　カーネルモードで動いてプロセス空間分離できてないってことですから！！
それってただのIPLじゃんぎりっ！！

72 ：

なんだまんまとC#にだまされたよ。。。
よくこれで未踏通ったな。
未踏の連中はあほばっかりだな。

73 ：

また税金がどぶに捨てられていくな・・・。
ひどい話だ。

74 ：

>>71
資源管理できればOS名乗ってもいいと思うがのう。
その理屈では携帯なんかもIPLだけで動いてることになってしまふ。

75 ：

>>70
まあサンプルですけど。
__gc class MyOS {
static void f() {
for(;;) __asm { hlt }
}
public:
static void Main() {
f();
}}
これが合法なので。頑張ればなんでもできます。

76 ：

>>71
IPLOSって名称もいいなあとか思いました（笑
アドレス空間分離は、アドレス空間分離機能があったからプロセス保護に使ったのではありません。
プロセスを保護するために、アドレス空間分離という手法があります。
特権レベルにしても同じことです。
機能を使うために目的を作り出すのはあまり賢くないと思います。
>>72>>73
うーん、この開発は僕にとってはとても難しいと考えたので、未踏性はそれなりにあると思っています。
でも他の人にしてみたらもしかしたら簡単で、未踏性はないのかもしれません。
ただ、JavaOSも同じ原理なんです。アドレス空間とか。
Sunの技術者陣が数年をかけたプロジェクトを、一朝一夕でできるというのは事実誤認だと思います。

77 ：

保護に関してはせっかくなのでもう少し説明します。
アドレス空間の分離はページングとかにも使ってますが、保護という観点から言えば
「他のプロセスのメモリの参照を禁止する」という機能です。
さて、C#ではポインタがないので、原理的に自由なアドレス位置の参照が出来ません。
ですから他のプロセスのアドレスを参照しようにも、そういうプログラムを書くことすら出来ない（※）のです。
なので、C#で保護を理由にアドレス空間の分離をする必要はないということになります。
特権モードも、所詮はI/Oと命令の制限ですので、同じことが言えます。
以上より、PonytailではWinやLinuxと違い、保護機構を無効にした状態でも同じ品質を出せる可能性があり、
その場合には（オプティマイザとかの性能で負けまくりですが理論的には）Winとかより高い性能が出せます。
これって開発する価値はある……と思わないかなあ？
ま、僕は思ったので作り始めてみたってわけです。

78 ：

追記
※にしたのは、アセンブラで書けるって言うのと矛盾するからです。
OSとしてアプリにアセンブラを許すとセキュリティホールになってしまうからです。
これについては、完成段階になるときに「ドライバや許されたプログラム以外機械語の実行を禁止する」というポリシーになります。
これはWinにおける.NETのセキュリティポリシーとも似ていますので、十分妥当だと考えています。

79 ：

必死だな。よっぽど痛いところをつかれたんだろうけど。
もうおそいよ。。
未踏の連中も気づくよ

80 ：

>>45, 47
レスありがと。
つまりは、実行が速いということでよいのか？
Winと比較すると、ネイティブアプリが一切実行できないかわりに、
CLIの実行に限ればより高速だ、ということでいいんだよね？
プロセス境界とか特権レベルとかメモリ管理とかは、
高速化のための手段と理解すればいいわけだ。
で、見込みとしては、どれくらい速くなりそうなの？10％くらい？
それと、動機にも興味がある。
高速に動かしたいCLIアプリが手元にあったのかな？

81 ：

80=957
顔が真っ赤になるほどのばればれの自作自演ヤメレ

82 ：

>>80
実行は速いはずです。実際にそういうOSがないので「はず」としか言えないのです。
もしかしたら局所性とかの問題で本格的なページングと併用した方が速いかもしれません。
Ponytailの未踏での目的の中には、そうした"はず"を確かめるための実証も含んでいます。
ネイティブは基本的には排除したいのですが、まあ、現実的には使えると速いので使えるようにはしておきます。
このとき、
・ドライバは常にネイティブ可
・アドミンはアプリでもネイティブ可
・ユーザは権限があれば可
・ネット経由プログラムは不可
とかになると思います。（これは未来予想図として捉えてください。運用問題は当面の目標ではありません。）
つづく

83 ：

OSASKは遅いといわれたセグメントをわんさと使い、
さらにリング切り替えにsysenterすら使ってないわけだが、
それでもあんなに軽い。
プロセス境界とか特権レベルってオーバヘッドほとんど無いような。
だから1％でも改善すれば、むしろ驚きかも。
未踏の成果発表の際には是非ベンチを頼むよ。
しかし、わずか1％のために新規にOS作る意味があるかというと、それは疑問。
OSASKにCLIエミュが載ったら、そっちのほうが速かったりしてな。
百年後かもしれんが。ｗ

84 ：

高速化の見込みは・・・ちょっとまだ分かりません。
さっきは実行は速いといいましたが、これは本当に対等の条件での話で、
実際には Ponytail 対 .NET Frmwk では、JITの性能がぜんぜん違います。
近年の中間言語モノの高速化はこれの進化が大きいので、
たとえ動作原理としては有利でもそういった理由により実際のアプリの動作は遅いと考えられます。
じゃあこれからずっと全然ダメかというとそうではなくて、
将来的にはJITをアドオンできる（ここに再利用性の高さが活きます）ようにしたりすれば、
オープンソースでの開発と同じような効果を得られるかもしれないとぼんやり思っています。
補足続く

85 ：

>>83そのとおりです。
速度の話をしましたが、作り始めたときに遅そうなのは分かってたので、未踏の申請でもちゃんと説明してあります。
「遅そうだし、OSなんて未踏期間じゃ絶対完成しません。」て。
C#が使えるというのは（新規性はない）技術的な面白みの話です。
じゃあ社会的になにか役に立つのというところでセキュリティがあります。
これはまあ出来て完成して普及したあとの話なので詳しく書きませんが、
コンピュータシステムを安心して使うためにはやっぱり大切なことだと思います。
結局、Ponytail は実用とか普及を目的にはしていません。
誰もやっていないから、やってみれば新しいことが分かるかもって試みなんです。

86 ：

あ、連投ごめんなさい。
実用・普及を目的としていないっていうのは、未踏期間みたいなスパンでの話です。
そのうち使いやすくなって普及したら嬉しいなあ〜とはもちろん思っています。

87 ：

>>71
iTROうわやめなにをすｋｂかるうはｌｓふじこ

88 ：

おいおい。
高速化の見込みが分からないって、
じゃあなんのためにプロセス境界とか特権レベルが
特徴に挙がっているわけ？
ネイティブが作りにくくなるだけやん。
ネイティブ完全否定かと思えば、
共存できるみたいなことも言い出すし。
まさか最初にOS作成ありきで、
後から製作理由をぶち上げて、
それで仕様を決めているなんて事はないよね？
なにか既存のOSにはできないことがあって、
それをできるようにするために、
新規にOSを作るのがベストだと考えた、
というのが普通だと思うんだけど。
結局WinやMonoの劣化コピーではないか？
>>21を読んで思うのだが、既存のILを
Ponytailで動かす動機って何があるわけ？
他の独自OSはBTRONもBeOSもOSASKでさえも、
まず既存のOSにない価値を提案しているが？

89 ：

>>88
既存のOSは、必要のために大抵「アドレス空間分離」と「特権レベル」を使っています。
Ponytailはそれらを使わずに同じ品質を得ようとしています。
これって特徴ですよね？？
機械語実行は、WinでのドライバとかLinuxでのカーネルコンパイルと同じ扱いです。
必要があればそうした手段をとれますが、OSが冒される場合があるので使用場面は限定されます。
OS開発そのものは、まずOSありきですね。OSを作りたいからOSを作る。
いま、コンピュータで便利に作業したいからOSから作るという人がいますか？？
こういったアイディアとか言うのは、順序論理ではないと思います。
AがBになりCになるのではなく、AとBがくっついてCになります。
書かれたような思考順序はビジネスでの考え方ですが、Ponytail はビジネスではありません。
OSASKを何度も挙げられていますが、僕はOSASKをよく知りません。
具体的に、Windowsユーザが今できないけどOSASKを使うと出来ることは何か、ぜひ教えて頂きたいです。
開発動機は面白そうだからです。世界で誰かやってるかなーと思ったら誰もやってないみたいだし。
これではいけませんか？
なにか崇高な動機を持ったOSをお探しなら、
残念ですが Ponytail は期待には添えないと思います。

90 ：

追記。
>結局WinやMonoの劣化コピーではないか？
C#を実行するアプローチが異なるので、どうやってもWinのアーキテクチャのコピーは出来ません。
それをふまえた上で、ユーザが出来ることが変わらない、という意味の劣化コピーという表現なら、まさにその通りです。
Ponytail で Windows と同じことができるなんて夢のようです。そうなればたくさんの人に使ってもらえそうですしね。
>まさか最初にOS作成ありきで、 後から製作理由をぶち上げて、 それで仕様を決めているなんて事はないよね？
Cマガ読んでOS作りたくなったので、順序からいえばそうなりますね。
>>>21を読んで思うのだが、既存のILを Ponytailで動かす動機って何があるわけ？
これは、他のOSの開発者の方に「Linuxにあるソフトをわざわざ動かしてどうするわけ？」と訊いてみればよろしいかと。

91 ：

せんせー。
ぜんぶりんぐぜろなおーえすだとけつぜいでやるにあたいしないんですか？

92 ：

> OSASKを何度も挙げられていますが、僕はOSASKをよく知りません。
> 具体的に、Windowsユーザが今できないけどOSASKを使うと出来ることは何か、ぜひ教えて頂きたいです。
俺がOSASKを引き合いに出したのは、>>21でOSASKが例示されていたからに過ぎない。
>>21がOSASKを引き合いに出したのは、おそらく>>18の影響だろう。
OSASKについてはここが客観的でまとまっていると思う。
ttp://www.ipa.go.jp/NBP/14nendo/14youth/mdata/2-3.htm
Winと比較だが、とにかく起動が早い。アプリが小さい。動作が軽い。
ロースペックPCやエミュではそれを強く実感できる。
ハイエンドでもこれがCPUのアイドル時間を増やして消費電力を抑えたり、
処理能力をさらに高めるという作者の言い分は説得力がある。
だからLinuxやWinのアプリをOSASKに移植してでも使いたいかと言われれば、
そういう場合もありうるとは思うよ。俺はそこまではやる気が無いがね。

93 ：

>開発動機は面白そうだからです。
Mona等のように個人またはグループで趣味として行うのは結構だが、未踏ソフトウェア創造事業を馬鹿にしているのか？

94 ：

>>93
本当は答える必要を感じないのですが、未踏周りは回答も義務かなと思うので答えます。
未踏を馬鹿にしているわけではもちろんありません。どこをどう曲解すればそんなふうに思うのか謎すぎです。

95 ：

>>94
変な香具師には構わないで開発に集中してくれ。

96 ：

LinusだってなんでLinux作ったかと聞かれれば面白かったからと答えるでしょ。
それでなんでいかんのやら。

97 ：

>>94
未踏の責任は成果を出すことだろう？
言い方悪いけど、
2chでQ&Aに答えるためにIPAが金出してるわけじゃないかと。

98 ：

>>94-97
ごもっともです…。
とりあえずいまは double 周辺整備してます。

99 ：

未踏の責任、新市場を切り拓くソフトウェアの開発を果たせるようにな。
開発楽しかったで終われば税金の無駄使いだからな。

100 ：

>>99
了解です。時間を上手く使わないといかんですね。

101 ：

後付けでもいいから、他のOS＋.NETではできない何かがほしい。
それないと移行する動機がないから普及は難しそう。
.NETだから、キラーアプリの出現ってのもなさそうだしね。
普及を考えないなら、他のOSを超える必要はないんだけど。
作る動機が「作りたいから」ってのは、別に構わないと思う。
でもちょっと心配なのは、作ることだけが目的のソフトって、
出来上がってしまったらオシマイで、作った本人も、
他の誰も使わないことがままあるので、そうならないでほしい。
個人的にはセキュリティに期待している。
早くこれを語れる段階になるといいね。
これが仮想マシン由来の、NXビット程度のセキュリティなのか、
もっと抜本的な何かなのか、興味があるところ。
未踏に関して言えば、957氏に採択の責任はないと思う。
957氏は提案した内容を実装すればそれで責任は果たされる。
採択に不満があるなら、PMに言うべきだよ。
もし結果的に税金の無駄づかいになっても、
それはPMの無駄づかいであって、957氏の無駄づかいではない。

102 ：

そりゃもっともな話だな。

103 ：

>>101
あれこれ考えてはいるんですが、OS開発って途中で頓挫しやすいので、
虚言にならないようにと思ってあまり話さないようにしています。
たとえば「最適化JITを使えばWinを超えられる！」とは言わずに、
「最適化JITがないから遅い」というふうな表現をなるべく使っています。
なので、ここから書く完全オリジナルは、ずっと先のことだと思ってください。
・JITを使って、ドライバコードをアプリに埋め込める
　たとえば、グラフィックドライバの一部をアプリの中に埋め込んでしまえます。
　MSがIIS6で、高速化のために一部をカーネル空間に配置したという事例もあるし、
　上手くいけばなんだかとてつもなく高速化できそうな気がします。
・Javaと相互運用
　Javaのクラスローダ作って型システムに合わせてやれば、結構上手く動きそうです。
　＃Ponytail の上に VM を乗せるという話ではないです。
　現状どのOSも、.NETとJavaオブジェクトが通信するにはものすごいコストが必要です。
　MSもやろうと思えば出来ると思うんで、完全独自にはならないかもしれませんが。
・分散環境
　.NETの特徴として、分散環境に適合しやすいと言うことがあります。
　いまOSの核はC言語で書かれているのでなにもできませんが、
　OSの中心から分散に適した形になった場合、なにかできそうです。。。（弱
たぶん、僕が考えてるより、いろいろできるんですよね…。上手く伝えられないけど…。

104 ：

続き。
モチべーションの持続は難しい課題ですね。
セキュリティはNXビット程度ではありません。もっと強力です。
詳しくは.NETのコードアクセスセキュリティとかを参照してください。ここで書くのは大変なので。。。
MSは昔ActiveXでいろいろやろうとしましたが、セキュリティが問題になっていまも不調です。
それをふまえて今度は.NETでやろうとしているので、セキュリティに関してはものすごい労力が払われています。
Ponytail は、それをOSにも適用してしまおうという考えなんです。
加えて、メモリアクセスがすべて安全になりますね。バッファオーバーフローによる乗っ取りはなくなります。
しかし、原理的に、ソフトウェアの論理ミスや運用ミスでできてしまうホールはなくなりません。
これは仕方のないことです。ただ、ソフトが作りやすくなる分、バグが減ることは期待できます。
僕は、こういった、「基盤の品質を上げて個々のアプリの品質を暗に高める」というアプローチが重要だと考えています。
特にセキュリティ周りはそうしないと、いつまでたっても個々の開発者任せになってしまい、潜在的なリスクを排除できないと思うからです。

105 ：

そーいや、そういう書き込み(ILを解釈してどうこう)をしてる奴が居たなー
もう1年ぐらい前になるか？

106 ：

>>105
さっきゅんは一時期ristiaを本気にやってたぞ
Kのnaskを改造したりして

107 ：

ponytailって日本語だと「おさげ」
和製OS界隈の人ならOSAGEを知ってるよね
ttp://www.osdev.info/index.php?topic=Osage
OSAGEは既に消滅してるしだからどうだってことはないんだけど
この界隈の人って発想が似てるのかなって思っただけ
ところで昔はz-slashにミラーがあったんだけど今はどうなってるの？＞雑記

108 ：

あ、雑記はセンター試験前日でこんなとこ見てる余裕ないか
悪かったね

109 ：

>>106
本当に惜しい奴を亡くしたな

110 ：

>>109
生きてるって
ttp://aireos.jp/

111 ：

ちょと前にドライバ云々の話を書きましたが、具体的にはこんなふうに。
// SETUP
IOPort.Write8(0x43, 0xB6);
IOPort.Write8(0x42, 0x98);
IOPort.Write8(0x42, 0x0A);
Console.WriteLine("BEEP");
// ON
al = IOPort.Read8(0x61);
Console.WriteLine(al);
al |= 0x03;
al &= 0x0f;
IOPort.Write8(0x61, al);
Console.WriteLine("ON");
// Wait
for(int i=0; i<100; ++i) {　Console.Write("|\r");　Console.Write("/\r");　Console.Write("-\r");　Console.Write("\\\r");　}
// OFF
al = IOPort.Read8(0x61);
Console.WriteLine(al);
al &= 0x0D;
IOPort.Write8(0x61, al);
Console.WriteLine("OFF");
//
VMwareでビープが鳴りました。嬉し。
IOPortクラスはMC++で、in/out命令だけアセンブラです。

112 ：

ちなみにそのサンプルコードそのものを内包したクラスはC#です。念のため。

113 ：

最近の技術は難しいね
.NET Frameworkとかみんなどうやって勉強してんのんかな

114 ：

http://www.ipa.go.jp/jinzai/esp/2004mito2/gaiyou/6-6.html
> .NETの実行環境であるCLI(Common Language Infrastructre)をハードウェア上に直接実装すると共に，
> 独自のOSを開発しようとする，野心的かつ意欲的な開発提案である．
ｶﾞﾝｶﾞﾚ

115 ：

>>114
このPM大丈夫なのか。。。orz
「CLIをハードウェア上に直接実装する」
って言うと普通Java Chipのパクリ品如く、
CLIをハードウェアで実装したマイクロプロセッサを作成すると言った意味になる希ガス。

116 ：

「ハードウェア上」だからそれでいいのか。
漏れの頭が逝かれているようだNE！

117 ：

>>114
ういっす。がんばってみます。
いまは起動方法の変更に着手しようとしてるところです。
現状だとインタープリタでVMの環境構築までやっているので効率悪いんですよね。

118 ：

>>113
.NETに関してはVS.NETを買わないと始まらない。話はそれからだ。

119 ：

>>118
なくてもなんとかなんない？
高いし、重いし、できれば使いたくないよ

120 ：

>>119
> なくてもなんとかなんない？
もちろんやろうと思えば何とかなるけど、
.NETをマスターしている人がその気になれば出来るものであって、
何も知らない人が手を出して使いこなすのは不可能。
> 高いし
タダで使えるやつを使え。
ttp://www.microsoft.com/japan/msdn/vstudio/2005/express/
> 重いし
そんなのトレードオフでしょ。
それなりのメリットがあるから割り切って使う。
GUIのデザインなんかちまちまコード書いてたら日が暮れる。
> できれば使いたくないよ
初心者がVS.NETを使わずに.NETを勉強するのは無理。
.NETを諦めるか、拘りを捨てるか、どちらかです。

121 ：

いちおう SharpDevelop っていうフリーのもあるけど、ウェブで情報を探しやすいのはやっぱりVS.NETです。
はじめてのときは自分が望む情報が手に入りやすいことも重要かと。
VS.NETで慣れて、期限切れたら SharpDevelop でもいいかもです。
SharpDevelop:
ttp://sharpdevelop-jp.sourceforge.jp/

122 ：

SharpDevelopあればVS.NETじゃなくてよさそう
複雑なことしようとすると必要かも
忘れてたがPonytailの板だったな

123 ：

Ponytail板?

124 ：

ttp://www.tirasweel.net/ponytail/homepage.aspx
ttp://www.tirasweel.net/ponytail/src/
ttp://www.tirasweel.net/ponytail/articles/
少しずつ更新してるんだ
しばらく開発してないのかと勘違い

125 ：

してますよ〜。日記とかないと日々の進捗は書きにくいですね。
MS.NETとかMonoは、C#の型システムの背後にC++で書かれた「本当の型システム」があるんだけど、
これが嫌なので、全部C#による型システムをやるために試行錯誤。ホムペの図はそれです。
型システムがないとシステム全体もどうにもならんので、告知に値するインパクトのリリースがなかなかできません。。。

126 ：

>>125
和製OS界で流行りのはてなにアカウント作っては？

127 ：

日記ならここでやって欲しいな〜
煽りは無視しちゃっていいからさ。

128 ：

はてなのblogでよくね？
技術者の話ほど貴重なものはない

129 ：

んー、ではここにぼちぼち書くことにします。
＃消費抑えるために毎日とかは書きません。
はてなだといちいち返事書くのが面倒に思った。
それにまだ"ユーザ"がいませんしね。
Ponytailが有名になる頃にちゃんとしたもの用意すればいいかな。

130 ：

というわけで、つっこみ歓迎で最近やってることなど書いてみる。
・まだ名前考え中。
昨日はPhaseshift,Intos,Primia,Selfinaとか思いついた。
・型システム
いま考えてるPonytailのブートシーケンスは次のような感じ。
　１　IPL > 1stboot > 2ndboot
　２　KERNEL.DLL(C++)
　３　ATAPI初期化してCD読む
　４　.NET向けシステムライブラリを普通のメモリ空間にロード
　５　ライブラリを解析してクラスとかメソッドの情報ゲット
　６　.NET向けの、GC的メモリ空間を用意
　７　ILインタープリタ(ILI)により、.NETメモリ空間内でライブラリの初期化
　　　※この時点では、型情報はカーネル空間に依存
　８　ILIにより、.NETメモリ空間にシステムライブラリを読み込む
　９　ILIにより、ライブラリを解析してメソッドとかの情報再ゲット
　Ａ　.NET空間の型情報をカーネル空間から.NET空間の方に移行
　Ｂ　JITコンパイラでJITコンパイラをコンパイル
　Ｃ　JITコンパイラでエントリポイントをコンパイル
　Ｄ　エントリーポイントにjmp
わかりにくいかな。で、Ａのとこやってます。
・JITコンパイラ
とりあえずこれがないと動かない。
こんな感じです。詳しい話がほしければレスください。

131 ：

そういえばVS.netで作成したDLLとかってOSで使用できるんだったっけ？
前Monaスレで聞いたらそう言っていたけど、その後何も無かった…
ちょっと気になる。

132 ：

というか教えてくださいorz

133 ：

>>131
ありゃごめん。学校と自宅でと見てると見逃してしまうことが…。
VS.NETなら、C#, VB.NET, Managed C++ （VC++）で作ればおけ。
自分でアプリ書く手順とかはPonytailのダウンロードのとこにちょこっと書いてあるので、
分からないとこは遠慮なくきいてください。
とりあえず試すにしてもまだ機能少なくて申し訳ないんだけどね…。

134 ：

いや、別の人が言っていたんだよ。
聞きたいことがあればって書いてあったので便乗しただけです
すまんorz

135 ：

>>130
Ｄ　エントリーポイントにjmp
とあるけど、ネイティブコードの利用は基本的に１〜Ｃのブート、初期化の時だけと考えてるの？

136 ：

>>134
お気になさらず。質問してくださったほうが歓迎です＾＾
>>135
そのとおりです。
最終的にはMMSからカーネル、ドライバまで、C#で書きます。
アプリ、ドライバ、カーネル開発者の誰も、アセンブラを使う必要はありません。

137 ：

>>115
マイクロプロセッサに実装する云々と解釈したって? …そう仮定する気心が知れん。健忘症か?
言語中立のオペレーティング環境という文脈で、加藤センセの成果物を知らん人はいないだろ。ここはOS板だよな。

138 ：

0.0.20.0 をリリースしました。
まだ外側には手を加えていないので、できることは0.0.17.0とほとんど変わらないのですが、
型がVMの中に閉じた個人的に記念すべきリリースなので告知です。
型がVMに閉じる、とは、ある型の情報がすべてVM内にあって、アクセスできることを言っています。
たとえば、現在の.NET Framework は閉じた型を持っていません。
typeof(int) -> System.Int32
typeof(int).GetType() -> System.RuntimeType
となり、RuntimeType はおそらくVM外部のランタイムとやりとりしてます。
これはMonoでも似たようなものです。（最終的に外部呼び出しになる。）
PonytailではVM内でシステムライブラリを再解釈することで、VM外とやりとりすることなくメタデータを操作できます。
んで、解析した情報と型を結合しているので、
typeof(Ponytail.Types.ClassType).GetType() -> Ponytail.Types.ClassType
こうなります。
いまのところまったく役に立ちませんが、JITをC#で書くのには必要な気がする。たぶん。

139 ：

訂正
typeof(int) -> System.Type
typeof(int).GetType() -> System.RuntimeType
.NETはこうでした。

140 ：

0.0.20.0リリースage！

141 ：

【日記】　今日はC#からFDにアクセスできるようにしてみます。

142 ：

さて、できるようになったのかね

143 ：

>>957氏
乙！

144 ：

>>142
昨日は頭痛でダウンしてしまいました。0.0.20のために数日頑張ってたので反動っぽい。
今日もFDドライバを頑張ります。いちばんの問題は delegate を割り込みハンドラにするところ。
>>143
ぅぃ〜！

145 ：

HDD Healthをみたら Nearest T.E.C. が 2005/02/05 のドライブがあったので、数日反応しなくなると思います。
ソースコード類が全部入ってるので洒落にならない・・・。
では

146 ：

開発を投げ捨てるときのいい言い訳だよね。
「ハードディスクが壊れました」

147 ：

さすがにいま投げ捨てちゃいかんだろう。
こういう事態に備えて、ネット上にバックアップを残しておくのですよ。

148 ：

バックアップ体制について釈明しないと信頼を失って
完成しても誰も付いてこなくなると思うんだが

149 ：

復帰しました。IO-DATAのUSB2外付け買ってきた。
ドライブ名の割り当てでちょっとつまづいてました。
いまはFDDの続きしてます。
>>146
ですね〜。高校の卒論の時はMOが消えました。パソコン周りはそんなこと多い気がします。
ちなみに「ハードディスクが壊れそうなのでなんとかします」なので、あしからずｗ
>>147
>>148
Visual SourceSafe のリポジトリをフラッシュメモリと研究室のマシンとたまに同期してます。
＃未踏の方にもソースコードの提出が義務づけられているのに、消えました、じゃ無責任ですしね。
ただ、周辺の開発環境はバックアップできるものでもないので、クラッシュするとやはりダメージでかいです。

150 ：

>>149
RAIDを使いましょう。外付けは定期バックアップ用にしてバックアップのときだけつなぎましょう。

151 ：

定期的にHDのイメージを吸い取ってネットワーク上に置いとけば
クラッシュしたときはFD突っ込んでネットワーク経由ですぐ復活できるよ。

152 ：

昨日の時点でqemuが暴走するとこまで出来た。
暴走するってことはIDTの設定ミスとかDMAバグバグとかいうことなので、今日はそこらへん。
うまくいけばもうちょいで出来そうな予感です。
>>150
RAID。。。内蔵HDDを増やすのは今のマシンだとキツいかなぁ。
確かにそろそろ安心を買う必要はあるかもしれない。
>>151
100GBoverをネットワークに置くのはちょっと面倒ですｗ

153 ：

なんで野良OSのソースが100Gもあるねん

154 ：

ちゃんと読めよ。。。

155 ：

そりゃちょっとでかすぎだな。
やっぱRAID+外付けHDDかね。
未踏ってよく知らないんだけど、経費として申請したら
お金だしてくれるの?

156 ：

開発環境だけ抽出してバックアップって難しいからそうするとHDDまるごとになっちゃうから１００Ｇくらいかなぁと。
ソースコードだけなら確かにネットワークに置けるけど、ソースコードだけならフラッシュメモリに保存できるので大丈夫なんですわ。

157 ：

>>155
未踏で出してくれるのでRAIDも選択肢です。（個人だとお金ないから無理・・・）
しかし唯でさえ金欠なのに、暫定支払いが３月末でそれまでは立て替えなので、RAID買う余裕はなさげ。
今回のHDDも身内借金でまかなったし。

158 ：

>>136
> 最終的にはMMSからカーネル、ドライバまで、C#で書きます。
さりげなくとんでもないことが書いてある…
ヲチしてみるか。

159 ：

>>157
概算払いが3末ということは、最近契約手続き終わったくらいか。
初回の概算払いは6桁後半は確実だから、それまで耐えろ。

160 ：

FDDの先頭セクタ読み込みｷﾀｰ！
C#によるFDDドライバ：
http://www.tirasweel.net/ponytail/src/viewer.aspx?path=ponytail/ptcorlib/Drivers/Devices/&file=FloppyDiskController.cs
いまFAT書きつつファイルシステムからアクセス可能にしてます。
でも結構量あった・・・。まあがんばろう。
>>159
了解っす。

161 ：

あんまりKとかひげぽんとかその周りとは関わらないようにして欲しいなぁ。
まぁ完全に個人作業となっているから大丈夫だとは思うけど。
無駄な争いが起きてそのために無駄な時間が掛かるのはお互いに不都合であると思うし。
裏で色々とあるらしいからな、関わると面倒だ。
とりあえずがんばって欲しいと思うわけでせう。

162 ：

本人および取り巻きが、MonaやOSASKと比較してどうだとかいわなければ、
他陣営からちょっかいを受けることはまずないと思われ。
>裏で色々とあるらしいからな、関わると面倒だ。
こういう失言が元で、信者から裏って何のことだとか言われて、ドツボになる。

163 ：

つまり俺がトラブルメーカーってことかorz
吊ってくる、すまぬ

164 ：

>>157
とりあえずリボで買っとけば良いと思った。

165 ：

だめだFD読み込み安定しない・・・、なぜか0Dとか00とか例外出る。もうちょいかかりそう。
>>161,162
関わらないというか、方向が違うので関わりようがないかも。
それに争い？も、ピンと来ないなあ。
ま、和やかに行きたいです。
OSって、はじめは一人なのに、最後は大勢じゃないと形にならないから、難しいですね。
>>164
さっきDELLから代替品が来たので、とりあえずこれにバックアップしておこうと思います。
カードも使ってるけど、基本的には好きではないので・・・。

166 ：

>>165
MonaもOSASKと方針が全然違うから干渉のしようがなかったけど、
Monaに湾岸が来てOSASK化をおっぱじめたからややこしいことになった。
OSASKの思想とやらをKが説いて追っ払われたが
KはOSASKに対する誹謗中傷と解釈して一人で怒ってる始末。
お前のことなんか誰も興味ないっちゅーの。
とゆーよーに他人が来ると必然的に人間関係がごちゃごちゃしてくる。
個別のOSがどーたらとかお山の大将やってないで、
全体としてOS開発に対する底上げという成果を出すべきだと思う。

167 ：

>>166
まあでも、発展途上中のOSのミドルウェア作ってると、カーネルを変更したくなるのは分かる気もします。
Ponytail は既存のOS化は絶対しないですね。それやるとアイデンティティが無くなってしまうので。
全体の底上げという意味では、まあ完成すれば結構いけそうな気がしなくもない。

168 ：

ということで（？）、0.0.22.0 リリースです。
予告していたC#によるFDD/FATの読み込みが出来ました。
ソースコードを公開していますので、技術的興味がある人はそちらをどうぞ。ptcorlib のあたりにあります。
一番面白いところは、
// public delegate void InterruptHandler();
// private static void HandleInterrupt();
InterruptHandler handler = new InterruptHandler(HandleInterrupt);
InterruptController.RegisterInterruptHandler(6, handler);
として、IRQ#6の割り込みを処理するところですかね。
本当は System.IO と統合してから公開したかったんだけど、
あそこらへん結構入り組んでるっぽいので一区切りしました。
System.IO.File あたりが動くようになればもしかしたら既存のソフトの中には動くモノがあるかもしれません。それを動かしてみたい。
この後すこししたら出かけるので返事は遅くなるかも。

169 ：

>>166みたいなやつがいるからトラブルになるって言っているのに。
>OSASKの思想とやらをKが説いて追っ払われたが
これは取り巻きの名無しが無知で断定的なことを書いたので、Kが補足に来ただけ。
というかこのときのKは控えめで態度がよろしい。
>KはOSASKに対する誹謗中傷と解釈して一人で怒ってる始末。
それどこよ。あのページにはないぞ。むしろこの書き込みこそ誹謗中傷くさいぞ。
>お前のことなんか誰も興味ないっちゅーの。
これも明らかにフレームの元。
ttp://mona.sourceforge.jp/dynamic/pukiwiki/pukiwiki/pukiwiki.php?%B5%C4%CF%C0%2F%B0%B5%BD%CC%B7%C1%BC%B0

170 ：

>>162
Kの犬は目障りだから消えてくれ。お前のせいで荒れて来たじゃないか。

171 ：

湾岸はOSASKのスパイ。そんな香具師にGUIを頼るしかない卑下。ただそれだけ。

172 ：

170=166
>171はmonaスレでやってくれ。

173 ：

やべー、俺のせいで本当に荒れてきた
ちょっちょちょっちょｔｙとちょとｔまｔってくれぇぇぇぇ
俺が悪かった。ご免orz
楽しく逝こーぜ、楽しくorz

174 ：

まあほんわり行きませう。＞みなさま
今日はVFSについて悩みつつ、いまVisioでモデリングしてます。結構いい感じだ。
今日はモデリングだけで終わりそうなので、実装は明日かなあ。

175 ：

957はプロ

176 ：

えーっと、割と学生です。
パスについて悩む。
path ::= (drive_name ':')? abs_path | rel_path
drive_name ::= [a-z]
abs_path ::= '/' rel_path?
rel_path ::= selector ('/' selector)*
selector ::= '.' | '..' | name
name ::= ふつうにファイル名に使う文字
つまり面倒だからWinとUniの両方でいいやとか思ってるんですけど、
意見とか「将来こんな問題がおきるんじゃないか」募集。

177 ：

具体例。
/home/usr
my music/pop
c:/home/usr
c:subdir
全部おっけーで。
ドライブ指定なしはVFSを指定。（Unix方式）
ドライブ指定ありはWinと一緒。
カレントディレクトリはVFSにしか設定できない。（考え中）
VFSのディレクトリはひとつのドライブ付きディレクトリ（物理ディレクトリ）にマップされる。
ひとつの物理ディレクトリは一つ以上の複数のVFSディレクトリにマップされる。（考え中）
どうだろう。。。

178 ：

>>176
ふつうにファイル名に使う文字
とは？
' 'も入る？'\'や'/'や':'も入るべきだと思う人もいるかも知れない。
nfs的なもののパス名は？Winだと、\\computername\sharename\foo みたい
なもの、Unix系だと、hostname:/foo みたいなもの。

179 ：

空白はないと困るかな。\/:とかはバグの原因になるのでなしで。
んで、そっか、ネットワークパスもあるんだ・・・
share@host:/music/song.mp3
ってどうだろう。
\\host\share\music\song.mp3
と同じ意味。
そういえばWinには内部パスもあるはずだけど、あれはよくわかんないな。詳しい人いたら解説プリーズ。

180 ：

>>179
新しい記法を導入するのは混乱するんじゃない？
1. Windowsのファイル名規則に従う（ただし「/」もパス区切りに使える）
2. UNIXのファイル名規則に従う
のどっちかにしてほしい。

181 ：

メモリの解放に確保の100倍の時間がかかってたのでそこを修正しようとして泥沼でした。疲れた。。。
まあ起動が速くなったからよしとしよう。
>>180
ふむふむ。たしかに互換というか、慣れにあわせておくのも大切ですよね。

もうちょい考えます。

182 ：

やっぱ .NET だったら
Windows に合わせておくのが無難かな
とか勝手に思ったりしてみた。

183 ：

>>179
Winでの内部パスとは？
カーネルモードのオブジェクトマネージャの名前空間でのパスのことかな？
例えば、Win32サブシステムでのファイル名'c:\boot.ini'は、オブジェクト
マネージャでの'\??\C:\boot.ini'に対応するけど…。
ちなみにWin32サブシステムでのファイル名規則は
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base/naming_a_file.asp
辺りに書いてあるようだね。

184 ：

>>182
ですね〜。でもなんでもかんでも同じにすると面白みがないｗ
>>183
まさにそれです。さんくす。
ちょいと読んでみます。

185 ：

URL (RFC1738および各種拡張)にする、とか。

186 ：

>>185
省略を許さないとURLって面倒だし、許すとUnixと一緒ですね。うーむ。

FileStreamとちょこっと統合できた予感。つかれた・・・。
詳細はあした。

187 ：

さっきゅんがPonytailの実力を認めた。
http://pc5.2ch.net/test/read.cgi/os/1097514774/809-811

188 ：

>>187
そんなことはどうでもいいんだよ。

189 ：

昨日、「あした」とかいいつつ、今日は学校で書類書きしてました。
とりあえずパスは適当でnew FileStream("fd0a;/kernel.img")とかで読めるようになったんだけど、
つぎはぎだらけでいまいちなのでリリースは見送ってます。
あと、登校途中でｷｭﾋﾟｰﾝと天啓が下りまして、改名することになると思います。
とりあえずドメインとろうっと〜

190 ：

学校でOS開発を布教しようと思うので、一週間くらいテキスト書きに集中するかもしれません。
ちょっと進捗がなくなりますけど、みなさま気長に待っててください。

191 ：

改名しました。
Ponytail 改め、CooS　（クース）とします。
Ponytailと変わらぬおつきあいをCooSでもよろしくお願いいたします。
ホムペは http://www.coos.jp/ です。（コンテンツは増えていません。）
世の中就職戦線は賑わっていたのですね。
遅ればせながら就活でちょっと忙しくなってます。

192 ：

すで終わるOSはなんとかっていう話題が昔あったような・・
unix, linux, minix, mac osx, windows, msdos, beos ...

193 ：

>>192
ぬるぽ
そんな話題は正直どうでも良い。
物が全て。

194 ：

とりあえずそのリストを見るとスで終わるOSは普及しそうな気がする。。。
いまは数日考えてJITコンパイラにぼちぼち手を出さないとダメっぽいので、そんなことしてます。

195 ：

http://pc5.2ch.net/test/read.cgi/os/1029813876/

196 ：

長音が入ってるのでうまく姓名判断できませぬ・・・残念

197 ：

EM64Tだとセグメントで保護できないんですね。
スタックオーバーフローをセグメントで保護する予定だったので、
64ビット移植の時は面倒だろうなあ。ま、対応予定はないんですが。

198 ：

ロングモードはページング必須だからNX保護でええやん

199 ：

NX保護は実行禁止なので、ちょっと意味合いが違います。
ページング必須なのはそのとおりみたいなので、
スタックの下方数キロでも書き込み禁止とかにして対応するのが無難かな〜。

200 ：

200get〜。
ホムペ ( http://www.coos.jp/ ) に、型システムの階層図をまた掲載しました。
これでほぼ完成だと思います。興味がある人はご覧ください。
いまはJITコンパイルの前段階で、各命令が実行される直前のスタックの状態がどうなっているかを調べる処理を書いています。

201 ：

957はどこの会社受けるんだ

202 ：

ソフト開発系を受けてます。
僕の中では、OS開発＞その他の開発っぽいので、
開発じゃなくてマネジメントやろうかなと。

203 ：

未踏やってるって書けばどこでもフリーパスだろ

204 ：

2chやってるって言ったらどこも入れないだろ

205 ：

未踏ソフトウェアに採択されたことを言えば、技術力に関してはなにも言ってこないだろう品。
よほど人間性に問題があるようでなければフリーパスじゃね。

206 ：

エントリーシートには書く場所がないという罠。
でも未踏の知名度を過信しない方がよい感じです。
未踏という単語は知っててもべつにすごいとは感じないとか、
ソフトウェア開発分野には興味がないので知らないとか・・・。
>>204
そういう事態が頭に浮かばなかったのは我ながら痛いかもｗ

207 ：

MSMVP > 未踏のスーパークリエータ
というのが世間一般の評価らしいでつ。

208 ：

>>207
マジカヨ。M$に媚売ってマンセーしているだけのMSMVPが上なのかorz

209 ：

MSMVPは成果物を基準としないので未踏と比較はできないと思いますが、なにせ未踏はピンキリですからねえ。。。

210 ：

>>209
MSMVPもピンキリだと思うヨ。
.NET系を取り扱っているところだとそれでも役に立つだろうけどなぁ。
卒業後は、ひげぽんのように仕事も両立させながらプライベートでOS開発って感じ？
それとも、川合さんのようにOS開発優先？

211 ：

OS開発を優先させる、、、ってのは魅力的なんですが…。
なにせ終わりがない開発になりそうなので無理だろうなあ。
それに仕事就かないと見えないこともあると思うので、いまんとこはひげぽんさんモデルを目指してます。

212 ：

>>211
まあOSの開発だけで食っていくのは無謀なので、
ちゃんと仕事見付けた方がよいでしょうな。
未踏の期間中に別なスポンサーを見付けられればいいんだけどねえ。

213 ：

近況報告〜。マシンが起動しなくなってしばらくPCから逃避してました。いまは水冷を新調して復帰。
MonaがUSBメモリからの起動でちょっと議論してますが、実は僕も休み中に試そうとして、んで挫折してたりします。
というのも、道のりが長すぎるのですよ。
まず、USBコントローラがPnPを扱わないと発見できないっぽい。
まあ情報取得だけなら簡単だと思うけどPCIを触ったことはないので油断できない。
んでさらに、肝心のUSBプロトコルが結構複雑です。
単に信号送ってデータ送りつければいいという話ではないので仕方ないんだろうけどさ。
実時間ベース（1ms/125us）での通信とかあったりするので、
とりあえずスレッド周りがきちんと整備されていないと手が出ません。
そんなわけで4月に発表があるし、USBはしばらく見なかったことにしました。
発表までにJITが動くようになるといいなあ。

214 ：

>>213
あっちでUSBメモリ起動に関するレスを投稿した者の一人ですが自分はお遊び目的に気軽にCDメディアを消費せずに友人・その他に紹介できるのではないかと言う事で投稿しました
しかしMonaの方はもともと小サイズを目指すというかそういう方向（今は違うみたいですが）だからあれですが、CoosはJITやJavaなどを取り込むらしい事を見るとあまり小サイズ化とかそういう方面では無い様な気もします
またUSBメモリ起動等という物は「現在では」あまり実用性のない物かと思われますし、未踏に関わっているのであればあまり注目するような技術でも無い様な気がします
ところでCoosのサイトにはOSの開発コンセプトの様な物が見つかる所に無かったのですが簡単な物でもそういう情報も載せてみるとパソコン初心者の方にもとっつきやすいのではないかと思います
ということで期待あげ

215 ：

>>214
起動だけを見ると確かに需要ないんだけど、単にメディアとしてものすごく需要があったりするｗ
CDより大容量、書き込み可能、持ち運び可能、端子だけならどのPCにもある。
サイトは確かにコンセプトなかった…。いま書いております。

216 ：

>>213
タイミングとかはコントローラーのお仕事なので、
CPUは用があるときにコマンドを送って返事を待てばいい。
どっちかてーとその上のレイヤが面倒だと思う。

217 ：

>>216
ほぅ〜。言われてみればそれが自然ですね。
プロトコル解説書を読んだだけなのでチップが何してくれるのかいまいち謎でした。

218 ：

http://www.coos.jp/homepage.aspx
一般人がとっつきやすくなった上げ

219 ：

通りすがりの物ですがCoosっていう名前の由来はなんでつか？

220 ：

白々しい自作自演おつかれ

221 ：

>>218
サイトを作るのが下手な人なので、こーしたほうがいいとかあったら是非教えてくださいな。
>>219
co-os です。
co- 【接頭】 共同｛きょうどう｝の、共通｛きょうつう｝の、相互｛そうご｝の
>>220
すくなくともこのスレでは必ずコテ付きで書き込んでます〜。

222 ：

>>221
レスありがとうございます
co-osなんですね
Javaに引っ掛けてということですか

223 ：

とくにJavaは頭になかったんだけど、なんか似たようなものでもあるの？？

224 ：

ちょとJITコンパイルしてみたのでメモ。f(x)=\sigma_{n=1}^x n の計算。
まずインタープリタ。
x= 0, y= 0, time= 200966
x= 0, y= 0, time= 32487
x= 10, y= 55, time= 113892
x= 100, y= 5050, time= 1509719
x= 1000, y= 500500, time= 88652059
つぎJITコンパイル。
x= 0, y= 0, time= 1027514
x= 0, y= 0, time= 479740
x= 10, y= 55, time= 469064
x= 100, y= 5050, time= 474037
x= 1000, y= 500500, time= 589739
やっぱり速いねー…。

225 ：

・・・インタプリタのが速くなってない？

226 ：

>>224
最適化オプション無しで良いからC言語との比較キボンヌ。

227 ：

>>225
インタープリタから機械語への切り替えにかかるコストが相当あるみたいです。

228 ：

>>226
あんまり変わらないと思うのでC++でしてみました。
最適化なし　（cl オプションなし）
x= 0, y= 0, time= 314
x= 0, y= 0, time= 451
x= 10, y= 55, time= 773
x= 100, y= 5050, time= 2805
x= 1000, y= 500500, time= 81762
最強最適化。（/Ox）
x= 0, y= 0, time= 102
x= 0, y= 0, time= 102
x= 10, y= 55, time= 93
x= 100, y= 5050, time= 110
x= 1000, y= 500500, time= 102
C#の同じコードをWindowsで実行。（最適化）
x= 0, y= 0, time= 688
x= 0, y= 0, time= 289
x= 10, y= 55, time= 255858
x= 100, y= 5050, time= 2839
x= 1000, y= 500500, time= 23103
to be continued.

229 ：

最強最適化の威力がすごすぎます。
たぶんインライン展開を数段おこなってるんだとおもう。
これは別格ですね。
C#とC++（最適化なし）ではC#のほうが速いですね。
一般的な実験では、C++の方が僅差で速いという結果になることが多いので、まあこんなもんかと思います。
今回のコードは最適化による効果が出すぎですね。。。
やっぱりさらに高速化するにはレジスタフル活用にしないとダメですなぁ。

230 ：

各CPUに最適化したリリースをそれぞれするというのはだめですか（爆死

231 ：

それはそれで面白そうだがｗ
「同一バイナリから異なるアーキテクチャにリリースしてます」って。
とりあえず最適化に手を出すとてんてこ舞いになるのは明らかなので見送りかな。
当面はJITの作り込みと、JIT動作に必要になるシステムコールを整備しないと。

232 ：

こういうのってベンチマークとって公開してもいいんだっけ？

233 ：

ベンチの禁止の条項はサーバ関係のソフトウェアに限られていた気がします。たぶん。

234 ：

ちょっと興味があるので横槍
OSをサーバとして使用した場合OSはソフトウェアには含まれない
ということでベンチOK
という理論でいいですか？

235 ：

ベンチをとったのはOSそのものではなくて、Win上でも動作する単なるアプリですので、以下略ｗ
せっかくなのでちゃんと調べました。要約すると、
・我々はMSの許可なしに、本サーバソフトウェアまたは本クライアントソフトウェアのベンチ結果を公表できない。
・本サーバソフトウェアとは、我々のサーバ上でサービスまたは機能を提供するサーバーソフトウェアを指す。
・本クライアントソフトウェアとは、本サーバソフトウェアのサービスまたは機能を呼び出しそれを利用することのできる電子デバイス用のクライアントソフトウェアを指す。
・本サーバソフトウェアと本クライアントソフトウェアはServer製品の本コンポーネントの一部として含まれる。
・本コンポーネントとは本ソフトウェアを構成するここのプログラム、ドキュメント、情報などである。
・本ソフトウェアとはVS.NETとかを指す。
ベンチ禁止の条項はServer製品のプログラムについてのみ関係するので、自作プログラムについては大丈夫っぽい。

236 ：

VMware 5 で起動すると激重くなるという事実を発見しました。
4 系だと平気だったので内部動作が変更されたんだと思う。
Mona でも試してみたら、起動時は異常に重いものの、途中から軽くなる。
予想としてはページングモード用に最適化されたんじゃないかと思うけど、
これでしばらくVMwareは切り捨てざるを得なくなったなぁ。速かったのに、残念。

237 ：

>>236
4を使い続けるんじゃ駄目なんですか

238 ：

そろそろ、GCは実装できた？

239 ：

Game Cube エミュ？

240 ：

>>237
５があるのに４を使うってなんか損している気になってしまう性分なので・・・。
でも4使うしかなさげ。
>>238
GC (Garbege Collector or Collection) まだです〜。
いまはインタープリタでGCしても仕方ないという結論になってますので、JITが先です。

241 ：

あ、そういえば 0.0.23.0 公開してます。あいかわらず何もできませんが。
インタープリタとJITコンパイラの違いを試験できるので興味がある方はどうぞ。

242 ：

日記。
就職活動が大変です。
スタックマシンの命令体系からレジスタマシンの命令体系への変換はスクリプト書いて半自動化した方がいいのかどうか悩んでます。
知っている限りの草の根OSではやっていないことができました。
＃それともなにか実現しない理由があるのだろうか。
でもGUIがないと意味ないので公表はしはらく先…orz
OSASKスレより、OSASKに中間言語による実行計画があるようですね。
たぶん、khaba? のやろうとしていることは、CooSと同じものだと思います。
どうなるか興味津々です。

243 ：

知っている限りの草の根OS、はちと言い過ぎかも。
すごいOSたくさんあるし、それらはもう実装してますからね。
公表できないことを話すのは良くなかったかなと反省。

244 ：

簡素でいいんでGUI搭載してほしい

245 ：

GUIを搭載することは非常に前向きなのですが、いつとは言えないのが辛いところです。

246 ：

先日中間発表してきました。そのとき使ったパワポを公開したので、未踏とか興味のある人はどうぞ。
人より一ヶ月遅く就活してるみたいです。早く終われー。
以下日記。
キックオフでも同じだったんだけど、プレゼンで時間オーバーってマジやめてほしい。
特に時間すぎてるのに予定通りにプレゼンを進行するって姿勢が意味不明でした。
内容にはいろいろ思いましたが、「出来ないことをやる」のが未踏であると思うと、最終的には何も言えなくなってしまいますね。

247 ：

乙。
なぜか就活が項目に入っているのがﾜﾗﾀ
普通の人が出来ないことを、貴方のような天才的な能力を持った人が実現するのが未踏だと思うヨ。
貴方が考えるHogeHoge手法を自信を持って言ってくださいな。

248 ：

>>247
ありがとう。
天才的ってのは僕には当てはまらない感じですが・・・。(^_^;
未踏に応募する人は技術的な話は面白いので、そーいった意味で有意義でした。

249 ：

>>248
それが未踏の最大のメリットという話もあります。
貴重な人脈なので有効利用しませう。

250 ：

やっぱりやってたか、という印象。
An operating system written in C#:
http://research.microsoft.com/os/singularity/

251 ：

窓の中の人ですら、まだこのあたりなら結構CooS頑張ってるんじゃね。

252 ：

Singularityはインストール時にコンパイルするみたいだから面白みが無い

253 ：

ひげぽんみたいにblogとかで開発日記とか書いたら面白そ

254 ：

就活終わったんでもうちょいしたら本格復帰したい…
TA×２、ゼミ×２ってのをなんとかしたいなあ。
>>253
開発日記はJITコンパイラができたら考える。
それまでは、初めてもネタ枯渇が激しそうだ。

255 ：

作業日報でも書いとけばいいんでは。
後からまとめる時に便利だぞ。
まあ毎日ちゃんと書いとけばそんな事しなくてもいいんだが。

256 ：

>>255
IPAへ提出する作業日報は1行形式なんでどうにでもなるじゃん。
成果報告書も(未踏の場合には)時系列の内容は問われないし。
でもまあ面が割れてるキャップでこれだけスレッドが続くなら、
blogに移行しても客はつくだろうって気はする。

257 ：

>>256
いや、催促されてから一ヶ月分まとめて書いてたので、
最初の方なんてきれいさっぱり忘れてるんですよ。
適当に書くとさすがに辻褄あわなくなるし。

258 ：

MSに就職して.NET OS作ってください

259 ：

設計書もレポジトリに入れて毎日コミットすると良い

260 ：

>>225,256
いまはVis.Src.Safeのコミットログ見て作業内容思い出して書いてます。
ブログは・・・まあもうちょい考える。
最初は面白そうだけど、そのうち面倒になりそうｗ
>>258
MSでやっちゃうと微妙かも・・・。
国内企業でそーゆーことやるなら参加したいなあ。
>>259
いまのところ設計書というものは存在してません（＾＾；

261 ：

アンカーミス。。。
×225
○>>255

262 ：

ガーベジコレクタ は実装完了？

263 ：

まだまだJITですよ・・・・orz
６月は頑張ってるので徐々にできてきてますけど。
正直未踏期間中にガベコレあやしいかも・・・。

264 ：

終わりが８末だっけ？そうなると成果報告会が８頭あたりか。
まだ一ヶ月以上あるじゃねーか。

265 ：

そういや成果発表会って期間中なんだ…。やべー。
ガベコレだけで一ヶ月以上かかるだろうし。
JITを頑張って偽GUIでも作った方がいいかな。

266 ：

JITの道は果てしなく遠い・・・。
まだまだ命令残ってます。ふぅ。
サイトのスクリーンショットを更新しました。
文字を描画した例ですが、ビットマップ貼り付けではなくてフォントレンダリングをしています。
次はJITの結果。前回と計算内容は同じ（nまでの総和）ですが、
f(x) -> if(x=0) 0 else g(x-1)
g(x) -> if(x=0) 0 else f(x-1)
としています。
非JIT：
x= 0, y= 0, time= 279539
x= 1, y= 1, time= 89514
x= 0, y= 0, time= 34952
x= 1, y= 1, time= 45110
x= 10, y= 55, time= 206745
x= 100, y= 5050, time= 1521466
x= 1000, y= 500500, time= 86041420
x=10000, y= 50005000, time= 8337842474
JIT付き：
x= 0, y= 0, time= 235569
x= 1, y= 1, time= 534712092
x= 0, y= 0, time= 44753
x= 1, y= 1, time= 46827
x= 10, y= 55, time= 74791
x= 100, y= 5050, time= 51128
x= 1000, y= 500500, time= 182096
x=10000, y= 50005000, time= 1134869
桁が３つくらい落ちますね。

267 ：

単純な数値計算能力も大事だが、
仮想関数呼び出しやインターフェイス関数呼び出しはどうなの？

268 ：

そいつらはいまのところシステムコールにしちゃってるので遅いっす。
＃システムコールまではまだコンパイルできないし。。。
原理的には、仮想関数呼び出しは４重間接アドレッシング呼び出しの機械語に展開できるはず。
インターフェイス関数の呼び出しは・・・システムコール挟まないと無理かも。
両方ともC++のvtable方式にすれば速くなるけど、CLI的には普通ではないので、やるとしてもずっと後かな。

269 ：

>>266
> 文字を描画した例ですが、ビットマップ貼り付けではなくてフォントレンダリングをしています。
FreeType2とありますが、まさか.NETでリライトしたんですか！？

270 ：

>>268
解説ﾄﾝｸｽ

271 ：

>>269
よくぞ聞いてくれました！ｗ
それが Managed C++ でコンパイルしただけなんです。
＃標準関数のたぐいは自力で用意して。
FreeTypeが標準関数にも依存しないようになっているので助かりました。

272 ：

>>270
C++では、インスタンスが仮想関数テーブル(vtable)の中に関数ポインタをすべて持っています。
これはインスタンスへのポインタがあれば仮想関数を使える一方、
同じ型のインスタンスが全く同じvtableを持っている=メモリが無駄と言えます。
もうひとつ、重要な特徴として、C++ではインスタンスのポインタが移動します。つまり、
class T : IX, IY
としたクラスについて、
T t;
IX* px = &t;
IY* py = &t;
の px と py は原則異なります。（メンバとか無いと同じかも。）
つづく

273 ：

.NETでは、インスタンスは型情報だけを持っていて、型情報に仮想関数テーブル(vtable)があります。
また、NETの場合は、C++のようにポインタが移動したりはしません。
移動してしまうと型情報の追跡が困難になるからです。
このとき、仮想関数は親クラスからの"多重継承のない"増加なので、
ある仮想関数のvtable内でのインデックスは一意に決めることが出来ます。
なぜなら、あるクラスで最初の仮想関数のインデックスは、（親の仮想関数の数）＋１だからです。
これより、ある仮想関数のインデックスは、JITコンパイル時に決定可能です。
一意なインデックスで参照できるのであれば、多重間接参照でなんとかなりそうです。
しかし、インターフェイスの場合にはこのようにはいきません。
あるインターフェイス関数の位置は、それを実装するクラスによって異なるからです。
つまり、次の二つのクラス
class A : IX
class B : IY, IX
は両方ともIXを実装していますが、BのIXはより後方に位置しています。
この位置の違いは、
IX x = new A()　または　IX x = new B()
の x からJITコンパイル時に確定することは出来ません。
つまり、C++では、ポインタがインターフェイスのvtableへと移動することで仮想関数のvtable内インデックスを固定することが出来ましたが、
.NETではインターフェイスのvtableの位置が確定できないために、特別な処理を必要とします。
どうでしょ？

274 ：

>>272-273
解説ﾄﾝｸｽ は267の返答ありがとうってことだったんだけど、
268の意味までご丁寧に説明してもらってありがとね。
折れには、大して説明できる能力ないので参考になるかもしれないリンクを。
知っていたらスマソ。
Java JIT について
ttp://logic.is.tsukuba.ac.jp/~kam/ppl_ss04/ishizaki.pdf
ttp://www.research.ibm.com/trl/people/ishizaki/papers/phd_thesis_ishizaki.pdf
Direct Threaded Codeについて(命令ディスパッチの高速化)
ttp://www.complang.tuwien.ac.at/forth/threading/

275 ：

>>274
ぁ、勘違いでしたか…orz
まあメモ代わりということで（苦笑
リンク先はとても役に立ちそう・・・なのは大分先かもしれませんが、面白かったです。
最適化は茨の道らしいというのはよく分かったｗ　さんくす〜。

276 ：

ttp://mitou.mysite.ddo.jp/modules/eguide/event.php?eid=20
渋谷か…行けるかなあ。

277 ：

本人にも連絡来てないのに ��(ﾟ□ﾟ
でもまだ１９日か２０日か決まってないみたいですね。早く決めてほしい。

278 ：

>>277
最近のPoneytailOS開発状況は如何でしょうか？
お暇なときに、何か書き込んでいただけると嬉しいです。

279 ：

主に発表会のための開発になってしまっているので、なんかこう付け焼き刃的なのが遺憾なんですよね。
たとえばJITとかもせっかく作ったんだけど、発表会で動かすまでには至らなかったりで、インタープリタを地道にリファインしてたり。
あとはテキストだけだとインパクトがないので起動時からグラフィカルにして、ビットマップを軽く画面に出したりとか。
マウスとかを使えた方がいいかなと思ってドライバ書いたり。
残り時間が少ないので、その中でやれることをするとなると厳しいなあというのが正直なところです。
そろそろパワーポイントと併せて開発した方がプレゼン的にいいかなあ。
＃つーかマジ夏休みなさそ・・・。

280 ：

試験があるから勉強するというのもあながち悪いことではないから、
時には追いまくられるのも必要だな。
ガンガレ。超ガンガレ。

281 ：

お忙しい中、書き込みどうも有難うございます。
在学中に、大人数の前で成果を発表する機会に恵まれることは、滅多に無いです。
全力で頑張って、世の中に貴方を知らしめてください。

282 ：

>>280
そうですね。
がんばります。
>>281
こちらこそ書き込んでいただいてお礼を言わないと。反応があるのは励みになります。
そんなに大層な人間でもないので、できる／できたことを精一杯伝えるしかないと思ってます。

283 ：

就職しないで廃人になるまでこのOS作りこんでほしい

284 ：

C# ATAPIドライバが実機で動かなくてorzです。熱帯夜のせいで作業効率がいまいちなこのごろ。
発表が19日の16:50〜17:30になりました。
一般公開されているし、会場が200人らしいのでたぶんひろびろしてそうです。
期待するほどのものではないと思いますが、お暇ならぜひ見に来てください。＞みなさま
僕の趣味として、ぐたぐた語らずに質疑応答をなるべく増やした方がいいと思っているのですが、
これまでの感じだとそもそも質問が来ないのでどうしようかと思ってます。
（質疑応答の件に限らず）なんか発表について思うところがあれば書き込んでいただけると参考にします。

285 ：

見に行けない漏れが言うのも何なのだが、
競合する研究(Singularityとか)との簡単な比較がほしいなぁと思う。

286 ：

Singularityのビデオがんばって観ました。
（たぶん３割くらいしか正確に分かってないので、漏れがあるのはご了承を。）
内容としてはCooSについて僕が言ってたことと変わりません。
フラットなメモリ空間やページテーブル、プロセス間通信、
例外による安全なエラー処理とか、まあそんなこと。
＃５０分あるので、全部書くのは辛いです。
観てて思ったんですが、僕は技術について話すより先に、そーゆーOSが必要とされると思うわけをもっと述べるべきなのかも。
上のビデオでは技術的な話よりも、Singularityの意義みたいなものの話が多かったです。
MS-Rのビデオを観るような人向けの説明でさえそうなんだから、未踏みたいな発表では記述について話すよりもそっちのが重要かもしれない。
うーん。

287 ：

このプロジェクトが必要とされる背景とどのようなことが実現できるか？
ってのは確かに大事だな。
CLIでカーネルを記述することで、
カーネルコードの無効なメモリアクセス、型安全な実行が可能となる。
また、CLRがハードウェア資源を直接管理することで、
従来では不可能だった機能をアプリに提供することができる。
これを踏まえて、従来のC(or C++)によるOS開発の問題点を挙げ、
この仕組みでは、どのように解決できるのか？
そして、アプリケーション開発にどのような影響を与えるか？
etc
CooS開発という実体験を元に、
これらの話題を話すことができればよいのじゃないかと思う。

288 ：

遅レスだけど、>>283について。OSの成功には社会性も必要なんじゃないかな。
廃人はなんつーか３枚差しグラボというか5GHzPen4っていうか。
んで発表について迷い中。なにを中心に据えるか。
>>287さんも、CLI-OSについて理解していただけているようで嬉しい。
期せずも、前半は技術、後半は社会的側面について述べておられる。
未踏の発表は技術中心のものが多い。（じゃなけりゃ変に社会寄り。）
でもCLI-OSの技術は発明ではなくて単純化による洗練だから、新規性がない。
それぞれの技術についてはウェブがあるし、CooSとしてもサイトがあるから、発表会で技術に時間を割くべきなのか・・・。
それに僕はたぶんCooSというプログラムよりも、そこから得た（Singularityの中の人も言ってるような）社会的効果の方が重要であると思っているみたい。
いま社会的側面からパワポ作り始めてみたけど、ちょっと電波かもなあ。

289 ：

宣伝も兼ねてageてみよう。
CooS 0.3 をリリースしました。for 未踏発表会用。
http://www.coos.jp/homepage.aspx
ついに画面がグラフィックモードになったりしてます。感想とかお待ちしてます。
QEMUでの実行は遅いので、VMwareでのテストが推奨です。まあQEMUでも動くけどね。
発表会では技術解説より動機説明が主になりそうなのでソフトは公開しても問題ないと判断しました。
＃CooS/SingularityみたいなOSの本当な意味？みたいな話になる予定。
＃でも上手く話せるか自信ないなあ・・・。

290 ：

明日か。がんばれよ！！

291 ：

>>290　さんきゅ！
会の最中、感想とか書き込んでたらやばいかな・・・。

292 ：

明日仕事の打ち合わせが午前中に片付くなら渋谷に逝きたいなぁ・・・

293 ：

スクリーンショットくらい用意してくれ

294 ：

発表後でいいでしょ。いそがしそうだから

295 ：

＃♯＃♯＃♯＃♯＃♯＃♯＃♯＃♯＃♯＃

296 ：

>>292 ぜひ〜。まあそこまでして聞く価値があるかは保証しかねるわけなんですがorz
>>292-295
PMにメールしても返事がないので、明日聞く「報告書の分量目安」次第なんですが、
〆切が２５日と言われたのでそれまでは死亡確定かもしれませんねー。ﾊﾊﾊ
つーわけでドキュメントのたぐいはもうちょいお待ちを。

297 ：

>>291
漏れはやったことがあるぞ。
発表直前までプレゼン資料作るなんてこともやってたが。

298 ：

そろそろ準備しないとなー。
>>297
会場でネットに接続できないっぽい。。。
携帯は面倒だし、パケット通信は怖いしな・・・

299 ：

ｴｯﾁﾞ

300 ：

定額ケータイ

301 ：

先方に適当なこと言って来週に延期したから楽勝でRた。v(^-^)
957さん良かったですよ。
日本でManaged C++が混ざったILをちゃんと解析した人って
他に聞いたことないです。
それだけでも十分未踏だなって思いました。
質疑応答でカッコ良かったのは、
「遅いならFreeTypeをやめてビットマップフォント使えば？」
という質問に
「機能を犠牲にして速度を稼ぐのは本質的な改善とは言えない。」
のようなことを回答されていたときですね。
とっさにこういった冷静な対応ができるというのは凄いです。
ビジネスの世界でもバリバリ渡り合える逸材ではないでしょうか！

302 ：

パワーポイントうｐまだ？

303 ：

>>301
大勢の人の前で、自分の意見を明確に主張できることは、
本当に素晴らしいことだと思う。
ただ、常に速度より機能を取ればよいというものではないハズ。
ところで、「Managed C++が混ざったIL」って、普通の？ILより難しいの？

304 ：

>>303
速度と機能に関しては一概に決め付けられないのは事実ですが、
今現在OSに求められる性能を基準に言えば、
遅すぎてTrueTypeが使い物にならないようなOSは
他の用途にもまともに使えるとは思えません。
純粋なILに関しては規格書がECMAに提出され公開されていますが、
ネイティブコード混合の規格は公開されていなかったはずですから、
自力で解析する必要があるでしょう。

305 ：

打ち上げパーティでもしてるのかな

306 ：

>>305
懇親会があるって書いてあるね。

307 ：

そういえば質疑応答で一点気になったのは、
「色々な言語をサポートするランタイムはどうするの？」
という質問に対して
「.NETではすべて同一のILにコンパイルされるので無問題」
と答えておられましたが、
J#が専用のJDK1.1互換ライブラリに依存してるようなケースを
想定した質問ではなかったかと感じました。

308 ：

大丈夫です。J#なんて使ってる奴まずいないから。

309 ：

>>304
Managedではない従来のC++は、x86ネイティブコードにコンパイルされるが、
Managed C++って、すべてMSILにコンパイルされる気が．．．
CooSを動かしてないからわからんのだけど、今のCooSでは、
TrueTypeは使い物になっているのかな？
>>308
激しく同意

310 ：

懇親会＋二次会でした。ちょっと酔い
明日は１０時なので書けるとこまで書いて寝ます。寝るときは寝ると言います。

311 ：

おつかれーぃ

312 ：

ひとりスレからｷﾀっぽい方とお話ししました。来てくれた方がありがとうございます。
自分の感想は次のレスに。
>>299,300
会場圏外でした。au。渋谷で圏外ってどういうことよ・・・。
>>301
ありがとうございます。
来年からビジネスマンですが、学歴無いからなあ。
偉そうなこと言いましたが、僕の基本はやりたいようにやっているだけです。
>>302
後述しますが明日遅刻できなくなったので睡眠時間の復旧にご理解を。
>>303
速度は後述。
MC++の機械語についても後述。
MC++は結局ILにコンパイルされますので、C#以上でも以下でもありません。
>>304
速度は人的リソースと、プロダクトとしての活動のなさだと考えます。
確かに今は遅いですが、しかし高速化は実現できると分かっているわけで
あとはいつだれがそれをするのかという問題になります。
この解決としてオープンソースなどがありますが、そのような問題はソフトウェアの限界というものとは区別するべきだと思います。
機械語についてはECMA規格の中に定義されております。
命令列を持たない代わりにRVA(要はファイルイメージの位置)を持つメソッドが宣言でき、
そのようなメソッドはRVAの位置に機械語を記述できます。

313 ：

つづき。
>>305-306
明日もありますが、懇親会でした。
>>307
それは、J#の専用互換ライブラリも、.NETライブラリであるということが重要です。
たとえばJavaにはjava.langというパッケージがありますが、
これはJ#ではjava.lang名前空間を持つアセンブリとして参照されます。
そして、そのアセンブリは、単純には同等の機能を持つSystem.*のアセンブリに処理を引き渡すだけです。
J#は、見かけの言語はJavaであっても、ライブラリからなにから.NETですので、CLIを超えたサポートは必要ありません。
＃ただし、実行時にJ#のライブラリは必要になります。
>>309
アルファベットに関してはいちおうキャッシュしてたりとか・・・・
まあ、今の時点で実用性に言及されると辛いものは確かです。

314 ：

まず自分の発表について。
のちのちパワポは公開しますが、私があの場で言いたかったことはCooSの紹介の前までがすべてでした。
自分でも言いたいことは言えたので、マジでCooSの紹介を前に終わった感がちょっとあったくらいｗ
そのせいか後半はすこしだらけたかもしれません。反省。
＃もともと時間が足りないと分かっていたので後半はアドリブだった。
しかし、予定通り３０分ジャストで終えたし、それなりの発表はできたと思っています。
未踏の成果としては、（どうせ分かるのでぶっちゃけますが）、スレッドとガベコレがないのが痛すぎ。
提案時に含めていたので、それがないことは非常に残念だと思うし、申し訳ない。
しかし僕の力量では、ドライバなど"実際のOSを作る"という開発をしながらそれらを組み込むことは無理でした・・・。
こーゆー苦労はOS開発特有だと思ったりします。
しかしまあ、一年前の今頃にプロテクトモードへの遷移を質問していたかと思うとねえ。ｼﾐｼﾞﾐ
発表は（世辞か分かりませんが）たぶん好評みたいでした。
すくなくとも二次会でお話しした方には思想という点まできちんと伝わっていたようで、まあいっかな、と。
次他の方の感想。

315 ：

共同体的P2P全文検索システムの開発
発言も聞き取れたし、内容も論理的な順序があり理解しやすかった。デモソフトもちゃんと動いていました。
たしか「このままこのクオリティなら俺ﾔﾊﾞｽ」とか思いました。
P2Pが掲げられていましたが、技術的には蛇足のような気がします。
つまり、P2Pでなくても動くし、いまのP2P以上のなにかがあるわけでもない。
Google Desktop Searchみたいなのと比較がなかったのも残念。
やさしい仕様記述による通信プログラム自動生成系の開発
形式的記述ってのは正しさはすでに証明済みなわけで、たしかにサンプルも正しいように見えた。
でも（質問しましたが）、結局OSレイヤとの依存部分を排除できないと、プロトコルとしての状態管理以外に
OSレイヤの管理が入って、やっぱり複雑になってしまうのではないだろうか。
そういえばデモンストレーション無かったような気もする。（確信はない

316 ：

インテリジェントな3次元形状ブラウザの開発
キックオフの時から怪しいと思っていたプロジェクト。
未踏スレのほうで名前が挙がっていた五十嵐という方が関わっているようです。（基本論文に名前があった。）
この時点で結果に関係なく僕としては含むものがある訳なんですが。（だから毒モード
プレゼンも練習していないのが丸わかりで、聞いてて疲れた。
成果物もなんかいかにも学術研究という感じで、さっぱり。
＃冒頭例が車と家のポリゴンモデルで、実例が水素原子の反応じゃそう思うよ。
とにかく、他のプロジェクトとは根本的な姿勢が異なっていると感じました。
人間の記憶の拡張を目指した知識情報管理基盤の開発
PMが同じで結構話した方なんで心苦しいんですが、発表が機能リファレンスなのは眠く・・・。
そのため内容を良く覚えていないんです。。。（キックオフも中間発表も同様だった
結局何ができたんだろう。

317 ：

確率文脈自由文法に基づく遺伝子情報RNAデータベース検索システム
遺伝子ということで分野違いなんですが、ちゃんと話を聞くとよく分かって面白いです。
というか、難しい話を僕でも理解できるように話されていたので凄いと思います。
デモも分かりやすいように作り込まれていて、「こういうふうに見せたかったなあ」と思いました。
成果がどれくらい役に立つかってのは正直ピンと来ないんですが、でも価値がありそうだと思った。
ウェブデータベースサーバGWSの開発
この方は、発表で損してると思う。
作ったソフトウェアはちゃんとしてて、他のひとではひどいと言い訳しながら動かしたりするのに、
これは作り込まれて安定して動作しているように見えた。
それなのに見栄えに気を遣っていなかったり、単に機能紹介だけで半分以上終わってたり。
どうも申請時の案件はちゃんとこなしているようなのだから、もっと威張っていいのになあと感じた。

もうこんな時間。寝ます。また明日の報告をお待ちください〜。

318 ：

>>309
> Managedではない従来のC++は、x86ネイティブコードにコンパイルされるが、
> Managed C++って、すべてMSILにコンパイルされる気が．．．
>>312
> MC++は結局ILにコンパイルされますので、C#以上でも以下でもありません。
以下の例のNop()のようなもののことをネイティブコンパイルと言いました。
I/OなどはMC++で記述されているというお話でしたので、
そういうもののことを念頭にしていました。
void Nop() { __asm { nop } }
public __gc class Test { public: Test() { Nop(); } };
Nop()の部分はMC++ではない従来のC++だと言われればそうですが、
元は単にMC++を使ってネイティブとILを混ぜたバイナリのことを言おうとしただけです。
私が>>301で「Managed C++が混ざったIL」と書いたのが誤解を招いたようですみません。

319 ：

>>312
> 速度は人的リソースと、プロダクトとしての活動のなさだと考えます。
> 確かに今は遅いですが、しかし高速化は実現できると分かっているわけで
> あとはいつだれがそれをするのかという問題になります。
はい、それは理解しています。
FreeTypeの質疑応答を引用したのは反論とかそういうことではなくて、
似たようなことをよく言われて話が平行線のまま決裂しがちなので、
（後で根本的な対処をするまでの暫定を認めるかどうかの類）
印象に残ったという以上ではありません。
> 機械語についてはECMA規格の中に定義されております。
> 命令列を持たない代わりにRVA(要はファイルイメージの位置)を持つメソッドが宣言でき、
> そのようなメソッドはRVAの位置に機械語を記述できます。
はい、それも理解しています。
仕様書の以下のフラグが立っている場合、
RVAはネイティブイメージを指しているということですよね。
22.1.10 Flags for Methods [MethodImplAttributes]
Native 0x0001 Method impl is native

320 ：

私がMC++や仕様書がどうこうと書いたのは、お話の中で
「MC++を分析する上でundocumentedなこととかあって苦労した」
「そういうところはMonoでも突き詰めていない」
というような趣旨のことをおっしゃっておられたので、
そんなことまで調べた人は日本で他にいないから凄いなあ、
という類の感想を述べたに過ぎません。
それが具体的に何なのかは私には分かりません。
CMOD_OPT周りの何かかなと勝手に想像したので、
MC++とネイティブがどうこうと適当なことを書いたために
混乱を招いてしまったことをお詫びいたします。

321 ：

>>313
> それは、J#の専用互換ライブラリも、.NETライブラリであるということが重要です。
そのことは私は理解しています。
これは反論とかそういうことではなく、単に質疑応答を見ていて、
質問者は納得がいかないまま引き下がられたように感じたということです。
ランタイムについて懸念を示されたことに対して、
「独自にILを定義したらそれは既に.NETから逸脱しているが
そういう実装はないから大丈夫」
というような回答をされておられましたが、
それでも質問者は腑に落ちないような印象でしたので、
ひょっとしたらVB6互換ライブラリとかJ#のようなケースを引き合いに出せば
うまく伝わったんじゃないかなと思ったということです。
実際のところは私は質問者ではないので分かりません。

322 ：

>>312-317
乙彼

323 ：

これ、Virtual PCだと動かない？
みんなVMwareで動かしてる？

324 ：

帰還。今日は気がついたら遅刻でした。。。
>>323
VPCは最近チェックしてません。なんか挙動が変で消したんだよね。
そこらへんの調整は一段落したらするかも。
引き続き日記代わりの感想。今日はネタものが多いです。

325 ：

三次元GUIスタイルの提案とその開発環境の整備
最初１０分みてません。けどこの方は面白くて、今回も２０分くらいで発表が終わってました。
よく言われますが、”作業記録”は本質的には他人にとってどうでもいいことを知っておられるのでは。
NHK教育であるような惑星の3DCGでスケジュールを管理するソフト。
この手のは実用には適さないことが多いし、これもそうだと思う。「スタイルの提案」という言葉で逃げ？てた。
JavaOneでなんとか賞もらったらしいですが、派手さ、分かりやすさという点では比類がないと思いました。
デジタル万華鏡 -ビジュアルエンターテイメントソフトウエア-
アート系。僕は懐疑論者です。コンピュータのアートはソフトウェアだと思うし。
まず、アートというものに対して、いくつか見方がある。
結果がすべてという場合、あまりに弱い。なんだかアルゴリズムとかの説明が長くて、作品も作品ではなくレビュー？みたい。
アルゴリズムなどの過程も含めてアートというのは、僕には論理破綻に聞こえる。
これ系は合意形成は不可能なので、僕としても彼らが「この作品は凄く美しい！」といいきっていれば文句はないが、
なんだか「アートだから僕は許されるんだ」みたいな自己欺瞞を感じるのがどうも僕は気に入らなかった。
だれかアート系で発表を５秒でやらないかな。みてみたいのに。

326 ：

PUI(Paper User Interface)の開発
結構面白そうなアイディアで、たぶんちゃんと作って特許押さえたら莫大な利益になる。
発表も分かりやすかったけど、デモが全く動かなかった。
たとえたまたまだとしても、紙の持つ信頼性に代えようとするときにこの失敗は痛くて、以降の話がいまいち信憑性に欠けた。
ソフトウェアのアーキテクチャが書いてあったけど、どうも茨の道をわざわざ選んでいるように見えて、安定化は先のことのように見えた。
繰り返すけど、アイディア自体は実用的すぎるので、普及するといいと思う。
メール・Web・会議を垂直統合するグループウェア
ベストオブプレゼン。スピーチ時間３０分だし、時間を見ながら調整してそうなったのが○
パワポもきちんと組み立てられていて、分かりやすかった。
デモもきちんと動作していて、多数の人が使いたいと思っていたみたい。

327 ：

エージェントベース社会シミュレーション言語SOARSの開発
ワーストオブプロジェクト。これを採択したことに問題の原因があるという気もする。
ある言語処理系が遅いからハードウェアするってあらすじなんだけど、
インタープリタで遅いからハード化するって意味不明。
しかも元々に比べて何十倍も速くなってません、て、逐次実行から機械化したら死ぬほど速くならなきゃダメだろ。
そもそもマルチタスク/スレッドの理解が間違っているぽいし、設計したCPUのアーキテクチャもダメダメ。
なんかスレッドをn個作ると性能がn倍になるって言ってるとしか聞こえなかったんだけど。
Cellに似て演算器が並行動作するんだけど、同じ共有メモリにみんなでアクセスするって。ぇー。
時間もオーバーしてたし、質問はいろんな意味で諦めた。（これのが高額なのか・・・orz
オーバレイネットワークを用いたMMOGインフラストラクチャの開発
キックオフ、中間と変化がなかったので、たぶん変わってないだろうと思ってた。その通りだった。
2chのP2Pスレを発表するとあんな感じになると思います。
P2Pって理想郷で動かすことは誰でも出来るんですよね。
とにかく発表が下手で、すでに２回も同様の失敗をしたのに、なぜ直らないのか理解に苦しむ。
僕としては（学歴コンプレックスで！）、上の人たちは最低限僕より上手いと信じたいのだけれど。
中間でも質問をしていたし、質問によって合理的な解が聞けるとは思えなかったので、質問しなかった。

328 ：

計算機上での活動履歴を利用する記憶の拡張
これ面白い。使ってみたけど、うちのマシンが熱でふぅふぅ言うので夏の間は諦めた。
うーん、ちょっと話し下手かなーとも感じたけど、アイディアが面白くて話の筋も通っているので聞きやすかった。
ソフトウェアも公開されているし、そう言った面でもちゃんとしている。
技術的にはアレとコレの組み合わせ、なんだけど着眼点がとにかくいい。
今後に一般公開用の整備をするとおっしゃっていたので期待。
Winmostar：分子計算支援ソフトウェアの開発
普通。既存のアプリの完成度を高めたという話なので、新規性もないし、おもしろさもない。
分野も専門外な上に対象ユーザも専門家なので、それについてなにも意見も言えない。
まあその道の人には便利がられているというのは伝わってきたので、無駄ではないとは思う。
未踏かどうかってのはよく分からない。

329 ：

ここ二日間私物化してますがもう少しご容赦を。
・未踏のよかったところ
話し相手がいることです。僕の周りには残念ながらコンピュータという分野で対等に話せる人はいません。
.NETについて知っている人もいないし、CooSを説明しても分かってもらえません。（概念を相手の分野に射影すれば別だけど。）
知ってるままに話して理解してもらえるというのはいいことですね。
今の研究室に不満はないですが、専門の先生のありがたみも分かりました。
あとお金です。というか最初はこれが目的ですが。
お金はAdobeなんかに使って、イラレをパワポに使いました。
他の方の感想を聞くに、プレゼンは３本のストロークで変わると思います。
金額は、普通の研究費に比べて少ないという意見もありますが、
・研究計画が融通できる
・責任による不本意な矮小化がない
・成果物を完全な個人の所有に出来る
という点を考慮するにかなり優遇されたと感じます。（僕は一般の研究助成を知りませんが。）
でも強化点に投資するのは当たり前なので、それに見合う結果がでるといいなあと思います。

330 ：

・未踏の悪いと思うところ
考えるに、助成の枠組みとして最高ではないんだけど、じゃあ現実どうするかってことになると代案が思いつかない。
たとえば採択基準とかも明確でないわけだけど、明確にするとなると・・・
僕はアート系がいまいちと言ったけど、でもCooSだって似たようなものだ。
対外的な情報公開が少ないのは悪い点かな。開発者でIPAからリンク張ってたの２、３人。
誠実な人は苦労してそういう公開をするのに、逃げを打つ人は秘匿を理由に隠蔽する。
こういう「正直者が馬鹿を見る」システムは良くないと思う。
IPAの中の人は苦労しているみたいだった。でもそんなもん一般には知れないので公開情報がすべて。
プレスリリースから読み取れというのではなく、直接的に改善をアピールする必要がある。
それが上手くできないってのはやっぱりお役所だからなのかな。

331 ：

>>324-330
未踏に関しては、これで終了かな？お疲れ。
これからのCooSはどうするの？

332 ：

そう、それ。これからの展望は？

333 ：

昨日今日連投の最後。
未踏についてまとめようと思ったけど、よく整理できてないのでずっと後回し。
まだ報告書あるしなー・・・
昨日今日の僕の発言について聞きたいことはどうぞ訊いてください。
「この人いい人？」には答えませんが、「この手法はどうなの？」には覚えている範囲で答えます。
みなさんのおかげでﾏﾀｰﾘだし、たまに相談にも乗っていただいたりなんかして、感謝しております。
とりあえずスレのタイトルがCooSになるまでは頑張りたいｗ のでひきつづきよろしくです

334 ：

そういえばパワポ公開しました。
>>331-332
どうしよー。
懸案事項は
・コンパイル
・ガベージコレクタ
・スレッド（プロセス
かな。ひとつの指針として、アプリケーションを作れるようにしたいというのがあります。
ガベコレを後回しにしているのは、動作に支障がでていないという理由が大きい。
スレッドもいいんだけど、プロセスがないのは困るし、プロセスがあればスレッドも必要。
＃必要になるまで開発しない、というのは当初からの方針。
もうひとつは技術的な問題で、インタープリタでの実行がそろそろ限界。
速度という点でもそうだし、割り込みハンドラをインタープリタでやるのは無理がありすぎる。
どっちにしろ何日か書類書きなので、要望希望意見反論批判ダメ出しにダメ押しあったら書いてくれると（例によって）助かります。

335 ：

>>318-321
了解です。
質問者の方が理解していないことは分かっていましたが、
言語とライブラリと命令体系の概念をあの場で説明するのは無理かなと思って、わざとごり押ししました。
もし、概念を理解した方が確認のために質問をするとああいう感じにはならないかなーと。
Javaをネイティブに解釈実行しろって話かとも思ったんだけど、どうも文脈が繋がらなかったしなぁ。質疑応答は難しいですね。
もう寝ますー

336 ：

orz ﾜﾛｽ

337 ：

公開されたパワポを見た、Javaな人から一言。
> Javaは、機械語が合法的に実行できない
Javaは、一部のコードからしか、自由に機械語を実行できないと解釈すると、
CooSの方針と一致すると思うけどなぁ。
Javaであっても、細工をしたVMとライブラリを用意すれば、何でもできる。
> Javaは、既存資産を活用することが出来ない
安全性はともかく、JNI(Java Native Interface)を用いれば、
自由にネイティブコードを呼び出すことができる。
また、バイトコードに落とすことができる言語ならJavaでなくても実行できる。
正直、MSは宣伝が上手いねorz

338 ：

なら君がJavaでOS作れば？
宣伝とかの問題じゃないと思うけど。

339 ：

>>338
宣伝を鵜呑みにせず、物事をきちんと調べることは大切。
揚げ足をとろうという気持ちで書き込んだわけではないぞ。
もしろ、C#というJavaに一番思想が似ているものでOSを作成しているのだから、
親しみを持っている。

340 ：

>>337
ひとつの前提として、JavaOSが不可能なんではないんですよね。客観的には効率の差でしかない。
JNIもなんとなく知っていますし、Java以外のバイトコード言語があるのも知ってます。
でも.NETの機械語の扱いが「仕方ない場合は存在を許す」という姿勢なのに対し、
Javaのは「仕方ないから外に追い出す」というものだと考えています。
アーキテクチャの美しさとして、JavaはJavaではないものも用意する必要があるところが良くない。
もうひとつ複数言語性、これは「MSは宣伝が上手い」という言葉と関係している。
正直に言って、MSは成功の理由をシェアや宣伝にされているうちはほくそ笑んでいると思う。
MSの成功の裏でシェアや宣伝は大きなウエイトを占めていますが、それだけで上手くいくことはない。
実際Javaだって"Write once, run anywhere."という宣伝はある程度成功していたわけです。
.NETが複数言語だといっても、所詮MS謹製のC#,C++,VBくらいしかまともな選択肢はないわけで、実際にはそれほどは違いません。
しかし、そうした宣伝や根本的な思想のあり方というのは、ユーザも巻き込んで後に技術体系の方向を大きく決定づけることになる。
MSはこうした戦略がとても上手くて、技術とそれを使うユーザを、望む未来というやつに方向付けることができている。
＃それが真に理想的な手段かはともかく。
特に>>337さんがそうだというのではなく、*NIX陣営のようなMSと競う人たちは、横恋慕みたいな台詞は自制した方がいいと思うんだけどねえ。

341 ：

>>338, 340
MSは宣伝が上手いという言葉に腹を立てたのなら、
やや感情的な書き込みであったことを謝る。
.NET技術を知っているのなら、Java技術を知っていることになる
と考えているのなら337は忘れてくれ。
余計なお節介すまん。影からこっそり応援するよ。

342 ：

携帯なのでトリップ略。
僕は普段からそっけなく書く人なので、腹を立ててるなんて全くないです。
むしろああいった質問を発表会でがんがん期待してたくらいで、
ちゃんと理解しようとしていただけるのは作品冥利に尽きます。
僕はジャバは詳しくないわけで、JNIにも知らない拡張があるかもしれない。
そーゆーのは話さないと分からないわけで、発表会でもそうなんですが、
知らないから発言する権利もないっていうことはないと思う。
これからも質問があればしてくださいな〜。

343 ：

何かと議論があったほうが活発でいいよね

344 ：

こちらこそ感情的な書き込みをして申し訳ございませんでした。

345 ：

汗^2
こちらこそ、なんか喧嘩売っているみたいな書き込みですみませんでした。
JavaVMだけでなく、CLI、CLRの方も興味を持っていますので、
良かったら色々聞かせてください。

346 ：

レポート一式ようやく送信できた・・・先方の確認待ち。
長かった。。。さすがにちょっとのんびりしたいかも。
＃もう一通くらい期間外にあったような気もするが。
成果報告書って公開したいんだけどなー。

347 ：

>>346
公開用のを書けという指令がくるので、それを待ちませう。

348 ：

今後の開発予定についての公開ﾏﾀﾞｰ？
とか逝ってみる。

349 ：

たぶん未踏に口止めされたんだよ

350 ：

>>347　９月下旬ぽいですね〜
>>348
アセンブリのコンパイル方法を変えるために、解析ルーチンを分離してます。
いまはSystem.Assemblyから派生したクラスがあるのでWindowsで実行すると怒られちゃうので・・・。
詳しい開発予定ってサイトに載っけたほうがよいのかな？？　（未踏終わってﾏﾀｰﾘﾓｰﾄﾞになってた
>>349　ないないｗ
明日から合宿なので数日間留守にしまーす　ﾉｼ

351 ：

ttp://www.rubyist.net/~matz/20050912.html#p02
まつもと先生がお怒りです。

352 ：

なんだそいつは。2chも見てないのかよ

353 ：

>>351
普通、本人に事前了解くらい取るよねえ…。メールもなしかい。
確かに記者（だろうと言われた）人はいたみたいだけど、、、信じられん。
まつもとさんのお怒りは端から端までお門違いですね。つーか記事も間違っている。
>今後の開発継続には消極的な姿勢を示した。（記事）
今後の開発はどうやっていこうとは話したけど、止めますとは言ってないです。
止めるように聞こえてしまったのなら僕が悪いんだけど、そのために本人に確認取れよ…。
取材を受けたわけではないので、なんだか納得いかないです。
>ちゅーかだな、税金を注ぎ込んでおいてだな、「初期の目的は達成できた」といって放り投げ、
>オープンソースにもしないってのはどういう了見かと。彼の「初期の目的」がなんだか知らないが。
、、、むしろ釣り？
>もっとも私も未踏の成果を考えると偉そうには言えないが、少なくともオープンにはしている。
まつもとさんがオープンソース主義者だとは知りませんでした。。。

354 ：

さすがにこんな辺境の地はみてないだろう。
漏れは行かなかったので、どういう経緯でそういう話が出てきたのかわからんけど、
そこに書いてあることが事実なら怒りますな。
日本限定じゃなきゃ興味を持つ人が集まると思うけどねえ。
宴会でそういう話は聞けなかったんすか？

355 ：

>>353
そういうことですか…
憶測で物書かれるなんてことはよくあることですよ。よくあっちゃ困るんだが。
とりあえずmycomに抗議しておいた方がいいよ。

356 ：

間違った前提で議論が進んでますな。
ttp://www.rubyist.net/~matz/20050912.html#c02
誰か突っ込んだ方がよくないかい？

357 ：

ポジティブに考えようぜ？
Matzはな、せっかくの面白そうなプロジェクトが何も言わずに
闇へ消え去ろうとするのが悔しくて、ブチキレちゃったんだよ。
キレてついつい税金とかオープンソースとか言っちゃったんだよ。

358 ：

>>353
釣り餌を見抜けるとは、冷静だね。

359 ：

なにはともあれ、注目していただけるのは嬉しいことです。
反論というわけではないですが、一応コメント。
>みんなでいじる
CooSの場合、みんなでいじるとしてもそれはC#の部分にしたいので、
C#を動かすことを頑張っている現状ではあまり考えていません。
>放置には自由なライセンスを／ライセンスが強すぎ
放置するときに考えますが、放置するときにCooSがValuableであればオープンにするかもしれません。
現状のライセンスは強く僕の権利を留保する形になっていますが、当面は変える気もありません。
CooSをダウンロードして試してみるのに不都合がある、というのなら速攻変えますが、今は別に問題ないからです。
基本的に個人の趣味なので、みんなのために公開しろ、って論調はぴんときません。
CooSを公共の福祉に役立てることは本望ですが、CooSの開発を譲り渡すのには抵抗があります。
オープンにすればCooSコミュニティの中で"王様"になれるかもしれませんが、さっぱり興味がありません。
これは幼稚な動機かもしれませんが、OSの開発では重要だと思います。
長くモチベーションを維持することが最優先で、短期的利益と引き換えに飽きてしまうのが一番ダメじゃないかなあ。
それと税金投入だからオープンの話がありますが、ありゃナンセンスです。
申請の際にわざわざ「オープン条項」のないPMを選びましたし・・・。
お金を理由にオープン化させたいなら追加で払ってください。
１０年くらい生活できるだけもらって新たに作り直しますｗ
んで、MYCOMにメールしてみた。

360 ：

追加。放置の話は「いつか」であって、「あと何年」という意味はないので念のため。いまは放置する気ないよん。

361 ：

まつもとさんの意見は、放り投げるつもりであるという誤解に基づいているように読めますけど、違うかな。
誤解に基づく意見に何を反論しても、何ら生産的ではないような気がします。
「苦言たれる前に、ウラ取りはしようね」と優しく微笑みかければ十分じゃないですか?

362 ：

まつもとさんより偉い紙がゴロゴロいる微笑ましいスレはここですか？

363 ：

>>362
いいえここではありません。

364 ：

>>361
ちょっとひっぱり過ぎかもしれませんね。
件は誤解というのは了解していますが、
それにしてもオープン化の要求が理不尽だったのでコメントしておこうかな、、、と。
あとはライセンスについて意見を書いたことがなかったのでついでに。
まあこの話はとりあえずここまでにしますか〜。まったりが一番だね。

365 ：

別に開発が継続されていれば本人も誤解だったと気づくというだけの話。

366 ：

まつもとさんに文句言える偉い人がこのスレにはいっぱいいるようで（笑）

367 ：

スクリプターって偉かったんだ…

368 ：

>もちろん誰にも見向きもされない可能性はありますが、
>そうでない可能性をあらかじめ否定するのももったいない。
ソースを公開しても誰にも見向きもされない段階らしい。

369 ：

ソース公開しておいても、バイナリ落として使う人ばっかりで、
中身いじる人は天然記念物並みに貴重でつよ。
つーかソースだけ転がしておいて、使いたけりゃ自分でビルドしてねなんて書いておくと、
まず誰も使ってくれないからなあ…

370 ：

ソースの公開が見向きされるように今まで通り頑張りまつ。
＃というか一部は公開してんだけどな・・・。

371 ：

Matzはモルモンの宣教師として神を説いているよ（マジ

372 ：

>>370
ここでうだうだ苦言をたれるより、ITRON名無しさん氏が言われているように、
一度Matz氏へつっこみを入れてきたらどうだろうか？
お互いに一方的な発言を行っても、説得力にかけるように思う。

373 ：

いやいや、またーり、またーり。
Matzにっきに追記も入ったことだし。
ここへのリンクもコメントに張られたみたいだし。
これ以上責めてもメリットは無いと思うよ。

374 ：

>>372
激しく同感。でも>>373ということもあり自制してたというのがホントのところです。
さらに感情的に言えば、向こうに"召喚される"というのはとても納得できない。
実際のところ、追記の「〜という情報あり」という他人事みたいな表現に顕著なように、
まつもとさんの日記は日記以上ではないようなので、日記に正しさを求めるのは野暮かなーと。
MYCOMの記事は訂正されましたし、あとは放っておこうと思います。

375 ：

それが一番ですね。また〜り〜

376 ：

オープンソース原理主義者は滅びるべき

377 ：

公共の金が使われたのだから、
公共の役に立つ形で終わらせて欲しいというのは、割と普通の意識でしょう。
作者もそういう形で役立つことを望んでるみたいですし (>>359)
Matz は熱心な OpenSource 布教者で噛み付き癖があるから、
不正確な記事と感性の違いが起因して、あんなことを言ったのでしょう。
実用度が低い状態で投げるなら、利益を還元する一例として OSS 化は悪くないから。
つーのが顛末か。
正直、税金を使われた側としては、
> 申請の際にわざわざ「オープン条項」のないPMを選びましたし
というのは理解したが、還元されないなら、かなり馬鹿馬鹿しいな。
習得したスキルが、今後変わった形で公共に益することになったとしてもだ。
せめて、還元する努力くらい見せて欲しいといったところ。オープンソースに拘る必要なないから。
でなきゃ、個人のRー代に使われただけじゃん。

378 ：

そろそろまとまりそうですね。
>>377
はい、全面的に、特に
>還元されないなら、かなり馬鹿馬鹿しいな。
ということについても、完全に同意です。
しかし、このことは申請以前から分かっていたことです。
僕は簡潔明瞭なのが好きなので「個人の趣味」と言い切っていますが、
美辞麗句を用いたところで、立ち上げから1年のOSが社会に還元できるようになるわけがない。
それを誤魔化すために安易に「普及のために今後も努力」なんて言い切る方が無責任だと僕は思うのです。
これは採択審査のときにも明確に説明しています。
このスレッドの初期にも同様の議論があり、
そんときは「まあ面白いからやるだけやれば？」という感じの結論だったかな。
ただ、「実用にならないのが当たり前」ということを免罪符にするのは心苦しいので、
当初からサイトを（まあ元税金から）取得・運営し、インターネットでの情報公開に努めていました。
特にこのような完全に開かれ場で、開発者自身が明確に返答しているのは珍しいと思います。
そしてこれが、私が思いついた、社会への現時点で可能な還元の方法です。
続きます。

379 ：

うーん、続けられなかった。
未踏スレでCooS叩かれてますね。ちとかなしぃ。
HyperEst*の方は（すでに述べていますが）僕も凄いと思ったので、自然な流れだと思います。
で、よく分からないし、問題だと思うのは、その他大勢の雲隠れプロジェクトがまったく批判されないことです。
僕は未踏に対してかなり正直に接したと思うのですが、その結果が批判の矢面に立たされることで、
雲隠れした方にはなんの批判も、コメントすら取り上げられない。これはまつもとさんの件でも明らかです。
＃CooSに対する批判が嫌だ、むかつく、という意味ではないことをぜひ理解してください。
これでは、ゲームの理論を持ち出すまでもなく、
メディアに取り上げる価値もないくらいに適当にお茶を濁してさっさととんずらするのが一番利口です。
この問題は往々にして各プロジェクトへの文句になりがちですが、
各々の開発者が悪いとするよりも、未踏のシステムが抱える問題として議論するべきです。
そして僕は、各プロジェクトは"強制的"に、"不特定多数"の批判を受けられるような窓口を用意するべきだと思います。
＃んでCooSでは批判"も"受けるためにココがある。
最後に。
たしかに未踏はシステム的にまだ弱いと思いますが、
一番の問題はIPAがそれを是正する力がいまいちないような・・・。
IPAって未踏への批判とかってどうやって認識してるんですかね。
いじょう。

380 ：

開発者さん、
きっと、オープンソース推進派からの理不尽な要求とかいぱーい来るだろうけど、
絶対に貴重な成果をオープンソースにしてはいけないよ。
応援してます。頑張れ。

381 ：

déjà vu
NWSOS公開当時を見ているようだ・・・

382 ：

>>379
>で、よく分からないし、問題だと思うのは、その他大勢の雲隠れプロジェクトがまったく批判されないことです。
は、全く批判されないというよりも、全体に対して批判的なのでそう見えているだけなのではないでしょうか。
また、適当にお茶を濁してとんずらするのが一番利口というのははたしてそうでしょうか？
民間企業でもいくら資金をつぎ込んでも成果の上がらないプロジェクトを抱えており、そういうプロジェクトは腐るほどあるというのはみなさん知っていると思います。
それに、数百万という資金の上、1年程度の期間では成果を上げるのは難しいのも知っていると思います。
そういう立場を理解した上で未踏に批判的なのは、プロジェクトが暗い部屋の中で生まれて外に出ずにそのまま死んでゆくという絵が見えるからではないでしょうか。
闇から闇へ、そういうい行動をとっている人に次の機会があるとは思えません。
未踏につぎ込んだ資金を回収してほしい、そう望んでいる人は少数派であり、多くの人が未踏に期待している事は「優秀な人材を発掘してほしい」「新しいアイデアを見せてほしい」等、明るい未来を夢見させて欲しい、そういうものだと私は思っています。
成果物の直接的な社会への還元は最初から期待していません。
そもそも「未踏」というテーマに挑んでいるのですから、失敗したとしても次に繋がる種を感じさせてくれるなら批判も少ないでしょう。
現状の批判は、未踏事業のプロジェクト全体があまりに不透明すぎ、内容に対して批判もできない事へだと思います。
税金が投入されているのですから、情報公開で社会に還元して成功の手助けや失敗の防止に役立てる。そういうのはあってもいいのではないでしょうか。
趣味だろうが事業だろうが、無駄に税金が使われるというのは避けて頂きたいです。
批判を受け入れる窓口をIPXが用意して全体を整えていくという意見は私も賛成です。
ですが、それが始まるのを待つのではなく、まずは各々が行動に出て欲しいです。学校ではないのですから。
外部とコミュニケーションをとっておられる957さんに対して的外れな意見が多いですが以上です。長文失礼しました。
CooSには期待しています。では。

383 ：

オープンソースにするのはいつでもできるが、
一度オープンになったものは再びクローズにはできない。
オープンソースにすると、ソフトウェアの資産価値はゼロ以下に下がり、
それはもはや資産ではなく負債になる。
私も応援しています。
957さん、せっかく作り上げた貴重な知的財産をオープンソースにしないでね。

384 ：

>>379
> たしかに未踏はシステム的にまだ弱いと思いますが、
それでも初年度頃に比べれば細かいところではずいぶん詰めが進んだと
思います。あの頃は完全に手探りでした。
実質の開発期間もとんでもなく短かったですし。

>>382
> 闇から闇へ、そういうい行動をとっている人に
まあビジネスの世界ではそうですけれどね。アカデミックの場合は割と雲隠れが許されます。
学生さんの場合は、就職でリセット効きますしね。(957氏のことじゃないですよ念のため)

> 未踏につぎ込んだ資金を回収してほしい、そう望んでいる人は少数派
今年からIPAは「事業化情報交換会」という採択事業のビジネスサポートを始めています。
OSS事業の採択者にもお誘いが来るのですが、未踏採択者にも来ます。
ビジネスまでの距離が遠いからこその未踏事業だと思うのですが…。
この辺りは当のIPA自身も苦悩しているのでは。
>>383
> オープンソースにすると、ソフトウェアの資産価値はゼロ以下
んなこたぁないです。

385 ：

>> オープンソースにすると、ソフトウェアの資産価値はゼロ以下
>んなこたぁないです。
いいえ、OSSは間違いなく負債です。
OSSといえども知財であることは間違いありませんが、それを持っていてもお金は入りません。
逆に、著作者であるというだけで無理やりサポートさせられます。
外人からは意味不明かつ失礼な要求メールが次々と送られてきます。
日本人からの要求を無視すると２ｃｈで叩かれ、評判の悪い噂を流されます。
みんなで開発を手伝っていいものを作ろう・・・など妄想もいいところです。
OSSでは、完全に放棄でもしないかぎり強制労働させられてしまいます。
これを負債といわずに何と言えばいいでしょう。
クローズにしておけばユーザからの失礼な要求が来たときにも安全に断ることができます。
少なくともマイナスにはなりません。

386 ：

>>385
> いいえ、OSSは間違いなく負債です。
"間違いなく"なんて言っちゃったりして怖ぃなぁもぅ。
またーり、またーり。
負債になるか資産になるかを決めるのは商材ではなく商才、なんてナ。

387 ：

コテハンうざい

388 ：

>>385
クローズドソースでもオープンソースでも変な要求を無視すればいいことになんら変わりは無い

389 ：

ライセンスの話は宗教も絡んでキリがないっつーか、
どこまでいっても観客全員の賛同は得られないもんなんで、ほどほどにやっとけばいい。
中身で頑張っとくれ。

390 ：

税金の分だけ社会に還元しろって意味じゃない？
利益が出る形にして、還元するのはなかなか大変。
そういう意味じゃ、一番簡単なのはオープンソースだよね？

391 ：

OSとして必要な機能のうち
実装済み
未実装
なものを大まかに教えて欲しいんだけど。

392 ：

>>390
要するにソース見てパクりたいだけだろ

393 ：

>>390
「還元」の種類による。
文科省系の事業ならまだしも、未踏は経産省系だから
直接的には事業化の際の税収、間接的には日本の技術者育成と産業振興が目的。
決してオープンソース支援ではない。
もちろんオープンにするのは決して悪い選択じゃないが、
放置して海外で利用されるだけだと国益としては×。
(もちろん開発を継続するのが一番なんだが)

394 ：

議論があるのはいいことですね。期間終わってからこうなるとは思ってなかったですが（笑
>>382
未踏は責任と評価の方式が違うから独特の価値観が求められると思うのですが、
開発者の大半は学会と同じようなノリで行っていますし、それを認める雰囲気があります。
それは>>384さんがちょこっと触れている（学術は雲隠れして良い）に繋がる気もします。
>>384
ビジネス化要求は、未踏の知名度を上げたいかららしいです。有名にならないと未踏に予算が付かないって。
だから短期間で有名になりそうなら、ちょっと面白くなくても取るらしいけど。。。
飲み会で「OSなんてメディアには取り上げられないでしょ？」って言われました。
未踏システムは発展途上なんですよね。でもうーん、、なんというか手の打ち方がお役所的のような。。。
来年あたり「未踏プロジェクト評価基盤の開発」で申請しようかしら（笑）　つか誰かすればいいのにね。
>>384-392 except 391
誰かが、"責任を持って"、CooSをオープンソースとして開発してくれるならいいけどねー。
現状のオープンソースはノーリターンの責任と義務がもれなく付いてきそう。
さらに書けば、公開したら公開したで、「公開してるんなら責任持ってメンテしろ」なんて。。。
ああ面倒ですね。
まーCooSは生誕一周年なわけです。
僕は去年はOSど素人だったわけで、CLIも去年から勉強した。
「OSS化すれば漏れが実用にする！」などという方は、自分で作っちゃった方がいいと思います。

395 ：

>>391
実装して特徴的なもの。
・CLR、つまりランタイム
・C#で書かれたデバイスドライバ
欠けていて批判されそうなもの。
・ガベコレ
・スレッド
ちなみに成果発表会でちゃんと「できなかったよゴメン」って言ってまつ。
なんでやんなかったかったていうと、いずれもインタープリタでやるのがきついから。
未踏じゃなけりゃ手を付けていたけど、期間内で半端に手を付けてもなんにもなんないので止めた。
いまはインタープリタから脱却して、上を書けるようにする作業がメイン。
＃最近は放置した学校の仕事で一杯一杯ですが・・・。

396 ：

>>385
いかにも、オープンソースの経験が無い妄想野郎の発言
>>386
オープンソースで公開するのと、コードの変更権限は
別途に管理できますよ。
「公開してるんなら責任持ってメンテしろ」 なんてレベルの
メールはほとんどありません。 もし来てもドキュメントよ
く読んでねとか、軽く返答する程度
来るメールは非常にレベルが高く、貴重な パッチが大半で
本当に頭が下がる思いです。
957さんが、オープンソースにするのであれば Linuxの
開発モデルのよーに、CVSのコミット権やパッチ適用等の
ソース変更権限は本人のみで 管理するのが良いのではないでしょうか？
まだまだ基本設計やコードのリファクタリングを したい気持ちは判りますし、
クローズドも個人の プロジェクトとしては良い選択肢ではあります。
ただし、実装が一段落した将来には、オープン ソースの選択肢も良いものですよ
それと後公開するなら、絶対に英語を主体に。 日本人からの貢献は、
母数的にもほとんど ゼロに近いですから。
以上、ご参考まで

397 ：

>>392
そうぱくりたいんだよ。
ブート直後からC++みたいだし、
OSのベースにするには申し分ない。

398 ：

>>385
もう一言いっておけば
あんたはプログラミングの楽しさを知らない人種。
そんな輩がオープンソースを語るからおかしくなる。
プログラミングは自己表現の一つだよ。その延長線に
オープンソースがあるだけ
オープンソースから話を進めるのは、プログラミングの
楽しさを知らない証拠だよな

399 ：

困ります八○さんとか
山○とかは、その代表格だな

400 ：

500万を趣味に使いました。
------終了------

401 ：

>>396>>398はいかにもオープンソースの開発経験がない人がいいそうな理想論ですね。
OSSの使用経験はあるかもしれないけど、大規模なOSSの開発経験はないのでしょうね。
>「公開してるんなら責任持ってメンテしろ」 なんてレベルのメールはほとんどありません。
ほとんどない＝少ないけどある
>もし来てもドキュメントよく読んでねとか、軽く返答する程度
再びうざい質問が来る
>来るメールは非常にレベルが高く、貴重な パッチが大半で
そのユーザ独自の特殊な環境で動くようにしたパッチ(変なCPU構成とか、変なビデオカードに対応した版)が来る。
他の人には全く役に立たないのがほとんど。
>ただし、実装が一段落した将来には、オープンソースの選択肢も良いものですよ
完成版をパクられて終わり
>それと後公開するなら、絶対に英語を主体に。
日本人でも欧米人でもパクりたい人がいるのは同じ。
以上、ご参考まで

402 ：

オープソンースにしなくっていいというのは、
プログラムを販売したい人とか幅広く優秀な人を集めたいからだろ。
完成もしないんじゃ話にならない。

403 ：

他のもあまりぱっとしないし、これくらいでいいんじゃない？
MSが似たようなの作ってるみたいだし、
MSのが完成したときに、あれと同じやつ先に作ったんだと自慢できるよ。

404 ：

初カキコ。
いいんじゃないの？coosの方向性はあれで。
ぶっちゃけオレはこのスレ始まった時から個人開発で有用性を証明するのは
大変なんじゃないかと懐疑的だった人だったが、
ＭＳよりも先にMSとは別の形でC#などのManagedな環境を用いた開発の有用性を
証明できたんだからそれはそれで価値があるはず。
オープンソース化しないから価値がない、価値が小さいってのは大きな間違いだと思う。
こーいうことばっかり言ってる人が多いからオープンソース界隈を
嫌ってしまう人もたくさんいるんじゃないかな。
まぁ国民の税金使ってるんだから、プログラミングについて全く知らない人に対しても
分かりやすい形での還元ってのはして欲しいかな。
オープンソース化はそーいう意味ではわかりやすいと思う。
ま、海外にパクられれば微妙だけどさ。。。
CLIについての技術視点からとか、C#でのOS開発で感じたメリット/デメリットとか、
そーいうのを文書化して公開してもらえると面白かったりするので期待してまふ。

405 ：

>>404
フリーソフトウェア/GPL派の折れも同意見。

406 ：

あ。
オープンソース云々の話が出てたからそれについて書いただけで満足してしまった。
まずいまずい。
「他のプロジェクトが批判されないのはおかしい」ってのは957氏の立場からは
言わないほうがいいのでは。
批判の矢面に立たされてる以上、「他の人だって・・・」的な子供のような批判の矛先の変え方は、
仮にそーいう意図がない場合でも、とても印象が悪いよ。
未踏プロジェクトの評価システムがまだまだ甘くて、
それぞれのプロジェクトについて評価・言及がなされていないものが多い、くらいにしておくべき。
そーしておかないと更なる批判を呼び起こしちゃう気がしまふ。
>> 405
私はGPLだけは嫌いなんだよなぁ・・・。
BSDLかPDSでいいじゃん、と思ってる人。

407 ：

>>401
なんか、OSSで失敗した経験でもあるのか？
>再びうざい質問が来る
これはOSSは関係ないでしょ。むしろドキュメント未整備が主要因。
>そのユーザ独自の特殊な環境で動くようにしたパッチ(変なCPU構成とか、変なビデオカードに対応した版)が来る。
>他の人には全く役に立たないのがほとんど。
Coosの事は知らんが、これはソフトウェア基盤の問題でしょ。
そんな糞ソフトを公開しているから、そんなパッチがくるんだよ。
ドライバ仕様を明確にして公開していれば、プラグイン感覚で
マージして終わりでしょ。
>完成版をパクられて終わり
現状のCoosに、それほどのアドバンテージがあるの？
個人での開発なんて、たかが知れている
Coosだって、他のOSS等を参考にしている訳だし
自分だけクローズってのもなぁ。
むしろOSSで公開して、開発のスピードを上げるべきでは？

408 ：

OSSにすべきかどうかっていうのは、>>394でもう答えが半ば出てるような気がするんだけど。
OSS化を提案する>>407は、責任もって開発に参加する用意があるってことなのかな。

409 ：

消えろ空気固定

410 ：

>>407のようにOSSで公開しろと主張する奴に限って、コードを１行も書かないんだろうなあ。
自分でOSSのプロジェクトを立ち上げてみりゃ、OSSの理想が机上の空論だってことはすぐにわかる。
>むしろドキュメント未整備が主要因。
第一に、ドキュメントをきちんと書いても、まず読まれない。
嘘だと思うなら、407がやってみなよ
そもそもOSSのソフトウェアって、「タダで転がっているもの」というイメージが強いんだよね。
要するに、道端の石ころと同じなわけ。
面白そうだから拾ってみて、ちょっといじって、ざっとコードを眺めて、
すぐにポイされる。
せっかくの成果がゴミのように扱われるんだよ。
これじゃあ作者はうかばれない。
OSSならみんなが知恵を出し合って改良発展させてくれる、って407は本気で信じてるのかな？
>むしろOSSで公開して、開発のスピードを上げるべきでは？
なんで、OSSで公開すると開発のスピードがあがるの？激しく疑問。

411 ：

言いたいことは分かるがここでやるな

412 ：

Lと同類ってことでFA

413 ：

Lﾀﾝスレがなくなって名無しで乙

414 ：

ふーむ。
僕がまとめていいものやら困りますが、CooSについてはまとめますか。
んで、まとめますが、なかなかレス量が多いのでちょっとメモ書き。
賛成・推進
>>396-398 >>407
反対・留保
>>401-405 >>408 >>410
まーどっちにしろ、オープンソース自体の一般的な善悪を判断することは適切ではないですかね。
それと>>406さん
ご意見参考になります。
開発者が批判をしない

415 ：

現状はどうなのかなと思うので、僕は敢えて批判をしているのですが、
確かに立場としては慎重に行動するべきですね。気をつけたいと思います。
と書こうとしたら、間違って途中で書き込みしてしまいました。

416 ：

結論から述べると、CooSをオープンソースにするようなリスクは取れそうにもないなあと思ったり。
いちばん怖いのが>>407において失敗の原因が「ソフトウェアが未熟だ」と括られていることです。
僕には「オープンソースとして失敗しないように開発を続ければ、絶対にOSS化は成功する」と読める。
＃これは別に407さんの発言だけで判断しているのではなくて、
＃OSS賛美の裏にあるリスクがよく現れていると思って引用しただけです。
それともう一つは、現在このスレッドは「いつものPoneytailスレ」ではないことです。
普段からCooSを支えていただいた人に加え、未踏スレからも人が来ている（気がする）。
新しく人が増えていることは嬉しいですが、でも今の流れを定常状態としてはなかなか受け取れません。
もうちょっと落ち着いたら考えよう、ということです。
CooSへのOSS化の要望はいくらでも歓迎？しますが、もうちょいクールダウンしませう。
それと未踏スレが消えて続きをココでって感じですね。
別にいいんだけど、僕としてはどこからが一般論なのか判断しにくいです・・・。

417 ：

GPL希望

418 ：

>>417
論外

419 ：

とりあえずソース公開を特別視して身構えてることは分かった。
そんな相手を説得しても無駄なのはみんなK対Lで身に染みてるよね。

420 ：

評価すべきはソフトそのもの。
成果物で語れば良い。
良いものか否か。
ただそれだけ。
ソース公開かどうかなんて無問題。
ここは公開するソースを書いたことない椰子がいるんじゃないのか？
自分で書いてみればソース公開への躊躇の理由くらいわかるだろう。
見たこともない映画や、遊んだこともないゲームを批判する椰子と同じ。
自分の身をもって知ったものでないことに説得力はない。
当然だがソースを公開するかどうかなんて作者の自由。
公開による知名度等への貢献・儚いフィードバックへの期待と
知的財産価値の低下分を天秤にかけて、個々の価値観で決めれば良いこと。
漏れの場合、過去にソース公開したものへのフィードバックは、
アプリ側の要望ばかりだった。
少なくとも漏れのソースは公開した価値なかったな。

421 ：

誰も見ないようなソースは公開しても公開しなくても大差ない。
公開しなくても誰も欲しがらないし、公開しても誰も見ないからだ。
つまりソース公開・非公開の両面に言えることなので、
どちらか一方が正しいという類の結論には結び付かない。
だから結局、自分が作ったものを自分でどう思ってるか、
というだけの問題に行き着く。
ある意味、誰かに拾ってもらえればと子猫を橋の下に捨てるのに似ている。

422 ：

同意。どっちも正しいとおもう。
どうでも良いことかもしれんが、
日本人って日本語化以外にそれほど興味ないのか？
とおもうことが良くある。
コア部分の開発を助けないから、海外の人に
相手にされないことが多い。
日本人の漏れが見ていても魅力感じないだろうと
おもうのだから、まあ当然だろう。
せめて多言語化すれば良いのだろうが、なぜか日本語化をしたがる。
もちろん例外はあるし、OS板ではコア部分を書くのが好きな
例外的な人が多いが。

423 ：

>>421
漏れのソースは、この板の大半の人が
知っているような、あるソフトの一部として使われている。
ただそれは漏れのプラスにはならなかった。
残念ながら。

424 ：

>>423
他の人のプラスになればそれでいいってのが共産主義者。

425 ：

Win/Winなんて滅多にないよ。
Win/Loseすらあまりないし、これは感じ悪い。
大抵はLose/Lose。
だから次善の策がLose/Winなわけだ。

426 ：

>>424
だな。
まあ漏れは相当の時間を割く以上、何らかの
リターンを望んでいたのだろうな。

427 ：

>>424
共産主義者というのは言い過ぎ。
そこそこの出来だけど売るほどのものでもない、ってときに、
放置しておいても腐るだけだし需要がゼロではないみたいだから、
ということで消極的に所有権を取り下げるくらいではないかと。
Irvineなんかこれだよね。
後継者なしでソース公開自体に意味がないというのは後出しジャンケンなわけで。
もっともオプソ＝善だと妄信しているような輩もいるのだけど。

428 ：

ｵｰﾌﾟﾝｿｰｽうんぬんはこれで終了にしよう
話をﾘｾｯﾄして技術的なことを話そう
957氏はOSを開発しててどういうところに苦労しましたか？
具体例とかあるとありがたい
#こんな振りしかできなくて情けない

429 ：

GPL以外のソフトは糞だからGPLを採用するべきだと思う

430 ：

>>414
反対・留保っていうか、>>420と同様、作者の自由だと思っている。
個人的には商売ネタとしてのオープンソースに可能性を感じていて奨めたいところだけれど、そう思わない人がいてもおかしくないし、界隈全体のリスクヘッジを考えると自分と違う思想の人がいるほうが都合がよい。自分の直感が正しいとは限らないからね。
それはさておき、全実行コンテキストで単一のメモリ空間を共有するっていうのは、割と"従来のOS"でも散見されるような。…なんていうのはこの板には似合わない話題か。すんまそん。

431 ：

共有するだけでなく保護されないと駄目だよ。

432 ：

>>431
うん。メモリアクセスに対して保護無しならいくらでもあるね。MMUがなきゃそうするしかないし。
保護も行っている例で一応実用になっているものなら、JavaOSやμITRON PX仕様があるよね。
ほかにもあるような気がするけど、ちゃんと調べてないや。

433 ：

ここは空気嫁る人が多いインターネッツですね（笑
>>428
設計で失敗してるのは、OSを開発していながら、ついついOSの存在を仮定してしまうところですかねえ。
特にC#なんかで書いていると、下位レイヤは隠蔽されているという立場が自然なわけで、
僕の頭の容量からしても Console.Write と打ちながらインタープリタの挙動までは正確にイメージしきれない。
上位レイヤを作っている自分と下位レイヤ担当の自分が意思疎通に失敗すると結構痛いミスになりました。
>>430-432
保護する必要がない、ってのがポイントです。
JavaOSはどーなのかなあ。思想は一緒だし。
jNodeを久しぶりに見たら結構活発ですしね。
新規性のなさについては、ごもっともです。
ただ、uITRONのように制約による単純化なのか、
洗練による単純化なのかというところは、見た目は同じでも大きい気がします。
これは僕はもっと大きい規模でもそうだと思っていて、たとえば、現時点でCooSを分岐して開発したとする。（どっちもOSSにしたとする。）
そうしたら、元は同じなのに、数年したら違うモノになってて、その違いは思想とか文化によるんじゃないかと思う。
僕はこの傾向はすべてのソフトウェアの中でOSが一番顕著だと考えているので、だから見た目よりも動機とか目的に拘ってる気は自分でもします。
んで、もとにもどると、だからアーキテクチャがすでにあるからっていうのはピンと来ないんだけど、
学会とかだとそれだとダメなんだろうなあ。修論でもダメかなあとちょっと頭が痛いです。

434 ：

>ここは空気嫁る人が多いインターネッツですね（笑
後ろ向きことは、話したくないよね
ただ、オープンソースへの反応は過剰すぎない？
その根底にはソースを見られたくないことへの拒否感で
表向きには「サポート面倒」「パクリやだ」だけれでも
本当のところは「自分も大いにパクリました」「ソースが汚い」って
低レベルな話な気がする
当人は開発を続けるつもりだろうけど、本家マイクロソフトの
.NET Compact Frameworkに対しての優位性があるとも
思えないし、クローズにしても商用展開は難しいの一言でしょう
まぁ、当人も気がついているでしょうけど、趣味レベルが
望む望まないに関わらずの終着駅じゃないかなぁ

435 ：

>>434
おめーが過剰すぎ。

436 ：

句点の無い人の割にはまともなこと言ってるな

437 ：

それなら、本当にOSのコアな部分の開発を手伝ってくれそうな人や、
一部のアプリを書いてくれそうな人だけに限定して、
NDAの元でソースを見せる、というソースコード開示方式にしたらどう？

438 ：

MSのshared source方式だね。何から何までMSの(ry

439 ：

>>434
確かに厳しいね。二番煎じのレベル
にも達していないのでは？
既に各デバイスプラットフォームに
多数のパートナー(英語リンク)が
参入/商品化していて
　デバイス プラットフォーム
　http://www.microsoft.com/japan/windows/embedded/devices/default.asp
現状でもサポートされるデバイスドライバが
多数存在している状況のWindowsCE.NETには
勝ち目はないかも
デバイスドライバ
http://www.microsoft.com/japan/windows/embedded/ce.net/evaluation/hardware/drivers.asp
957さんは、どういう方向性で進める
つもりなの？

440 ：

> ただ、uITRONのように制約による単純化なのか、
よくわからない。解説きぼん。
> んで、もとにもどると、だからアーキテクチャがすでにあるからっていうのはピンと来ないんだけど、
> 学会とかだとそれだとダメなんだろうなあ。修論でもダメかなあとちょっと頭が痛いです。
新規性が無かったからといって何かを言うつもりはないんだけれどね。
アカデミックを意識している一方で先行研究との比較がが不十分なのは、
結構致命的かなと思うんだ。

441 ：

とりあえずOSSとCooSに関わる話は>>416で総括とします。
要点は「議論はいいけど現時点で判断するべきではない」です。
＃ついでに言えばOSS汎論はそろそろスレ違いっすね
>>437
たぶん余計に批判されそうな…。
まあ公開しようかなーと思ったらココに試案でも投げますので、
具体的な議論はそのときでいいと思うです。
>>439
勝ち負けの話であれば、客観的には「負け」を前提にしてかまいませんよ。
.NETの.NETのための.NETによるOSを作りたいです。
>>440
もし違ってたら指摘してください。uITRONは組み込みですよね？
ですからPCみたいに「ちょっと遅くなってもCPUに頑張ってもらえ」という姿勢ではない。
一方CLI/Javaのコード検証というのは結構たいへんな処理です。ついでにJITも。
これらを組み込みシステムで実現するのはなかなか厳しいと思いますが、
「実行時保護が不要」というためにはコード検証が不可欠です。
ですから、
PCの場合は、ソフトウェアによるコード検証が実装されたために要らなくなった保護機能で、
組み込みでは、アーキテクチャの複雑さを抑えるために機能を絞られた保護機能　だと思う。
これらは「保護がない」という点では同じですが、＋コード検証が可能か否かでだいぶ事情が異なると思います。
アカデミックについては了解です。学会出せそうなら注意します。

442 ：

>>441
議論上のつまらないテクニックだけど、安易にPCと組込みを対立軸にしないほうがいいかもしれないよ。最近組込み領域は広がる一方なので。古くはJavaOSの派生としてのJBlend、最近なら.NET Compact Frameworkなんて組込み向けだよね。
それに、最近のクリティカルソフトウェアの文脈では、適用分野をきつく規定するのって流行りではないみたい。
以上脱線。本題の保護に関する事情については、また後で。

443 ：

>>441 さて本題。ttp://www.coos.jp/introduction/architecture.aspx を参照しながら。
以前例示したとおり、JavaOSとμITRON PX仕様は全実行コンテキストが単一のアドレス空間を共有している。
「（そのようなOSが存在するかは知りませんが。）」とはもう書けないね。
　
この2つのうち、μITRON PX仕様のメモリ管理は、MMUのアクセスコントロールを利用したもので、CooSとは方針が異なる。
それは認めるんだけれど、この方針のどこに「必ず制約が出てきてしまう」のか説明がない。
説明しきれていないものを特徴に挙げるのは、ちょっとキツいんじゃないかな。
ITRONだから噛み付いているわけじゃないよ。
PX仕様と同じ方式を採用しているOSが、他にもあるような気がする。
IPCのコストを下げるために、とか、マイクロカーネル屋がやりそうな手口じゃない?
視点を変えてJavaOS方面から考えてみる。
CooSは、OSであると同時に特定言語を軸とした仮想計算機の側面もあると思う(違う?)。
CLIの場合は、一応言語独立なのだけれど、分類上は汎用OSというよりは、Smalltalk環境やLISPマシンの方向に近いのではないかと。
これらの仮想計算機の場合は、実行コンテキストごとにMMUで保護するほうが稀なんじゃないかと思うんだけど、どうだろう。
そんなこんなで特徴として挙げている項目は、特徴たりえていないのではないかという気がする。
むしろ「CooSの面白さ」で挙げた項目のほうが、特徴なんじゃないかな、とかとか。

444 ：

>>441
.NETの.NETのための.NETによるOSを作りたいですって
自分の趣味のための税金によるOSの勉強をしたいって
はっきり言ってもいいとおもうけどな
>>443
確かに、CooSの特徴って、単なる制限による仕様って
ぐらいにしか思えないね
>>434,>>439,>>443で、新規性も将来性もないような
書き方されているけど、モチベーションは維持でき
てますか？

445 ：

>>444
おっとっと、>>443では「Webページで書いてある特徴は特徴じゃないかも」とは書いたけれど、将来性が無いとは書いてないよ。明日の事なんて誰もわからない。
新規性は、どうだろ。メモリモデルに新規性はないかもとは書いたけれど、全体としては、まだ判断つかないかもね。
新規性自身が要るかどうかわからない。初期のLinuxなんて開発プロセス以外に何も新規性がなかったわけだし今だって古くさいと後ろ指さされているし。

446 ：

拝啓ちょっと大学の後期が始まりつつある関係でみょーに忙しく、まとまったレスはもうちょい先になりそうです。敬具

447 ：

気のせいかもしれないが、公式HPで公開されてるソースっていつの間にか少し増えてる？
C#もC++も全然わからないから、眺めてるだけなんだけど

448 ：

たまに手を入れたりしているので増えたりしてますよ〜。

449 ：

もう日曜か…orz
>>443,444
結局のところ、個々の技術的には、大した新規性は無いのは間違いないです。
仮想マシン、メモリモデル、中間言語、リフレクション、コード検証…。
OSアーキテクチャはどうしてもCPUに縛られますから、本質的な多様さはありませんし。
それをふまえて、CooSの特徴（というよりはCLIのすごさ）ってのは、それらを動作可能な形で実際にまとめ上げた、の一点に尽きると思います。
で、たぶんこれが本当のCooSの特徴なんですが、これって説明しにくいんですよね。
「どんなOS？」っていう問いに答えるには、思想的なものではなく、技術的なものがあった方が答えやすい。
だから書いてあるのがメモリモデルやらなんやら、というわけです。
>CLIの場合は、一応言語独立なのだけれど、分類上は汎用OSというよりは、Smalltalk環境やLISPマシンの方向に近いのではないかと。
SmalltalkやLISPマシンについてはあまりよく知らないのですが、近いといえば近いし、遠いと言えば遠い、、、かな。
SmalltalkマシンとかはSmalltalkありきですよね。CLIは普及した言語ありきだった。
Smalltalkは未来予想図としては良かったんだけど、"次の一歩"としてはCLIの方がいい。
だから、究極の環境としてはMMUは無くなって当たり前に見えるけれど、現実にはMMUが存在していて、
じゃあ現実にこれからMMUを無くすためにどうすればいいかってことになると、CLIとCooSってことにならないかな・・・。
＃思いつくまま書いてるので分かりにくいかもしれない
>新規性も将来性もないような書き方されているけど、モチベーションは維持できてますか？
最近忙しくて触ってないけど、たぶんそのうち「開発させろー」とか言い始めるので大丈夫ですよ〜。

450 ：

> 動作可能な形で実際にまとめ上げた
同意。だからこそ今の技術解説だと曲解されないかなという気が。
ちなみに、技術よりも思想の差異を示したほうが記事にしてもらいやすい。マスコミ対策の瑣末なテクニック。
あんまり思想に傾きすぎるのも、TRON界隈みたいな状態を呼びそうだけど…バランスバランス。
> CLIは普及した言語ありき
必ずしも同意できない。VB.NETなんて、もとのVBに対してかなり大きな変更を強いたし。
(CLIが強いた制約とは別に「このどさくさに紛れて」と言語設計者が考えたものも、あるいはあるかもしれないけれど)
まあそれぞれの言語に対して工数最小の移行パスを用意できた。そのバランス感覚は大したものだ、とは思う。

451 ：

> CLIは普及した言語ありき
これはどちらかと言うと、Windowsアプリがかけるっていうのが大きいんじゃないの？
VS見たいなIDEで、アプリを書く環境がある。

452 ：

単一アドレスのOSは研究レベルなら結構ある。
ttp://www.cs.washington.edu/homes/levy/opal/
ttp://www.cse.unsw.edu.au/~disy/Mungi/
など。
coosの特徴は「CLIのネイティブ実装」に尽きるような気がする。
なので将来のことはわからないけれど、今はCLIをもっと
前面に押し出すべきだと思う。

453 ：

> 単一アドレスのOSは研究レベルなら結構ある。
ざっと読んだけど、やっぱしIPC絡みなのね。誰でも一度は考えそうだよな。
相変わらず調べてないけど、Embeddedの切り口でもきっと研究例はあると思うんだよね。
メモリの仮想化しちゃうとヤワなデバッガでは対応できなくなるケースがあるから。
> 今はCLIをもっと
言語Cの環境区分に倣って、フリースタンディングCLI環境と呼んでみたりとか?
まあ確かにそういう訴求の仕方が正しいと思う。

454 ：

>452
>coosの特徴は「CLIのネイティブ実装」に尽きるような気がする
???? 意味分からん。CLI 実装はネイティブなんて必要条件でしょ
下記のページを参考に独自性を見つけるってはどう？
Microsoft シェアード ソース CLI 実装
http://www.microsoft.com/japan/msdn/net/sscli/mssharsourcecli.asp

455 ：

>>454
それ見ちゃうとNDAにひっかかるだろ。

456 ：

>454
ネイティブってのは下位のレイヤーを必要としないという意味にとってください。

457 ：

> Windowsアプリがかけるっていうのが
書けない。CLR相当まで拡張すれば話は別だけど。
IDEの大部分を流用できるというのは確かにメリットだね。
"大部分"と書いたのは、ウイザードがCLRにべったりのコードを吐く可能性があるから。

458 ：

そういえば去年も9月の中旬に未踏申請したあと非常に忙しかった気がする。。。
>>452
そうですね。実際には、CLIっていう現実解を選んだことが大きいと思います。
ただ、CLIを前面に押し出したとしても、普通の人はそれで何が起こるか分からないのではないかなあ。
んで、まずアーキテクチャ的な説明か、セキュリティみたいなエンドユーザ側からの説明が必要になって、
そのあとにようやくCLIを選んだことの意味っていうふうになるんじゃないかなぁ。
ま、とりあえず、サイトのドキュメントが未整備なのは良くありませんね。。。
>>457
CLI規格はCLRも含むので、一応ドットネット向けなら動かせるはずです。
絶対動かせないのはP/Invokeとかで明らかに依存してるやつ。
あとCLRがライブラリという意味なら、たしかにSystem.Windowsの移植はしてないので足りないですね。

459 ：

> 絶対動かせないのはP/Invokeとかで明らかに依存してるやつ。
VBから流れてきた人々は、Declare使うよね、ふつう。
.NET向けなら動くっていうのはわかるんだけど、Windowsアプリが
書けるっていうのは、ちょっと言いすぎじゃないかな。

460 ：

うーん、そもそも"Windows"アプリでは言葉の定義としてOS依存なわけですから、
エミュレーションをしないCooSでは動かないですね。

461 ：

Windowsとバイナリ互換

462 ：

なんか、理解はできないけどすごく読み応えのあるスレですね。
そんな中、こんなことを聞くのは気が引けるのですが、
このCooSは.NET FrameworkのVM（のような感じ？）として使えますか？現段階ではなくても
たとえばQemu上のCooSの中に.NET Frameworkでできたアプリケーションを動かしたいと思っています。
.NET Framework製アプリ専用のお砂場みたいな・・・

463 ：

たぶん今日あたりプレスリリースかな。
おかげさまで「スーパークリエータ」らしいです。
感想とかはリリースを待ってからで。
とりあえずもう晒されるのは勘弁してほしいなぁ。
>>461
さすがにムリぽｗ
>>462
それは可能だと思います。もちろんOS+.NETなのですぐに実現できるわけではないですが…。

464 ：

>>463
おめ。名前だけで特にメリットが無いのがあれだが。
暇なので展示を見に行くかのう。

465 ：

>>463
レスどうもです。
やはり.NETのアプリケーションを動かせる段階というのは
その他OSの基本的な機能が実装されてからになるのでしょうか？
.NET Frameworkのアプリを動かすだけなら
現時点ではqemuに別のWindowsOSを入れてそこに.NET Frameworkランタイムを入れて
.NET Framework製アプリケーションを動かしたほうが現実的でしょうか？

466 ：

> とりあえずもう晒されるのは勘弁してほしいなぁ。
引きこもるか、晒されるか、どちらかしか道は無い。
未踏採択者は定期的に近況報告を求められるので、
引きこもるほうが難しい。

467 ：

資料作ってない〜。ひー。
>>464
ありが�d。
スーパーも恥ずかしいし、クリ"エータ"も恥ずかしいです…。
展示は特にしない予定なんだけど、ダメ？
ここ一ヶ月は何も進んでないしなあ。忙しすぎ。
>>465
CooSでは.NETが基本レイヤなので、むしろ「基本的な機能」が.NET関係だと言えます。
実用的な解であれば、おっしゃるとおりWindowsか、強いていえばLinux+Monoだと思います。
>>466
また色々言われたらめんどーって思ってます。。。

つーかスーパー（ｒｙ）になっちゃったからもう未踏応募できない〜。かなしー。

468 ：

まだほとんど出来てないのに、スーパークリエータで応募出来ないのか。
どういう制度だよ。

469 ：

人材発掘が目的だとすればスーパーなひとの再採用は不要だと思いますが、
スーパークリエータのがノンスーパーよりも権利を制限されるってのはどう考えても謎ですね。

470 ：

スーパーになった奴は、希望すれば自動で継続とかにすればいいのに。

471 ：

未踏の後は次世代があります、って話じゃないの?
確か去年か一昨年、そういう例あったよね。
次世代で目処がつければマッOファンドとか。
って、釣られておいてなんですが、そろそろCooSの話に戻しませんか？

472 ：

話題ないし

473 ：

>>467
漏れは飯を食うのが主目的なのでどうでもいいんだけど、
未踏で成果発表できる所はIPAXくらいなので、出れるなら出た方がいいと思う。
>>471
それは法人格が厳しいですな。
未踏のアンケートにそう書いて送ったけど、どうにもならんしなあ。

474 ：

> それは法人格が厳しいですな。
んなもん印紙税数万円と2週間の時間がありゃできますがな。実質工数は数日だし。半年もすりゃ会社法も改正でさらに作りやすくなるし、むしろ最近の連中は恵まれていると思うぞ。
ま、会社に勤めているとしがらみ障壁がいろいろあって踏ん切りつかないっていうのなら、判らんでもないけどね。

475 ：

この段階で会社作って応募するなんて無理だろ

476 ：

悩んだんだけど、当日はプレゼンもブースも出さないことにしました。
現状で出しても仕方ないし、それならビジネスにできる人に譲った方が良いかなってのが主な理由。
んで、ひさしぶりに次にやることというか。
次はJIT系だと決めてるんだけど、ちょっと前からバグがバグバグ出てきて、このままだと破綻する予感〜と思っていました。
なのでまずはNUnitを導入して、それなりにテスト駆動に移行しながらやっていこうかなと思います。
時間的見通しは難しいけど、未踏で〆切がなくなったので、品質志向（理想志向？）に戻ってもいいかなーと。
今週来週くらいで再開したい。。。

477 ：

プレスリリースｷﾀｰ。
2004年度第２回未踏ソフトウェア創造事業　開発成果＆PMの評価：
http://www.ipa.go.jp/jinzai/esp/2004mito2/kaihatuseika.html

478 ：

突然ですが、ブートローダをCで書いてみました。
前々からアセンブラは分からん…と思っていたので。
したらサイズが増える増える。2nd loaderが3KB近越え。
やっぱりアセンブラでちまちま書いた方が小さいねえ。
まー見やすいのでこれで行くけど〜。
http://www.coos.jp/src/viewer.aspx?path=coos/bootloader/
ディスク上では bpb.asm + 1stboot.c + 3rdboot.asm + 2ndboot.c という感じで並ぶけど、
実行は bpb -> 1st -> 2nd -> 3rd です。

479 ：

>>478
Monaみたいに2ndをC#で書かないの？

480 ：

>>478
どういうコードが生成されるか意識して書けば、それなりに小さくできるよ。
いわゆる高級アセンブラな使いかた。
>>479
x86なコードに落とす手間を考えると、それほどメリットないべ。
ネタとしては面白いけど。

481 ：

授与式でした。レセプションには偉い人来すぎ。
「未踏打ち上げー」みたいなノリを想像してたのでびびりましたよ。
>>479
ぶっちゃけCのが自然だと思います。CooS的ネタにはなるかもしれないけどｗ
>>480
そーなのかなぁ。
確かにCになると富豪的スタイルになっている感は否めない。
それにくわえて、手を抜いた部分をコンパイラが仕上げている感じもある。
ま、CローダはOS勉強する人に役に立つかなあと言うのも目的です。
アセンブラが王道なんだろうけど、やっぱアルゴリズムは理解しにくいので。

482 ：

JITの応用でPreJIT(AOT)もできることを示す意味があるかと

483 ：

コード書きに夢中になってレセプション行きそびれたorz。
タダ飯食いながら957に粘着しようとおもっていたのだが。
C#やJavaでAOTという選択肢はスジが悪い(速度もメモリ効率も
あんまし上がらない)というのは、巷で割と良く言われていること
なのでわん。
そうじゃねーぞと言える何かがないと、頑張るだけの意味ないよね。
まあネタだっていうなら、それはそれでありか。

484 ：

ぶっちゃけOSをネタから引き上げるのが一番難しいから、
意味のあるなしで言えばOS作りほど筋が悪いことはないかと。

485 ：

誤解を招きそうなので補足。
Coosに水を差すつもりは毛頭ありません。
現実的な意味を取り沙汰するのに違和感を感じただけっす。
技術的探究心は大いに結構、それこそ未踏の精神では。

486 ：

>>481
未踏は少数派ですからな。漏れの時は2000-2003合同でそれなり関係者がいたが。
昨日はIPAのえらい人に捕まってあんまし食えんかった。しくしく…
>>484-485
漏れはブートローダーなんて枝葉な部分に労力を割くのは
もったいないと考えとるので、ネタ扱いした訳ですよ。
実験としてはまあおもろいけど、実用性が？だし。
という意味ではCで書くつーのは正しい道だと思いますよ。
ただサイズの問題があるので、そのへん考慮しないとねえということで。
しかし、ブートローダーを枝葉とか言ってるとそっち方面の人に怒られそうな
気がするな。

487 ：

>>486
ブートローダーに拘ってるわけじゃないですよ。
ブートローダーを何で書こうがOS自体の機能が増えるわけでなし。
>>480
＞x86なコードに落とす手間を考えると、それほどメリットないべ。
AOTの確立自体がメリットだと考えています。
原理的にはCooSに限らずx86汎用で使えるわけですし。
（ブートローダーをAOTで書いたら汎用という意味ではないので念のため）
AOTよりHotSpotみたいにJITを極めた方が有利というのは、
技術的な難しさと天秤に掛けると絵に描いた餅かと。

488 ：

>>484
> 意味のあるなしで言えば
現時点でのCooSをOSと呼ぶには、ちょっとした躊躇いが漏れはあるんだけど、どうよ。
現時点のCooSってOSっていうよりもプリミティブな言語マシンに見えるのな。
だからまあOS云々と反論されても？な気分。
せめてポリシーを持った実行コンテキストの管理はしてくれるくらいにならないとと
思う訳で、それを除けて枝葉に走るのはどんなもんかなー、とかとか。
以下 >>486 と同様。
> OS作りほど筋が悪いことはないかと。
はっはっは。そりゃまーそりゃそうだわな。
一応OSとか言われているものに関わっている自分が笑っちゃイカンか。
>>487
> AOTよりHotSpotみたいにJITを極めた方が有利というのは、
> 技術的な難しさと天秤に掛けると絵に描いた餅かと。
んー? Javaでは HotSpot世代までいかなくてもAOTとJITの差は瞭然だった記憶があるんだけど。
静的に決定しないものが結構あるからね、Javaの場合は。C#の場合は何か違うのかな。

489 ：

>>488
＞現時点のCooSってOSっていうよりもプリミティブな言語マシンに見えるのな。
＞だからまあOS云々と反論されても？な気分。
自分としてはMSIL処理系として見ていたので、
汎用的に利用価値があるとなると真っ先にAOTが思い浮かんだのです。
＞せめてポリシーを持った実行コンテキストの管理はしてくれるくらいにならないとと
＞思う訳で、それを除けて枝葉に走るのはどんなもんかなー、とかとか。
言語マシンとしてみればAOTは枝葉ですかね。
MSIL処理系としてみればAOTは本命だと思ったのですが。
＞んー? Javaでは HotSpot世代までいかなくてもAOTとJITの差は瞭然だった記憶があるんだけど。
＞静的に決定しないものが結構あるからね、Javaの場合は。C#の場合は何か違うのかな。
Java特有の動的さというのはC/C++に対しての型付けのことでしょうか？
クラスローダの実装が最適化されていないと起動が遅くなったりはするでしょうけど、
実行時の決定的な性能差として影響するというのは聞いたことがなかったです。
HotSpotが実行時に取得する情報というのはプロファイリングなので
型付けの動的さとは全然関係ないしJava特有でも何でもないですね。
何か資料がないと話が発散するだけなので適当に探してみました。
ttp://www.shudo.net/article/Fedora-Core-Expert-200507-GCJ/#performance
商用のAOTコンパイラは蚊帳の外であまり参考にならないかも。

490 ：

>>489
MINIX3ｷﾀね
次はいよいよ大本命HURD1か？

491 ：

誤爆ｽﾏｿ

492 ：

>>489
首藤さんの資料ね。
ちょっと古いけど、こっちのほうがCooSスレでは参考になるかも。
http://www.shudo.net/publications/NASDA-200212/ の
http://www.shudo.net/publications/NASDA-200212/slide15.png
http://www.shudo.net/publications/NASDA-200212/slide16.png
辺り。処理系の詳細は説明はないもののC#のデータが入ってるから。
このプレゼンのときに首藤さんも前置きしてましたけれど、
これLinPackだから、AOTが異様に善戦してますね。
聴講者の大多数がシミュレーション屋さんだったので、
これはこれで数値の取り方として悪くはないけど。
> クラスローダの実装が最適化されていないと起動が遅く
言語やVMの問題っていうよりは、プログラミングスタイルというか。
レイヤの分割で Class.forName() を良く使うので、どんなにコアを
AOTで最適化かけても、どうしてもどこかの層がインタプリタ動作に
なって律速orzという。クラスローダがオンデマンドコンパイルとか
考えれば考えるほど、JITのほうがいいじゃんという結論に向かって
いっちゃうという。泥臭い実運用上の話ですよ。
どこで聞いたのだっけかな? JTRON界隈か、JavaOS界隈か。
Googleに聞いてみたけど、5年以上前の話はさすがにもう残ってないみたい。
MSILではAOTが本命なのかぁ。

493 ：

>>492
えーとごめんなさい。性能論争は望んでいません。
興味があったのは、CooSのために開発された技術を応用して、
実際に使えるのは何かということだけですので。
MSIL関連のサードパーティー技術で、
自分から見て欲しいと思えるのはAOTだっていう話なので、
AOTが欲しい局面では性能が半分でもAOTが欲しいわけなんですよ。
たとえ実装が不完全で運用に制限があっても
ソースを直してでもAOTにしたい案件は多いので。
.NET Frameworkのインスコを客に拒否されたりしたら
今は泣く泣くMFCに戻るしかないって結構ありましたので。

494 ：

>>492
なんでC#こんなに遅いの？

495 ：

>>494
知らん。隣のオバサン的無責任さで想像すると、こんなことは言えるのかも
しれない。
まだJITがこなれていないってことなのかもしれない。
確かJavaからの移植だったはずなので、多次元配列ではなくてジャグ配列を使っているはず。このことでC#の実力を反映できていないのかもしれない。
CLR(CLIもか?)では配列型はCLRが動的に生成するという仕様だったはず。
その辺りに起因して配列操作の性能でCLRはJavaVMよりオーバヘッドが
あるのかもしれない。
今評価すると、また違った数値になるだろうね。もう3年も前の資料だから。

496 ：

497 ：

ぐは、驚愕の事実を確認。
どうやらVS.NETに「Windows以外禁止条項」はない。
つまりVCのライブラリが含まれていても問題ないってこと。
＃EULAのあの一文はなんなんだろう。。。
サポートに聞いたので間違いありません。
二カ所に聞いたけど、最初の人は「お客様のご自由にどうぞ」と言ってた。
次のサポートの人は、「禁止されてはいないが、
そもそもサポート外なので許諾されているとは言えない」らしい。
ということは、あとは実行ファイルに取り込まれているライブラリのコード断片がどう影響するかだけど、
「Windows用アプリを特別視して許諾する」という条項がないからWinアプリと同じだと見なせて、
MSがWinアプリにライブラリ断片を理由に成果物に制限を掛けることはできないだろう。
ということで、
作った基礎ルーチンが無駄に。。。orzorzorz
もっと早く聞いておけば良かった…。
これでVC++でも作りやすくなるね。

498 ：

よかったじゃん

499 ：

どうでもいいじゃん

500 ：

500

501 ：

ttp://channel9.msdn.com/Showpost.aspx?postid=141858

502 ：

>>501
うぉ。貼り付けさんくすです。
ちと研究活動で忙しいので、見たら感想でも書きますね。

503 ：

お久しぶりです。
あけましておめでとうございます。
最近はJITコンパイル周りをいろいろやってたんですが、面白くないのに道のりだけは長くて。。。
あとは論文書きと修論書きと、開発そのものはあんまり・・・です。
あとあと、ついでにVS.NET2005への移行を進めていたり。これも大変そうです。
まあ何かあればこちらに書き込もうとは思ってます。
このスレが無事（？）なのも皆様のおかげですし、本年もなにとぞよろしくお願いいたします。
２００６年元旦

504 ：

今年もよろしく！

505 ：

今年もがんばってください！

506 ：

age

507 ：

Ｋさんがなにやらよさげなものを書かれたときにアレですが、
修士論文がようやくできたので公開することにしました。
http://www.coos.jp/articles/thesis.pdf
まぁ絶対評価ではぜんぜん納得できていませんが、
状況とかを振り返れば結構書けた方かなと思います。
＃そもそもＯＳが完成してないのに論文を完成と思うわけがない。
ちと恥ずかしいですが、興味のある方は読んでみてください。

あと、２／１６に大阪の学会で発表をします。（トップからリンク有り。）
アカデミック縛りがあるのでＯＳ開発という視点では？かもしれませんが
こちらもついでに報告しておきます。ただ、学会員じゃないとお金掛かるので
C/Pについては言及を避けたいと思います（＾＾；

508 ：

ageとこ

509 ：

>>507
修論乙。
一応、うちの研究室もOS風味なので、
行く人がいればどんな話だったか聞いておきたい。

510 ：

論文ぽくない論文で面白いな

511 ：

>>509
（論文・修論で開発進まず、）あんまり変わってない上に
どうも学術主眼に話をするのは苦手なので、
あんまりクオリティ高くないかも…。
期待しないで来ていただければ嬉しいです。
>>510
各章の扉ページに無意味な絵がある論文は珍しいと思います（笑）

512 ：

発表終わった
「機械語どうすんだ」って突っ込まれた〜
パワポは戻ったら公開します

513 ：

発表資料公開しました。

514 ：

電波電波〜

515 ：

なんかGoogleみたいなロゴになってるな

516 ：

そろそろOSが完成してそうな予感

517 ：

コード一行も書いてないから

518 ：

>>516,517
お恥ずかしい限りですが全然進んでません。
就職準備に加えワークショップへの参加で時間全部つぶれてます。
＃まだ公開されてないみたいなので名言はしませんが。
もうここ数ヶ月同じネタで発表し続けているので、いい加減開発に戻りたいです…。

519 ：

近況報告。
3/22-25で北京で開かれるMicrosoft Research AsiaのTheme Workshop 2006というのに出てきます。
３０分の持ち時間で研究報告。内容的には前回の研究会からあまり変わってません。
MSRA-TW06: http://research.microsoft.com/asia/ur/workshop06/
でも明後日くらいに出発なのにまだspeakersもpresentationsも"Will provide later!"って…。
予定では２４日の午後のはずなんですが。行って何もなかったらどうしよう。
英語とかも超下手なのでもういっぱいいっぱいです。
つか街中で英語すら通じなかったらどうしよう。。。

520 ：

安心していいよ．北京は空港も町中もろくに英語通じないから．

521 ：

もしかしてMSに発表するの？
スゲー！

522 ：

>>520
ﾏｼﾞｽｶorz
>>521
MSに発表というよりはMS主催の研究会で発表が正しいです。
ただ、同じ参加者としてMS関係者もたくさんいるので、
そういう意味では「MSに発表」というのもそれほど間違いではないかも。

523 ：

ひょっとしてMVPもらったとか？

524 ：

いえ、貰ってませんよ〜

＃まだ原稿おわってないー

525 ：

こりゃマジで引き抜かれるな

526 ：

骨を

527 ：

ついさっき終了。もう骨って感じでした
原稿つきって緊張するもんなんですね。汗だくです。
とりあえずステージでかっっっ！
http://www.coos.jp/stage.jpg
これは初日のなんですが、今日もステージは一緒。
ただ、観客が少ないのを予想してか席が全部机付きになって、
人も減ってました。（写真のProbert博士はある意味メインゲスト。）
とりあえず眠たいけど寝ても仕方ないのでまた戻ろう。
ではまたﾉｼ

528 ：

おつかれ〜

529 ：

話題がないね

530 ：

だったら上げるな

531 ：

とりあえずWindows Formsが使えればシェルつくったる

532 ：

今どの辺ですか？そろそろ使えますか？
GUIありの推奨動作環境はどれくらいですか？

533 ：

そろそろ会社生活に慣れてきたので開発再開してるとこです。
C#2.0などで規格が新しくなっているのでそれへの対応をしてます。
＃それに対応しないとVS2005とか使えないし。。。
昨年度の後半にしたかったけど、学会やらで後回しにしちゃった分ですね。

534 ：

Windows Formsなんていらん。

535 ：

Singularity IV: Return of the UI
http://channel9.msdn.com/Showpost.aspx?postid=227260

536 ：

今どの辺・・・？

537 ：

Javaを意識した構造に作り替えたところです
Javaも考慮することで分離が良くなるかなあ、と。
だいたい出来たのでいまC#で（また）インタープリタ作ってるところ
ジェネリクスとかどうなるんだろうなあ、と思っています

ただ、FF3がちょっとやばいｗ

538 ：

メインマシンにドットネット入れたくないからサブマシンにドットネットアプリ専用OSとして入れたいな

539 ：

これはVMを動かすだけのOS？

540 ：

まあそういう表現も間違ってはいないのですが、
別にvirtualにするわけではないです。

541 ：

Windows上の.NET VM上の.NETアプリ
が
COOS上の.NETアプリ
と直で動くってこと？
早く使わせろー

542 ：

Wiki生きてる？

543 ：

ひげと比べると進みが遅そう

544 ：

とっくにひげなんかは追い越してるわけだが

545 ：

途中で投げ出さないでこのペースで行ってくれれば
すごくいい感じに

546 ：

会社入ったらもうだめだろ。時間がない

547 ：

ニートになれと？

548 ：

Kはその路線だね

549 ：

>>542
あーWikiは死んでると思います
どうもホスティングいまいちだったので解約しました
WWWは生きてるはず〜
>>546
たまに進めてるんですが、やっぱり毎日数時間みたいなのは無理ですね。。。

550 ：

あまり期待しちゃだめなの？

551 ：

期待していいよ。年末あたりには大きいのが来るよ

552 ：

.NETアプリ、入力フォーム部分はWindowsの部品を使っているんだと思ってたけど
Windowsなしでも動くんだ。

553 ：

Monoがあるじゃないか

554 ：

2007年

555 ：

C o o S

556 ：

お久しぶりです。
最近はホント時間取れてないです。申し訳ない。
やっぱり仕事終わったあとは複雑なことは無理ですね。。。
ただずっとこのままなのは寂しいので、社会人二年目からはよく考えたいです。
とりあえず現状報告でした。

557 ：

勤め人が片手間で開発するのは厳しいですよ、
技術を理解してくれる所に移って、昼間動けるようになるのが理想ですが、
日本だとそういう物好きな会社は少ないので、難しい所ですな。

558 ：

未踏・・・税金の無駄・・・いやなんでもない

559 ：

>>557
真実かは分からないですが、一年目ってスケジューリングしにくくて余計に時間がないっす。
でも非常に近い分野に従事してるし、いまのとこで知見を広げるのも悪くないと思ってます。
>>558
一応CooSで得た経験が役に立ちまくっているので、超間接的に社会に貢献…じゃダメかな〜ｗ

560 ：

ここにもKﾀﾝきてるの？

561 ：

来てないと思いますが。
30日本以来あんましみかけないねえ。

562 ：

>>559
Linuxカーネル関係ですかね。
この手の経験ってかなり限られた分野でしか役に立たないので、
良い所に就職したなぁと思いますよ。

563 ：

Googleに入れ

564 ：

がっかりだ

565 ：

俺もがっかり

566 ：

>>563
英語苦手ｗ
>>564-565
ご期待に添えていなくて申し訳ない・・・
最近はSmalltalkとかSqueakの方針にしたほうが良いのかなあとも思ったり。
なんつーか.NET Frameworkの発展が速すぎて、着いていく限界を感じますね。。。

567 ：

>>566
MSへ転職して、Singularity ver2 を開発すれば全ては解決

568 ：

>>568
やー、Singuarityは
"Singularity Version 1.0 is complete. We're moving our
research forward to the development of Singularity V2.0."
らしいですからねえ。こんな研究を着々とやれちゃうのがすごい。

569 ：

発展早いか？
CLRは実質2.0でしばらくとまりそうだし、
MSILの仕様も変わってないだろ。
むしろ.NETは発展がなすぎて将来性がないって言う印象だが

570 ：

ひげぽんの偉大さが証明されましたね

571 ：

>>570
どう見ても高橋氏の方が上

572 ：

>>569
おっしゃる通りCLRの規格はジェネリクスの大きな変更以降止まっている感じがします。
ただ、代わりにクラスライブラリの規模がでかくなってて、現状の開発方法でそれをキャッチアップできるのか・・・。
>>570-571
仕事と平行してやれてるってすごいと思います。
最近2ch系OSがしずかになってしまって、ちょっともったいないですね。

573 ：

>>572
フォローうまいね

574 ：

まあ、まともな社会人ならこれくらい出来ないとまずいだろう。
風呂敷広げない所は好感が持てますな。
自分の技術力が把握できてるからだろうけど。

575 ：

まともな社会人って？

576 ：

まぁまともな社会人なら趣味でOS開発する時間なんてないだろう。
>>572
クラスライブラリはMonoを使用するでなかったの？

577 ：

>>576
Monoもいくらかの部分がLinux依存なので、動的にパッチしてます。
最近まったく手を入れてないんで、中身どうなっているんだろう・・・

578 ：

どれくらい進んでるの？

579 ：

最近は
・JITコンパイラの開発　→　下のと合わせてやる
・リフレクションの整備　→　ジェネリクスの仕様に合わせて拡張中
ですねぇ。
自分でいうのもなんなんですが、やってることがOSっぽくなくて辛い。。。

580 ：

ライブラリは、Silverlightに照準を合わせれば？
そうすれば、.NETより規模が小さい。
Moonlightとかあるし。

581 ：

辛いって感じるような作業は、やらなくていいよ。
やりたいことやったほうが、楽しくできるでしょ。

582 ：

すいみません完全に見過ごしてました。。。
九月末に引っ越しまして、一時ネット隔離されてたもんで。
>>580
Silverlightの中までよく知らないんですが、
ライブラリはサブセットなんですかね？？
>>581
そうですね。
実は最初に言った引っ越しで通勤時間が短くなりまして、前より開発が進むようになってます。
やっぱり仕事して脳内キャッシュからパージされちゃうと、元に戻すまでに一定コスト掛かるんですねえ。
いままでは「前回の自分にリストアする」だけでいっぱいいっぱいだったので、それに比べると全然よいです。
以前に書いてるかもしれませんが、最近もずっとジェネリクスのインプリではまりにはまってます。
.NETの内部構造と、リフレクションにどう見せるか、というのの摺り合わせが上手くいかず。。。
脳内キャッシュの容量が足りないようなので、どうやって開発したらいいかと考えながらぼちぼちやってるところです。

583 ：

へんてこなソフトは作ってるみたいね

584 ：

>>583
小物しか作る時間ないんですよね。
・・という理由もあり、なによりMS-ResearchのSingularityが
ソースコード公開しちゃったしなーってのもあります。
あれと純粋に差別化を図るのは厳しいorz
いっそのこと旗を降ろしたほうがいいかもしれんのだけど、
うーん、勝手ながらOS以外で気分転換したいってのが正直なところです。

585 ：

ひげはがんばってるなえらいな

586 ：

ひげはホント成長していくよな
エンジニアって感じだ

587 ：

>>585-586
いちいち他所でゴミの話題を出すな

588 ：

まぁゴミではないな

589 ：

>>587 に賛成

590 ：

>>584
Singularity改良すればいいじゃん。

591 ：

CooSとInfernoってスタンスが似てる気がするなぁ

592 ：

テレビは見たい番組だけを録画してから見るから
もう10年以上全くと言っていい程CMを見ていない

593 ：

http://toki.2ch.net/test/read.cgi/dataroom/1293616589/

594 ：

http://toki.2ch.net/test/read.cgi/dataroom/1309855042/

595 ：

これってC#で出来てるの？
んじゃVB.NETでOS作れたりもするのかな？

596 ：2012/06/05

http://ikura.2ch.net/test/read.cgi/dataroom/1324189253/