Сообщений 5    Оценка 246        Оценить

Использование COM из DLL незаметно для клиента

Автор: Сергей Холодилов
The RSDN Group
Источник: RSDN Magazine #1-2003

Опубликовано: 06.12.2002
Исправлено: 10.12.2016
Версия текста: 1.1

Задача Проблемы Уточнение задачи Решение Код Серверы Клиент DLL Статистика P.S. Даже Microsoft делает это… Благодарности

Демонстрационный проект

Однажды, когда я писал DLL, передо мной встала элементарная, на первый взгляд, задача: создать и использовать COM объект. Но оказалось, что это не так-то просто. Основные проблемы заключались в том, что клиент моей DLL ничего не знал о COM, поэтому не собирался его инициализировать, зато имел кучу потоков, каждый из которых периодически вызывал функции DLL. Как мне кажется, после некоторых размышлений, экспериментов (и консультаций в форуме RSDN COM/DCOM/COM+) было найдено общее и достаточно красивое решение, которое и описано в этой статье.

Задача

Необходимо написать DLL, не предъявляющую к клиенту никаких требований, связанных с COM. Подобная необходимость возникает, если уже существует несколько различных клиентов, использующих DLL с подобным интерфейсом, а вам нужно подменить её. Или, если вы пишете plug-in к чему-либо.

По каким-то причинам при реализации очень хочется использовать COM. В моём случае причиной была возможность прозрачного (для клиента моей DLL) использования сервера в другом процессе (ну очень не хотелось использовать традиционные методы взаимодействия между процессами... пришлось выдумывать). В вашем случае это может быть, например, наличие COM-компонентов, реализующих нужную функциональность.

Проблемы

• Некоторые потоки клиента ничего не знают о COM. А DLL использовать хотят. И CoInitialize[Ex] перед обращением к DLL вызвать не догадаются...
• Некоторые потоки клиента что-то знают о COM. Они все принадлежат разным апартаментам, но, несмотря на это, будут поочерёдно (или одновременно) обращаться к DLL.

Уточнение задачи

Будем решать упрощённую версию моей задачи. Это простой, но показательный случай. Надеюсь, ваши задачи можно будет свести к чему-то подобному, или хотя бы использовать тот же подход.

Требуется создать DLL, экспортирующую следующие функции:

      void Init();
void Cleanup();

void SomeFunc(int I);

Кроме этого есть COM-компонент CoolServer, реализующий интерфейс ICoolServer, который содержит SomeFunc. Если бы COM был везде инициализирован, и не было бы проблем с апартаментами, нужно было бы реализовать DLL примерно так:

ICoolServer* pCS = NULL;

extern «С» __declspec(dllexport) void Init()
{
  pCS = CoCreateInstance(..);
}

extern «С» __declspec(dllexport) void Cleanup()
{
  pCS->Release()
  pCS = NULL;
}

extern «С» __declspec(dllexport) void SomeFunc(int i)
{
  pCS->SomeFunc(i);
}

То есть нужно использовать только один указатель на интерфейс, полученный при инициализации библиотеки и освобождаемый при очистке. Если можно создавать объект в SomeFunc и там же его уничтожать, то функции Init и Cleanup можно убрать, проблемы с апартаментами тоже исчезнут. Случай, когда экземпляр COM-объекта нужно сохранять между вызовами, более интересен.

Итак, нужно чтобы:

• При инициализации библиотеки создавался объект. Этот объект должен жить независимо от того, сколько раз и в каких потоках клиент вызывает CoUninitialize.
• При очистке ссылка на этот объект освобождалась.
• При вызове SomeFunc вызывался метод SomeFunc глобального объекта. Других побочных эффектов функция иметь не должна. Метод должен вызываться независимо от того, какому апартаменту принадлежит вызывающий поток, и инициализирован ли в нём COM вообще. Отсутствие побочных эффектов означает, что если до вызова COM не был инициализирован, то и после вызова COM не должен быть инициализирован.

Решение

Для выполнения первых двух требований я предлагаю создать дополнительный поток, инициализировать в нём COM и создать объект. После этого поток будет ждать очистки, во время которой освободит указатель на интерфейс, деинициализирует COM и завершится.

В псевдокоде это выглядит так:

      void Init()
{
    // запускает поток InitCleanupThread// ждёт завершения инициализации
}

void Cleanup()
{
    // сообщает, что можно чистить// ждёт завершения очистки
}

DWORD CALLBACK InitCleanupThread(LPVOID)
{
    // инициализирует COM// создаёт объект// каким-то образом делает полученный указатель// на интерфейс доступным из других апартментов// сообщает о завершении инициализации// ждет разрешения всё почистить// освобождает ссылку на объект// деинициализирует COM
}

Для выполнения третьего требования можно поступить так:

1. Попытаться инициализировать COM.

если CoInitialize[Ex] вернула ошибку RPC_E_CHANGED_MODE, то COM уже был инициализирован, просто немного не так.

если CoInitialize[Ex] вернула S_OK, то COM успешно инициализировался.

если CoInitialize[Ex] вернула S_FALSE, то COM уже был инициализирован, причём с теми же параметрами.

если CoInitialize[Ex] вернула что-то другое, произошло что-то ужасное.

2. Получить допустимый для использования в данном апартаменте указатель на нужный интерфейс. Метод получения указателя может зависеть от результата вызова CoInitialize[Ex].

3. Вызвать метод SomeFunc.

4. Если CoInitialize[Ex] вернула S_OK или S_FALSE, деинициализировать COM.

Или так:

1. Попытаться получить допустимый для использования в данном апартменте указатель на нужный интерфейс.

• если в результате получена ошибка CO_E_NOTINITIALIZED, перейти к пункту 2;
• если всё в порядке к пункту 4;
• если что-то другое, произошло что-то ужасное.

2. Инициализировать COM.

3. Получить допустимый для использования в данном апартаменте указатель на нужный интерфейс.

4. Вызвать метод SomeFunc.

5. Если выполнялся пункт 2, деинициализировать COM.

Получить «допустимый для использования в данном апартаменте указатель на нужный интерфейс» можно тремя путями:

• Global Interface Table (GIT)
• CoMarshalInterface/CoUnmarshalInterface
• Простое копирование указателя

Последний метод применим только если поток, создавший объект (InitCleanupThread), и поток, желающий этот объект использовать, принадлежат одному апартаменту, то есть оба входят в MTA; первые два метода применимы в любом случае.

Код

В качестве примера я написал два сервера (один – exe, другой – DLL), две DLL (на каждый сервер по одной) и клиента с набором тестов.

Серверы

Оба сервера реализуют следующий интерфейс:

interface ICoolServer : IUnknown
{
	HRESULT SomeFunction();
	HRESULT WorkFunction([in] BSTR str);
};

SomeFunction просто возвращает S_OK, WorkFunction выводит переданную ей строку (сервер в DLL – через printf, сервер в exe – через MessageBox). Первая используется для сравнения быстродействия различных методов вызова, вторая для проверки их принципиальной работоспособности.

Как обычно, серверы нужно зарегистрировать. При этом они оба пытаются зарегистрировать свои библиотеки типов. Оба сервера предполагают, что библиотека называется «iface.tlb» и лежит в том же каталоге, что и исполняемый файл сервера.

Клиент

Клиент, в зависимости от значения в командной строке (цифра от 0 до 6, отсутствие аргументов эквивалентно «0»), выполняет один из тестов. Тест «0» проверяет функциональность, остальные позволяют оценить производительность. Их результаты приведены в разделе «Статистика».

DLL

Отличаются друг от друга только именами экспортируемых функций и GUID-ами создаваемых объектов. Теоретические построения из раздела "Решение" реализованы следующим образом:

• Поток InitCleanupThread входит в MTA.
• Поток InitCleanupThread сообщает Init о завершении инициализации с помощью события, которое принимает как параметр.
• Cleanup сообщает потоку InitCleanupThread о начале очистки с помощью глобального события.
• Cleanup не дожидается завершения очистки. Лень...
• InitCleanupThread регистрирует интерфейс в GIT.
• InitCleanupThread производит маршалинг интерфейса в глобальный IStream. CoMarshalInterface вызывается с флагом MSHLFLAGS_TABLESTRONG.
• При попытке инициализировать COM все потоки пытаются войти в MTA. Поэтому, если у них это получается, маршалинг не требуется.
• Dll экспортирует следующие функции («xx» – либо «In», либо «Out»): xx_Init, xx_Cleanup, xx_One, xx_Two, xx_Three, xx_Four, xx_One_Work, xx_Two_Work, xx_Three_Work, xx_Four_Work. «One», «Two», «Three», «Four» – это четыре метода получения указателя на объект. Work-функции вызывают WorkFunction, обычные функции – SomeFunction.

Реализованные методы:

ICoolServer* GetPointer_1(bool* init)
{
  // Пытаемся инициализировать COM
  HRESULT hr = CoInitializeEx(0, COINIT_MULTITHREADED);

  if (hr == RPC_E_CHANGED_MODE)
  {
    // Попытка не удалась, COM уже был инициализирован, но по-другому. // Нужен маршалинг
    LARGE_INTEGER li = {0};
    pStr->Seek(li, STREAM_SEEK_SET, NULL); // Стрим – в начало!

    ICoolServer* marsh;
    CoUnmarshalInterface(pStr, __uuidof(ICoolServer), (void**)&marsh); 

    *init = false;
    return marsh;
  }
  elseif (FAILED(hr))
  {
    // Попытка не удалась, причины не известны
    *init = false;
    return NULL;
  }

  // Либо нам удалось инициализировать COM, // либо он уже был инициализирован точно так же.// В любом случае мы в MTA, можно смело использовать глобальный указатель.
  *init = true;
  pCS->AddRef();
  return pCS;
}

ICoolServer* GetPointer_2(bool* init)
{
  LARGE_INTEGER li = {0};
  pStr->Seek(li, STREAM_SEEK_SET, NULL); // Стрим – в начало!

  ICoolServer* marsh;
  // Попытка маршалинга глобального указателя
  HRESULT hr = CoUnmarshalInterface(pStr, __uuidof(ICoolServer), (void**)&marsh);

  if (hr == CO_E_NOTINITIALIZED)
  {
    // Практика показывает, что сюда мы никогда не попадём. :(// Не удалось, так как не инициализирован COM. Ну так инициализируем его.
    CoInitializeEx(0, COINIT_MULTITHREADED);
    
    // Мы в MTA, используем глобальный указатель
    *init = true;
    pCS->AddRef();
    return pCS;
  }
  elseif (FAILED(hr))
  {
    // Непонятная ошибка
    *init = false;
    return NULL;
  }

  // Получилось!
  *init = false;
  return marsh;
}

ICoolServer* GetPointer_3(bool* init)
{
  // Пытаемся инициализировать COM
  HRESULT hr = CoInitializeEx(0, COINIT_MULTITHREADED);

  if (hr == RPC_E_CHANGED_MODE)
  {
    // Попытка не удалась, COM уже был инициализирован, но по-другому. // Нужен маршалинг.
    ICoolServer* marsh;
    pGIT->GetInterfaceFromGlobal(magic, __uuidof(ICoolServer), (void**)&marsh); 

    *init = false;
    return marsh;
  }
  elseif (FAILED(hr))
  {
    // Попытка не удалась, причины не известны
    *init = false;
    return NULL;
  }

  // Либо нам удалось инициализировать COM, // либо он уже был инициализирован точно так же.// В любом случае мы в MTA, можно смело использовать глобальный указатель
  *init = true;
  pCS->AddRef();
  return pCS;
}

ICoolServer* GetPointer_4(bool* init)
{
  ICoolServer* marsh;
  // Попытка маршалинга глобального указателя.
  HRESULT hr = pGIT->GetInterfaceFromGlobal(magic, __uuidof(ICoolServer),
 (void**)&marsh);

  if (hr == CO_E_NOTINITIALIZED)
  {
    // Практика показывает, что и сюда мы никогда не попадём. :(// Не удалось, так как не инициализирован COM. Ну так инициализируем его.
    CoInitializeEx(0, COINIT_MULTITHREADED);
    
    // Мы в MTA, используем глобальный указатель
    *init = true;
    pCS->AddRef();
    return pCS;
  }
  elseif (FAILED(hr))
  {
    // Непонятная ошибка. А вот сюда попасть можем.
    *init = false;
    return NULL;
  }

  // Получилось!
  *init = false;
  return marsh;
}

Статистика

Скорее всего, после того, как вы прочитали, что за каждый вызов придётся платить инициализацией/деинициализацией COM или чем-то подобным, вы задумались над вопросом: сколько это стоит? Меня это тоже интересовало, я поставил несколько экспериментов.

Всё эксперименты проводились следующим образом:

• Операционная система – Windows 2000 Professional SP2
• Класс приоритета процесса – HIGH_PRIORITY_CLASS. Что бы посторонние меньше мешали.
• Время измерялось с помощью функции GetTickCount. Применять GetThreadTimes в данном случае нельзя, так как в одном вызове задействовано несколько потоков и «время вызова» – это суммарное время их работы. Даже если из десяти минут, которые требуются на вызов, основной поток (тот, который вызывает функцию из DLL) работает только одну секунду, а всё остальное время молча ждёт, пользователю от этого не легче. За десять минут он успеет десять раз запустить Task Manager и прибить вашу программу.
• Эксперименты заключаются в многократном вызове xx_One, потом столько же раз вызывается xx_Two, потом – xx_Three и, наконец, xx_Four. Отличаются друг от друга количеством вызовов, используемым сервером и «окружающей средой» (инициализирован ли COM, как именно инициализирован, какова поточная модель компонента).
• Количество повторов подбиралось так, что бы иметь хотя бы три значащие цифры.
• xx_Two и xx_Four работают так, как описано в предупреждении, то есть не совсем корректно.
• Для сравнения приведены результаты замеров вызовов объекта напрямую из клиента.

Собственно, результаты:

Выводы делайте сами.

P.S. Даже Microsoft делает это…

Вы никогда не задумывались над вопросом, как реализована функция ShellExecute[Ex]? С одной стороны, она не требует предварительной инициализации COM, а с другой, явно его использует… Я вот не задумывался. А оказывается, в ней применяется похожий подход.

Если в Windows 2000 Professional SP2 залезть WinDbg-ом в ShellExecuteExW, можно увидеть примерно следующее (99% «деталей» я опустил для большей ясности):

SHELL32!ShellExecuteExW:

Регистры – в стек.

7831bc75 e8e739feff       call    SHELL32!SHCoInitialize (782ff661)

Проверка корректности переданного указателя (кстати, даже если выясняется, что указатель некорректен, функция пытается записать в поле hInstApp код ошибки).

Анализ поля fMask, различные пороверки в зависимости от его значения. Заканчивается одним из следующих вариантов:
  call SHELL32!ShellExecuteNormal (7831bd28)
  call SHELL32!_ShellExecPidl (78343366)
  call dwordptr [SHELL32!_imp__SetLastError (782f18dc)]
 
Обработка возможных ошибок.

7831bcea e8d039feff       call    SHELL32!CoUninitialize (782ff6bf)

Регистры - из стека.

А функция SHCoInitialize выглядит так:

SHELL32!SHCoInitialize:
782ff661 56           push esi
782ff662 8b35acf62f78 mov  esi,[SHELL32!_imp__CoInitializeEx (782ff6ac)]
782ff668 6a06         push 0x6    COINIT_APARTMENTTHREADED +
                                  COINIT_DISABLE_OLE1DDE
782ff66a 6a00         push 0x0 
782ff66c ffd6         call esi    Вызов CoInitializeEx
782ff66e 85c0         test eax,eax
Если функция вернула значение меньше 0, т.е. ошибку
782ff670 0f8c24211000 jl   SHELL32!SHCoInitialize+0x11 (7840179a)   -----    
782ff676 5e           pop  esi                             <------------|----
782ff677 c3           ret                                               |   |
                                                                        |   |
Разный код…                                                             |   |
                                                                        |   |
7840179a 6a04         push 0x4    COINIT_MULTITHREADED +       <---------   |
                                  COINIT_DISABLE_OLE1DDE                    |
7840179c 6a00         push 0x0                                              |
7840179e ffd6         call esi    Вызов CoInitializeEx с новыми параметрами |
784017a0 e9d1deefff   jmp  SHELL32!SHCoInitialize+0x17 (782ff676)    --------

То есть, если ей не удалось инициализировать COM с параметром COINIT_APARTMENTTHREADED, она пытается инициализировать его с COINIT_MULTITHREADED. Если не произойдёт ничего неожиданного, то после выполнения этой функции можно:

• быть уверенным, что COM инициализирован
• смело вызывать CoUninitialize, так как клиенту это не повредит

ShellExecuteExW так и поступает.

Благодарности

Во время написания кода, послужившего основой и для этого текста и для привёдённого примера, мне очень помог Vi2 (Виктор Шарахов). Большое ему спасибо. Второе спасибо – Павлу Блудову, обратившему моё внимание на функцию ShellExecute[Ex].

Сообщений 5    Оценка 246        Оценить