Интерфейс прикладных программ (API – Application Programming Interface) – часть ОС, через которую происходит взаимодействие ОС с приложениями, решающими задачи пользователя. API – это набор средств (обычно – процедур и функций), входящих в состав ОС, который может использоваться любой прикладной программой для обеспечения взаимодействия ее с ядром ОС, внешними устройствами и пользователем. Обычно в API входят средства, обеспечивающие выделение ресурсов, работу с файловой системой, взаимодействие с пользователем и управление работой самой ОС. Физически API обычно представляет собой одну или несколько общедоступных библиотек процедур, каждая из которых является частью ОС и может быть вызвана любой программой, выполняющейся под управлением этой ОС. Конкретный механизм вызова процедур API зависит от типа ОС.
Использование API избавляет разработчика прикладных программ от необходимости программировать ряд рутинных операций, таких как чтение файла, ввод с клавиатуры, запуск программ и многое другое. Теоретически, использование программой для работы с системой пользователями и внешними устройствами исключено API ОС обеспечивает системе полную независимость от оборудования, которое физически установлено на компьютере и от особенностей реализации ОС. Программа, работающая только через API, будет (после перекомпиляции в код нужного процессора, естественно) безо всяких изменений работать на компьютере другого типа, нежели тот, на котором она написана, если на этих компьютерах работает ОС, для которой написана программа. Таким образом, использование API обеспечивает лучшую переносимость программы.
Системные программы и операционная система
Поскольку API, как правило, разрабатывается как универсальная библиотека, которая, по определения, должна подходить для практически всех применений, ее процедуры обычно неоптимальны для решения каждой конкретной задачи. Поэтому часть программ в некоторых ОС работает с оборудованием ЭВМ напрямую, минуя ОС и API, что может значительно увеличить производительность, но создает проблемы с работой этих программ на некоторых конкретных компьютерах.
Внешние устройства (ВУ) компьютера очень разнообразны. Для того, чтобы прикладные программы могли работать с ними. Программы, теоретически, должны содержать модули, обеспечивающие взаимодействие с каждым типом ВУ, который может встретиться. В какой-то мере эта задача решается путем стандартизации самих ВУ, что делает возможной работу со многими устройствами с помощью одного и того же программного кода. Так, например, для вывода информации на большинство матричных принтеров можно воспользоваться системой команд фирмы Epson, поскольку эта система команд поддерживается большинством аналогичных принтеров других производителей.
Однако постоянно появляются новые ВУ, которые реализуют принципиально новые возможности или делают возможным выполнение ранее поддерживаемых операций более простыми и эффективными методами. Ограничение командного языка ВУ только общим подмножеством языков всех ВУ такого типа ограничит использование специфических возможностей каждого конкретного устройства.
Компьютер — это система
В связи с этим наиболее приемлемым решением проблемы взаимодействия программ и ВУ является перекладные функции непосредственного взаимодействия с ВУ на ОС. ОС должна содержать модули, умеющие работать с каждым конкретным ВУ, а программа должна работать с ВУ через API ОС. Интерфейс внешних устройств реализуется в ОС с помощью специального вида программ, называемых драйверами. Драйвер – это программа, которая обеспечивает взаимодействие между ВУ определенного типа и операционной системой.
ОС имеет строго заданный стандарт на перечень функций, которые должно выполнять устройство того или иного типа и на порядок взаимодействия с таким ВУ (то есть обобщенные интерфейс ВУ данного типа). Фактически, этот интерфейс описывает некоторое виртуальное устройство, с которым и работает ядро системы.
Драйвер пишется так, сто та его часть, с которой взаимодействует ядро ОС, полностью соответствует заданному интерфейсу виртуального ВУ. Драйвер принимает от ОС команды в стандартизированном виде, перекодирует их в команды конкретного вида ВУ и передает в ОС данные от ВУ также в стандартном формате. ОС может работать с любым ВУ, для которого имеется драйвер, реализующий стандартный протокол взаимодействия. Ядро ОС, а значит и прикладные программы, использующие API, работают с ВУ через драйвер. В результате они могут общаться с ВУ, не зная ничего о его конкретном типе, наборе команд и прочих особенностях.
Более того, некоторые функции, поддерживаемые драйвером, устройство может вообще не реализовать аппаратно. Если, в соответствии с протоколом, в данной ОС устройство данного типа обязано реализовать данную функцию, то эта функция может быть реализована не самим устройством, а его драйвером. Впрочем, и такое поведение драйвера вовсе не обязательно.
Часто бывает, что ряд функций ВУ считается необязательным. Для таких функций предусматриваются средства проверки, с помощью которых обращаются к драйверу программа (или ядро ОС) могут определить поддерживается ли определенная функция. Если необходимая функция поддерживается, она используется, а если нет, то программа должна самостоятельно решить эту проблему.
Так, например, если видеоадаптер компьютера не поддерживает возможности рисования ломанных линий, но ОС требует, что такая функция была, драйвер может перекодировать запрос на рисование ломанной линии в набор из нескольких запросов на рисование отрезков и именно этот набор передать устройству. Естественно, такая реализация даст худшую производительность, чем на устройстве, аппаратно поддерживающем рисование ломанных, однако, функция все-таки будет реализована, и устройство можно будет использовать. С другой стороны, драйвер может просто отказаться рисовать ломанные. Ели функция вывода ломанных не является обязательной, система, прежде чем ее использовать, должна проверить, поддерживается ли она используемым устройством, и если нет, то выполнить рисование ломаной отрезками самостоятельно.
Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:
Источник: studopedia.ru
Программное обеспечение внешних устройств — презентация
Первый слайд презентации: Программное обеспечение внешних устройств
Информатика для СПО
Изображение слайда
Слайд 2: Что такое драйвер?
страница 2 Что такое драйвер? Работа всего спектра внешних устройств обеспечивается специальным программным обеспечением – драйверами. Драйвер — это часть кода операционной системы, отвечающая за взаимодействие с аппаратурой.
Изображение слайда
Слайд 3: Эволюция драйверов
С момента своего появления до сегодняшнего дня драйвер беспрерывно эволюционировал, и процесс этот до сих пор не закончился. Один из моментов эволюции драйвера — это эволюция концепции драйвера, как легко заменяемой части операционной системы. Как отдельный и довольно независимый модуль, драйвер сформировался не сразу. Да и сейчас многие драйверы практически неотделимы от операционной системы.
Изображение слайда
Слайд 4: Эволюция драйверов
Во многих случаях это приводит к необходимости переустановки системы (ОС Windows ) или пересборки ее (ядра) (в UNIX-системах). Такое же различие есть и между ветками операционной системы Windows : Windows 9x и Windows NT. В первом случае процесс работы с драйверами происходит (практически всегда) как с отдельными «кирпичиками», а во втором дела обстоят намного хуже (множество (если не большинство) драйверов «вшито» в ядро).
Изображение слайда
Слайд 5: Общие концепции драйверов
Существуют следующие общие концепции драйверов в Windows — и UNIX-системах: способ работы с драйверами как файлами; драйвер, как легко заменяемая часть ОС (учитывая сказанное выше); существование режима ядра.
Изображение слайда
Слайд 6: Способ работы с драйверами как файлами
Способ работы с драйверами как файлами означает, что функции, используемые при взаимодействии с файлами, практически идентичны таковым при взаимодействии с драйверами (имеется в виду лексически): open, close, read и т. д.
Изображение слайда
Слайд 7: Классификацию типов драйверов для ОС Windows NT
драйверы пользовательского режима ( User-Mode Drivers ): драйверы режима ядра (Kernel-Mode Drivers): Классификацию типов драйверов для ОС Windows NT
Изображение слайда
Слайд 8: Классификацию типов драйверов для ОС Windows NT
драйверы пользовательского режима ( User-Mode Drivers ): драйверы виртуальных устройств ( Virtual Device Drivers, VDD) — используются для поддержки программ MS-DOS; драйверы принтеров ( Printer Drivers); Классификацию типов драйверов для ОС Windows NT
Изображение слайда
Слайд 9: Классификацию типов драйверов для ОС Windows NT
драйверы режима ядра (Kernel-Mode Drivers): драйверы файловой системы ( File System Drivers ) — осуществляют ввод/вывод на локальные и сетевые диски; унаследованные драйверы ( Legacy Drivers ) — написаны для предыдущих версий Windows NT; драйверы видеоадаптеров ( Video Drivers ) — реализуют графические операции; драйверы потоковых устройств ( Streaming Drivers ) — осуществляют ввод/вывод потокового видео и звука; WDM- драйверы ( Windows Driver Model, WDM) — поддерживают технологию Plag and Play и управления электропитанием.
Изображение слайда
Слайд 10: Одно- и многоуровневые драйверы
Если драйвер является многоуровневым, то обработка запросов ввода/вывода распределяется между несколькими драйверами, каждый из которых выполняет свою часть работы. Между этими драйверами можно «поставить» любое количество фильтр-драйверов ( filter-drivers ). Сейчас необходимо запомнить два термина — вышестоящие ( higher-level ) и нижестоящие ( lower-level ) драйверы. При обработке запроса данные идут от вышестоящих драйверов к нижестоящим, а при возврате результатов — наоборот. Ну и, понятно, одноуровневый ( monolithic ) драйвер просто является противоположностью многоуровневому. Одно- и многоуровневые драйверы
Изображение слайда
Слайд 11: Технология Plug and Play
Для технологии Plug and Play существуют три уровня-типа драйверов: шинные драйверы; фильтр-драйверы; функциональные драйверы. Технология Plug and Play
Изображение слайда
Слайд 12: Иерархия драйверов Plug and Play
На низшей ступени находится шинный драйвер, выше него — функциональный драйвер. Между и над ними находится определенное количество фильтр-драйверов. Если точнее, то: 1. Над шинным драйвером — фильтр-драйвер шины; эти два драйвера, очевидно, шинные. 2. Нижестоящие фильтр-драйвер устройства и классовый фильтр-драйвер. 3. Затем — собственно функциональный драйвер.
4. И, наконец, вышестоящие фильтр-драйвер устройства и классовый фильтр-драйвер; все драйверы со 2 по настоящий пункт относятся к драйверам устройства.
Изображение слайда
Слайд 13: Уровни запросов прерываний ( IRQL)
Как известно, прерывания обрабатываются в соответствии с их приоритетом. В Windows NT используется особая схема прерываний, называемая уровнями запросов прерываний. Всего уровней IRQL 32, самый низкий — 0 ( passive ), самый высокий — 31 ( high ). Прерывания с уровня 0 по 2 (DPC dispatch ) являются программными, а с 3 по 31 — аппаратными. Существуют специальные функции ядра, позволяющие узнать текущий уровень IRQL, а также сменить (понизить или повысить) его. Уровни запросов прерываний ( IRQL)
Изображение слайда
Слайд 14: Технология Plug and Play
Технология Plug and Play (в условном переводе — «подключи и работай») — это технология, состоящая как из программной, так и из аппаратной поддержки механизма, позволяющего подключать/отключать, настраивать и т. д. применительно к системе все устройства, подключаемые к ней (конечно же, при условии, что подключаемые устройства поддерживают Plug and Play -технологию). В идеале весь этот процесс осуществляет только механизм Plug and Play, и какие-то действия со стороны пользователя вообще не требуются. Для каких-то устройств это так и происходит, для других — проблем, к сожалению, может быть гораздо больше. Кроме того, для успешной работы Plug and Play необходима не только поддержка этой технологии со стороны устройств, но также, конечно, со стороны драйверов и системного ПО.
Изображение слайда
Слайд 15: Возможности системного ПО поддерживающего технологию Plug and Play
Рассмотрим какие возможности предоставляет системное ПО (вместе с драйверами), поддерживающее технологию Plug and Play : автоматическое распознание подключенных к системе устройств; распределение и перераспределение ресурсов (таких как, например, порты ввода/вывода и участки памяти) между запросившими их устройствами; загрузка необходимых драйверов; предоставление драйверам необходимого интерфейса для взаимодействия с технологией Plug and Play ; реализация механизма, позволяющего драйверам и приложениям получать информацию касаемо изменений в наборе устройств, подключенных к системе устройств, и совершить необходимые действия.
Изображение слайда
Слайд 16: Структура механизма Plug and Play
Система Plug and Play состоит из двух компонентов, находящихся соответственно в пользовательском режиме и режиме ядра — менеджера Plug and Play пользовательского режима и менеджера Plug and Play «ядерного» режима. Менеджер Plug and Play режима ядра работает с ОС и драйверами для конфигурирования, управления и обслуживания устройств. Менеджер Plug and Play пользовательского режима же взаимодействует с установочными компонентами пользовательского режима для конфигурирования и установки устройств. Также, при необходимости, менеджер Plug and Play взаимодействует с приложениями.
Изображение слайда
Слайд 17: Номенклатура устройств поддерживающих PnP
PnP (сокращенное обозначение Plug and Play ) может успешно работать со следующими типами устройств: физические устройства; виртуальные устройства; логические устройства.
Изображение слайда
Последний слайд презентации: Программное обеспечение внешних устройств: Требования к драйверам, реализующим PnP
Какие условия драйвер должен выполнить для осуществления полной поддержки Plug and Play ? наличие функции DriverEntry ; наличие функции AddDevice ; наличие функции DispatchPnp ; наличие функции DispatchPower ; наличие функции Unload ; наличие cat -файла (файла каталога), содержащего сигнатуру WHQL ; наличие inf -файла для установки драйвера.
Источник: slide-share.ru
Программное обеспечение внешних устройств
ЧТО ТАКОЕ
ДРАЙВЕР?
• Работа всего спектра внешних
устройств обеспечивается
специальным программным
обеспечением – драйверами.
• Драйвер — это часть кода
операционной системы, отвечающая
за взаимодействие с аппаратурой.
страница 2
3.
Эволюция драйверов
С момента своего появления до сегодняшнего
дня драйвер беспрерывно эволюционировал, и
процесс этот до сих пор не закончился. Один из
моментов эволюции драйвера — это эволюция
концепции драйвера, как легко заменяемой
части операционной системы. Как отдельный и
довольно независимый модуль, драйвер
сформировался не сразу. Да и сейчас многие
драйверы практически неотделимы от
операционной системы.
4.
Эволюция драйверов
Во многих случаях это приводит к необходимости
переустановки системы (ОС Windows) или
пересборки ее (ядра) (в UNIX-системах). Такое же
различие есть и между ветками операционной
системы Windows: Windows 9x и Windows NT. В
первом случае процесс работы с драйверами
происходит (практически всегда) как с отдельными
«кирпичиками», а во втором дела обстоят намного
хуже (множество (если не большинство) драйверов
«вшито» в ядро).
5.
Общие концепции драйверов
Существуют следующие общие концепции
драйверов в Windows- и UNIX-системах:
• способ работы с драйверами как файлами;
• драйвер, как легко заменяемая часть ОС
(учитывая сказанное выше);
• существование режима ядра.
6.
Способ работы с драйверами как файлами
Способ работы с драйверами как файлами
означает, что функции, используемые при
взаимодействии с файлами, практически
идентичны таковым при взаимодействии с
драйверами (имеется в виду лексически): open,
close, read и т. д.
7.
Классификацию типов драйверов для ОС Windows NT
• драйверы
пользовательского
режима (User-Mode
Drivers):
• драйверы режима ядра
(Kernel-Mode Drivers):
8.
Классификацию типов драйверов для ОС Windows NT
• драйверы пользовательского режима (User-Mode
Drivers):
• драйверы виртуальных устройств (Virtual
Device Drivers, VDD) — используются для
поддержки программ MS-DOS;
• драйверы принтеров (Printer Drivers);
9.
Классификацию типов драйверов для ОС Windows NT
• драйверы режима ядра (Kernel-Mode Drivers):
• драйверы файловой системы (File System Drivers) —
осуществляют ввод/вывод на локальные и сетевые диски;
• унаследованные драйверы (Legacy Drivers) — написаны для
предыдущих версий Windows NT;
• драйверы видеоадаптеров (Video Drivers) — реализуют
графические операции;
• драйверы потоковых устройств (Streaming Drivers) —
осуществляют ввод/вывод потокового видео и звука;
• WDM-драйверы (Windows Driver Model, WDM) —
поддерживают технологию Plag and Play и управления
электропитанием.
10.
Одно- и многоуровневые драйверы
Если драйвер является многоуровневым, то
обработка запросов ввода/вывода
распределяется между несколькими
драйверами, каждый из которых выполняет
свою часть работы. Между этими
драйверами можно «поставить» любое
количество фильтр-драйверов (filter-drivers).
Сейчас необходимо запомнить два термина
— вышестоящие (higher-level) и
нижестоящие (lower-level) драйверы. При
обработке запроса данные идут от
вышестоящих драйверов к нижестоящим, а
при возврате результатов — наоборот. Ну и,
понятно, одноуровневый (monolithic)
драйвер просто является
противоположностью многоуровневому.
11.
Технология Plug and Play
Для технологии Plug and
Play существуют три
уровня-типа драйверов:
• шинные драйверы;
• фильтр-драйверы;
• функциональные
драйверы.
12.
Иерархия драйверов Plug and Play
На низшей ступени находится шинный драйвер, выше него
— функциональный драйвер. Между и над ними находится
определенное количество фильтр-драйверов. Если точнее,
то:
• 1. Над шинным драйвером — фильтр-драйвер шины; эти
два драйвера, очевидно, шинные.
• 2. Нижестоящие фильтр-драйвер устройства и классовый
фильтр-драйвер.
• 3. Затем — собственно функциональный драйвер.
• 4. И, наконец, вышестоящие фильтр-драйвер устройства
и классовый фильтр-драйвер; все драйверы со 2 по
настоящий пункт относятся к драйверам устройства.
13.
Уровни запросов прерываний (IRQL)
Как известно, прерывания
обрабатываются в соответствии с
их приоритетом. В Windows NT
используется особая схема
прерываний, называемая уровнями
запросов прерываний. Всего
уровней IRQL 32, самый низкий —
0 (passive), самый высокий — 31
(high). Прерывания с уровня 0 по 2
(DPCdispatch) являются
программными, а с 3 по 31 —
аппаратными. Существуют
специальные функции ядра,
позволяющие узнать текущий
уровень IRQL, а также сменить
(понизить или повысить) его.
14.
Технология Plug and Play
Технология Plug and Play (в условном переводе — «подключи и
работай») — это технология, состоящая как из программной, так
и из аппаратной поддержки механизма, позволяющего
подключать/отключать, настраивать и т. д. применительно к
системе все устройства, подключаемые к ней (конечно же, при
условии, что подключаемые устройства поддерживают Plug and
Play-технологию). В идеале весь этот процесс осуществляет
только механизм Plug and Play, и какие-то действия со стороны
пользователя вообще не требуются. Для каких-то устройств это
так и происходит, для других — проблем, к сожалению, может
быть гораздо больше. Кроме того, для успешной работы Plug and
Play необходима не только поддержка этой технологии со
стороны устройств, но также, конечно, со стороны драйверов и
системного ПО.
15.
Возможности системного ПО поддерживающего технологию
Plug and Play
Рассмотрим какие возможности предоставляет системное ПО (вместе с
драйверами), поддерживающее технологию Plug and Play:
• автоматическое распознание подключенных к системе устройств;
• распределение и перераспределение ресурсов (таких как, например,
порты ввода/вывода и участки памяти) между запросившими их
устройствами;
• загрузка необходимых драйверов;
• предоставление драйверам необходимого интерфейса для
взаимодействия с технологией Plug and Play;
• реализация механизма, позволяющего драйверам и приложениям
получать информацию касаемо изменений в наборе устройств,
подключенных к системе устройств, и совершить необходимые
действия.
16.
Структура механизма Plug and Play
Система Plug and Play состоит из двух компонентов,
находящихся соответственно в пользовательском режиме и
режиме ядра — менеджера Plug and Play пользовательского
режима и менеджера Plug and Play «ядерного» режима.
Менеджер Plug and Play режима ядра работает с ОС и
драйверами для конфигурирования, управления и
обслуживания устройств. Менеджер Plug and Play
пользовательского режима же взаимодействует с
установочными компонентами пользовательского режима
для конфигурирования и установки устройств. Также, при
необходимости, менеджер Plug and Play взаимодействует с
приложениями.
17.
Номенклатура устройств поддерживающих PnP
PnP (сокращенное обозначение Plug and Play)
может успешно работать со следующими типами
устройств:
• физические устройства;
• виртуальные устройства;
• логические устройства.
18.
Требования к драйверам, реализующим PnP
Какие условия драйвер должен выполнить для
осуществления полной поддержки Plug and Play?
• наличие функции DriverEntry;
• наличие функции AddDevice;
• наличие функции DispatchPnp;
• наличие функции DispatchPower;
• наличие функции Unload;
• наличие cat-файла (файла каталога), содержащего
сигнатуру WHQL;
• наличие inf-файла для установки драйвера.
Источник: ppt-online.org