Dll При использовании динамической компоновки загрузочный код нескольких (или нескольких десятков) функций объединяется в отдельные файлы, загружаемые в оперативную память в единственном экземпляре. Программы, работающие параллельно, вызывают функции, загруженные в память из файлов библиотек динамической компоновки, а не из файлов программ. Таким образом, используя механизм динамической компоновки, в загрузочном файле программы можно расположить только те функции, которые являются специфическими для данной программы. Те же функции, которые нужны всем (или многим) программам, работающим параллельно, можно вынести в отдельные файлы - библиотеки динамической компоновки, и хранить в памяти в единственном экземпляре. Эти файлы можно загружать в память только при необходимости, например, когда какая-нибудь программа захочет вызвать функцию, код которой расположен в библиотеке. Механизм динамической компоновки используется не только в системе Windows.
Более того, он был изобретен задолго до появления Windows. Например, в мультизадачных многопользовательских операционных системах VS1, VS2, MVS, VM, созданных для компьютеров IBM-370 и аналогичных (вспомните добрым словом ушедшую в прошлое серию ЕС ЭВМ и операционные системы SVS, TKS, СВМ, МВС), код функций, нужных параллельно работающим программам, располагается в отдельных библиотеках и может загружаться при необходимости в специально выделенную общую область памяти. Операционная система OS/2 также работает с DLL-библиотеками. DLL-библиотеки используются для экономии памяти, так как все запущенные приложения могут использовать один модуль DLL-библиотеки, не включая стандартные функции в состав своих модулей. С помощью DLL-библиотек можно организовать коллективное использование ресурсов или данных, расположенных в сегменте данных библиотеки. Более того, вы можете создать DLL-библиотеки, состоящие только из одних ресурсов, например, из пиктограмм или изображений bitmap. В состав Windows входит DLL-библиотека moricons.dll, состоящая из одних пиктограмм. Файлы с расширением fon представляют собой ни что иное, как DLL-библиотеки, содержащие шрифты в виде ресурса.
Функции, входящие в состав DLL-библиотеки, могут заказывать блоки памяти с атрибутом GMEM_SHARE. Такой блок памяти не принадлежит ни одному приложению и поэтому не освобождается автоматически при завершении работы приложения. Так как в Windows версии 3.1 все приложения используют общую глобальную память, блоки памяти с атрибутом GMEM_SHARE можно использовать для обмена данными между приложениями. Управлять таким обменом могут, например, функции, расположенные в соответствующей DLL-библиотеке. Использование DLL-библиотек повышает модульность приложений и самой операционной системы Windows.
С точки зрения приложения DLL-библиотека является не более чем набором функций с тем или иным интерфейсом, а также, возможно, набором ресурсов. Внутреннее "устройство" и алгоритмы работы функций, а также используемые функциями структуры данных полностью скрыты от приложения. Поэтому при внесении изменений или усовершенствований в DLL-библиотеки нет необходимости выполнять повторную сборку приложений (если не изменился интерфейс или набор функций, входящих в библиотеку). Область применения DLL-библиотек достаточно широка. Помимо предоставления приложениям функций организации пользовательского интерфейса и реализации различных расширений Windows типа мультимедиа или систем управления базами данных, DLL-библиотеки необходимы для обеспечения ряда системных операций. Например, приложение может организовать "перехват" системных сообщений или функций, при этом соответствующие модули "перехватчика" необходимо располагать в фиксированном сегменте кода DLL-библиотеки. Для удаляемых (discardable) блоков памяти можно, вызвав функцию GlobalNotify, определить функцию, которой будет передаваться управление при попытке удалить блок из памяти. Такая функция должна находиться в фиксированном сегменте кода в DLL-библиотеке. Если ваше приложение обрабатывает аппаратные прерывания или само вызывает программные прерывания, ему также не обойтись без DLL-библиотек (единственный способ обработки прерываний в реальном времени - создание виртуального драйвера).
Наконец, все обычные драйвера устройств в операционной системе Windows реализованы с помощью DLL-библиотек. Даже если вы не собираетесь обрабатывать или вызывать прерывания и не разрабатываете собственный драйвер, отдельные подсистемы большого приложения имеет смысл оформлять в виде DLL-библиотек из соображений модульности и доступности библиотек для других приложений.
Ole Com Activex Технологии OLE и ActiveX являются высокоуровневыми программными сервисами, построенными фирмой Microsoft на основе технологии СОМ. Доступ к средствам СОМ, OLE и ActiveX обеспечивается операционной системой Windows посредством набора СОМ-интерфейсов и небольшого числа функций WIN32 API. Как и в случае с СОМ, в отличных от Windows операционных системах также поддерживаются сервисы подобные OLE ActiveX.COM является платформно-независимой, объектно-ориентированной технологией, позволяющей создавать бинарные компоненты. Эти компоненты можно использовать как локально, так и в распределенном сетевом окружении. COM служит основой для: OLE (технология составных документов), ActiveX-объектов и элементов управления ActiveX, DCOM, COM+. Одной из наиболее важных черт СОМ является ее способность предоставлять двоичный стандарт для программных компонентов. Этот двоичный стандарт обеспечивает средства, с помощью которых объекты и компоненты, разработанные на разных языках программирования разными поставщиками и работающие в различных операционных системах, могут взаимодействовать без каких-либо изменений в двоичном (исполняемом) коде. Это является основным достижением создателей СОМ и отвечает насущным потребностям сообщества разработчиков программ. Другое важное свойство СОМ известно под названием независимости от местоположения (Location Transparency). Независимость от местоположения означает, что пользователь компонента, клиент, не обязательно должен знать, где находится определенный компонент. Клиентское приложение использует одинаковые сервисы СОМ для создания экземпляра и использования компонента независимо от его фактического расположения. Компонент может находиться непосредственно в адресном пространстве задачи клиента (DLL-файл), в пространстве другой задачи на том же компьютере (ЕХЕ-файл) или на компьютере, расположенном за сотни миль (распределенный объект). Технологии СОМ и DCOM (Distributed СОМ - распределенная СОМ) обеспечивают независимость от местоположения. Другими средствами, реализующими эту способность, являются сервисы распределенных объектов. Аналогичные возможности обеспечивает стандарт CORBA. Поскольку клиентское приложение взаимодействует с СОМ - компонентами, вне зависимости от их положения, одинаковым образом, интерфейс клиента тоже не меняется. Независимость от местоположения позволяет разработчику создавать масштабируемые приложения.
Понятия OLE и ActiveX. Многие новые возможности OLE не имеют ничего общего со связыванием и внедрением. Хорошим примером этого является OLE-автоматизация (или просто автоматизация), вообще не имеющая отношения к составным документам. Основной задачей OLE-автоматизации является обеспечение взаимодействия компонентов и приложений независимо от языков программирования и средств разработки. В апреле 1996 года Microsoft приняла в сферу своих интересов среду WWW и ввела в обращение термин ActiveX, призванный отобразить новое направление в стратегии выпуска программных продуктов фирмы. Однако большинство новых технологий ActiveX уже существовали до апреля 1996 года под другим названием: OLE. В общем, термин ActiveX заменил термин OLE, цель этой замены - подчеркнуть превосходство СОМ-технологий фирмы Microsoft. Теперь термин OLE снова может быть использован для описания тех технологий, которые относятся к составным документам, а также связыванию и внедрению объектов.
Службы и драйвера Системная служба Windows NT (по-английски - system service; в дальнейшем - просто служба) - это фоновый процесс, который может запускаться и работать без участия интерактивного пользователя. В этом смысле системные службы похожи на демоны Unix и резидентные программы MS-DOS. Как правило, системные службы стартуют при загрузке системы и продолжают работать, пока система не будет остановлена, хотя возможны запуск и остановка служб уже в процессе работы. Архитектура системных служб Windows NT подразумевает три вида компонентов . Ee ядром является менеджер системных служб (Service Control Manager или SCM). SCM запускается при загрузке системы и работает, пока компьютер не будет выключен. Менеджер системных служб взаимодействует с одной стороны с управляющими программами, а с другой - с системными службами. Основными задачами менеджера являются:
Запуск при загрузке системы тех служб, которые должны быть запущены автоматически. –
Хранение конфигурационной базы данных, содержащей информацию обо всех службах.
Прием запросов от управляющих программ и передача их системным службам.
Windows NT определяет два вида системных служб. Один из них - это так называемые службы режима ядра (kernel-mode services), которые есть ни что иное, как драйверы устройств. Другой вид - службы Win32 - это обычные Win32-процессы, использующие специальный набор функций для взаимодействия с менеджером системных служб. Управляющие программы - это обычные Win32-приложения, которые манипулируют службами с использованием программного интерфейса, предоставляемого менеджером системных служб. Типичный пример управляющей программы - это MMC snap-in "Службы" в Windows 2000.
