なあ、monaの開発は続いています

2ch発のOS、MONAについてのスレッドです。
ひげぽん ◆Ngzcp/NZpA を中心に着々と開発が進められています。

■前スレ
なあ、monaの開発はどうなったの？
http://pc8.2ch.net/test/read.cgi/os/1138681234/l50

■本家or分家or避難所
OSを作ろうPart15Mona専用
http://etc3.2ch.net/test/read.cgi/siberia/1136088527/l50

■過去スレ
OSを作ろうpart14　Mona専用
http://pc8.2ch.net/test/read.cgi/os/1127467365/l50
OSを作ろうpart13　Mona専用
http://pc8.2ch.net/test/read.cgi/os/1121690722/l50
OSを作ろうpart12　Mona専用
http://pc8.2ch.net/test/read.cgi/os/1114611781/l50
OSを作ろうpart12　Mona専用
http://pc8.2ch.net/test/read.cgi/os/1114611721/l50
OSを作ろうpart11　Mona専用
http://pc8.2ch.net/test/read.cgi/os/1098713480/l50
【ひげぽん】2ch発のMona 一発目【モダンOS】
http://pc5.2ch.net/test/read.cgi/os/1066957498/l50
OSを作ろうpart11
http://pc5.2ch.net/test/read.cgi/os/1093825736/l50
OSを作ろうpart10
http://nostalgia.rr6.org/test/read.cgi/oslog/1083420872
OSを作ろうpart9
http://nostalgia.rr6.org/test/read.cgi/oslog/1081561384

■続き
OSを作ろうpart8
http://nostalgia.rr6.org/test/read.cgi/oslog/1076216434
OSを作ろうpart7
http://pc5.2ch.net/tech/kako/1066/10669/1066968321.html
OSを作ろうpart6
http://pc5.2ch.net/tech/kako/1052/10525/1052537020.html
OSを作ろうpart5
http://pc5.2ch.net/tech/kako/1042/10423/1042375466.html
OSをつくろうpart4
http://pc3.2ch.net/tech/kako/1037/10370/1037096449.html
OSをつくろうpart3
http://pc3.2ch.net/tech/kako/1027/10270/1027080631.html
OSをつくろうpart2
http://pc3.2ch.net/tech/kako/1024/10244/1024411711.html

一般的な「OSを作ろう」的話題は↓へ。
http://pc8.2ch.net/test/read.cgi/os/1153133384/

本家：http://monaos.org/
開発Wiki：http://wiki.monaos.org/
ひげぽんはてなダイアリ：http://d.hatena.ne.jp/higepon/
ダイアリの広告をほどほどにクリックするとひげぽんのモチベーションが上がるらしい

Mona/開発版/0.3.0
http://wiki.monaos.org/pukiwiki.php?Mona%2F%B3%AB%C8%AF%C8%C7%2F0.3.0
最近活発な話題
http://wiki.monaos.org/pukiwiki.php?%BA%C7%B6%E1%B3%E8%C8%AF%A4%CA%CF%C3%C2%EA

Mona本「MONA〜2ちゃんねる発祥の手作りOS」発売中。
http://www.amazon.co.jp/exec/obidos/ASIN/4839917639/
http://www.cbook24.com/bm_detail.asp?sku=4839917639

↓から買うとひげぽんの収入に。
http://d.hatena.ne.jp/asin/4839917639/higepon-22

前スレでの1000GET協力に感謝。>ALL

ちいッ、結局1000取りやがった　＞ひげ

>>6
次はお前が湾岸を助ける番だぞ

しかし言われて口出しって構図もわりと情けないという罠。

>>8
湾岸かえれ

>>10
なんだよ、湾岸って言った方が湾岸なんだよ！この湾岸！

湾岸を助ける必要なしだよ＞ひげ

monasqで monapi_file_open/read/seek/closeに対応しました。
okayuさんサポートありがとうございました。

実力がないのに大きく見せようとする
人を見下したいやみな発言が多い
小さな手間、派手な成果だけで存在をアピールしようとする
Monaを裏切ってたがなかったことにしている
やりかけで逃げる
匿名で自分擁護

あたりが見透かされて嫌われているんだと思う＞湾岸

これ見よがしにスルーする太郎は相当やな奴だと思うが。

スルーなんて卑怯なことはしていない
ちゃんと匿名で反応している

> crt
monapiとmonalibcが別の物なんであれば、ランタイムも別にあるのが自然かと。
fread()使うなら素直にlibcのcrtリンクしなさいよという。
役割分担してmonapiのcrtがmonalibcのcrt呼ぶっていう形がいいんじゃない。
案2のinit_libc/fini_libcみたいにlibcへのABIを提示してさ。

湾岸はいい奴だよ

>>17さん
両方のcrtがcrtとして成り立つのを維持しつつ、monapiのcrtがmonalibcのcrtを呼ぶって感じでしょうか。

テンプレに湾岸叩き禁止とか書いときゃ良かったか？ｗ
本家へのリンクとかは>>1に入れとくのが良かったかも。
暇な時にWikiへスレたて用のテンプレでもメモっとこーかな。

太郎にすら見放された湾岸哀れ

>>21
同情するなら金をくれ

おっさん古っｗ

>>19
libcはmonapiの上にあるんでmonapiのランタイムは必ずリンク、
libcの関数使うなら加えてlibcのもリンク、みたいな。
ウィークシンボルとか使えば特別問題なくやれるはず。

EXEのエントリポイントの前に各DLLのエントリポイントを呼べばいいんじゃね？

>>24さん
>>25さん

もう少し詳しくお願いします。興味あります。

なあ、もうちょっとまともなスレタイ考えろよ

>>27
だってもうpartほにゃららとか付けようとすると、
「今何スレ目だっけ」とか考えるの面倒じゃん。
適当でいいよ適当で。

>>26
DLLにはエントリポイントがあるし本来DLL用のCRTが必要だろ
そんなことより湾岸ネタを無視し続けるのは人としてどうかと

>>29
湾岸かえれよ
おまえ以外は全員湾岸スルーで同意している空気嫁

>>29
湾岸知ったか乙

>>29
恥ずかしい書き込みだな

ひげぽんさんにとって，もはや湾岸は邪魔なだけ。さっさと追放しちまおう。

>>26
詳しくっつっても、割とそのまんまな話。
現状のコードでlibcとmonapiの両crt共通な処理はmonapiのだけが持って、
libcで必要なstdio初期化なんかについてはウィークシンボル使って
libcがリンクされてる時だけ実行されるようにする。
どうせDLLなんでエントリポイント使うのも確かにいいかも。

>>29
気持ちは分かる。軽くでいいからたまーに何か言っていいかも。

>>24さん
ありがとうございます。
ウィークシンボルについて詳しく調べてみようと思います。
Binary Hacksでも見かけたなぁ。

>>34
PEでweak使えない

>>35
見損なった

>>36
Σ(´Д｀　）あるぇー、そうだっけ？
なんかgcc方面で外人がPE-COFFでweak動かしたぜhahahaとか言ってた覚えが。
最近gcc使ってないんで今日の夜でも作ってみるわ……。

>>37
gcc-3.4.4 => NG
gcc-4.1.1 => OK

>>38
こっちも3.4.2と4.1.1で同様の結果を確認。
PEだとサポートされたの割と最近みたいね。

>>Yume大王
> __attribute__((constructor))やdestructorでinit_libcとfini_libc
init_libcが実際に呼ばれるまで他の静的コンストラクタ/デストラクタ内で
stdio使えないのを解決する（コンストラクタリスト内の順序を制御する？）か諦めるならアリ。

おっと、デストラクタの方はfini_libcが呼ばれる前じゃないと駄目、って感じか。

stdin, stdout, stderrってのはプログラム開始時に予め定義されているってことになってるんだけどプログラム開始時ってのはいつなのかなあ…

>>41
viposどうよ？

ｷﾀ Y⌒Y⌒Y⌒Y⌒Y⌒Y⌒(｡A｡)!!!
ｷﾀ*･゜ﾟ･*:.｡..｡.:*･゜(ﾟ∀ﾟ)ﾟ･*:.｡. .｡.:*･゜ﾟ･*!!!!!
ｷﾀ━(ﾟ∀ﾟ)━(∀ﾟ )━(ﾟ　 )━(　　)━(　　)━(　 ﾟ)━( ﾟ∀)━(ﾟ∀ﾟ)━ !!
ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!!!
ｷﾀ━━━━(°Д°)━━━━!!!!
ttp://www.ipa.go.jp/jinzai/esp/2006mito2/koubokekka.html
ｷﾀ━━━━(Дﾟ(○=(ﾟ∀ﾟ)=○)Дﾟ)━━━━━!!!
ｷﾀ━━━━━(ﾟ(ﾟ∀(ﾟ∀ﾟ(☆∀☆)ﾟ∀ﾟ)∀ﾟ)ﾟ)━━━━━!!
ｷﾀ─ｗｗﾍ√ﾚｖｖ〜(ﾟ∀ﾟ)─ｗｗﾍ√ﾚｖｖ〜ー!!
ｷﾀｧｧｧ(ﾟ∀ﾟ)ｧ( ﾟ∀)ｧ( ﾟ)ｧ( )ｧ(｀ )ﾊｧ(Д｀)ﾊｧ(;´Д｀)ﾊｧﾊｧ
ｷﾀｷﾀｷﾀｷﾀ━━━（ﾟ∀ﾟ≡（ﾟ∀ﾟ≡ﾟ∀ﾟ）≡ﾟ∀ﾟ）━━━━！！

>>41
規格上の定義はよう分からんすけど、ユーザ側のコードで
あんま細かいこと気にせず書ける方が嬉しいかなあ……。

>>43
野郎黙って応募してやがったｗ
ていうか>>43太朗じゃねえのｗ

>>38さん
>>39さん
いろいろあって、weakシンボルまだ調べてないです。ごめんなさい（懺悔）。

>>41(Yumeさん)
確かに。いつなんだろう。
38さんの指摘通り、静的コンストラクタでは使いたいですよね。

>>43さん
きましたw

>>44さん
ごめんなさい。高確率で落ちると思っていたので黙って応募してました。
いや、自分で書くのは恥ずかしいので様子を見てました。＜43太朗じゃねえのｗ

ああ偉大なる税金の無駄遣い

>>46さん
出来る限りがんばるんで許してください

>>45
weakはMr.BKの日記が分かりやすい。
なので読んでないけどBinary Hacksの方にも入ってるかも。
http://0xcc.net/blog/archives/000105.html
http://0xcc.net/blog/archives/000062.html

>>45
無視？未踏祝いに粘着してやる。
- 何のためにDLLにエントリポイントがあるのか？
- 嵐を放置して二度も追放されたのにまだ懲りていないのか？

↓みたいなの書いてhoge.oリンクしたりリンクしなかったり、
main.cのhage()のコメントアウト外してみたりすると挙動が分かりやすい。
同名の非weakシンボルでweakシンボルの定義を上書き出来て、リンクの際に
weak定義のシンボルが未定義参照になる場合は値0のシンボルとして解決される。

---main.c---
#include <stdio.h>
int hage(void) __attribute__((weak));

//int hage(void){return 68616765;}
int main(void)
{
if (hage)
printf("hage見ーっけ(%d)\n", hage());
else
printf("hageてなーい\n");
return 0;
}
---hage.c---
int hage(void){return 0;}

>>49
エントリポイント使うと順序の問題に出くわさないし結構綺麗に出来るんよね。
DLL前提でやる限り割とオススメ。
湾岸話は任せたｗ　あんまり騒いでも逆に言いづらくなるかもしんないから俺は黙るｗ

orz　hoge.oでなくhage.oでした

>>49
monaの梨花はDLLのエントリポイント無視してる

>>52
higeにすればいいのにｗ

>>53
直せばいいじゃん。
梨花で依存され順にDLLのエントリポイントを並べて、
順番にCALLするコードを生成して、
カーネルにエントリポイントとして渡せばいいだけ。

A.EXE -> B.DLL（依存）
B.DLL -> C.DLL（依存）

カーネルに渡すエントリポイント:
　CALL C.DLLのエントリポイント
　CALL B.DLLのエントリポイント
　JMP A.EXEのエントリポイント

>>48さん
>>50さん
weakシンボルの件ありがとうございます。
近いうちに教えてもらったことをまとめますです。

>>49さん
- 何のためにDLLにエントリポイントがあるのか？
→DLL初期化・終了のためでしょうか。
- 嵐を放置して二度も追放されたのにまだ懲りていないのか？
→基本的にどのような発言をしようとも書き込んだ人の自己責任だと思っていますし、僕がコントロールできるものではないと考えています。
僕は僕にとって（主観で）意味のあると感じる書き込み（アドバイス・批判・コード）を読み返事を書きます、興味のない書き込み（荒らしを含む）には返事を書かないことが多くなるでしょう。

礼儀正しかったり、適切なアドバイスやコードを提供してくださる人達には頭が下がる思いです。

>>56
嵐は「ひげぽんのため」と称しているのを忘れないように。
不快感はちゃんと書くこと。
そうしないと勝手に大義名分を与えることになる。

たとえば以前
- ひげぽんさんにとって，もはやココは邪魔なだけ。さっさとスレ消費しちまおう。
という嵐があったが
同じことをOSASKに仕掛けてKが止めたら収まっただろ？
地位に応じた責任を果たさないといけない。
厳しい言い方をすると放置は事実上の加担ともなり得る。

ああそうだ。
いじめを見て見ぬ振りをする教師、と言えば分かりやすいかな。
生徒の問題で教師が関係ないと主張したらどうなる？

>>56
自分が叩かれてる時は主に放置というのもイイんだけど、
身内が叩かれてる時はたまーに何か言っといてもあんま傷付かないよ。
何かよほどの失態やらかしゃともかく、湾岸何もやってない時まで
散々叩かれてんのがなんかかわいそうでｗ

>>57-59
落ち着け、湾岸乙って言われるぞ。

>>57
明らかに湾岸乙
湾岸を擁護するメリットのなさを冷静に考えたら57==湾岸と分かる

太郎の書き込みとアドバイスが良い感じなので水を差すな>湾岸

よっぽど太郎の未踏が悔しいと見える>湾岸

>>61
57=DLLの人じゃね。mona応援派には湾岸擁護意味あるよ。
ていうか最近のリリース担当でGUIも作ったような協力者が、スレで叩かれて
コミュからも見捨てられるような構図って応援する人には割とたえらんないじゃん。
多漏が湾岸いいじゃんアリじゃんていう仲間大事にする姿勢示しゃ少しは安心して関われる。

>>41
カーネルからアプリケーションに飛んできたとき。
なんで、そのへんはカーネル側でopenしとかないと面倒な事になりますな。
んで、ファイルディスクリプタ→FILE*は静的データですかねえ。

というのが世間一般の実装ですが。

まあlibc用のcrt0を別に用意するのがいちばんお手軽でないかい。

皆さんから頂いたアドバイスを元に、monalibc 初期化問題の対応案をまとめました。
４つあるんですが、僕はweakシンボルでの実装が楽しげだと思っています。

>>65
既存の実装だと>>64の人が言うように静的に初期化されてたりもする。
まあ4つの中ではweakかDLLエントリポイントかな。

DLLエントリポイントは今回の件で不採用だとしても使えりゃ便利だから、
この話別にしてその内実行時リンカの挙動変えることも考えとくといいと思う。

自分のことだけで思いやりがないんだな。
名前見るだけで気分悪くなるからもう来ねぇよ。

>>67
かえれ湾岸
思いやりがないと思っているのはおまえだけ

>>68
68に同意
湾岸擁護中が来なければ全然荒れない

>>湾岸の人
実はPEの仕様に元々weakがあったり。（5.4.4、5.5.3）
最近まで使えなかったのがむしろおかしいってような機能なんで、
利用箇所が低レベルライブラリに十分局所化されてりゃ問題ないよ！

>>ひげの人
今はPEなんで問題無いけど、ELFだと未定義weakの解決が少し違うから注意ねー。
（いっそELFは完全に切っちゃってもいいかも）

>>69
それはそれで別の荒れ方するだろ！

gcc 4.1.1を利用し、静的リンクの場合にきちんとweakシンボルが機能していることを確認出来ました。
情報ありがとうございました。

DLLを利用した場合ですが、MonaないのPE DLLリンカに手を入れなければ行けないのでは?と思い始めています。
実験してみます。

>>70さん
いろいろフォローありがとうございます。

ELFだと未定義weakの解決が違うという件ですが具体的にはどのように違うのでしょうか。
weakシンボルが解決できなかったらゼロとして扱われるという点以外を意識していませんでした。

> gcc のバージョンに依存する実装はかなりマズーだと思います

実務を全然知らない管理職がプロジェクト内の存在感ゼロで、存在感をアピールするために、会議で部下に偉そうにせっきょうをしている姿を連想した。
そのせっきょうがまた、全然的外れなわけですよ。
今話しているのは、そんな内容じゃないんだってば！

>>73
同じことを思ったw
太朗がそんなことにまじめに答えていて悲哀を感じる。。

cygwin標準のgccが使えるのが売りだったのに
gcc4.1を自分でmakeして用意しないと使えないのは問題
どうせgccを用意させるならmona用のELFのクロス環境を標準化して
PEを切ってしまえばいいんじゃね？

>>75
OSを作るのにクロスコンパイラのmakeで挫折してたら話にならん
低レベルな奴を入口で排除するべき

>>76
挫折したら話にならないんだったら
別の方法を考えるのが普通だと思うんだけど。

>>77
挫折するような奴は話にならないから排除しろということだが？

なんか湾岸が登場しているねここに。
名無しで。
gccのバージョンとか本質的でないことでしか発言できないの＞湾岸
見せかけの技術と浅ましい心が見えてますよ

>>78
入口で挫折させるのは話にならないからやめろということだが？

>>76
>低レベルな奴
湾岸のことかー

>>78
賛成
低レベルな奴を排除するために敷居を上げるべき

>>75
そろそろpeとtekは外す時期だな
どっちも太郎の意図に反して他人が持ち込んだんだし

みんな落ち着け湾岸と同じレベルまで落ちるな
GCCのバージョン問題は本質的な問題じゃないよ

敷居なんか気にせずどんどん新しいものを取り入れるべき。
もともとmonaは先進性を売りにしてたんだし。

>>84
weakで鮮やかに実装できるのが本質だと言いたいの？
そのweakはgccのバージョンを上げないと使えないんだけど。

>>86
湾岸名無しで乙

>>86
鮮やかに実装できるんだから上げればいいんでない？
古いものに拘って回りくどいことをするのは愚の骨頂。

湾岸はgccを自分でmakeできないヘタレ

ちょっとでも組み込みをやったことがある人なら
クロスコンパイラの準備くらい朝飯前。
それくらいできないでOS作るとか笑わせるなよ。＞湾岸

>>83
他人が持ち込んだものってことごとく不良債権化してるよね。
MonaFormsとかBayGUIとか。

>>91
そうだね
何だか無性に純粋に太郎が書いたコードだけで動くOSを見てみたくなった

>>91
BayGUIは特にひどい。メンテナがいるのに不在っぽい。
速度がでなすぎて実用にならないし、GCの話やD化の話はいずこ？

QEMUでOSASKと比較したがとにかく描画がおそい。
クリッピングとかどうなった？

>純粋に太郎が書いたコードだけで動くOS
（・∀・）ｲｲ!!

>>91
monapi2

>>92
いいねそれ
俺も見てみたい

うわ。スレがすごい進んでいる。

あくまで個人的意見ですが、gcc 4.0にするだけで良い感じになるならありなんじゃないですかね。
動的リンクのあたりがちょっと怪しいですけど（今調査中。）

不良債権化とか言われていますが、もし外部からそう見えるならば僕のマネジメントの責任です申し訳ありません。

＞何だか無性に純粋に太郎が書いたコードだけで動くOSを見てみたくなった
それは無理ですよw。
僕の力なんて微々たるものなので、何十年かかっても終わらないと思います。

湾岸必死だな＜ふりょうさいけん

おまえが（ry

>>97
謙遜も度が過ぎると嫌味ですよ
他人が書いたコードを全部外してもコアな部分に影響ないでそ

ひげぽん頑張れ！

今だ！百ｹﾞｯﾄｫｵ
￣￣￣￣￣∨￣￣￣　　　　　　　(´´
　　　　 ∧∧　　　)　　　　　　(´⌒(´
　　⊂（ﾟДﾟ⊂⌒｀つ≡≡≡(´⌒;;;≡≡≡
　　　　　　 ￣￣　 (´⌒(´⌒;;
　　　　　　ｽﾞｻﾞｰｰｰｰｰｯ

>101

>>99さん
いあ。本当に謙遜ではないです。
コアだけでは何もできないですし、使ってもらえないでしょう。
例えば libcやプロトコルスタック、GUIサーバ、PEローダなどひとりで書くのはとても大変です。

　　|
　　|　　　　　　　　　　　　　 　　　　　　　(´´
　　|　　　　 ∧∧　　　)　　　　　　(´⌒(´
壁 |　　⊂（ﾟДﾟ⊂⌒｀つ≡≡≡(´⌒;;;≡≡≡
　　|　　　　　　 ￣￣　 (´⌒(´⌒;;
　　|　　　　　　ｽﾞｻﾞｰｰｰｰｰｯ

>>103
libc -> なくてもプログラムは書ける
プロトコルスタック -> どのみちまだ実用に達していない
GUIサーバ -> なくてもschemeシェルに影響はない
PEローダ -> 自分で作ったELFローダがあるよね？

↓101の捨て台詞

　　　　　　　　　 ∧_∧
　　　　　　　　　 /⌒ヽ )　もう来ねぇよ・・・・
　　　　　　　　　i三　∪
　　　　　　　 　 |三　| 　　
　　　　　　　　　(/~∪
　　　　　　　　三三
　　　　　　　三三
　　　　　　三三

けっ

>>105
そういうのを外したmonaが真のmonaの姿だね
未踏を記念して完全私物化しなよ
もう誰にも遠慮する必要のない神なんだから＞ひげ

>>109
神を呼び捨てにするんじゃねぇ

monapi_impl.cppから init_libc を weakシンボルとして参照する。
MONALIBC.DLLに init_libc を用意する。

てので実験してみたんですがキーボードサーバが死んでしまいました。
if(init_libc)が真と判定されて init_libcを呼ぶと死ぬので、参照が解決してないのではないかと推測されます。

weakシンボルの値が決まるのはリンク時なので（合ってますよね？）、PEのローダーに手を入れるのが筋かなと思っています。

その筋を調べるためにまずは問題のきりわけをしようと思っていますが
もし万が一お気づきの点があれば御指摘頂けると助かります。

>>111
weakのテストはwinネイティブではちゃんと動いてる？
もし動いてるならpe梨花の問題
もし動かないならgccの問題

>>109さん
半ば冗談で煽っていると理解はしているんですがいちおうまじめに答えておきます。

私物化する気はないです。
協力してくれる人がいて、それぞれが個性を発揮して好きな物を作っているのが楽しいです。

作っていただいたものが有効活用されていないのは改善の余地が多分にありますが、がんばります。

>>111
weakにしたときとしないときで↓の値は変わる？
printf("%p",init_libc);

>>112さん
weakですが、Mona上での静的リンクではうまくいっています。
つまり、mingw-gcc 4.1.1とmingw-ldではうまくっています。

今回試しているのは mingw-gcc 4.1.1, mingw-ld , (Monaの)PE DLLローダ・リンカの３者が絡んでいますです。

>>113
自分の身勝手な楽しさで他人を振り回していないかな。

>>115
静的リンクは関係ない

>今回試しているのは
の状況でweakをつけたり外したりしてポインタの値の変化を調べてみることを言っている

>>116さん
僕に振り回された本人の方でしょうか?
もしそうならば謝ります。
改善しますので具体的に御指摘頂けないでしょうか。

>>116
湾岸乙
自分の身勝手なGUIで他人を振り回していないかな。

>>118
>>57-59

>>115
winではdllへのweakが動いているの？
もし動いてるならpe梨花の問題
もし動かないならgccの問題

>121
「なしはな」って何？

>>122
×なしはな
○りんか

ひげぽんさんがんばって！

>>120さん
具体的にどの開発者の方が振り回されたんでしょうか。

>>114さん
keyboard_server内で
extern "C" int init_libc() __attribute__((weak));の場合
init_libc = 0でした。

extern "C" int init_libc();
の場合 init_libc != 0でした。
うーん。
ちょっと混乱してきたので（僕が）落ち着いた方が良さそうです。

>>112さん
なるほど。それは試していなかったです。
失礼しました。
それを真っ先に試すべきですね。
明日やってみます。

>>応援してくれたかたへ

ありがとうございます。もうそろそろ寝ます。

>>125
俺俺
もうすげー不愉快

>>126
代わりにテストしてみた
$ echo 'void test(){}'>b.c
$ echo '#include<stdio.h>'>a.c
$ echo 'extern void test() __attribute__((weak));'>>a.c
$ echo 'int main(){printf("%p\n",test);return 0;}'>>a.c
$ i386-mingw32-gcc a.c&&./a
00000000
$ i386-mingw32-gcc a.c b.c&&./a
00401310
$ i386-mingw32-gcc -shared -o b.dll b.c
$ i386-mingw32-gcc a.c b.dll&&./a
00000000

∴weakでimport不可能

>>125さん
ごめんなさい。そしてありがとうございます。＜テスト

で結局>>55

寝る前にひとつだけ気になったので。
nobita% ~/bin/i386-mingw32-nm b.dll |grep test
100011c0 T _test

wじゃなくてTですね。
Tはテキストセクションにあるってことか。

これを w にする方法(オプション）がないか探してみてダメならDLLエントリポイントにチャレンジします。

メモ。
リンカスクリプトは？どうだろうか。明日試そう。

>>130
wは参照先ではなく参照元

$ i386-mingw32-gcc -c a.c
$ i386-mingw32-nm a.o|grep test
00000000 A .weak._test._main
w _test

>>131
インポートテーブル経由の間接参照は理解してる？
参照元はインポートテーブルを見てるだけで
インポートテーブルから参照先にジャンプしてるから
参照元から見たアドレスと参照先から見たアドレスは違う

$ echo '#include <stdio.h>'>a.c
$ echo 'extern void test();'>>a.c
$ echo 'int main(){printf("1:%p\n",test);test();return 0;}'>>a.c
$ echo '#include<stdio.h>'>b.c
$ echo 'void test(){printf("2:%p\n",test);}'>>b.c
$ i386-mingw32-gcc a.c b.c&&./a
1:00401310
2:00401310
$ i386-mingw32-gcc -shared -o b.dll b.c
$ i386-mingw32-gcc a.c b.dll&&./a
1:004014F0
2:100011C0

グローバル変数だとこういう間接参照ができない
それを無理矢理回避してるのがauto-import
んじゃ！（もう来ねぇよ）

pe捨ててelf梨花を書くのが正解な希ガス

Linuxに移行した今となってはPEは癌だな。
クロスコンパイラが必要だし手軽に実験できないしでメリットなし。

話の流れぶった切って悪いが、今Monaは何ができるの？
ホームページも妙な英語になってるし、流れがまったくつかめない…

>>136
未踏が取れる

>>136
使うためのOSじゃないから何もできない。
ひげぽんの勉強成果の発表会みたいなもん。

>>135
GNUツールの主力はELFで、PEは異端だからなぁ。。。
M$が採用してなけりゃa.outと同じ運命を辿ったんだし。。。

>>139
そこでMach-Oですよ

ps3linuxのQemuで動いた

>>140
Mach-Oはなぁ。。。
dylibとbundleを区別するのが萎え。

>>141
ps3linuxでクロス開発環境を構築すれば勇者様の仲間入りだ！

>>72
ELFだと未定義weakの解決にライブラリ（アーカイブ）内を探索しない。PEだと仕様的にはするかしないか選べる。
>>127の話聞いてgccの実際の動作が気になってきたんで、この辺俺も少し調べてみる。

>>75
それは大事な話かも。

http://sources.redhat.com/ml/binutils/2005-08/msg00205.html
あっさり……。ある意味ビンゴ。
知らん内にSVR4 ABIに合わせてgasがデフォでIMAGE_WEAK_EXTERN_SEARCH_NOLIBRARYを
吐くようになっていたらしい。IMAGE_WEAK_EXTERN_SEARCH_LIBRARYで吐く方法探してみる。

結論：
gnu ldはIMAGE_WEAK_EXTERN_SEARCH_LIBRARYに対応してねえ。
gcc/gasもIMAGE_WEAK_EXTERN_SEARCH_LIBRARYを吐かせる方法持ってない。
今のところgccで使う限りPEもELFも同じweakの動作みたい。

というわけで結局DLLかなあ。素っ裸のobjで一段かましゃweakでやれないこともないけど、
気持ち良さが減り過ぎ？　因みに>>143からこっち一度もコンパイラ走らせずに言ってるから、
信用出来ない人は自分で検証しちゃってー。

ああ、monalibc用にgccのspecs書くという手もあるか？
monalibcがリンクされる場合だけ素っ裸obj1つ食わせるとか多分出来るよね。
それだとそこまで気持ち良さ減らないけど、そこまでやるかっつー感じはあるｗ

>>75
>どうせgccを用意させるならmona用のELFのクロス環境を標準化して
>PEを切ってしまえばいいんじゃね？
賛成

カスタムクロスgccの作り方は任天堂のes OSが参考になる
gccにパッチ当ててtargetをカスタムしてる
GPLじゃないからソース見ても大丈夫
ttp://nes.sourceforge.jp/

>>147
おお、こんなのがあったのか。
和製OSに近いノリや規模なのにソース構成の洗練度は桁違いだな。
プロとアマの壁を感じた。

IDLとか使ってるのがイイね。しかも独自パーサ。

なぁ、なんでCOFFなんて時代遅れの遺物を使ってるん？

>>150
cygwinがメイン環境の時代にはその方が都合が良かったから

>>132さん
御指摘の通り間違いです。完全に寝ぼけてました。ごめんなさい。

>>133さん
理解していませんでした。ありがとうございます。
静的リンクの場合
a.c ->(call)-> test()

動的リンクの場合
a.c ->(call)-> (インポートテーブル内の関数) ->(jmp?) -> test()

nobita% ~/bin/i386-mingw32-nm a.exe|grep test
__imp__testがインポートテーブルの関数ってことかな。
つまり a.c + (インポート関数) = a.exe。
>||
004050e8 I __imp__test
004014f0 T _test
||<

> グローバル変数だとこういう間接参照ができない

a.c
>||
extern int test;
extern void show_test();
int main()
{
  printf("1:%x\n", test);
  show_test();
  return 0;
}
||<

b.c
>||
int test = 0x1234;
void show_test()
{
  printf("2:%x\n",test);
}
||<

静的リンクの場合
>||
1:1234
2:1234
||<

動的リンクの場合
>||
nobita% ~/bin/i386-mingw32-gcc a.c b.dll
Info: resolving _test by linking to __imp__test (auto-import)
||<

なんか言われた!
>||
nobita% ~/bin/i386-mingw32-nm a.exe|grep test|grep -v show
004012e7 T __fu0__test
0040510c I __imp__test
0040510c I __imp__test
004051e4 I __nm__test
004050b8 I __nm_thnk__test
||<

いろいろシンボルが出来ている。
実行結果は良い感じ
>||
1:1234
2:1234
||<

気になるので追試
c.c
>||
extern int test;
extern int get_test();
int main()
{
  printf("1:%x\n", test);
  printf("2:%x\n", get_test());
  return 0;
}
||<

d.c
>||
int test = 0x1234;
int get_test()
{
  return test;
}
||<

さっきと結果は同じ
>||
nobita% ~/bin/i386-mingw32-gcc -shared -o d.dll d.c
nobita% ~/bin/i386-mingw32-gcc c.c d.dll
Info: resolving _test by linking to __imp__test (auto-import)
nobita% wine a.exe
1:1234
2:1234
||<

MONAPI.DLLなどで使われている手法
>||
nobita% ~/bin/i386-mingw32-ld --export-all-symbols --out-implib d_imp.a -o d.dll d.o
Cannot export get_test: symbol not found
Cannot export test: symbol not found
Creating library file: d_imp.a
||<

なんか失敗しているなあ。なぜだろう。--verboseでやってみたけどリンカスクリプトが表示されるだけだ。

man /home/taro/man/man1/i386-mingw32-ld.1
>||
--out-implib file
    The linker will create the file file which will contain an import lib corresponding to the DLL the  linker  is
    generating. This import lib (which should be called "*.dll.a" or "*.a" may be used to link clients against the
    generated DLL; this behaviour makes it possible to skip a separate "dlltool"  import  library  creation  step.
    [This option is specific to the i386 PE targeted port of the linker]
||<

import関数を*.aに分離することで DLL本体がなくても、そのDLLファイルを参照する実行ファイルを作ることが出来るってことだろうか。
とりあえず実験はここまで。

>>134さん
>>135さん
なるほど。現段階では自分の理解が浅くコストバランスが見えていませんが頭に留めておきます。

>>141さん
おおすごい。Mona動かしてScreen Shotを！

>>75さんの発言について
okayuさん(monasqの方)程の人が Mona SDKで開発されていたことを考えると
「Windowsで簡単に開発できること」は絶対維持したいです。
今まではそれが cygwin とかだったんですが、ELFクロスコンパイラを用意してSDKとして配れば
使う側からすれば手間はあまり変わらないですよね。

マイクロソフトのドキュメント(Google Cacheから発掘)によると
>||
弱い外部参照はEXTERNALストレージ クラス、UNDEFセクション番号、および値0を持つシンボル テーブル レコードによって表されます。
弱い外部参照シンボル レコードの後には、下記の形式の補助レコードが続きます。
 オフセット     サイズ  フィールド  解説
 0  4   TagIndex    sym1が見つからないときにリンクされるシンボルsym2のシンボル テーブル インデックスです。
 4  4   Characteristics     IMAGE_WEAK_EXTERN_SEARCH_NOLIBRARYの値です。これはsym1のためのライブラリ検索が行われないことを示します。

 IMAGE_WEAK_EXTERN_SEARCH_LIBRARYの値です。これはsym1のためのライブラリ検索が行われることを示します。

 IMAGE_WEAK_EXTERN_SEARCH_ALIASの値です。これはsym1がsym2の別名であることを示します
||<

そもそも127さんの検証で、動的リンク時には weakシンボルをimport不可っぽいことが分かった。
それで
>>143さん
が何を言っているのか、僕の理解が浅くてよく分からないので調べる。

理解が間違っていたらツッコミをお願いします。
ELF/PEともに、gnu ldはweak参照のシンボルのルックアップを *.a 内ではやらない。
一見すると ELF/PE 同じ動作で何も困らないじゃん！という話なのだけど。

Monaでは実行ファイルの作成に importlib(--out-implibで作ったやつ) をリンクしていている。
weak 参照シンボルを.aなファイルから探してもらえないと、リンクしているにもかかわらず weak 参照に失敗するということになる。
だから困るって話でしょうか。

解決案として monalibc をリンクする場合に monalibc_imp.a 以外に init_libc.o を必ずリンクするようにしてそこで weak参照を解決させるという話も。

で、143さんがおっしゃっていることを僕も検証すべきなので
一番信用できるのはソースなので grep してみた。
>||
nobita% pwd
/home/taro/src/binutils-2.17
nobita% fxg "c" "IMAGE_WEAK"
./bfd/cofflink.c:                    characteristic IMAGE_WEAK_EXTERN_SEARCH_NOLIBRARY (1).
./gas/config/obj-coff.c:  SA_SET_SYM_FSIZE (symbolP, IMAGE_WEAK_EXTERN_SEARCH_NOLIBRARY);
||<

143さんの言う通り IMAGE_WEAK_EXTERN_SEARCH_NOLIBRARY 決め打ち。

gccのspecsに関しては現在オフラインなので調べきれていませんが、以下のようなお気楽方法はどうでしょう。
現在libcをリンクするときは Makefile に
>||
ADDLINK    = -lmonalibc-imp
||<

と書いていますが、今後は↓みたいに書くことにして、LINK_MONALIBCのなかに importlibと.oをリンクするってのを隠蔽してしまえば良い。
>||
ADDLINK    = LINK_MONALIBC
||<

既存のMakefileの書き換えは発生しますが、開発者の負担はそんなに変わらないのではないでしょうか。

と怒涛の書き込みすみません。買いもの行ってきます。

>>156
ヒアドキュメント読みにくい

> なんか失敗しているなあ。なぜだろう。
--shared抜けてる
sharedの有無で違うものができる
$ file d-noshared.dll
d.dll: PE executable for MS Windows (console) Intel 80386 32-bit
$ file d-shared.dll
d.dll: PE executable for MS Windows (DLL) (console) Intel 80386 32-bit
前者はDLLではなくEXE

> そのDLLファイルを参照する実行ファイルを作ることが出来る
昔はDLLを直接リンクできなかった
gcc a.c b.dllみたいなのはエラー

PEのDLLはEXEと同じ場所に置くのが基本
ldconfigみたいにパスが分離されているわけではない
Cygwin見ると/usr/binにcygXXX.dllがあるでしょ
POSIX風にリンカに/usr/libを見せるためにインポートライブラリを置く

>>160
monalibc特別扱いで済む問題じゃないよ
ちょっと頑張ったDLL作るたびに同じ細工が必要になるし
そもそもエントリポイントが実行されれば必要ない
現状DLL内のコンストラクタをisInDll()とか無理して呼んでるでしょ
そういうのをなくすのにもDLLにCRTが必要

>>156
引用されているmanにも書いてあるけどインポートライブラリの接尾辞は .dll.a が良い
たとえば /usr/lib に libHIGE.a と libHIGE.dll.a があった場合
gcc a.c -lHIGE とすれば libHIGE.dll.a が
gcc -static a.c -lHIGE とすれば libHIGE.a がリンクされる

これはELFで /usr/lib に libHIGE.a と libHIGE.so があるのと同じ
というか意図的にそれと似るように配慮した結果

143様とは別人だけど

>>159
> gnu ldはweak参照のシンボルのルックアップを *.a 内ではやらない。
これを>>127のソースで確認

$ i386-mingw32-gcc -c b.c
$ i386-mingw32-ar cru libb.a b.o
$ i386-mingw32-gcc a.c libb.a&&./a
$ i386-mingw32-gcc a.c b.o&&./a
$ i386-mingw32-gcc a.c libb.a&&./a
00000000
$ i386-mingw32-gcc a.c b.o&&./a
00401310

> Monaでは実行ファイルの作成に importlib(--out-implibで作ったやつ) をリンクしていている。
>>127ではインポートライブラリを経由せずにDLL直にリンクしているけどぬるぽだよ

> $ i386-mingw32-gcc a.c b.dll&&./a
> 00000000

>>157
> 使う側からすれば手間はあまり変わらないですよね。
それはどういう層を対象にしているかで全然違う

普段からcygwin環境で開発しているような人なら
別途専用SDKを使う方が面倒くさく感じる
いつものgccでOSが作れるというインパクトもない

万人向けなんてあり得ないから自分の都合だけ考えてればいいんじゃね？
思いやりがないとか批判されても無視してるのと同じこと

>>163 検証さんきゅー横着者でごめんなさい。
>>48の高林さんの奴が成立するのは、ELFの.soはアーカイブではないからだろうね。
さんざんweakプッシュしたのは俺だけど、やっぱエントリポイントで解決するのが良さそう。
お騒がせしてアイムソーリー！
しかしね、結局のところ、君だって楽しんだんだろ？　（←重荷になった不倫を終わらせるダメ中年のような面持ちで）

>>165
一緒に湾岸を応援してくれてありがとう

bayside先生の次回作にご期待ください。

〜　完　〜

次回作
bayOS 〜退化〜

>>161さん
>ヒアドキュメント読みにくい
失礼しました。別の方法を考えます。

--sharedについて
  nobita% ~/bin/i386-mingw32-ld --shared --export-all-symbols --out-implib libd.dll.a -o d.dll d.o
  Cannot export get_test: symbol not found
  Cannot export test: symbol not found
  Creating library file: libd.dll.a

まだおかしいみたいです。後で調べよう。
DLLにCRTが必要とのこと理解できています。

>>162さん
ありがとうございます。気をつけます。

>>163さん
検証ありがとうございます。

> 127ではインポートライブラリを経由せずにDLL直にリンクしているけどぬるぽだよ
つまり、.dllは、.a(アーカイブ)と同等の扱いで検索対象にならないってことでしょうか。

>>164さん
> それはどういう層を対象にしているかで全然違う
その通りですね。

-僕はLinuxが開発環境なのでLinuxサポートは続けたい
-Windowsの人がLinux環境を用意するのは大変なので、なんらかの開発環境を用意すべき

の2つは外せないと思っています。
cygwin のgccでそのままOSの開発が出来るというインパクトはそこまで重要視していません。
(過去にTinoさんを引きつけた理由ではあるのですけども)

>>143さん

>しかしね、結局のところ、君だって楽しんだんだろ？　
僕は楽しかったです。かなり！。

ということで、DLLのエントリポイント実装を調べますか。

ところでweak参照の件を調べる過程でLinker&Loadersの一部を読み直したのですが、ELFのリンカを書いても良いかなと思い始めています。
標準入出力対応が完全でないのでいますぐは手を出さないつもりですけども。

＞cygwin のgccでそのままOSの開発が出来るというインパクトはそこまで重要視していません。
＞(過去にTinoさんを引きつけた理由ではあるのですけども)
いちいち煽ってんじゃねーよ

ん？誰に対する煽りですか?

>>172
自分で名指ししてるだろ

Tinoさん？
煽ってないですよ。書き方が悪かったなら謝ります。
難しいな。。

ちなみに怒っているのは誰なのでしょうか。
Tinoさん本人?Tinoさんファン？

>>175
そんなことどーでもいいから
事実無根な叩きはきちんと鎮火しろ

怒っているんだけど理由とその人が特定できないのは難しいなあ。

鎮火ですが必要だと思えばやりますし、そう思わなければやりません。
ということで >>176さん

うん。なんか。例によって仲の良い奴らだと思うわよ。

＞鎮火ですが必要だと思えばやりますし、そう思わなければやりません。
ぐちぐち言ってんじゃねーよ
一度そんなちっぽけな自分を捨ててみ

微妙に見落としてた。

>>163
> >>127ではインポートライブラリを経由せずにDLL直にリンクしているけどぬるぽだよ
>>169
> つまり、.dllは、.a(アーカイブ)と同等の扱いで検索対象にならないってことでしょうか。
多分。よく考えたら.soがアーカイブじゃねーんならDLLの中だって見てくれてもいいよな。
ある程度調べてからMLにでも投げて中の人に聞いてみるかも。

>179
そんなあなたがちっぽけにみえるw

湾岸かえれ

湾岸と湾岸の態度と自作自演がうざい

DLLのエントリポイント対応
http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx から仕様書を入手する。

    AddressOfEntryPoint
    The address of the entry point relative to the image base when the executable file is loaded into memory.
    For program images, this is the starting address.
    For device drivers, this is the address of the initialization function.
    An entry point is optional for DLLs. When no entry point is present, this field must be zero.

PEParserに
inline uint32_t get_EntryPoint() { return this->data == NULL ? 0 : this->specific->ImageBase + this->standard->EntryPointRVA; }
がある。

PELinkerのLoadでDLLの参照を解決してBinaryを作っているみたい。
ここを通った後(途中)であれば、どのDLLを参照していてどのアドレスに割り当てられたか?が分かっているはず。
使用されているDLLでかつ、EntryPointが0でないもののアドレスのリストを作って、Binaryと共にプロセスサーバに渡す。
プロセスサーバはそのリストを保持する。
各プログラムの__user_start時に、プロセスサーバにそのリストを問い合わせて call する。って感じかなあ。
あ。初期化の順番にも気を付けないとだな。

詳細はまだ追えてないんですがこんな感じかな。

>>184
>>55見た？また無視？
ブートストラップを実行時に作るとプロセス鯖にもカーネルにも手を入れる必要はない

>>147
スラドにも来たね
ttp://slashdot.jp/developers/article.pl?sid=06/11/24/042234&threshold=-1

ふと、一つ気付いた
ひげぽんの書く文章が長くて理屈っぽくなってるね
何となくとか好みとか言ってたのと比べたら格段の進歩だ
なるほど未踏が通るレベルに確かに達してると思った

未踏通過を踏台にして外資に就職や転職する奴多いが、それは典型的税金泥棒。
蓑輪君もうっかりそうならないように気をつけようね。

？は通過点でgoogleが目的地

>>185さん
大変申し訳ありません。
読んではいたのですが頭に入っていなかったようです。
きちんと読み直して方針を考えます。すみません。

>>187さん
ありがとうございます。がんばります。

>>188さん
今のところそんな予定はないですねぇ
というか未踏の準備せねば。

太郎深追いしてて成長を感じる
大きくなった

湾岸GUIの欠陥がいろいろあるみたいだね

ちょっとしたものを作ろうとすると破綻するGUIって作者が全然やるきないよな

Wikiが熱い
太郎攻めてる

>とはいえ、FDサポートがこれだけ放置気味だとそれしかないかという気もします。
>-- bayside 2006-11-30 (木) 00:53:42 New!

普通に引いた。
自分は放置しまくってるのに、こんな嫌味よく言えるね。

それも事実を誤認して。

ちゃんと聞いてちゃんと答えた。イイ流れじゃないか。
これで少なくともGUIについちゃ自分の要求を解決する力のある奴が
動きやすい状況になった。

あとは太郎が拗ねて「もうアンタなんか大っ嫌い、絶交よ！」でなく
「女を磨いていつかきっと振り向かせてみるわ！」な方向にやる気出せば万事OK。
最近太郎が盛り上がってるだけに、他の奴がお通夜みたいだとなんか拗ねそうｗｗｗ

＞ちゃんと聞いてちゃんと答えた。イイ流れじゃないか。
＞これで少なくともGUIについちゃ自分の要求を解決する力のある奴が
＞動きやすい状況になった。

そうですねー。
聞いてよかったですよ。

＞あとは太郎が拗ねて「もうアンタなんか大っ嫌い、絶交よ！」でなく
＞「女を磨いていつかきっと振り向かせてみるわ！」な方向にやる気出せば万事OK。
＞最近太郎が盛り上がってるだけに、他の奴がお通夜みたいだとなんか拗ねそうｗｗｗ

変な方向にはいかないですよ（笑)
自分はMonaを一生かかっても完成させる覚悟は出来ているんで、淡々と妥協せずやっていこうと思います。


GUIに関しては
＞これで少なくともGUIについちゃ自分の要求を解決する力のある奴が
＞動きやすい状況になった。

に期待しています。
我こそは天下をとるという人が入ればぜひ。

GUIに関しては現段階では未踏が終わるまでは様子を見ようと思っていますが、それまでに好転しないようであれば自分で半年-1年ほど時間をかけてGUI一筋でやってみる覚悟もあります。

ということでDLLエントリポイントに取り掛かります。
時間がかかってすみませんでした。

まずはLinux上でこんな感じかな。

#define ENTRY_POINT_FUNC(x)      \
    void entry_point_##x()       \
    {                            \
        printf("%s\n", __func__);\
    }

ENTRY_POINT_FUNC(0);
ENTRY_POINT_FUNC(1);
ENTRY_POINT_FUNC(2);

typedef unsigned int dword;

void call_functions(dword size, dword* functions, dword goal)
{
    for (dword i = 0; i < size; i++)
    {
        void (*f)(void) = (void(*)(void))functions[i];
        f();
    }
    void (*g)(void) = (void(*)(void))goal;
    g();
}

void hello()
{
    printf("hello\n");
}

int main(int argc, char *argv[])
{
    dword functions[3];
    functions[0] = (dword)entry_point_0;
    functions[1] = (dword)entry_point_1;
    functions[2] = (dword)entry_point_2;

    call_functions(3, functions, (dword)hello);
    return 0;
}

goalは call じゃなくて jmp でも良いなぁ。

>>55の人が言っているコード生成は
バイナリで call, call, jmpなコードを動的に生成してプロセスメモリ空間にコピーするってことかな。
一晩考えます。

>>199
>f();
>g();
(*f)();
(*g)();
と書け

>203さん
ちょっと自信がなかったので調べたのですが手元のC言語辞典では
(*f)();
f();
のどちらも同じような扱いっぽいのですが(*f)();をすすめているのは
一目で関数ポインタだと分かるようにするとかそういう意図でしょうか。

>>204
>一目で関数ポインタだと分かる
それがひとつ

ふたつめは対称性
int a;
int *b;
この書式はaと*bが対称でintだということを示している
同様に
void foo();
void(*bar)() = foo;
とした場合fooと(*bar)が対称になっている
そのためfoo()に対応するのは(*bar)()となる

>void call_functions(dword size, dword* functions, dword goal)
なぜ引数を関数ポインタにしないのか?
void call_functions(int size, void(**functions)(), void(*goal)())

渡す前にキャストして渡されてからキャストする意味がない
前>(dword)hello
後>void (*g)(void) = (void(*)(void))goal;
これは型保障性を破壊する悪いコード

dwordみたいなtypedefはローカルでやるのは勝手だけど
システムヘッダで使うのは感心しない

typedefについて補足
ありがちな名前は干渉するのが問題だということ
この手のことを独自にやるときは接頭辞を付けるのが普通
たとえばglibではtypedef unsigned int guint;のようにgを付ける

>>206
問題はそこじゃないんじゃね？
>>199は64bit移植性がないコードだよね？
型不明のポインタはvoid*で受けとくのが無難では。

>>207
基本的に同意だけど
>型不明のポインタ
今回は型がわかってるんだよね

>>207
monaは64bit関係ないだろ

>>205さん
対称性の話了解です。
ありがとうございます。
なぜ関数ポインタにしないかですが、一応理由があって
将来予想される入力が dword だからです。
具体的にはPEのEntryPointをアドレスとして dword で受けて、キャストして実行することを想定しています。（アセンブラだったらキャストも何もないですが）

typedefですが、Mona内では dword/word/byte というtypedefをシステムヘッダでやっています。
まずいですかねぇ。
確かに何かを移植しようとしたときに被るかもしれない。

>>207さん
型不明に関してはその通りです。（一般的なシチュエーションでは）

今回はMonaで32bitコードなので上の様になっています。

>>210
>一応理由があって
渡す前にキャストすればいいだけじゃないの?
引数を型不明にする理由にはならない

>>210
御父上は超対称性でニュートラリーノとか研究しておられるんでしたっけ。

渡す前にcastでも良いと思います。
今回は渡した後にcastで実験しました。

>>212さん
詳しく知らないので今度聞いてみます（笑）

>>213
1. 引数を型保障した方が関数の意図が分かりやすい
2. 状況依存部分と汎用部分を切り分けて汎用部分は汎用的に書く

1、2ともに同意です。ありがとうございます。

これか
ttp://www.icepp.s.u-tokyo.ac.jp/~minowa/bolometer.html

東大教授！？マジ？

http://d.hatena.ne.jp/higepon/20061202/1165025517

実験その3を公開しました。
これを応用してDLLエントリポイントを呼び出すコード生成をしようと思っています。
>>55の人が
思ってたのはこれかなぁ。(もっとスマートだったらどうしよう）

＼　　　∩─ー、 　　　====
　 ＼／　●　、_ ｀ヽ 　　======
　　/ ＼(　●　 ● |つ
　　|　　 X_入__ノ 　 ミ　　そんな餌に俺様がクマーー！！
　　 、　(＿／　　　ノ　/⌒l
　　 /＼＿＿＿ノ゛＿/　 /　　=====
　　〈　　　　　　　　 ＿_ノ　　====
　　 ＼　＼＿　　　　＼
　　　　＼＿__）　　　　　＼　　　======　　　(´⌒
　　　　　　　＼　　 ＿＿_ ＼＿＿　　(´⌒;;(´⌒;;
　　　　　　　　 ＼＿＿＿）＿＿＿）(´;;⌒　 (´⌒;;　　ズザザザ

今の方針でもう少しすすめてみようと思います。

http://d.hatena.ne.jp/higepon/20061202/1165061214

こんな感じでエントリポイントをcallしていく感じかなぁ

>>221
そんなことよりそろそろ来週発売のオプソマガジン最終号の宣伝しないの？

>>222さん
うあ。忘れてた。
指摘ありがとうございます。日記に書くかな。

>>212
熟知してるくせに何で聞いてんのｗ

12/8発売か。まぁ直前で良い気がしてきました。

ハッカー夭逝術
モナーOSの作者、ひげぽんさん

＞夭逝
ちょーーーーーーーーｗ
洒落にならんｗｗ

洒落？太郎が音楽集めてるやつか

この池沼どもはどっから流れてきたの？

>>229

ここかな？
http://www.kh.rim.or.jp/~nagamura/misc/stroustrup-interview.html

>>230
でももうカーネルから全部scheme化するんだよね?

>228
音楽だけじゃないお＾＾

>>231
それは画期的馬鹿なので800万の価値がある。

�念S・・・

湾岸はschemeにブチ切れて転進？

>>234
それは鮫島事件と同じように闇に葬り去られた事件なんだ！

あれ？外が騒がしい。ちょっと行ってくる・・・

>>236
鮫島って太郎の師匠の屋根裏の弟子？

瑞記か。今何してるのかね。

巻き添え食った亮太郎は元気かな？

>239
ttp://d.hatena.ne.jp/mdiapp/

>>205
対称性を言うなら代入で&を付けるべき

int a;
int *b = &a;

void foo();
void (*bar)() = &foo; ← ここのことね

fooも&fooも同じ扱いだがC++では&が強制される

class Hige(){public: void pon();};
void (Hige::*foo)() = &Hige::pon;
void (Hige::*bar)() = Hige::pon; ← エラー

>>241
>int a;
>int *b = &a;
a=2;と*b=2;が同じ
　↓
aと*bが同じint
　↓
すげー！ポインタが分かったかも！

int a,*b,c;みたいな書式が気持ち悪い人も
これで安心して使えるかも

ついでに説明すると
intは整数の型だから『整数型』と呼ばれるように
void(*)()みたいな関数の型は『関数型』と呼ぶ

関数型が活用できるように
インラインで定義した無名関数を代入できるように
便宜を与える方向で進化したのが『関数型言語』

void hige(void(*pon)());
を呼び出すのに
hige({printf("mona");});
みたいな書き方ができると考えると近い

型推論や副作用やモナドは関数型の本質ではない

>>243
無名庵ＥＯって知ってるか？

>>243
モナとモナドに何の関係が？

>>243
> ついでに説明すると

ttp://business.nikkeibp.co.jp/article/skillup/20061106/113138/

> 聞き手を失望・疲労させてはいけない
> こんなプレゼンはダメだ

> 一人の聴衆の質問に対して回答を終えた。
> 「････いかかでしょうか。ご理解いただけましたでしょうか」
> 「はい、ありがとうございました」
> 「ついでにご説明しておきますが」
> と、勢いでつい････

>>244
鈴木のペンネーム

>>245
scheme>haskellなんかね？

>>235
どんどん派手にやって脱落する奴は放置すればいいと思うよ

>>249
同意
Cの知識をひけらかすようなカスが来なくなることを期待

入れ替わりにschemeの知識をひけらかすカスが集まるだけかと

かすカスうるせーんだよ粕ｗ

クズの妬みがすごいな。
太郎が手の届かない所に逝っちゃったね。

最近の気合の入りようは正直手が届かない。さすがはボンクラどもの期待の星。
実力に関してはまあ、多少へぼいくらいが絡みやすくて愛嬌がある。

>>237
pmokyのことかーーーーーーー

>>253
湾岸のことかーーーーーーー

関数型はocamlくらいが落とし所だと思う

何でもいいけどj様の日本語入力やらネットやらはどうなったの？

>>241さん

あ。これどちらか迷っていました。&にします。

>>258さん
確かにjunjunnさん最近お見かけしないですね
呼んでみよう。
junjunnさーーん

業務連絡です。ひげさん、ひげさん、蓑輪さん、蓑輪さん、>>259 さん
>>230 番の件でお客様がお呼びです。至急資料をまとめて >>261 番へお越し
ください。

C++がだめという話かな?
使いどころによるのではないでしょうか。
気に入らない人がいれば自分で何とかするのが良いかもしれませんね。

>>261
あれに書いてあるC++の策略はMonaそのものに写るが、あの文章を知ってて
Monaを始めた？それとも知らずにまったく偶然同じ道を歩んでいるの？

話をぶった切って悪いが、プログラミングが良くわからん物見遊山ユーザーな俺には、パッとする機能進化がなくてつまらん。
OSASKよりもぜんぜん綺麗だし面白みがあるけど、なんか物足りない。
>>258の言うような日本語入力やネットが出来るんだったら少し面白いと思う。
テキストブラウザやRSS取得、メーラーだけでも結構見栄えしそう。

何の参考にもならないくだらない意見だけど、頭の隅にでも置いといてくれるとうれしい。

>>263
君がプログラミングを覚えて自分で作りましょう。
それが太郎様のルールです。

>>262
具体的に。

>>262さん
何も知らないです。

>>265
簡単なことも難しく高尚に見せることで保身を図る。
皆まで言わせるな。

>>267
湾岸自分の頭がわるいのを人のせいにしては行けない
君が理解できていないのは概念だC++のせいじゃない
真っ赤なかおしてないで謝ろうよ

>>268
的確なツッコミだ

何もしてないカスが湾岸を批判するのは正直不愉快。
Monaで湾岸以上の実績を残した者しか湾岸を批判する資格なし。
太郎以外に湾岸を扱き下ろす資格があるのはj様だけ。

その理論だと、あらゆるコメンテーターや国民は、国会議員に対して文句を言えないなぁ。

憲法で国民主権が定められている国家と太郎独裁のMonaを一緒にされてもなｗ

その理論だと、あらゆるユーザーは、MSやAppleに対して文句を言えないなぁ。

>>273
お前頭いいな。
遠慮せずどんどん湾岸を批判してくれ。

湾岸新ADKｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!!!

EntryPointがRelocate後にどこにいくか解析中。
外から動きを見るべきか、仕様を見るべきか迷うけどまずは動きを見ています。

Relocate時にEntryPointもRelocate（？）すれば良い気がしてきた。

いや違うな。ImageBaseにRelativeだから今のコードであっているのかな。

このスレではまた〜りしたいので、
bayside批判はシベリアでお願いします。

>>ひげ
RVAなんでImageBase見てればOK。仕様見た方が早いんじゃね？

仕様も糞も再配置したアドレスにEntryPointRVAを足すだけじゃん
再配置の関数に渡したアドレスがどっかのフィールドに残ってんじゃね？

>>280
>>184にそのまま書いてあった
> this->specific->ImageBase + this->standard->EntryPointRVA

>>280 >>282
再配置したらImageBase関係ないんで再配置先のアドレスでよろ

こうであろう

uint32_t PEParser::get_EntryPoint() {
if(!data)return 0;
if(!address) return specific->ImageBase+standard->EntryPointRVA;
return address+standard->EntryPointRVA:
}

あとスレはお前の顔なんだから好き勝手言ってる奴に警告くらいスレや＞ひげ

>>284
糞みたいなコードをコピペしてる暇がおありでしたら、
目上の人間に対する言葉遣いでも勉強した方がよろしいかと。

>>283
おおっと、配置先のベースアドレスと言うつもりでトチ狂って
何か寝ぼけた事を言ってしまった。面目ない。

みなさんありがとうございます。
今日は本業がトラブル続きのため明日以降にきちんと読んで検証してお返事させていただきます。

もちろん失礼な書き込みは無視しますので悪しからず。
確実に返答が欲しい場合はシベリアでお願いします。

トラブルひと段落。
ttp://d.hatena.ne.jp/higepon/20061206/1165416970


dword/word/byteを使うのをやめようと思うんですけど賛成・反対などありましたらぜひ。

>>284さん
来た!来ました。ありがとうございます。
近くまで肉薄していたのに悔しいなぁ。
どのような経緯でその結論に至ったのでしょうか。
僕は、relocate するときはImageBaseが信用ならないことから、違うBaseAddressがあるのだろう。
それは address + ImageBaseかな？みたいなところではまっていたんですが。

「好き勝手いっている奴」の件ですが
コードを書く人が一番偉いと思っているので、もし不愉快な書き込みを見かけたら皆でスルーすれば良いのではないでしょうか。

不愉快になった人が弱い立場であったり僕に助けを求めるのであれば助けます。

やっぱネギトロマヨネーズ、これでしょ。

誤爆

あ？

い？

>>290
スルーとか逝っちゃってるような奴に教えることはできないなぁ。
他人に攻撃が集中すれば自分への攻撃が減るから好都合なんだろうけどさ。

>>284さん
そんな意図はありませんよ＜好都合


monapiのdllmainは呼べるようになりました。
monalibcの方が呼ぶと落ちてしまうので調べ中。

>>296

過失

2 法律用語
�@私法上、一定の事実を認識することができるはずなのに、不注意で認識しないこと。
�A刑法上、行為者が不注意によって犯罪事実の発生を防止しなかった落ち度のある態度。

>>297

気違い・気狂い

１ 精神状態が普通でなく、正常ではない言動をすること。気が狂うこと。

>>298

ヒロポン

〔補説〕 (和製) Philopon
覚醒剤、塩酸メタンフェタミンの商標名。法律により製造・所持・使用が禁止されている。

今だ！三百ｹﾞｯﾄｫｵ
￣￣￣￣￣∨￣￣￣　　　　　　　(´´
　　　　 ∧∧　　　)　　　　　　(´⌒(´
　　⊂（ﾟДﾟ⊂⌒｀つ≡≡≡(´⌒;;;≡≡≡
　　　　　　 ￣￣　 (´⌒(´⌒;;
　　　　　　ｽﾞｻﾞｰｰｰｰｰｯ

>>290
uint32_t* target = (uint32_t*)&image[page_addr + offset];
*target -= this->specific->ImageBase;
*target += address;
∴X' = X - ImageBase + address
　↓
X = get_EntryPoint() = ImageBase + EntryPointRVA;
X' = (ImageBase + EntryPointRVA) - ImageBase + address
∴X' = EntryPoinyRVA + address

>>301さん
良く考えたのですが分かりませんでした。
もし御面倒でなければ詳しく教えていただけないでしょうか。

>>302
最初の3行はコード
それ以降は中学レベルの算数
・帰納→演繹

>>297
指摘されたのだから過失にはならない
未必の故意だ
考えてないとか意図してないとかで逃げられたら誰も逮捕されねーよ＞卑下

＆が文字化けしている
X'の定義が不明確

きのうえんえき以前の問題では？

>>305
> ＆が文字化けしている
環境は？

> X'の定義が不明確
コード見れば分かるだろ？

uint32_t* target = (uint32_t*)&image[page_addr + offset];
(1)
*target -= this->specific->ImageBase;
*target += address;
(2)

(1)のときの*targetがXで(2)のときの*targetがX'
あとは関係を方程式にして中学レベルの代入をして同類項を整理しただけ

質問のときはどう考えてどこが分からないか書くのが常識。
どこが分からないか書いたから、>>305の方が太郎より上だな。

relocate後のアドレス = relocate前のアドレス - ImageBase + address
であるという事実から以下を類推ということですね。理解できました。
relocate後のentrypoint = relocate前のentrypoint - ImageBase + address
                       = (ImageBase + EntryPointRVA) - ImageBase + address
                       = EntryPointRVA + address

ありがとうございます。

すみません、質問です。
MacOSX(10.3.9)でmonaosのアプリは開発できますか？

>>309さん
公式にはサポートしていないのですが、もしかしたらYumeさんが知っているかも。
どうでしょう＞Yumeさん

>>309
MinGWとMonoをインストールすればいけたはず。
詳しくは此処を。

http://wiki.monaos.org/pukiwiki.php?Mac%20OS%20X%A4%C7mona%A4%F2%A5%D3%A5%EB%A5%C9

そういえばこんなイベントがあるわけですが。
ttp://mitou.mysite.ddo.jp/modules/eguide/event.php?eid=33

聞きたいのがばらけとるなあ…一日張りつけないのに。

夢さんありがとうございます。

>312さん
資料を今作ってます＞＜

まずMinGWのインストールでつまづく・・・。
誰か漏れのiBookG4をThinkPadと交換してくれーーーー。

PE Parserのバグも修正できていろいろ解決した予感。
ふぅ。

落ち着いたら年内にリリースしましょうか．

iBookにvinelinuxを入れました。
これでなんとかいけるかも……。

>>316さん
おお。お疲れさまです．

>>315
> PE Parserのバグ
おいおい。対策済みの問題をスルーしてバグ呼ばわりねぇ。

[[議論/標準入出力/ストリームによる実装/07.MONALIBC.DLLのリンクがうまくいかない]]
> import table 2つ以上あるとおかしくなる？
> →当たり。libcが参照している MonAPI::Stream OutStreamあたりをコメントアウトすると import table が1つになり動く。
これって>>154で実験してたauto-importだよね。

↓何これ？ｗ
[[Mona/パッチ]]
> auto-import対応
あーあ、やっちゃったねぇ。ｗｗｗ

あと素朴な疑問。
何で自分でブックマークしてる仕様書の日本語訳を見ないの？
ttp://b.hatena.ne.jp/higepon/ABI/
> PE format

お昼休みに見てみたら鋭いツッコミが！

>>318さん
ごめんなさい。
branches/mona-stdioで作業していて、trunkへの変更に全く気付きませんでした．
import lookup table を参照すべきという答えに自力でたどり着けたのでまあ得たものがゼロではないのですがまずいっすね。

日本語訳は見てなかったです。ローカルに落として見ていたので日本語訳の存在をすっかり忘れていました．

>>319
> trunkへの変更に全く気付きませんでした
そもそもパッチに一切コメントしていないのがまずいよね。
しかもその後別のパッチでそのページで反応してるわけだから
ページを見ていなかったという言い訳もできない。

> import lookup table を参照すべきという答えに自力でたどり着けたので
動いたからOKというのは見方が浅すぎ。
auto-importというキーワードでつながっていることが見抜けなかったのが大問題。

・パッチが出て、>>154でauto-importの確認をしておきながら、
　両者の関連性を見落としていた。
・OutStreamが典型的なauto-importだということに気付けなかった。

ただ、同じことを二人が修正するってのは珍しいよね。
良い機会だからパッチを徹底的に比較してここでレポートすれば良いかと。

ついでに言えば、こういう細かい所に目を行き届かせるための心構えは、
>>63で指摘されている配慮ともつながっている。
>>63を何度も読んで猛反省してスレでの対応を改めてみれば、
今まで見落としていたものに気付くだろう。
>>290みたいに屁理屈をこねていたら自分の殻を破れないぞ。

>>318
ABI、ってまた無茶なエントリをｗｗｗ
そんなに大雑把でいいのかｗ
それとも実はアルファバイナリアンなんちゃらとかそういう造語か。

>>320
ちょｗｗあんたそんな言い方したらまた泥沼ｗｗｗ

まあ太郎は自分の技術がある種の人気に育てられているのをよく自覚して
スカっと爽やかに猛省するように！
わざとヘタをやって>>320みたいなのを煽ってんならなかなかの大物だがｗ

>>320
パッチとその周辺のコメントを見てみたけどその時点でPEの知識がなかったらわからないでしょw

むしろ自力解決したことをほめてやれ
ほめる8割
反省点2割

で育てないと

貶しても伸びないってのは賛成だな
お互い言いかたを考えろってことでFA

つーかお前らなんでこの時間に書き込んでんだよ！
ニートか不良学生か！そういう俺はプロのサボタージャーだが！

>>320
言い過ぎじゃw

>>320 って
口調、詳しさから言って恥膿ﾀﾝ？
名乗れば良いのに
違ったらごめん

> そもそもパッチに一切コメントしていないのがまずいよね。
>しかもその後別のパッチでそのページで反応してるわけだから
>ページを見ていなかったという言い訳もできない。
ページは見ていますが該当のパッチは記憶にないです。見たけど頭には入らなかったのかもしれないです。
気を付けます。

> 動いたからOKというのは見方が浅すぎ。
> auto-importというキーワードでつながっていることが見抜けなかったのが大問題。
動いたからOKではなくて、なぜ動かなくなったか、動かすためにはどうしたら良いかが分かったからOKだと思っています。
auto-importとの関連には気付きませんでした。
なぜ気付かないかと言われれば頭が悪いからかなあ

> ただ、同じことを二人が修正するってのは珍しいよね。
> 良い機会だからパッチを徹底的に比較してここでレポートすれば良いかと。

diff -EbwBu core/pe_server/PEParser.cpp ~/mona/core/pe_server/PEParser.cpp

違いを見てみました。変数名等意味的に同じものをのぞくと以下のような違いがありました．ほとんど違いはないです。
// Tinoさんは丁寧にエラーチェックしている
-   if (addr1 == 0 || addr2 == 0) return false;

// Tinoさんのコードでは imageSizeを越えるかどうかのチェックはなくなった
// 確かにテーブル終端はNULLと決まっているのでそれで良い気がする
-   for (;; addr1 += 4, addr2 += 4)
+   for (; addr < this->imageSize; addr += 4, lookupAddrr += 4)

> ついでに言えば、こういう細かい所に目を行き届かせるための心構えは、

今回の件はパッチを見逃していた自分が悪いので言い訳はしません。ごめんなさい。

UPPER.EXEが途中で死ぬなぁ。
どうやらStreamっぽい。調査中。

>>328
> Tinoさんのコードでは imageSizeを越えるかどうかのチェックはなくなった
↓これは何？
if (addr1 >= this->imageSize || addr2 >= this->imageSize) return false;

>>330さん
おっと。失礼しました。

Tino様復帰?

>>332
井上七誌で乙
自分に様付けかよｗｗｗ

悲しいね　悲しいね　悲しいね
争うばかりじゃ　悲しいね・・・

>>327
どうかな、この辺の知識持ってる奴って意外といるから。
最近一部でBin2.0も大流行だし。

まあ仮に本人だとしても。
いちいち野暮を言うんじゃねえｗｗスルーカが足りねえぞｗｗｗ

コメントをよく見るとなにげに湾岸がパッチの目的を見抜いてるな

>>336
はいはい湾岸お疲れ
湾岸がなきついてTinoがパッチ作ったってだけ

パッチ作れない湾岸は帰れ

>>335
井上は太郎を溺愛してるからなｗ
精一杯頑張ってもツンデレがやっとだろｗｗｗ

キモヲタにツンデレされても気色悪いだけ・・・

今は太郎がひたすらがんばっている時期
コミュニケーションを濃密にとるよりも
・適切で手短なアドバイス
・かぶらない分野での実用化に向けたコード

が喜ばれるのではないかな
サウンドカードドライバとか。

>>340
サウンドは辻氏と被るかと。

最近淡々と進んでいて見ていて気持ちよいよね
また一皮むけたんじゃない？

>>341
最近進んでいない

>>342
オプソマガ読んだ？

>>344
立ち読みした

ぼくは立ちしょんべん

>>345
マジしびれちゃうよね♥

>>346
マジしびれちゃうよね♥

>>347
お世辞はいいから、寄付でもしてやれよ。
1000人が1万円ずつ出し合えば1年は暮らせる。

>>347
マジしびれちゃうよね♥

>>349
レスはいいから、寄付でもしてやれよ。
1人が1000万円出せば1年は暮らせる。

>>349
親方日の丸なんだから似たようなもんだろｗｗｗ

>>351
マジレスすると、1000万円も出したら俺が暮らせなくなる。

>>353
そこで俺俺ですよ

>>353
その程度の財力で太郎のパトロンが務まるわけがない

　　. ∩＿∩ ;
　　; | ノ|||||||ヽ `
　,　/　●　●|
　;, |＼( _●)/　ミ　俺だよ俺だよ
;　彡､| |∪| |､＼ ,　　　　　ちょっとｸﾏっててさ
　./　　ヽ／>　) :
(＿ﾆﾆ>/　(／ ;
;　　|　　　| ;
'　　＼ヽ/ / :
,　　／／＼＼ .
;　　し’　'`|　|　;

予言しておく

太郎は未踏が終われば作家に転進して直木賞
知識人として名を馳せテレビにも引っ張りだこ
その知名度を生かし石原や田中みたいに政界進出
最後に総理にまで上り詰めるお人だよ

うーん。
monapi_impl.cppのuser_start_implで
    bool dll = isInDLL(__CTOR_LIST__);
    if (dll) invokeFuncList(__CTOR_LIST__);
していて、
monapi.cppの
user_start
    setConstructorList(__CTOR_LIST__);
    invokeFuncList(__CTOR_LIST__);

としているんだけど、違いがよくわからないなぁ。
このあたりの初期化の順序にいまの不具合のヒントがあるきがする

OSMそんなに良かったの?
内容教えて

>>358
$ echo "#include<stdio.h>">a.c
$ echo 'extern void *__CTOR_LIST__[];'>>a.c
$ cp a.c b.c
$ echo 'extern void test();'>>a.c
$ echo 'int main(){printf("main:%p\n",__CTOR_LIST__);test();return 0;}'>>a.c
$ echo 'void test(){printf("test:%p\n",__CTOR_LIST__);}'>>b.c
$ gcc -o 1 a.c b.c
$ gcc -shared -o b.dll b.c
$ gcc -o 2 a.c b.dll
$ ./1
main:0x4013d0
test:0x4013d0
$ ./2
main:0x4013b8
test:0x10001410

1. DLLのエントリポイントは汎用にして独自の処理を入れない
2. DLL用のCRTを用意してDLLの生成時にリンクしてエントリポイントにする
3. DLL用のCRTでは__CTOR_LIST__の処理だけをする
4. 初期化が必要なDLLは初期化クラス等で対応する
※何度呼ばれても初回しか処理しないようにする
static bool Foo_initialized=false;
void FooInit(){
　if(Foo_initialized)return;
　Foo_initialized=true;
　// 初期化処理
}
static struct FooInitWrapper{Init(){FooInit();}} Foo_initializer;
5. 静的リンクとの互換性のためDLL間の初期化処理の依存関係は自前解決する
※このため初回しか処理しないことを保証する必要がある
static bool Bar_initialized=false;
void BarInit(){
　if(Bar_initialized)return;
　Bar_initialized=true;
// 依存関係解決
FooInit();
// 初期化処理
}

>>361の訂正
誤：static struct FooInitWrapper{Init(){FooInit();}} Foo_initializer;
正：static struct FooInitWrapper{FooInitWrapper(){FooInit();}} Foo_initializer;

>>360さん
ありがとうございます。
DLLのエントリポイントで__CTOR_LIST__の処理だけをするというのは、staticリンクとDLLのときで初期化処理を共通化するためですね。

実験したところうまくいきそうなのですが、ひとつだけ問題があって
__CTOR_LIST__の処理の前に monapi のメモリ初期化だけは先にやらないとまずそうです。
初期化リストの中からどこかで new が呼ばれているためだと思われます。

そういえば構造体を利用した初期化の方法はC++の仕様を利用していて素晴らしいと思いました。

もしgcc依存でよいならば__attribute__((constructor))でも同じ効果が得られそうですね。

どちらが良いのかなあ。１

>>360さん
頂いたアドバイスを元に以下のように書いてみました。
http://d.hatena.ne.jp/higepon/20061221/1166714970

今までうまく動いていなかったものがきちんと動くようになりました。
ただひとつ問題があって monalibc_initialize でStream を初期化してしまうと MONAPI.DLL + MONALIBC.DLLをリンクしている contrib/misc/helloworldなども死ぬようになってしまいます。

どこかのシーケンスで何かを見落としているのだと思うのですがもしお気付きの点があれば御教授頂けると助かります．

>>363
> __CTOR_LIST__の処理の前に monapi のメモリ初期化だけは先にやらないとまずそうです。
→初期化処理の依存関係は自前解決する

static bool malloc_initialized=false;

void *mallloc(size_t size){
　if(!malloc_initialized){
　　// メモリ初期化
　　malloc_initialized=true;
　}
　// mallocの処理
}

>>366
それは違うんじゃない？

>>367
メモリ初期化はMemoryManagerにアドレス範囲を渡すだけで
BSSのヌルクリアみたいなフェーズじゃないYO!

そうじゃなくて初期化が一ヶ所にないし、処理が無駄じゃない

>>369
初期化は一行呼び出すだけだYO!
monapi_initialize_memory(64 * 1024 * 1024);

一行でもあちこちにあると無駄無駄無駄ァ〜ってことかな？
確かに即値だし分散するのは良くない。
でもそれは外野が言わなくても本人が調整できることじゃないかな。
漏れは回避方法を示しただけなんで後はお任せ〜。

>>366さん
ありがとうございます。
確かにそのような方法でStreamを初期化していてありだとは思うのですが
あとから初期化処理を追ったときに見通しが悪くなるのが気になっていて
メモリの初期化はとりあえず今の方法で行こうと思います。

>>364
attributeはバイナリアンかぶれっぽくていやらしい
初心者にOSの根幹部分は特殊な処理をしないといけないという印象を持たせるのは×

>>371
> あとから初期化処理を追ったときに見通しが悪くなるのが
それを言うか！
dllmainとか__CTOR_LIST__の挙動を理解しないと追えないんで
今のままでも部外者には充分過ぎるほど見通し悪いよ
だからcrtは共通化して存在を隠す方がましだと思った

>>365
方針については好みなら干渉しないけど試行錯誤の混乱を引きずってる感じ
もうちょっと整理できるよね

[monapi.cpp]
extern "C" int user_start()
{
　monapi_initialize(); ←即値指定やチェックが重複しているのであちら持ちにさせる
　invokeFuncList(__CTOR_LIST__, __FILE__, __LINE__);
　int result = user_start_c_impl(main);
　invokeFuncList(__DTOR_LIST__, __FILE__, __LINE__);
　return result;
}

[monapi_impl.cpp]
extern "C" int dllmain()
{
　monapi_initialize(); ←monapi.cppに同じ
　invokeFuncList(__CTOR_LIST__, __FILE__, __LINE__);
　return 1; ←成功時にTRUEを返すのがWindowsの流儀
// 本当はもっと仕様が違って終了処理もするんだけど（合わせる必要もないが）
　// 詳しくは → ttp://www.h4.dion.ne.jp/~fht/htmkdll/#6
　// 終了処理もするならラッパーは属性より構造体の方が対にできて良い感じ
}
extern "C" __attribute__((constructor)) void monapi_initialize()
{
　if (monapi_initialized) return;
　monapi_initialized = true;
　monapi_initialize_memory(64 * 1024 * 1024); ←処理を一箇所に集約する
}

[monalibc/crt/dllmain.cpp]
extern "C" int dllmain()
↑これ共通だからmonapi.oみたいにdllcrt.oに分離して隠蔽するべき
>>361
> 1. DLLのエントリポイントは汎用にして独自の処理を入れない
> 2. DLL用のCRTを用意してDLLの生成時にリンクしてエントリポイントにする

ついでにmonapi.oもcrt.oとかに変えた方がいいかもしれない

extern "C" __attribute__((constructor)) void monalibc_initialize()
{
　if (monalibc_initialized) return;
　monalibc_initialized = true; ←何かの拍子に再帰呼び出しされるとハマるから前に持って来る
　monapi_initialize();
　init_stdio();
}

再帰対策について>>361では意図的にそうやっている
> if(Bar_initialized)return;
> Bar_initialized=true;

DllMain()で初期化と終了処理を兼ねさせるなら
動的生成ブートストラップがこんな感じになるかな？
（テキトーなんでWindowsの仕様に合わせてはいない）
いずれにせよこれやらないとDLLのデストラクタが呼ばれない

　push dword 0
　call monapi:dllmain
　add esp,4
　test eax,eax
　jz ERROR
　push dword 0
　call monalibc:dllmain
　add esp,4
　test eax,eax
　jz ERROR
　call user_start
　test eax,eax
　jnz ERROR # DLLと逆なので注意
（続く）

（続き）
　push dword 1
　call monalibc:dllmain # コンストラクタとは逆順で呼ぶ
　add esp,4
　test eax,eax
　jz ERROR
　push dword 1
　call monalibc:dllmain
　add esp,4
　test eax,eax
　jz ERROR
　# 正常終了
　ret
ERROR:
　# エラー処理等
　ret

（続く）

>>376の訂正
訂正
2つ目のcall monalibc:dllmainはmonapi:dllmainの間違い

（続き）
dllmainの例

extern "C" int dllmain(int reason)
{
　switch (reason)
　{
　　case 0: // DLL_PROCESS_ATTACH相当
　　　invokeFuncList(__CTOR_LIST__, __FILE__, __LINE__);
　　　break;
　　case 1: // DLL_PROCESS_DETACH相当
　　　invokeFuncList(__DTOR_LIST__, __FILE__, __LINE__);
　　　break;
　}
　return 1;
}

毒を食らわば皿までって感じｗ

あと大改造してんならついでにちょっとだけ

1. MonAPIの関数名はlibcと分ける
memcpy()はmonapi_memcpy()とかにしてlibc側でのシンボルを空けておく

2. システムコールラッパー専用のライブラリを分離する(SYSCALL.DLLとか）
monacapiみたいなのを作っても共用できて便利

うー、原因不明の発熱で調子悪い
ムカツクばかりの無意義な人生ももう終わりかｗｗｗ

アスペクティブにdllmainに処理を挟むならweakが使えるね
そうすればDLL内で完結した参照だからインポートライブラリ問題もない
見通しすっげー悪いし初心者に優しくもないけどｗｗｗ

>>375-376の補足
今は終了コードを伝える仕組みがないから
エラーは単純に無視しても構わないかな
そうするとブートストラップはかなり簡単になる

push dword 0
call monapi:dllmain
call monalibc:dllmain
pop eax
call user_start
push dword 1
call monalibc:dllmain
call monapi:dllmain
pop eax
ret

これならコードの埋め込みを付け足すだけだから5分で実装できる筈
終了コードの伝達はいずれ必要になるだろうけど今やる必要もない

初心者なんか相手にしてるとOSASKみたいに足を引っ張られるだけじゃないか？

>>381
同意

>>381-382
おいおい、現実を見ろよ
Monaに変な幻想を抱いて手を出そうとするのは初心者だけ
玄人はいちいち酔狂に付き合わない
なのに最近妙に玄人志向だから初心者にもそっぽを向かれてる

ブログ見てたらわかるだろ？
盛り上がるのはMona以外の一般技術論だけ
Monaの実装話に誰も反応しないｗｗｗ

このスレだって能書きだけ垂れてる香具師は多いけど
自分の手を汚して付き合う香具師ほとんどいないじゃん
本人も他人のために手を汚す気は更々ないから仕方ないか

井上さん復活希望

>>383
所詮個人プロジェクトだからそれでいいんジャマイカ

>>385
同意

太郎は自分の信じる道を突き進めば良い
雑魚が寄って来ても邪魔なだけ

>>384
井上パッチがなくても太郎が自力実装できたんだから用済み

>>378
＞memcpy()はmonapi_memcpy()
そんなことするとアプリのソース総書き換えじゃん

>>388
#defineでよくね？

>>388
string.h
#define memcpy monapi_memcpy
または
__inline__ void* memcpy(void *out, const void *in, size_t n){monapi_memcpy(out, in, n);}

>>387
貢献しても捨てられる状況で手を出す気になるかね（呆

>>391
だから用済みっつってんじゃん

J様も用済みか
IMEやネットは結局釣りだったのか？

太郎だけが異常に持ち上げられてj様やら湾岸やら井上は総叩き
この荒れ様を見て誰も手を出す気にはなるまい

>>394
Monaは太郎の個人プロジェクトだっつってんじゃん
変な幻想を抱いて参入したそいつらの負け

>>394
渡辺氏や辻氏みたいに叩かれない人もいる。
叩かれてる奴らは厨だってこと。

- 叩かれない
渡辺氏：御意見番で隙がない。
辻氏：自分の世界に入っていて隙がない。

- 叩かれる
j様：自分の実装を説明できずに公開もしない。
湾岸：中途半端な知識でズレたことしまくり。
井上：無意味な長文で迷惑かけまくり。

叩かれる奴らにはそれなりの落ち度がある。

>>397
昔はj様が異様に持ち上げられて太郎が叩かれてたよな
ちゃねらーなんていい加減なもんだ

キリ番どぞ〜
↓↓↓↓↓↓

j様：自分の実装を説明できずに公開もしない。
↑ハッタリ

湾岸：中途半端な知識でズレたことしまくり。
↑やるだけまし

井上：無意味な長文で迷惑かけまくり。
↑荒らし


湾岸がいちばん高評価になってしまうじゃまいか

>>398
ヒント：本人

今だ！四百ｹﾞｯﾄｫｵ
￣￣￣￣￣∨￣￣￣　　　　　　　(´´
　　　　 ∧∧　　　)　　　　　　(´⌒(´
　　⊂（ﾟДﾟ⊂⌒｀つ≡≡≡(´⌒;;;≡≡≡
　　　　　　 ￣￣　 (´⌒(´⌒;;
　　　　　　ｽﾞｻﾞｰｰｰｰｰｯ

>>402
またかよｗｗｗｗ

湾岸：中途半端な知識でズレたことしまくり。
↑やるだけまし


やっていることを3としたら、ズレたことしまくり・人を不愉快にする・空気読まない・偉そうが-100
よって大幅なマイナス

あと最近は実はBayGUIには手を入れず、はったりアプリで何とかしのいでいる
さらに自分の存在感を示すために、とりあえずいろいろな事に反対するという子供な手法をつかっている。

じゃあL氏やKなんて虫けら以下の存在だな

お。なんだか盛り上がっていますね。
>>372さんのまとめについて

ありがとうございます。明日以降に出来るところは取り込もうと思います。

いろいろ言われていますが、Tinoさんやjunjunさんがまたアクティブになってくれるならば、僕はうれしいけどなあ。
（僕にまだまだ問題があって参加しづらいというのは事実だと思います。）

Monaが個人プロジェクトかどうかについては、個人プロジェクトのままでは勝てないのでどうにかしないとですね。
プログラマとして熟練した人が参加しやすくすることには多少の労力をかけるべきかと思っています。

逆に初心者の方が深く参加できるようになるのは大分後かもしれません。

といいつつも未踏もがんばらないと、GC調査に戻ります。

>>406
湾岸は蚊帳の外かよｗｗｗｗｗｗｗｗｗｗｗｗ

>>406
マジレスすると、自分が覚えた難しいことを素人にもちゃんと説明できなければ、
それをきちんとマスターしたとは言えない。
俺は使えるしもっと詳しい人も沢山いるなんてのは言い訳に過ぎんよ。

>>407
ヒント：紳士協定

>>406
＞多少の労力
認識が甘すぎ
他力本願では人は来ない

お客様は神様です、くらいに自分を犠牲にしても最大の労力を払わないと
＞プログラマとして熟練した人
に三顧の礼を尽くしたとは言えない

相手が玄人か素人で区別するなんて無礼もはなはだしい
何様のつもりか

>>410
湾岸帰れ

玄人か素人でわけるのは当り前
おまえは素人

鬼の首をとったかのような 410 が痛い件について

プロジェクトの方針に口を出している暇があったらコードを書けば良いのに

>>413
君は何か書いたの？

書いてないよ
だから太郎の方針には口を出したりはしない

技術的アドバイスかな
これで察して

>>415
運営技術も技術の一つだと思うけど

>>415
Monaには手を出す魅力もないってこと？

運営技術は

・人に依存する（具体的には主催者・参加者の性格）
・アドバイスが正しいかどうかの検証にとてもコストがかかる

などでよろしくないかと。

例えばAさんから
・このコードの方が速い
と言われれば検証のしようもある。

だけど
・こういう運営の方が「自分は」参加しやすい
・こういう方針の方が絶対良い

なんてのはあまり意味がない

>>416
>>417

まぁそうカッカとなるな。

自分が素人だったのを周りに育ててもらった恩を忘れて玄人気取りかよ

>>420
育てられたとか言っているけど、ほとんどは本人の努力じゃあるまいか
他人に努力は強制できないからね


まぁそうカッカとなるな。

>>421
それだとアドバイスする意味なくね？

>>418
＞・こういう運営の方が「自分は」参加しやすい
こういうことを言う人がいたとして話を聞かないとその人は参加しないよね？

育てたと恩をきせなければよい

>>423
その人の言いかたとその人の価値で決まる

>>424
質問に対して回答があったことに対して
回答者の方から恩を着せるのは非常識だが
恩を忘れるのも非常識だよね

そもそも太郎は恩を忘れてはいない件について

恩を忘れたといいいがかりをつける
そんなことないよ　←いまここ

そんなに気に入らないならスレなんか見なければいいのにと思った。

>>426
ヒント：紳士協定

結論：湾岸がいなくなれば良い

アホ過ぎる、もう太郎にはふれないでおこう

答えられなくなって逃げたかｗ

はいはい、そうですね

>>432
懸命かと
うちもはなれるとします

>>435
だから湾岸は帰れよ

湾岸がくるとつまらなくなる

j様復活希望

>>379
複数のライブラリでそれをやるとstaticリンクのときにmultiple definitionになるので×

>>410
意味不明だ。
そんなのおまいが勝手に作ればいいだけじゃん。

新入り風情が

今はもう充分古参だと思った

>>442
一応お約束のツッコミなんで

そろそろ時効にしてやれよ・・・

>>439
それを言うならdllmain自体がmultiple definitionになるじゃね？

>>418
そうやって避け続けているからいつまで経ってもそっち方面が改善しないかと。
ぶっちゃけ個人プロジェクトと割り切って自分だけ精進すればいいとは思うが。

>>444
んー、でも、当時はその程度じゃびくともしない程の存在感があったよね

>>446
気持ちは分かるが今はそれどころじゃないだろ
なにはともあれ未踏が終わってからだ

未踏が終わって天才認定されたからって安泰じゃないよな。
OSASKやCooSなんて見る影もない。
個人プロジェクトはどこまで行っても個人プロジェクトだよ。

個人プロジェクトでいいんジャマイカ
参加者募集といいつつ配慮もしないのが太郎クオリティ
いちいち突っ込んでも染み付いた性格は直らないよ

>>450
太郎は配慮してないわけじゃない
ただズレてるだけ

湾岸が技術方面で滑りまくってるのと同じで
太郎は運営方面では滑りまくっているだけ

>>447
当時は、ね・・・（遠い目

>>451
つっても、対人技術なんて相手の反応を見て、
顔では笑って心ではアカンベーするような技術だからなぁ。
表と裏のない太郎はある意味貴重な存在ではあるよ。

>>452
だれのこと？

>>449
未踏のテーマはOSASK本体じゃなくてGOだったよね？
GOは湾岸他はりぼて方面の人の役には立ってるし、
Monaの新ADKもGOベースだったかと。

CooSの場合、完全に個人プロジェクトだって言い切って、
オープンソースも意図的に避けていたから、
NWSOSと同じ道を歩むのも仕方ない面はあるかな。

>>454
>>440

>>455
それを言うならschemeなんて誰の役に立つんだ？
schemeにコアなファンが多いからと言ってその層がMonaに取り込めるわけじゃない。
scheme方面に声の大きい人が多いだけで、
開発者人口比で言えばschemeなんてC++の足元にも及ばんよ。

>>457
まあそう言うな。
未踏は太郎個人の直木賞受賞みたいなもんだろ？

それに開発者人口だけ見ればC++なんてJavaの足元にも及ばんが、
Javaを採用したからって偽装派遣でコキ使われてる層が来るわけでもない。

309 名前： ひげぽん ◆zcp/NZpA　 投稿日： 02/07/30 22:54
　　おれは何も出来ない。
　　でもこのスレは好き。
　　だからage

310 名前： ひげぽん ◆zcp/NZpA 投稿日： 02/07/30 22:56
　　スレッドを間違えました。
　　恥ずかしい･･･　　そもそもageてないし。
　　反省して今日はもう寝ます。


311 名前： デフォルトの名無しさん 投稿日： 02/07/31 00:12
　　>>309 ?

312 名前： デフォルトの名無しさん 投稿日： 02/07/31 01:56
　　>>309
　　ｺﾞﾊﾞｸ（・∀・）ﾆﾔﾆﾔ

湾岸帰れ
空気嫁

>>453
コールドリーディングとかそれなりに体系化はされているので、
その気があれば勉強できないわけではないよ。

湾岸と某イベントで少し話した
勘違いしていてキモかった

>>458
＞偽装派遣でコキ使われてる層
これって太郎的には素人に分類されてると思った
バイナリアンレベルの神々以外眼中にないっぽい

>>463
上を見つづける太郎の姿勢は好きだけどな

>>462
2ch
Wiki
日記
をみただけでキモいよ…

313 名前： デフォルトの名無しさん 投稿日： 02/07/31 02:08
　　誤爆じゃなくて自演だろ。（　´_ゝ`）

>>466
湾岸の嫉妬？

 全部完了していると思ってもらって結構です。 -- bayside 2006-11-08 (水) 21:07:29
 了解しました。クリッピングもか。すばらすぃ。 -- ひげぽん 2006-11-08 (水) 21:12:38
 いやいや、ひげぽんのパッチをちょこっと変えて当てただけです・・・。それ以外は特にする予定ないですし・・・。 -- bayside 2006-11-08 (水) 22:59:01

少なくとも素人に優しいことで間違っていることはないよ。
玄人にしか理解できないことは一歩間違えれば内ゲバに直行してしまう。

Bayside 『いろんなソフトウェアを見てきましたけど、この辺は全く統一性がないので、何に変えても一緒じゃないですかね？外から見た人が混乱しないというなら unsigned int とか unsigned char って省略せずに書けばいいと思います。

>>469
内ゲバという単語を使うのはあの人だけだな
そろそろ復活?

>>464
プロジェクト運営でも上を目指せば天下取れるよ。

>>472
NO.1にならなくてもいい♪
もともと特別なOnly one♪

>>473
本人はそうは思ってないみたい
>>406 個人プロジェクトのままでは勝てない

>>474
未踏が終わって余裕が出来たらコールドリーディングとか対人技術を勉強すれば済む話。
単なる技術だから人格関係ないし。

>>473
太郎は既にもう充分なonly oneだよな
でも今の延長線上にNo.1がないことを自覚しないとまずい
No.1にならなくてもいいとは思うけど

>>471
osdev分裂騒動のときにしきりに使われてたような

>>475
それってプロジェクト運営というよりも教祖になる方法じゃね？

119 ：ひげぽん ◆Ngzcp/NZpA ：2006/06/26(月) 23:41:12 発信元:210.197.210.21
　　404でした。
　　大変申し訳ないのですが http://wiki.monaos.orgのどこかに添付していただけませんでしょうか?

120 ：ひげぽん ◆Ngzcp/NZpA ：2006/07/06(木) 21:18:32 発信元:218.218.194.98
　　>118さん
　　Mona Wikiでご意見募集中です。
　　よろしくお願いします。

124 ：いやあ名無しってほんとにいいもんですね ：2006/08/06(日) 20:43:12 発信元:218.218.194.98
　　> 本日 Mona OSプロジェクトはfile_server_on_linux-0.0.1をリリースしました。
　　> download
　　>
　　> https://sourceforge.jp/projects/mona/files/?release_id=21273#21273
　　> 開発者向けリリースです

　　> など多大なメリットが得らています。

>>472
やっぱそうだよな。
そろそろ臭い物に蓋をし続けるのも限界だろ。

>>478
だから？

125 ：いやあ名無しってほんとにいいもんですね ：2006/08/06(日) 20:43:42 発信元:218.218.194.98
　　> 開発の動機
　　>
　　> 次期Mona OSのリリースでサポート予定の仮想メモリの実装に必須であったため。
　　>
　　> 大きな変更点

　　> ひげぽんの個人的な感想
　　>
　　> OSの必須コンポーネントであるファイルシステムがまるごとLinuxで動くようになったのは大きなメリットだと思います。
　　>
　　> おおげさではなく開発効率は10倍くらいになるのではないでしょうか。
　　>
　　> 以前から気になっていたfile_serverのジャングルコードが解消されたのと、VFSについて深い理解が得られたのも個人的にはかなり大きかったと思います。

>>463
エリート意識が鼻に付くよな

>>482
はいはい低学歴乙
実際にエリートなんだから仕方ない

>>477
さっきゅんと湾岸が喧嘩別れしたときモナー

>>407
太郎の中では意図して湾岸を除外したわけではないと思う。
自分の中でどういう扱いをしているかが無意識に出てしまっただけではないかな。

>>409
そんな計算ができるタマではないな。

本人的には他人を巻き込んで天下を取る気はあるのだろう。
だからそんなんじゃダメだって言う奴が出てきても仕方がない。
技術的な勉強だけで天下が取れたら苦労しないわな。

>>478
今でもある意味教祖なんだけど、
集金システムが確立できていないのが弱いかな。

>>479 >>481
今でもスラドJに垂れ込むのは恥ずかしいとか
宣伝に変な自己規制意識があるみたいなんだよな。
そのくせスラド本家に垂れ込んで没になったりとか。
もう少し自分の足元を見た方がいいかも、とは思う。

教祖はまだまだでも神主くらいならいけるんじゃね？

洒落かよｗｗｗ

割れ厨乙
所詮神主は金子の二番煎じだからなぁ

>>491
それを言ったら太郎もLinusの二番煎じかと

ちょｗｗｗ太郎なんかと比べたらLinusに失礼だろｗｗｗ

>>491
割れ厨で思い出したがj様はISOをRAR圧縮するのが好きだったよなぁ

>>494
RARを見て割れ厨とか思う奴が割れ厨

>>494
失礼な、ISOはRAR圧縮がデファクトスタンダード

>>496
だからISOを圧縮するようなシチュエーションって何よ？

>>493
じゃあMatz
Matzくらいなら時間の問題だろ

キリ番どぞ〜 （今度は外すなよ）
↓↓↓↓↓↓

今だ！五百ｹﾞｯﾄｫｵ
￣￣￣￣￣∨￣￣￣　　　　　　　(´´
　　　　 ∧∧　　　)　　　　　　(´⌒(´
　　⊂（ﾟДﾟ⊂⌒｀つ≡≡≡(´⌒;;;≡≡≡
　　　　　　 ￣￣　 (´⌒(´⌒;;
　　　　　　ｽﾞｻﾞｰｰｰｰｰｯ

>>498
ぶっちゃけもうMatzレベルは超えてると思う
太郎にインタプリタは作れるがMatzにカーネルが作れるかっての

カーネル？
いつまで経っても何もできないゴミ同然じゃんｗｗｗ

>>502
じゃあお前が作ってみろよ

>>503
太郎が費やしたのと同じ時間と労力を費やせば小学生でも作れるわｗ
そんなもんより子供でも作った方がいいだろｗｗｗ

北斗壊骨拳で氏ね

>>504
認知しなくていいならいくらでも作ってやるよ

>>505
そっちはColonel（大佐）
太郎のはKernel（核）

>>507
発音まったく同じ

誰一人としてまともに関わろうとしていないのがMonaの位置を物語っている。

>>426
親から受けた恩は子供に返すものだよ。
親から受けた恨みまで子供に返すのが一般的だが。

>>493
Linuxは1991年に開発が開始され、1995年頃にはBSDを追い越している。
Monaは2002年に開発が開始され、2006年現在実用性の片鱗すらない。
まったく比較にもならない。

Monaの開発は2008年5月までというのが公式設定だった筈

>>510
こういうことか
ttp://ja.wikipedia.org/wiki/%E5%85%90%E7%AB%A5%E8%99%90%E5%BE%85
＞また、虐待を行う親の多くが、自らも虐待を受けた経験がある事が知られている。

太郎をヲチするのは楽しいがMonaに手を出す気にはならんなぁ

>>512
ｋｗｓｋ

>>512
Part2 140 に５年計画。とあるから 2007/5-6月付近までじゃないか。

>>515
30歳で小説家になるって言ってた

>>516
ちょうど未踏が終わる頃だね

>>406
mona=ひげぽんの等式がある限り個人プロジェクトでしかない。
一国の指導者に置き換えてみればいいかな。
積極的に人材を発掘して対等の後継者として育成しなければ、
革命やクーデターはあっても共同統治や禅譲はありえない。

下手に募集とか勝つとか吹いたりしなければ突っ込まれないのにね、と思う。
もう個人プロジェクトでいいじゃん、みたいな。

>>519
吹いてるってわかってんならいちいち真に受けんなYO!

>>415様のように突っ込みを入れつつマターリとヲチするのが正しい姿勢
下請けに甘んじる覚悟がない奴は貢献とか手を出そうとか考えるな

>>514
みんなそうだよ

結局はあれだ、勝手に妄想を膨らました奴が自滅してるだけ、と。

>>518
実は太郎自身が革命やクーデターを望んでいるような希ガス
もう半分興味なくしてるのに引くに引けない状況だからな

そこで内ゲバですよ

このスレやけに左寄りだよな

左寄りどころか極左じゃね?

議論を内ゲバに置き換えてみればわかりやすいかと

カバラで占ってみた

1978.5.16 誕生数１

誕生数１の人はたくましい人生を開拓していく強い意志を持っており、情熱的で勇ましく、男性的。
自信家で自己に対して絶大の信頼と誇りを抱いています。

長所： 情熱的、意志力が強い、外向的、正義感が強い。
短所： 誇大妄想的、高慢、短気、頑固。

使命
あらゆる分野の創始者、指導者になる事である。
政界、学会、芸能、どんな世界にしろそこでリーダーとして他の人たちを導く使命にある。

代表人物
植木等/明石家さんま/羽賀研二/福沢諭吉/西郷隆盛/今井美樹/山瀬まみ/
ナポレオン/ウォルト・ディズニー/ヘンリー・フォード/チャップリン/トルストイ/など

>>529さん
もう一才上です

>>512さん
少なくともあと５年くらいはやるつもりです。
実際問題ここ半年くらいでMonaを今まで以上に真剣にやろうと決意しました。
なのでいろいろと深追いしています。

例えばですが、GUIに1-2年かけても良いくらいのスケジュール感です。

>>530
あんた、サバ読んでたなｗ

17 名前： ひげぽん 投稿日： 02/06/19 00:03
　24才です。もしや年齢制限あり？

お口直し

1977.5.16 誕生数９

誕生数９の人は複雑な性格で、焦点が定めにくい特徴を持つ。
男性は女性的、女性は男性的である。本心を隠し芝居を演じる事ができる。

長所： 自己犠牲的、奉仕的、包容力がある。
短所： 複雑、分裂的、利己主義。

使命
人類愛を実践する使命にある。世の革命者であるが、過激な手段に訴える事なく、地味で温和な運動を続ける。

代表人物
伊武雅刀/本木雅弘/風間トオル/谷村新司/菊池寛/工藤夕貴/かとうかずこ/美空ひばり/
マハトマ・ガンジー/シュバイツァー(医師)など

＞本心を隠し芝居
なるほど、当たってるわｗ

うそつき

太郎の取り巻きは自作自演というのが定説

>>531さん
そのころはまだ本当の事を書くのが恐かったころですねーw

>あらゆる分野の創始者、指導者になる事である。

創始者ｶｺｲｲ

二番煎じが創始者ねぇ・・・

自作自演にしても恥ずかしくないのかね

342 名前： Be名無しさん 投稿日： 2006/12/20(水) 00:22:03
　最近淡々と進んでいて見ていて気持ちよいよね
　また一皮むけたんじゃない？

太郎ももう29か

>>530
小説家はどうすんの？

弟が18ってかなり離れてるね

太郎（年収1500万円）は超美人嫁と10万円の超豪華セレブクリスマスディナー
漏れ（年収150万円）は一人で洒落で拾った裏でオ○ニー

>>481
＞仮想メモリの実装に必須
はぁ？スワップにFSなんか必要ねーだろ

美人嫁とスワップきぼんぬ

おまいら美人美人って騒ぎすぎなんだよ
そのせいで今年はOSCに連れて来なかったじゃんか
逝って損した

>>543
おまえ滑っているよ。湾岸?

はい。湾岸です。
嫉妬しています。

湾岸ｷﾀｰ

湾岸の本音
・俺はGUIを作った。Tinoより上だ
→GUIサーバーはそのまま流用、仕様はAWTを微妙に劣化。クリッピングもしない
・俺はGUIを作った。ひげぽんと同じくらいすごい
→本当？
・俺はBayOSを作った。ひげぽんと同じくらいすごい
→はりぼてじゃない？
・俺はOSCに参加したりと超貢献している
→貢献リストを作ってみ?
・俺は有名になるべき男だ
→そうですね（ﾌﾟ

お、スレが伸びてるじゃん
昔の殺伐とした雰囲気に戻って良い感じ
やっぱモナスレはこうじゃなくちゃね！

DLLの変数のアドレスがEXE側から見たらずれる・・・そんな気もした。

>>551
それは auto import ではあるまいか

なんかみんなPEに詳しくなってるしｗ

>>553
理想の形だね

雨降って地固まる・・・か
いい話や（泣

それはともかく
太郎パッチと井上パッチの両方で動かして
どっちで正常に動くかで実力が測れるんじゃね？
ついに太郎が井上を倒す日が来た！？

テストプログラムをtrunkとbranchの両方で動かしてみれば良いかと

- a.c
#include <stdio.h>
extern int a;
extern void aa();
int main(){
　printf("%x\n",&a);
　aa();
　return 0;
}

- b.c
#include <stdio.h>
int a;
void aa(){printf("%x\n",&a);}

cygwinでやってみたらこうなった

$ gcc -shared -o b.dll b.c
$ gcc a.c b.dll
Info: resolving _a by linking to __imp__a (auto-import)
$ ./a
10003100
10003100

monaでのテストは環境ないので誰か頼んだ

snvで取って来てmakeしてるんだけど
trunkはuint*_t周りでエラー出まくりだし
branches/mona-stdioはmakeできるけどerrormapとか言って起動しない
中の人じゃないと手が出ないねこれは

>>558
qemuの起動オプションを-cdrom mona.iso -fda mona.img -boot dにすればよろしかと

trunkの方は適当にtypedefを追加してコンパイル通した
とりあえず起動する

テストプログラムを作る方法もよくわからないなぁ
どうやってサンプル作って実験してんだろ
contrib/Misc/helloworldを直に書き換えてみるか

リンクするためにまずDLL作らなきゃいけない

- b.c
extern void printf(const char *format, ...);
int a;
void aa(){printf("%x\n",&a);}

こんなのをでっち上げてB.DLLを作る

$ gcc -mno-cygwin -nostdlib -nostdinc -fno-builtin -shared -o B.DLL b.c \
-L../../../mona/lib -lmonapi-imp

>>559
qemuよくわかんないんでvpc使ってるんだけど・・・

main.cppをでっち上げる

#include <monapi.h>
extern int a;
extern "C" void aa();
int MonaMain(List<char*>* pekoe){
printf("%x\n",&a);
aa();
return 0;
}

MakefileにADDLINK=B.DLLを付け足す
これでHELLO.EXEができた

HELLO.EXEとB.DLLを入れたISOを作って起動させた
[Mona]/APPS> hello
PE Server: Linking MONAPI.DLL to HELLO.EXE....OK
PE Server: Linking B.DLL to HELLO.EXE....OK
PE Server: Linking MONAPI.DLL to B.DLL....OK
0xA0019600
0xA0019600

trunkは問題ないみたい

>>561
とりあえずフロッピーのイメージも一緒にして起動させてやらなきゃなんない。
結構懐かしいバグな気がする。

>>563
了解
起動したYO!

さっきのHELLO.EXEとB.DLLをコピーしてみると

[Mona]/APPS> hello
link error _Z14invokeFuncListPPFvvE
NG

あちゃ、trunkとbranchでバイナリ互換性がないな
再コンパイルか・・・

太郎お大事に

再コンパイルしてみるがエラー
MonaMain()やめてmain()にしたのね
直すとコンパイルはOK

[Mona]/APPS> hello
access denied.address = 0x00000000 Process HELLO.EXE killed eip=0xA0004B36

いきなり死ぬなー

b.cに何もしないエントリポイント追加して作り直し
int dllmain(){return 1;}
$ gcc -mno-cygwin -nostdlib -nostdinc -fno-builtin -Wl,--entry=dllmain \
-shared -o B.DLL b.c -L../../../mona-stdio/lib -lmonapi-imp

[Mona]/APPS> hello
0xA10
0xA10

なんじゃこりゃ
結果がわかんね('A`)

>>566
printf使うと数値表示がぶっ壊れるときがあるっぽい。
_printfなら大丈夫かも。

printf()は未完成の標準出力を通してるからおかしくなるっぽい
_printf()なんてのがあるからそっちを使って書き換え

[Mona]/APPS> hello
0xA001D800
0xA001D800

やっぱりズレてない
とゆーわけでこの勝負引き分け・・・

>>567
あ、かぶった
ずれてないYO!

>>568
ありがとう。
じゃあmonalibcがおかしいな。
asm(".section .drectve");
asm(".ascii ¥"-export:__sF¥"");
みたいな強引なことしてるからかな？

DLLを２つ用意して、
DLL1の変数をDLL2から参照する場合を試した方が良いかも。

>>570
それ削っても普通にauto-importできたんだけど・・・

monalibc側からasmを削って替わりにこんなのを入れる
FILE *get_sF(){return __sF;}

- main.cpp
#include <monapi.h>
#include <monalibc/stdio.h>
extern FILE __sF[3];
extern "C" FILE *get_sF();
int main(int argc, char** argv[]){
_printf("%x\n",__sF);
_printf("%x\n",get_sF());
return 0;
}

実行結果（ズレていない）
0xA000A480
0xA000A480

>>571
その前に同じことを夢様の側で試してもらわないと話が進まないかと

夢様に質問

1. >>568でやったような簡単なB.DLLのauto-importはうまくいきますか？
2. >>572でやったような__sFのauto-importはうまくいきますか？

この辺が違う結果だと調べようがないよ('A`)

つかMonaぐちゃぐちゃだな
これ上級者とか慣れとかそういう次元じゃないぞ
いじってて発狂しそうだ
初心者でもわかるくらいの過剰な配慮してやっと並くらいになるんじゃね？('A`)

>>573
1の方のauto-importはウマくいくけど、__sFがウマくいかない。binutilsのバージョン関係あるかな？

>>575
＞binutilsのバージョン関係あるかな？
めちゃめちゃあると思う

cygwinのはこんなかんじ

$ ld --version
GNU ld version 2.17.50 20060817

>>576
こっちGNU ld version 2.16だ。バージョンうpしてくる。

>>574
開発中のものを触ってぐちゃぐちゃと言うのは可哀想
リリース版じゃないのでしょ

>>578
開発中で流動的な部分があるのは当たり前なんだけど
行き当たりばったりでだらだら弄り回してる感じがありあり
こんな調子でやってると問題の切り分けできなくなるYO!

>>574
他で経験あるやつは皆そう思うらしい。気がつかないのはカーネルいじりが
初めての奴だけ（カーネル童貞か...）

いきあたりばったりなのは井上のせい

2.17にしたらすんなりリンク出来て、アドレスも一致した。
俺の今日一日は何だったんだwww

>>582
おつかれー

>>582
おめでと！
もうMonaには懲りたからこれで俺も消えるYO!

>>584
まあそう言わず

>>584
お疲れ
藻前の活躍は素晴らしかった
懲りずに手を出してやれ

>>586
手を出さずに方針に口を出す方が楽しいYO!

>>587
あいつの才能は口出しだけでは伸びないよ分かっている？

>>588
俺は俺のために生きてる

か、かっこいい？か？

>>588
キモヲタ？

またツンデレ？

>>588
まじキモい・・・・

太郎にそういう心を読ませるような技は通じないんだけどなぁ

あいつが求めてるのは参考書的な知識だけ
典型的な受験特化型人間さ

>>594
まわりくどいのは井上の特徴（not 特長）

>>595
阿呆かおまえ

>>595
失礼な
エリート様とお呼び

キリ番どぞ〜
↓↓↓↓↓

>>595
学歴コンプレックス?

はいな。
http://proxy.f3.ymdb.yahoofs.jp/bc/458fde4c_11dcc/bc/f81c/Mona.rar?bcJV.jFBo5aV54J7

CGUI＋2chブラウザ＋日本語IME一式入った.iso。
QEMUから立ち上げたらそのままニュース速報とかに書き込めると思いまつ。

正直まだまだバグとかありますしIMEの完成度も低いですが
（あとメモリを使いすぎたりファイルアクセスが集中するとカーネルがバグるみたいで今あちこちの機能ダウンしてます。）
100%終わるの待ってたら切りがないのでクリスマスって事でもう公開しちゃいます。

>>601
来たーーーーーーーーーーーー

CGUIの起動画面かっこいｲｲｲｲｲｲｲｲｲｲｲｲ

ニュー速つながった。これMona?
超速いんだけど。GUIが速いのかな。

ソース公開希望！というか、とりこめや＞太郎

alpha4ベースか。
junjunn復活して！

junjunn復活祭！！！！！


Tinoﾀﾝが復活したら超クリスマスプレゼント！

太郎様
j様
Tino様
Gaku様
shadow様
Yume様

並べてみるとすごい面々だな

>>606
何か涙出てきた
そのチームの100%を引き出せたら誰にも負けない気が

>>696
全員カーネル童貞で、モナで筆おろし組…

>>606
猫様を忘れてはいかんよ

>>601
j様乙！！

だが、クリスマスに乗り遅れたせいかダウンできないorz

>>601
junjunnさん
すばらしい！

もし可能ならば成果をとりこみたいです。
どうしたらよいでしょうか。ご指示を頂けると助かります。

意味不明なバグに振り回される俺。
誰か現在のmonalibcテストしてくれないかな？fwriteだけでいいから。

今昼休みなんでやりますよ。
svn up して upperが動けば良いですか？

>>613
とりあえず_logprintfで色々垂れ流してるのでシリアルの方を見て頂きたいです。
あと、失敗する場合はfwriteは何も書こうとはしないです。

upperを動かしたときのログ
write:110
DLL_PROCESS_ATTACH
invokeFuncList:[UPPER.EX5:monapi_impl.cpp:39]address=0xA001CE18
invokeFuncList:outStream=0x00000000, &outStream=0xA002080C, inStream=0x00000000 &inStream=0xA0020808
DLL_PROCESS_ATTACH
invokeFuncList:[UPPER.EX5:crt/dllmain.cpp:19]address=0xA0009518
invokeFuncList:outStream=0x00000000, &outStream=0xA002080C, inStream=0x00000000 &inStream=0xA0020808
monalibc: fp->_flags = 0x00000041
initializeFromHandle initializeFromHandle:284[UPPER.EX5]
this = 0xC0000220, header_=0x90000000
memoryAddress_=0x90000034
memorySize = 0x00000000
initializeFromHandle initializeFromHandle:284[UPPER.EX5]
this = 0xC0000270, header_=0x90011000
memoryAddress_=0x90011034
memorySize = 0x00000000
monalibc: stdin = 0xA000B710
monalibc: stdout= 0xA000B744
monalibc: stderr= 0xA000B778
monalibc: __sF[0]._extra = 0xC00001D8
monalibc: __sF[1]._extra = 0xC00001F0
monalibc: __sF[2]._extra = 0xC0000208
invokeFuncList:[UPPER.EX5:monapi_crt.cpp:22]address=0xA00015D8
invokeFuncList:outStream=0xC0000270, &outStream=0xA002080C, inStream=0xC0000220 &inStream=0xA0020808
upper start*******************************************************************

>>615
もうちょっと先のfwriteが何か言うところが欲しいです。

>>616
monalibc: fp->_flags = 0x00000041
initializeFromHandle initializeFromHandle:284[UPPER.EX5]
this = 0xC0000220, header_=0x90000000
memoryAddress_=0x90000034
memorySize = 0x00000000
initializeFromHandle initializeFromHandle:284[UPPER.EX5]
this = 0xC0000270, header_=0x90011000
memoryAddress_=0x90011034
memorySize = 0x00000000
monalibc: stdin = 0xA000B710
monalibc: stdout= 0xA000B744
monalibc: stderr= 0xA000B778
monalibc: __sF[0]._extra = 0xC00001D8
monalibc: __sF[1]._extra = 0xC00001F0
monalibc: __sF[2]._extra = 0xC0000208
invokeFuncList:[UPPER.EX5:monapi_crt.cpp:22]address=0xA0001448
invokeFuncList:outStream=0xC0000270, &outStream=0xA002080C, inStream=0xC0000220 &inStream=0xA0020808
monalibc: fwrite
monalibc: stream = 0xA000B710
monalibc: stream->_flags = 0x00000021
monalibc: stream->_extra = 0xC00001D8
monalibc: stream->_extra->stds = 0x00000001
invokeFuncList:[UPPER.EX5:monapi_crt.cpp:25]address=0xA0001450
invokeFuncList:outStream=0xC0000270, &outStream=0xA002080C, inStream=0xC0000220 &inStream=0xA0020808
LIBC DLL_PROCESS_DETACH
invokeFuncList:[UPPER.EX5:crt/dllmain.cpp:23]address=0xA0009528
invokeFuncList:outStream=0xC0000270, &outStream=0xA002080C, inStream=0xC0000220 &inStream=0xA0020808
monalibc: __nc_atexit_caller: 0

>>617
ありがとうございます。
どうやらそちらでもポインタがきちんと渡されていないようです・・・

今は無理ですが帰ってから検証を手伝いたいです。
症状はどんな感じでしょう。
・意図する結果
・今のおかしい結果
とか。

>>619
意図する結果：fwriteに&__sF[1]の値が渡される。
今のおかしい結果:fwriteに&__sF[1]の値ではなく&__sF[0]の値が渡される。

>>620
0d453172c62fe69b3d3c9b24110ded82 *PEParser.diff
begin 644 PEParser.diff.bz2
hEZdcCH3-KGNHKNcE836++9xTU5tkSLzzzr9ZKkezvxxaE+8Qm3O+-d4eODIm
h+4U4U++4U1E+DI+1FGbao3HMYAbW+E4HmU1+2+owcMCON4EmM6OA7UXHFcl+
homN4++673-B0N-dA8byYdyYp44aWMXl-4pAOB-duGnKlAMao5LpbotjPcwMS
hDjb3ggNX5bYd7DzxogdAfVxLCUYPIA2Wq+bmA67AYKYJHcy7u5mAUZ8VPZaW
hb8W34q+16JZ+Fe8LvBMs8bUwxEsaWBZUnH0iMQXlQf-VJG64fVQY0p-XFiT0
hBQImKWtX7dqH1XqFHlyIg6cqQKanRt7N6mSiu2gNkYooKwlUUVc4cE4E+bPQ
hibyxw9zr7KMZcm-E6YUOhvKPpYT7Gu2mEvrJ55L1AUm-oE0o4XdLJoNkwna4
hc91W1Fmofa2WNJp-zUJEpHFCyigFJYPbJd2C4GiVThQYNJ+Uk-JMrk5uwPBg
h72X+76C30MRSzU860nIQUVqKvtfqd6oHVWKPri6fqQssC22qWLUaXSUws2kz
hUCmtcikKZInRZ4gwUKCdEkfd+BG+2a0Y2COGBOkWDMT42AN99-QR-1eIgnPC
hsehxdvlVSmOlKcca5PuyHVRyFext3CDkDRp2n3DiEKfvK5CUqOMEN-IOkZFx
hdGIOSyu80tp9wBO1Aqw2ARADj6lHaOGcDMfUrPBWniSIvA1OemqagFRi1l9D
hlDdgGes6NasRWBgWGsP91VB8SdH9vz0cFJfjMooVcc4p5vJop4wp5UVR58aX
hs0oK9wwggdI4dJMNiAMD0AMitC8KZkaP8ZEwwWpG923QevmoB0vr2q4mlb93
h-scN7gWf3rznikstaBuRRo38IV16chb3HcS3rQqRA8dJeKRKOwqJ33Wih11I
Kgzyr0x40KPihjTu3r73C30EaV+cIU+++
+
end

uuencode?

uudecodeしてもだめぽ

>>622
xxe

>>621
うおっ、すげえ。パッチ当てたらちゃんと動くようになった。
ありがとうございます。

>>621さん
おお。すばらしい。ありがとうございます。
Mona/パッチページに追記しました。
パッチの核心部分ですが、同じアドレスが lookup table に出てきたら、以前のアドレスからの差分でずらすという感じでしょうか。
peの資料をあたりましたが該当部分を見つけられず。

+        uint32_t fixup = 0;
+        std::map<uint32_t, uint32_t>::iterator it = this->fixups.find(*lookupPtr);
+        if (it == this->fixups.end())
+            this->fixups.insert(std::pair<uint32_t, uint32_t>(*lookupPtr, addr));
+        else
+            fixup = *ptr - this->specific->ImageBase - it->second;
+
-        *ptr = exp_addr + parser->address;
+        *ptr = exp_addr + parser->address + fixup;


>>夢さん
うまくいっているものをパッチを含めて commit をお願いします。

>>377
でご提案頂いていた、dllmain の引数違いで detach相当を行うというのをやりました。

>>621のパッチで
monalibc:dllmain で inStream/outStream を初期化してもよくなったかもしれないなぁ。
どうだろう。

>>621さんとYumeさんのおかげで年内にリリースできるかもしれないなあ。
ありがとうございます。

junjunnさんの成果も取り込めれば最高なんだけどもどうでしょうか。

>>625
auto-importは独自拡張で地雷

[[gcj/質問箱]]
＞PEではDLLのグローバル変数を直接インポートして参照してはいけません

>>625
commitしました。

>>628さん
A.DLLからB.DLLにあるグローバル変数を、直接インポートしてはいけないという意味でしょうか．
これは、ハマりそうですね。

>>629さん
お疲れさまです。

http://support.microsoft.com/kb/125677/en-us

こんなのみっけた。

＞memcpy()はmonapi_memcpy()とかにしてlibc側でのシンボルを空けておく

これは結構必要だなと思っていて、printf とかもそもそも libc に移動したいですし。
どうでしょう＞Yumeさん
一緒にがーっとやりますか？

>>630
参照先を読まずに質問？？？

[[gcj/質問箱]]
＞*** PEではダメな例 ***
＞【DLL側】
＞int g_foobar = 1;
＞【EXE側】
＞extern int g_foobar;

>>626
↓これを避けた理由は？
>>373 即値指定やチェックが重複しているのであちら持ちにさせる
>>374 処理を一箇所に集約する

【結論】
auto-importはテクニックで避けられるから
梨花に手を入れてまで使うような代物ではない

>>631
それはerrnoのときに懸念してたプロセス間の変数共有を意図的にする方法では・・・

>>633
核心をわざと引用しないのはどうかな
アンフェア

維持側類

タルるートくんに伊知川累って女がいたのを思い出した・・・

最近清水君来なくて寂しいね

(´･ω･`)ｼｮﾎﾞｰﾝ

>>640
名無しでいやがらせ書き込みしているじゃん

清水君はいい奴だよ

>>643
湾岸帰れ

愛されてるなぁ♥

湾岸の書き込みを見るだけで吐き気がする

>>646
勇気を出して言ってみる。
実は俺も好きじゃない。
なんでだろう、いちいち鼻につくんだよな

>>646
俺も昔はそう思ってたけどいい奴だと気付いた

>>647
今はむしろ太郎の方が鼻につく
なんか昔と人格変わったよね

>>648
うーん。そうかな。
湾岸は安定してむかつく

太郎に関しては別に印象変わらないけど
よく我慢していると思うよ

>>648
君が湾岸でないと一応信じるとしても、同意できない。

太郎は人格が安定していて特に変化はしていない
ただ情熱や知識が増えている印象

湾岸はうざいだけ

>>649-650
ふーん、そっかぁ

昔の太郎の少年みたいな純粋さが好きだったんだけど
どうも最近は世間体に縛られてぎすぎすしてる印象

そんな失われた属性を湾岸が持ってる気がするんだよなぁ

純粋さ＝無知
を求めているならば正解かもな

自分は湾岸に何かを教えたり期待するのはやめておくよ
人格がダメだからね

BayGCとかJMonaもしかり。

>>652
彼の場合は無知が純粋にはつながらないような希ガス
知らないものに対して徹底して偏見持ってる
でも嫌々触りながら考えが変わってく節操のなさが人間っぽくて好き

太郎は嫌々とあまり思わなそう
外から観察していて思うけど良くあんなにエネルギーが持つよな

>>654
嫌なことは徹底してスルーしてるんじゃね？
スレでの罵詈雑言とか

罵詈雑言は目に入らないに1票

実は結構ストレスになってるに1票

>>657
だったらむしろ偉いよな

太郎は尊敬するが湾岸は侮蔑する

太郎信者みたいに負けを認めちゃうんじゃなくて
なにくそって対抗するのが湾岸のいいところ
信者はそれが気に入らないから徹底して叩く
信者の支持を失いたくない太郎も黙認する

こんな微妙なバランスで成り立ってんじゃね？

どちらにも信者はいないのではないだろうか。

信者は重要じゃなくて太郎や湾岸がどういう人物かどうか。

「なにくそ」っていう気概はむしろ太郎から感じるよ
湾岸はあきらめるのが早い

>>661
君は自覚していないようだが太郎信者

実は太郎も結構あきらめるのはやい
あきらめたらもう二度とやらない貝になっちゃう癖もある
そういうのが印象に残らないのは君が信者だから

湾岸に信者はいないけど熱心なアンチがいる
取るに足らないつまらない奴だったら無視されて終わりだが
アンチを引き付けるマイナスの魅力を持ってるんだな

>>662
んー。そうか。漏れは信者なのか。
それは違うと思うけどな。

どちらかというと引き気味なんだが

>>663
マイナスの魅力は、結局魅力ではなくて、ただ不快なだけ

>>658
反応はなくてもちゃんと読んで
事実無根でないものには留意するくらいの玉だったら
かなりの大物だとは思う
もしそうならアクティブな人をもっとひきつけてる筈

フィルタリングする習慣があるというのが事実に近いかな
本人は記憶力の問題だと思ってるみたいだけど

>>664
ごめん、別の人と間違えてたみたい

マイナスの魅力は自覚できればプラスにもできる
忙しさに潰されるか一皮むけるか
もうちょっとヲチしてみようと思ってる

>>665
>フィルタリングする習慣があるというのが事実に近いかな
>本人は記憶力の問題だと思ってるみたいだけど
遠まわしにアスペルガーだって言ってないか？ｗ

>>667
医者じゃないからそういうのは遠慮しとくよ

＞マイナスの魅力は自覚できればプラスにもできる
単純な符号逆転ではないよ
それくらいは理解できる人生経験を積んでいる？

一緒に仕事をしている人から聞いたけど湾岸は最悪らしいよ
空気読まない・手柄総取り狙いまくりだそうだ

ここは妄想がすごいスレ

冬だなぁ

>>669
湾岸が珈琲牛乳を開始したときに裏切り呼ばわりされながらも
何人かは動作報告してたのを覚えてるんだよ

湾岸小泉純一郎、蓑輪竹中平蔵説。リーダーに相応しいのは実は湾岸氏で
みのぽんは実務型。

25日にファイルをダウンロードができなかった方はすいません。
YahooブリーフケースのURLは一日？しか持たないの知りませんでした。（´д｀;
最新版は今作ったHP
http://www.geocities.jp/mona_cgui/
に載せておきますのでここからダウンロードしてください。

あと25日に公開したのはクリスマスの為の特別であって
今の時点で私が他にぽこぽこ動く事はないです。


>ひげぽんさんへ
私の考えとしてはCGUI関連に関しては正直しばらく
独立を保ちたいと思っている所です。

実際今の所CGUI・IME・Windmillなど全ては
カーネルの上の普通のアプリケーションとして動いているだけですので
本体にはフィードバックする必要がないからです。

CGUIは最初から設計方針として本体とは切り離し
完全独立するようになっています。
本体に食い込ませると依存関係などが出てきて
逆にややこしくなる可能性がありますし、
それにサービスとして独立しているのは
マイクロカーネルを採用しモジュール単位で作り込む
Mona本来の設計方針だったとも思いますので。

もちろん、本体にマージするのが嫌などと言う意味ではありません。
あくまで現時点では本体にマージするメリットがないですし
モジュール化の為に今は私がCGUIの担当として全部管理している方が
うまくいくと思うからです。
少なくとも落ち着くまでの間は。


今後の私の予定としては：
・私の方も最新のカーネルにアップデートして
　(Alpha4を使っているのはそれ以外では一発コンパイルが通らなくて
　フィックスするのが面倒だったからです・・・)
　.iso全体も最新の状態にする。

・ヒープメモリのバグ（alpha4ではmallocのアルゴリズムに問題があるようで大量に確保するととんでもないスピードダウンがありました。）
　を直すなどカーネルレベルの方でもいじりたい所があります。
　
ひとえに言うとQEMU上からWindmillを動かしてもストレスがないぐらいになるまで
その為の障害やボトルネックになっているあらゆる部分に手を加えたいです。

後は
・CGUIのドキュメント（アプリケーション開発手順）のページを作る。


こんな事を考えています。
また何か進展があったら現れます。

>>675-676
MonaをDOSみたいな感覚で捉えてるのかな？
それなら太郎とつるむメリットがないのはわかる気がする

>>676
＞・ヒープメモリのバグ（alpha4ではmallocのアルゴリズムに問題があるようで
＞大量に確保するととんでもないスピードダウンがありました。）
これはalpha5で直ってる

>>674
みのぽんは学者肌だよね
血は争えないという印象

>>648
太郎の持ち味は昔から一貫して公開オナニー。
これは変わらない。
変わったように感じるのは最初の頃は猫を被っていたため。
大人になったらそうそう性格なんて変わるもんじゃない。

>>677
試行錯誤して自分に合った道に落ち着いたということでは。
Monaは好き勝手いじって遊ぶのにはそこそこ良く出来たおもちゃ。
中の人には外に対して素材を提供するという意識を持ち続けてほしい。

>>679
どんどんマッドサイエンティストっぽくなって正直引く

>>680
以前はもっとフレンドリーな印象だったんだけど
猫被って下手に出てたからではないと思うけどなぁ

>>359
自分で線引きしてどんどん閉じこもって幸せって話

ふとLとKとさっきゅんとひげが仲良くわいわいやってた時代を思い出して涙が出そうになった・・・

>>684
同じようなこと言ってる香具師がいる
http://pc8.2ch.net/test/read.cgi/os/1165476969/232

j様乙
これでもかっというくらい落ちるけど
それが直れば実用できそうな速度ですね

IMEは名詞類が無いのはいいとして
「chu」で「ちゅ」が入らないのがｲﾔﾝですた

CGUI1.21ｷﾀｺﾚ
超絶に速すぎﾜﾗﾀ
ありえねー うはははははwwwwwwwww

コンパイル済のisoイメージがあれば簡単に試せるのになー。


virtual pc無料になったし。

初心者にはlinux以上に敷居が高い。

j様がカーネル見直したらここまで伸びる余地があったのか。
5倍ぐらい一気にスピードアップしてないか。
やっぱこの人だけは桁違いに飛び抜けたスキル持ってるな・・・

>688 あるよ普通に。

>>689
カーネル触ってないでしょ?

いじったのはピクセルじゃなくて？

CGUI 1.2.1：カーネルやモジュールを独自に改造した大幅な高速化

そういやmonapi2を制定した時も(MonAPI1の)4倍スピード上がるって書いてたような
ハッタリじゃなくて本当に出せたんだ；；ﾟдﾟ)

>>687さん
うぉーーーー。超起動が速い。

junjunnさんどこをどうしたのか知りたいなぁ。
あわよくば取り込む方針で。
ここまで本格的にチューニングで成果を出したのは正直すごいと思います。


気づくのが遅れて本当に申し訳ないです。
pc8.2ch.netの方をブックマークして、Firefoxのbbs2chreaderを利用して読んでいたら、pc10への移転に気づかなかった。

>ひげぽんさんへ
改変ソースはここに上げておきます。
http://www.geocities.jp/mona_cgui/temp/kernel.zip
http://www.geocities.jp/mona_cgui/temp/file_server.zip

いじったのは主にFile.binです。
IDEドライバの中に大きいボトルネックがあったのを発見したので
それを取り除いたら一気に伸びました。
後はカーネルとmonapiの、両方のmemcpyとmemsetをいじったような気がします。

すみませんがソースの安全性は保証できません・・・
テストの為に私が後先考えず改造やメモを入れてゴミを撒き散らしましたし、
もしかしたら新しいバグを作ったりしてたりひどい有様ですが
それでもよかったら改造箇所をフィードバックするなり自由に使ってください。

CGUI SDKが公開された。
ソースが・・・
あの内容だからさぞかし恐ろしいコードの山になってるのかと思えば
拍子抜けするほど少ない。
他のライブラリと動的リンクしてるわけでもないしCGUInterfaceって奴が全部か。
よく動くなこれで。

すごいな・・・これ。
俺もなんでこれでGUIアプリが動いちまうんかと思ったら
結局全部メッセージングだけで片づけてるのか。

つくづく、うまい・・・
DLLも動的リンクも共有メモリも何もいらなかったんだ。
最初からメッセージングでリクエストだけ送ればGUIコードそのものを共有化する必要なんて。
シンプルで最強だ。こんなのでよかったんだ。こんなやり方が( ﾟдﾟ)・・・

>junjunnさん
おお。ありがとうございます！。
週末にじっくり diff をとりながら勉強させていただきます。
たぶん最新版Monaに取り込むことになると思います。

レポートはまた後日にでも。

素晴らしい仕事なのでコードを読んでみました。
関数やの引数の命名規則がモダンでないのが気になりました。
細かいのかもしれませんが今どき、こういうコードを見てしまうとJavaプログラマが離れてしまいそうです。

もったいない。

>>699
今時の命名規則ってどういう感じなんでしょうか？
モダンな命名規則に興味あるのですが、どこらへん見たらいいんでしょうか？

コーディング規約でぐぐればトップに出てくるわけだが…

プログラミング言語によると思うけど C++ であれば卑下のそれが一番近いのではないかな。
メンバだったら m_
ポインタだったら p_

みたいなのはかなり古いかと

なるほどね。関数もメンバも全部メッセージングに追い出せば変な物導入しないでも全部用は済んじゃうし
この先どれだけCGUIを拡張してもライブラリの増大は一行で済むわ
MonaForms系が苦しんでたソースの肥大化が嘘みたいだ。こんな綺麗なやり方ができるのか。

実際に見せられてみれば俺でも原理はやり方はわかったけど
これを思いつけって言われたら無理だったな・・・やっぱ共有空間とか持ち出してメンバをシェアしようとしてただろうな。
実際にMonaFormsが出来てから今まで
こういう風に書けばスッキリするのを誰一人も指摘しなかったし。

同じ問題を解くにも設計力でここまで差が出るのか。
すげーよ・・・orz


>699
個人的にJAVAはいらんけどな。JAVAで書かれたまともなソフトなんて見たことない。

>junjunnさん
まずは file_server の高速化を取り込ませていただきました。ありがとうございます！
レポジトリ の trunk/mona に取り込みました。

高速化の内容は
・IDEDriver.cpp でのウェイト用　sleep をコメントアウト
・ISO9660FileSystem::read での offset == 0時に共有メモリに直接読み込み
の2点でした。過不足があったらご指摘ください。

詳細は
ttp://d.hatena.ne.jp/higepon/20070120/1169307018
に書きました。


関数の引数や命名規則の話が出ていますが、。過去にこんな議論がありました。
ttp://wiki.monaos.org/pukiwiki.php?%B5%C4%CF%C0%2FMonAPI%2F%CC%BF%CC%BE%B5%AC%C2%A7


あともしも、CGUIが最新の trunk に入るのであれば、beep player をCGUIで作ってみようかなとか思っています。
入るとうれしいなぁ。

>>703
おいおい、IDLを知らんのか？
任天堂のesはIDLでもっとスマートに自動化してるぞ。
BeOSのやり方もIDLを隠して同じことをやってるし、
IDLもC++も使わないで同じことをしてるのがWin16/32だし、
昔からあるやり方で別に新規性はないぞ。

コマンド書き込み後とかの400ns or 割り込み待ちのとこか

>>703
君の嫌いなJAVA用語でカテゴリわけがされている。

CGUIの方式はピア
MonaFormsは方式はライトウェイト

それぞれの方式の長所・短所は良く知られている。

プアな環境ではピアが有利。
Swingが登場時にボロクソに言われていたように、
ライトウェイトはプアな環境では使い物にならない。

ピアはポトペタ式に定型部品だけを使うのに向いている。
しかしアプリ側で手を入れると実装としてリニアにならない。
サブクラス化やオーナードローで泥縄になる。
LLの人ならSWIGでC++のクラスをPerlでラップするのをイメージすると近い。

>>697
＞DLLも動的リンクも共有メモリも何もいらなかったんだ。
＞最初からメッセージングでリクエストだけ送ればGUIコードそのものを共有化する必要なんて。
DLLが使えなかった頃は後者の方法が使われていて、
解凍をDLLではなくファイルサーバでやるのはその名残だった筈。

サーバ式ではキューが直列化されるので排他的な処理には有利だけど、
リエントラントな処理では無駄になるし、
かと言ってリクエストごとにスレッドを立てるとシンプルではなくなるので、
無条件にどちらが優れているというものではない。

>>702
ひげぽんはメンバにサフィックス付けてるけど、
前か後ろかというだけで本質的には違いはないかと。
m_hige <-> hige_

プレフィックスが好まれるのは主にソートや補完の便。

ATA/ATAPIのプロトコル見た感じ、ステータスレジスタ読む前に
最低400ns待つのはちゃんとやらないとヤバそうよ。
waitまるっきり無くしちゃうのは却下却下。
仮に実機で動いたとしても、動くからイイやーとか言わないでー。

>>708
プレフィックスもサフィックスも付けないのがモダンな命名規約なんだが

どっかのバッドノウハウが「bikeshedだね」とか言いそう

>>703
コモンコントロールの外に一歩出たら体系が交錯する。
サードパーティーコンポーネントはクライアントで実装せざるを得ない。

本体側は絶対落ちないくらいに堅牢なものだけにしないと、
コンポーネントのバグでGUI全体が落ちる危険がある。
カーネルのモノリシックかマイクロかって議論とまったく同じ。
OSAKAみたいにGUIまでカーネルに取り込むようなのもあるしな。

カーネルだとモノリシックとマイクロみたいに構造がよく議論されるけど
GUIの作り方は興味持つ人が少ないから目にする機会が少ないってことかと
どーせWeb3.0の時代になればクライアントサイドGUIなんて死滅死滅

>>713
こうやってスレが伸びてるのは刺激があったからだよね？
両極端な実装が並ぶから鮮やかに対比できる。
GUIに関心を引くチャンスなんじゃないかと。
これで湾岸あたりが打倒j様で萌え上がれば面白い。

CGUIアイドリングしてなくね？

>>712
GUI本体がコンポーネントを持っているのがモノリシックカーネル的
GUI本体からコンポーネントを追い出すのがマイクロカーネル的

この理解で合ってる？

>>716
＞この理解で合ってる？
ＯＫ

＞GUI本体がコンポーネントを持っているのがモノリシックカーネル的
こっちがピア

＞GUI本体からコンポーネントを追い出すのがマイクロカーネル的
こっちがライトウェイト

たまには入食いのためにVPC買ってOSまで乗り換えた影様のことを思い出してあげてください・・・

sleep(ms)で待とうとすっと最低10msみたいだから、確かに長いかもしんない。
もっとマシなwaitのかけ方を確保した上で、t13見るか既存の実装パクるかして
より大雑把さ少なめの制御するといいんでないでしょーか。　＞ファイルシステム高速化

http://www.t13.org/

しかし……現状sleep(1)でもsleep(5)でも実質sleep(10)と同じなんだけど、
それにしたってどういう基準でこの秒数指定してるのかよう分からんちん。
wait入れる場所は割と合ってるっぽいけど、なして間隔がこう大雑把なの？　＞IDEDriver書いた人

>>696-697 >>700 >>703
j様七誌で乙

>>719
意味不明だ。
そんなのおまいが勝手に作ればいいだけじゃん。

新入り風情が

実機でウェイトなしはまずい
それに物理メディアアクセスが糞遅いんで
少々ウェイト削ったくらいでは高速化しない
安全側に振ってロールバックするのが良いかと

そうすっと、高速化については割とぬか喜びだたーかもなのか？

それがj様クオリティ

>>705
esのソースは綺麗だよな
特に構成が非常に上手い

でもさあ、やっぱし10ミリ秒て長くないですか？
100回繰り返したら1秒じゃないですか。いや100回繰り返すのか知らないけど実際。
せめてマイクロ秒くらいに抑えると結構変わったりしないすか。しないすか。そうすか。

>>728
ユーザー側なんで仕方ないじゃん
犬糞だってnanosleepしてもタスクスイッチで10ms浪費する

>>728
そう考えるとプリエンプティブって張り子の虎だよな
世間体に縛られて体裁を繕っている今と違って
プリエンプティブの実験とかしてた頃の太郎は
純粋に実験が楽しかったんだろうな・・・（遠い目

いまどきrdtscもねえしなぁ。

なんか妙に最適化に固執してアーキが古臭くなってるような。。。
あんまそれやるとOSASKの二の舞にならないかと老婆心ながら。。。

モダン＝富豪的な罠

それよかビジーループ何とかしろって
ノンプリエンプティブか？ｗ
古臭いにも程度ってもんがあるだろ

>>733
有り余るリソースを力技でブンブン振り回すのが漢の浪漫だろ？
2年もすれば8コアくらいは当たり前の世界が見えてるってのに。

>>715 >>734
意味不明だ。
そんなのおまいが勝手に作ればいいだけじゃん。

新入り風情が

実機でウェイトなしはまずい
このスレもビジーループ

>>738
ﾜﾗﾀ

既にmonaはモダンさが売りじゃなくなってる希ガス
これからはlispの時代ねぇ

>>740
太郎は既に充分な功績を残したんだから
余生くらい好きなように送らせてやれよ

アーキテクチャが世間に逆行しててﾜﾗﾀ

j様は湾岸の豪華版

>>743
j様に大変失礼かと
というか湾岸の名前はだすな

簡単なものを複雑に実現しないと、大人OSであるMonaOS界隈では
認められないのかもしれませんね > j様

Yamamoto Mona-OS (オフィシャルサイト)
http://yamamoto-mona.cocolog-nifty.com/mona/2007/01/index.html

デザインパターンとか持ち出す奴に限って無能。100％www
そんなにすごいんなら自分でプロジェクトメンバに加わってOS書けよ。できないから遠くから名無しで吠えてるだけなんだろーね(ﾜﾗ

って遠くから名無しが吠えてた

CGUIのメッセージ方式はまあモダンなOSなら全部採用してる当たり前の方法だけどな。
今まで誰も指摘しなかったのは事実。
理論的にはわかっちゃいるけど実際に書くのが難しいのがプログラミング。

言われたらわかるんだけどな・・・
今まで何もしないで
できた後からケチつけるのは答えを見てから解答を逆算しただけだろ。

>745
全然関係ないだろw

今後の成果次第だ
少なくともCGUIはBayGUIより落ちまくるし今のところご大層な理論も微妙？
両方が改良を重ねて最終的にどっちのアーキテクチャが優れてるか現物出して証明しない事には何言えんよ

>>748
捨てられつつある方式なんだが
X intrinsic -> GTK+, Qt
AWT -> Swing
Win32 -> Avalon

ハンガリアン使いなところを見るとMFCを相当やり込んでいそう
Win32のマクロの影響を受けたんじゃないかと

windowsx.h

#define Button_SetState(hwndCtl,state) ((UINT)(DWORD)SendMessage((hwndCtl),BM_SE
TSTATE,(WPARAM)(int)(state),0))
#define ComboBox_AddString(hwndCtl,lpsz) ((int)(DWORD)SendMessage((hwndCtl),CB_A
DDSTRING,0,(LPARAM)(LPCTSTR)(lpsz)))

>>750
適用範囲が全然違うので同じ土俵で比べるものではない。
優劣とかではなく、一般的には目的によって使い分けられる。

組み込み部品方式は組み込みパーツを並べたGUIには強い。
業務用のVB製フロントエンドみたいなアプリ。
起動時間もバイナリサイズも有利。

自分で部品を作ったり、既存の部品を拡張したり、
移植性を重視するような場合には、
全部クライアント側で書くような作り方をする。
富豪的な実装なので重くなる。

前者の方式をモダンにやるならIDLは必須。
プロセス間通信のコードを手書きするのは時代遅れ。

後者の方式はプロセス間通信は不要なのでひたすらフラット。
既存OSのアプリとしてバイナリ配布する際に
スタティックリンクしてしまえば単体で動くので都合が良い。

>>748
全部手書きしたら難しいのは当たり前。
IDLのトランスレータからちゃんと作り込んで
コードを書く側でプロセスの壁を意識しないようようにするのが
CORBAやCOMなどのモダンな方法。

ただこれを何の工夫もなしにやると
継承できないコンポーネントができてしまう。
CORBAではないがSWTなんかがその例。
与えられた部品を改造せずにそのまま使うなら問題ないが、
継承して手を加えるときに大問題が発生する。

>>754
意味不明だ。
そんなのおまいが勝手に作ればいいだけじゃん。

何か事件があると必ず出てくる「俺には前からわかってた」人間。（笑）
今まで何してたんだ？
その自慢のスキルで今度は事件が起こる前に見せてみろよ(´ｰ`)y-~~

>>756
意味不明だ。
そんなのおまいが勝手に作ればいいだけじゃん。

ttp://www.daionet.gr.jp/~knok/flash/os-win-lose/os-win-lose1.swf
> 負け組みとは？
> ----
> 他人のソフトウェアをメンテナンス
> 　バグ修正
> 　backport
> 　環境変化への追従
> 　　他のhackする暇なし！

>>758
Linusの評価が太郎に被るな・・・

>>759
太郎に大変失礼かと
というかLinusの名前はだすな

やあ(´･ω･`) また逢ったね

本当にすまない　こんな騒動になってしまって


でもね、ひとつだけ閉鎖をふせぐ方法があるんだ


http://game11.2ch.net/test/read.cgi/otoge/1167185144/


↑のスレに


「あっきーは書き込まないでください」
と書き込むんだ。

またより多くの人間に知ってもらうため他のスレにコピペして知らせて欲しい

では健闘を祈るよ

>>761
なんで大内君が晒し者にされてるわけ？＞太郎

昔俺を振ったねーちゃんもあっきーって呼ばれてたな

>>762

http://d.hatena.ne.jp/jkondo/20061205
jkondoの日記

　2006-12-05
　■スルー力なんて無くていい 16:31

　　なんか最近「スルー力」という言葉が流行っていて驚いているのですが、
　「なんでも華麗にスルーできる人は偉い」というような価値観だけが蔓延
　するのもどうかなあ、と思っています。


290 ：ひげぽん ◆Ngzcp/NZpA ：2006/12/07(木) 00:33:11

　「好き勝手いっている奴」の件ですが
　コードを書く人が一番偉いと思っているので、もし不愉快な書き込みを見
　かけたら皆でスルーすれば良いのではないでしょうか。

http://pc10.2ch.net/test/read.cgi/os/1163920221/290

>>762さん

761のスレッドを斜めよみしましたが、あっきぃさん違いかな？
ちと良く分からないです。

>>765
あんまり心配させんなYO!
また内ゲバで粛清でも始めたかと思ったじゃん

> また内ゲバで粛清でも始めたかと思ったじゃん
"また"とかいうなよ。まるで以前にはあったみたいじゃないか。

...まさか、もしかして、あったの？

内ゲバは和製OSコミュの伝統です。

大変遅くなってすみません。
junjunnさんの高速化取り込み kernel 編をやりました。
詳細は
ttp://d.hatena.ne.jp/higepon/20070210/1171121873
に書きました。

これで junjunnさん提供の高速化取り込みは完了です。

junjunnさんありがとうございます！

>>769
>>724

元々、このOSが実機で動いたことないんだけど、
さらにPCエミュレータ専用OSの方向に進んでいくのか…

CGUIみてみました。
ほぼストレスない操作感に感動です。

>> 現在できない事：
>> 　ビットマップ描画などユーザーがドット単位でアプリケーション
>> 　の描画バッファに　アクセスする手段は現時点では用意されてい
>> 　ないため無理です。
>> 　（略）
>> 　将来的にデバイスコンテキストに相当するクラスを導入して解決
>> 　する予定です。

個人的にはこれが解決するまで放置だなぁ。
ユーザ側で部品を拡張できなきゃ遊ぶ気にならないね。
あと、イベントはウィンドウでハンドリングするのかな。
部品内で処理できないと部品を自作しても結局はウィンドウ
までいじる必要になっちゃうよね。

とりあえず今後が楽しみです。

最近、Windows Vistaがあまりにも糞であることが分かるようになり、Windows
にかわる第３のOSの登場が待ち望まれています。

新OS：monaの開発で、新しいOS革命を起こしてほしいです。

OS文化大革命？

>>773
もうMonaは技術的にも廃れたOSになってしまったが、革命を起こすとか…

そこで内ゲバ＆粛清ですよ

>新OS：monaの開発で、新しいOS革命を起こして→　革命OS派→　革○派

>MicroKernel開発隊　→　中核派

>>777
ﾃﾗﾜﾛｽｗｗｗ
おまいセンスあるな
あとラッキーセブンおめ！

>>772
OLEを再発明して信者（を装った本人)がベタ褒めする悪寒

もうMona自体が古いしな。
こう考えると、Windowsが一番マシっていう結論になる。

>>780
だからこそSchemeで一点突破なわけだが。

ttp://d.hatena.ne.jp/fromdusktildawn/20061002/1159784863
> Lispは、JavaやC#や多くのLL言語の過去であると同時に、未来でもある

>>781
LISP至上主義はEmacs使いの成れの果てと相場は決まっている
結局和製OSは技術を人口に膾炙させたKの一人勝ちで終わったな

>>782
つ「それがぼくには楽しかったから」
他人のことなんか関係ない

>>783
Mona本を買った人の大半はOSの作り方が知りたかったという事実。
そんな不満をK本がフォロー。
出版社もうまいね。

>>784
それは勝手にそう思い込んでた香具師の落ち度だろ
卑下本はMonaアプリ開発の手引きとしては悪くない
もっとも今のMonaには何の役にも立たないが

Schemeインタプリタなんてまだ練習みたいなもんだろ？
Schemeコンパイラを作ってカーネルをリライトしてからが本番。
太郎にとっての本当の勝負はそこから始まる。

>>763
現首相夫人？

>>783
>>760

>>772
それを突き詰めると基本部品も全部ユーザー側で持っちゃえってなって
実際にそういう実装が最近のトレンドではあるのだが
MonaFormsとの差別化のために意地でも避けようとするだろうな

>>779
そうなると残された選択肢として
OLEの劣化コピーを「独自に考案する」のはあり得る

>>786
APIやカーネルまでschemeだから
schemeシェルから透過（＝ネイティブ）ですよって戦略か。
CooSのCLIをschemeに置き換えたようなもんだな。
最初はインタプリタからってのもCooSと同じ。

>>790
なんだか全然萌えないんだが・・・
太郎があっちに逝っちゃったってのが正直な感想

既にMonaの開発の中心はj様に移ったってことかもな
jOSはプロプラでNWSOSと似たような雰囲気になりそうだが
パクリ上等でGPLをやめたんだからそれはそれでいい

OSに夢を見る時代が終わったのをparallelsのcoherenceが象徴しているかと

>>781

　寝　言　は　寝　て　か　ら　言　え

>>793
ヒント：分裂勘違い

ttp://www.itmedia.co.jp/news/articles/0702/16/news037.html
YouTubeをテレビで“ダラ見”　はてな、Wii対応の動画サービス (1/2)

ttp://image.itmedia.co.jp/news/articles/0702/16/yu_hatena_10.jpg
頭がスーパー蓑輪人

　　「これがうまくいけば、はてなと別会社で運営してもいい、ぐらいに思っている」

暫定CEOの座キタ

未踏採択期間中にこういうことを堂々とやられると複雑だな
PMやIPAひいては他の採択者や非採択者に対しても失礼じゃないかなあ
まあひげぽんさんの未踏の成果が有無を言わさないほど充実していれば問題ないのかもしれないが

>>796
>まあひげぽんさんの未踏の成果が有無を言わさないほど充実していれば

他のBSDライセンスのScheme実装をパクってMITライセンス/C++に
鋭意書き直し中なので無問題

せこい奴だ

ヤリタイホーダイの売名行為だったとはな・・・

>>795
JASRACに文句付けられたりしね？

>797
湾岸？
また妬みか

>797
日記読んでる？
パクっているならあそこまで苦労しないかと

パクって、さも自分の手柄のように言うのは一人だけです。

動画再生サイト「Rimo」にも著作権問題？
ttp://www.j-cast.com/2007/02/21005658.html

>>802
ツベをパクって画期的とか？

必死だな。

スラドきてた
ttp://slashdot.jp/articles/07/02/22/1519226.shtml

jさまがHDD書き込み対応ｷﾀ━━━━(ﾟ∀ﾟ)━━━━

>>799
技術者の暴走レベルで尻つぼみに終わるか、ホリエモン並の大物に化けるかの
瀬戸際だと思う。

>>808
太郎はもうダメだろ
既にMonaは実質j様のものだし

仕様書ﾏｰﾀﾞｰ

つーか未踏に出した書類を晒せと
どこに逝くのかさっぱりわからん

俺は仕様書とかはどーでもいいと思うよ。APIさえ提供されてりゃ全ての機能が使えるんだし。
オープンにして勝手な亜種が乱立するよりクローズにして本家が仕切ってもらう方が助かる。

j様名無しで乙

>>811
太郎はお呼びじゃない

>>812
同じようなことをL様、j様、高橋氏（CooSの人）が言ってた

>>813
先を越された、、、

仕様書が書けない=パクリ

NTFS最強ということだな

ｸﾚｸﾚ厨はほっとけ。
こいつらは要求するだけ要求して、物ができても何も仕事しない足を引っ張るだけの屑ども。昔から住んでる。
大物なら名無しの小物なんて相手せずどーんと構とけ。

j様七誌で乙

別に仕様くらい教えてくれてもいいだろ
ファイル名に何文字使えるとか、ファイルサイズ制限とか

おお。HDDだ。
素晴らしい仕事 > junjunnさん

ところで FileServerHDDInterface ですが、既存の monapi_file_xx からも使えるようになるとうれしいのですがだめですかねえ。

iModeに移植したやつなのかな？iMonaってやつ。
使いやすくていいね。感謝してます。

>>820
>>811

>>821
これか？
ttp://imona.net/

まったく関係ないから帰れよ

さすがに太郎はもう逝ってよしだろ
なんか勘違いしてるみたいだし

>>824
ヒント：老害

>>825
それは言いすぎｗ
でも未踏終って30歳になったらさっさとMonaから手を引いて小説家になるべき

part2〜5が黄金期だったような気がしなくもない
人が入ってきたのにさばききれなかったのが敗因かな
あとはj様がNWSOS路線でL様に張り合ってくれればいい

>>827
未踏に受かって、本業でも大評判ですが伺か？

>>828
ただの童貞のひがみだろ
いちいち相手にすんな

モナは太郎の個人プロジェクト
j様のはフォークなんで勘違いすんな

もうjOSって名前にしちゃった方がいいんじゃね？

それ何てPalmOS日本語版？

今はPalmも犬糞上に乗っかる時代だからなぁ
日本のケータイもITRONから犬糞に移行しつつあるし

シンビアンがためすぎ＆ロイヤリティ払いたくないだけ

>>830
>モナは太郎の個人プロジェクト

違うよ。既に未踏から数百万受け取ってるのだから。

×数百万受け取った
△数百万搾取した
○数百万詐取した

>>835
未踏は個人プロジェクトの支援なんだが。
法人向けの支援は別にある。

>>836
未踏の意義は金よりも名誉じゃね？
年収１千万円を超えてるんだし。

名誉だけなら、税金の無駄遣いはいらない。
日本の技術発展に直接的に寄与しないものに投資するIPAもIPAだ。

>>838
＞日本の技術発展に直接的に寄与しない
ＰＭは寄与すると判断したから採用したんだろ？

エストとかアンシーとか未踏出身の有名ソフトは結構あるぞ

日本の技術発展のためじゃなくて、個人の技術開発のためだろ

>>841
そうでもないみたいだよ
未踏でできたコネに飲み込まれちゃったりするらしい

>>840
ソフトイーサもなー

Anthyなんて採用はされたけども、未踏ですらないし。
結局は旧態依然の役人が、高度経済成長時代の技術観でポートフォリオ読んで金ばら撒いてるだけ。

エスト→鯰で十分
アンシー→かんなで十分
ソフトイーサ→OpenVPNで十分

どこが未踏？

OSとかIMEとか好きだよな。>IPA
その割に発展しないのは、まさに未踏なんてやってるから。

未踏後は開発が停止したものもかなりある。
シグマの時代から形は変えたが中身はまったく変わらないのがIPA。

検索系も大好き

>未踏後は開発が停止
OSASKとかCooSとか？

>>845
たまにはWnnのことも思い出してあげてください

>>846
＞未踏後は開発が停止したものもかなりある。
それ何てOSASK？

>>848 >>850
Kが未踏で竹ちゃんに後進の育成の意義を認められたから
人を育てるためにハリボテにシフトしたんだろ