APIな環境という意味でしょうか?だったら判るけど、それなら回りくどくなく「Win32」といえば良いのに。環境といえば、もし今後GtkだのQtだのGNOMEだのKDEだのが隆盛してきたら、あれらは一応(^^;クロスプラットフォームですから、APIセットがOS環境を特定するとはいえなくなってきますね。GUIライブラリ「の」APIなわけでして。余談:というか、どこまでを「API」と呼ぶか、ですね。同じようにOSをラップする(^^;クラスライブラリという位置付けであるDelphi界隈ではVCLをAPIとは呼ばなかった(あっちでAPIといえばOSのほうのを指しますね)わけで、APIってなんじゃらほい?と思ってしまう昨今。---->でも、研究発表ではPowerPointとか使いますし、WORDの書類がメール添付で来ることもしょっちゅうなので、Windowsも使っこっちについては、幸い、FREEのOfficeソフトとかも出始めてますよね。OpenOffice.orgの日本の書籍(軽い感じの)が既に何冊か出ているのを見て、ちょっと嬉しかったです。#もちろん今はMSOfficeの書籍が無数にある中でのほんの数冊でしかないのですが。まあMSのとの互換性とかもまだまだ厳しいようです(俺も最近使ってみてます)が、将来に期待。#でもWYSIWYGなワープロ文書ってものを人間は、気がつけばソフト実装にバリバリ依存した書き方をしてしまうものだから、#完全互換ってのは険しい道のりだろうとは思いますけどね。Fontの寸法とかの微妙な処理の相違で#レイアウトががらっと狂ってしまったりする。1つ開くライブラリ関数は、引数の意味などおそらく違いますよね。(実は良く知りません。識者の訂正、お願いします。)で、関数名などから違っているでしょう。使えばそれらの違いを吸収してくれると聞いたことはあるのですが、それらが万能なのか、良く分かりません。関係のプリミティブが何で、どれがもっとも高速か、などが結構気になって、それによってプログラムの書き方が変わるのですが。使えばそれらの違いを吸収してくれると聞いたことはあるのですが、それらが万能なのか、良く分かりません。関係のプリミティブが何で、どれがもっとも高速か、などが結構気になって、>それによってプログラムの書き方が変わるのですが。関係ない話ですが、そういう問題については、アプリじゃなくライブラリレベルで解決したいですね。問題を吸収するか(それが不可能なら「切り分ける」か)をするライブラリを自作するとか、あるいは可能ならばそのライブラリ(QtはGPLだよね(^^;)がそういう問題を吸収あるいは切り分けする能力を強化するようなContributeをしてあげる、とか。「アプリごとに毎度工夫する」ってのは、ちょっとやってられないです。いやJavaのFileクラスは面白いです。メジャー(笑)な環境におけるFileの機能のうち、共通化できる部分だけを扱っている。意外な機能(^^;が不在だったりします。>万能なのか、良く分かりません。なんで「判らない」んだろう?既に判っている人が構築したライブラリなんだから、判ってる人に聞けばいいのに。OpenSourceなら、そういう情報を仕入れるのは比較的簡単なわけで。一般的に「APIで」プログラムするなんてことが、そうそう頻繁に有るものなのか?という疑問が、生じます。APIは必須になると思いますが。判るけど、それなら回りくどくなく「Win32」といえば良いのに。APIと同義?)を「直接は」使わない、って言っているように読めます。<違ったらごめんなさい。ラップしたクラスとか、もっと高次のものを使うのはもちろんありで、それがライブラリ(これも微妙な用語だ)を使ってプログラムするってことじゃないですか?極端な例ですがWin32APIを直に使ってウインドウを描画するってのは結構悲惨なコードですよね。いうことはしない、という意味かと。>cygwinやmingwでしかコンパイルできないソースcygwinやmingwでしかコンパイルできなくてもWin32上のプログラム足りえるものはできます。クロスコンパイル(のようなこと)をするにせよ、それはコンパイラがgccなだけで、至って普通のWin32プログラムだと思いますが?ところでcygwinだとforkとかpthreadとかの挙動が。(涙ちょっとエグめのことをやろうとするとLinuxマシンかVMwareが必要だったり。(#201744)>極端な例ですがWin32APIを直に使ってウインドウを描画するってのは結構悲惨なコードですよね。いうことはしない、という意味かと。職業か趣味か研究かに"拠らず"に、悲惨なコードは書かないほうが幸せでしょ、と思うんですが、それは変(&非実用的)、ですかね?そういう悲惨なのを逆に欲する考え方って、どっちかってーと、1:Fotran君(昔取った杵柄で、これしか知らないんだもん)2:assembler君(これのほうが速いんだ!ボクがPCを一番旨く使えるんだ!)くらいしか、思いつかないんですけど。どっちも非生産的ですね。#仕事に不利という意味だけじゃなく、人生(笑)における損失。パフォーマンスについてはそれが必要になる「仕事」があるのも判りますが、それこそ組み込みでもAssmは避けてCでやるってのと同じで、「(人生の損失を減らすためには)出来れば避けたい」ことですし、近年は避けるのが結構無理じゃなくなってきてるわけですし。APIは必須になると思いますが。Win純正(?)モノを作るときのプログラミング環境としてVC++とかを専ら連想する人にとっては、どうやらそういう世界が拓けているらしいですよね(笑)。俺は一言もVC++ともC++とも言っておりませんので。ちなむと例えばDelphiの世界はだいぶ違います。APIまみれに比べれば少しはお洒落なプログラミングがやれる世界ですんで、よろしく。いや、APIそのものはCレベルで定義されてるから、MFCを使うのがwin純正世界で一方VCLを使うのはそうではない、という論法は成り立たないはずですね。#MFCがMS製品かどうかは別問題。