08/08/03 23:13:15
マイクロソフトじゃないからまし。
205:デフォルトの名無しさん
08/08/03 23:43:44
でたｗｗｗｗｗｗｗｗｗ
そうやって第二のMSが生み出され続ける
206:デフォルトの名無しさん
08/08/04 09:57:48
いや、そういう問題じゃなく、
ActiveXってクライアントＰＣでExe並になんでもできちゃうわけ。
207:デフォルトの名無しさん
08/08/04 10:39:27
ActiveXは署名技術でがんじがらめにするしかなかった。
よほどよく知られた会社のよく知られたアプリ以外に署名を受け入れるようなユーザーはそういない。
結局、名の知れたプラグインを配布する技術として残った。
208:デフォルトの名無しさん
08/08/04 10:41:00
△ 結局、名の知れたプラグインを配布する技術として残った。
○ 結局、アドビのPDFとマクロメディアのFLASHのプラグインを配布する技術として残った。
209:デフォルトの名無しさん
08/08/04 12:18:30
セキュリティソフト系の会社のネットスキャンも結構受け入れられてね？
210:デフォルトの名無しさん
08/08/05 09:32:11
セキュリティソフトと見せかけたスパイウェアですね、わかります。
211:デフォルトの名無しさん
08/10/22 17:30:59
>>208
結局、アドビの為だけの技術ってことかw
212:デフォルトの名無しさん
08/11/13 02:44:55
アドビは行儀が悪く、しかもウザイので入れない。
213:デフォルトの名無しさん
09/03/19 13:36:08
はいはい
214:デフォルトの名無しさん
09/07/31 03:16:18
そもそもCOMなんていらない。
いや、あってもいいが、Windowsの標準的な機構に取り入れすぎた。
COMの力を本当に借りなければいけないシーンがいったいどれだけあるのか。
クライアントPC内でほとんどプロセス内サーバで十分なら従来のDLLで関数をエクスポートする方法でいい。
クラスをエクスポートする必要など無い。
エクスポートするべき関数セットを定義してさえあればそれでよいじゃないか。
第一ベンダーも異なるソフトウエア同士が強調して動作するシーンならほかにもある。
ドライバーだ。あれはCOMじゃないぞ？
COMなんか使わなければアプリケーションはもっと素早く連係動作できるし実装だって楽だ。
VBとかjavaから使いたいなら、それらのエクスポートされた関数をラップするCOMでも用意すれば良かったんだ。
そもそもVBなんて小汚い文法の言語はさっさと捨てるべきなんだよ。
215:デフォルトの名無しさん
10/03/30 14:25:05
てす
216:デフォルトの名無しさん
10/05/09 23:40:01
>関数をラップするCOMでも用意すれば良かったんだ。
結局comは必要なわけねｗ
217:デフォルトの名無しさん
10/05/10 02:34:41
>>163
これは単にThreadingModelが合ってないだけでは？
fctest10.cpp
CoInitialize(NULL);
FcTest1.h
threading(free),
この組み合わせではマーシャリングが発生してしまう。
Side-by-sideの場合のThreadingModelがどうなるのか分からんけど。
未指定ならThreadingModel=none相当になって、primary STAにインスタンスが作られるから、
マーシャリングが発生しなくて早くなると。
218:デフォルトの名無しさん
10/05/10 09:00:10
>>214
JScriptからもCOMを使いたいのだす
219:デフォルトの名無しさん
10/05/10 11:05:22
いろんなところが同じようなことを目指したが、まともに実装/実践したのはMicrosoftだけ。
今は、もっと不効率な方法でも実用に耐えるようになったけど。
220:デフォルトの名無しさん
10/05/10 11:17:22
＞まともに実装/実践したのは
M$DNセミナーで、COMはBSD UNIX対応すると、何度もアナウンスして実現できなかったわけだが。
同時期、ローカルのＲＤＢ用ＣＯＭコンポーネント（ローカルでＳＱＬいくつも実行してサーバーにそれを纏めて送る）とか、
ＶＪ＋＋脂肪とか、ドトネトパスポートもシパーイと頓挫続きだった。
221:デフォルトの名無しさん
10/05/10 11:18:58
x できなかった
o できるのにしなかった
222:デフォルトの名無しさん
10/05/10 11:23:26
いや、BSD UNIX対応は年を越えてアナウンスしてたが、実現できなかったんだよ。
UNIXでCOMが動いていれば、COMが消えるどころか標準規格に昇格してるだろｗ
223:デフォルトの名無しさん
10/05/10 11:34:51
COM/DCOMの独自性があるとすれば、インプロセス、アウトプロセス、ネットワークを
全部プロキシで統合してることかな？
ネットワーク分散オブジェクトならCORBAが標準だし
インプロセスではMozillaのパチモンNSCOMとかあるよね
インプロセスCOMの存在意義は、つきつめればC++のABIの問題回避という面が
大きかったのではないかと俺は思う
C++でまともに（ただの関数インタフェースではない）DLL組もうとすると、
レジストリによってファクトリーを統合するなんて仕掛けは作らないにしても、
結局COMに非常に似たものが出来上がる、というかそうせざるを得ない
224:デフォルトの名無しさん
10/05/10 11:55:50
CORBAの実装が遅すぎ。