Классы и IDL

Как уже отмечалось в начале этой главы, СОМ рассматривает интерфейсы и классы как отдельные сущности. В свете этого классы СОМ (а равно и интерфейсы СОМ) должны быть определены в IDL с целью обеспечить независимое от языка описание конкретных типов данных, которые может экспортировать сервер. IDL-определение класса СОМ содержит список интерфейсов, которые экспортируются элементами класса, исключая катастрофический сбой:

[uuid(753A8A7D-A7FF-11d0-8C30-0080C73925BA)]

coclass Gorilla { interface IApe; interface IWarrior; }

IDL -определения коклассов (coclass) всегда появляются в контексте определения библиотеки (library definition). В IDL определения библиотек используются для группирования набора типов данных (например, интерфейсы, коклассы, определения типов) в логический блок или пространство имен. Все типы данных, появляющиеся в контексте определения библиотеки IDL, будут отмечены в результирующей библиотеке типов. Библиотеки типов используются вместо IDL-файлов такими средами, как Visual Basic и Java.

Как правило, IDL-файл может содержать один библиотечный оператор, и все типы данных, определенные или использованные внутри определения библиотек, появятся в генерируемой библиотеке типа:

// apes.idl // bring in IDL definitions of ape interfaces

// введем IDL-определения интерфейсов обезьян

import «apeitfs.idl»;

[ uuid(753A8A80-A7FF-11d0-8C30-0080C73925BA),

// LIBID – идентификатор библиотеки version(1.0),

// version number of library – номер версии библиотеки

lcid(9),

// locale ID of library (english)

// код локализации библиотеки (english)

helpstring(«Library of the Apes»)

// title of library – заголовок библиотеки

]

library ApeLib { importlib(«stdole32.tlb»);

// bring in std defs. – вносим стандартные опредепения

[uuid(753A8A7D-A7FF-11d0-8C30-0080C73925BA)] coclass Gorilla {

[default] interface IApe;

interface IWarrior; }

[uuid(753A8A7E-A7FF-11d0-8C30-0080C73925BA)] coclass Chimpanzee {

[default] interface IApe;

interface IEgghead; }

[uuid(753A8A7F-A7FF-11d0-8C30-O080C73925BA)] coclass Orangutan {

[default] interface IApe;

interface IKeeperOfTheFaith; } }

Атрибут [default] показывает, какой из интерфейсов наиболее близко представляет внутренний тип класса. В тех языках, которые распознают этот атрибут, [default] позволяет программисту объявлять ссылки объекта, используя только имя кокласса СОМ:

Dim ursus as Gorilla

Исходя из IDL-определения для Gorilla, данный оператор эквивалентен следующему:

Dim ursus as IApe

поскольку IApe является интерфейсом по умолчанию для класса Gorilla. В любом случае программист мог вызывать методы EatBanana и SwingFromTree с переменной ursus. Если атрибут [default] не указан, то он неявно добавляется к первому интерфейсу в определении coclass.

Имея указанное выше библиотечное определение IDL, результирующий заголовочный файл apes.h будет использовать препроцессор С для включения файла apesitfs.h. Этот файл apesitfs.h будет содержать определения абстрактных базовых классов для четырех интерфейсов СОМ IApe, IWarrior, IKeeperOfTheFaith и IEgghead. Кроме того, файл apes.h будет содержать объявления GUID для каждого класса:

extern "С" const CLSID CLSID_Gorilla;

extern "С" const CLSID CLSID_Chimpanzee;

extern "С" const CLSID CLSID_Orangutan;

Соответствующий файл apes_i.с будет содержать определения этих CLSID. Сгенерированная библиотека типов apes.tlb будет содержать описания каждого из интерфейсов и классов, что позволит программисту на Visual Basic написать следующее:

Dim ape As IApe

Dim warrior as IWarrior

Set ape = New Gorilla

' ask СОМ for a new gorilla

' запрашиваем СОМ о новой

gorilla Set warrior = ape

А вот так выглядит Java-версия того же самого кода:

IАре аре;

IWarrior warrior;

аре = new Gorilla();

// no cast needed for [default]

// никаких приведений не требуется для [default] ???

warrior = (IWarrior)ape;

Оба этих фрагмента кода предписывают виртуальной машине использовать CLSID_Gorilla для сообщения CoCreateInstanceEx о том, какой тип объекта нужно создать.

В предыдущем IDL на каждый из интерфейсов IApe, IWarrior, IEgghead и IKeeperOfTheFaith есть ссылки из определения библиотеки. По этой причине их определения присутствуют в генерируемой библиотеке типов, несмотря та то, что они определены вне области действия определения библиотеки. В действительности любые типы данных, используемые как параметры или как базовые интерфейсы для данных интерфейсов, будут в то же время присутствовать в генерируемой библиотеке. Существует хорошая практика – определять оператор с реализацией библиотеки в отдельном IDL-файле, который импортирует все необходимые определения интерфейсов из внешнего IDL-файла, содержащего только описания интерфейсов. Такая практика является обязательной в больших проектах со многими IDL-файлами, так как для IDL-файла, содержащего определение библиотеки, недопустимо импортировать другой IDL-файл, который также содержит определение библиотеки. Путем разделения определений библиотеки по отдельным IDL-файлам можно корректно импортировать интерфейсы, используемые библиотекой, в другие проекты, не беспокоясь о множественных определениях библиотеки. Если не использовать этот способ, то существует только одна возможность импортировать определение интерфейса из IDL-файла, содержащего определение библиотеки, – использовать директиву importlib:

// humans.idl

// apeitfs.idl DOESN'T have a library statement, so import

// apeitfs.idl HE ИМЕЕТ оператора library, поэтому импортируем

import «apeitfs.idl»;

[ uuid(753A8AC9-A7FF-11d0-8C30-0080C73925BA), version(1.0), lcld(9), helpstring(«Humans that need apes»)

// «Люди, нуждающиеся в обезьянах»

]

library HumanLib {

importlib(«stdole32.tlb»);

// bring in std defs. – вносим стандартные определения

// Dogs.idl DOES have a library definition, so importlib

// its corresponding type library

// Dogs.idl ИМЕЕТ определение библиотеки, поэтому

// импортируем библиотеку соответствующего типа

importlib(«dogs.tlb»);

[uuid(753A8AD1-A7FF-11d0-8C30-0080C73925BA)]

coclass DogApe {

interface IDog;

interface IApe;

} }

В простых проектах часто используется один IDL-файл, в котором определяются как интерфейсы, так и классы, экспортируемые из проекта. Для простых интерфейсов это имеет смысл, так как генерируемая библиотека типов будет содержать взаимно однозначные образы исходных определений IDL, что позволит пользователям этой библиотеки применять importlib без потери информации. К сожалению, в случае сложных интерфейсов многие из исходных IDL-измов (IDL-ism) теряются в результирующей библиотеке типов, и тогда importlib не будет работать так, как хотелось бы. Грядущая версия компилятора MIDL, быть может, будет способна генерировать библиотеки типов, которые будут содержать все из исходного IDL.

Эмуляция классов

Часто случается, что разработчики классов желают развернуть новые версии уже существующих классов, чтобы исправить дефекты или расширить функциональные возможности. Полезно придать этим новым реализациям новые идентификаторы класса CLSID , чтобы клиенты могли четко различать, какая версия им нужна. В качестве примера посмотрим, что происходит, когда развертывается новая версия класса. Если для идентификации нового класса используется новый CLSID, (например, CLSID_Chimp2), то клиентам, определенно желающим использовать новую версию, следует использовать новый CLSID во время активации: // new client – новый клиент

IАре *рАре = 0; hr = CoCreateInstance(CLSID_Chimp2, 0, CLSCTX_ALL, IID_Ape, (void**)&pApe);

Использование второго CLSID гарантирует, что клиенты не получат случайно старую версию класса Chimp . В то же время старые клиенты делают запросы на активацию с применением старого CLSID:

// old client – старый клиент

IАре *рАре = 0;

hr = CoCreateInstance(CLSID_Chimp, 0, CLSCTX_ALL, IID_Ape, (void**)&pApe);

Чтобы продолжать поддержку старых клиентов, разработчику Chimp необходимо сохранить в реестре исходный CLSID для удовлетворения этих запросов на активацию. Если изменилась семантика класса, то необходимо, чтобы исходный сервер также оставался доступным для этих клиентов. Однако бывает, что семантика просто расширяется. В этом случае предпочтительнее просто переадресовать запросы на активацию от старых клиентов на создание экземпляров нового класса.

Чтобы дать возможность разработчику новой версии класса прозрачно удовлетворять запросы на активацию для других CLSID , в СОМ введено понятие эмуляции классов (class emulation). Эмуляция классов позволяет разработчику компонента указать, что старый CLSID заменен новым, альтернативным CLSID, эмулирующим семантику исходного класса. Это позволяет прежним клиентам, делающим запросы на активацию с использованием прежнего CLSID, получать экземпляры нового усовершенствованного класса. Для индикации того, что у класса имеется новая альтернативная версия, в СОМ существует такая API-функция:

HRESULT CoTreatAsClass([in] REFCLSID rclsidOld, [in] REFCLSID rclsidNew);

Пусть Сhimp2 является новой версией класса Chimp, тогда следующий код проинформирует СОМ, что необходимо переадресовать запросы на активацию Chimp на запросы на активацию Chimp2:

// cause Chimp activation calls to activate Chimp2

// заставим запросы на активацию Chimp активизировать Chimp2

HRESULT hr = CoTreatAsClass(CLSID_Chimp, CLSID_Chimp2);

Эта API-функция добавляет следующий ключ реестра (registry key)

[HKCR\CLSID\{CLSID_Chimp}\TreatAs][1] @={CLSID_Chimp2}

Вызов CoTreatAsClass c CLSID_NULL в качестве второго параметра удаляет настройку TreatAs:

// cause Chimp activation calls to activate Chimps

// заставим запросы на активацию Chimp

// активизировать Chimps

HRESULT hr = CoTreatAsClass(CLSID_Chimp, CLSID_NULL);

Этот запрос восстанавливает исходную реализацию класса в состояние, предшествующее эмуляции. Клиенты могут запросить установку эмуляции данного класса, используя API-функцию CoGetTreatAsClass:

HRESULT CoGetTreatAsClass ([in] REFCLSID rclsidOld, [out] REFCLSID *pclsidNew);

Если запрошенный класс эмулируется другим классом, то CLSID эмулирующего класса будет возвращен посредством второго параметра и вся подпрограмма возвратит S_OK . Если же запрошенный класс не эмулируется другим классом, то посредством второго параметра будет возвращен исходный CLSID и подпрограмма возвратит S_FALSE. Необходимо также отметить, что в момент написания этой книги эмуляция классов не работает должным образом для удаленных запросов на активацию.

Категории компонентов

Как подчеркивалось в этой главе, основные примитивы активации СОМ требуют, чтобы вызывающей программе при создании новых экземпляров класса было известно его точное имя. Иногда, однако, бывает полезно просто потребовать, чтобы подходящим являлся любой класс, удовлетворяющий некоторым семантическим ограничениям. Кроме того, прежде чем сделать запрос на активацию, было бы полезно знать, какие сервисные средства класс требует от своих клиентов. В этом случае не будут создаваться объекты, которые клиент не готов должным образом поддерживать. Эти проблемы послужили причиной для создания категорий компонентов (component categories).

СОМ дает разработчикам возможность группировать родственные СОМ-классы в логические группы, или категории компонентов. Чаще всего все классы внутри категории будут реализовывать один и тот же набор интерфейсов. В то же время простое разделение пространства классов на части по признаку, какие интерфейсы какой класс реализует, не обеспечивает должного уровня модульности для многих приложений. Категории компонентов выступают как метаинформация, показывающая, какие классы совместимы с определенными семантическими ограничениями.

Категория компонентов есть группа логически родственных СОМ-классов, которые разделяют общий ID категории, или CATID. Идентификаторы категории CATID – это GUID, записанные в реестре как атрибуты класса. Каждый класс может иметь два подключа: Implemented Categories и Required Categories (реализованные категории и нужные категории). Представим, что есть две категории компонентов: Simians и Mammals (приматы и млекопитающие). Каждая из этих двух категорий будет иметь уникальный CATID (CATID_Simians и CATID_Mammals соответственно). Допустим, что класс Chimp является членом каждой из этих категорий, и тогда для Chimp ключ реестра Implemented Categories будет содержать в себе каждый GUID как отдельный подключ:

[HKCR\CLSID\{CLSID_Chimp}\Implemented Categories\{CATID_Mammals}]

[HKCR\CLSID\{CLSID_Chimp}\Implemented Categories\{CATID_Simians}]

Эти элементы реестра обычно добавляются во время саморегистрации. Каждая известная категория компонентов в системе имеет запись в разделе реестра HKEY_CLASSES_ROOT\Component Categories

Каждая категория имеет свой собственный уникальный подключ, названный как CATID. Под этим подключом каждая категория имеет одну или более именованных величин, содержащих текстовое описание этой категории. Например, двум показанным выше категориям понадобятся такие элементы реестра:

[HKCR\Component Categories\{CATID_Mammals}] 409="Bears live young"

[HKCR\Component Categones\{CATID_Simians}] 409="Eats Bananas"

Отметим, что в этом примере используется величина 409, являющаяся кодом локализации, или локальным идентификатором языка LCID (locale identifier), для U.S.English. Другая местная специфика может поддерживаться путем добавления дополнительных именованных величин.

Классы также могут указать, что они требуют от клиента функциональное назначение определенного типа. Обычно такая поддержка принимает вид узловых интерфейсов (site interfaces), которые клиент предоставляет активированному объекту. Для того, чтобы разделить эти предоставляемые клиентом сервисы на категории, не зависящие от отдельного интерфейса, СОМ позволяет классам объявлять второй тип категорий ID; он может использоваться клиентами для гарантии того, что они не активировали компонент, который не могут должным образом принять. Рассмотрим следующие две категории сервисов, предоставляемых клиентом: CATID_HasOxygen и CATID_HasWater. Поскольку для выживания шимпанзе необходимы кислород и вода, разработчик Chimp должен объявить, что эти две категории сервисов, предоставляемых клиентом, необходимы для активации. Это делается с помощью подключей из Required Categories:

[HKCR\CLSID\{CLSID_Chimp}\Required Categories\{CATID_HasOxygen}]

[HKCR\CLSID\{CLSID_Chimp}\Required Categories\{CATID_HasWater}]

Кроме того, ID этих двух категорий следует внести в реестр под ключом HKEY_CLASSES_ROOT\Component Categories

Получив эти записи, сам клиент перед активацией должен убедиться в том, что он удовлетворяет запрошенным категориям. СОМ не обеспечивает согласование с клиентом.

Элементы категорий компонентов могут быть зарегистрированы либо с помощью явных функций реестра, либо с использованием предлагаемого СОМ менеджера категорий компонентов (component category manager). Этот менеджер категорий компонентов объявляется в СОМ как создаваемый СОМ-класс (CLSID_StdComponentCategoriesMgr), который реализует интерфейс ICatRegister для регистрации информации о категории и интерфейс ICatInformation для запроса информации о категории. Интерфейс ICatRegister позволяет библиотекам DLL сервера легко добавлять в реестр необходимые элементы:

[object, uuid(0002E012-0000-0000-C000-000000000046)]

interface ICatRegister : IUnknown {

// description info for a category

// описательная информация для категории

typedef struct tagCATEGORYINFO

{ CATID catid; LCID lcid; OLECHAR szDescription[128]; }

CATEGORYINFO;

// register cCts category descriptions

// регистрируем описания категории cCts

HRESULT RegisterCategories([in] ULONG cCts,

[in, size_is(cCts)] CATEGORYINFO rgCatInfo[]);

// unregister cCategories category descriptions

// отменяем регистрацию описаний категории

cCategories HRESULT UnRegisterCategories([in] ULONG cCategories,

[in, size_is(cCategories)] CATID rgcatid[]);

// indicate a class implements one or more categories

// показываем, что класс реализует одну или более категорий

HRESULT RegisterClassImplCategories([in] REFCLSID rclsid,

[in] ULONG cCategories,

[in, size_is(cCategories)] CATID rgcatid[]);

// deindicate a class implements one or more categories

// перестаем показывать, реализует класс одну или более категорий

HRESULT UnRegisterClassImplCategories([in] REFCLSID rclsd,

[in] ULONG cCategories,

[in, size_is(cCategories)] CATID rgcatid[]);

// indicate a class requires one or more categories

// показываем, что класс требует одну или более категорий

HRESULT RegisterClassReqCategories([in] REFCLSID rclsid,

[in] ULONG cCategories,

[in, size_is(cCategories)] CATID rgcatid[]):

// deindicate a class requires one or more categories

// перестаем показывать, требует ли класс одну или более категорий

HRESULT UnRegisterClassReqCategones([in] REFCLSID rclsid,

[in] ULONG cCategories,

[in, size_is(cCategories)] CATID rgcatid[]); }

Для определяемых пользователем СОМ-классов нет необходимости реализовывать этот интерфейс. Он существует единственно для того, чтобы серверы смогли сами зарегистрировать свои категории компонентов с использованием реализации предоставляемого СОМ менеджера категорий компонентов.

В случае примера с Chimp следующий код зарегистрирует правильную информацию о каждой категории:

// get the standard category manager

// получим стандартный менеджер категорий

ICatRegister *pcr = 0; HRESULT hr = CoCreateInstance(

CLSID_StdComponentCategoriesMgr, 0,

CLSCTX_ALL, IID_ICatRegister, (void**)&pcr); if (SUCCEEDED(hr)) {

// build descriptions of each category

// формируем описания каждой категории

CATECORYINFO rgcc[4];

rgcc[0].catid = CATID_Simian;

rgcc[1].catid = CATID_Mammal;

rgcc[2].catid = CATID_HasOxygen;

rgcc[3].catid = CATID_HasWater;

rgcc[0].lcid = rgcc[1].lcid = rgcc[2].lcid = rgcc[3].lcid = 0х409;

wcscpy(rgcc[0].szDescription, OLESTR(«Eats Bananas»));

wcscpy(rgcc[1].szDescription, OLESTR(«Bears live young»));

wcscpy(rgcc[2].szDescription, OLESTR(«Provides Oxygen»));

wcscpy(rgcc[3].szDescription, OLESTR(«Provides Water»));

// register information regarding categories

// регистрируем информацию о категориях

pcr->RegisterCategories(4, rgcc);

// note that Chimps are Simians and mammals

// отметим, что Chimps (шимпанзе) являются Simian

// (обезьянами) и Mammal (млекопитающими)

CATID rgcid[2];

rgcid[0] = CATID_Simian;

rgcid[1] = CATID_Mammal;

pcr->RegisterClassImplCategories(CLSID_Chimp, 2, rgcid);

// note that Chimps require Oxygen and Water

// отметим, что Chimps (шимпанзе) нуждаются

// в кислороде (Oxygen) и воде (Water)

rgcid[0] = CATID_HasOxygen;

rgcid[1] = CATID_HasWater;

pcr->RegisterClassReqCategories(CLSID_Chimp, 2, rgcid);

pcr->Release(); }

Заметим, что в этом коде не делается обычных вызовов реестровых API-функций, а вместо них для обработки реестра используется стандартный менеджер категорий.

Кроме того, стандартный менеджер категорий позволяет приложениям запрашивать реестр найти информацию о категориях. Эта функциональная возможность предоставляется через интерфейс ICatInformation:

[object, uuid(0002E013-0000-0000-C000-000000000046)]

interface ICatInformation : IUnknown

{

// get list of known categories

// получаем список известных категорий

HRESULT EnumCategories([in] LCID lcid, [out] IEnumCATEGORYINFO** ppeci);

// get description of a particular category

// получаем описание определенной категории

HRESULT GetCategoryDesc([in] REFCATID rcatid, [in] LCID lcid, [out] OLECHAR ** ppszDesc);

// get list of classes compatible with specified categories

// получаем список классов, совместимых с указанными категориями

HRESULT EnumClassesOfCategories(

[in] ULONG cImplemented,

// -1 indicates ignore

// (-1) означает игнорировать

[in,size_is(cImplemented)] CATID rgcatidImpl[], [in] ULONG cRequired,

// -1 indicates ignore

// (-1) означает игнорировать

[in,size_is(cRequired)] CATID rgcatidReq[], [out] IEnumCLSID** ppenumClsid);

// verify class is compatible with specified categories

// проверяем, совместим ли класс с указанными категориями

HRESULT IsClassOfCategories([in] REFCLSID rclsid,

[in] ULONG cImplemented,

[in,size_is(cImplemented)] CATID rgcatidImpl[],

[in] ULONG cRequired,

[in,size_is(cRequired)] CATID rgcatidReq[]);

// get list of class's implemented categories

// получаем список реализованных категорий класса

HRESULT EnumImplCategoriesOfClass([in] REFCLSID rclsid,

[out] IEnumCATID** ppenumCatid);

// get list of class's required categories

// получаем список категорий, необходимых классу

HRESULT EnumReqCategoriesOfClass([in] REFCLSID rclsid,

[out] IEnumCATID** ppenumCatid);

}

Большинство этих методов возвращают свои курсоры на списки идентификаторов категории или класса. Эти указатели называются нумераторами (enumerators ) и подробно описываются в главе 7.

Следующий код показывает, как выделить список классов, являющихся членами категории Mammal:

// get the standard category manager // получаем стандартный менеджер категорий

ICatInformation *pci = 0; HRESULT hr = CoCreateInstance(

CLSID_StdComponentCategoriesMgr, 0,

CLSCTX_ALL, IID_ICatInformat1on, (void**)&pci); if (SUCCEEDED(hr)) {

// get the classes that are Simians (ignore required cats)

// получаем классы, являющиеся Simian

// (игнорируем требуемые категории)

IEnumCLSID *pec = 0;

CATID rgcid[1];

rgcid[0] = CATID_Simian;

hr = pci->EnumClassesOfCategories(1, rgcid, -1, 0, &pec);

if (SUCCEEDED(hr)) {

// walk list of CLSIDs 64 at a time

// просматриваем список CLSID no 64 за проход

enum { MAX = 64 };

CLSID rgclsid[MAX];

do {

ULONG cActual = 0;

hr = pec->Next(MAX, rgclsid, &cActual);

if (SUCCEEDED(hr)) {

for (ULONG i = 0; i < cActual; i++)

DisplayClass(rgclsid[i]);

}

}

while (hr == S_OK);

pec->Release();

}

pci->Release(); }

Этот фрагмент кода игнорирует то обстоятельство, что клиентская программа может не поддерживать нужные категории результирующего списка классов. Если бы клиент был осведомлен о том, какие локальные категории им поддерживаются, то он мог бы указать список всех поддерживаемых категорий.

Рассмотрим следующий вызов EnumClassesOfCategories:

CATID rgimpl[1]; rgimpl[0] = CATID_Simians;

CATID rgreq[3]; rgreq[0] = CATID_HasWater;

rgreq[1] = CATID_HasOxygen; rgreq[2] = CATID_HasMilk;

hr =pci->EnumClassesOfCategories(1, rgimpl, 3, rgreq, &pec);

Результирующий список классов будет содержать всех приматов (Simians), которые не требуют от среды клиента ничего, кроме кислорода (Oxygen), воды (Water) и молока (Milk). Класс Chimp, зарегистрированный ранее, мог бы быть совместимым классом, так как он реализует специфицированную категорию Simian и требует подмножество специфицированных категорий, использованных в запросе.

Заключительным, причем спорным, аспектом категорий компонентов является представление о классе по умолчанию для категории. СОМ допускает регистрацию CATID в качестве CLSID под ключом реестра HKEY_CLASSES_ROOT\CLSID

Для преобразования CATID в CLSID по умолчанию используется средство TreatAs , введенное эмуляцией. Для указания того, что класс Gorilla является классом по умолчанию для Simian, необходимо добавить следующий ключ реестра:

[HKCR\CLSID\{CATID_Simian}\TreatAs] @={CLSID_Gorilla}

Это простое соглашение позволяет клиентам просто использовать CATID там, где ожидаются CLSID:

// create an instance of the default Simian class

// создаем экземпляр класса Simian, принятого по умолчанию

hr = CoCreateInstance(CATID_Simian, 0, CLSCTX_ALL, IID_IApe, (void**)&pApe);

Если для указанной категории не зарегистрировано ни одного класса по умолчанию, то вызов активации даст сбой и вернет REGDB_E_CLASSNOTREG.

Где мы находимся?

В этой главе представлена концепция СОМ-класса. СОМ-классами называются конкретные типы данных, которые экспортируют один или более интерфейсов и являются основной абстракцией, используемой при активации объектов в СОМ. СОМ поддерживает три примитива активации. CoGetClassObject связывает ссылку с объектом класса, который представляет независимые от экземпляра функциональные возможности класса. CoCreateInstanceEx связывает ссылку с новым экземпляром класса, a CoGetInstanceFromFile связывает ссылку с постоянным экземпляром, находящимся в файле. Моникеры используются в качестве универсальной абстракции для передачи клиентам стратегии связывания и активации, причем MkParseDisplayName выполняет функции точки входа в пространство имен СОМ.

Глава 4. Объекты