Реализация альтернативной API на примере CentOS
Архитектура строения операционной системы. Назначение API в операционных системах и разных платформах. Особенности строения API в ядре Linux. Реализация проекта для работы с CDROM на CentOS. Сравнение Linux и Windows. Реализация проекта на Win32 API.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 08.06.2017 |
| Размер файла | 1,6 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
72
Размещено на http://www.allbest.ru/
Министерство образования и науки Амурской области
Государственное профессиональное образовательное автономное учреждение Амурской области
"Амурский колледж строительства и жилищно-коммунального хозяйства"
Кафедра технических дисциплин
Дипломный проект
Тема: "Реализация альтернативной API на примере CentOS"
Содержание
- Введение
- 1. Теоретическая часть
- 1.1 Архитектура строения операционной системы
- 1.2 API в операционных системах и разных платформах
- 1.3 API и системные вызовы
- 1.4 CentOS
- 1.5 Строение API в ядре Linux
- 1.6 Windows API
- 1.7 Usermode-helper API
- 1.8 Win32 API
- 2. Практическая часть
- 2.1 Примечание к практической части
- 2.2 Пример использования usermode-helper API
- 2.3 Реализация проекта для работы с CDROM на CentOS
- 2.4 Реализация проекта на Win32 API
- 2.5 Сравнение Linux и Windows
- Заключение
- Список литературы
- Приложение А
- Приложение Б
Введение
На сегодняшний день каждая операционная система имеет свои API - Application Programming Interface, которые позволяют программистам разрабатывать приложения под конкретную платформу. По сути дела, API является набор готовых функций, классов, библиотек, модулей, констант и функций, которые предоставляет операционная система и/или набор стороннего программного обеспечения.
Это даёт ряд преимуществ при написании программного обеспечения, поскольку разработчику не придётся писать свой метод, а воспользоваться уже готовым решением.
API помогают взаимодействовать компонентам операционной системы и прикладным программам посредствам передачи информации в API,
Однако сама концепция API также имеет и ряд недостатков, например, жёстко ограничивает платформу. Приложение, написанное под Microsoft Windows уже не запуститься под GNU/Linux или FreeBSD штатными средствами. Конечно, можно использовать программы для эмуляции предоставления API, такие как Wine и Cygwin, но это только эмуляции программного обеспечения, а не полноценная поддержка.
Актуальность данной темы является в постоянном использовании API практически во всех приложениях, начиная от запуска графического интерфейса и демонов служб, и заканчивая новейшими играми.
Целью данного дипломного проекта является изучения реализации API в операционной системе CentOS, а задачи можно выделить как:
Теоретически рассмотреть API в разных платформах и с точки зрения разработчика программного обеспечения.
Практически сравнить API в 2-х ОС: CentOS, Microsoft Windows, путём написания программы с использованием API.
Написать сравнительный анализ.
1. Теоретическая часть
1.1 Архитектура строения операционной системы
APIначало развиваться с эволюцией и разработкой операционных систем. Для более полного представления об взаимодействии API с операционной системой и/или прикладным программным обеспечением следует понимать об их внутреннем устройстве.
Операционная система (в дальнейшем ОС) должна обеспечивать:
Взаимодействие между аппаратными комплектующими ПК (ввод/вывод данных).
Хранение и организация строения данных.
Организовывать загрузку и выполнение программ.
Организовывать роль интерфейса между пользователем и аппаратным обеспечением.
На основание предыдущих пунктов можно сформулировать понятие: ОС - комплекс программ, обеспечивающих интерфейс между пользователем и "железом".
Структура ОС выглядит следующим образом:
Ядро.
Системные библиотеки.
Shell и другие утилиты.
Ядро является наиважнейшим компонентом любой ОС, поскольку именно оно даёт приложениям доступ к ресурсам компьютера, таким как память, процессорное время, устройства ввода-вывода и т.д.
Системные библиотеки служат вспомогательными средствами для вызова операций. Обычно это файлы содержащие в себе машинный код.
Shell является командным интерпритатором ОС. Позволяет взаимодействовать пользователю либо через графический интерфейс (GUI), либо через текстовый режим (TUI). В качестве программ используются системные утилиты, например man, cp, ping в UNIX-подобных ОС и проводник Windows в случае с Microsoft Windows.
В качестве наглядного примера мы поставили следующую задачу - узнать свойства ОС в разных вариантах интерпретатора. Ниже приведены 2 рисунка, на одном из которых показана работа в TUI (вызов утилиты screenfetch в командном интерпретаторе SH) и GUI (вызов свойств в интерпретаторе Explorer от Microsoft Windows).
Рисунок 1 - Вызов утилиты screenfetch в SH.
На рисунке 1 мы видим взаимодействие с пользователем путём текстового интерфейса, программа screenfetch с помощью текста отобразила основные характеристики операционной системы.
архитектура строение операционная система
Рисунок 2 - Свойства системы в ОС Microsoft Windows 7 в Проводнике Windows.
Таким образом мы показали разные способы взаимодействия ОС с пользователем: текстовый и графический.
1.2 API в операционных системах и разных платформах
[API (интерфейс программирования приложений, интерфейс прикладного программирования) (англ. application programming interface) - набор готовых классов, процедур, функций, структур и констант, предоставляемых приложением (библиотекой, сервисом) или операционной системой для использования во внешних программных продуктах. Используется программистами при написании всевозможных приложений], цитирование из Википедии.
Что по сути дела представляет API? Конечно-же облегчённый доступ к вызовам функций внутри ОС, однако, с технической точки зрения API это только файлы. Файлы, с уже написанными метода, функциями и т.д., и если приложения обладает достаточным уровнем доступа, то оно может использовать эти возможности. В качестве примера можно провести аналогию с динамическими библиотеками.
Таблица 1 - Динамические библиотеки в разных ОС.
|
Операционная Система |
Расширение |
|
|
Microsoft Windows |
Dll |
|
|
UNIX-подобные ОС |
So |
|
|
Mac OS |
Dylib |
|
|
AmigaOS |
Library |
Практическое применение API является чрезвычайно частым явлением. В качестве примера смоделируем следующую ситуацию: "Необходимо разработать программу для ОС GNU/Linux, которая отобразит файлы в указанной директории".
Для решения этой задачи мне необходимо обращаться к API ОС, либо воспользоваться системные вызовами.2-ой вариант является не особо практичен из-за сложности реализации и более большого объёма работы.
#include <stdio. h>
#include <dirent. h> // подключение API библиотеки
int main (int argc, char ** argv)
{
DIR * direct;
struct dirent * entry;
if (argc! = 2)
{
printf ("Press directory\n", argv [0]);
return 0;
}
direct = opendir (argv [1]);
if (direct == NULL)
{
printf ("Error, sorry: (\n");
return 1;
}
while (entry = readdir (direct))
printf ("%s inode=%i\n", entry->direct_name, entry->direct_ino);
closedir (direct);
return 0;
}
В данном примере рассмотрена работа вызова методов opendir, readdir и closedir с применением API. Сам код этих функций находится в подключенном модуле "dirent. h", и мы вызываем функции прямиком из него. Это даёт огромные преимущества: писать приложения становится более просто, код более маленький и понятный.
Не смотря на все явные преимущества, скомпилированное приложение уже не запустится ни под Microsoft Windows, ни под Mac OS, ни под любой другой программной платформой. Хотя сам код либо части, либо полностью будет работоспособен. Это всё потому что API разные и даёт возможность запускать одни и те же приложения на разных платформах.
APIв Web приложениях так же широко развиты и постоянно используются, к примеру такие сервисы как vk.com, twitter и многие другие имеют свои задокументированные API, что позволяет разработчикам писать клиенты для социальных сетей - приложения, позволяющие использовать функционал сайта, но при этом не являясь web-браузером.
1.3 API и системные вызовы
Дело в том что прикладное обращение при эксплуатации может обращаться к системному ядру ОС. Такие запросы называются системными вызовами. Для совершения такого запроса приложению необходимы права доступа из-за того что приложения выполняются в своём адресном пространстве и не могут изменять другие приложения или саму ОС. Для обеспечения безопасности и используют системные вызовы, то есть обращение приложения к ядру дляпредоставление доступа к каким-то ресурсам. Если ресурсы доступны и права доступа соблюдены, то ядро предоставляет требуемую операцию и возвращает результат и/или предоставляет приложению управление ресурсом.
Интерфейс системных вызовов в ОС семейства Microsoft Windows предоставлены в Native API - API для внутреннего использования ОС Microsoft Windows, или функция syscall из заголовочного файла sys/syscall. h в CentOS (как и в любом другом GNU/Linux дистрибутиве).
1.4 CentOS
CentOS является дистрибутивом GNU/Linux, основанном на свободных исходных текстах коммерческого дистрибутива Red Hat Enterprise Linux компании Red Hat, и совместимый с ним. Срок поддержки каждой версии CentOS составляет 10 лет (с помощью выпуска обновлений безопасности). Новая версия CentOS выходит раз в 2 года и каждая версия регулярно обновляется (каждые 6 месяцев) для поддержки новых аппаратных средств. В результате это приводит к безопасной, легко обслуживаемой, надежной, предсказуемой и масштабируемой Linux среде.
Дистрибутивом GNU/Linux принято называть форму распространения программного обеспечения. Дистрибутив включает в себя программы для начальной инициализации операционной системы, её установщика и некоторые другие программы, например программа для работы с жёсткими дисками cfdisk, проверка интернет соединения с помощью программы ping и так далее.
Так как CentOS является дистрибутивом GNU/Linux, то API будут использоваться самого ядра Linux. Основные отличия CentOS от того-же Arch Linux (да и любого другого дистрибутива Linux) заключается в:
Пакете поставки. В CentOS уже будут включены многие программы, начиная от драйверов и заканчивая веб-браузерами, в то время как в Arch будет только текстовый редактор и консоль;
менеджер пакетов. Если в Arch используется pacman, то в CentOS dnf;
репозитории. Места хранения пакетов значительно отличаются друг от друга, как и наличия в них пакетов и версий. В Arch используются самые последние сборки программ, в то время как в CentOS обновления пакетов будут проходить тщательное тестирование на безопасность и стабильность;
философия распространения. Arch позиционирует себя как дистрибутив для опытных пользователей и его дальнейшая эксплуатация будет зависеть поставленных целей, в то время как CentOS является дистрибутив больше предназначенным для использования в качестве серверов или другого сетевого программного обеспечения.
Приэто данные дистрибутивы можно использовать в одинаковых целях: в качестве домашней операционной системы для просмотра фильмов, прослушивания музыки или же для игр, или развернуть целый сервер. Потому что такие пакеты как Apache, Samba, VLC или Steam будут доступны в репозиториях, или можно будет скачать исходный код этих программ и выполнить самостоятельную компиляцию исходного кода (так называемую сборку из исходников).
В итоге получается, что дистрибутивы технически разные, но это никак не отменяет возможность их применения в различных сферах.
1.5 Строение API в ядре Linux
Ядро Linux предоставляет несколько интерфейсов для приложений пользовательского пространства, которые используются для разных целей и имеют разные свойства по использованию. В ядре Linux есть два типа интерфейса прикладного программирования (API), которые не следует путать: API-интерфейс "пространство ядра пользователя" и "внутренний интерфейс ядра".
APILinux - это API-интерфейс пользователя ядра, который позволяет программам в пространстве пользователя получать доступ к системным ресурсам и службам ядра Linux. Он составлен из интерфейса системных вызовов ядра Linux и подпрограмм в библиотеке GNU C (glibc). Развитие Linux API заключался в том, чтобы предоставить пригодные для использования функции спецификаций, определенных в POSIX, таким образом, чтобы они были достаточно совместимыми, надежными и производительными и предоставляли дополнительные полезные функции, не определенные в POSIX. Поскольку в ядро Linux поступает гораздо больше изменений по сравнению с другими стандартными библиотеками ядра и CIOS, совместимыми с POSIX, ядро Linux и его API были дополнены дополнительными функциями. Поскольку эти дополнительные функции обеспечивают техническое преимущество, программирование для Linux API предпочтительнее POSIX-API. Хорошо известными примерами являются udev, systemd и Weston. пространства API других систем, реализующих POSIX API, также предоставляют дополнительные функции, не определенные в POSIX.
Для POSIX API написано много свободного программного обеспечения с открытым исходным кодом. Поскольку в ядро Linux поступает гораздо больше изменений по сравнению с другими стандартными библиотеками ядра и CIOS, совместимыми с POSIX, ядро Linux и его API были дополнены дополнительными функциями. Поскольку эти дополнительные функции обеспечивают техническое преимущество, программирование для Linux API предпочтительнее POSIX-API. Хорошо известными примерами являются udev, systemd и Weston.
Интерфейс системного вызова является наименованием для всех всех реализованных и доступных системных вызовов в ядре. Различные подсистемы, например, например. DRM определяют свои собственные системные вызовы, а целостность называется "Системным Интерфейсом Вызова".
Термин Linux ABI относится к пространству пользователя ядра ABI. Бинарный интерфейс приложения ссылается на скомпилированные двоичные файлы в машинном коде. Поэтому любой такой ABI привязан к набору команд. Определение полезного ABI и поддержание его стабильности в меньшей степени зависит от разработчиков ядра Linux или разработчиков библиотеки GNU C, а также от задач для дистрибутивов Linux и независимых поставщиков программного обеспечения (ISV), которые хотят продавать и поддерживать их проприетарное программное обеспечение как двоичные файлы только для такого единого Linux ABI, а не для поддержки нескольких Linux ABI.
Для каждого набора команд необходимо определить ABI для каждого набора команд, например x86, x86-64, MIPS, ARMv7-A (32-бит), ARMv8-A (64-бит) и так далее, если они поддерживаются.
1.6 Windows API
WindowsAPI - общее наименование целого набора базовых функций интерфейсов программирования приложений операционных систем семейств Microsoft Windows корпорации "Майкрософт". Является самым прямым способом взаимодействия приложений с Windows. Для создания программ, использующих Windows API, "Майкрософт" выпускает комплект разработчика программного обеспечения, который называется Platform SDK, и содержит документацию, набор библиотек, утилит и других инструментальных средств для разработки.
WindowsAPIспроектирован для использования в языке Си для написания прикладных программ, предназначенных для работы под управлением операционной системы MS Windows. Работа через Windows API - это наиболее близкий к операционной системе способ взаимодействия с ней из прикладных программ. Более низкий уровень доступа, необходимый только для драйверов устройств, в текущих версиях Windows предоставляется через Windows Driver Model.
WindowsAPIпредставляет собой множество функций, структур данных и числовых констант, следующих соглашениям языка Си. Все языки программирования, способные вызывать такие функции и оперировать такими типами данных в программах, исполняемых в среде Windows, могут пользоваться этим API. В частности, это языки C++, Pascal, Visual Basic и многие другие.
Для облегчения программирования под Windows, в компании Microsoft и сторонними разработчиками было предпринято множество попыток создать библиотеки и среды программирования, частично или полностью скрывающие от программиста особенности Windows API, и предоставляющие ту или иную часть его возможностей в более удобном виде. Вчастности, сама Microsoft вразноевремяпредлагалабиблиотеки Active Template Library (ATL) /Windows Template Library (WTL), Microsoft Foundation Classes (MFC),.net/WinForms/WPF, TXLib. Компания Borland (ныне Embarcadero, её преемник в части средств разработки) предлагала OWL и VCL. Есть кросс-платформенные библиотеки, такие как Qt, Tk и многие другие. Весомая часть этих библиотек сконцентрирована на облегчении программирования графического интерфейса пользователя.
Для облегчения переноса на другие платформы программ, написанных с опорой на Windows API, сделана библиотека Wine.
1.7 Usermode-helper API
Вызовы конкретных функций ядра (системные вызовы) являются естественной частью разработки приложений на GNU/Linux. Но что относительно другого направления, когда вызов осуществляется из пространства ядра в пользовательское пространство? Оказывается, что есть ряд приложений, использующих эту возможность. Например, когда ядро обнаруживает устройство, для которого необходимо загрузить модуль, то как происходит этот процесс? Происходит динамическая загрузка модуля, которая выполняется из ядра в рамках процесса, называемого usermode-helper.
Интерфейс usermode-helper API представляет собой API ядра Linux с известным набором возможностей.
Например, чтобы создать процесс из пользовательского пространства обычно указываем имя исполняемого модуля и набор переменной среды. То же самое происходит при создании процесса из ядра. Но поскольку запускается процесс из пространства ядра, то есть ряд дополнительных возможностей.
В таблице 2 приведен базовый набор функций ядра, которые есть в usermode-helper API.
Таблица 2 - Базовые функции usermode-helper API
|
Функция API |
Описание |
|
|
call_usermodehelper_setup |
Подготовкаобработчика handler длявызовафункциипользовательскогопространства |
|
|
call_usermodehelper_setkeys |
Установкасессионныхключейдля helper |
|
|
call_usermodehelper_setcleanup |
Установкафункцииочистки cleanup для helper |
|
|
call_usermodehelper_stdinpipe |
Созданиеконвейера stdin для helper |
|
|
call_usermodehelper_exec |
Вызовфункциипользовательскогопространства |
В следующей таблице приведены несколько сокращенных функций, объединяющие функции ядра.
Таблица 3 - Сокращенные функции usermode-helper API
|
Функция API |
Описание |
|
|
call_usermodehelper |
Осуществляетвызовфункциипользовательскогопространства |
|
|
call_usermodehelper_pipe |
Осуществляетвызовфункциипользовательскогопространствасиспользованиемконвейера stdin |
|
|
call_usermodehelper_keys |
Осуществляетвызовфункциипользовательскогопространствасиспользованиемсессионныхключей |
Давайте сначала пройдемся по базовым функциям, а затем изучим возможности, которые предлагают сокращенные функции. Базовое API в своей работе использует ссылку на обработчик (handler), который является структурой subprocess_info. В этой структуре (которую можно найти в. /kernel/kmod. c) собраны все элементы, необходимые для данного экземпляра usermode-helper. Ссылка на структуру возвращается в вызове call_usermodehelper_setup. Дальнейшее конфигурирование структуры (и последующих вызовов) осуществляется с помощью вызовов call_usermodehelper_setkeys (работа с учетными данными), call_usermodehelper_setcleanup и call_usermodehelper_stdinpipe. Наконец, после того, как конфигурирование будет завершено, можно воспользоваться с помощью функции call_usermodehelper_exec вызвать сконфигурированное приложение, работающее в пользовательском режиме.
Базовые функции предоставят максимальную возможность управления, причем функции helper выполнят большую часть работы за один вызов. Вызовы, использующие конвейеры (call_usermodehelper_stdinpipe и функция call_usermodehelper_pipe из helper), создают соответствующий конвейер для использования его helper-ом. В частности, создается конвейер pipe (файловая структура в ядре). Приложение пользовательского пространства читает данные из pipe, а со стороны ядра осуществляется запись в pipe. А что касается записи, то выдача дампа памяти является единственным приложением, которое может использовать конвейер совместно с usermode-helper. В этом приложении (do_coredump () в. /fs/exec. c), выдача дампа памяти выполняет запись данных через конвейер из пространства ядра в пользовательское пространство.
Соотношение между этими функциями и sub_processinfo вместе с деталями структуры subprocess_info показано на Рисунке 3.
Рисунок 3 - Элементы интерфейса usermode-helper API.
Давайте теперь рассмотрим, где в ядре полезно использовать интерфейс программирования прикладного программного обеспечения usermode-helper API. В Таблице 4 приведен не исчерпывающий список приложений, использующих этот интернфейс, а лишь указаны некоторые интересные случаи применения.
Таблица 4 - Приложения, использующие usermode-helper API для вызовов из ядра.
|
Приложение |
Расположение исходного кода |
|
|
Загрузка модулей ядра |
. /kernel/kmod. c |
|
|
Управление питанием |
. /kernel/sys. c |
|
|
Управление группами |
. /kernel/cgroup. c |
|
|
Генерация ключей |
. /security/keys/request_key. c |
|
|
Передача событий в ядро |
. /lib/kobject_uevent. c |
Одним из наиболее ожидаемых применений usermode-helper API является загрузка модулей из пространства ядра. В функции request_module инкапсулирована функциональность usermode-helper API и предоставлен простой интерфейс. В обычных случаях ядро идентифицирует устройство или необходимую службу и делает вызов request_module, который осуществляет загрузку модуля. В случае использования usermode-helper API модуль загружается в ядро через modprobe (в пользовательском пространстве приложение вызывается с помощью request_module).
Аналогичной ситуацией, в которой загружаются модули, является "горячее" подключение устройств (добавление или удаление устройств во время работы системы). Эта возможность реализована с помощью usermode-helper API, вызывающего утилиту /sbin/hotplug, исполняемую в пользовательском пространстве.
Интересным приложением, использующим usermode-helper API (через request_module), является textsearch API (. /lib/textsearch. c). Это приложение обеспечивает в ядре реализацию настраиваемой инфраструктуры, предназначенной для текстового поиска. Это приложение использует usermode-helper API для динамической загрузки поисковых алгоритмов, реализованных в виде загружаемых модулей. В релизе ядра 2.6.30 поддерживается три алгоритма, в том число алгоритм Бойера-Мура (Boyer-Moor, смотрите в. /lib/ts_bm. c), нативного подхода с использованием автомата с конечным числом состояний (. /lib/ts_fsm. c) и, наконец, алгоритм Кнута-Морриса-Пратта (Knuth-Morris-Pratt, смотрите в. /lib/ts_kmp. cc).
Интерфейс usermode-helper API также используется в Linux для упорядоченного завершения работы системы. Когда необходимо отключить питание системы, ядро вызывает в пользовательском пространстве команду /sbin/poweroff, которая выполняет соответствующие действия. В таблице 4 приведен список других приложений и указывается место, где можно найти их исходный код.
Исходный код API для usermode-helper API можно найти в файле kernel/kmod. c (где проиллюстрировано его первоочередное использование в качестве используемого в ядре загрузчика модулей в пространство ядра). Основной объем работы в этой реализации выполняет функция kernel_execve. Обратите внимание, что kernel_execve является функцией, которая используется для запуска процесса init при загрузке системы и не использует usermode-helper API.
Реализация usermode-helper API довольно проста и очевидна (см. рис 2). Работа usermode-helper начинается с вызова функции call_usermodehelper_exec (которая используется для вызова приложения, предназначенного для работы в пользовательском пространсте, взятого из предварительно сконфигурированной структуры subprocess_info). Эта функция имеет два аргумента: ссылку на структуру subprocess_info и аргумент перечисляемого типа (определяющего ждать или не ждать, когда процесс будет запущен, и ждать или не ждать, когда процесс полностью завершится). Затем структура subprocess_info (или, точнее, элемент work_struct этой структуры) ставится в очередь в рабочую структуру (khelper_wq), которая выполняет асинхронный вызов.
Рисунок 4 - Внутренняя организация usermode-helper API.
Когда элемент помещается в khelper_wq, вызывается функция обработчика для очереди работ (в данном случае, __call_usermodehelper), которая исполняется внутри потока khelper. Эта функция начинается с удаления из очереди структуры subprocess_info, в которой содержится вся информация, необходимая для вызова из пользовательского пространства. Далее весь процесс зависит от значения переменной wait, имеющий перечисляемый тип. Если запрашиваемый процесс хочет ждать, пока весь данный процесс закончится, в том числе и вызовы, сделанные в пользовательском пространстве (UMH_WAIT_PROC) или вообще ничего не захочет ждать (UMH_NO_WAIT), то поток ядра создается из функции wait_for_helper. В противном случае, запрашиваемый процесс просто будет ждать, пока закончится вызов приложения в пользовательском пространстве (UMH_WAIT_EXEC), но не завершение приложения. В этом случае поток ядра создается для ____call_usermodehelper ().
В потоке wait_for_helper установлен обработчик сигнала SIGCHLD, а для ____call_usermodehelper создается другой поток ядра. Но в потоке wait_for_helper делается вызов sys_wait4, который дожидается окончания потока ядра ____call_usermodehelper (указывается сигналом SIGCHLD). Затем поток выполняет всю необходимую очистку (либо освобождая структуры для UMH_NO_WAIT, либо просто посылая уведомление о завершении в call_usermodehelper_exec ()).
Функция ____call_usermodehelper является именно тем местом, где выполняется фактическая работа по запуску приложения в пользовательском пространстве. Эта функция начинается с разблокирования всех сигналов и настройки службы хранения ключей. Она также устанавливает стандартный конвейер stdin (если это требуется). Затем, после еще некоторой минимальной инициализации приложение пользовательского пространства запускается с помощью вызова функции kernel_execve (из kernel/syscall. c), который включает в себя заранее заданный список path, argv (в том числе указывающий название приложения пользовательского пространства), а также настройку среды окружения. Когда этот процесс завершится, произойдет выход из потока с помощью обращения к функции do_exit ().
Этот процесс также используется при завершении Linux, что похоже на операцию с использованием семафоров. Когда вызывается функция call_usermodehelper_exec, делается объявление о завершении работы системы. После того, как структура subprocess_info помещается в khelper_wq, делается вызов функции wait_for_completion (использующую переменную completion, указывающую о завершении, в качестве своего единственного аргумента). Обратите внимание, что эта переменная, также хранится в структуре subprocess_info как поле complete. Когда дочерние потоки захотят обратиться к функции call_usermodehelper_exec, они вызовут метод ядра complete, возвращающий переменную completion в структуре subprocess_info. Этот вызов разблокирует функцию, так что она может быть продолжена. Вы можете узнать подробности реализации этого API в файле include/linux/completion. h.
1.8 Win32 API
Мы уже рассматривали API в операционных системах Microsoft Windows. Сейчас же мы взглянем на те же API, но уже с более практическим применением и с точки зрения разработчика приложений.
С помощью WinAPI можно создавать различные оконные процедуры, диалоговые окна, программы и даже игры. Эта, скажем так, библиотека является базовой в освоении программирования Windows Forms, MFC, потому что эти интерфейсы являются надстройками этой библиотеки.
И сразу оговоримся - в теоретической части мы не ставим задачи углублённого рассмотрение программного кода, а лишь демонстрируем его части для более наглядного примера применения. Практический пример будет находится в практической части.
Функции для работы с Win32 API находятся в библиотеки "windows. h".
Собственно, чтобы ими воспользоваться, необходимо подключить заголовочный файл, вот таким образом:
#include<windows. h>
После чего можно обращаться к API вызовам:
int APIENTRY WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance,
LPSTR lpCmdLine, int nCmdShow)
{
MessageBox (NULL, "Hello, Win32 API","WinAPI App", 0);
return 0;
}
На этом примере мы продемонстрировали способ запуска окна с сообщением "Hello, Win32 API" с применением API. Описанием функций:
HINSTANCEhInstance - дескриптор экземпляра приложения. Этот дескриптор содержит адрес начала кода программы в ее адресном пространстве. Дескриптор hInstance чаще всего требуется функциям, работающим с ресурсами программы.
HINSTANCEhPrevInstance - дескриптор предыдущего экземпляра приложения. Этот дескриптор остался от старых версий Windows - скорее всего, вам он никогда не пригодится.
LPSTRlpCmdLine - указатель на начало командной строки, введенной при запуске программы.
intnCmdShow - это значение содержит желаемый вид окна (например, свернутый или развернутый).
Значение, которое возвращается функцией WinMain (тип int) - код завершения программы. Принято, что если программа завершила свое выполнение без ошибок, возвращается 0.
Функция WinMain - первая функция, которая выполнятся в программе (ее еще называют "точка входа" или "entrypoint"). С нее все начинается, и ею (желательно) все должно закончиться.
На этом мы завершаем теоретическую часть дипломного проекта. Мы рассмотрели такие темы как архитектуры операционных систем, API с применением в системных вызовах, применение Win32 и Usermode-Helper API, затронули описания операционной системы CentOS, а также вызов API с помощью ядра Linux.
2. Практическая часть
2.1 Примечание к практической части
В практической части дипломного проекта мы затронем практическое применение API в двух операционных системах: CentOS и Microsoft Windows на примере разработки двух программ разных по целям, но схожим по задачам.
Реализация проектов будет выполнена с помощью языка C++ на компиляторе g++ на CentOS и Dev-C++ на Windows.
Также в теории достаточно подробно рассматривалась тема применения Usermode-Helper API и для наглядного примера мы реализуем приложение для работы с этой библиотекой.
Задачи для выполнения практической части условно можно обозначить как:
Реализация проекта на CentOS.
Реализация проекта на Microsoft Windows.
Сравнить особенности вызовов API, трудности использования и практическую пригодность.
Практически рассмотреть применение Web API на основе сервиса vk.com.
2.2 Пример использования usermode-helper API
Теперь давайте взглянем на простой пример использования usermode-helper API. Сначала рассмотрим стандартное API, а затем узнаем, как с помощью helper-функций это сделать еще проще.
Для этой демонстрации мы разработаем простой загружаемый модуль ядра, который вызывает API. Ниже в коде представлены функции модуля - заготовки, определяющие функции входа в модуль и выхода из модуля. Эти две функции вызываются по modprobe и insmod для модуля (функция входа в модуль) и по rmmod для модуля (выход из модуля).
#include <linux/module. h>
#include <linux/init. h>
#include <linux/kmod. h>
MODULE_LICENSE ("GPL");
static int __init mod_entry_func (void)
{
return umh_test ();
}
static void __exit mod_exit_func (void)
{
return;
}
module_init (mod_entry_func);
module_exit (mod_exit_func);
Использование usermode-helper API приведено в коде ниже, который мы изучим детально. Функция начинается с объявления целого ряда необходимых переменных и структур. Начинаем со структуры subprocess_info, которая содержит всю информацию, необходимую для выполнения вызова приложения пользовательского пространства. Этот вызов инициализируется, когда вызывается функцию call_usermodehelper_setup. Далее, определяем список аргументов, называемый argv. Этот список аналогичен списку argv, используемый в обычных программах на языке C, в нем указывается приложение (первый элемент массива) и список аргументов. Для того, чтобы указать конец списка, требуется завершающий элемент NULL. Обратите внимание, что неявно подразумевается использование переменной argc (счетчик аргументов), поскольку известна длина списка argv. В этом примере именем приложения будет /usr/bin/logger, а его аргументом - help!, за которым следует завершающий NULL. Следующей необходимой переменной является массив, описывающий среду окружения (envp). Этот массив имеет список параметров, которые определяют среду, в которой будет выполняться приложение пользовательского пространства. В этом примере, мы определяем несколько типичных параметров, которые задаются для шелл оболочки, а в конце ставим завершающий NULL.
static int umh_test (void)
{
struct subprocess_info *sub_info;
char *argv [] = { "/usr/bin/logger", "help!", NULL };
static char *envp [] = {
"HOME=/",
"TERM=linux",
"PATH=/sbin: /bin: /usr/sbin: /usr/bin", NULL };
sub_info = call_usermodehelper_setup (argv [0], argv, envp, GFP_ATOMIC);
if (sub_info == NULL) return - ENOMEM;
return call_usermodehelper_exec (sub_info, UMH_WAIT_PROC);
}
Далее обращаемся к call_usermodehelper_setup, для того чтобы создать нашу инициализированную структуру subprocess_info. Обратите внимание, что используется ранее инициализированные переменные и четвертый параметр, который указывает маску GFP для инициализации памяти. Из функции setup делается вызов kzalloc (в результате выделяется и обнуляется память ядра). Для этой функции требуется либо флаг GFP_ATOMIC, либо флаг GFP_KERNEL (первый определяет, что вызов не должен "засыпать", а второй - что "засыпать" можно). После быстрой проверки новой структуры (а именно, что она не NULL), переходим к вызову, который выполняется с помощью функции call_usermodehelper_exec. Эта функция использует вашу структуру subprocess_info, а по параметру перечисляемого типа определяется, следует ли ждать (описано внутри раздела). После загрузки модуля, мы должны увидеть сообщение в файле /var/log/messages.
Можно еще упростить этот процесс, если использовать функцию call_usermodehelper, которая одновременно выполняет функцию call_usermodehelper_setup и функцию call_usermodehelper_exec. Как видно из кода ниже, в результате не только удаляется функция, но и пропадает необходимость управлять структурой subprocess_info.
static int umh_test (void)
{
char *argv [] = { "/usr/bin/logger", "help!", NULL };
static char *envp [] = {
"HOME=/",
"TERM=linux",
"PATH=/sbin: /bin: /usr/sbin: /usr/bin", NULL };
return call_usermodehelper (argv [0], argv, envp, UMH_WAIT_PROC);
}
Стоит заметить, что в коде выше выполнены все те же требования по настройке и осуществлению вызова (такие как инициализация массивов argv и envp). Единственная разница состоит в том, что функция helper выполняет функции setup и exec.
Интерфейс usermode-helper API является важной особенностью ядра, если учитывать его повсеместное и разностороннее применение (от загрузки модулей ядра, "горячего" подключения устройств и даже работу с событиями udev). Хотя важно проверять приложения на соответствие API, понятно, что это важная особенность и, следовательно, будет полезным дополнением к инструментальным средствам ядра Linux.
2.3 Реализация проекта для работы с CDROM на CentOS
В качестве примера использования системных вызовов для работы с файлами устройств мы напишем программу, копирующую аудиоданные с audio-CD в wav - файлы (так называемый "риппер"). Файлы устройств, как известно, расположены в директории /dev/. В этой директории мы найдем и устройство /dev/cdrom, представляющее первый из установленных в вашей системе CD-приводов. Прежде, чем мы приступим к написанию программы-риппера, имеет смысл обратить внимание на врезку, посвященную устройству Audio CD.
Работа с CD-ROM с помощью устройства /dev/cdrom обычно выполняется по следующему сценарию: открытие файла устройства, настройка параметров с помощью ioctl (2), чтение (запись) данных, закрытие устройства. Полный текст программы можно найти в приложении к дипломному проекту, а тут мы рассмотрим только самые интересные части кода, имеющие отношение к управлению устройствами-файлами. Текст программы начинается с директив включения заголовочных файлов. Файлы unistd. h и sys/fcntl. h содержат функции для работы с системными вызовами. Заголовочный файл linux/cdrom. h содержит различные константы и макросы, используемые при работе с CD-ROM, но, увы, не содержит макросов, с помощью которых можно было бы преобразовать MSF во фреймы и обратно. Мы сами определяем соответствующие функции. Мы открываем файл устройства с помощью системного вызова open (2):
int cdd = open ("/dev/cdrom", O_RDONLY);
Флаг, переданный функции open, указывает, что файл открыт только для чтения. Дальнейший доступ к устройству будет выполняться с помощью полученного дескриптора cdd. В Linux каждый процесс может открыть не более 1048576 дескрипторов одновременно. Нашим программам этого будет вполне достаточно. Мы предполагаем, что устройство /dev/cdrom установлено в системе и работает правильно, однако, в общем случае неплохо проверить значение дескриптора, возвращенное open, на предмет ошибки (в этом случае функция возвращает - 1, переменная errno содержит дополнительный код ошибки).
Вызовы ioctl, связанные с воспроизведением Audio CD, приведены в таблице 5.
Таблица 5 - Вызовы ioctl, связанные с воспроизведением Audio CD.
|
Вызов |
Описание |
Дополнительныйпараметр |
|
|
CDROM_DRIVE_STATUS |
Получение данных о состоянии устройства |
константа CDSL_XXX |
|
|
CDROM_DISC_STATUS |
Получение данных о диске |
константа CDSL_XXX |
|
|
CDROMREADTOCHDR |
Чтение заголовка оглавления диска |
структура cdrom_tochdr |
|
|
CDROMREADTOCENTRY |
Чтение элемента оглавления диска |
структура cdrom_tocentry |
|
|
CDROMSUBCHNL |
Чтение данных о параметрах воспроизведения |
структура cdrom_subchnl |
|
|
CDROMPLAYTRKIND, CDROMPLAYMSF |
Воспроизведение аудиозаписи |
Структуры cdrom_ti и cdrom_msf |
|
|
CDROMSTOP |
Остановка воспроизведения |
значение 0 |
|
|
CDROMPAUSE, CDROMRESUME |
Приостановка, возобновление воспроизведения |
значение 0 |
|
|
CDROMEJECT |
Открытие лотка устройства |
значение 0 |
|
|
CDROMCLOSETRAY |
Закрытие лотка устройства |
значение 0 |
Результат запросов CDROM_DRIVE_STATUS и CDROM_DISC_STATUS возвращается не в параметре-ссылке, а как результат функции ioctl. В качестве третьего аргумента в этих запросах выступает одна из констант CDSL_XXX, определенных в файле cdrom. h. Эти константы предназначены для работы с устройствами автоматической смены компакт-дисков (CD changers). В случае "однодискового" устройства следует использовать CDSL_CURRENT. Результатом вызова CDROM_DRIVE_STATUS могут быть значения CDS_NO_DISC (нет диска в устройстве), CDS_DRIVE_NOT_READY (устройство не готово), CDS_DISC_OK (диск обнаружен), а также некоторые другие константы из файла cdrom. h. Среди значений, возвращаемых вызовом CDROM_DISC_STATUS, следует отметить CDS_NO_DISC (см. выше) CDS_AUDIO (диск опознан как аудио) и CDS_MIXED (диск опознан как "смешанный"). Остальные значения соответствуют не - аудиодискам. Нижеследующий фрагмент программы проверяет, готов ли CD - дисковод к передаче данных:
disc_stat = ioctl (cdd, CDROM_DRIVE_STATUS, CDSL_CURRENT);
if ( (disc_stat! = CDS_DISC_OK) && (disc_stat! = CDS_NO_INFO))
{ close (cdd);
printf ("Устройство не готово\n");
return 1;
}
Вызовы CDROMREADTOCHDR и CDROMREADTOCENTRY предназначены для работы с оглавлением диска. Вызов CDROMREADTOCHDR позволяет получить данные о номере первого и последнего информационных треков на диске, а вызов CDROMREADTOCENTRY - данные об отдельном треке: адрес начала трека (в формате MSF или LBA), тип трека (аудио или данные) и т.п. Вызов CDROMSUBCHNL позволяет получить информацию о текущем состоянии устройства - находится ли диск в режиме воспроизведения, и в какой позиции выполняется чтение данных. Строка программы ioctl (cdd, CDROMREADTOCHDR, &toc);
заполняет переменную toc типа cdrom_tochdr данными заголовка оглавления диска. Структура cdrom_tochdr позволяет нам узнать количество треков на диске.
Вызов
ioctl (cdd, CDROMREADTOCENTRY, &entry);
позволяет получить информацию о заданном треке. Дополнительный параметр вызова имеет тип "указатель на структуру cdrom_tocentry". Перед вызовом ioctl мы заполняем поля format (формат длительности трека) и track (номер трека) этой структуры. В этой же структуре системный вызов возвращает информацию о выбранном треке, в том числе тип трека (аудио или данные) и длительность трека. В файле cdrom. h определена константа CDROM_LEADOUT, указывающая на условный трек, расположенный после последнего трека.
Чтение данных трека выполняется с помощью вызова:
ioctl (cdd, CDROMREADAUDIO, &rdaudio);
где rdaudio - структура cdrom_read_audio.
Наша программа считывает данные CD и записывает их в файл формата wav. Строка вызова программы должна выглядеть так (исполнимый файл названии cdripper)
cdripper<трек><файл>
где трек - номер трека (первый трек, содержащий пользовательские данные имеет номер 1), файл - имя файла в котором будут сохранены аудиоданные в формате wav.
Принцип, согласно которому любой объект системы должен быть представлен в виде файла, приводит к тому, что даже дескрипторы файлов представлены в Linux в виде файлов. В директории /dev/fd можно увидеть файлы-ссылки с именами 0, 1, 2 и так далее. Эти файлы представляют дескрипторы файлов, открытых процессом, который читает директорию /dev/fd. Именно так, каждый процесс видит в этой директории только свои дескрипторы.
2.4 Реализация проекта на Win32 API
Для Microsoft Windows мы подготовили следующую задачу: отобразить информацию о жёстком диске.
Использовалась библиотека Win32 API windows. h, которая содержала в себе константы и методы для работы с HDD.
#include <windows. h>
#include <stdio. h>
Далее объявляются все переменные и массивы.
DWORD dwSectPerClust = 0, dwBytesPerSect = 0, dwNumbFreeClust = 0, dwTotalNumbOfClust = 0;
typedef struct DIOCRegs {
DWORD reg_EBX;
DWORD reg_EDX;
DWORD reg_ECX;
DWORD reg_EAX;
DWORD reg_EDI;
DWORD reg_ESI;
DWORD reg_Flags;
}
А затем с помощью printf выводится информация о жёстком диске, полученная с функций PrintInfoDrive, ReadSector и других.
Результат выполнения программы показан на рисунке 5, а программный код доступен в приложении к диплому.
Рисунок 5 - Результат выполнения программы.
2.5 Сравнение Linux и Windows
Обе операционные системы предназначены как для персональных систем, так и для web-серверов, вычислительных кластеров и т.п.
WindowsNTудалось завоевать первенство на настольных и персональных системах (около 97 % настольных компьютеров на данный, 2016 год.) тогда как решения на базе Linux популярны на веб-серверах, вычислительных кластерах, суперкомпьютерах и мобильных устройствах (50 - 90 %, 2010 - 2016 г.).
Эти системы разнятся в лежащей в основе их философии, стоимости приобретения и использования, простоте управления, удобстве и стабильности. При их сравнении приходится принимать во внимание корни, исторические факторы и способы распространения.
В 2015 году фирма Microsoft выпустила для внутреннего использования свой дистрибутив Линукс - Azure Cloud Switch (ACS), который можно описать как кроссплатформенную модульную операционную систему для управления дата-центрами.
Windows и Linux трудно сравнивать "на равных" из-за следующих факторов:
Исторически слово "Linux" означает ядро операционной системы. Операционные системы на основе ядра Linux, утилит проекта GNU исторически называют GNU/Linux, но в последнее время имя упрощают до "Linux", что не везде приветствуется.
Linux - это не определённая ОС, их более 600, среди них есть те, которые отличаются друг от друга значительно, а некоторые совсем немного.
И Windows, и Linux поставляются в различных конфигурациях. Особенно Linux, для которой существует огромное количество вариантов, некоторые из них предназначены для узкого круга задач.
Цена и широта технической поддержки различаются у разных поставщиков, а также в зависимости от версии и дистрибутива.
Производители оборудования могут устанавливать дополнительное ПО с операционной системой, которое делает доступные функции системы разнообразнее. Иногда они даже спонсируют продавца, снижая цену продукта для пользователя.
Данные, полученные от маркетинговых подразделений, и результаты тестирования могут расходиться.
Microsoft распространяет Windows под разными лицензиями (закрытыми). Дистрибутивы Linux, со своей стороны, могут содержать проприетарные компоненты.
В 2004 году компания Microsoft запустила маркетинговую кампанию под названием "GettheFacts", призванную обозначить преимущества Windows перед Linux. Было заявлено, что совокупная стоимость владения для Windows ниже, чем для продуктов с открытым кодом.
Выводы, сделанные Microsoft, оспаривают другие авторитетные организации, например, компания Novell и английский IT-сайт The Register. Некоторые полагают, что неточности в частности обусловлены тем, что в отчёте примешаны цифры по UNIX и Solaris, а кроме того, подсчитана стоимость профессиональной поддержки Linux (профессиональная поддержка может потребоваться при производстве ПО, но не при использовании системы).
Государственное агентство Великобритании по рекламе в 2004 г. предупредило Microsoft, что формулировка "стоимость владения Linux в 10 раз выше, чем стоимость владения Windows Server 2003" не соответствует истине, так как серверное оборудование, выбранное в сравнении для Linux (с операционной системой Red Hat Enterprise Linux AS v.3, в "комплектации" PremiumSubscription), было максимально дорогим, тогда как выбором для Windows была практически "голая" операционная система.
Ознакомление с популярностью данных операционных систем можно произвести с помощью таблицы 6.
Таблица 6 - Популярность операционных систем на ПК
|
Windows |
Linux |
Примечание |
||
|
Доля при продаже компьютеров (OEM) |
Предустанавливается без возможности выбора на 99 % персональных компьютеров, начиная с первой версии MS-DOS, по демпинговым ценам (цена для OEM ~30€, розница ~100€ в зависимости от версий). |
Предустанавливается на небольшое количество продаваемых систем. Например, Ubuntu на компьютеры Dell и System76, SUSE Linux на компьютерах марки Lenovo ThinkPads, MSI. В последнее время компания Google начала активно продвигать нетбуки и ноутбуки с предустановленной Google Chrome OS. Также на смартфоны, планшетные компьютеры, электронные книги, цифровые проигрыватели и другие устройства устанавливают операционную систему Android - основанную на ядре Linux. |
Во Франции против соглашения Microsoft с поставщиками компьютеров об установке исключительно Windows ведется судебное дело. |
|
|
Оконные менеджеры/графическая среда |
Изначально только системный оконный менеджер. Для изменения его работы требуется подмена системных файлов (uxtheme. dll), что прямо нарушает лицензионное соглашение, или использование программ независимых поставщиков (это утверждение верно только для Windows XP). Графическая оболочка необходима для работы подавляющего большинства программ, и её отказ ведет к нарушению их функционирования. Существует ряд программ, которые работают без использования графической оболочки, но служат они преимущественно для технического обслуживания системы (например, восстановления работоспособности). Удалённое управление с помощью Remote Desktop Protocol, telnet [23], WMI и других инструментов. Возможна установка сторонней среды рабочего стола, к примеру KDE, но и в этом случае библиотеки встроенного оконного менеджера загружаются в оперативную память, значительно снижая быстродействие системы. |
Среды рабочего стола: GNOME, KDE, Enlightenment, Xfce и другие. Множество "самостоятельных" оконных менеджеров: Openbox, Fluxbox, и другие, в том числе и композитные менеджеры окон Beryl, Compiz или Compiz Fusion. Графическая оболочка не критична для работы операционной системы, система может переключаться в текстовый режим. Удалённое управление осуществляется, обычно, через SSH, VNC и XDMCP. Используются "виртуальные терминалы", что позволяет избежать перезагрузки системы в случае отказа одного из терминалов. |
Разные среды рабочего стола предлагают разные способы управления компьютером, что позволяет пользователю выбрать полностью отвечающий его потребностям. Иногда это вызывает неудобства при переходе с одной на другую, но на практике большинство пользователей используют GNOME, KDE или похожие среды. |
|
|
Системная консоль/командная строка |
Командная строка существует, но обладает ограниченной функциональностью. Базируется на MS-DOS, наследуя её скромные возможности, мало изменившиеся с 1990-х годов. Разработан также мощный командный процессор Windows PowerShell, реализующий некоторые возможности командной строки UNIX, основанный на.net. Доступна независимая коллекция инструментов командной строки Cygwin и набор программ от Microsoft SUA, кроме этого есть CONEMU. Начиная с Windows 98 в поставку входит мощный инструмент для автоматизации задач - Windows Script Host, возможности которого значительно превосходят встроенную командную строку. Функции по восстановлению или настройке могут выполняться из командной строки. |
Командная строка также является неотъемлемой частью системы. Во многих ОС функции настройки системы реализованы при помощи графического интерфейса (иногда - работающего незаметно для пользователя с системой с помощью командной строки), но изза различия между вариантами не знакомые с конкретным дистрибутивом пользователи часто дают новичкам инструкции, ориентированные на командную строку. Командная строка позволяет опытному пользователю полностью перенастроить все функции ОС. Существует множество утилит для выполнения специализированных функций, тесно интегрированных с системными и прикладными программами. Функции по восстановлению или настройке могут выполняться из командной строки. Специальный слой абстракции "фреймбуффер" позволяет расширить функциональность "текстовых" терминалов до функциональности графического режима. |
Точно подсчитать количество пользователей затруднительно, так как почти все копии Linux не требуют регистрации, а Windows NT существует во множестве не авторизованных или незарегистрированных копий. Приведенные данные основаны на идентификационных откликах web-браузеров, поэтому цифры весьма приблизительны: разные сайты привлекают разные аудитории, а браузеры не всегда точно передают данные об операционной системе.
Исследование, опубликованное Relecantive AG в 2003 г., заключило, что "готовность Linux к использованию на настольной системе не ниже, чем Windows XP".
Подобные документы
Анализ серверных операционных систем на базе ядра Linux. Подходы к построению маршрутизации и оценка полученных результатов. Установка операционной системы CentOS 6.6 и закономерности ее настройки. Принципы и основные этапы тестирования созданного шлюза.
курсовая работа [2,9 M], добавлен 19.11.2015Основные понятия операционных систем. Современное оборудование компьютера. Преимущества и недостатки операционной системы Linux. Функциональные возможности операционной системы Knoppix. Сравнительная характеристика операционных систем Linux и Knoppix.
реферат [1,5 M], добавлен 17.12.2014Основные моменты истории операционных систем, связывающих аппаратное обеспечение и прикладные программы. Характеристика операционной системы Microsoft Windows Seven, анализ операционной системы Linux. Преимущества и недостатки каждой операционной системы.
курсовая работа [63,0 K], добавлен 07.05.2011Графические интерфейсы и расширения для DOS. История развития операционной системы Microsoft Windows. Новшества ее современных версий: пользовательский интерфейс, языковая интеграция, системы защиты. Хронология развития и архитектура системы GNU/Linux.
реферат [38,9 K], добавлен 25.10.2010Изучение общих понятий операционной системы Android, разработанной для коммуникаторов, планшетных компьютеров, основанной на ядре Linux. Разработка программного обеспечения Android. Преимущества и недостатки мобильной операционной системы Windows Mobile.
реферат [60,6 K], добавлен 16.04.2012Назначение команды "diskcomp". Текст и запуск командного файла. Сравнение команды в Windows 7 и Windows XP. Разработка файла-сценария в ОС Linux. Создание файла в подкаталоге. Создание файла "oglavlenie.txt" с отсортированным по времени списком файлов.
курсовая работа [1,6 M], добавлен 22.08.2012Схемы графической аутентификации, их реализация и внедрение в операционных системах Linux. Оценка вероятности взлома графического пароля. Буквенно-цифровые пароли. Схемы треугольника и подвижной рамки. Исследование удобства и простоты использования.
дипломная работа [5,1 M], добавлен 25.01.2013Разработка приложения, которое осуществляет удаленный доступ управления компьютером с операционной системой Linux с компьютера с ОС Windows. Реализация функциональной части. Графический интерфейс клиента и сервера. Разработка интеграционных тестов.
курсовая работа [1,1 M], добавлен 28.04.2014Назначение серверных операционных систем. Сравнительный анализ серверных операционных систем Windows и Linux и сравнение их по важным показателям таким как: пользовательский графический интерфейс, безопасность, стабильность работы, возможность и цена.
курсовая работа [50,1 K], добавлен 03.07.2012Основные сходства и отличия операционных систем Microsoft Windows и GNU/Linux: конфигурации, цена и широта технической поддержки; оценка стоимости владения и статистика использования на настольных компьютерах; простота инсталляции и наличие драйверов.
курсовая работа [294,9 K], добавлен 12.05.2011
