おまえらCOMぐらい知っとけ

このエントリーをはてなブックマークに追加
1 ：sage：
漏れはよく知らんが。
とにかく知っとけ。根拠はない。
2 ：e：02/07/26 17:04
2
3 ：仕様書無しさん：02/07/26 17:04
COM1：とかCOM2:とかのことか？
4 ：仕様書無しさん：02/07/26 17:05
Carry On Musicの略。
5 ：仕様書無しさん：02/07/26 17:07
USのIPアドレス
6 ：sage：02/07/26 17:08
オブジェクト指向>コンポーネント指向
これからわな
7 ：sage：02/07/26 17:09
すまん逆
オブジェクト指向<コンポーネント指向
8 ：仕様書無しさん：02/07/26 17:10
フレーム試行>オブジェクト指向>コンポーネント指向
これからわな
9 ：仕様書無しさん：02/07/26 17:13
>>8
フレーム指向ってなに？
構造化プログラミングのことか？
10 ：仕様書無しさん：02/07/26 17:16

　　∧＿∧
　 （　・∀・）　　　|　|　ｶﾞｯ
　 　　　　）　 　 |　|
　　 Ｙ　/ノ　　　 人
　　　 /　）　 　 < 　>__Λ∩
　 ＿/し'　／／. Ｖ｀Д´）/ 　←1
　（＿フ彡　　　　　 　　/
11 ：仕様書無しさん：02/07/26 17:20
>>9　煽りまくりという事。
12 ：仕様書無しさん：02/07/26 17:21
>>9
comなんていうのなら、.NETぐらいしっとけ。
13 ：仕様書無しさん：02/07/26 17:52
そのうち org も出てくるとか？



gTLDとの区別が・・・
14 ：仕様書無しさん：02/07/26 18:01
悲しいとき〜
　悲しいとき〜
あ、ごめん。
15 ：仕様書無しさん：02/07/26 18:04
>14
おまえVisualBasic大王にも逝ったろ。
16 ：仕様書無しさん：02/07/26 18:06
コムドーム
17 ：仕様書無しさん：02/07/26 18:08
64Kの壁・・・
18 ：仕様書無しさん：02/07/26 19:08
2Gの壁･･･
19 ：仕様書無しさん：02/07/26 19:47
Crack Of Macintosh.
厨の聖典やね…
20 ：仕様書無しさん：02/07/26 19:53
COMねえ、・・・あほか　＞１
21 ：仕様書無しさん：02/07/26 21:07
今は.NETの時代だろ？
ていうか今ごろCOMってか
22 ：仕様書無しさん：02/07/26 21:08
昔、テキストファイルなのに、comファイルとして実行出来る
ってツールがあったけど、どういう原理？
23 ：仕様書無しさん：02/07/26 21:09
>>1は周回遅れ
24 ：仕様書無しさん：02/07/26 21:09
ここですか？エージェント指向をCOBOLに取り入れている悲惨な２２のいるスレは？
25 ：仕様書無しさん：02/07/26 21:11
MSにも見放された悲惨なCOM、、、
EssentialCOMを必死で勉強したヤシは怒り心頭だろうな
26 ：仕様書無しさん：02/07/26 21:21
そういうやしにCOMを聞くと決まって長いうんちくをたれやかるニダ
27 ：仕様書無しさん：02/07/26 21:22
昔あった漫画雑誌のことですか？
28 ：仕様書無しさん：02/07/26 21:26
混同くんに聞いてやれ。
Windowsのことなら詳しいと自慢しているから。
３７歳童貞でヒッキーの無職だけど
きっと頼りになるから。
29 ：世界一のうんこ：02/07/26 22:06
>>1
ひとつのセグメントしか使えない、あれのことですか。
30 ：仕様書無しさん：02/07/26 23:46
PLAYER vs COM
31 ：仕様書無しさん：02/07/27 15:53
C:\>DIR
32 ：仕様書無しさん：02/07/27 16:31
混同くんに聞いてやれ。
Windowsのことなら詳しいと自慢しているから。
３７歳童貞でヒッキーの無職で、MFCも.NETも理解できないロートルだけど
きっと頼りになる。
33 ：仕様書無しさん：02/07/27 16:34
混同くんに聞いてやれ。
Windowsのことなら詳しいと自慢しているから。
３７歳童貞でヒッキーの無職の粘着で、
MFCも.NETもOOPも理解できないロートルだけど
きっと頼りになる。
34 ：仕様書無しさん：02/07/28 00:27
TEST.COM
TEST.BAT
TEST.EXE
TEST.CMD

これらが同じディレクトリの存在して、
＞TEST
とすると、TEST.COMが起動するから、COMが一番偉い！
35 ：仕様書無しさん：02/07/28 00:29
>>34
その理屈でいくと、君より早く起動（誕生）した年寄りコボラーは君よりえらいということか？
36 ：仕様書無しさん：02/07/28 00:31
老人は大切にしましょう。
37 ：仕様書無しさん：02/07/28 00:32
年長者には礼をつくせ

ってそうか？誕生した順に優先してコマンドプロセッサは処理するのか。
38 ：仕様書無しさん：02/07/28 00:37
確かにタイムスタンプは関係無いな。
39 ：仕様書無しさん：02/07/28 00:42
「お台場どっと混む」のことですか？
40 ：仕様書無しさん：02/07/28 00:45
住友3COM
41 ：仕様書無しさん：02/07/28 00:53
>>34
COMは制限が多すぎる。
42 ：仕様書無しさん：02/07/28 01:14
>>34
BAT が最初に起動されるのだ。
43 ：仕様書無しさん：02/07/28 01:23
>>42
Win2Kのこまぷろは、COMのほうが強かったぞ？
44 ：仕様書無しさん：02/07/28 04:25
「マンガエリートのためのマンガ専門誌」か? 懐かしいが板違いだな。
45 ：近藤君＠本物 ◆ccEetFnM ：02/07/29 05:28
ＣＯＭの全貌は理解した。
後は、ＶＣで実践あるのみ＞Ｋ仲川氏
46 ：仕様書無しさん：02/07/29 23:13
「火の鳥」が連載されていた雑誌？
47 ：仕様書無しさん：02/09/15 15:22
>>1
逝っていいよ　　　　　
48 ：仕様書無しさん：02/09/22 21:48
先にビョーキ直すのに専念しな（ワラ　>>45
49 ：仕様書無しさん：02/09/23 00:42
それよりも時代は.NETだぞ。混同
50 ：仕様書無しさん：02/10/30 04:10
こんなスレに貼っても意味ないじゃんとか言ってみるが
ttp://www.asahi-net.or.jp/~kv8s-yjm/another/yjamain.htm
51 ：仕様書無しさん：02/10/30 07:53
J-COM
52 ：仕様書無しさん：02/10/30 12:28
クソスレかと思ったが、>>50のおかげで漏れ的には良スレになった。

漏れがMFCで悪戦苦闘してるうちに世間は OLE → COM(ActiveX) → .NET だもんなー。
どいつもこいつもMFCかVB前提で悲しかったよ。

今のところCとWindowsAPIでしこしこ書いてるけど、次のVC++あたりでWindowsAPIの
サポートがなくなるんじゃないかと戦々恐々。。。
53 ：仕様書無しさん：02/11/04 19:58
command.com ?
54 ：仕様書無しさん：02/11/12 09:58
COMｧったちゃん
55 ：fujianasan：02/12/15 16:05
ははは
56 ：211.155.198.7：02/12/15 16:08
ぶわははは
57 ：山崎渉：03/01/15 17:43
（＾＾）
58 ：４−４＝４　　　　　　　　　　　　　　　1st ◆VZ.CboVnb2 ：03/01/15 20:37


59 ：　　　　　　　　　　　　　　　　　　　　2 ◆VZ.CboVnb2 ：03/01/15 20:39


999
60 ：４−４＝４　　　　　　　　　　　　　　　1 ◆VZ.CboVnb2 ：03/01/15 20:40
0
61 ：　　　　　　　　　　　　　　　　　　　　　2 ◆VZ.CboVnb2 ：03/01/15 20:42
99
62 ：　　　　　　　　　　　　　　　　　　　　　2 ◆VZ.CboVnb2 ：03/01/15 20:46
　 ４
返し

なクな
り　 ケ

り　 し

　 し
ばらク
63 ：４−４＝４　　　　　　　　　　　　　　　1 ◆VZ.CboVnb2 ：03/01/15 20:47
i
64 ：　　　　　　　　　　　　　　　　　　　　　2 ◆VZ.CboVnb2 ：03/01/15 20:48


65 ：　　　　　　　　　　　　　　　　　　　　 2 ◆VZ.CboVnb2 ：03/01/15 20:49
0987
66 ：仕様書無しさん：03/01/18 12:10
COM って DOS だろ。
Linux なら /dev/cua/0 とかだ。
67 ：仕様書無しさん：03/01/18 12:43
OLEの方がまし。
68 ：山崎渉：03/03/13 18:17
（＾＾）
69 ：山崎渉：03/04/17 12:35
（＾＾）
70 ：山崎渉：03/04/20 06:04
　　 ∧＿∧
　　（　　＾＾ ）＜ ぬるぽ（＾＾）
71 ：山崎渉：03/05/22 02:37
━―━―━―━―━―━―━―━―━[JR山崎駅（＾＾）]━―━―━―━―━―━―━―━―━―
72 ：仕様書無しさん：03/05/31 04:43
http://www.yomiuri.co.jp/entertainment/tv/tv03051401.htm
“電波少年的”異色ＦＭ番組　３局共同制作「ＯＬＥっち」
73 ：仕様書無しさん：03/05/31 05:20
COM はいいよなぁ
リロケータブルで・・・
一つのセグメントに収まって・・・
そこいくとなんだあのEXEとかいう醜悪なモノは
74 ：仕様書無しさん：03/05/31 05:39
COMはめんどい。作るのが。
75 ：仕様書無しさん：03/05/31 09:51
>>74
EXE2BIN で一発やん
76 ：山崎 渉：03/07/15 11:43

　__∧＿∧_
　|（　　＾＾ ）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣
77 ：なまえをいれてください：03/07/25 17:59
ハッキリ言ってアメリカなどの多民族国家では黒人の方がアジア人よりもずっと立場は上だよ。
貧弱で弱弱しく、アグレッシブさに欠け、醜いアジア人は黒人のストレス解消のいい的。
黒人は有名スポーツ選手、ミュージシャンを多数輩出してるし、アジア人はかなり彼らに見下されている。
(黒人は白人には頭があがらないため日系料理天などの日本人店員相手に威張り散らしてストレス解消する。
また、日本女はすぐヤラせてくれる肉便器としてとおっている。
「○ドルでどうだ？(俺を買え）」と逆売春を持ちかける黒人男性も多い。）
彼らの見ていないところでこそこそ陰口しか叩けない日本人は滑稽。
78 ：山崎 渉：03/08/02 02:54
　　 ∧＿∧
　　（　　＾＾ ）＜ ぬるぽ（＾＾）
79 ：仕様書無しさん：03/08/14 04:33
MSBLAST で話題になってますけど、DCOM RPC 脆弱性って、なんですか？
80 ：仕様書無しさん：03/08/14 04:54
>>79
ここはマ板なんだが（藁
字見てわかるじゃねーか
81 ：79：03/08/14 23:32
だから、何ですか？それ
82 ：仕様書無しさん：03/08/15 01:23
コムぴゅーたー
83 ：仕様書無しさん：03/08/15 01:24
とりあえず脆弱は普通の日本語
84 ：山崎 渉：03/08/15 22:42
　　　 (⌒V⌒)
　　　│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン
85 ：仕様書無しさん：03/10/05 10:56
COM age
86 ：仕様書無しさん：03/10/08 01:22
COM COM えぶりぼでぃ
87 ：仕様書無しさん：03/10/08 12:10
>>86
スネークマンかよ！
88 ：仕様書無しさん：03/10/11 13:13
COMは死滅。これからは.NETの時代というが。

.NETも腐った時代だ。

今の時代が.NETの時代というならばJ2EEの時代といったほうが辻褄が合う。
89 ：仕様書無しさん：03/10/11 13:19
クライアントでは使われないがな。
90 ：仕様書無しさん：03/10/11 13:31
腐ったのはアホアンチw
91 ：仕様書無しさん：03/10/11 13:42
COMは糞。
こういう糞をブリブリ吐き出すシロンボのコミュニティーを滅ぼせ。
92 ：仕様書無しさん：03/10/11 13:54
エクスプローラ、IEコンポーネント、DirectX、音楽や動画のプレイヤー。
今でもいたるところにCOMは使われているわけで、
死滅してないし死滅するとしてもそうとう時間がかかるだろうな。
死滅といっている奴は何を根拠に言っているのだろうか？ ただの無知か？
93 ：仕様書無しさん：03/10/11 14:02
ただのアホアンチだろ。(ｹﾞﾗ
94 ：仕様書無しさん：03/10/11 14:02
自分が理解できない・覚えたくない技術→死滅（してほしい）
95 ：仕様書無しさん：03/10/11 14:10
以上。理解することが目的になってる香具師の挨拶でした。
96 ：仕様書無しさん：03/10/11 14:15
あぁなるほど。これからは.NETがあればCOMは理解しなくても
いいと勘違いしているから死滅したとか言っているのか。
実際には使用されていても理解することが目的ならそう思うかもな。
97 ：仕様書無しさん：03/10/11 14:28
今OLE はどうなってるんだ、という話と同じようなものですかね？
98 ：仕様書無しさん：03/10/11 14:36
やっぱり、DDEだろ。
99 ：頭悪い ◆gGTEz68pSM ：03/10/11 14:38
コンポーネント屋はまだまだ必要かな。
100 ：仕様書無しさん：03/10/12 00:29
100
101 ：仕様書無しさん：03/10/12 20:14
うちのPCには２個ついてます。
102 ：仕様書無しさん：03/10/12 20:16
DCOMってMS製のアプリケーションですらあんまり使って無さそうだけど、
いったいどんなところに使われてるんでしょ。
103 ：仕様書無しさん：03/10/12 20:29
SQL鯖のエンタープライズマネージャとSQL鯖本体との通信はDCOMじゃ
なかったかな。
104 ：仕様書無しさん：03/10/12 21:39
COMはそれなりに成功したんだし
むりしてDCOMになんか作らなくても良かったのにね。
まあDCOMがあったおかげで、そのノウハウが
SOAPに受け継がれたんだろうけど。
105 ：仕様書無しさん：03/10/12 21:58
Socket -> RPC -> DCOM
　　　　　　 -> SOAP
結局は今でもSocketが大半を占めてるのは
どうしてなんでしょうか？メッセンジャーで
DCOMが使われていないのはどうしてなのかな。
106 ：仕様書無しさん：03/10/12 22:12
> 結局は今でもSocketが大半を占めてるのは
そういやCORBAもつかわれてないね。どうしてだろう。
107 ：仕様書無しさん：03/10/12 22:22
RPC自体が使われてないし。LAN内だったら別に良いとは思うけど。
108 ：仕様書無しさん：03/10/12 22:56
>>103
ODBCでは？
109 ：仕様書無しさん：03/10/13 23:20
結局COMとはINPROCでしか使い物にならなかったということですね。
それってつまりMozillaと同じでは？
110 ：仕様書無しさん：03/10/13 23:27
>>109
昔、IISで、ASPから、DCOM経由でMTXを使おうとデザインしたが、使い物にならなくて。
結局、inprocでMTX使うことになって、あんまりご利益無かったな。
Queued Componentはどうなたのかな？それなりに、先進性は認めるが、今や
音沙汰ないし。IBMのMQに対抗したのは良いが、初めにかねを掛ける割には
いきが続かないのはM$の悪い癖.

111 ：仕様書無しさん：03/10/13 23:35
>>110
MQと比べるにはWindows自体の信頼性も上がらないとダメですよね。
Windowsはよくなったけど、運用するためのノウハウが圧倒的に
不足気味というか。。。
112 ：仕様書無しさん：03/10/13 23:36
>>110
ものにならない、金にならないことについて、きちんと撤退できる
というのは、そうでないよりマトモだと思うけどな。

いいかげん×箱も諦めればいいのにね。
113 ：仕様書無しさん：03/10/14 01:03
>>111
MQは、Windowsベースでも相当稼動しているよ。勿論、運用のノウハウは
余計なものを一切動かさないこと。元々、MQはクロスプラットホームだから
OSの機能は最低限しか使っていない。
114 ：仕様書無しさん：03/10/14 01:10
>>113
安定性を求めるとSocketなどのOSの基本的機能しか使わないですよね。
逆にネットワークの簡易利用だとSocketで十分となる。つまり、
DCOMの使える場所ってのが？だったりします。DCOMというかCOM+を安定稼動
させるにはまだまだ、時間が必要なのかなって気がしてます。
115 ：仕様書無しさん：03/10/14 01:37
>>114
COM+は、オブジェクトのまま、キューに入れて使えるところが
魅力的なところだが、MQでは、XMLをキューに入れてやり取りする手法が
完全に確立している。
CORBAはJ2EEとともに生き残るが、DCOMは完全に行き場の無い状況だと思う。


116 ：仕様書無しさん：03/10/14 09:56
DCOMは必要なかった。
ローカル内だけで動作するCOM。その枠を越えて動作するSOAP。
MSの技術はこれだけで十分。
117 ：仕様書無しさん：03/10/14 12:18
以前、M$が散々Unix上で動くDCOMを宣伝していたが、実態を見たものは
ほとんどいないのではないか？
CORBA <-> COMブリッジも既にある（強烈に高価）。ActiveDirectoryと
DCOMに絡めた時点で大失敗だったのかもしれない。M$のネットワーク
セキュリティ何ぞ誰も信用していないということ。
118 ：仕様書無しさん：03/10/14 12:20
つうか、RPCからSOAPに流れが変わった。
119 ：仕様書無しさん：03/10/14 12:21
UNIXのRPCも使われて無いからね。
120 ：仕様書無しさん：03/10/14 12:28
そのとおり。DCOMがダメだったというより、SOAPがでて、CORBAもDCOMも
廃れるということ。
121 ：仕様書無しさん：03/10/14 12:31
unixコマンドを覚えまつた。
122 ：仕様書無しさん：03/10/14 14:13
COMはよかったんだけねぇ。
WindowsやWindowsアプリの多くが
直接・間接的に使っているし。
123 ：仕様書無しさん：03/10/14 15:02
COMは、今でも悪くないよ。
inprocだと、パフォーマンスも悪くないし、VBからだと、直接DLL使うより
何かと、便利だね。
特に他人に、部品として使わせるときには重宝する。
124 ：仕様書無しさん：03/10/14 16:35
コモンコントロール自体がCOMだしね。
125 ：仕様書無しさん：03/10/14 17:54
そりゃWindowsは何もかもがCOMだ
126 ：仕様書無しさん：03/10/14 19:10
COM(OLE)が無ければWordに画像を挿入とか
IE内でFlashを表示とかできなかっただろうな。
127 ：仕様書無しさん：03/10/15 21:18
(*^.^*)
128 ：仕様書無しさん：03/10/16 00:03
正直、COMなんて使わなくてもなんでも開発できるから。
129 ：仕様書無しさん：03/10/16 00:23
>>128
それはCOM以外のライブラリすべてにいえること。
130 ：仕様書無しさん：03/10/16 02:44
MSはCOMとか？とか色々あって勉強したいと思わない。
COMMAND.COMだけでいい。
131 ：仕様書無しさん：03/10/16 13:03
>>130
勉強嫌いなんですね。低学歴・低脳ですね。
132 ：仕様書無しさん：03/10/27 14:54
age
133 ：名無し＠沢村：03/10/27 19:43
>>128
＞正直、COMなんて使わなくてもなんでも開発できるから。

COMを使わず、Wordに画像を挿入してくれ。
COMを使わず、IE内でFlashを表示してくれ。
134 ：仕様書無しさん：03/10/27 20:22
>>133 それはCOMというよりもOLEでは
135 ：仕様書無しさん：03/10/27 20:31
それもCOM
136 ：名無し＠沢村：03/10/27 20:36
>>134
ﾌﾟｯ、OLE。
いまはOLEとはいわんのよ。いまはActiveXというのよ。
137 ：仕様書無しさん：03/10/27 20:51
OLEはCOMの技術を使ってはいるだろうが
138 ：仕様書無しさん：03/10/27 22:01
オートメーションを備えたインプロセスサーバ＝OLE
139 ： ：03/10/28 09:19
ここで OLE の話してもいいですか？
Access 2000 で OLE オブジェクトをデータベース内に格納してます。
OLE オブジェクトはビットマップだったりテキストファイルだったりExcelファイルです。

もちろんそれらを Visual Basic for Access (Applications か？) で
活性化すれば、開くことは出来るのですが、OLE オブジェクトの中身を直接いじりたいと思っています。

たとえば OLE オブジェクトがビットマップなら、ペイントで開くかわりに
直接ビットマップデータを抽出したい、ということです。
ビットマップの場合にはいろいろとサンプルがあるので問題なく扱うことが出来ました。
http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/q147/7/27.asp&NoWebContent=1
http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/q175/2/61.asp&NoWebContent=1
http://homepages.borland.com/efg2lab/Library/Delphi/ADO/Northwind/

で、それ以外の OLE オブジェクトについては、たいてい OLE クラスが "Package" となっています。
つまりオブジェクトパッケージャ (packager.exe) でパッケージ化された OLE オブジェクトだということです。
これを活性化するとまずオブジェクトパッケージャが一時的なファイルを作成し、
当該アプリケーションがその一時的なファイルを開く、ということになります。

OLE クラスが "Package" の OLE オブジェクトも、バイナリの状態、というか、
メモリに格納されている状態、では元のファイル名やアプリケーション名が先頭部分に書き込まれているわけですが、
そのフォーマットがわかりません。

どこかに packager.exe とそれが生成するパッケージの詳細な記述はないでしょうか？
140 ：仕様書無しさん：03/10/28 12:12
COMおぼえるんだったら.NET覚えたほうがまだまし
COMを押し付ける奴は氏ね
141 ：仕様書無しさん：03/10/28 12:17
COM位は教養で知ってたほうが良いぞ。
142 ：仕様書無しさん：03/10/28 13:16
あんなもん教養で大学で必修で学生に押し付けるのは学生にたいして失礼だ。
143 ：仕様書無しさん：03/10/28 13:26
おまえらMAMUCOぐらい知っとけ
144 ： ：03/10/28 22:50
Developing Applications with OLE 2.0
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnolegen/html/msdn_devwole2.asp
UNIX から来ていまさらながら OLE のドキュメントを読んでる漏れって…
145 ：仕様書無しさん：03/12/09 10:30
>>143
関西人ならOMECOM
146 ：仕様書無しさん：04/01/23 19:07
COMって、オブジェクト指向みたいに現実世界とのメタファっとか、
ソフトウェア科学の成果とか背景にあるんですか？
それとも、Ｍ＄がまったく何の脈絡もなく独自に作り出した物なんでしょうか。
とても分かりづらいんですけど。
147 ：仕様書無しさん：04/01/23 20:11
>>146
どういう状態ならソフトウェア科学の成果で
どういう状態ならソフトウェア科学の成果にならないんだ？

普通に考えればコンピュータおよびコンピュータ上で動く
すべて物はソフトウェア科学の成果だと思うぞ。
148 ：146：04/01/23 20:36
>>147
確かにちと大げさすぎたが。
たとえばコンパイラなんかは、そのバックグラウンドに
形式言語論とかあるじゃないですか。
オブジェクト指向もいまいち定義がはっきりしないけど、
ソフトウェアを「物」として扱おうという流れじゃないですか。
でも、ＣＯＭはＭ＄の都合だけで作られたような感じがしたということです。
しかも、それがＷｉｎｄｏｗの基礎となってる。
149 ：仕様書無しさん：04/01/23 21:11
>>148
> しかも、それがＷｉｎｄｏｗの基礎となってる。

もう終わるよ。今から COM を覚えるならアセンブリを覚えておけ。これから
主流になる。COM はもうすぐ obsolete になるで。
150 ：仕様書無しさん：04/01/23 22:36
おまえら、COMCOM言うけどな。
昔のDOSの実行モジュールxxxx.com（非xxxx.exe）
を知らないでCOMCOM言うなよな。
６４Kバイト以内という制限があったが、純粋に機械語
命令だけのちっちゃいプログラムになるんだぞ！
…という俺は今のCOMはよく知らんがな。
151 ：仕様書無しさん：04/01/23 22:42
>>150
ああ。PC9801VMとかで、MASMやらで
遊んでいた頃がなつかすぃ。
コマンドラインマンセー。
152 ：仕様書無しさん：04/01/23 23:31
>>148
じゃあライブラリや動的ライブラリやオブジェクトファイルは
ソフトウェア科学の成果ではないということですね。
153 ：仕様書無しさん：04/01/23 23:36
言っておくが、COMが出来た当時に
C言語などの手続き型言語を含めて、
どの言語からも使えるオブジェクト指向な
動的ライブラリは存在しないといっても過言じゃない。
154 ：148：04/01/23 23:37
>>152
それってＭ＄が考えたの？知らなかった。
なにもＷｉｎｄｏｗｓ全てを否定しているわけではないよ。
ＣＯＭが直感的に分かりづらいと言っているだけ。
155 ：仕様書無しさん：04/01/23 23:42
たしかにCOMはMSが作った物だが、
必要な物(オブジェクト指向動的ライブラリ）が
無い状態なのにどうしろと。

Cだってベル研究所の都合だ。
JavaだってSUNの都合だ。
Linuxだってリーナスの都合だ。
必要な無い状態なんだからMSの都合で何も悪いことはない。
156 ：仕様書無しさん：04/01/23 23:47
>>154
> それってＭ＄が考えたの？知らなかった。
そんなこと誰も言って無い。

> ＣＯＭが直感的に分かりづらいと言っているだけ。
そんなことお前は言っていない。

お前が聞いたのは動的ライブラリ形式(COMやDLLやUNIX系のSO等)が
ソフトウェア科学の成果かどうかだろ？
157 ：154：04/01/23 23:53
>>155,156
自分の言いたいことがあまり整理されていませんでした。ｽﾏｿ
つまり、ＡＰＩでプログラムを組んでいる分には
Ｗｉｎｄｏｗｓはそれほど難解ではないんだけど、
ＤｉｒｅｃｔＸとか使おうとしたとたん、Ｗｉｎｄｏｗｓの裏に隠蔽されていた
ＣＯＭという仕組みが顔を出してきて、
それを理解しないと手も足も出なくなる、と言うことがぼやきたかっただけです。
158 ：仕様書無しさん：04/01/24 00:04
> ＤｉｒｅｃｔＸとか使おうとしたとたん、Ｗｉｎｄｏｗｓの裏に隠蔽されていた
> ＣＯＭという仕組みが顔を出してきて、
しかたないだろ。DLLファイルで提供されている
API(非オブジェクト指向ライブラリ)では限界があるんだから。

大規模な物を作ろうとしたらオブジェクト指向のほうが便利。
しかし時代的に出来た当時はC言語もまだまだ主流。
DLLにオブジェクト指向風に使える拡張をした物がCOM。
非オブジェクト指向言語からも使えるように考慮しているのだから
複雑になるのは当然。

これに対して非オブジェクト指向言語からの利用を(あまり)考慮していない
.NETでは.NETの動的ライブラリをもっと簡単に使える。
159 ：仕様書無しさん：04/01/24 00:06
>>155
> たしかにCOMはMSが作った物だが、
> 必要な物(オブジェクト指向動的ライブラリ）が
> 無い状態なのにどうしろと。

だから、早くアセンブリを覚えろ。
同じプロジェクトで作成したクラスとまったく変わらずに使えるぞ。
しかも、属性をつけてリフレクションとか便利だし。
もう、同じオペレーションをするクラスに継承は必要ない。
どんなかは、NUnit のテストの書き方を見てみれば分かる。
160 ：仕様書無しさん：04/01/24 00:08
>>150
よく、テキストでアセンブリ言語でソースを書いて、DEBUG または SYMDEB に
リダイレクトしてアセンブルしてたっけ。
161 ：仕様書無しさん：04/01/24 00:10
>>157
DelphiやBCBやVBからだと特にCOMだからって難しいことは無いぞ。
普通のクラスライブラリって感じで使えるからな。

つーか、そもそもCOMのどこが難しいんだ？
162 ：仕様書無しさん：04/01/24 00:10
>>159
しかも、子 AppDomain で ShadowCopy を true にして使えば、DLL にロックが
かからないから、アセンブリを使っているプログラムの実行時に DLL が書き換えられるしな。
163 ：仕様書無しさん：04/01/24 00:17
>>161
BCB でも、マルチスレッドでマーシャリングしたり、COM の規則全部空で言える？
164 ：仕様書無しさん：04/01/24 00:19
>>161
VBはスレッドが使えないからいいとして、おまいは、DelphiやBCBでこれを全部理解しているのか？
165 ：仕様書無しさん：04/01/24 00:21
「これ」と書いたのはこれのことだ。
http://www.borland.co.jp/delphi/papers/com/com01.html

STA、MTA、インターフェース・アパートメントとか、マーシャリングとか。

> DelphiやBCBやVBからだと特にCOMだからって難しいことは無いぞ。
> 普通のクラスライブラリって感じで使えるからな。

それは、ごくごく限られた状況下なら沿うかもしれない。
166 ：仕様書無しさん：04/01/24 00:22
.NET でアセンブリが一番楽だね。
C#、MS だけどこれだけはスキ。
167 ：仕様書無しさん：04/01/24 00:23
.NET でアセンブリが一番楽だね。
C#、MS だけどこれだけはスキ。
168 ：仕様書無しさん：04/01/24 00:27
STA、MTA、インターフェース・アパートメントとか、マーシャリングなんか
考えなくてもいいだろ。

API使うときに考えているか？
169 ：仕様書無しさん：04/01/24 00:35
>>168
考えなかったらCOM動かないじゃん。
170 ：仕様書無しさん：04/01/24 00:37
>>169
考えなくてもデフォルトで動く。

その証拠に理解しなくても使えることを示唆するセリフがある。
> おまいは、DelphiやBCBでこれを全部理解しているのか？
171 ：仕様書無しさん：04/01/24 00:51
COMって難しいか？
漏れみたいな糞vb厨でも知ってるんだが。
172 ：仕様書無しさん：04/01/24 00:55
>>171
だってVBってスレッドもないし、別スレッドにあるCOM間でオブジェクトをやりとりすることも
ないじゃん。クラスのメソッドの呼び方さえ知っていれば住む世界だよ。
173 ：仕様書無しさん：04/01/24 00:58
マルチスレッドを使えない言語、使わない仕様なら難しいことはないだろうね、COM。
174 ：69式フリーPG：04/01/24 04:15
使うのと作るのでは大違いなんだよねぇ。
175 ：仕様書無しさん：04/01/24 11:30
>>172
別プロセスにあるCOM間でオブジェクトをやり取りすることはあるけどね。

さて、APIでスレッドを使う場合はSTAとかMTAとか面倒くさいことを
考慮しなくいいんだろ？ 単純にAPIでスレッドを使った場合に
相当するのはCOMで言えばSTAとかMTAとかどういうモードに相当するんだ？

そもそもなぜ複数のモードが存在するんだ？
APIでスレッド使うのに相当するモードだけを使うことを
前提にしたら、COMはもっと簡単だと思うんだが。

あと、Javaとか.NETとかCORBAとかオブジェクト指向な言語・ライブラリで
スレッドを使ったときはSTAとかMTAとか(に相当すること)を考えなくていいのか？
COMだけに特別なことなのか？
176 ：仕様書無しさん：04/01/24 11:34
遅レスだが、>>146が言いたいのはCOMとかの難しい(？)概念、
STA、MTA、インターフェース・アパートメント、マーシャリング(に相当する概念)は
COMだけに存在する物なのか？ ということだろ？
177 ：146：04/01/24 11:43
>>176
いえ、DirectXで挫折した者のただのぼやきです。
気にしないでください。
考えてみたら、ＣＯＭがあるから今のタブブラウザブームとかがあるわけですね。
178 ：仕様書無しさん：04/01/24 11:46
multithreadedなライブラリが孕むメンドクささと基本的には同じかと。
179 ：仕様書無しさん：04/02/02 08:02

>>157と同じような理由でCOMの勉強を始めている者です。

現在読んでいる入門書だと1999年の本なのに、MSがCOM
やVBを見捨てることはないと書いてあって、時代の流れの
速さを感じています。

自分の場合は、VC++6.0なんですが、それ付属のMSDNの
Platform SDKで Shell Reference を見たら、いきなり、
HRESULTを返すサンプルが載ってて、COMをやろうかと
思い立ったのですが、この辺りの知識は.NETでは完全に
無駄になってしまうのでしょうか？　OLEVIEW.EXEで
利用できるコンポーネントを探すなんてこともなくなるんですか？

もしも、こういった知識がすぐに無駄になってしまって、
.NETで同じことがより簡単にできるようになっているのであれば
VC++6.0からVC++.NETに乗り換えるべきなのかなと思っている
のですが。
180 ：仕様書無しさん：04/02/02 13:26
>>175
まずはEssential COMを読め。
181 ：仕様書無しさん：04/02/26 18:41
COMを始めたばかりのものです。
COMのメソッドって、クラスのオーバーロード関数みたいなことはできないのでしょうか？
例えばクラスのメンバ関数で
Func(int a);
Func(int a, DWORD b);
みたいなことをCOMのメソッドでやりたいのですが、だめなんでしょうか？
ヘンなこと言ってたらすいません
182 ：ブッシュ大統領：04/03/15 11:14
三大悪の枢軸国の紹介
　C++帝國(北朝鮮)　← C++厨代表の正体は、何と！　金正日だった！
　VB帝國(イラン)　←　VB厨代表はイランに潜伏していいた！
　Perl帝國(イラク)　← Perl厨代表フセインがついに逮捕された！
183 ：仕様書無しさん：04/03/15 15:02
EXEの方がいいよ
184 ：仕様書無しさん：04/03/16 21:33
>>182
じゃあ米は何よ？ｗ
185 ：仕様書無しさん：04/03/16 21:40
>>184
Lispにきまってるだろーが
186 ：仕様書無しさん：04/03/16 21:47
今、VBA(VB6.0相当)でスレッドを使って多量のExcelファイルを
処理しようとして苦労してるんだが、APIを使うってのは最早VBAじゃねぇのかなぁ。
まだCOMとかの基本的なことが分かってないので、一応動くが多々落ちる。
javaとかC#に移行してくれねぇかなぁ。
187 ：仕様書無しさん：04/03/16 21:48
Lisp！！ （゜∀゜）ｶｺｲｲ！！
188 ：仕様書無しさん：
ExcelのVBAで一日かけてプログラムを書き、保存してPCをとめた。
翌日Excelで開いてみたら、開いた時点でExcelが死にやがる。
VBAのコードはバイナリ化されててファイル覗いても拾うことすらできない。

結局は生のVBからExcelオブジェクトを操作する形に直して
また１から組みなおした。

VBAは怖い。