2) Поддержка com в Windows nt (реестр Widows, dcom, реализация сервера в процессе, реализация сервера за пределами процесса).
COM (англ. Component Object Model — объектная модель компонентов— это технологический стандарт от компании Microsoft, предназначенный для создания программного обеспечения на основе взаимодействующих компонентов, каждый из которых может использоваться во многих программах одновременно. Стандарт COM закрепился в основном на операционных системах семейства Microsoft Windows
Принципы работы COM. Основным понятием, которым оперирует стандарт COM, является COM-компонент. Программы, построенные на стандарте COM, фактически не являются автономными программами, а представляют собой набор взаимодействующих между собой COM-компонентов. Каждый компонент имеет уникальный идентификатор (GUID) и может одновременно использоваться многими программами. Компонент взаимодействует с другими программами через COM-интерфейсы — наборы абстрактных функций и свойств. Каждый COM-компонент должен, как минимум, поддерживать стандартный интерфейс «IUnknown», который предоставляет базовые средства для работы с компонентом. Интерфейс «IUnknown» включает в себя три метода: QueryInterface, AddRef, Release.
Windows API предоставляет базовые функции, позволяющие использовать COM-компоненты. Библиотеки MFC и, особенно, ATL/WTL предоставляют гораздо более гибкие и удобные средства для работы с COM. Библиотека ATL от Microsoft до сих пор остаётся самым популярным средством создания COM-компонентов. Но зачастую COM-разработка остаётся ещё довольно сложным делом, программистам приходится вручную выполнять многие рутинные задачи, связанные с COM (особенно это заметно в случае разработки на C++). Впоследствии (в технологиях COM+ и особенно .NET) Microsoft попыталась упростить задачу разработки COM-компонентов.
При построении СОМ-сервера у разработчика есть альтернативы. Интерфейсы, производные от IUnknown, обладают высоким быстродействием и интуитивно понятны C++ программисту. Интерфейсы, производные от IDispatch, поддерживают OLE автоматизацию (технологию, позволяющую встраивать программные пакеты в другие приложения) и работу с языками сценариев, такими как Visual Basic Script, Java Script и т.д. Вызов метода посредством интерфейса IDispatch осуществляется через таблицу имен. По имени метода функция IDispatch::GetIDsOfNames0 воз вращает из таблицы имен идентификатор метода (DISPID). По этому идентификатору функция IDispatch::Invoike() вызывает сам метод. Набор функций, реализованных с помощью IDispatch::Invoike(), называют диспетчерским интерфейсом. IDispatch работают существенно медленнее в сравнении с интерфейсами, производными OTlUnknown.
Дуальные интерфейсы представляют собой комбинации IUnknown иIDispatch, обладающие всеми их свойствами. Как правило, реализация этогоинтерфейса требует больших затрат времени на разработку.
Преимущества компонентного подхода обеспечили широкую сферу его применения.
Во-первых, это повторное использование компонентов. СОМ позволяет однажды создать программный код, а потом использовать его во многих приложениях. Через какое-то время в компонент можно вносить коррекции и усовершенствования, что не повлечет необходимости менять любое использующее его приложение.
Во-вторых, это параллельная разработка. Обычно начинают с разработки интерфейсов компонента, что определяет корректность совместной работы всего программного обеспечения. Последующую разработку функциональных возможностей компонентов можно распараллеливать.
В-третьих, это унификация прикладного программного обеспечения. Речь идет о производстве, в котором собраны несовместимые системы управления разного типа и от разных производителей. Пусть нужно создать приложение, осуществляющее измерение сигналов для диагностики следящих приводов. Создают обобщенный СОМ-интерфейс и разрабатывают СОМ-сервер для каждого контроллера управления приводами. Прикладное приложение обращается через обобщенный СОМ-интерфейс к любому СОМ-серверу контроллера, при этом протокол управления конкретным контроллером привода полностью прозрачен/ Существуют некоторые особенности использования СОМ. Например, необходимо тщательно планировать интерфейсы, потому что опубликованный интерфейс нельзя менять. Если нужно изменить или расширить функциональные возможности интерфейса, то выпускают его новую версию с новым GUID. В новой версии компонента необходимо поддерживать все старые интерфейсы для обеспечения совместимости
Дополнительно про com *при ответе лучше не говорить- последует куча вопросов про все использованные термины.
Путаница в названиях В 1996 году Microsoft попыталась переименовать технологию OLE в ActiveX, но это удалось лишь частично. Например, технология OLE позволяла создавать так называемые элементы управления OLE (англ. OLE Controls, или OCX) — повторно используемые элементы пользовательского интерфейса, которые были построены на стандарте COM. Эти элементы управления OLE были переименованы в элементы управления ActiveX (англ. ActiveX controls), хотя расширение файлов «.ocx» за ними осталось. Затем Microsoft стала активно продвигать ActiveX в Интернет, включив поддержку элементов ActiveX в свой популярный браузер Internet Explorer. В результате название OLE осталось только за технологией составных документов и локальных внедряемых объектов. А сетевые OLE-объекты стали называть по-новому — ActiveX. Некоторая путаница между понятиями OLE и ActiveX сохраняется и до сих пор, но речь идёт об одних и тех же COM-технологиях. Причём, иногда даже путают понятия OLE и COM. Так, внедряемые OLE-объекты иногда называют COM-объектами, а OLE-контейнеры COM-контейнерами, и т. п.
РЕЕСТР Windows - это иерархически построенная база данных параметров и настроек в большинстве операционных систем Microsoft Windows. Реестр содержит информацию и настройки для аппаратного обеспечения, программного обеспечения, профилей пользователей, предустановки. Большинство изменений в Панели управления, ассоциации файлов, системные политики, список установленного ПО фиксируются в реестре.
ИЗ КНИГИ: Чтобы запустить СОМ-сервер в конкретной системе, его следует зарегистрировать, например с помощью утилиты regsvr32.exe. При регистрации глобальный уникальный идентификатор и путь к серверу записываются в системный реестр Windows. Клиент не знает, где находится СОМ-сервер; он просто обращается к операционной системе для получения указателя на интерфейс IUnknown для сервера с идентификатором GUID
Реестр Windows был введён для упорядочения информации, хранившейся до этого во множестве INI-файлов.
Реестр Windows 3.1 Сам реестр, как древовидная иерархическая база данных (registration database — регистрационная база) впервые появился в Windows 3.1 (апрель 1992). Это был всего один двоичный файл, который назывался REG.DAT и хранился в каталоге C:\Windows\. Реестр Windows 3.1 имел только одну ветку HKEY_CLASSES_ROOT. Он служил для связи DDE, а позднее и OLE объектов.
Одновременно c появлением реестра в Windows 3.1 появилась программа REGEDIT.EXE для просмотра и редактирования реестра.
Первый реестр уже имел возможность импорта данных из *.REG файлов. В базовой поставке шёл файл SETUP.REG, содержащий данные по основным расширениям и типам файлов.
Реестр Windows 3.1 имел ограничение на максимальный размер файла REG.DAT — 64 Кбайт. Если вдруг реестр превышал этот размер — то файл реестра (REG.DAT) приходилось удалять и собирать заново либо из *.REG файлов, либо вводить данные вручную.
Реестр Windows NT 3.1 Следующий шаг сделан в Windows NT 3.1 (июль 1993). Произошёл отказ от устаревших файлов MS-DOS: AUTOEXEC.BAT и CONFIG.SYS, а также от INI-файлов, как от основных файлов конфигурации. На «регистрационную базу» (реестр) была переведена вся конфигурация системы. Основой конфигурации системы стал реестр. Он имел 4 корневых раздела: HKEY_ LOCAL_MACHINE, HKEY_CURRENT_USER, HKEY_CLASSES_ROOT и HKEY_USERS.
Реестр стал «сборным»: на диске он хранился в файлах: DEFAULT, SOFTWARE, SYSTEM, а при запуске системы из этих файлов собиралась единая БД.
В комплекте поставки оставался файл REGEDIT.EXE, который по-прежнему позволял просматривать и редактировать только ветку HKEY_CLASSES_ROOT, и появился файл REGEDT32.EXE, который позволял редактировать все ветки реестра.
Далее технология и идеология (назначение) реестра уже не менялись. Все последующие версии Windows (NT 3.5, 95, NT 4.0, 98, 2000, XP, Vista, 7) использовали реестр как основную БД, содержащую все основные данные по конфигурации как самой ОС, так и прикладных программ. Далее менялись названия файлов реестра и их расположение, а также название и назначение ключей.
Современный реестр Windows Реестр в том виде, как его использует Windows и как видит его пользователь в процессе использования программ работы с реестром, формируется из различных данных. Чтобы получилось то, что видит пользователь, редактируя реестр, происходит следующее.
Вначале, в процессе установки и настройки Windows, на диске формируются файлы, в которых хранится часть данных относительно конфигурации системы.
Затем, в процессе каждой загрузки системы, а также в процессе каждого входа и выхода каждого из пользователей, формируется некая виртуальная сущность, называемая «реестром» — объект REGISTRY\. Данные для формирования «реестра» частично берутся из тех самых файлов (Software, System …), частично из информации, собранной ntdetect при загрузке (HKLM\Hardware\Description).
То есть часть данных реестра хранится в файлах, а часть данных формируется в процессе загрузки Windows.
Для редактирования, просмотра и изучения реестра стандартными средствами Windows (программы regedit.exe и regedt32.exe) доступны именно ветки реестра. После редактирования реестра и/или внесения в него изменений эти изменения сразу записываются в файлы.
Однако, есть программы сторонних разработчиков, которые позволяют работать непосредственно с файлами.
Программы оптимизации реестра, твикеры, а также инсталляторы и деинсталляторы программ работают через специальные функции работы с реестром.
В Windows Vista файлы реестра хранятся там же, где и в Windows XP.
Описание разделов реестра HKEY_CURRENT_USER Данный раздел содержит настройки текущего активного пользователя, вошедшего в систему. Здесь хранятся папки пользователя, цвета экрана и параметры панели управления. Эти сведения сопоставлены с профилем пользователя. Вместо полного имени раздела иногда используется аббревиатура HKCU.[2] Хотя этот раздел выглядит как один из основных в редакторе реестра, он является всего лишь ссылкой на один из профилей HKEY_USERS\.
HKEY_USERS Раздел HKEY_CURRENT_USER является подразделом раздела HKEY_USERS. Вместо полного имени раздела иногда используется аббревиатура HKU.
HKEY_LOCAL_MACHINE Раздел содержит параметры конфигурации, относящиеся к данному компьютеру (для всех пользователей). Вместо полного имени раздела иногда используется аббревиатура HKLM.
HKEY_CLASSES_ROOT Является подразделом HKEY_LOCAL_MACHINE\Software\Classes. В основном, содержит информацию о зарегистрированных типах файлов и объектах COM и ActiveX.
HKEY_CURRENT_CONFIG Данный раздел содержит сведения о профиле оборудования, используемом локальным компьютером при запуске системы. Является ссылкой на HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Hardware Profiles\Current
HKEY_DYN_DATA Данный раздел имеется только в реестре ОС семейства Windows 9x/ME. Содержит динамически изменяемые данные о компьютере (загрузка процессора, размер файла подкачки и т. п.).
Критика Способ хранения параметров и настроек операционной системы при помощи реестра Windows часто подвергается критике по следующим причинам:
Реестр подвержен фрагментации, из-за чего доступ к реестру постепенно замедляется. В связи с тем, что помимо настроек в реестре хранится различная информация системы и приложений (например, многие приложения хранят в реестре список недавно открытых файлов), размер реестра значительно увеличивается по мере использования операционной системы. Эта проблема частично решается при помощи специальных утилит
Не все настройки системы хранятся в реестре, соответственно перенос настроек системы путём копирования реестра невозможен
Некоторые программы не могут работать без параметров, занесенных в реестр, что создаёт трудности при переносе их с компьютера на компьютер, или теряют данные после переустановки операционной системы.
Критики приводят в пример UNIX-подобные операционные системы, где нет реестра и выполняемые им задачи решаются другими средствами.
Программы для работы с реестром regedit.exe regedt32.exe Reg Organizer Test-Run by BB CCleaner Ashampoo WinOptimizer
Терминология. В описании реестра в английской литературе, среди прочих, используется термин Hive. В некоторых работах его переводят на русский как «улей». Microsoft в своих документах переводит это как куст.
Древо реестра — это подмножество разделов, подразделов и параметров реестра, которому сопоставлен набор вспомогательных файлов, содержащих резервные копии этих данных
DCOM. Выпущенная в 1996 году технология DCOM (англ. Distributed COM — распределённая COM) основана на технологии DCE/RPC (разновидности RPC). DCOM позволяет COM-компонентам взаимодействовать друг с другом по сети. Главным конкурентом DCOM является другая известная распределённая технология — CORBA. Как DCOM, так и CORBA решают задачу вызова метода объекта, расположенного на другой машине, а также передачу ссылки на объект с одной машины на другую.
Сетевой уровень DCOM называется ORPC (Object RPC) и является объектно-ориентированным расширением DCE RPC.
Технология DCOM обеспечивает базовые установки безопасности, позволяя задавать, кто и из каких машин (может создавать экземпляры объекта и вызывать его методы.
Одной из задач применения DCOM может быть распределение вычислений по сети. Действительно задачи могут быть довольно ресурсоемкие и выполняться много часов или десятков часов. Применяя DCOM у Вас есть возможность распределить вычисления по нескольким серверам или обычным рабочим станциям Windows 98 значительно сократив время на выполнение вычислений РИС:
Концентрация компонент. (Да, я не описался!!) Данная схема позволяет удобно организовать поддержку компонент. Действительно у нас есть возможность разместить компоненту на сервере и этой компонентой будут пользоваться большое количество клиентов. Если в ней ошибка то у нас есть возможность исправить ее, поместить новую версию на сервер и у всех она будет в дальнейшем с исправленной ошибкой. РИС:
Обеспечение стабильности сети Данная идея заключается в том, что сервер или рабочея станция на которой работают компоненты может выйти из строя. Ну и ладно, компонент в любой момент можно разместить на другой машине и воспользоваться dcomcnfg для перенаправления запроса.
Реализация удаленного администрирования на основе DCOM. Можно создать компонент который будет запускать указанные программы на удаленной машине.
Когда вы начинаете использовать распределенное приложение в реальной сети, выявляется несколько особенностей:
Компоненты, взаимодействующие чаще, должны быть “ближе” друг к другу.
Некоторые компоненты могут работать на определенных машинах или в определенных местах.
Использование меньших по размеру компонентов увеличивает гибкость в перераспределении, но при этом увеличивается сетевой трафик.
Компоненты большего размера уменьшают сетевой траффик, но зато уменьшается и гибкость в перераспределении.
С помощью DCOM эти критические моменты обходятся достаточно легко, поскольку в исходном коде не определены детали перераспределения. DCOM полностью скрывает местоположение компонента, будь он в том же процессе, что и клиент, или на другом конце света. В любом случае способы, которыми клиент соединяется с компонентом и вызывает методы компонента, идентичны. DCOM не нуждается не только в изменениях исходного кода, но даже и в рекомпиляции программы. Простая реконфигурация изменяет способ, которым компоненты соединяются друг с другом.
Как развитие СОМ, DCOM абсолютно не зависит от языка. Теоретически для создания СОМ-компонентов может использоваться любой язык
Масштабируемость Критическим фактором распределенных приложений является их способность модифицироваться в соответствии с числом пользователей, объемом данных и требуемой функциональностью. Приложение должно быть маленьким и быстрым при минимальной потребности в нем, но оно должно обеспечить и дополнительные потребности без ущерба быстродействию или надежности. DCOM предлагает ряд возможностей, улучшающих масштабируемость вашего приложения.
Симметричная многопроцессорная обработка (SMP)
DCOM использует возможность Windows NT поддерживать симметричную многопроцессорную обработку. Для приложений, использующих модель свободных потоков, DCOM организует объединение потоков входящих запросов. На многопроцессорных машинах это объединение потоков оптимизируется в соответствии с числом доступных процессоров: чрезмерно большие потоки приводят к слишком частому переключению между содержимым, в то время как слишком маленькие потоки могут привести к простою некоторых процессоров. DCOM ограждает разработчика от деталей управления потоками и обеспечивает оптимальное быстродействие, что может обеспечить лишь кодирование управления объединением потоков вручную, требующее больших затрат.
Используя поддержку симметричной многопроцессорной обработки Windows NT, DCOM-приложения могут безболезненно масштабироваться от уровня однопроцессорных машин до уровня огромных многопроцессорных систем.
Многие протоколы нуждаются в постоянном управлении. Компонентам нужно знать, что на машине клиента возникла серьезная авария аппаратного обеспечения или сетевое соединение между клиентом и компонентом прервалось на длительное время.
Общим решением этой проблемы является постоянная пересылка сообщений с определенной периодичностью (pinging). Если сервер не получает сообщения в течение определенного времени, это значит, что связи с клиентом нет.
DCOM использует такие сообщения для каждой из машин.
Дополнительно: *Мне диктовать!!!!!!!!!!!!! Дима О4
Критика Технология часто критикуется за неоправданную сложность, конкретно:
необходимость использования двух языков программирования (.idl для описания интерфейсов и обычно C++ для написания реализаций). Необходимость возникает только при создании собственных интерфейсов, и не возникает в случае, если разработчик ограничил себя использованием готовых интерфейсов.
необходимость "прокладочного" кода (в его роли обычно выступает ATL) для того, чтобы создать COM-объект на базе Си++ класса. Хотя этот код и тривиален в использовании для опытного человека, он не очень прост для начинающих. Как и в предыдущем пункте, эта проблема возникает только при написании собственных классов и не возникает при одном лишь использовании стандартных чужих классов (для которых MS разработал библиотеку смарт-пойнтеров - comdef.h, _com_ptr_t<Interface>, эта библиотека делает использование COM-объектов тривиальным).
необходимость регистрации компонент в реестре операционной системы, причем при этом в качестве идентификатора класса используется нечитаемый человеком GUID (хотя его и возможно дополнить читаемым именем).
инфраструктура remoting (удаленного вызова методов) использует бинарный формат запросов и ответов, являясь расширением DCE RPC. Это приводит к возникновению огромной "поверхности уязвимости" с точки зрения безопасности, и не раз приводило к крупным эпидемиям вредоносного ПО (MSBlaster).
инфраструктура remoting использует по умолчанию (вслед за DCE RPC) динамически назначаемые номера TCP и UDP портов, что делает ее крайне сложной в настройке при наличии межсетевых экранов.
обработка ошибок. В COM принято использовать 32битные коды ошибки HRESULT, которые имеют значения вроде 0x80070123, и совершенно не читаемы человеком (хотя последнее время все они тривиально ищутся поисковыми машинами Интернета).
Кроме того, runtime type information в COM, известная под названием type libraries, поддерживается только для т.н. Automation-compatible интерфейсов, имеющих огромные ограничения на типы параметров (массивы - только SAFEARRAY, строки - только BSTR, никаких произвольных структур, только числа, дата/время, массивы, строки и ссылки на другие Automation-compatible объекты).
Заметно, однако, что многие из этих недостатков являются платой за огромное достоинство COM - независимость от языка программирования и исполняющей среды, и не существуют в "истинно объектных" языках, таких, как C# или же (прекращенная) реализация Java компании Microsoft. Эти языки предоставляют и полную runtime type information, и отсутствие необходимости регистрации, и возможность написания как интерфейсов, так и классов стандартным для языка образом, без "прокладок" вроде ATL. Так, в MS J++ любой класс Java тривиально публиковался внешнему миру как класс COM, достаточно было лишь регистрации. То же существует и в C#.
С противоположной стороны, "истинно объектные" языки либо вообще не способны стыковаться с компонентами из других объектных языков и требуют написания всей системы (и нижележащих подсистем и фреймворков) "сверху донизу" на одном языке в одной исполняющей среде (Java, Objective C), либо же налагают такое же требование хотя и не на язык, но на исполняющую среду (.NET, языки C#, Си++ managed и VB.NET).
Многие недостатки COM на деле есть недостатки Си++, который ради сохранения совместимости с Си и облегчения среды времени исполнения не реализован как "истинно объектный" язык (примитивнейшая RTTI, которая как правило выключена из-за общей убогости и невозможности практического использования, нет поддержки QueryInterface на уровне языка), и тем не менее предлагался как основной язык для COM (за неимением лучшего).
Более новые аналогичные технологии (например, в мире .NET) пытаются решить эти проблемы. Там обычно используются полноценные объектные языки, а стек remoting полиморфен и кастомизируем, что дает возможность самостоятельно выбирать формат вопросов/ответов и транспортный протокол (по умолчанию используется уже не DCE RPC, а SOAP, в качестве формата данных - XML, а в качестве транспорта - HTTP, который не полагается на динамические номера портов).
Использование механизма позднего связывания может существенно снизить производительность по сравнению, например, с вызовом экспортируемой функции из динамической библиотеки. Однако этот механизм применяется только в скриптовых языках, и только в том случае, если язык не поддерживает объявление ссылок на объекты как ссылок на COM-интерфейсы из type libraries (в виде Dim obj As Excel.Workbook), а поддерживает только абстрактные COM-объекты (в виде Dim obj As Object). Кроме того, ровно такой же подход применяется в Objective C и Cocoa, где не жалуются на производительность.
реализация сервера в процессе, реализация сервера за пределами процесса
По способам реализации СОМ-серверы подразделяются на следующие типы.
-Внутрипроцессный (in-process), загружаемый в ту же область памяти процесса, что и обслуживаемый клиент. Высокая скорость является основным достоинством внутрипроцессной связи. Клиенты получают доступ к функциональным возможностям внутрипроцессного сервера со скоростью вызова локальных функций, поскольку клиент и объект общаются
напрямую через указатели интерфейса. Недостаток внутрипроцессного сервера состоите его низкой устойчивости к ошибкам.
-Внепроцессный (out-of-process, local), когда клиент и сервер находятся на одном компьютере, но загружены в разные области его памяти (т.е. выполняются в разных процессах). Достоинство такой связи в высокой устойчивости к ошибкам. При ошибке в сервере, приводящей к завершению серверного процесса, клиент продолжит работу. Недостатком локального сервера можно посчитать низкую скорость: информация от одного процесса к другому должна быть запакована, передана и распакованана границе процессов. СОМ берет этот сервис на себя.
-Удаленный сервер расположен на другом компьютере по отношению к клиенту. Эта клиент-серверная связь наиболее медленная, поскольку здесь оказывают влияние пропускная способность и задержки в сети. Удаленная связь устанавливается с помощью протокола удаленного вызова процедур в распределенной модели COM (DCOM).
Объект СОМ может создавать и использовать другие СОМ-объекты, при этом клиенту не известно, является ли СОМ-сервер составным или монолитным. Использование одного компонента другим возможно посредством включения или агрегации. Включение (containment) предполагает, что внешний компонент предоставляет интерфейс включаемому компоненту и обращается к нему для организации интерфейса. Агрегация (aggregation) означает, что внешний компонент агрегирует интерфейс внутреннего компонента, не создавая интерфейс заново и не передавая вызов этого интерфейса явно, как при включении. Вместо этого внешний компонент передает клиенту указатель на интерфейс внутреннего компонента.