Реализация альтернативной API на примере CentOS

  • Вид работы:
    Дипломная (ВКР)
  • Предмет:
    Информационное обеспечение, программирование
  • Язык:
    Русский
    ,
    Формат файла:
    MS Word
    1,02 Мб
  • Опубликовано:
    2017-06-08
Вы можете узнать стоимость помощи в написании студенческой работы.
Помощь в написании работы, которую точно примут!

Реализация альтернативной API на примере CentOS

Министерство образования и науки Амурской области

Государственное профессиональное образовательное автономное учреждение Амурской области

"Амурский колледж строительства и жилищно-коммунального хозяйства"

Кафедра технических дисциплин

Дипломный проект

Тема: "Реализация альтернативной 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


Практическое применение 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_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");

{

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

Открытие лотка устройства

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 или похожие среды.

Системная консоль/командная строка

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



Точно подсчитать количество пользователей затруднительно, так как почти все копии Linux не требуют регистрации, а Windows NT существует во множестве не авторизованных или незарегистрированных копий. Приведенные данные основаны на идентификационных откликах web-браузеров, поэтому цифры весьма приблизительны: разные сайты привлекают разные аудитории, а браузеры не всегда точно передают данные об операционной системе.

Исследование, опубликованное Relecantive AG в 2003 г., заключило, что "готовность Linux к использованию на настольной системе не ниже, чем Windows XP".

Таблица 7 - Сравнение установки операционных системах

WindowsLinuxПримечание




Размер иснталлятора

Представляет стандартизированный набор программных средств и размер варьируется от нескольких десятков дискет (Windows 3.11) до DVD-диска (Windows Vista/7/8) и USB флеш драйва (Windows 10). Существуют как официальные так и неофициальные инструменты по созданию своих дистрибутивов Windows. Возможна установка через сеть.

От одной дискеты до нескольких DVD дисков. Например, дистрибутив DSL занимает всего 50 МБ, предоставляя браузеры, офисные приложения и т.д. Многие дистрибутивы распространяются в нескольких вариантах (как правило, DVD с большим набором программ и выбором графической среды или Live CD для каждой графической среды (KDE, GNOME, Xfce) с набором программ для неё). Возможна установка через сеть, при которой всё необходимое программное обеспечение будет получено со специального сервера. Эти варианты могут совмещаться, если есть постоянное соединение с интернетом: установка большинства пакетов происходит с диска, а их новые версии и дополнительные программы устанавливаются с удаленного сервера.


Простота установки

Windows 7, довольно проста в установке, если предполагается установка на машину без присутствующих операционных систем. Установка Windows XP, может быть затруднена в случае, если установленное оборудование использует новые технологии. Может понадобиться использование дискеты 3,5" с драйвером [27], или ручная упаковка более поздних обновлений к оригинальному дистрибутиву с созданием нового образа установочного диска.

Очень просты в установке (SuSE, Mandriva, Ubuntu, Fedora и др.), в процессе позволяет менять множество настроек, легко устанавливается к существующим операционным системам. Есть дистрибутивы с установкой ориентированной на максимальную подвижность, например сетевую удаленную установку при минимальном размере (40 Мебибайт) на слабой аппаратуре (Debian, Vector Linux, ArchLinux, Slackware). Есть дистрибутивы, намеренно отказывающиеся от простоты в пользу осознанной ручной установки, чтобы максимально расширить функциональность для пользователя (Gentoo, ArchLinux, Slackware). Непопулярные, новые или персональные дистрибутивы также могут отличаться. Кроме того, есть возможность целиком скомпоновать систему из исходных кодов, не прибегая к менеджерам установки программного обеспечения (Linux from Scratch).


Время установки

Заявленное время составляет около часа (вплоть до 10─30 минут для Windows Vista/7, в зависимости от мощности компьютера). В случае необходимости, подготовка к установке может занять дополнительное время (например, создание дискет с драйверами для установки Windows XP на SATA жёсткий диск). Во время установки необходимо будет выполнить одну или несколько перезагрузок. Установка важных обновлений может занять дополнительное время и потребовать несколько перезагрузок.

От пары минут до часа и более, в зависимости от объёма устанавливаемого программного обеспечения, поставляемого с дистрибутивом и мощности дисковой подсистемы компьютера. В среднем составляет 6─30 минут для распространённых дистрибутивов, таких, как OpenSUSE или Ubuntu. Компиляция полной системы из исходных кодов может быть выполнена, в зависимости от мощности компьютера, опыта пользователя, необходимого программного обеспечения за несколько минут, часов или дней.


Наличие драйверов

Драйверы некоторых устройств, использованных в системе, устанавливаются отдельно. Многие драйверы устанавливаются системой из набора драйверов на установочном носителе, некоторые недостающие драйверы можно получить через интернет с помощью средств системы. Процесс установки большинства драйверов автоматизирован. Оборудование, считающееся по каким-либо причинам устаревшим, не поддерживается разработчиками этого оборудования, в результате чего для него отсутствуют драйверы, поскольку для разных ОС Windows требуются различные драйверы устройств. На практике, для неинтегрированных устройств почти всегда приходится устанавливать драйверы отдельно. Это требует времени и дополнительных перезагрузок. Производители встроенного оборудования стараются создавать свои новые продукты, чтобы они без проблем работали даже на старых, но популярных Windows (напр. XP), в которых драйверов на это устройство быть не может, но есть драйверы более старых устройств, которые оказываются подходящими благодаря разработчикам устройств.

Большинство драйверов устанавливается автоматически при инсталляции операционной системы или доступно для загрузки через интернет. Множество драйверов уже включено в ядро. Производители некоторых устройств (ТВ-тюнеров и др.) иногда не выпускают драйверы для Linux, поэтому устройства могут оказаться неработоспособными (в этом случае могут помочь драйверы открытого сообщества для систем на одном чипе SoC). Применение некоторых драйверов требует принятия лицензионного соглашения. Некоторые драйверы (беспроводные карты) могут поставляться только в закрытом виде. Возможно использование Windows-драйверов для некоторых из устройств. На непопулярных системах, или на системах в которых отсутствуют правила добавления конкретного устройства, может потребоваться скачивать и устанавливать драйвера вручную. Если в системе нет системы управления пакетами (популярные RPM, APT), то драйверы требуется устанавливать средствами, предоставленными их разработчиком.


Инсталляция с помощью ознакомительного CD (Live CD)

Официальных свободно-распространяемых ознакомительных CD не существует. Но можно специально создать работающую систему в облегченном варианте на диске (WinPE) с диска или флеш-накопителя или с помощью специально созданного загрузочного диска (BartPE). До выхода Vista, Windows PE распространялся только среди поставщиков компьютеров в виде "OEMPreinstallationKit", в настоящее время его можно бесплатно скачать с официального сайта Microsoft в составе Windows Automated Installation Kit.

Многие полноценные дистрибутивы (Knoppix, openSUSE, Ubuntu) имеют ознакомительный диск (live CD). С помощью таких дисков можно осуществлять восстановление работоспособности системы, в том числе с другой операционной системой. Также многие live-CD предоставляют возможность установки ОС на компьютер с этого же диска.


Поставляемое программное обеспечение

Несколькопрограммдляработысмультимедиаисетьюинтернет (браузер Internet Explorer, проигрыватель Windows Media Player, текстовыередакторы Notepad, WordPad, графическийредактор Paint), почтовыйклиент Outlook Express. Дополнительное ПО может быть включено производителем оборудования. Windows Vista включает в себя также почтовую программу Windows Mail, мультимедиа-центр Windows Media Center и др., в зависимости от версии. Офисный пакет Microsoft Office не включается в поставку (кроме Windows RT), так как является отдельным коммерческим продуктом, но иногда может быть включена ознакомительная версия. На практике без установки дополнительных компонентов Windows Media Player не может воспроизводить видео, а встроенная в Windows XP (SP1) программа записи дисков не может записывать DVD и сильно ограничена в функционале. Кроме того, в системе отсутствуют средства работы с архивами, отличными от. zip и. cab

Во всех основных дистрибутивах присутствует множество программ для самых разных задач: мультимедиа, графики, интернета, офисной работы, игр, а также системные утилиты и дополнительные визуальные оболочки. Однако из-за недостаточной открытости форматов файлов собственнических продуктов для Microsoft Windows существует ряд проблем с совместимостью форматов файлов между такими продуктами и свободными приложениями. Например, сложный текст, созданный в OpenOffice.org, и сохранённый в собственническом формате Microsoft Office, не всегда корректно читается в Microsoft Office; и наоборот, OOo не всегда может точно декодировать форматы Microsoft Office. Существуют специализированные дистрибутивы. В них набор программ скорректирован в сторону решаемых задач, например Ubuntu Studio, Edubuntu, BackTrack. Единообразие (в рамках системы управления пакетами) позволяет очень гибко настраивать список устанавливаемого ПО, а в случае подключения к репозиторию - так же установить дополнительное ПО во время установки ОС.

Практика совместной поставки компанией Microsoft программ вместе с Windows была признана в США незаконной.

Программы, которые можно установить дополнительно

Огромный выбор собственнических и свободно распространяемых программ (Однако нет централизованного хранилища необходимого для работы свободного программного обеспечения, поддерживаемого производителем ОС). Как правило, они поставляются со всеми необходимыми библиотеками, устанавливаются с помощью специальной программы-инсталлятора. Хотя в windows есть собственная система установки/удаления программ, многие программы устанавливаются уникальными инсталляторами. Деинсталляция тоже проста, хотя программы удаления зачастую оставляют глобальные пометки (например, для ограничения срока работы), а иногда - и бинарные файлы (например, библиотеки). Отсутствие централизованного хранилища и общее правило включать в дистрибутив все необходимые библиотеки может приводить к конфликтам, когда одна прикладная программа перезаписывает общую библиотеку другой программы (например, на библиотеку другой версии); такие конфликты часто называются dll hell. Имеется возможность установки некоторых простых программ путём простого копирования файлов в системную директорию (бинарный формат файлов). Некоторые программы могут работать только на определённых версиях ОС.

Большой выбор свободно распространяемых программ и небольшой выбор коммерческих. Однако для ряда задач приложений гораздо меньше, чем для Windows, или они отсутствуют. Созданы версии некоторых Win32-программ для Linux. Программы, включенные в официальные дистрибутивы и их репозитории, устанавливаются в большинстве вариантов с помощью специальной программы для установки/удаления программ, обеспечивающей наличие необходимых библиотек (система управления пакетами), либо ручной компиляцией из исходных кодов с поиском необходимых библиотек (в случае редких программ - например, устаревших или находящихся на ранней стадии разработки). Применяется несколько специальных упаковочных форматов (RPM, DEB), позволяющих распространять программы в пакетах для разных дистрибутивов. При инсталляции ПОв пакете часто может требоваться инсталляция других пакетов, которые устанавливаются автоматически, либо их можно скачать из Интернета. Это используется для того, чтобы избежать конфликта библиотек (dll hell): две программы могут использовать один и тот же пакет, а операционная система самостоятельно заботится о том, чтобы поддерживать актуальность его версии. Дополнительным преимуществом такого подхода можно считать то, что в совокупности размер пакетов, требуемых для установки программы для Linux меньше, чем размер дистрибутива той же программы для Windows. Ряд программ (в основном собственнические или не очень популярные) может инсталлироваться только на одну или некоторые из версий ядра и дистрибутива. Некоторые программы должны устанавливаться пользователем самостоятельно, либо из исходных кодов, иногда с применением командной строки.

Для Linux разработаны и другие инсталляторы, такие как loki installer, klik или autopackage. Однако до сих пор они малораспространены.

Подготовка диска

По умолчанию устанавливает только себя, затирая возможность запуска других ОС, кроме других инсталляций Windows. Разделы с "родной" файловой системой NTFS легко могут быть расширены и уменьшены (под Vista/7 уменьшить размер раздела можно системными средствами, под XP - только с помощью программ сторонних производителей). При этом графическая программа для этой задачи обладает меньшим функционалом, чем утилита командной строки. Возможно динамическое разделение диска (Dynamic Disks).

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


Программа-загрузчик

При установке автоматически настраивается для загрузки других имеющихся на компьютере инсталляций систем семейства Windows NT/9x (NTLDR), для загрузки Linux и других подобных систем необходимо ручное редактирование файла BOOT. INI. Также возможно применение сторонних загрузчиков, таких как GRUB.

Может загружать операционные системы по выбору пользователя с помощью встроенных менеджеров GRUB или LILO. Также имеются средства безопасности (например запрос пароля), которых нет в загрузчике Windows.

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


Установка Linux когда-то была затруднительной для среднего пользователя. В настоящее время почти все дистрибутивы содержат упрощённую процедуру установки и демонстрационный диск (Live CD), который дает возможность загрузить систему прямо с CD или DVD и пользоваться ей, не устанавливая на жёсткий диск.

Установщик Windows тоже включает в себя программу-помощника (wizard), как и дистрибутивы Linux.

Особенности Linux, а именно: открытость, изначальное предпочтение открытых программных компонентов закрытым, нестандартность поставки (огромное количество дистрибутивов со своими особенностями), центральные безопасные источники программ, наличие бита выполнения, исходный запрет на работу под пользователем root, наличие средств ограничения прав (SELinux, AppArmor) - делают возможным только точечное, намеренное заражение и исключают возможность масштабной жизнедеятельности вредоносных программных кодов. Количество вирусов под Linux исчисляется несколькими десятками (обычно разработанными в учебных целях), так как открытость ядра позволила закрыть большинство уязвимостей в нём. Число вредоносных программ вообще, написанных под Linux, включая вирусы и трояны, выросло в последние годы, и более чем удвоилось в течение 2005 от 422 до 863, однако открытая модель разработки приводит к тому, что большинство данных программ в настоящее время неработоспособно - уязвимости, которыми они пользовались, как правило, закрываются в течение нескольких дней после обнаружения. Справедливости ради надо заметить, что некоторые открытые программы со сложным кодом всё-таки содержат уязвимости, которые долгое время были не обнаруженными. Например, Heartbleed был обнаружен только спустя два года.

Для Microsoft Windows создано очень большое число вирусов и деструктивных программ (их количество исчисляется десятками миллионов. Для борьбы с ними используется специальное программное обеспечение - антивирусы. Вирусы бывают разных видов: от сравнительно безобидных не приносящих особого вреда пользователю, до деструктивных, которые изменяют настройки системы, уничтожают важные данные пользователя или похищают банковские данные. В линейке Windows NT всегда присутствовало чёткое разделение пользовательских прав. Тем не менее, большинство пользователей домашних компьютеров всегда использует права администратора, что негативно сказывается на защищённости системы. С появлением Windows Vista, эта проблема была частично решена при помощи комплекса технологий User Account Control: теперь Windows в явном виде запрашивает подтверждение действий, требующих прав администратора, даже если пользователь является администратором.

В Linux (как и во всех других UNIX-подобных системах) всегда присутствовало чёткое разделение пользовательских прав. Имеется только одна учётная запись системного администратора ("суперпользователя") - root. Этот пользователь может выполнять ничем не ограниченные действия над системой: изменять настройки, устанавливать и удалять программы, изменять системные файлы, останавливать отдельные компоненты или всю систему, и даже полностью удалить её одной командой. Также имеются учётные записи обычных пользователей: они могут только изменять личные настройки (внешний вид, настройки программ), и выполнять операции с файлами только в пределах своего домашнего каталога (или в других каталогах, если разрешит root). Обычному пользователю разрешено устанавливать программы только в свой домашний каталог или в те каталоги, где у него есть разрешение на запись данных. В большинстве современных дистрибутивов Linux работа непосредственно из-под учётной записи root невозможна; пользователь всегда работает с ограниченными правами, запуск же учётной записи root производится только для выполнения отдельных действий, и для каждого такого запуска требуется ввод пароля root (su) или текущего пользователя (sudo) для подтверждения полномочий. Запуск учётной записи root производится только в том случае, если текущий пользователь имеет права на администрирование системы, и правильно ввёл свой пароль; этот же механизм взаимодействия с пользователем Microsoft чуть позже заимствовала для Windows в рамках технологии "UserAccountControl". Антивирусы, существующие под Linux [проприетарные (Dr. Web, Антивирус Касперского, avast! и др.) и свободные (ClamAV)], предназначены для проверки и защиты Windows. Они позволяют сканировать сетевой трафик на шлюзах, почтовых серверах, файлсерверах, проверять выбранные отдельные файлы, каталоги, сменные и другие носители, по желанию пользователя, при обращениях на чтение/запись файлов, по расписанию, с графической оболочкой или без таковой.

В Linux намного меньше уязвимостей из-за чего он часто используется там, где нужна секретность данных (правительственные организации, банки).

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

Для Microsoft Windows из-за монопольной позиции и результирующего большого процента рынка постоянно выпускается огромное количество игр разных жанров. Распространяются в большинстве своём за оплату, но есть и бесплатные казуальные игры. Большое количество игр также объясняется тем, что Windows - наиболее популярная операционная система на настольных компьютерах. Для написания трёхмерных игр для Windows обычно используются API DirectX и XNA (реже OpenGL).

Для Linux существует меньше игр, но эта ситуация постепенно улучшается. Основной причиной является малый процент рыночного сегмента. В большинстве своём это также свободное программное обеспечение, однако и здесь встречаются проприетарные игры (в основном это игры, портированные из Windows). Наиболее популярными жанрами здесь являются казуальные игры, шутеры от первого лица (в основном они написаны на свободных движках Quake, например Tremulous, Xonotic, Nexuiz, Urban Terror, Warsow, или же это портированные из Windows игры), а также стратегии.

Для написания трёхмерных игр здесь используется только интерфейс OpenGL, так как DirectX является проприетарным ПО и официально существует только в версиях для платформ Microsoft (Windows, Xbox, Zune и других). Проекты Wine и Cedega предоставляют реализацию DirectX в связке с реализацией среды Win32 API с довольно хорошей, но не идеальной, совместимостью. Несмотря на это после выхода интернет магазина Windows Store в Windows 8 корпорация Valve заявила о том, что Windows 8 является катастрофой в "PC-пространстве" и что Linux является наиболее жизнеспособной платформой для разработки игр, нежели Windows, в связи с чем уже выпустила версию клиента Steam для операционной системы Ubuntu.

Как заявил в своем интервью Гейб Ньюэлл, глава Valve: "Мы хотим, чтобы все 2500 игр в Steam легко шли под Linux." В настоящий момент портирована часть из них, в том числе Dota 2, Counter-Strike 1.6, Counter-Strike: Source, Serious Sam 3 и другие.

После этого заявления компания System76 выпустила мощный игровой ноутбук с предустановленной операционной системой Ubuntu 12.04 в надежде на успешность проекта Valve.

Заключение


На основании проделанной работы мы изучили исторический аспект развития операционных систем, рассмотрели строение API в операционных системах Linux и Microsoft Windows, провели анализ реализации API самого ядра Linux и успешно реализовали 2 проекта на языке программирования C++ с применением API Linux и Windows.

Таким образом, задачи, поставленные в техническом задании выполнены.

Список литературы


1.      В. Костромин, Свободная система для свободных людей, март 2012 г.

2.      В. Костромин, Linux для пользователя, 2014 г.

.        Соловьев Алексей, Разработка модулей ядра ОС Linux, 2014 г.

.        Даниэл Дж. Баррет, Linux основные команды карманный справочник, 2013 г.

.        А. Чекмарев, Windows 7: Руководство администратора, 2015 г.

.        М. Руссинович, Внутреннее устройство Microsoft Windows, 2012 г.

.        Ричард Саймон, Microsoft Windows API, Справочник системного программиста, 2013 г.

.        Брюс Эккель, Философия C++. Практическое программирование, 2013 г.

.        Стенли Липпман, Жози Лажойе, Барбара Э. Му, Язык программирования C++. Вводный курс, 2012 г.

.        Стенли Липпман, Основы программирования на С++, Том 1, 2016 г.

.        Стенли Липпман, Основы программирования на С++, Том 2, 2016 г.

.        Скотт Мейерс, 55 верных советов улучшить структуру и код ваших программ, 2012 г.

.        Герб Саттер, Решение сложных задач на С++, 2012 г.

.        Андрей Александреску, Современное проектирование на C++, 2014 г.

.        Герб Саттер, Андрей Александреску, Стандарты программирования на C++, 2016 г.

.        Бен Клеменс, Программирования на C в 21 веке, 2017 г.

.        Электронные источники:

18.    https: // ru. wikipedia.org/wiki/Linux <https://ru.wikipedia.org/wiki/Linux>

19.    https: // ru. wikipedia.org/wiki/Windows <https://ru.wikipedia.org/wiki/Windows>

20.    https: // ru. wikipedia.org/wiki/API <https://ru.wikipedia.org/wiki/API>

21.    https: // ru. wikipedia.org/wiki/%D0%AF%D0%B4%D1%80%D0%BE_Linux <https://ru.wikipedia.org/wiki/Ядро_Linux>

.        https: // www.centos.org/ <https://www.centos.org/>

.        https: // ru. wikipedia.org/wiki/%D0%A1%D1%80%D0%B0%D0%B2%D0%BD%D0%B5%D0%BD%D0%B8%D0%B5_Microsoft_Windows_NT_%D0%B8_Linux <https://ru.wikipedia.org/wiki/Сравнение_Microsoft_Windows_NT_и_Linux>

25.    http://ru. d-ws. biz/articles/WinOrLin. shtml <http://ru.d-ws.biz/articles/WinOrLin.shtml>

26.    <http://citforum.ru/programming/unix/ipc_intro/>

27.    <http://citforum.ru/programming/unix/linux_api/>

28.    https: // en. wikipedia.org/wiki/Linux_kernel_interfaces <https://en.wikipedia.org/wiki/Linux_kernel_interfaces>

29.    https: // www.ibm.com/developerworks/ru/library/linux_windows_13/ <https://www.ibm.com/developerworks/ru/library/linux_windows_13/>

30.    https: // github.com/ <https://github.com/>

.        https: // ru. wikipedia.org/wiki/CentOS <https://ru.wikipedia.org/wiki/CentOS>

32.    https: // ru. wikipedia.org/wiki/Windows_7 <https://ru.wikipedia.org/wiki/Windows_7>

33.    https: // gcc. gnu.org <https://gcc.gnu.org/>

.        https: // ru. wikipedia.org/wiki/G%2B%2B <https://ru.wikipedia.org/wiki/G%2B%2B>

35.    https: // www.visualstudio.com/ru/downloads/ <https://www.visualstudio.com/ru/downloads/>

36.    https: // stackoverflow.com/questions/2171177/what-is-application-binary-interface-abi <https://stackoverflow.com/questions/2171177/what-is-application-binary-interface-abi>

Приложение А


Код программы для работы с CD-ROM

#include <stdio. h>

#include <unistd. h>

#include <sys/fcntl. h>

#include <linux/cdrom. h>

#define BUF_SIZE 75*2352struct wav_header {riff [4];filesize;rifftype [4];chunk_id1 [4];chunksize1;wFormatTag;nChannels;nSamplesPerSec;nAvgBytesPerSec;nBlockAlign;wBitsPerSample;chunk_id2 [4];chunksize2;

} wav_header;msf_to_frames (struct cdrom_msf0 * msf) {(msf->minute * 60 + msf->second) * 75 + msf->frame;

}frames_to_msf (int frames, struct cdrom_msf0 * msf) {>frame = frames % 75;>second = (frames / 75) % 60;>minute = (frames / 75) / 60;

}main (int argc, char ** argv) {cdd, fd, track, start, stop, disc_stat;buf [BUF_SIZE];cdrom_tochdr toc;cdrom_tocentry entry;cdrom_read_audio rdaudio;wav_header hdr;(argc! = 3) {

printf ("Использование: %s <трек><аудиофайл>\n", argv [0]);

return 1;

}= open ("/dev/cdrom", O_RDONLY);= atoi (argv [1]);_stat = ioctl (cdd, CDROM_DRIVE_STATUS, CDSL_CURRENT);( (disc_stat! = CDS_DISC_OK) && (disc_stat! = CDS_NO_INFO) && (disc_stat! = - 1))

{(cdd);("Устройство не готово\n");1;

}(cdd, CDROMREADTOCHDR, &toc);( (track < toc. cdth_trk0) || (track > toc. cdth_trk1)) { (cdd);

printf ("Неверный номер трека\n");

return 1;

}. cdte_format = CDROM_MSF;. cdte_track = track;(cdd, CDROMREADTOCENTRY, &entry);( (entry. cdte_ctrl & CDROM_DATA_TRACK)! = 0) {

close (cdd);

printf ("Выбран не аудио-трек\n");

return 1;

}= msf_to_frames (&entry. cdte_addr. msf);. cdte_track = (track < toc. cdth_trk1)? track + 1: CDROM_LEADOUT;(cdd, CDROMREADTOCENTRY, &entry);= msf_to_frames (&entry. cdte_addr. msf);= open (argv [2], O_WRONLY|O_CREAT, 0777);(hdr. riff, (const void *)"RIFF",

);(hdr. rifftype, (const void *)"WAVE",

);(hdr. chunk_id1, (const void *)"fmt ",

);. chunksize1 = 16;. wFormatTag = 1; // WAVE_FORMAT_PCM;(hdr. chunk_id2, (const void *)"data",

);. nChannels = 2;. nSamplesPerSec = 44100;. nBlockAlign = 4;. nAvgBytesPerSec = 44100 * hdr. nBlockAlign;. wBitsPerSample = 16;. chunksize2 = (stop-start) *2352;. filesize = hdr. chunksize2 + 44;(fd, &hdr, sizeof (hdr));. addr_format = CDROM_MSF;. buf = buf;(start < stop) {_to_msf (start, &rdaudio. addr. msf);+= (rdaudio. nframes = (stop - start) > 75? 75: stop - start);(cdd, CDROMREADAUDIO, &rdaudio);(fd, buf, rdaudio. nframes*2352);

}(cdd);(fd);

}

Приложение Б


Код программы дляполучение информации с жёсткого диска

#include <windows. h>

#include <stdio. h>dwSectPerClust = 0, dwBytesPerSect = 0, dwNumbFreeClust = 0, dwTotalNumbOfClust = 0;struct DIOCRegs {reg_EBX;reg_EDX;reg_ECX;reg_EAX;reg_EDI;reg_ESI;reg_Flags;

} DIOC_REGISTERS;PrintError ()

{str [256];lpMsgBuf;(_MESSAGE_ALLOCATE_BUFFER |_MESSAGE_FROM_SYSTEM |_MESSAGE_IGNORE_INSERTS,,(),(LANG_NEUTRAL, SUBLANG_DEFAULT),

(LPTSTR) &lpMsgBuf,

,NULL

);( (LPCSTR) lpMsgBuf, str);("%s\n", str);

}PrintInfoDrive (LPCSTR lpDriveName = "c: \\")

{(,

&dwSectPerClust,

&dwBytesPerSect,

&dwNumbFreeClust,

&dwTotalNumbOfClust

);("Drive name: %s\n", lpDriveName);("SectorsPerClustre: %d\n", dwSectPerClust);("BytesPerSector: %d\n", dwBytesPerSect);("NumberFreeOfCluster: %d\n", dwNumbFreeClust);("TotalNumberOfCluster: %d\n",dwTotalNumbOfClust);("------------------------------------\n");dwTotalSize = dwBytesPerSect * dwNumbFreeClust;("Free space: %d kb\n", (dwTotalSize/1024));

}ReadSector (UINT sector, LPCSTR lpDriveName = "\\\\. \\C: ")

{verInfo = {0};. dwOSVersionInfoSize = sizeof (verInfo);(&verInfo);hDrive;*buf;dw, n;(verInfo. dwPlatformId)

{VER_PLATFORM_WIN32_NT:= CreateFile (,_READ,_SHARE_READ,,_EXISTING,_ATTRIBUTE_NORMAL,

);(hDrive == INVALID_HANDLE_VALUE)

{();1;

}= new char [dwBytesPerSect];(hDrive, (sector-1) * dwBytesPerSect, NULL, FILE_BEGIN); // c 1(hDrive, (LPVOID) buf, dwBytesPerSect, &dw, NULL);(hDrive);(n = 0; n < dw; n++)("%c", buf [n]);[] buf;;VER_PLATFORM_WIN32_WINDOWS:;:("Error!!! \n");1;

}0;

}main ()

{();("------------------------------------\n");(20);0;

}

Похожие работы на - Реализация альтернативной API на примере CentOS

 

Не нашли материал для своей работы?
Поможем написать уникальную работу
Без плагиата!