アカウント名:
パスワード:
もしもWin32 APIが標準化され、Microsoftが全てのWindowsで厳密にその仕様を守るのであれば、どんなに使いにくくても存在意義はあると思います。少なくともwine [winehq.com]は、その標準化Win32 APIを実装すれば完璧;-)ってことになりますし、Windowsアプリも「各種Windowsの実機で個別に動作確認」なんてばかばかしいことは必用無くなるはずですから。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲ以上のなにものでもなさげ -- アレゲ研究家
主観ですぎ (スコア:2, 興味深い)
勝ったの負けたの言い出すあたり気持ち悪いのですが・・・
「勝った」というのは、あれですか、憎き帝国主義のM$を
我らがオープンソース同盟が打ち破ったみたい
Re:主観ですぎ (スコア:1)
Re:主観ですぎ (スコア:0)
Win32 APIってカバーしてる範囲が広すぎて、もはやPOSIXとかと比較するのは適切じゃない気がするんですけど。まぁ「それでも敢えてPOSIX APIだけでやっていこうぜ」という話であれば「そうか。がんばれよ」としか言えませんが。
UNIXの世界では、GTKやQTの例を引くまてもなくPOSIXやUNIX由来の標準的APIの上に乗せるレイヤは混沌とした状況ですよね。その中でWin32 APIはこれだけの市場や開発者を持っているわけですから、Win32 APIを消し去るよりは、IEEEとかISOとかがWin32 APIを厳格・厳密に標準化してくれた方が幸せな人が増えるんじゃないかと思いますけど。
Re:主観ですぎ (スコア:1)
誤解を招きました。
Win32 API は POSIX にくらべ範囲が広いですが、基本的な部分でいやなものが多すぎます。それは、Win32 API 自身が全体的にシンプルじゃないことがあげられます。
私は、 "Keep It Simple, Stupid !" [cruel.org] を心がけながらコーディングしています。あと、 ソースコードがドキュメントだ、バグも全て記述されている [u-netsurf.ne.jp] 。もです。
これら、複雑すぎじゃありませんか ?
>> IEEEとかISOとかがWin32 APIを厳格・厳密に標準化してくれた方が幸せな人が増えるんじゃないかと思いますけど。
それが、標準にでもなったら標準化委員会の頭を疑うぜ。
Re:主観ですぎ (スコア:1, 参考になる)
>> これら、複雑すぎじゃありませんか ?
別にプログラムで飯食ってるわけじゃないので、以前は「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の実機で個別に動作確認」なんてばかばかしいことは必用無くなるはずですから。
Re:主観ですぎ (スコア:1)
>> もしもWin32 APIが標準化され、Microsoftが全てのWindowsで厳密にその仕様を守るのであれば、どんなに使いにくくても存在意義はあると思います。少なくともwine [winehq.com]は、その標準化Win32 APIを実装すれば完璧;-)ってことになりますし、Windowsアプリも「各種Windowsの実機で個別に動作確認」なんてばかばかしいことは必用無くなるはずですから。
そうですね。同意します。
Re:主観ですぎ (スコア:0)
> API のパラメータの多さはやはりチェック項目になってしまうので、こういう微妙な動きをされると、
> 創造的活動からはなれ、ひたす
Re:主観ですぎ (スコア:1)
CString tmp;
で、
error C2065: 'CString' : undeclared identifier
と出てしまいす。もし、コンソールアプリで、MFC 関数か使用できるならその情報へのポインタ。ここで調べろ。など、すみませんが誰か教えてください。
Re:主観ですぎ (スコア:1)
使えます。
VC++なら、普通はAppWizardでワークスペース作るときに
「MFCのサポート」だかなんだかをチェックするんだけど、
後付けならコンパイルオプションを変える必要があるかな？
MSDNの「MFC 実行可能 (.EXE) プログラムのビルドの設定」あたりを見ればいいかな。
＃AppWizardでMFCを使える新しいワークスペースを作って、
＃そこにファイルを追加してくほうが早いかも。
Re:主観ですぎ (スコア:1)
キモは
・#include ＜afxwin.h＞ 宣言、
・AfxWinInit(::GetModuleHandle(NULL), NULL, ::GetCommandLine(), 0) をmain関数で実行、
・プロジェクト設定→一般→MFCを使用 と設定
とするとできるみたいです。
まあ、MFCを使うDLLを作ってそれを使う、ってのでもいいと思うんですが…。
はすかわ
Console で MFC (Re:主観ですぎ (スコア:1)
AppWizard で、"Win32 Console Application" を選んで、プロジェクト名を決め、次の画面で、"An Application that supports MFC." にチェックを入れる。でした。
Re:主観ですぎ (スコア:0)
Re:主観ですぎ (スコア:1)
>あとはOpenOfficeが発展することでMS- Officeは不要になりますね。
自覚があるかどうかわかりませんが、これは完全にアンチMSの思考ですね。
「Win32 APIを標準化され…」によって得られるのは、WindowsとWineその他、MS-OfficeとOpenOfficeその他を対等に評価/選択できるということです。
たとえばMS-OfficeとOpenOfficeがAPIやファイルフォーマットなどの互換性を損なわない形でまともな競争状態になれば、それ以外の機能やユーザインターフェイスなどで差別化を図ろうとするでしょう。われわれはその中から自分の目的にとって有利な方を選択すればいいという事です。（もちろんライセンスの内容なども評価の対象です）
その結果としてMS-Officeを選択する方が有利である場合もあるでしょう。
WindowsやMS-Officeが消えてなくなることでハッピーになるわけではありません。選択肢が増えること、選択に関わる制約が少なくなることでハッピーになるんです。
うじゃうじゃ
Re:主観ですぎ (スコア:0)
>あとはOpenOfficeが発展することでMS- Officeは不要になりますね。>
>
>自覚があるかどうかわかりませんが、これは完全にアンチMSの思考ですね。
MS 自身の思考とも取れるかと。
>選択肢が増えること
Re:主観ですぎ (スコア:1)
ああなるほど。
MSが「必死だな」状態に陥っている理由を説明していたんですね。
読み違えておりました。
うじゃうじゃ