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

ここで 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 とそれが生成するパッケージの詳細な記述はないでしょうか？

COMおぼえるんだったら.NET覚えたほうがまだまし
COMを押し付ける奴は氏ね

COM位は教養で知ってたほうが良いぞ。

あんなもん教養で大学で必修で学生に押し付けるのは学生にたいして失礼だ。

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

Developing Applications with OLE 2.0
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnolegen/html/msdn_devwole2.asp
UNIX から来ていまさらながら OLE のドキュメントを読んでる漏れって…

>>143
関西人ならOMECOM

COMって、オブジェクト指向みたいに現実世界とのメタファっとか、
ソフトウェア科学の成果とか背景にあるんですか？
それとも、Ｍ＄がまったく何の脈絡もなく独自に作り出した物なんでしょうか。
とても分かりづらいんですけど。

>>146
どういう状態ならソフトウェア科学の成果で
どういう状態ならソフトウェア科学の成果にならないんだ？

普通に考えればコンピュータおよびコンピュータ上で動く
すべて物はソフトウェア科学の成果だと思うぞ。

>>147
確かにちと大げさすぎたが。
たとえばコンパイラなんかは、そのバックグラウンドに
形式言語論とかあるじゃないですか。
オブジェクト指向もいまいち定義がはっきりしないけど、
ソフトウェアを「物」として扱おうという流れじゃないですか。
でも、ＣＯＭはＭ＄の都合だけで作られたような感じがしたということです。
しかも、それがＷｉｎｄｏｗの基礎となってる。

>>148
> しかも、それがＷｉｎｄｏｗの基礎となってる。

もう終わるよ。今から COM を覚えるならアセンブリを覚えておけ。これから
主流になる。COM はもうすぐ obsolete になるで。

おまえら、COMCOM言うけどな。
昔のDOSの実行モジュールxxxx.com（非xxxx.exe）
を知らないでCOMCOM言うなよな。
６４Kバイト以内という制限があったが、純粋に機械語
命令だけのちっちゃいプログラムになるんだぞ！
…という俺は今のCOMはよく知らんがな。

>>150
ああ。PC9801VMとかで、MASMやらで
遊んでいた頃がなつかすぃ。
コマンドラインマンセー。

>>148
じゃあライブラリや動的ライブラリやオブジェクトファイルは
ソフトウェア科学の成果ではないということですね。

言っておくが、COMが出来た当時に
C言語などの手続き型言語を含めて、
どの言語からも使えるオブジェクト指向な
動的ライブラリは存在しないといっても過言じゃない。

>>152
それってＭ＄が考えたの？知らなかった。
なにもＷｉｎｄｏｗｓ全てを否定しているわけではないよ。
ＣＯＭが直感的に分かりづらいと言っているだけ。

たしかにCOMはMSが作った物だが、
必要な物(オブジェクト指向動的ライブラリ）が
無い状態なのにどうしろと。

Cだってベル研究所の都合だ。
JavaだってSUNの都合だ。
Linuxだってリーナスの都合だ。
必要な無い状態なんだからMSの都合で何も悪いことはない。

>>154
> それってＭ＄が考えたの？知らなかった。
そんなこと誰も言って無い。

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

お前が聞いたのは動的ライブラリ形式(COMやDLLやUNIX系のSO等)が
ソフトウェア科学の成果かどうかだろ？

>>155,156
自分の言いたいことがあまり整理されていませんでした。ｽﾏｿ
つまり、ＡＰＩでプログラムを組んでいる分には
Ｗｉｎｄｏｗｓはそれほど難解ではないんだけど、
ＤｉｒｅｃｔＸとか使おうとしたとたん、Ｗｉｎｄｏｗｓの裏に隠蔽されていた
ＣＯＭという仕組みが顔を出してきて、
それを理解しないと手も足も出なくなる、と言うことがぼやきたかっただけです。

> ＤｉｒｅｃｔＸとか使おうとしたとたん、Ｗｉｎｄｏｗｓの裏に隠蔽されていた
> ＣＯＭという仕組みが顔を出してきて、
しかたないだろ。DLLファイルで提供されている
API(非オブジェクト指向ライブラリ)では限界があるんだから。

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

これに対して非オブジェクト指向言語からの利用を(あまり)考慮していない
.NETでは.NETの動的ライブラリをもっと簡単に使える。

>>155
> たしかにCOMはMSが作った物だが、
> 必要な物(オブジェクト指向動的ライブラリ）が
> 無い状態なのにどうしろと。

だから、早くアセンブリを覚えろ。
同じプロジェクトで作成したクラスとまったく変わらずに使えるぞ。
しかも、属性をつけてリフレクションとか便利だし。
もう、同じオペレーションをするクラスに継承は必要ない。
どんなかは、NUnit のテストの書き方を見てみれば分かる。

>>150
よく、テキストでアセンブリ言語でソースを書いて、DEBUG または SYMDEB に
リダイレクトしてアセンブルしてたっけ。

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

つーか、そもそもCOMのどこが難しいんだ？

>>159
しかも、子 AppDomain で ShadowCopy を true にして使えば、DLL にロックが
かからないから、アセンブリを使っているプログラムの実行時に DLL が書き換えられるしな。

>>161
BCB でも、マルチスレッドでマーシャリングしたり、COM の規則全部空で言える？

>>161
VBはスレッドが使えないからいいとして、おまいは、DelphiやBCBでこれを全部理解しているのか？

「これ」と書いたのはこれのことだ。
http://www.borland.co.jp/delphi/papers/com/com01.html

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

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

それは、ごくごく限られた状況下なら沿うかもしれない。

.NET でアセンブリが一番楽だね。
C#、MS だけどこれだけはスキ。

.NET でアセンブリが一番楽だね。
C#、MS だけどこれだけはスキ。

STA、MTA、インターフェース・アパートメントとか、マーシャリングなんか
考えなくてもいいだろ。

API使うときに考えているか？

>>168
考えなかったらCOM動かないじゃん。

>>169
考えなくてもデフォルトで動く。

その証拠に理解しなくても使えることを示唆するセリフがある。
> おまいは、DelphiやBCBでこれを全部理解しているのか？

COMって難しいか？
漏れみたいな糞vb厨でも知ってるんだが。

>>171
だってVBってスレッドもないし、別スレッドにあるCOM間でオブジェクトをやりとりすることも
ないじゃん。クラスのメソッドの呼び方さえ知っていれば住む世界だよ。

マルチスレッドを使えない言語、使わない仕様なら難しいことはないだろうね、COM。

使うのと作るのでは大違いなんだよねぇ。

>>172
別プロセスにあるCOM間でオブジェクトをやり取りすることはあるけどね。

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

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

あと、Javaとか.NETとかCORBAとかオブジェクト指向な言語・ライブラリで
スレッドを使ったときはSTAとかMTAとか(に相当すること)を考えなくていいのか？
COMだけに特別なことなのか？

遅レスだが、>>146が言いたいのはCOMとかの難しい(？)概念、
STA、MTA、インターフェース・アパートメント、マーシャリング(に相当する概念)は
COMだけに存在する物なのか？ ということだろ？

>>176
いえ、DirectXで挫折した者のただのぼやきです。
気にしないでください。
考えてみたら、ＣＯＭがあるから今のタブブラウザブームとかがあるわけですね。

multithreadedなライブラリが孕むメンドクささと基本的には同じかと。

>>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に乗り換えるべきなのかなと思っている
のですが。

>>175
まずはEssential COMを読め。

COMを始めたばかりのものです。
COMのメソッドって、クラスのオーバーロード関数みたいなことはできないのでしょうか？
例えばクラスのメンバ関数で
Func(int a);
Func(int a, DWORD b);
みたいなことをCOMのメソッドでやりたいのですが、だめなんでしょうか？
ヘンなこと言ってたらすいません

三大悪の枢軸国の紹介
　C++帝國(北朝鮮)　← C++厨代表の正体は、何と！　金正日だった！
　VB帝國(イラン)　←　VB厨代表はイランに潜伏していいた！
　Perl帝國(イラク)　← Perl厨代表フセインがついに逮捕された！

EXEの方がいいよ

>>182
じゃあ米は何よ？ｗ

>>184
Lispにきまってるだろーが

今、VBA(VB6.0相当)でスレッドを使って多量のExcelファイルを
処理しようとして苦労してるんだが、APIを使うってのは最早VBAじゃねぇのかなぁ。
まだCOMとかの基本的なことが分かってないので、一応動くが多々落ちる。
javaとかC#に移行してくれねぇかなぁ。

Lisp！！ （゜∀゜）ｶｺｲｲ！！

ExcelのVBAで一日かけてプログラムを書き、保存してPCをとめた。
翌日Excelで開いてみたら、開いた時点でExcelが死にやがる。
VBAのコードはバイナリ化されててファイル覗いても拾うことすらできない。

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

VBAは怖い。