СПО

используемая библиотека удовлетворяет какому-то принятому стандарту, а система программирования поддерживает этот стандарт.

Например, библиотеки, удовлетворяющие стандарту POSIX, доступны в большинстве систем программирования для языка С. И если прикладная программа использует только библиотеки этого стандарта, то ее исходный код будет переносимым.

Для большинства специфических библиотек отдельных разработчиков это не так. Если пользователь использует ка- кую-то библиотеку, то она ориентирована на ограниченный набор доступных архитектур целевой вычислительной системы. Примерами могут служить библиотеки MFC (Microsoft foundation classes) фирмы Microsoft и VCL (Visual Components Library) фирмы Borland, жестко ориентированные на архитектуру ОС типа Windows.

Тем не менее, многие фирмы-разработчики сейчас стремятся создать библиотеки, которые бы обеспечивали переносимость исходного кода приложений между различными архитектурами целевой вычислительной системы. К ним можно отнести библиотеку CLX (Component Library for Cross Platform) производства фирмы Borland ориентированную на архитектуру ОС типа Linux и ОС типа Windows.

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

Поэтому разработчики системных программ вынуждены оставаться в довольно узких рамках ограничений стандартных библиотек языков программирования.

Что касается прикладных программ, то гораздо большую перспективу для них предоставляют технологии, связанные с

разработками в рамках архитектуры «клиент – сервер» или трехуровневой архитектуры создания приложений. В этом направлении ведущие производители ОС, СУБД и систем программирования скорее достигнут соглашений, чем в направлении стандартизации API.

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

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

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

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

Частным случаем попытки стандартизации API является внутренний корпоративный стандарт компании Microsoft, известный как WinAPI. Он включает в себя следующие реализа-

ции: Win 16, Win32s, Win32, WinCE.

С точки зрения WinAPI (в силу ряда идеологических причин – обязательный графический «оконный» интерфейс пользователя), базовой задачей является окно. Таким образом, WinAPI изначально ориентирован на работу в графической среде. Однако базовые понятия дополнены традиционными функциями, в том числе частично поддерживается стандарт

POSIX.

6.4. Классификация системных вызовов

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

API:

–управление процессами, потоками и синхронизацией;

–управление виртуальной и физической памятью;

–управление вводом-выводом.

В API Windows также есть еще ряд групп:

–графический интерфейс пользователя;

–управление защитой;

–управление реестром;

–консольные функции

–другие группы специальных функций.

Примеры функций API, относящихся к разным группам приведены в табл. 7 - 15.

Таблица 7 Основные функции управления процессами и потоками

Таблица 9 Основные функции управления виртуальной и физической

памятью

Продолжение табл. 11

MoveFile Переместить файл из одного каталога в другой

SetCurrent Directory Изменить текущий рабочий каталог

Насчитывается несколько сотен функций графического интерфейса пользователя (GUI). Поэтому следует ограничиться названиями групп этих функций (табл. 12)

Таблица 12 Группы API-функций, реализующий графический

интерфейс пользователя

6.5. Интерфейс пользователя

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

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

Поскольку с операционной системой могут взаимодействовать различные категории пользователей – администраторы, системные программисты, операторы, программисты и конечные пользователи, то каждой из этих категорий предоставляется свой интерфейс.

Вид интерфейса взаимодействия пользователя с ОС исторически определялся возможностями технических средств общения пользователя с системой.

Изначально пользователь общался с системой, вводя в

командную строку консоли информацию по принципу «приглашение/вопрос – ввод – обработка – ответ». С развитием операционных систем были разработаны графические интер-

фейсы, представляющие собой надстройки над операционными системами.

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

ВUNIX-подобных системах (UNIX , Linux) графический интерфейс строится основе стандарта X Window System. Система X Window построена на модели «клиент/сервер». Основой подсистемы является так называемый Х-сервер, который работает на компьютере пользователя и обеспечивает вывод изображения на экран монитора, а также ввод данных от пользователя (через клавиатуру, мышь и т. п.). Приложения выступают в роли клиентов. Для общения с сервером клиентам предоставляется библиотека XLib, содержащая функции низкоуровневого взаимодействия.

Следующий уровень в реализации интерфейсных возможностей в UNIX-подобных системах представлен интегри-

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

6.6.Пользовательский интерфейс приложений

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

окна имеют рамку, которая определяет их границы; рамка используется также для изменения размеров окна. В верхнем левом углу окна находится значок системного меню. Щелчок мыши на этот значок открывает системное меню. Справа от значка системного меню находится заголовок окна. В правом верхнем углу окна расположены кнопки минимизации, полноэкранной развертки (полноэкранного представления) и закрытия окна. Ниже находится рабочая область – это часть окна, в которой отображается выполнение программы. Стандартными элементами пользовательского интерфейса стали главное меню программы, контекстные меню, горячие клавиши, панели инструментов, строка состояния, вертикальные и горизонтальные линейки прокрутки, различные элементы управления и т. д.

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

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