パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

ハロウィン文書 VII」記事へのコメント

  • 主観ですぎ (スコア:2, 興味深い)

    by Anonymous Coward
    > これで「勝った」と思うのは間違いだが

    勝ったの負けたの言い出すあたり気持ち悪いのですが・・・

    「勝った」というのは、あれですか、憎き帝国主義のM$を
    我らがオープンソース同盟が打ち破ったみたい
    • いや、そういう勝った負けたの動機づけは大事だよ。 私は心情的に腐った Win32 API がなくなって、UNIX/POSIX API が世界中で使えることを望みます。 こういう話になると、よくどっちつかずの主観のない意見ばっかりでげんなりします。 勝った! これからも、社内に流布しようっと。
      • by Anonymous Coward
        >> 私は心情的に腐った Win32 API がなくなって、UNIX/POSIX API が世界中で使えることを望みます。

        Win32 APIってカバーしてる範囲が広すぎて、もはやPOSIXとかと比較するのは適切じゃない気がするんですけど。まぁ「それでも敢えてPOSIX APIだけでやっていこうぜ」という話であれば「そうか。がんばれよ」としか言えませんが。

        UNIXの世界では、GTKやQTの例を引くまてもなくPOSIXやUNIX由
        • >> Win32 APIってカバーしてる範囲が広すぎて、もはやPOSIXとかと比較するのは適切じゃない気がするんですけど。まぁ「それでも敢えてPOSIX APIだけでやっていこうぜ」という話であれば「そうか。がんばれよ」としか言えませんが。

          誤解を招きました。

          Win32 API は POSIX にくらべ範囲が広いですが、基本的な部分でいやなものが多すぎます。それは、Win32 API 自身が全体的にシンプルじゃないことがあげられます。

          私は、 "Keep It Simple, Stupid !" [cruel.org] を心がけながらコーディングしています。あと、 ソースコードがドキュメントだ、バグも全て記述されている [u-netsurf.ne.jp] 。
          • Re:主観ですぎ (スコア:1, 参考になる)

            by Anonymous Coward on 2002年11月07日 20時10分 (#196733)
            先に Win32 API 標準化云々と書いたACです。

            >> これら、複雑すぎじゃありませんか ?

            別にプログラムで飯食ってるわけじゃないので、以前は「UNIXたまにcygwin」という生活をしていました。ここ数ヶ月、諸事情によりWin32 APIにちょこっとだけ手を出しましたが、たしかに「おいおい」と思うことは非常に多いですね。僕も「Win32 APIはすばらしい」とか言ってるわけじゃないですよ。ただ、良くも悪くも「UNIX系OSの最大公約数」的な宿命を背負っているPOSIXと、少なくとも当初は「一般消費者が気に入るようなイケてる商用プログラムをバンバン開発してくれい」的な思想で作られていたはずのWin32 APIを比較するのは、ちょっとずれてる気がするんです。

            で、Win32 APIってのは明らかに場当たり的な設計が散見されるAPI群ではありますが、僕がWin32 APIで最大の問題だと思っているのは、Windowsのバージョンによって動作が致命的に異なる点です。っていうか、この時点でAPIとは呼べないと思いますね。

            もしもWin32 APIが標準化され、Microsoftが全てのWindowsで厳密にその仕様を守るのであれば、どんなに使いにくくても存在意義はあると思います。少なくともwine [winehq.com]は、その標準化Win32 APIを実装すれば完璧;-)ってことになりますし、Windowsアプリも「各種Windowsの実機で個別に動作確認」なんてばかばかしいことは必用無くなるはずですから。
            親コメント
            • by monitan (10472) on 2002年11月07日 21時24分 (#196797) 日記
              私はプログラムで飯食ってるんで、:-) OS ごとに微妙に異なる動作というのが一番つらかったりします。API のパラメータの多さはやはりチェック項目になってしまうので、こういう微妙な動きをされると、創造的活動からはなれ、ひたすら、テストモンキーになってしまいます。 他人の作ったソースがあれば、書き直したりできますが、API だとどうしようもないです。汚いソースを見たら? [srad.jp]

              >> もしもWin32 APIが標準化され、Microsoftが全てのWindowsで厳密にその仕様を守るのであれば、どんなに使いにくくても存在意義はあると思います。少なくともwine [winehq.com]は、その標準化Win32 APIを実装すれば完璧;-)ってことになりますし、Windowsアプリも「各種Windowsの実機で個別に動作確認」なんてばかばかしいことは必用無くなるはずですから。

              そうですね。同意します。
              親コメント
              • by Anonymous Coward
                > 私はプログラムで飯食ってるんで、:-) OS ごとに微妙に異なる動作というのが一番つらかったりします。
                > API のパラメータの多さはやはりチェック項目になってしまうので、こういう微妙な動きをされると、
                > 創造的活動からはなれ、ひたす
              • by monitan (10472) on 2002年11月08日 12時48分 (#197130) 日記
                コンソールアプリベースに構築してますが、MFC も同時に使えるんでしょうか ?

                CString tmp;

                で、

                error C2065: 'CString' : undeclared identifier

                と出てしまいす。もし、コンソールアプリで、MFC 関数か使用できるならその情報へのポインタ。ここで調べろ。など、すみませんが誰か教えてください。
                親コメント
              • by Joga (8113) on 2002年11月08日 13時51分 (#197149)
                > コンソールアプリベースに構築してますが、MFC も同時に使えるんでしょうか ?

                使えます。
                VC++なら、普通はAppWizardでワークスペース作るときに
                「MFCのサポート」だかなんだかをチェックするんだけど、
                後付けならコンパイルオプションを変える必要があるかな?
                MSDNの「MFC 実行可能 (.EXE) プログラムのビルドの設定」あたりを見ればいいかな。

                #AppWizardでMFCを使える新しいワークスペースを作って、
                #そこにファイルを追加してくほうが早いかも。
                親コメント
              • 今やってるのがそのパターンですが…。

                キモは
                 ・#include <afxwin.h> 宣言、
                 ・AfxWinInit(::GetModuleHandle(NULL), NULL, ::GetCommandLine(), 0) をmain関数で実行、
                 ・プロジェクト設定→一般→MFCを使用 と設定
                とするとできるみたいです。

                まあ、MFCを使うDLLを作ってそれを使う、ってのでもいいと思うんですが…。
                 
                --
                はすかわ
                親コメント
              • 有り難うございます。できました。
                AppWizard で、"Win32 Console Application" を選んで、プロジェクト名を決め、次の画面で、"An Application that supports MFC." にチェックを入れる。でした。
                親コメント
            • by Anonymous Coward

              もしもWin32 APIが標準化され、Microsoftが全てのWindowsで厳密にその仕様を守るのであれば、どんなに使いにくくても存在意義はあると思います。少なくともwine [winehq.com]は、その標準化Win32 APIを実装すれば完璧;-)ってことになりますし、Windowsアプリも「各種Windowsの実機で個別に動作確認」なんてばかばかしいことは必用無くなるはずですから。

              • by albireo (7374) on 2002年11月08日 10時48分 (#197074) 日記
                >それがうまく行くとwine全盛期に突入し、Windowsは不要になりますね:-)
                >あとはOpenOfficeが発展することでMS- Officeは不要になりますね。

                自覚があるかどうかわかりませんが、これは完全にアンチMSの思考ですね。
                「Win32 APIを標準化され…」によって得られるのは、WindowsとWineその他、MS-OfficeとOpenOfficeその他を対等に評価/選択できるということです。

                たとえばMS-OfficeとOpenOfficeがAPIやファイルフォーマットなどの互換性を損なわない形でまともな競争状態になれば、それ以外の機能やユーザインターフェイスなどで差別化を図ろうとするでしょう。われわれはその中から自分の目的にとって有利な方を選択すればいいという事です。(もちろんライセンスの内容なども評価の対象です)
                その結果としてMS-Officeを選択する方が有利である場合もあるでしょう。

                WindowsやMS-Officeが消えてなくなることでハッピーになるわけではありません。選択肢が増えること、選択に関わる制約が少なくなることでハッピーになるんです。
                --
                うじゃうじゃ
                親コメント
              • by Anonymous Coward
                >>それがうまく行くとwine全盛期に突入し、Windowsは不要になりますね:-)
                >あとはOpenOfficeが発展することでMS- Officeは不要になりますね。>
                >
                >自覚があるかどうかわかりませんが、これは完全にアンチMSの思考ですね。

                MS 自身の思考とも取れるかと。

                >選択肢が増えること
              • by albireo (7374) on 2002年11月09日 2時33分 (#197468) 日記
                >MS 自身の思考とも取れるかと。

                ああなるほど。
                MSが「必死だな」状態に陥っている理由を説明していたんですね。
                読み違えておりました。
                --
                うじゃうじゃ
                親コメント

私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson

処理中...