лишь создать сборочный файл (makefile), который скомпилирует три исходных С- файла (sports_i.с, sports_p.c, dlldata.c) и скомпонует их имеете для создания библиотеки DLL. Четыре стандартные точки входа СОМ должны быть явно экспортированы с помощью либо файла определения модуля, либо переключателей компоновщика. Отметим, что по умолчанию dlldata.c содержит только определения DllGetClassObject и DllCanUnloadNow . Это происходит потому, что поддерживающая RPC динамическая библиотека под Windows NT 3.50 поддерживала только эти две подпрограммы. Если интерфейсный маршалер будет использоваться только под Windows NT 3.51 или под более поздние версии (а также под Windows 95), то символ С-препроцсссора REGISTER_PROXY_DLL должен быть определен при компиляции файла dlldata.c , чтобы стандартные входные точки саморегистрации также были скомпилированы. Интерфейсный маршалер после создания должен быть установлен в локальном реестре и/или в хранилище классов.
В реализацию библиотеки СОМ под Windows NT 4.0 введена поддержка полностью интерпретируемого (interpretive) маршалинга. В зависимости от интерфейса использование интерпретируемого маршалера может значительно увеличить эффективность приложения путем сокращения объема рабочей памяти (working set). Предварительно установленные интерфейсные маршалеры для всех стандартных интерфейсов СОМ используют интерпретируемый маршалер. Microsoft Transaction Server (MTS) обязывает интерфейсные маршалеры использовать интерпретируемый маршалер[1] . Чтобы задействовать интерпретируемый маршалер, просто запустите компилятор MIDL с переключателем /Oicf в командной строке:
midl.exe /0icf sports.idl
В то время, когда пишется этот текст, компилятор MIDL не перезаписывает существующий файл _p.c, так что при изменении данной установки этот файл должен быть удален. Поскольку интерфейсные маршалеры, основанные на /Oicf, не будут работать на версиях СОМ до Windows NT 4.0, то при компиляции исходного кода маршалера символу С-препроцессора _WIN32_WINNT нужно присвоить целое значение, большее или равное 0х400. С- компилятор сделает это во время компиляции.
Третья методика для генерирования интерфейсных маршалеров поддерживается ограниченным числом интерфейсных классов. Если интерфейс использует только простые типы данных, которые поддерживаются VARIANT[2], то можно использовать универсальный маршалер. Использование универсального маршалера разрешается путем добавления атрибута [oleautomation] к определению интерфейса:
[ uuid(F99D19A3-D8BA-11d0-8C4F-0080C73925BA), version(1.0)]
library SportsLib {
importlib(«stdole32.tlb»);
[
uuid(F99D1907-D8BA-11D0-8C4F-0080C73925BA), object,
oleautomation
]
interface IWrestler : IUnknown {
import «oaidl.idl»;
HRESULT HalfNelson([in] double nmsec);
} }
Наличие атрибута [oleautomation] информирует функцию RegisterTypeLib , что при регистрации библиотеки типов ей следует добавить следующие дополнительные элементы реестра:
[HKCRInterface{F99D1907-D8BA-11d0-8C4F-0080C73925BA}]
@='IWrestler'
[HKCRInterface{F99D1907-D8BA-11d0-8C4F-0080C73925BA}ProxyStubClsid32]
@='{O0020424-0000-0000-C000-000000000046}'
[HKCRInterface{F99D1907-D8BA-11d0-8C4F-0080C73925BA}ProxyStubClsid]
@='{O0020424-0000-0000-C000-000000000046}'
[HKCRInterface{F99D1907-D8BA-11d0-8C4F-0080C73925BA}TypeLib]
@='{F99D19AЗ-08BA-11d0-8C4F-0080C73925BA}'
Version='1.0'
CLSID {O0020424-0000-0000-C000-000000000046} соответствует универсальному маршалеру, который предварительно устанавливается на всех платформах, поддерживающих СОМ, в том числе в 16-разрядных Windows.
Основное преимущество использования универсального маршалера заключается в том, что это – единственная поддерживаемая методика осуществления стандартного маршалинга между 16– и 32- разрядными приложениями. Кроме того, универсальный маршалер совместим с Microsoft Transaction Server. Другое преимущество универсального марщалера заключается в следующем: если библиотека типов установлена на хост-машинах и клиента, и объекта, то не потребуется никакой дополнительной DLL интерфейсного марщалера. Основной же недостаток использования универсального маршалера – ограниченная поддержка типов данных параметров. Это то же самое ограничение, которое устанавливают динамический вызов и среды выполнения сценариев, но является серьезным ограничением при разработке интерфейсов системного программирования низкого уровня[3]. Под Windows NT 4.0 начальные затраты на вызов CoMarshalInterface / CoUnmarshalInterface несколько повысятся при использовании универсального маршалера. Однако после обработки интерфейсных заместителя и заглушки затраты на вызов метода становятся эквивалентными затратам на /0icf -маршалер.
Стандартный маршалинг, потоки и протоколы
Подробности того. как СОМ на самом деле преобразует запросы ORPC в потоки, нигде не документированы и подлежат изменениям но мере развития реализации библиотеки СОМ. Описания, содержащиеся в данном разделе, относятся только ко времени написания этого текста, но, конечно, некоторые детали реализации могут измениться в последующих выпусках СОМ.
Когда в процессе инициализируется первый апартамент, СОМ включает RPC-слой времени выполнения, переводя процесс в RPC-сервер. Если апартамент имеет тип МТА или RTA, то используется RPC-протокол ncalrpc , который является оберткой вокруг портов LPC (local procedure call – локальный вызов процедуры) под Windows NT. Если тип апартамента – STA, то используется последовательность закрытого протокола, основанная на очередях сообщений MSG Windows. При первом обращении внехостовых клиентов к объектам, постоянно находящимся в процессе, в процессе регистрируются дополнительные сетевые протоколы. Когда процесс впервые начинает использовать протоколы, отличные от протокола MSG Windows , запускается кэш потоков RPC. Этот кэш потоков начинается с одного потока, который ожидает приходящих запросов на установление соединения, запросов RPC или других действий, специфических для протоколов. Как только произойдет любое из этих событий, кэш потоков RPC переключит поток на обслуживание запроса и будет ждать следующих действий.
