2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

UNIXプログラマの為のWindows入門

1 :なんだ、こりゃ!!:02/03/06 22:26
いつも、Solaris,HP-UX,FreeBSD等でプログラムを作っています。
最近、業務上、どうしてもWindows上でのプログラムを作らなくては
いけない状況になりつつあります。
UNIXに慣れてしまったこの体、なんでいまさらWindowsって感じですが、
ここは一発、頑張りましょう。
って事で、UNIXプログラマの為の、Windowsプログラミングの手引き
のようなスレです。
UNIXの良き伝統に則り、みんなで知識を共有しませんか?


2 :板違い:02/03/06 22:39
>>1
プログラム板
http://pc.2ch.net/tech/
へGO

3 :名無しさん@Emacs:02/03/06 23:00
あくまでUNIX文化圏の発想を持ったままWindowsプログラミングを探検
するならいいネタじゃない?

とりあえず漏れのWindows体験。仕事上VBでプログラム作らなきゃいけ
なくなってCOMを触ってたんだけど、Collectionオブジェクトの実体が
さっぱり分からず気持悪い思いをした。ヘルプ見ても非プログラマ向け
の説明をタライ回しで読まされるだけだった。

IDLかC++のヘッダが見てえ! でも必死でGoogleしても見つからねえ!
こんな時UNIXなら「分からない事はソースに聞け」で解決なのに!
って感じで地獄でした。陸に上がった魚の気分。

何を探せばよかったですか?

4 :名無しさん@お腹いっぱい。:02/03/06 23:04
MSDNだな

5 :なんだ、こりゃ!!:02/03/06 23:07
WindowsっていうOSの根本思想というか、設計思想、アーキテクチャって
なんなんでしょう?
UNIXって、とりあえず、ファイル。
何をするにも、ファイル、ioctl ってイメージがあるんだけど。


6 :なんだ、こりゃ!!:02/03/06 23:09
あと、なんであんなにプログラム作るのが複雑なんだろう。
Visualなツール使ってみんなプログラム作ってるけど、
Visualなツールが自動的にやってることって、みんな理解してるのかな?
わたし、サパリわからないです。


7 :名無しさん@お腹いっぱい。:02/03/06 23:11
それって、VBのことですか?

8 :名無しさん@お腹いっぱい。:02/03/06 23:11
>5
MS Winつまりマイクロソフトが儲かる為のOS

9 :なんだ、こりゃ!!:02/03/06 23:18
VBに至っては、何がどうなってるのかサパリわからんです。
大体、main はどこ?って感じです。
VCだと、最初にプロジェクトを選択するじゃないですか。
んでもって、なんちゃらーってプロジェクトを選ぶと、テンプレート
が作成されますよね。
なんじゃコリャって感じなんです。


10 :名無しさん@お腹いっぱい。:02/03/06 23:21
winの統合開発環境は良いよなあ。。
KdeveloperやKylixのおもちゃみたいな出来をなんとかしろ

11 :なんだ、こりゃ!!:02/03/06 23:21
>>8
それは確かに正論です。
でも、これからWindowsを無視しては食っていけないと、危機感をもっています。
といっても、身についたUNIX的考えかたって、悪くはないと思うんです。
いかにして、発想の転換を行えばいいのか。(UNIX->Windows)
これが、問題です。(私にとってはね。)

12 :名無しさん@お腹いっぱい。:02/03/06 23:22
Delphiが良いですよ。わかりやすくて。
MSの余計で汚い部分はuses節で見えませんし、Visualとの関連もわかりやすいです。
linuxに逆に移植できるし。


13 :なんだ、こりゃ!!:02/03/06 23:23
>10
私も、あの統合環境は良く出来てると思います。
その反面、あの環境でないとプログラムを作れない自分にいらだちます。

14 :3:02/03/06 23:23
>>5
とりあえず「何でもオブジェクト(コンポーネント)」じゃないかな。オ
ブジェクト指向マンセ-の漏れとしては、その点はうらやましい。この辺の
事情は「Rubyを256倍使うための本 邪道編」が参考になる。

15 :なんだ、こりゃ!!:02/03/06 23:26
Windowsのプログラミングの肝って、Win32APIじゃないんでしょうか?
いわゆる、UNIXでいうシステムコール。
まず、システムコールを通して、OSの作りや、動作を理解していく。
それが出来て初めて、そのOSに合ったプログラムが作れる。
と思っているのですが。

16 :3:02/03/06 23:29
>>15
今のWindowsはWin32 APIを包み隠す方向に進んでるように見える(外か
らは)。.NET時代には邪魔な存在だろうし、オブジェクト指向の世界と
馴染まないよね。>Win32 API

17 :名無しさん@お腹いっぱい。:02/03/06 23:29
Visualのほうは、オブジェクトがWin32APIに包まれて隠れているので気にしなくても良いのでは?
必要なときだけ呼び出せば作れる。
問題なのはMSのバグがオブジェクトに隠れているのできちんと動いてくれないことが多いところ。

18 :なんだ、こりゃ!!:02/03/06 23:29
>14
MFCとかの本を読んでると、なんとなくオブジェクトのイメージが
沸いてくるのですが、Win32APIの本を読んでるとオブジェクト指向的な
考えが全く感じられません。
私って、逝ってよし?

19 :17:02/03/06 23:31
(正)Win32APIがオブジェクトに包まれて隠れているので

20 :3:02/03/06 23:32
>>18
単純に、先に存在していた古くて汚いWin32 APIを後の時代にオブジェ
クトの皮で隠蔽しただけだと思うよ。だからMSはWin32 APIを消したい
と思ってると思うんだけど。個人的に。

21 :名無しさん@お腹いっぱい。:02/03/06 23:33
とりあえず、.NETを用意してくれたんだから、
Win32APIやMFCのことは忘れようぜ。
そんなもんこれからやるのは馬鹿らしい。
まぁ適当に関わっていくならいいかもしれないけどね。

22 :なんだ、こりゃ!!:02/03/06 23:33
>17
そこなんですよ。
現在のUNIXって、統一的なオブジェクト指向なIFってないですよね。
(いわゆるクラスライブラリっていうのかな。)
OSへのIFがクラスの中に閉じ込められてるのが許せないってのがそもそもの間違い
なのかな?

23 :3:02/03/06 23:35
>>22
> OSへのIFがクラスの中に閉じ込められてる
これどういう意味? ちとわかんない。

24 :3:02/03/06 23:37
>>23
ああごめん、Win32 APIがMFCに閉じ込められてるって事か。その上の文
のUNIXの話の続きだと思った。

25 :なんだ、こりゃ!!:02/03/06 23:38
今後のMSの方針を考えると、Win32APIを直接使うプログラムは、
推奨しないということになっていくのでしょうか?

26 :17:02/03/06 23:39
そこら辺は諦めましょう。慣れだと思います。たかがWINDOWSなんですから。
私みたいなやつが多いから、こんな糞OSをみんな使わざるをえないのはしゃくですが

27 :なんだ、こりゃ!!:02/03/06 23:42
>>21
まだ、Windowsのプログラムを作り始めて数ヶ月です。
不勉強で申し訳ないのですが、.NETってなんですか?
もちろん、言葉は聞いたことがあるのですが、イメージが
全くつかめません。
イメージだけで結構です。教えていただけませんか?


28 :3:02/03/06 23:43
では、「UNIXプログラマが新しめのオブジェクト指向環境でWindowsプ
ログラミングする話」にしちゃってOK?

29 :名無しさん@お腹いっぱい。:02/03/06 23:45
>>27
ごくおおざっぱにいえばJavaのMicrosoftふう実装

30 :なんだ、こりゃ!!:02/03/06 23:50
>>28
OKです。
UNIXプログラマがWindowsでプログラムを作らざるをえなくなったとき、
どういう風に今までの考え方を変化させていかなければいけないか、
という部分について議論できれば最高です。

31 :なんだ、こりゃ!!:02/03/06 23:59
>>29
Javaというと、
プラットフォームに依存しない。
というイメージが一番強いのですが...


32 :名無しさん@お腹いっぱい。:02/03/07 00:05
>>31
いちおう他プラットフォームへの移植も
検討されてますが何か?

33 :名無しさん@お腹いっぱい。:02/03/07 00:11
でも仕様を決めるのはMicrosoft だよな。当然ながら。



34 :3:02/03/07 00:17
>>30
んじゃ遠慮なく。

まず変わらざるをえないのが情報の探し方だよね。

UNIXの場合はソースという一次情報源があって、正確な情報が知りたけ
ればソースを読むって手が使える。楽に済ませる場合はドキュメントや
MLの情報をあさるけど、真実が知りたきゃソースを読むしかない。後は
信憑性と時間コストのトレードオフでどの情報源を使うか決めるだけ。

でもWindowsプログラミングでは大抵のソースは読めない。MSのドキュ
メントや一般開発者のメモ等の二次情報をあさったり、ブラックボック
スをいじり回す事になる。

UNIXのソースに相当するような信頼性の高い情報はどうやって得たらい
いのか? ってのが俺の課題かな。

35 :名無しさん@お腹いっぱい。:02/03/07 00:24
かーごめかごめ かーごのなーかのとーりーはー いーついーつーでーやーるー

STABLEじゃないと思うぞ.NET
しかもOPENSOURCEでも、「常識ですね」でもない世界。
あの環境の呪縛から逃げるには、やっぱWin32APIしかないと思うのだが。


36 :名無しさん@お腹いっぱい。:02/03/07 00:28
>>35
もう無理だよ。やるっていってるんだから
普及させるんだろ。それにそれほど悪いものでも
ないと思うんだが。

37 :名無しさん@お腹いっぱい。:02/03/07 00:30
>>36
う〜ん だってあれってj2ee+CORBAでもなんとかなっちゃいそうなんだもん
MSの通信系ってDOSの頃から信用してねーもん

38 :名無しさん@お腹いっぱい。:02/03/07 00:55
>>34
MSにお布施しまくって常に最新のMSDNとかMSJとかを読みまくる。
位しかないんじゃない?

俺なんかも含め、びんぼー人は
>MSのドキュメントや一般開発者のメモ等の二次情報をあさったり、ブラック
>ボックスをいじり回す事になる。
しかないと思うけど。

# だから中途半端な金持ちはMSまんせーになりがちなのかね

39 :38:02/03/07 01:00
あ、最後の1行が意味不明だった。
まんせーっていうか質問しても「MSDN見ればいいんじゃないですか?」
しか言わないやなやろーが多い(と思う)ってことで。

まぁhelpはPlatform SDK落とせばいいだけだけど、MSJに載ってる
ような技術資料は会員にならないと見れないし。

40 :名無しさん@お腹いっぱい。:02/03/09 17:27


41 :名無しさん@お腹いっぱい。:02/03/09 17:50
>>34
Windowsプログラミングの場合、その2次情報が多いし。
いいんじゃない?

ソースが常にある環境は確かにうらやましいけど
最終的にソースに 頼る のはプログラマとしては
前時代的で長い目で見た場合の効率はよくないと思ってる。

だって、何のためのドキュメントなのよ。
man ls が信用ならないからってソースを見る人もいないしね。

42 :名無しさん@お腹いっぱい。:02/03/09 18:19
>>41
ごめん・・・みてたm(_ _)m < lsのソース


43 :名無しさん@お腹いっぱい。:02/03/09 18:32
>41
そのドキュメントが信頼置けんからな…
バージョンによる挙動の違いをMSDNからは読み取れないと思うけど?
# immとかwininetとか悲惨の一言。使う奴が馬鹿だって? そりゃないよ…


44 :名無しさん@お腹いっぱい。:02/03/09 19:11
>>41
ls(とも限らないが)の結果の間違いが致命的なら、ソースを見ると思う。
>>34の言うとおり、トレードオフでしょ。

45 :名無しさん@お腹いっぱい。:02/03/09 19:11
>>43
そうなると信用できそうなのはlibcとWin32APIくらいになっちまうのよな。
(ん?Windowsではlibcっていわずに標準Cライブラリって呼ばんといかんかったか)

46 :41:02/03/09 19:42
>>42
あーおれも見たことあるや。すまん。
標準出力とリダイレクトの動作の違いがマニュアルから読み取れなくて・・・

47 :名無しさん@お腹いっぱい。:02/03/10 20:59
だいたいUNIX系のはマニュアルがしょぼい。
「ボランティアで書いてんだからしょーがねーだろ」
「これで判らなかったらソース見ろバーカ」
っていう態度がありありと見てとれて、むかつく。

48 :名無しさん@お腹いっぱい。:02/03/10 21:02
>>47
フリーのUnixの場合は、だよね?

49 :名無しさん@お腹いっぱい。:02/03/10 21:40
>47
MSDNに金払ったところで、この内容で判るかボケって感じだよな。
結局動かしてみて挙動を追うしかない、ソースがあるとないとでは大違い。

50 :名無しさん@お腹いっぱい。:02/03/11 01:41
MFC使ってみようと思ってMSDNのドキュメントとか読んだが、
結局わからなくてソースを読んだ。
マニュアルがあるに越したことはないが、
やはり最後はソースだと。

51 ::02/03/11 15:02
ソースがあっても、果たして理解できるんだろうか?
> Windows
だいたい、Win32APIって何種類ぐらいあるんだろ?
どんどん増えていってるのか?もしかして。

あと、INVALID_SOCKETはやめれ。
ソケットIFぐらい周りとあわせろ。

52 :名無しさん@お腹いっぱい。:02/03/21 23:43
age

53 :名無しさん@お腹いっぱい。:02/03/22 09:07
>>50
みんなcodeguruあたりから適当にコピペしてるんですよ。


54 :名無しさん@お腹いっぱい。:02/04/01 00:51
>>51
構わず -1 使ってますが何か?

というか むしろ WSA 系の方を使ってほしいんでは。


55 :名無しさん@お腹いっぱい。:02/04/01 01:06
http://www.zdnet.co.jp/news/0203/01/e_cheappc.html

56 :名無しさん@お腹いっぱい。:02/04/01 01:13
「プログラミングWindows95」
http://www.amazon.co.jp/exec/obidos/ASIN/4756117171/qid=1017591056/sr=1-9/ref=sr_1_2_9/250-8988679-1953819

この本、大分前に買って埃かぶってるんですけど、今でも読む価値ある?

57 :名無しさん@お腹いっぱい。:02/04/01 01:27
>>56
Win32プログラムの基本的な構造は今も変わっていないから
これから始めるのなら一読の価値あり。

58 :名無しさん@お腹いっぱい。:02/04/01 01:34
56>>57 んじゃ勿体無いので読みます。しかし分厚いから読みにくいんだなこれが。

59 :57:02/04/01 02:08
>>58
読んでおくべきなのは頭から1/3ぐらいまで。
後は必要に応じて拾い読み。

今の版は2分冊になっているから、読みにくかったらそっちを買えば
少しは薄くなって読みやすくなるんでない? (藁

60 :名無しさん@XEmacs:02/04/02 00:23
> ソースがあっても、果たして理解できるんだろうか?
> > Windows

普通無理だな。
Windows向けのCのソース見てると混乱する。
お前どこからでてきたねん! って感じで。
UNIXでのプログラミングに比べて数段難しい。

多分GUIはWinの方が楽なんだろうけど。

61 ::02/04/03 23:07
>>54
-1 で、ちゃんと動いてる?
Winsock1.1使って、VC++でDLL作って、それを
VBから使ってたんです。
ずーっと動かしてるとだんだん重ーくなってくるんよ。
何回も、何回も、繋いで、切ってってやってるとね。
んで、-1 やめたら、なんか直ったみたい。



62 :名無しさん@お腹いっぱい。:02/04/24 23:00
http://www.kumei.ne.jp/c_lang/
windowsSDKについては、ここかなぁ。

63 :名無しさん@Emacs:02/04/24 23:12
VC++の起動時のTipsで
「VC++はVC++で開発されました」
と書いてあったんだけど「だから何?」と思った

というか最初のVC++はMS-Cで書いたと思われた
あまりにもUNIXから離れたのでsage


64 :某国製品の奴隷:02/04/25 02:03
>63
DelphiもObjective PascalだしJbuilderもJavaで開発されてますな。
あ、どっちも IDEだけだけど。

ほんとにどうでもいい話だが。


65 :名無しさん@お腹いっぱい。:02/04/26 18:48
ところで皆さん、ハンガリー記法ってどうですか?
変数名のプレフィクスに i だの lp だのと型名をつけるやつ。

漏れは覚えたのがWindows→UNIXだったもんで、ついUNIXでも
ハンガリー記法で書いてしまうですよ・・・鬱。
でもって、他のソース読むときも「変数名にプレフィクスつけて
くれないかな」と思ってしまう始末。

すっかりシモニーたんに支配されてます。うぅ・・・

66 :名無しさん@お腹いっぱい。:02/04/26 19:21
(´-`).。oO(きっとSoftware Designを読んだのだろう)

67 :名無しさん@お腹いっぱい。:02/04/26 19:43
漏れは、最近Windowsプログラマーから、UNIXプログラマに転向した。
正直言って、カルチャーショックだね。
UNIXのシステムコールの少なさに唖然。
Win32APIなんか1000個くらいあるが、漏れほぼ全部わかる。でも人生の無駄だった。
ネットワーク系のプログラムや、サービス(デーモン)のプログラムなんか、Windowsはめちゃ難しくて手間がかかる。
そんなにUNIX詳しくないので、えらそーなことは言えんが、
システムコールやライブラリレベルで、Windowsが明らかに勝っているのは、
ACL, SAM, ファイルロックくらいかな。
それ以外は、UNIXマンセーだね。
WindowsでSTLなんて使おうとしたら、ブービートラップがいっぱい。
正直、WindowsでSTLは使いものにならない上に、意図的に隠されている。
MFCのCStringクラスや、CArrayクラスなんか、STLを覚えた今の頭で考えると、もう最悪。
今では、STLを隠されていたいたことに怒り爆裂だ。


68 :名無しさん@お腹いっぱい。:02/04/26 20:37
>>67
スレッド周りもWin32の方が扱いやすいと思うなぁ。
mutex, semaphore, eventいずれも区別無しでWaitFor〜()で待ち合わせ
できるし。socket descriptorがハブにされてるのはアホだけど。

69 :名無しさん@お腹いっぱい。:02/04/26 21:17
>>67
というかそれはWindowsの問題ではなくVC++の問題だと思う


70 :名無しさん@お腹いっぱい。:02/04/27 00:14
>>69
STL云々って部分はね

しかしMFCのコンテナなんかは、わざと使いにくくしたとしか
思えないよなー

Win32APIのなかには概要を覚えたつもりでも恐ろしい罠が
待ち受けていたり、構造体がしこたま必要だったりするので....




71 :67:02/04/27 00:21
>>68
Win32のスレッド周りは、APIとTLSとCランタイムの関係がよろしくないのが問題。
あれで、どつぼにはまる人多数。
MSは、Cランタイムを駆逐して、全てAPIや.NETにしようとしている。

>>69
その通り。でも現実問題として、通常用途のお仕事用はVC++しか無いし・・・

72 :68:02/04/27 01:41
>>71
まぁ確かにmsvcrt.dll使う場合は_beginthreadex()使えだの、MFC使う
場合はAfxBeginThread()使えだのややこしいけど、それぞれのライブラリ
内で使ってるTLS初期化用にそれらを使わなきゃいかんのねぇ、ってのが
理解できれば(実装が汚いというのは置いとけば)別にどうって事ないと思う
けど。他になんか問題あるっけ?

>MSは、Cランタイムを駆逐して、全てAPIや.NETにしようとしている。

Unixだって昔からいろんなライブラリあるけどね。
ただ、Winの場合設定がレジストリだし、ログ出力もイベントログにAPIで
通知だしで、「APIが無いと非常にいじりにくい」ってだけでしょ。

73 :68:02/04/27 01:54
>「APIが無いと非常にいじりにくい」ってだけでしょ。

ごめん。「だけでしょ」ってのは撤回。
COM関係だと「API使わないといじりようがない」もんね。

74 :名無しさん@お腹いっぱい。:02/04/27 02:10
横入りスマソ。TLSって何?
ググってみたらThread-Level Speculationってのが引っかかったけど話の流れ的に違いそう。
Thread Level Stateか何か?

75 :名無しさん@お腹いっぱい。:02/04/27 02:54
>>72
ヤヴァいAPIやAfx関数なんか使うとスレッドの解放時に、
スタック領域が残ったりすると思われ

漏れの場合は長ったらしいAPIを呼びまくってる中に
ふとC標準ライブラリのコールを見ると、場違いな気がしてくる
ラスベガスで寿司屋を見つけたような。



76 :名無しさん@お腹いっぱい。:02/04/27 04:41
>>74
Thread Local Storage。


77 :74:02/04/27 07:29
>>76
アリガト。

78 :68:02/04/27 07:35
>>74
TLSは「スレッド毎に別々の値を保持できるグローバル変数」というとイメージ
しやすいかな。APIとしてTLSAlloc()なんか使う方法もあるけど、VC++だと
コンパイラサポートがあるので、本当にグローバル変数そのものをTLSとして
定義できちゃう。

まぁ俺は普通スレッド毎の管理/ワーク領域作って親スレッドで一括管理する
ように作るんで、自分でTLS操作した事もVC++のTLSサポートも直接使った事
は無いけど。

>>75
スタックが残るようなのってTerminateThread()とかでしょ?
これは最初から「そういうもんだから最終手段としてしか使うな」ってヘルプ
に書いてあるんだから、使う方が悪いつーか。
デザインとしてなんかダサいってのは分かるけど。

79 :名無しさん@お腹いっぱい。:02/04/29 13:26
api の名前がダサダサ

80 :名無しさん@お腹いっぱい。:02/11/04 05:19
アピ━━━━━━━(゚∀゚)━━━━━ !!!!!

81 :Win:02/11/04 11:47
UNIXにもAPIがあるの?


82 :名無しさん@お腹いっぱい。:02/11/04 12:10
>>81
ばーか、氏ね!

83 :名無しさん@お腹いっぱい。:02/11/04 14:52
>>73
Windows は、そもそもシステムコール相当の「カーネルへのエントリ
ポイント」(Windows NT 系列だと NTDLL.DLL あたりに書いてある)
は非公開だから、API を使わんことにはどうにもならんよね。

どっちが優れてるって話じゃなく、単に文化の違いだと思うけど。

>>78
UNIX というか POSIX Thread だと、TLS 相当の機能は pthread_getspecific()
を使って書くよね。VC++ のようにコンパイラのサポートがないから、さすがに
グローバル変数を勝手に TLS に割り当て、なんつー真似はできんけど。

84 :山崎渉:03/01/15 13:23
(^^)

85 :名無しさん@お腹いっぱい。:03/02/04 01:58
UNIXからrcpでWindows2000からコピーしたいのですが、あれってリソースキットを
入れるだけで動くかご存知ないでしょうか?
あ〜.hostsもありますねぇ。

86 :山崎渉:03/03/13 17:57
(^^)

87 :山崎渉:03/04/17 12:20
(^^)

88 :あぼーん:あぼーん
あぼーん

89 :あぼーん:あぼーん
あぼーん

90 :あぼーん:あぼーん
あぼーん

91 :あぼーん:あぼーん
あぼーん

92 :名無しさん@お腹いっぱい。:03/10/08 22:24
age

93 :名無しさん@お腹いっぱい。:03/10/09 06:21
まずVMSを徹底的に勉強する。
次にホイールマウスの使い方を覚える。
そしてWindowsUpdateを実行する。

94 :名無しさん@お腹いっぱい。:03/10/26 11:01
age

95 :名無しさん@お腹いっぱい。:04/10/03 01:51:17
おおう、一年ぶり。
>>1 は見事にWindows プログラマになり切れたのだろうか?
それとも、いつの間にか古巣に戻って来てしまったのか?
まぁ、このスレの閑散ぶりからすると、戻れない河を渡ってしまったんだろうな。
さらば、 >>1

96 :名無しさん@お腹いっぱい。:04/10/07 22:05:13
>>95
よく一年も経ってから彫り上げたな・・・

97 :1:04/10/07 22:39:26
もうUNIX使わなくなりました。

98 :名無しさん@お腹いっぱい。:04/10/07 23:30:16
>>97
裏切者め地獄の業火に投げ込まれるてしまえ

99 :名無しさん@お腹いっぱい。:04/10/08 00:05:10
るてしまえ

100 :ネット代月6万:04/10/19 00:12:33

       /\___/ヽ
    /ノヽ       ヽ、
    / ⌒''ヽ,,,)ii(,,,r'''''' :::ヘ
    | ン(○),ン <、(○)<::|  |`ヽ、
    |  `⌒,,ノ(、_, )ヽ⌒´ ::l  |::::ヽl
.   ヽ ヽ il´トェェェイ`li r ;/  .|:::::i |
   /ヽ  !l |,r-r-| l!   /ヽ  |:::::l |
  /  |^|ヽ、 `ニニ´一/|   ^|`,r-|:


101 :名無しさん@お腹いっぱい。:04/11/15 21:11:36
>>100
Yahoo BB HIKARI にしろよ・・・マジお薦め。

102 :名無しさん@お腹いっぱい。:2005/11/15(火) 00:10:33
>>101
こんな見えないところでわざわざ工作ご苦労様

103 :名無しさん@お腹いっぱい。:2005/11/15(火) 20:53:03
こちとら生粋のWindowsプログラマー!
だがWin32APIを直接呼んだことなんて一切無ぇとくらあっ!

104 :名無しさん@お腹いっぱい。:2005/11/18(金) 22:52:59
Windowsは歴史に無頓着なものかもしれないけど、
でも設計的にはUNIXを綺麗にまとめたものだったりしない?
カーネルオブジェクトと概念をひとまとめにしてある辺りは、
アプリケーションプログラマの頭の負担も少ないと思う。

105 :名無しさん@お腹いっぱい。:2005/11/18(金) 23:05:36
でもまあ一見して概念的に綺麗になっているものこそ、
齟齬をきたしているケースも多々あるから一概には言えんか。

106 :名無しさん@お腹いっぱい。:2005/11/18(金) 23:19:25
Win32 のシステムコールインターフェースは結構きれい。
というか、UNIX のものとほとんど変わらん。
CreateProcess 系は全然違うけど。Win32 は fork() を
使わないから、かなり複雑。ここはポリシーの違いなので、
どっちがいいとも言い難いけど。

Win32 の GUI 系のプリミティブ、特にイベント回りは、
Win16 との互換性のためにかなり汚い。まあメッセージ
クラッカーとか使えば隠蔽できるし、MFC 使ってれば
気づかないけどね。

107 :名無しさん@お腹いっぱい。:2006/11/14(火) 02:35:12
保守あげ

26 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)