Пользовательский интерфейс и оболочки

Напомним, что ОС всегда выступает как интерфейс между аппаратурой компьютера и пользователем с его задачами. Под интерфейсами операционных систем здесь и далее следует понимать специальные интерфейсы системного и прикладного программирования, предназначенные для выполнения следующих задач:

Управление процессами, которое включает в себя следующий набор основных функций:

- запуск, приостановка и снятие задачи с выполнения;

- задание или изменение приоритета задачи;

- взаимодействие задач между собой;

- удаленный вызов подпрограмм.

- Управление памятью:

- запрос на выделение блока памяти;

- освобождение памяти;

- изменение параметров блока памяти;

- отображение файлов на намять.

- Управление вводом/выводом:

- запрос на управление виртуальными устройствами;

- файловые операции.

Здесь мы перечислили основные наборы функций, которые выполняются ОС по соответствующим запросам от задач. Что касается пользовательского интерфейса операционной системы, то он реализуется с помощью специальных программных модулей, которые принимают его команды на соответствующем языке и транслируют их в обычные вызовы в соответствии с основным интерфейсом системы. Обычно эти модули называют интерпретатором команд. Получив от пользователя команду, после лексического и синтаксического анализа либо сам выполняет действие, либо, что случается чаще, обращается к другим модулям ОС, используя механизм API. Надо заметить, что в последние годы большую популярность получили графические интерфейсы (GUI), в которых задействованы соответствующие манипуляторы типа «мышь» или «трекбол». Указание курсором на объекты и щелчок (клик) или двойной щелчок по соответствующим клавишам приводит к каким-либо действиям — запуску программы, ассоциированной с указываемым объектом, выбору и/или активизации пунктов меню и т. д. Можно сказать, что такая интерфейсная подсистема транслирует «команды» пользователя в обращения к ОС.

Обращения к операционной системе, в соответствии с имеющимся API, может осуществляться как посредством вызова подпрограммы и передачей ей необходимых параметров, гак и через механизм программных прерываний. Выбор метода реализации вызовов функции API должен определяться архитектурой платформы.

В более сложных системах имеется не одна точка входа, а множество — по количеству функций API. В большинстве операционных систем используется метод вызова подпрограмм. В этом случае вызов сначала передается в модуль API, который и перенаправляет вызов соответствующим обработчикам программных прерываний, входящим в состав операционной системы. Использование механизма прерывании вызвано, главным образом, тем, что при этом процессор переводится в режим супервизора.

Современные ОС поддерживают развитые функции пользовательского интерфейса для интерактивной работы за терминалами двух типов: алфавитно-цифровыми и графическими.

При работе за алфавитно-цифровым терминалом пользователь имеет в своем распоряжении систему команд, мощность который отражает функциональные возможности данной ОС. Обычно командный язык ОС позволяет запускать и останавливать приложения, выполнять различные операции с файлами и каталогами, получать информацию о состоянии ОС (количество работающих процессов, объем свободного пространства на дисках и т. п.), администрировать систему. Команды могут вводиться не только в интерактивном режиме с терминала, но и считываться из так называемого командного файла, содержащего некоторую последовательность команд.

Программный модуль ОС, ответственный за чтение отдельных команд или же последовательности команд из командного файла, иногда называют командным интерпретатором.

Ввод команды может быть упрощен, если операционная система поддерживает графический пользовательский интерфейс, В этом случае пользователь для выполнения нужного действия с помощью мыши выбирает на экране нужный пункт меню или графический символ.

Контрольные задания для СРС [(1;3-27,196-227),(5;380-414),(2;207-219)]

1. Базовые концепции Windows API

2. Ключевые компоненты системы

3. Анализ и устранение проблем с реестром

Рекомендуемая литература

1. Руссинович М., Соломон Д. Внутреннее устройство Microsoft Winows

2. Гордеев А.В, Молчанов А.Ю. Системное программное обеспечение.

3. Таненбаум Э, Вудхал А Операционные системы: разработка и реализация.

4. Столингс Операционные системы

5. Олифер В.Г.,Олифер Н.А. Сетевые ОС

Лекция

1.Тема лекции.Маршрутизация, буферизация и регистрация сообщений. Удаленная обработка. Электронная почта.

План лекции

1. Маршрутизация, буферизация и регистрация сообщений.

2. Удаленная обработка.

3. Электронная почта.

3. Цель лекции: Ознакомить студентов с маршрутизация, буферизация и регистрация сообщений. Удаленная обработка. Электронная почта..

4. Содержание лекции:

Чтобы упростить разработку Интернет-приложений, в ОС предусмотрены клиентские и серверные API-интерфейсы доступа к Интернету. С помощью этих API приложения могут предоставлять и использовать сервисы Gopher, FTP и HTTP, не зная внутреннего устройства соответствующих протоколов. Клиентские API в системе WINDOWS включают Windows Internet, также называемый WinInet, и WinHTTP. В определенных ситуациях WinHTTP удобнее WinInet. HTTP — это серверный API, введенный в Windows Server 2003 для поддержки разработки серверных Web-приложений.

WinInet делится на наборы под-API, специфичные для каждого протокола. Используя API-функции FTP, разработчик приложения может не задумываться о деталях, связанных с установлением соединения и форматированием TCP/IP-сообщений для протокола FTP. API-функции Gopher и HTTP обеспечивают аналогичный уровень абстракции. Winlnet применяется базовыми компонентами Windows, например Windows Explorer и Internet Explorer.

WinHTTP этот API обеспечивает абстракцию протокола HTTP 1.1 для серверных приложений, взаимодействующих с HTTP-серверами. Серверные приложения часто реализуются как Windows-службы без UI, поэтому им не нужны диалоговые окна. Кроме того, WinHTTP API лучше масштабируется и предоставляет средства защиты вроде подмены потоков, недоступные в Winlnet API.

HTTP API, к которому приложения обращаются через библиотеку Httpapi.dll, опирается на драйвер Http.sys режима ядра. Http.sys запускается по требованию при первом вызове HttpInitialize любым приложением. Функция HttpCreateHttpHandle позволяет создавать закрытую очередь запросов, а функция HttpAddUrl — указывать URL-адреса, по которым приложение собирается принимать запросы для обработки. Используя очереди запросов и их зарегистрированные URL, Http.sys дает возможность обслуживать HTTP-запросы на одном порту, например 80, более чем одному приложению.

HttpReceiveHttpRequest принимает входящие запросы, направленные по зарегистрированным URL, a HttpSendHttpResponse передает HTTP-ответы. Обе функции работают в асинхронном режиме, так что приложение может определять, закончена ли какая-то операция, используя GetOverlappedResult или порты завершения ввода-вывода.

Приложения могут использовать Http.sys кэширования данных в неподкачиеваемой физической памяти, вызывая HttpAddToFragmentCache и сопоставляя имя фрагмента с кэшируемыми данными. Для выделения неспроецированных страниц физической памяти Http.sys запускает функцию MmAllocate-PagesForMctt, принадлежащую диспетчеру памяти. Когда Http.sys требуется сопоставление виртуального адреса с физической памятью, описываемой элементом кэша (например, если Http.sys копирует данные в кэш или передает их из кэша), он вызывает MmMapLockedPagesSpecijyCache, а по окончании операций — MmUnmapLockedPages. Http.sys хранит кэшируемые данные до тех пор, пока приложение не объявит их недействительными или пока не истечет срок их актуальности, заданный приложением. Http.sys также усекает кэшируемые данные при пробуждении рабочего потока из-за перехода в свободное состояние события, уведомляющего о малом объеме памяти. Если при вызове HttpSendHttpResponse приложение указывает одно или несколько имен фрагментов, Http.sys передает указатель на данные, кэшируемые в физической памяти, драйверу TCP/ IP и тем самым исключает лишнюю операцию копирования.