パスワードを忘れた? アカウント作成
7534 story

Mona ver.0.1.5 リリース 66

ストーリー by Oliver
目指せ、Hurdより前に完成 部門より

Anonymous Coward曰く、"2ちゃんねるOSを作ろうスレッドでひげぽん氏を中心に開発が進められているMonaのver.0.1.5がリリースされた。(リリースノート, スペック, ダウンロード)
Monaは従来のOSの枠組みにとらわれない新しいOSを目指して2年前から開発されている。その大半は地道なカーネルの実装に費やされたため地味な印象があったが、今回のリリースで念願のユーザーモードアプリケーションが作成できるようになった。リリースに含まれるフロッピーイメージにはメガデモやオセロなどが収録されている。"

"Monaは主にC++で記述されているが、ひげぽん氏はOS作成に着手するまでアセンブリやC/C++の経験はほとんどなかった。2年間でこれだけのものに仕上がったというのだから驚きである。もちろんそれは2ちゃんねるでのアドバイスが大きな助けになっており、2ちゃんねるをうまく利用したバザールモデルとして注目に値する。
将来的にはマイクロカーネルを目指しており、プロセス間のメッセージングによって動作するモデルを追求している。現時点でマウスやキーボードがサービス(デーモン)として提供されている。
実機でフロッピーブートさせることの繁雑さを避けるためエミュレータを重視しており、ひげぽん氏自らBochs, Virtual PC, VMwareで徹底的に動作を検証しているのも心強い。
まだまだ検証に不十分な点が多いため、MonaBBSのMonaOS開発板にある動作・不具合報告スレッド(直リンク不可)への報告にご協力をお願いしたい。"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • ひげぽん氏の人格 (スコア:3, すばらしい洞察)

    by Anonymous Coward on 2004年02月16日 17時25分 (#496731)
    もちろんそれは2ちゃんねるでのアドバイスが大きな助けになっており、2ちゃんねるをうまく利用したバザールモデルとして注目に値する

    Monaがここまできたのはひげぽん氏の人格によるところも大きいと思います。
    普通の人だったら2ちゃんねるのあのものすごい荒らしには耐えられないでしょう。
    これからも頑張ってほしいものです。影ながら応援しています。

  • by Anonymous Coward on 2004年02月16日 17時16分 (#496716)
    なんかGUIになるのはいつになるのかなって気がします。
    BeOSと一緒の道を歩むんだろうか。

    ポイントはアプリでしょう。ゲーム業界と一緒でソフトウェア・キラーコンテンツが無いと
    ハード自体も売れないしOS自体も成長しないと思うんですが。

    重たいOSにはなってほしくないと願います。
    • ん? (スコア:0, フレームのもと)

      by Anonymous Coward
      実用OSになると思ってるんですか?
      素朴な疑問
      • Re:ん? (スコア:4, すばらしい洞察)

        by Anonymous Coward on 2004年02月16日 17時41分 (#496749)
        成果物そのものよりも作る過程で得られる
        知識とか経験とか楽しみの方が重要ですな。
        親コメント
      • Re:ん? (スコア:2, すばらしい洞察)

        by Anonymous Coward on 2004年02月16日 17時46分 (#496753)
        この人はLinux初期リリース頃のLinusにも同じコメント書きそうだな・・・
        親コメント
        • 新キャッチコピー (スコア:2, おもしろおかしい)

          by Anonymous Coward on 2004年02月16日 20時49分 (#496888)
          タネンバウム教授も見ている/.JP!
          親コメント
        • Re:ん? (スコア:1, すばらしい洞察)

          by Anonymous Coward on 2004年02月17日 0時39分 (#496988)
          でも、もしLinuxが今の時点で存在しなかったとして、*BSD+XFree86+gnome/kdeな環境がここまで動いている現状で(TCP/IPスタックすら無い)初期Linuxが出てきたら、やっぱり「なんて中途半端な..っていうか、使えねー」って思う気がするけどねぇ。あの時期だからこそ、「x86で動くUNIX」というだけで皆が「おぉ!」って食いついたわけで。

          他コメントにも書かれてるけど、このOSって、作ること自体を楽しんでるわけでしょ?「使えるOS」を目指してたLinuxをこの場で比喩に出すのはイマイチな気がするし、時代背景を考えれば、使うことにしか興味のない人にとっては「GUI無いのぉ?」っていう反応があってもおかしくないと思うよ。
          親コメント
      • by Anonymous Coward
        なんで#496728が「フレームのもと」なのかなあ
        素朴な疑問・・・
        • by Anonymous Coward
          コメントがネガティブすぎるからでしょう。

          「素朴」という言葉を使って、素朴を演出する方が
          発想がいやらしいとも思いますしね。
  • by shadowfire (6584) on 2004年02月16日 17時25分 (#496730) ホームページ
    スペック表見てるだけだと、例えば既存のUnix系OSに比べて
    こいつはここがスゲーんだ!
    というポイントが見えてこないんだけど、
    どのへんがスゴイのか、解説お願いします、エラい人。

    --
    --------------------
    /* SHADOWFIRE */
    • Re:解説を (スコア:3, すばらしい洞察)

      by kanina (16615) on 2004年02月16日 17時35分 (#496741) 日記
      「作ったこと自体がすごい」に1票
      親コメント
    • OSなんて (スコア:2, すばらしい洞察)

      by Anonymous Coward on 2004年02月16日 17時43分 (#496751)
      凄くなくて結構。
      親コメント
    • Re:解説を (スコア:2, すばらしい洞察)

      by Anonymous Coward on 2004年02月16日 17時47分 (#496754)
      「ネタとしてスゲーんだ!」に一票
      親コメント
    • Re:解説を (スコア:1, おもしろおかしい)

      by Anonymous Coward on 2004年02月16日 18時16分 (#496781)
      別にすごいすごくないじゃなくて。おもしろいかと。
      数日あれば全体を把握できそうな感じで手が出しやすそう・・・てか手をだしてぇ~
      でもこれに手をだすと卒業できない・・・就職も決まらない。。。
      なぜだか昔「はじめて読む486」を読んだ時のわくわく感がありますね。
      親コメント
    • Re:解説を (スコア:1, おもしろおかしい)

      by Anonymous Coward on 2004年02月17日 14時37分 (#497303)
      ・一見GUIだが、よく見るとすべて、AAで出来ている。
      ・処理に時間が掛かっている時に「中の人も大変なんです」とメッセージを表示する。
      ・ブラウザーがデフォルトでギコナビ
      ・ポップアップウィンドゥにHサイトへの広告がついている。
      ・AIが文章チェックを行っているので、誤字にうるさい。
      ・そのくせ「力」と「カ」などわざと誤変換する。

      ・愛着が湧いて使用しつづけていると、ある日突然閉鎖(アンインストール)している。
      親コメント
  • by udon64bit (20085) on 2004年02月16日 17時42分 (#496750) 日記
    出てくるんだろうなぁ。。。
    ・Mona搭載PC
    ・Mona搭載モバイル
    ・Mona搭載ケイタイ
    ・Mona搭載PSX

    #搭載する意味があるのか分からないがID
    • Re:Mona搭載・・・ (スコア:3, 参考になる)

      by Anonymouse Cowards X (20544) on 2004年02月16日 17時54分 (#496756) 日記
      ねたにまぢれす。

      Monaは基本的にC++で開発されているので、携帯等のプアな環境には向きません。
      もっとも、最近の携帯は数世代前のPDAよりも強力になってきてますが。
      親コメント
      • Re:Mona搭載・・・ (スコア:2, おもしろおかしい)

        by s-tomo (2841) on 2004年02月16日 18時32分 (#496796) ホームページ 日記
        Javaが動く環境をプアだなんて認めませんっ。
        親コメント
      • by passer-by (13494) on 2004年02月16日 18時05分 (#496770) 日記
        C++ って、どういう点がプアな環境に向かないんですか?いや、ちょっと考えてみたけど本質的な弱点を思い付けなかったもので…。
        親コメント
        • by trueOne (134) on 2004年02月17日 0時38分 (#496986)
          Embedded C++ [caravan.net]なんてのもあるので、リソース制限厳しめの環境でもC++使いたい人はいるんじゃないですかね。
          # そういやOpenGL/ESなんてのもあるな。
          --
          trueOne
          親コメント
        • Re:Mona搭載・・・ (スコア:2, 参考になる)

          by Crisp (10852) on 2004年02月17日 2時03分 (#497015)
          C++がCに対してheavyになると思うのは以下の点でしょうか。

          ・templateの使用
          コンパイラにもよると思いますが、基本的に使われうる型の組み合わせの分だけ同じようなコードが生成されるのであっという間にサイズが肥大化する傾向があります。

          ・例外処理機構の使用
          try文の中では、例外発生時にスタック等を巻き戻すのに備えてある種のチェックコードのようなものが埋め込まれて多少実行効率が落ちる、のかな?(ちょっと自信なし)

          あとはまあ、いろんな処理をクラスにラップすることで見通しはよくなるが、コードのサイズでちょっと損をするという場合は往々にしてあるように思います。
          親コメント
          • by Sakura Avalon (12557) on 2004年02月17日 6時12分 (#497044)
            >・templateの使用
            >・例外処理機構の使用

            もうふたつほど、
            ・クラスでオブジェクトを渡す際に値渡しでなく参照を用いる。int1個をただ渡すだけとかまで参照にしなくてもいいんですけど、ふだんから気をつけてないとクラスのメンバーが実は数百バイトとかになってるのを平気で値渡しで書いてくる人もおられますので。
            ・constやstaticにすべきところは面倒でも省略しない。
            このふたつがいいかげんだとすぐ肥大化します。また逆にきちんと守っているだけで劇的にコードは小さく速くなります。デバッグモードでビルドした時にはコードおよびメモリ使用量の差は歴然です。

            templateについては、その中身をよく理解してから使わないと巨大になったり非効率だったりしますね。特にイテレータ関連だと、配列を直で扱うクラスで1枚ラッピングした方が良かったりしますし。もちろんあくまで時と場合によりますのでtemplateはすべてダメとか言うわけではありません。

            #C++やJavaで True,False用途でtry,catch使う人がいますが、お願いだから勘弁して!ソースが見にくいだけでなく、アセンブラレベルでも追いにくい~!!
            親コメント
            • by Crisp (10852) on 2004年02月17日 13時49分 (#497269)
              >・クラスでオブジェクトを渡す際に値渡しでなく参照を用いる。

              これってまともなC++プログラマには常識かと思ってたんですがそうでもないんでしょうか。というかC++に限らずCでもでかい構造体の値渡しは褒められたもんではないですよね。
              親コメント
          • by bero (5057) on 2004年02月17日 10時47分 (#497139) 日記
            >いろんな処理をクラスにラップすることで見通しはよくなるが

            これがまあ利点でもあり欠点でもあるでしょうね
            O(n)表記のように抽象的なレベルの見通しは良くなるが、定数項の重さが見えにくくなる。

            コンストラクタ・デストラクタ・コピー・オペレータオーバーロード等々暗黙にコードが入るので、
            明示的に関数呼び出しを書くのに比べて呼び出しコストを意識しなくなりがち

            Cだと暗黙にコードが入るのは構造体の代入(と関数への構造体値渡し・返し)くらいだが
            C++だと気をつけるところが増える。
            (Cでも気をつけるべきところは気をつけんと効率が落ちるのは他の人が述べているが)

            あと、一般的なスタイル的に
            Cでは(記述がめんどくさいがゆえに?)メモリの動的確保は極力さける、
            C++では(記述が簡単なゆえに?)多用する、といった傾向があるような

            C++で実行・メモリ効率を意識しながら貧乏くさく書けばプアな環境でもいけるだろうし
            Cでも富豪的に書けばだめだろ。
            親コメント
        • by snurf-kim (10835) on 2004年02月16日 18時18分 (#496783) 日記
          >C++ って、どういう点がプアな環境に向かないんですか?いや、ちょっと考えてみたけど本質的な弱点を思い付けなかったもので…。

          このインタビュー [vector.co.jp]に答えがあるかも。:-)
          親コメント
          • by Anonymous Coward
            いや何でジョークサイトを見ないといけないのか説明ヨロ。
            • by TxG (7966) on 2004年02月16日 21時02分 (#496895)
              Stroustrup: そうですね、大体は。 実行ファイルは巨大だったし、128MBのRAMを積んだHPのワークステーションでロードするのに5分かかりました。
              という辺りなんじゃないでしょうか。ジョークはジョークとしても、バイナリサイズは無視できない問題かと思います。ジョークを載せている方のページ [vector.co.jp](ページ内を検索してください)でも
              速度よりサイズの最適化を
              と言っていますし。

              以下私見。

              実行環境(バイナリサイズ、メモリ量)の他にもコンパイラ側の問題もあるような気がします。

              C++はコンパイラを作るのが大変なので(Cすらまともなコンパイラのない環境が多いのに…)サポートするのは無理。templateなんて言わずもがな。割とメジャーと思われるPalmでもまともにSTLが使えるような環境ではありません…。
              親コメント
        • C++のバイナリはあまりに遅く、OSとしては使い物にならない。
          そう言ってカトラー氏はC++のコードをCで書き直したとか。

          初代NT開発時の逸話ですから、当時とはコンパイラの最適化周り等
          事情は多分に異なるでしょうが、一般PCでは気にならないことも
          プアな環境では大きく響いてくることはお分かりかと思います。
          私の主観ではありますが、まだ資源の限られた状況で気ままに
          走らせられるとは思いません。
          親コメント
          • Re:Mona搭載・・・ (スコア:3, 参考になる)

            by passer-by (13494) on 2004年02月16日 18時48分 (#496809) 日記
            なるほど…。

            しかし、かつて同じようにCのバイナリはあまりにも効率が悪く使いものにならないとMC68000で大量のアセンブラコードが書かれた事がありましたが、今では「gccの吐く68000コードはあまりにも効率が良く人間がいじる余地がない」という声を聞きますよね。また、かつてBe-OSは当時の環境 (今のPDAよりプアだったように思います) で高いパフォーマンスを見せていたように記憶しています。

            コンパイラと設計次第だったりはしませんかね。いや、「使っちゃいけないC++の重要な機能」なんてのがあれば本質的な弱点なのでしょうけど…。

            親コメント
            • Re:Mona搭載・・・ (スコア:1, 参考になる)

              by Anonymous Coward on 2004年02月16日 20時55分 (#496892)
              まあ、なんというか比較の問題なのだけど。

              例えば C でサイズの大きい構造体を call by value の引数にして関数呼出しすると、スタックに大きいデータを積む関係で、実行速度は遅くなりますよね。
              C で書く場合には、ほんの幾つかの点に気をつけてれば上の例のような状況を避けて実行速度の速いコードを書けるのですが、C++ で書くと、このへんの見通しが極端に悪くなるので、かなり大変なんですよ。

              C++ を使って、ちゃんとカプセル化して、実行速度の速いコードを書けるってかなりの上級者ではないかな。

              同じように実行速度が必要なGUIの場合はクラスライブラリ化した方がメリットがあるから、頑張って高速化したけど、OSの場合はそこまでやるメリットがあるかどうかもポイントなんじゃないですかね。
              親コメント
              • by passer-by (13494) on 2004年02月16日 21時07分 (#496900) 日記
                例えば C でサイズの大きい構造体を call by value の引数にして関数呼出しすると、スタックに大きいデータを積む関係で、実行速度は遅くなりますよね。
                ...
                C++ を使って、ちゃんとカプセル化して、実行速度の速いコードを書けるってかなりの上級者ではないかな。
                あー、なるほど。確かにそれはありますね。そういえばC++ではないけど他人様のそういった感じのコードを片端から叩いてパフォーマンスチューニングをした覚えも…。

                納得しました。高パフォーマンスは可能だけどそれなりの労力が必要って事ですね。ありがとうございます。

                親コメント
              • by Anonymous Coward
                逆のアプローチで、virtual とか template とか、C++特有の複雑な機能は一切使わず、
                ・クラスメソッドで名前空間がすっきり
                ・関数のオーバーロードにより、同機能のAPIは同名の関数で呼び出せる
                ぐらいのベターCとして使えば、
                Cと比べて効率は落ちず、しかも、読みやすいものになるんじゃないかと思うんですがどう
      • by Anonymous Coward
        >Monaは基本的にC++で開発されているので、携帯等のプアな環境には向きません。

        携帯電話用のOSであるSymbianOSはC++で書かれている [symbian.com]のだが。
    • by geln12 (18637) on 2004年02月16日 20時53分 (#496890) 日記
      Mona搭載8頭身ロボット

      ネコ型ロボット(青?)に搭載されたときは「ギコ」バージョンと呼ばれる。
      親コメント
  • by saitoh (10803) on 2004年02月16日 18時44分 (#496806)
    > 従来のOSの枠組みにとらわれない新しいOS

    というのは具体的にどこに現れているのでしょうか?

    > 新しい技術に基づいてマイクロカーネルのOSを作成
    とも書いてあるけど、単にマイクロカーネルと言うだけでは ありふれているし。どういう新規技術を導入した のか興味があります。 以前bitに、マイクロカーネルのIPCのオーバーヘッドを モノリシックのシステムコールのオーバーヘッドより軽くする 手法についての記事が載ったことがあったけど、それと 関係有る?

    • Re:解説求む (スコア:3, 興味深い)

      by Anonymous Coward on 2004年02月16日 19時16分 (#496833)
      > > 従来のOSの枠組みにとらわれない新しいOS
      >
      > というのは具体的にどこに現れているのでしょうか?

      他OSとの互換性(POSIXなど)を気にしていないという点です。
      裏を返せば初心者が自分の好きなように遊んでいるだけですが。

      > > 新しい技術に基づいてマイクロカーネルのOSを作成
      > とも書いてあるけど、単にマイクロカーネルと言うだけではありふれているし。どういう新規技術を導入したのか興味があります。

      そうだったらいいな、という理想です。実際に何か目新しい技術があるかと言えば、ありません。現時点ではマイクロカーネルですらありません。

      > 以前bitに、マイクロカーネルのIPCのオーバーヘッドをモノリシックのシステムコールのオーバーヘッドより軽くする手法についての記事が載ったことがあったけど、それと関係有る?

      現時点では動作させるのに精一杯という状態で、チューニングのことはほとんど考えられていません。FDドライバすら最適化されていない状態です。

      もともと好奇心でOSを作りたくなったというだけで、革新的な何かを実装するためにやっているプロジェクトではないです。
      親コメント
      • Re:解説求む (スコア:2, 参考になる)

        by uchida-t (14803) on 2004年02月16日 19時26分 (#496838)

        ちなみに、Linuxもそもそもは「もともと好奇心でOSを作りたくなったというだけで、革新的な何かを実装するためにやっているプロジェクトではない」というものでした。ただ、実用を目指してPOSIX互換を前提にしていたのがmonaとの大きな違いですね。

        とはいえ、この手の小さなOSというのは、学習用途には非常にいいと思います。いきなり*BSDやLinuxではいまや肥大化しすぎていますし、かつてのこの手の用途の王道だったMINIXは、いまやフリーになったとはいえいまさら感が漂っていますし。

        で、「革新的なOSがいじりたいんだ」っていう人はPlan9あたりをいじりましょう。

        #マイクロカーネル云々な人はL4 Hurdという手もあるな。

        親コメント
  • by kzk (16011) on 2004年02月17日 0時03分 (#496974) 日記
    TinyQt [uwyn.com]とか乗らんかな?
    QtからX依存の部分を切り離したもので、Unicode扱えるQStringクラスとかそれはまぁ色々なものが着いて来るんですが。

    #暇になったらやってみよっかなぁ。
    • by G7 (3009) on 2004年02月17日 0時40分 (#496990)
      ぱっと見た感じ、X依存云々以前の問題として、GUIな部分(描画とかイベントとか)が
      ごっそり無いような気がしますが、誤読でしょうか?

      UIとかの部分が無いと、純粋にコンパイラでコンパイルできるかどうか
      というだけの問題になっちゃったりするんで、
      「乗らんかな」という興味の対象には、なりにくいかも、と
      ふと思ったのですが。

      #まあFileアクセスとかも充分にOSアーキテクチャ依存なテーマだけど。

      それにしても、そっか。
      C++で独自アーキテクチャなOSってことは、
      libc(ってんだったよね)とも無縁なわけですね。

      #従来(?)と全然違うアーキテクチャのGUIを構築したい今日このごろなのでG7
      #Widgetが「Displayに」描画するんじゃなく、
      #Widgetが「親Widgetに」描画するっていうモデル。
      #イベントも「親Widgetから」渡されるってモデル。
      #Widgetの親子関係(親子間のデータのやりとり)だけで出来るだけ全ての事柄が動くようなモデル。
      #そうすれば「GUI版のExpect」や「マルチマウス」も無理なく対応できるはずなので…
      親コメント
      • by kzk (16011) on 2004年02月17日 16時16分 (#497400) 日記
        えぇ。ごっそりないですよ。
        ただ便利なクラスが色々有るので動いたらよいかなと。
        これが動くとKHTMLなんかも動いたりしますので。(もちろん描画部分だけはMona用に実装しなければいけませんが、HTML、CSS、Javascriptの解析部分等はTinyQtに含まれているクラスのみで動くので)

        「乗る」というとちょっと誤解が有りますね。すいませんでした。
        親コメント
      • > ぱっと見た感じ、X依存云々以前の問題として、GUIな部分(描画とかイベントとか)が
        > ごっそり無いような気がしますが、誤読でしょうか?

        2chのスレの281 [2ch.net]のことですか?
        それであれば誤読です。
        X上のBochsでMonaを動かそうとしたときの話です。
        MonaでXを動かそうとしているわけではありません。

        > UIとかの部分が無いと、純粋にコンパイラでコンパイルできるかどうか
        > というだけの問題になっちゃったりするんで、
        > 「乗らんかな」という興味の対象には、なりにくいかも、と
        > ふと思ったのですが。

        何をコンパイラでコンパイルするのですか?

        > C++で独自アーキテクチャなOSってことは、
        > libc(ってんだったよね)とも無縁なわけですね。

        基本
        • by G7 (3009) on 2004年02月19日 3時01分 (#498858)
          >> UIとかの部分が無いと、純粋にコンパイラでコンパイルできるかどうか
          >何をコンパイラでコンパイルするのですか?

          他の方が書いてくださいましたが、TinyQtのほうの話でしたので、
          コンパイルの対象もTinyQtです。

          あ。サイトを見たところ、名称が違いますね。 TinyQ。最後のtは要らない。
          #何が削除されてることを意味するんだろうか?(^^;

          >基本的にはそうなのですが、最低限のlibcは実装しようとしている [osdn.jp]ようです。

          なるほど。

          ところで蛇足、相変わらずよく判ってないんですが(^^;プロセス起動はforkとは違うやりかた、ですよね? [osdn.jp]
          (だったら)わーい。
          親コメント
        • by G7 (3009) on 2004年02月19日 3時06分 (#498860)
          余談ですが、おつきあいくださって有難うございます。

          >固定委譲にどんな意味があるのでしょうか?

          時間軸については「固定」したいわけではないです。
          つまりWidgetの生成後の、(Widgetの親子関係の)付け替えは、幾らでも許すっていう奴。
          ここらへんはSqueakとかと同じ(ですよね)。
          Squeakの場合、マウスポインタすら1つのWidgetで、
          DragDropのDrag開始は対象Widgetが「元の親からマウスポインタWidgetに乗り換えた」という形で表現されてるそうで、
          従来のGUIと比べての余りのシンプルさに唖然としてしまった次第。
          これからはせめてこれくらいは出来ないと駄目ですね。

          あと、ビジュアルと委譲関係を一致させる(そういう意味では固定ですね)っていう発想をしていますが、
          それは「わかりやすさ」を狙ったせいです。
          というのは、ビジュアルプログラミング(^^;とかの方向性をやりたいんで。
          ユーザ(しばしばトーシロ)でも、弄れば弄ったなりのモノになる、という感じの。
          なので、良くも悪くも見たまんまに動く(orしばしば動かない(藁))といいなぁと。Program自体のWYSIWYG化。
          触ったことないけどIntelligentPadとかが似た方向性なのかなあ???
          効率とかはあまり優先したくありません。
          ちょうど動作効率より記述効率のScript言語が最近元気なように、
          GUIも記述(変更)のしやすさを優先するほうに倒しても良い時期じゃないかと。
          #他人が作った(Swingの)ソフトで「どのWidgetがProgramの何処に」通じているのかを探るのが物凄くシンドくて参ったので、G7

          あと、ビジュアルと一致した委譲はあくまで「主な委譲先」の話です。
          面倒な手段(=とりあえず思い描いているのは古典的なProgramming)を使えば
          それ以外の委譲も出来ないわけじゃない、くらいの世界を考えました。
          で、使いたくない人は使わなければいい、と。
          ただ、主な委譲だけで記述できる範囲は、それなりに広くできるといいなぁとは勿論思っています。
          そういう意味で「できるだけ」です。

          >しかしWinFXでは任意のオブジェクトに委譲できるようなモデルに移行するので、

          ああ。WinFXって、次世代Windows(ってのか)の事なんですね。

          ええと。「動的委譲」というのが実際どういうものなのかは知らないんですが、
          こういう話だと、どれくらいすれ違って(^^;いるんでしょうか?
          #そこはかとなくググってみましたが旨く発見できず。

          ただ、OSとかが用意するWidgetの仕組みは、もうどうでもいいような気がしています。
          というのは、自在な委譲を極めようと思ったら今でも既に簡単に出来るわけでして、
          つまり我々がプログラミングすればいいんです(^^;。ええと、こういう問題でしょうか?

          一緒になるかどうか判りませんが、古い体験でいえば、VC++とDelphiの差を連想しました。
          つまり、WindowsのWidgetに対する「巧妙なラッパー」としてDelphiのオブジェクト群は設計されてて、
          生Widgetの色々な使いにくさを隠蔽してくれる、っていうアレ。
          (ちなみに、逆にDelphiで腹が立ったのは、単なる「Line」のWidgetすら無かったという点。)

          で、一方、なまじ自在な委譲をやってくれると、今度は
          他人(に限りませんが)のプログラムが「読みにくい」という問題が生じるような
          気がしています。
          あまり上手じゃないやりかたで、自由度ばかり増えてしまったので、
          いわば「GUIスパゲティ」「イベント委譲スパゲティ」に陥っているんじゃないかと。

          それを解決する道の1つとして、今のところ個人的には、
          「何処に何が(何と何が)繋がっているか」が、もろに「見える」という
          プログラミングスタイルが実現されると、良いんじゃないか?と思っているところなんです。

          #このGUIモデルのほかに「配線モデル」も考えてます。
          #ただ、よりスパゲティになりにくい(笑)のは、線よりも面かなーと。

          ただ、自由度は落ちますね。そういう意味では高機能にはしにくいかも。
          親コメント
        • G7さんのコメントはMonaについてではなくて、TinyQtについてでは?私のほうこそ誤読?
  • g++が強制的にリンクするlibstdc++ってバックグラウンドで強制的にmallocしたり、pthread_mutex_lock() したりしてるんだけど・・
    #だから普通のOSはカーネル内はC言語

    その辺はどうやって乗り越えたのかな?
  • by Anonymous Coward on 2004年02月16日 23時26分 (#496951)
    訴えられるということはかなり凄いOSになったという証拠だからね。
typodupeerror

アレゲは一日にしてならず -- アレゲ見習い

読み込み中...