Классификация API функций. Динамические библиотеки.

Windows API (application programming interfaces) — общее наименование целого набора базовых функций интерфейсов программирования приложений операционных систем семейств Windows и Windows NT корпорации «Майкрософт». Является самым прямым способом взаимодействия приложений с Windows. Для создания программ, использующих Windows API, «Майкрософт» выпускает SDK, который называется Platform SDK и содержит документацию, набор библиотек, утилит и других инструментальных средств.

Windows API был изначально спроектирован для использования в программах, написанных на языке C (или C++). Работа через Windows API — это наиболее близкий к системе способ взаимодействия с ней из прикладных программ. Более низкий уровень доступа, необходимый только для драйверов устройств, в текущих версиях Windows предоставляется через Windows Driver Model.

Все виды API функций можно разбить на следующие классы:

· Win16 — первая версия Windows API для 16-разрядных версий Windows. Изначально назывался просто Windows API, затем стал называться Win16 для отличения от Win32.

· Win32s — подмножество Win32, устанавливаемое на семейство 16-разрядных систем Windows 3.x и реализующее ограниченный набор функций Win32 API для этих систем.

· Win32 — 32-разрядный API для современных версий Windows. Самая популярная ныне версия. Базовые функции этого API реализованы в DLL kernel32.dll и advapi32.dll; базовые модули GUI — в user32.dll и gdi32.dll. Win32 появился вместе с Windows NT и затем был перенесён (в несколько ограниченном виде) в системы серии Windows 9x. В современных версиях Windows, происходящих от Windows NT, работу Win32 GUI обеспечивают два модуля: csrss.exe (Client/Server Runtime Subsystem), работающий в пользовательском режиме, и win32k.sys в режиме ядра. Работу же системных Win32 API обеспечивает ядро - ntoskrnl.exe

· Win64 — 64-разрядная версия Win32, содержащая дополнительные функции для использования на 64-разрядных компьютерах. Win64 API можно найти только в 64-разрядных версиях Windows XP, Windows Server 2003, Windows Vista и Windows Server 2008.

Сервис АРI - функция или подпрограмма API, которая реализует некоторое действие (сервис) операционной системы, такое как создание файла или работа с графикой (рисование линий или окружностей). Например, функция API Crea t eProcess используется в Windows для создания нового процесса;

системный сервис - недокументированная (undocumented) функция, которая может вызываться из пользовательского режима. Эти функции часто используются функциями Win32 API для предоставления низкоуровневых сервисов.

Динамически подключаемые библиотеки (dynamic-link libraries, DLL) — краеугольный камень операционной системы Windows, начиная с самой первой ec версии. В DLL содержатся все функции Windows API. Три самые важные DLL: Kernel32.dll (управление памятью, процессами и потоками), User32.dll (поддержка пользовательского интерфейса, в том числе функции, связанные с созданием окон и передачей сообщений) и GDI32.dll (графика и вывод текста).

В Windows есть и другие DLL, функции которых предназначены для более специализированных задач. Например, в AdvAPI32.dll содержатся функции для защиты объектов, работы с реестром и регистрации событий, в ComDlg32.dll ~ стандартные диалоговые окна (вроде File Open и File Save), a ComCrl32 dll поддерживает стандартные элементы управления.

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

- если DLL подсистемы (например, USER32.DLL), экспортирующая данную API-функцию, содержит весь код, необходимый для выполнения функции то функция выполняется и возвращает результат;

- API-функции, вызываемой приложением, может потребоваться вызвать для выполнения вспомогательных действий дополнительный модуль, принадлежащий подсистеме Win32 (но не той DLL, которая экспортирует данную функцию);

- API-функции, вызываемой приложением, могут понадобиться услуги недокументированного системного сервиса. Например, чтобы создать но­вый процесс, API-функция CreateProcess вызывает недокументирован­ный системный сервис NTCreateProcess для реального создания данного процесса. Это делается с помощью функций библиотеки NTDLL.DLL, кото­рая помогает осуществлять переход из пользовательского режима в ре­жим ядра.

Концепция объектной модели компонентов (COM). Основные понятия в COM модели.

Архитектура Windows базируется на использовании множества различных объектов. Объект ядра (kernel object) - это структура данных, доступ к членам которой, имеет только ядро Windows. Далее приведены примеры объектов ядра:

- объект Process представляет процесс;

- объект Thread определяет поток;

- объект File представляет открытый файл;

- объект File-mapping представляет отображаемый в память файл (memory-mapped file), то есть файл, содержимое которого отображено непосредствен­но на виртуальное адресное пространство и используется как физическая память;

- объект Pipe используется для обмена данными между процессами;

- объект Event является объектом синхронизации потоков, сигнализирую­щим о завершении операции;

- объект Mutex представляет собой объект синхронизации потоков, который может использоваться несколькими процессами;

- объект Semaphore используется для того, чтобы учитывать ресурсы и сигнализировать потоку о доступности ресурса на данный момент.

Кроме объектов ядра, существуют также пользовательские объекты и объекты GDI, такие как меню, окна, шрифты, кисти и курсоры мыши.

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

Хотя к объектам ядра нельзя получить непосредственный доступ из пользовательского режима, в Windows API есть функции, которые можно вызывать из данного режима для управления этими объектами. Это своего рода инкапсуляция (encapsulation), защищающая объекты от непредусмотренных или неразрешенные действий. Когда создается объект ядра посредством вызова соответствующей АРI функции (CreateProcess, GreateThread, CreateFile и GreateFileMapping), функция возвращает дескриптор вновь созданного объекта. Такой дескриптор может быть передан другой API-функции для того, чтобы она могла управлять данным объектом.

Дескриптор объекта является зависимым от процесса (process-specific). Это означает, что он действует только в пределах данного процесса. Некоторые идентификаторы, такие как ID процесса, наоборот, являются идентификаторами системного уровня - область их действия - все процессы системы.

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

С учетом этого ядро должно поддерживать подсчет используемости (usage count) каждого объекта. Ядро уничтожает объект тогда, когда его используемость становится равной нулю, но не раньше. Таким образом, процесс, создавший данный объект, может закрыть (close) его дескриптор (посредством вызова API-функции CloseHandle), но объект не будет уничтожен, если какой-то другой процесс продолжает его использовать.

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