stanford-oval/wikipedia huggingface dataset:
Component Object Model
関連技術 > COM+

エンタープライズレベルのオペレーティングシステム (OS) の代替としてWindowsのポジションを確立するためだけでなく、分散トランザクションをサポートし、メモリとプロセッサ（スレッド）の管理の改善するため、マイクロソフトはWindows NT 4.0 Service Pack 4でMicrosoft Transaction Server (MTS) を導入した。
Windows 2000でのCOMの重要な拡張は（MTSによる外部ツールの組み合わせとは対照的に）OSへ統合することであり、これをCOM+と改名した。この時点でマイクロソフトは個別の要素としてDCOMを重視していなかった。COM+の追加レイヤでトランザクショナルCOMコンポーネントを直接的に取り扱った。COM+コンポーネントはコンポーネントサービスアプリケーションインタフェースを通じて追加された。
COM+は「コンポーネントファーム (component farms)」で動作できる利点があった。コードが正しい場合、コンポーネントはメモリからアンロードすることなく初期化ルーチンを新たに呼び出すことにより再利用できた。以前はDCOMだけで可能だったコンポーネントの分散化（他のマシンからの呼び出し）も可能となった。
またCOM+では、COM+イベントという、サブスクライバ/パブリッシャー型のイベントメカニズムを導入し、アプリケーション間非同期メッセージングプロトコルであるMSMQを利用するための新たな方法として、Queued Componentsというコンポーネントを介するモデルを提供した。これにより、COM+プログラミングモデルでは、遅延バインディングされたイベント、および、パブリッシャー/サブスクライバとイベントシステムの間のメソッド呼び出しがサポートされる。
関連技術 > DCOM

→詳細は「Distributed Component Object Model」を参照
関連技術 > .NET

→詳細は「.NET Framework」を参照
COMプラットフォームは.NET Frameworkに大幅に取って代わられ、マイクロソフトは.NETに注力する戦略に集中している。COMは複雑で高性能なVisual BasicやASPで実装されたフロントエンドのコードと接続するためによく利用されていた。
好感されている.NETに対して、COMはある程度批判されている。.NETがWindows FormsとWeb Formの両方に対してジャストインタイムコンパイル方式と共にVisual Basicに似たラピッドデベロップメントツールを提供するため、バックエンドコードはC#、Visual Basic .NET、C++/CLIを含むあらゆる.NET言語で実装できる。
それでもCOMはまだ様々なテクノロジーで重要なソフトウェアの基盤として生き延びている。例えばマルチメディアAPIとして広く普及しているDirectXのAPIはCOMをベースにしている。2015年にWindows 10とともにリリースされたDirectX 12 (Direct3D 12) も、依然としてCOMベースであり、C++を第1級言語としている。2018年時点では、マイクロソフトはCOMのサポートやCOMそのものをやめてしまう計画を持っていない。
COMはまた、コンパイル時点でAPIの情報を必要としないスクリプトからCOMオブジェクトを呼び出すためのインタフェース（動的ダックタイピング）を提供するため、Microsoft OfficeやInternet Explorerのようなネイティブアプリケーションのスクリプト制御のための技術として理想的でもある。COMにおけるあらゆる要素を一意に識別するために開発されたGUIDシステムはマイクロソフトによるUUIDの実装であり、COM以外でもユニークなIDが必要とされる場合に広く利用されている。
トランザクションやコンポーネントのキューといったようなCOM+が提供する複数のサービスはエンタープライズな.NETアプリケーションでもまだ重要である。
制約はあるものの、.NETはCOMに対して相互運用性のサポートがある。.NETはランタイム呼び出し可能ラッパー (RCW) を実装することでCOMオブジェクトを利用できる。COMクライアントはCOM呼び出し可能ラッパー (CCW) によって、特定の制約に従った.NETオブジェクトを利用できる。COMと.NETの両方の側からは相手側のオブジェクトがネイティブなオブジェクトに見える。
.NET Remotingでは、オブジェクトがプロセスやマシンの境界を越えてリファレンスや値を透過的にマーシャリングできるようにして、COMが持つ数多くのリモート実行の欠点を解決する。
関連技術 > Windowsランタイム

→詳細は「Windowsランタイム」を参照
Windows 8およびWindows RTにて、新たなアプリケーションの開発・実行基盤としてWindowsランタイム (WinRT) が導入された。WinRTはCOMを拡張したネイティブ技術であるが、Windowsメタデータ (WinMD) および言語プロジェクション (language projection) と呼ばれる技術により、.NET言語やJavaScriptなどからも透過的に利用可能である。
技術的詳細

COMコンポーネントにはクラスID (CLSID) が割り当てられ、COMコンポーネント同士はクラスIDによって区別される。CLSIDはGUIDで構成されている。各COMコンポーネントは1つ以上のインターフェイスを公開することで機能を提供している。インターフェイス同士はインターフェイスID (IID) で区別される。IIDもGUIDで構成されている。
COMインターフェイスはプログラミング言語とCOMとを結び付けている。COMコンポーネントへのアクセスは全てインターフェイスを通さなければならない。これによって、プロセスやコンピュータを跨いでCOMコンポーネントにアクセスすることができるようになっている（コンピュータを跨いでのアクセスにはDCOMが必要）。
技術的詳細 > インターフェイス

全てのCOMコンポーネントはIUnknownと呼ばれるインターフェイスを継承する必要がある。また、全てのCOMインターフェイスはIUnknownから派生している。IUnknownは、AddRef / Release / QueryInterfaceという3つのメソッドを持っている。AddRefとReleaseはインターフェイスの生存期間を管理するための参照カウントを実装するメソッドである。そしてQueryInterfaceは、IIDを指定してコンポーネントが実装している他のインターフェイスを取得するメソッドである。これはC++のdynamic_castや、JavaおよびC#の型変換演算子に相当する。
COMコンポーネントのインターフェイスは、反射性、対称性、推移性を備えている必要がある。反射性とは、あるインターフェイスから、QueryInterfaceをそのインターフェイス自身を表すIIDを与えて呼び出すと、返ってくるインターフェイスは元と同じものでなければならないということである。対称性とは、インターフェイスAからQueryInterfaceでインターフェイスBが取得できる場合、インターフェイスBからインターフェイスAが取得できなければならないということである。推移性とは、対称性と似ているが、インターフェイスBがインターフェイスAから取得でき、インターフェイスCがインターフェイスBから取得できる場合、インターフェイスCはインターフェイスAから取得できなければならないということである。
インターフェイスには、インターフェイスを実装した関数へのポインタをその宣言時の順に並べた仮想関数テーブルへのポインタが含まれている。この関数テーブル構造は、OLE 1.0のときからOLEシステムとの通信に使われていた。
COMはコンポーネント間の通信のためにほかにも多くの標準インターフェイスを定めている。たとえばデータストリームを管理するIStreamが挙げられる。これはファイルストリームのコンポーネントがファイルを読み書きする際に使うことが考えられる。IStreamのReadメソッドとWriteメソッドはストリームに対して読み取りと書き込みを行うことが想定される。他の例として、IOleObjectは、あるアプリケーションのデータオブジェクト内に別のアプリケーション向けのデータオブジェクトを埋め込むような複合文書に利用される。IOleObjectインターフェイスは、呼び出した側が呼び出し先コンポーネントとの画面表示上の境界を決められるメソッドや、「開く」あるいは「保存」などのユーザー操作（アクション）に対応する処理を実行することができるメソッドを持っている。
技術的詳細 > コクラス

COMではクラスのことをコクラス (coclass) と呼ぶ。コクラスは、COMにおける（オブジェクト指向プログラミングのような）クラスを定義する言語非依存の手段である。
1つのコクラスは、1つ以上のインターフェイスの具体的な実装を提供する。COMに対応しているプログラミング言語であれば、C++、Visual Basicなどどんな言語でも実装を行うことができる。
個々のコクラスは、クラスID (CLSID) やProgIDで識別される。
クラスIDはGUIDを使った表現である。通常、各コクラスに対しクラスIDを1つ割り当てる。ただし、互換性のため、旧バージョンのクラスIDに新バージョンのコクラス実装を登録し、結果的に複数クラスIDが同一コクラスを指し示す場合もある。そのような用途にCoTreatAsClass関数が用意されている。
ProgIDは文字列による表現である。InternetExplorer.ApplicationやMsxml2.DOMDocument.6.0など「プログラム名.コンポーネント.バージョン」（バージョンは非必須）という規則である。ProgIDは必須ではなく、コクラスによってはProgIDを持っていない場合もある。
ProgIDによる指定でオブジェクトを作成・取得する際には、ProgIDからクラスIDに変換する必要がある。この変換は一意ではなく、特にバージョン指定のないProgIDでは、インストールされているコンポーネントのバージョン次第で、コンピュータごとに異なるCLSIDとなる可能性がある。
この処理はプログラミング言語やライブラリによって実装される場合もある。VBScriptなど、オブジェクト作成時にProgIDでの指定のみ可能なプログラミング言語もある。
COMは、Windows開発の世界に、実装とインターフェイスを切り離すという概念を意識させることをもたらした。この基本的な概念の延長には、オブジェクト指向におけるポリモーフィズム（多態）の実現がある。すなわち、1つのインターフェイスに対して複数の実装（COMサーバー）を用意し、アプリケーション（COMクライアント）側が任意の実装を選び、それを区別なく一様に操作することができるということであり、またCOMコンポーネントが要求するインターフェイスを実装するオブジェクトをアプリケーション側で用意して、COMコンポーネントにインターフェイスを通じて操作させることで、コールバック処理などのカスタマイズを実現することもできるということである。後者はイベントシンク (event sink) として標準化され、プロセス内だけでなくDCOMプロセス間の透過的なコールバック処理をも実現することにつながった。
技術的詳細 > インターフェイス定義言語とタイプライブラリ

COMコンポーネントに関する情報の記述手段として、MIDL（マイクロソフトインターフェイス定義言語、IDLも参照）やタイプライブラリがある。MIDLはテキストファイルで主として開発時に用いられる。タイプライブラリは型に関する言語非依存の情報を提供するバイナリファイルであり、開発時だけでなく実行時に参照されることも想定されている。
COMコンポーネントの開発では、普通IDLで型を定義することから始める。IDLファイルではオブジェクト指向的なクラスやインターフェイス、構造体、列挙体などのユーザー定義型をプログラミング言語に依存せず記述できる。このIDLではC/C++に似たキーワードと、それに追加してインターフェイスを定義する「interface」、コクラスを定義する「coclass」、それらの集合を現す「library」という2つのキーワードを使用する。また各宣言の前に角括弧[]で括って属性を指定でき、インターフェイスにGUID (IID) を指定したり、配列引数とその長さを示す引数との関係を指示したりできる。
IDLファイルはMIDLコンパイラで様々なプログラミング言語に向けてコンパイルされる。C/C++用にはインターフェイスなどが宣言されたヘッダファイルとGUIDを定義したCのソースファイル、またCOMのメソッド呼び出しをRPC用に変換する「プロキシ」とそれを元に戻す「スタブ」のソースファイルも生成される。
MIDLはIDLファイルからタイプライブラリ（.TLBファイル）も作る。タイプライブラリに含まれているバイナリのメタデータはコンパイラや実行環境（Visual BasicやDelphi、.NETのCLRなど）で利用される。その結果タイプライブラリファイルで定義されたコクラスをその言語や環境に持ち込んで使用できるようになる。
技術的詳細 > オブジェクトフレームワークとしてのCOM

COMの基本原則はそれがオブジェクト指向の哲学に基づいているということである。オブジェクト指向開発と実装を実現するためのプラットフォームである。
COMはランタイムフレームワークであるため、型は明示的に識別可能であり実行時に指定可能である必要がある。これを実現するためにGUIDが使われる。それぞれのCOMの型は実行時あるいはコンパイル時に自分の識別用GUIDを指定する。
COMの型についての情報がコンパイル時と実行時の両方でアクセスできるようにする必要性から、COMはタイプライブラリを提供する。COMがオブジェクトの相互作用のための動的なフレームワークとしてその能力を発揮するのはタイプライブラリが効果的に利用されているからである。
以下の例にあるIDLのコクラス定義を考える。
interface ISomeInterface : IUnknown
{
    HRESULT DoSomething();
};

coclass SomeClass
{
    [default] interface ISomeInterface;
};
上記のコード断片は、ISomeInterfaceというインターフェイスを実装する、SomeClassという名前のCOMクラスを宣言している。
これは概念的には次のようなC++のクラスを定義することに等しい。
struct ISomeInterface : public IUnknown
{
    virtual HRESULT DoSomething() = 0;
};

class SomeClass : public ISomeInterface
{
    ...
};
ISomeInterfaceはC++の純粋仮想基底クラスに相当するものである。
COMのインターフェイスおよびコクラスを含むIDLファイルはタイプライブラリファイルにコンパイルされる。タイプライブラリはCOMクライアントのコンパイル時あるいは実行時に解釈され、オブジェクトがどのインターフェイスをサポートするかを決定し、オブジェクトのインターフェイスメソッドを呼び出すために利用される。
C++では、Windows API関数のひとつであるCoCreateInstance()を使用してCOMオブジェクトをインスタンス化することができる。引数にはクラスID (CLSID) およびインターフェイスID (IID) を指定する。
ISomeInterface* pSomeInterface = NULL;
HRESULT hr = CoCreateInstance(
    CLSID_SomeClass,
    NULL,
    CLSCTX_INPROC_SERVER,
    IID_ISomeInterface,
    reinterpret_cast<void**>(&pSomeInterface)
);
この例では、ISomeInterfaceインターフェイスを実装するSomeClassオブジェクトへのポインタを取得するためにCOMサブシステムが使われる。これは概念的に次のようなC++のコードと等しい。
ISomeInterface* pSomeInterface = new SomeClass();
そしてコクラスはCOMの世界ではオブジェクト指向のクラスである。コクラスの主要機能は、(1) バイナリの性質と、(2) 結果的にプログラミング言語に非依存ということである。
技術的詳細 > レジストリ

Windowsの場合、COMのクラス、インターフェイス、タイプライブラリはWindowsレジストリにあるGUIDのリストであり、クラスは"HKEY_CLASSES_ROOT\CLSID"に、インターフェイスは"HKEY_CLASSES_ROOT\interface"にある。COMライブラリは各COMオブジェクトが正しいローカルライブラリを特定するためやリモートサービスのネットワーク上の位置を特定するためにレジストリを使用する。DLLサーバー型のCOMコンポーネントはregsvr32（英語版）というコマンドラインプログラムを使用してレジストリ登録および登録解除を行なうが、EXEサーバー型のCOMコンポーネントは自身に/RegServerあるいは/UnRegServerスイッチを付けて起動し、レジストリ登録および登録解除を行なう。
システムレジストリを使用する性質上、レジストリ登録されたCOMコンポーネントはコンピュータあるいはネットワーク上のすべてのCOMクライアントから共有される。COMコンポーネントをバージョンアップする際にインターフェイスを変更・追加する場合、旧バージョンをレジストリ登録解除したうえで新バージョンをレジストリ登録し直すか、異なる名前およびGUIDを持つインターフェイスを改めて定義した別のコンポーネントをレジストリ登録する必要がある。前者はバージョンアップの際にCOMクライアントの更新は不要だが、破壊的な仕様変更を避けるなど後方互換性に配慮した設計が求められる。後者は新しいバージョンに対応するCOMクライアントを再作成する必要があるが、複数のバージョンを共存させることができ、バージョン間の互換性を考慮する必要はない。たとえばDirect3Dのバージョン7/8/9/10/11/12は、すべて異なるインターフェイスを持つ独立したCOMコンポーネントであり、同一コンピュータ上に共存できる。典型的にいって、COMにおける最良のアプローチは、機能を拡張するためには新しいインターフェイスを定義することである。なおCOMコンポーネントのマイナーバージョンアップの際は、通例既存のインターフェイスを継承して新たなインターフェイスを定義する手法が採られる。たとえばDirect3D 10.1あるいは11.1/11.2/11.3における各インターフェイスは、Direct3D 10.0あるいは11.0のインターフェイスからそれぞれ派生した新しいインターフェイスを定義する方法で機能拡張が行なわれている。
Windows XP以降では、「分離アプリケーションとSide-by-Sideアセンブリ」と呼ばれる仕組みを使い、レジストリではなくマニフェストファイルを使用してコンポーネント依存関係を解決することも可能である。この仕組みを用いることで、COMコンポーネントをシステム全体で共有せず、アプリケーションごとにプライベートアセンブリとして配布・運用することも可能となる。
技術的詳細 > 参照カウント

最も基本的なCOMのインタフェースであるIUnknown（全てのCOMインタフェースはここから派生する）は、QueryInterface()による機能の確認と、AddRef()およびRelease()を通じたオブジェクトの寿命の管理という2つの主要な概念をサポートする。参照カウントと機能の確認は（オブジェクトの各インタフェースに対してではなく）オブジェクトに対して適用される。従って注意深く実装する必要がある。
インタフェースへのアクセスを要求したクライアントが存在している限り個々のオブジェクトが生存していることを保障し、逆にオブジェクトを使用していたすべてのコードが終了してそのオブジェクトが不要になった時にオブジェクトを適切に処分するため、インタフェースの参照カウントというテクニックがCOMでは要求される。COMオブジェクトは参照カウントが0に達したときに自分のメモリを自分で解放する責任がある。
これを実装するため、COMオブジェクトは一般的に参照カウントのための整数値を持つ。オブジェクトのインタフェースからAddRef()が呼ばれるとこの整数値が加算される。Release()が呼ばれるとこの整数値は減算される。AddRef()とRelease()はCOMオブジェクトのクライアントがそのオブジェクトの寿命に関与できる唯一の手段である。内部の整数値はCOMオブジェクトのプライベートなメンバーであり、直接的にはアクセスできない。
AddRef()の目的は、COMオブジェクトへの新しい参照が生じて、その参照が正当である限り生存し続ける必要があるということを、そのCOMオブジェクトに対して示すことである。Release()の目的は、クライアント（またはクライアントコードの一部）がもうオブジェクトを必要としなくなり、もし参照カウントが0に達した場合にはオブジェクトが自らを破棄するであろうということを示すことである。
一部の言語（例えばVisual Basic）では自動参照カウントが提供されるため、COMオブジェクトの開発者はソースコード中で内部参照カウントを明示的に保持する必要がない。C言語でCOMを利用する場合、明示的な参照カウントの操作が必要である。C++では、自分自身でそれを管理することもできるし、参照カウントを全部管理してくれるスマートポインタ（ATL::CComPtrなど）を利用することも選択できる。
下記はCOMオブジェクトで適切な参照カウントの制御を簡単にするためのAddRef()とRelease()を呼び出す際の一般的なガイドラインである。
（戻り値またはoutパラメーターで）インタフェースの参照を返す関数（オブジェクトメソッドとグローバル関数のいずれも）は、それを返却する前に、背後にあるオブジェクトの参照カウントを加算しておくべきである。従って関数やメソッドの内部で、AddRef()が（返却する）インタフェースの参照に対して呼び出される。IUnknownインタフェースのQueryInterface()メソッドはこの実例である。従って、リターンされたインタフェースの参照は既に加算されており、リターンされたインタフェースの参照のAddRefを再度呼びだす必要がないということを開発者は理解していなければならない。
インタフェースのポインタが上書きされるかスコープから外れる前にインタフェースの参照からRelease()を呼び出さなければならない。
インタフェースの参照ポインタからコピーを作る場合、そのポインタでAddRef()を呼び出すべきである。結局この場合は、背後にあるオブジェクトのもう1つの参照を実際に作成している。
インタフェースを参照するだけで内部リソースを割り当てる必要があることからインタフェース毎に参照をカウントするようにオブジェクトが実装されているかもしれないため、参照した特定のインタフェースに対してAddRef()とRelease()を呼び出さなければならない。
これらの関数の追加の呼び出しはケーブルを超えてリモートオブジェクトに送信されない。プロキシはリモートオブジェクトの参照を1つだけ保持し、ローカルの参照カウントを管理する。
COMの開発を容易にして促進するため、マイクロソフトはC++の開発者のためにActive Template Library (ATL) を導入した。ATLは高レベルのCOM開発パラダイムを提供する。ATLはまた、スマートポインタオブジェクトを提供することによってCOMクライアントのアプリケーション開発者が参照カウントを直接管理しなくてもよいようにする。
その他にはMFC、VBScript、Visual Basic、ECMAScript (JavaScript)、Delphiなどのライブラリや言語がCOMに対応している。
技術的詳細 > インストール

COMはクラスファクトリを利用してCOMオブジェクトのインストール（つまり生成）プロセスを標準化する。COMオブジェクトを作成するため、2つの関連した項目が存在していなければならない。
クラスID
クラスファクトリ
各COMクラスまたはコクラスはユニークなクラスID (GUID) で関連付けられていなければならない。またクラスファクトリとも関連付けられていなければならない（レジストリを利用して行う）。クラスファクトリ自身はCOMオブジェクトである。これはIClassFactoryまたはIClassFactory2インタフェースを持つオブジェクトでなければならない（後者はライセンス管理をサポートしているインタフェースである）。これらのオブジェクトは他のオブジェクトを生成する責任がある。
クラスファクトリオブジェクトは一般的にはCOMオブジェクト自身と同じ実行ファイル内（つまりサーバーコード内）に含まれている。ターゲットオブジェクトを作成するようにクラスファクトリを呼び出すとき、このターゲットオブジェクトのクラスIDが提供されていなければならない。このようにしてクラスファクトリはどのクラスのオブジェクトをインスタンス化するのかを把握する。
単一のクラスファクトリオブジェクトは複数のクラスのオブジェクトを生成するかもしれない。すなわち、異なるクラスIDを持つ2つのオブジェクトが同じクラスファクトリオブジェクトによって生成されるかもしれない。しかしながら、これはCOMシステムにとっては曖昧なものではない。
別のオブジェクトにオブジェクト生成の責任を委ねることにより、抽象度が非常に高くなり、開発者に高い柔軟性をもたらす。例えば、シングルトンやその他のオブジェクト生成パターンの実装が容易になる。またファクトリオブジェクトはCOMオブジェクトのメモリ割り当てからアプリケーションの呼び出しを守る。
クライアントアプリケーションがクラスファクトリオブジェクトを入手できるようにする必要性から、COMサーバーはそれらを適切に公開しなければならない。クラスファクトリはサーバーコードの特質上、別の方法で公開される。DLL サーバーはDllGetClassObject()というグローバル関数をエクスポートしなければならない。EXEサーバーは実行時にCoRegisterClassObject()というWindows API関数でクラスファクトリを登録しなければならない。
下記はクラスファクトリを利用したオブジェクト生成のシーケンスの一般的な概略である。
オブジェクトのクラスファクトリを、Windows API関数CoGetClassObject()で取得する。

CoGetClassObject()を呼び出すためには作成するオブジェクトのクラスIDが提供されていなければならない。C++によるコード例を以下に示す。
IClassFactory* pIClassFactory = NULL;

CoGetClassObject
(
  CLSID_SomeObject,
  CLSCTX_ALL,
  NULL,
  IID_IClassFactory,
  (LPVOID*)&pIClassFactory
);

上記のコードはCLSID_SomeObjectというクラスIDによって識別されたCOMオブジェクトのクラスファクトリが必要であることを示している。このクラスファクトリオブジェクトはIClassFactoryインタフェースで返される。
返却されたクラスファクトリオブジェクトを使って元々意図していたCOMオブジェクトのインタフェースを生成するように要求する。C++によるコード例を以下に示す。
ISomeObject* pISomeObject = NULL;

if (pIClassFactory)
{
  pIClassFactory->CreateInstance
  (
    NULL,
    IID_ISomeObject,
    (LPVOID*)&pISomeObject
  ); 

  pIClassFactory->Release();

  pIClassFactory = NULL;
}

上記のコードは、クラスファクトリオブジェクトのCreateInstance()メソッドを使用して、IID_ISomeObjectというGUIDで識別されるインタフェースを公開しているオブジェクトを生成することを示している。このオブジェクトのISomeObjectインタフェースへのポインタが返される。クラスファクトリオブジェクトはそれ自身がCOMオブジェクトであることから、もう必要なければリリースする必要があるということにも注意してほしい（要するにこれのRelease()メソッドを呼び出さなければならない）。
上記はオブジェクトをインスタンス化するクラスファクトリの非常に基本的な使用例である。上位レベルのコンストラクタも利用可能であり、その一部はWindows APIを直接利用しないものもある。
例えば、アプリケーションはオブジェクトのクラスファクトリを取得せずにCOMオブジェクトを直接生成するためにCoCreateInstance() APIを利用できる。しかしながら、CoCreateInstance() APIはオブジェクトのクラスファクトリを取得するためにCoGetClassObject() APIを内部で呼び出しており、そしてCOMオブジェクトを生成するためにクラスファクトリのCreateInstance()メソッドを使用している。
CreateObject()というオブジェクトをインスタンス化するためのグローバル関数の他に、C++ではnewを利用できる。C++のコンストラクタはIClassFactory::CreateInstance()メソッドを呼び出して（CoGetClassObject() APIで）目的のオブジェクトのクラスファクトリオブジェクトを取得することを隠蔽する。
PowerBuilderのPowerScriptのように上位レベルのオブジェクトを生成するコンストラクタを提供する言語もある。しかしながらCoGetClassObject()とIClassFactoryインタフェースを使った非常に基本的なオブジェクト生成手法もまだ利用できる。
技術的詳細 > リフレクション

COMの初期の時代、オブジェクトがどのような機能を提供するのかということをクライアントから確認するためには、インスタンスを実際に生成して（IUnknownインタフェースの）QueryInterfaceメソッドを呼び出してみるしかなかった。
この検証方法は、特定の業務のために適切なコンポーネントを選択したり、オブジェクトが提供するメソッドの使用方法を開発者が理解できるようにしたりといったところで、多くのアプリケーションにとって不便であるということになった。
結果的にコンポーネントを完全に確認できるCOMタイプライブラリが導入された。タイプライブラリは、コンポーネントのCLSID、コンポーネント実装のインタフェースのIID、これらのインタフェースの各メソッドの解説といった情報を含んでいる。タイプライブラリは一般にVisual BasicやVisual StudioのようなRAD環境でクライアントアプリケーションの開発者を支援するために利用されている。
技術的詳細 > プログラミング

COMは「言語にとらわれない」(language-agnostic) あるいは「言語非依存」(language-independent) のバイナリ標準であり、タイプライブラリすなわちバイナリで定義されたデータ型とインターフェイスを解釈する機能を実装できさえすれば、いかなるプログラミング言語でも開発できる。
ランタイムライブラリ（厳密に言えばプログラマ）は、COMの環境に立ち入って、インスタンス化してCOMオブジェクトの参照をカウントし、バージョン情報からオブジェクトを問い合わせて、新しいバージョンのオブジェクトを利用してコーディングし、新しいバージョンが利用可能でない場合は古いバージョンでも動作するようにフォールトトレラントをコーディングするといった責任がある。
技術的詳細 > アプリケーションとネットワークの透過性

プロセス内から、またはコンピュータ内のプロセスの境界を越えて、あるいはDCOMテクノロジを利用してネットワークを超えて、COMオブジェクトをインスタンス化して参照できる。
プロセスの外やリモートにあるオブジェクトはメソッドコールや戻り値をやりとりするためにマーシャリングを利用できる。
マーシャリングでは、オブジェクトや、オブジェクトを利用しているコードは見えない。
技術的詳細 > COMのスレッド

COMでは、アパートメントモデルとして知られているコンセプトによってスレッドの問題を解決している。ここで言うアパートとは、単一のスレッドまたはスレッドのグループの中にある実行コンテキストが1つまたは複数のCOMオブジェクトに関連づけられていることを指している。
アパートメントでは以下のガイドラインが関連するスレッドとオブジェクトのために示される。
1つのCOMオブジェクトは1つのアパートメントだけに関連づけられる。オブジェクトが実行時に生成された時点で関連づけられる。オブジェクトの初期化後は一生そのアパートメントに属する。
COMスレッド（つまりCOMオブジェクトを生成したか、COMのメソッドコールが行われたスレッド）もまた1つのアパートメントに関連づけられる。COMオブジェクトと同様、スレッドとアパートメントの関連づけは初期化時に決定される。各COMのスレッドもまた終了するまで指定されたアパートメントに属し続ける。
メソッドを呼び出すスレッドとオブジェクトが同じアパートメントに属す場合、COMの介入無しに直接呼び出される。
メソッドを呼び出すスレッドとオブジェクトが異なるアパートメントに属す場合、そのメソッド呼び出しはマーシャリングを利用して行われる。これにはプロキシとスタブが利用される。
COMの世界では、シングルスレッドアパートメント (STA)、マルチスレッドアパートメント (MTA)、中立アパートメント (NA) の3つのアパートメントモデルがある。各アパートメントは、オブジェクトの内部状態が複数のスレッドを超えて同期されるかどうかという1つのメカニズムを表している。
シングルスレッドアパートメントモデルは非常に一般的に利用されているモデルである。ここではCOMオブジェクトはデスクトップアプリケーションのユーザーインタフェースに似た立場にある。STAモデルでは、単一のスレッドがオブジェクトのメソッドを動かすことに専念している。つまり常に単一のスレッドでオブジェクトのメソッドが実行される。このようなアパートメントでは、アパートメントの外にあるスレッドからのメソッドコールはマーシャリングされ、（標準のWindowsのメッセージキューを利用して）システムによって自動的にキューに入れられる。これによりその呼び出しが完了してから各オブジェクトのメソッド呼び出しが実行されるようになり、レースコンディションや同期性の欠如といった心配がない。プロセスの中で最初に作られたSTAは特にメインSTAと呼ばれ、マルチスレッドを全く考慮していないCOMオブジェクトはメインSTAだけで動作させられる。
COMオブジェクトのメソッドの同期を自分で取りたい場合、メソッドを呼び出したスレッドと同一のスレッドでメソッドを処理するようにできる。これをマルチプルスレッドアパートメントと呼ぶ。ただし、STAスレッドからのMTAオブジェクトのメソッド呼び出しはマーシャリングされる。プロセスは複数のCOMオブジェクトで構成でき、その一部をSTAにしてそれ以外はMTAを利用するというようにできる。
COM+で導入されたスレッド中立アパートメントは、オブジェクトのメソッド呼び出しを管理する必要がない場合に用いられる。唯一の条件はオブジェクトの全てのメソッドがリエントラント（再入可能）でなければならないということである。中立アパートメントに属すオブジェクトのメソッドは、STAスレッド・MTAスレッド、どちらからでもマーシャリングなしに直接呼び出せる。
通幻寂霊

通幻寂霊（つうげん じゃくれい、元亨2年（1322年） - 明徳2年/元中8年5月5日（1391年6月7日））は、南北朝時代の曹洞宗の僧。俗姓は藤原氏。諱は寂霊。道号は通幻。
概要

出身地には諸説あり、豊後国國東郷（国東郡）武蔵郷（現・大分県国東市国東町治郎丸）とするものや、因幡国岩井郡などがある。
17歳で豊後国大光寺（現・大分県国東市国見町竹田津）の定山祖禅について出家し、翌年大宰府戒壇院で受戒している。1340年加賀国大乗寺の明峰素哲に、1352年能登国總持寺の峨山韶碩に師事してその法を継いだ。1368年總持寺5世となり、1370年細川頼之の庇護を受け丹波国に永澤寺を開いた。後円融天皇の勅命により洞上の僧録となり、その後再び総持寺に住した。1386年越前国に龍泉寺を開いている。通幻の門下には「通幻十哲」と呼ばれる優れた禅僧を輩出した。梅山聞本の法を嗣いだ傑堂能勝も、通幻寂霊に師事していた時期がある。
伝承

民話「子育て幽霊」の幽霊によって育てられた赤ん坊の後身が寂霊であるとする伝承がある。
通幻寂霊の指導は厳しく、時には活埋杭（かつまいきょう）と言って、悟りを開かない僧を生き埋めにすることもあった。しかしながら、その厳しい指導によって、悟って仏道を体得する僧侶を輩出したため、通玄派は、曹洞宗の大きな勢力となって、仏道の流布、宗門の興隆をもたらした。
通幻十哲

了庵慧明：総持寺16世、神奈川県最乗寺開山、永澤寺2世、千葉・滋賀総寧寺各2世
石屋真梁：総持寺20世、鹿児島県妙円寺・福昌寺・山口県大寧寺・岡山県西来寺各開山、永澤寺3世
一径永就：永澤寺4世、景福寺各開山
普済善救：総持寺12世、福井県禅林寺開山、永澤寺5世、石川県永光寺29世
不見明見：総持寺19世、福井県興禅寺・島根県総光寺・山口県海潮寺各開山、永澤寺6世
天真自性：福井県慈眼寺開山、永澤寺7世
天鷹祖祐：愛知県正眼寺・雲興寺・兵庫県洞光寺各開山、永澤寺8世
天徳曇貞：総持寺29世、福井県宗生寺・滋賀県大光寺・山口県大陽寺各開山、永澤寺9世
量外聖壽：鹿児島県永興寺[要曖昧さ回避]開山、永澤寺10世
芳庵祖厳：総持寺23世、福井県願成寺開山、永澤寺11世
アガサ・クリスティー ミス・マープル

| アガサ・クリスティー ミス・マープル |
| --- | --- |
ジャンル:  ミステリードラマ
原作:  アガサ・クリスティ
出演者:  シーズン1 - 3 ジェラルディン・マクイーワン シーズン4 - 6 ジュリア・マッケンジー
製作
制作:  グラナダテレビ WGBHボストン

放送
放送国・地域:  イギリス ITV・STV・UTV  日本 NHKBSプレミアム・LaLa TV他
放送期間: 2004年 - 2013年
放送時間: 88 - 94分
回数: 23
テンプレートを表示
『アガサ・クリスティー ミス・マープル』（Agatha Christie's Marple）は、推理作家アガサ・クリスティの作品を原作に、イギリスのITVとアメリカのWGBH-TVが共同で制作・放送したテレビドラマのシリーズ。主演のミス・マープルは、シーズン1からシーズン3までをジェラルディン・マクイーワン（英語版） (発音はマキューアン)、シーズン4からシーズン6までをジュリア・マッケンジー（英語版）が務めた。
シーズン1からシーズン5までは4エピソード、シーズン6のみ3エピソードで構成されている。ミス・マープルシリーズを原作としているのは最初の6話（シーズン1からシーズン2第2話）のみで、他はマープルシリーズと他作品を混合した作品である。原題"Agatha Christie's Marple" に"Miss" がないのは、"Agatha Christie's Poirot" （『名探偵ポワロ』として放送）に倣ったためである。
シーズン6終了後、BBCはITVに続編（シーズン7）制作の意思がないことをほのめかしつつ、クリスティの作品の映像化の権利を得たことを発表した。
主なあらすじ

セント・メアリ・ミード村に静かに暮らす老婦人ミス・ジェーン・マープルの活躍が描かれる。他の村の友人や親戚を訪ねたマープルが、度々不可解な殺人に遭遇し、事件を解決していく。警察は往々にしてマープルの介入を好まないが、マープルの名声や比類なき観察力は時に彼らを圧倒する。
事件の捜査中に、クリスティの別作品の主人公トミーとタペンスに出会う場面もある。
登場人物

全エピソードに登場するのはミス・マープルのみで、前半3シリーズをジェラルディン・マクイーワン（英語版）が、後半3シリーズをジュリア・マッケンジー（英語版）が演じている。
複数エピソードに登場する人物も何人かいるが、同じ俳優が演じているわけではない。例外は『書斎の死体』と『鏡は横にひび割れて』でミセス・バントリーを演じたジョアナ・ラムリーと、4エピソードで検死官役を演じたスティーヴン・チャーチェット（英語版）である。
ヘイドック医師は3エピソードに登場するが、全て異なる俳優が演じており、『書斎の死体』ではロビン・ソーンズ（英語版）が、『牧師館の殺人』ではロバート・パウエル（英語版）が、『鏡は横にひび割れて』ではニール・ステューク（英語版）が演じた。マープルの古くからの友人ジェイソン・ラフィエルは、『復讐の女神』では、『牧師館の殺人』にデュフォス教授役で出演したハーバート・ロムが声を当て、『カリブ海の秘密』ではアントニー・シャー（英語版）が演じた。
非映像化作品

ミス・マープルシリーズの長編全12作は全て本作で映像化されている。
しかし、短編で映像化されていない作品がまだ残っており、それらが映像化されるか否かは不明である。「青いゼラニウム」は長編として制作され、「グリーンショウ氏の阿房宮」は「聖ペテロの指のあと」と繋ぎ合わせる形で制作された。「毒草」は『チムニーズ館の秘密』の一部として制作された。
ノミネート

2005年、ジェラルディン・マクイーワンが第10回サテライト賞主演女優賞（ミニシリーズ部門）にノミネートされた。また、同年シーズン1はプライムタイム・エミー賞 作品賞 (ミニシリーズ/テレビ映画部門)にノミネートされた。
世界への配給

アメリカでは、PBS（公共放送サービス）のミステリードラマ枠"Mystery!" にて"Agatha Christie's Miss Marple"のタイトルで放送された。カナダ全域でカナダ放送協会で（レディオ・カナダではフランス語版）放送された。オーストラリアでは、原題のままオーストラリア放送協会で放送された。
香港ではATVワールドで、韓国ではMegaTVで、中国ではCCTV-8で放送された。なお、中国では『書斎の死体』と『殺人は容易だ』はレズビアンや近親相姦がストーリーに関わってくるため放送されなかった。また、『なぜ、エヴァンズに頼まなかったのか?』は中国の終戦のエピソードが出てくるため大幅に編集されて放送された。
ノルウェーではNRK1で"Miss Marple" として、スウェーデンではTV4で"Marple" として、ポーランドではAle Kino+で、チェコではチェコ語でミス・マープルを意味する"Slečna Marplová" として放送された。
ブラジルでは、ブラジルHBOで放送された。
世界への配給 > 日本

日本ではNHKBSプレミアムほかで放送された。
主な出演者の声の吹き替えはシーズン1でジェラルディン・マクイーワン（岸田今日子）、イアン・リチャードソン（内田稔）、タラ・フィッツジェラルド（藤生聖子）、レイチェル・スターリング（山崎美貴）、ジェーン・アッシャー（一城みゆ希）が務めた。なお岸田の亡くなった後に放送されたシーズン2ではマープル役は草笛光子に、シーズン4以降ジュリア・マッケンジーがマープルを演じるのに合わせて、藤田弓子が起用された。
原作からの変更点

映像化に当たって、いくつかの変更があり、視聴者に議論を巻き起こした。第1話『書斎の死体』では、犯人の1人を変え、プロットに同性愛のエピソードを盛り込んだ。第2話ではマープルの若い頃のエピソードを挿入し、第3話では犯行の動機が変更され、第4話では登場人物が減らされ、原作で控えめに表現されているレズビアンのエピソードが強調された。
シーズン2でも変更点がいくつか見られる。トミーとタペンスシリーズの『親指のうずき』や、シリーズ外の『シタフォードの秘密』などがミス・マープルものとして、犯人を変更して制作された。
シーズン3の『無実はさいなむ』と『ゼロ時間へ』もシリーズ外の作品である。シリーズ外の作品を取り入れる傾向は続き、シーズン4では『殺人は容易だ』や『なぜ、エヴァンズに頼まなかったのか?』が、シーズン5では『チムニーズ館の秘密』と『蒼ざめた馬』が、シーズン6では『終わりなき夜に生まれつく』がそれに相当する。
| S | サブタイトル | 変更点 |
| --- | --- | --- |
| 1-1 | 書斎の死体 | レズビアンのエピソードを追加、犯人の1人を変更 |
| 1-2 | 牧師館の殺人 | マープルの若かりし頃のエピソードを追加 |
| 1-3 | パディントン発4時50分 | 犯人の犯行動機を変更 |
| 1-4 | 予告殺人 | 登場人物を複数人変え、レズビアンの関係を強調 |
| 2-1 | スリーピング・マーダー | 恋愛関係のエピソードを中心に追加 |
| 2-2 | 動く指 | メインのトリックを変更 |
| 2-3 | 親指のうずき | 原作はトミーとタペンスシリーズ、プロットの要素を変更 |
| 2-4 | シタフォードの秘密 | 原作はシリーズ外作品、犯人を変更 |
| 3-1 | バートラム・ホテルにて | プロット、登場人物、設定など多くを変更 |
| 3-2 | 無実はさいなむ | 原作はシリーズ外作品、登場人物を大幅に変更 |
| 3-3 | ゼロ時間へ | 原作はシリーズ外作品 |
| 3-4 | 復讐の女神 | 容疑者と設定を変更 |
| 4-1 | ポケットにライ麦を | 登場人物に多少の変更があるが、ほぼ原作に忠実 |
| 4-2 | 殺人は容易だ | 原作はシリーズ外作品、犯行動機を変更 |
| 4-3 | 魔術の殺人 | 複数の登場人物をまとめ、放火事件を追加 |
| 4-4 | なぜ、エヴァンズに頼まなかったのか? | 原作はシリーズ外作品 |
| 5-1 | 蒼ざめた馬 | 原作はシリーズ外作品 |
| 5-2 | チムニーズ館の秘密 | 原作はシリーズ外作品、犯人を変更、短編「毒草」の要素を追加 |
| 5-3 | 青いゼラニウム | 原作にほぼ忠実 |
| 5-4 | 鏡は横にひび割れて | 原作にほぼ忠実 |
| 6-1 | カリブ海の秘密 | 原作にほぼ忠実 |
| 6-2 | グリーンショウ氏の阿房宮 | 「親指のうずき」と合体、コアな部分は原作に忠実 |
| 6-3 | 終わりなき夜に生まれつく | 原作はシリーズ外作品だが、マープルシリーズの短編「管理人事件」と似ている |
DVD

| シーズン | 国 | 発売 |
| --- | --- | --- |
| シーズン1 |  イギリス （リージョン2） | 2005年03月 |
| シーズン1 |  アメリカ合衆国 （リージョン1） | 2005年05月 |
| シーズン1 |  日本 （リージョン2） | 2007年11月 |
| シーズン2 |  イギリス | 2006年07月 |
| シーズン2 |  アメリカ合衆国 | 2006年08月 |
| シーズン2 |  日本 | 2008年11月 |
| シーズン3 |  アメリカ合衆国 | 2007年10月 |
| シーズン3 |  イギリス | 2008年10月 |
| シーズン3 |  日本 | 2010年08月 |
| シーズン4 |  イギリス | 2010年01月 |
| シーズン4 |  アメリカ合衆国 | 2009年08月 |
| シーズン4 |  日本 | 2012年10月 |
| シーズン5 |  アメリカ合衆国 | 2010年08月 |
| シーズン5 |  イギリス | 2011年06月 |
| シーズン5 |  日本 | 2012年11月 |
| シーズン6 |  イギリス | 2014年01月 |
| シーズン6 |  日本 | 2015年02月 |
| シーズン1-5 コレクションボックス |  イギリス | 2011年08月 |
| シーズン1-6 DVD-BOX |  イギリス | 2014年01月 |
ブルーレイディスク

| シーズン | 国 | 発売 |
| --- | --- | --- |
| シーズン1-5 Blu-ray BOX |  スペイン （リージョン・フリー） |  |
撮影

撮影は、ロンドンを含む、バークシャー・エングルフィールド村、ケント・チラム村、バッキンガムシャー・ターヴィル、オックスフォードシャー・ブルーバリーなどで行われた。ウィンザーのウィンザー・ギルドホールは『牧師館の殺人』で使用された。ネブワースのカントリー・ハウス、ネブワース・ハウスは『パディントン発4時50分』や『グリーンショウ氏の阿房宮』で、ハットフィールド・ハウスは『チムニーズ館の秘密』でチムニーズ館として使用された。ハンブルドン村はセント・メアリ・ミード村や『書斎の死体』に登場するマナー・ハウス、バントリー氏の居館ゴッシントン・ホールとして、『なぜ、エヴァンズに頼まなかったのか?』に登場するサヴェージ城はギルフォードにあるマナー・ハウス、ラズリー・パークが使用された。『カリブ海の秘密』の撮影は南アフリカ共和国のケープタウンで、ビーチのシーンはボルダーズ・ビーチで行われた。最終話『終わりなき夜に生まれつく』はドーセット州ドーチェスターで撮影された。
視聴者数

データはイギリスのNPO BARBの視聴率調査による。
| 放送日 | サブタイトル | 視聴者数 （100万人） |
| --- | --- | --- |
| 2004年12月12日 | 書斎の死体 | 8.72 |
| 2004年12月19日 | 牧師館の殺人 | 8.36 |
| 2004年12月26日 | パディントン発4時50分 | 5.95 |
| 2005年01月02日 | 予告殺人 | 7.78 |
| 放送日 | サブタイトル | 視聴者数 （100万人） |
| --- | --- | --- |
| 2006年02月05日 | スリーピング・マーダー | 8.74 |
| 2006年02月12日 | 動く指 | 7.89 |
| 2006年02月19日 | 親指のうずき | 7.93 |
| 2006年04月30日 | シタフォードの秘密 | 6.58 |
| 放送日 | サブタイトル | 視聴者数 （100万人） |
| --- | --- | --- |
| 2007年09月23日 | バートラム・ホテルにて | 5.41 |
| 2007年09月30日 | 無実はさいなむ | 5.54 |
| 2008年08月03日 | ゼロ時間へ | 5.84 |
| 2009年01月01日 | 復讐の女神 | 4.48 |
| 放送日 | サブタイトル | 視聴者数 （100万人） |
| --- | --- | --- |
| 2009年09月06日 | ポケットにライ麦を | 5.39 |
| 2009年09月13日 | 殺人は容易だ | 4.86 |
| 2010年01月01日 | 魔術の殺人 | 5.55 |
| 2011年06月15日 | なぜ、エヴァンズに頼まなかったのか? | 4.51 |
| 放送日 | サブタイトル | 視聴者数 （100万人） |
| --- | --- | --- |
| 2010年08月30日 | 蒼ざめた馬 | 5.11 |
| 2010年12月27日 | チムニーズ館の秘密 | 5.06 |
| 2010年12月29日 | 青いゼラニウム | 5.96 |
| 2011年01月02日 | 鏡は横にひび割れて | 4.93 |
| 放送日 | サブタイトル | 視聴者数 （100万人） |
| --- | --- | --- |
| 2013年06月16日 | カリブ海の秘密 | 4.89 |
| 2013年06月23日 | グリーンショウ氏の阿房宮 | 5.11 |
| 2013年12月29日 | 終わりなき夜に生まれつく | 5.34 |
アメリカン・ミー

| アメリカン・ミー |
| --- | --- |
 American Me
監督:  エドワード・ジェームズ・オルモス
脚本:  フロイド・マトラックス デズモンド・ナカノ
製作:  エドワード・ジェームズ・オルモス ショーン・ダニエル ロバート・Ｍ・ヤング
製作総指揮:  フロイド・マトラックス アーウィン・ヤング ルー・アドラー
音楽:  デニス・ランバート クロード・ゴーデット
撮影:  レイナルド・ビジャロボス
編集:  リチャード・カンディブ アーサー・コバーン
制作会社:  YOY プロダクションズ オルモス・プロダクション ショーン・ダニエル・カンパニー
配給:  ユニバーサル・ピクチャーズ
公開:   1992年3月13日  1992年（東京国際映画祭）
上映時間:  126分
製作国:   アメリカ合衆国
言語:  英語 スペイン語
テンプレートを表示
アメリカン・ミー（原題：American Me）は、1992年のアメリカ合衆国の犯罪ドラマ映画。エドワード・ジェームズ・オルモスの初監督作品で、メキシカン・マフィアの実態を描いた作品。
日本では東京国際映画祭で上映された他、VHS・DVDが発売された。
あらすじ

少年院で自分をレイプした男を殺害したチカーノが刑務所でギャングのリーダーになり、やがて破滅していくまで描く。
キャスト

※括弧内は日本語吹替（DVD版）
モントーヤ・サンタナ：エドワード・ジェームズ・オルモス（山路和弘）
J.D.：ウィリアム・フォーサイス（廣田行生）
パペット：ダニー・デ・ラ・パズ（小形満）
ムンド：ペペ・セルナ（諸角憲一）
ジュリー：イヴェルナ・フェルナンデス（磯西真喜）
ヒューロ：ダニエル・A・ハロ
エル・ジャポ：ケイリー＝ヒロユキ・タガワ
エスペランサ・サンタナ：ヴィラ・モンテス
リトル・パペット：ダニエル・ビジャレアル
アチャ：ロベルト・マルティン・マルケス
ヨランダ：ディアナ・オルテリ
パウリート・サンタナ：ジェイコブ・バルガス
ジュビー・ホール・アタッカー：エリック・クローズ
ビッグ・ハッピー：リゴベルト・ヒメネス
制作

刑務所のシーンはカリフォルニア州にある実際の刑務所内で撮影が行われ、800人の受刑者と看守がエキストラとして起用された。
騒動

本作の性的暴行の描写に腹を立てたマフィアが本作に関わったコンサルタントを3人殺害するという事件が発生。オルモス自身も殺害予告を受け、しばらく隠遁生活を送ったという。
その他、本作にエキストラとして出演したギャングが警官に射殺された。