Введение

Последние 10 лет Windows – самая популярная (91,02% ) операционная система на рынке персональных компьютеров. Операционные системы Windows работают на платформах x86, AMD64, IA-64. Существовали также версии для DEC Alpha, MIPSи PowerPC.

Семейство Windows NT:

Операционные системы этого семейства работали на процессорах с архитектурой IA-32 и некоторых RISC-процессорах: Alpha, MIPS, Power PC (до версии 2000, которая вышла только в версии для IA-32). Windows NT являются полностью 32-битными операционными системами, и, в отличие от версий 1.0–3.x и 9x, не нуждаются в поддержке со стороны MS-DOS.

Windows NT 3.1 (1993)

Windows NT 3.5 (1994)

Windows NT 3.51 (1995)

Windows NT 4.0 (1996)

Windows 2000 (2000) – Windows NT 5.0

Windows XP (2001) – Windows NT 5.1

Windows XP 64-bit Edition (2006) – Windows NT 5.2

Windows Server 2003 (2003) – Windows NT 5.2

Windows Vista (2006) – Windows NT 6.0

Windows Home Server (2007)

Windows Server 2008

Windows 7 (2009) – Windows NT 7.0 (Актуальная версия – 6.1)

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

Семейство Windows NT относится к операционным системам с вытесняющей многозадачностью, а не к операционным системам реального времени. Разделение процессорного времени между потоками происходит по принципу «карусели». Ядро операционной системы выделяет квант времени (в Windows 2000 квант равен примерно 20 мс) каждому из потоков по очереди при условии, что все потоки имеют одинаковый приоритет. Поток может отказаться от выделенного ему кванта времени. В этом случае, система перехватывает у него управление (даже если выделенный квант времени не закончен) и передаёт управление другому потоку. При передаче управления другому потоку система сохраняет состояние всех регистров процессора в особой структуре в оперативной памяти. Эта структура называется контекстом потока. Сохранение контекста потока достаточно для последующего возобновления его работы.

API (Application Programming Interface – интерфейс прикладных программ) – это множество функций, организованных, обычно, в виде DLL. Функции API позволяют организовать интерфейс между прикладной программой и средой, в которой работает эта программа. Вызов функций API позволяет программе получать доступ к ресурсам среды и управлять ее работой. Как правило, API задает стандарт взаимодействия среды и прикладной программы.

Win32 – это название интерфейса, ориентированного на 32-х разрядные приложения и реализованного на таких известных платформах как Windows 95, Windows 98, Windows NT, Windows CE. Функции, составляющие этот интерфейс, позволяют прикладной программе получать доступ к ресурсам операционной системы и управлять ее работой. Более ранние версии Windows используют интерфейс, известный как Win16. Конечно, не все функции, составляющие интерфейс Win32, реализованы в полной мере на всех платформах, так что вызов одной и той же функции под NT приведет к определенному результату, а под Windows 95 работает как вызов заглушки. Любое из приложений, работающее в среде Windows, прямо или косвенно вызывает функции, входящие в Win32 API.

Функции, составляющие Win32 интерфейс, организованы в виде нескольких динамически подключаемых библиотек (DLL) и исполняемых файлов.

API функции не обязательно входят в состав Win32 интерфейса. Например, MAPI интерфейс (Messaging Application Programming Interface) составляют функции, предназначенные для обработки сообщений электронной почты, TAPI (Telephone API) – функции работы с телефонными сообщениями. MAPI, TAPI, также как и Win32 это некоторый набор функций, задающий определенный стандарт взаимодействия

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

1. Теоретическая часть

1.1 Возможности Win32 для нахождения списка запущенных процессов

программа алгоритм библиотека пользователь

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

1. Рассмотрим следующие методы:

2. С помощью библиотеки Process Status Helper (PSAPI)

3. С помощью ToolHelp32 API

4. С помощью недокументированной функции ZwQuerySystemInformation

5. Через счетчики производительности

6. С использованием интерфейсов Windows Management Instrumentation

7. Функции интерфейса сокетов

1.2 Использование библиотеки Process Status Helper

Библиотека Process Status Helper, известная также под названием PSAPI, предоставляет набор функций, позволяющих получить информацию о процессах и драйверах устройств. Библиотека поставляется в составе Windows 2000/XP и доступна в качестве устанавливаемой компоненты для Windows NT 4.0.

Для перечисления процессов библиотека предоставляет функцию EnumProcesses, которая возвращает массив идентификаторов запущенных процессов. Ниже приведен текст функции EnumProcesses_PsApi, реализующей перечисление процессов с помощью PSAPI.

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

Поскольку мы хотим помимо идентификаторов процессов получить и имена процессов, мы должны проделать дополнительную работу. Для каждого процесса мы сначала получаем его описатель (handle) c помощью функции OpenProcess и затем используем функцию ЕnumProcessModules, которая возвращает список модулей, загруженных в адресное пространство процесса. Первым модулем в списке всегда является модуль, соответсвующий EXE-файлу программы. Наконец, мы вызываем функцию GetModuleFileNameEx (которая также является частью PSAPI), чтобы получить путь к EXE-файлу по описателю модуля. Мы используем имя EXE-файла без пути в качестве имени процесса.

Нужно обратить внимание на специальную обработку для двух процессов. Мы вынуждены обрабатывать отдельно процесс бездействия системы (Idle) с идентификатором 0, и системный процесс (System), который имеет идентификатор 2 на Windows NT 4 и 8 – на Windows 2000/XP, потому что OpenProcess не позволяет открыть описатель для этих процессов, возвращая код ошибки ERROR_ACCESS_DENIED.

RTOS складається з ядра, планувальника процесів (process manager) і розширених сервісів на рівні користувача. Як справжня мікроядерного операційна система, QNX Neutrino RTOS реалізує в ядрі ОС тільки найбільш фундаментальні сервіси, такі як передача повідомлень, сигнали, таймери, планування потоків, об"єкти синхронізації. Всі інші сервіси ОС, драйвери та програми виконуються як окремі процеси, які ...

Обеспечения является адекватной решению поставленной в техническом задании задачи. 4. ПРОГРАММНАЯ РЕАЛИЗАЦИЯ ПОСТАВЛЕННОЙ ЗАДАЧИ Программная реализация разработанной выше структуры приложения состоит в разработке исполняемого Win32-приложения в среде визуального программирования MS Visual Studio. Проект программного обеспечения состоит из трех классов – CFuzzyApp, CFuzzyDlg, CFuzzy_. В...

Выдачей и приёмом лицензий). В условиях крупных сетей рекомендуется выделение под сервер лицензий отдельного компьютера (или нескольких - для резервирования). 1.1 Архитектура терминальных устройств В компьютерных технологиях трёхуровневая архитектура, синоним трёхзвенная архитектура (по англ. three-tier или Multitier architecture) предполагает наличие следующих компонентов приложения: ...

Доступ, то собственник сервера не идет в милицию, а нанимает хакера и «залатывает брешь» в защите. ГЛАВА 2. УГОЛОВНО-ПРАВОВАЯ ХАРАКТЕРИСТИКА ПРЕСТУПЛЕНИЙ В СФЕРЕ КОМПЬЮТЕРНОЙ ИНФОРМАЦИИ 2.1. Неправомерный доступ к компьютерной информации В статье 272 Уголовного кодекса РФ предусмотрена ответственность за неправомерный доступ к компьютерной информации, охраняемой законом, т.е. информации на...

Реализация Win32 интерфейса (API) в среде ОС реального времени стандарта POSIX

Перевод: А. Николаев
С. Ющенко

Dan Hildebrand
Senior Architect, R&D
QNX Software Systems Ltd.

Введение

Широкое распространение Windows 95 и Windows NT создало спрос на встраиваемые операционные системы реального времени, которые могут приспосабливать для себя исходный код, написанный для Win32 API. В настоящее время, в ответ на это, несколько производителей разрабатывают продукты, которые “грубо” представляют возможности реального времени в Windows NT. К сожалению, Microsoft без особой охоты дает доступ к исходным кодам Windows NT, и, как следствие, эти расширения реального времени выполняются вне операционной системы. Одна из таких реализаций заключается во внедрении “расширений реального времени” непосредственно в слой, отделяющий NT от аппаратной части (NT hardware abstraction layer ) или HAL. Другое дополнение запускает NT как задачу под управлением ОС реального времени, наравне с другими процессами, работающими как отдельные задачи. Оба расширения требуют внесения модификаций в HAL, причем, первое в большей степени, чем второе.

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

Реальное время выполненное внутри HAL

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

Так как аппаратные прерывания, в первую очередь, обрабатываются HAL’ом и затем передаются операционной системе, HAL имеет преимущество «первой руки» по отношению к ОС. Вместо того чтобы немедленно передать прерывание, HAL может решить использовать его для управления диспетчером внутри ядра реального времени. В ответ на это, диспетчер может запустить набор резидентных HAL задач в реальном масштабе времени. Так как прерывания не были перехвачены ядром реального времени, они могут быть переданы NT для дальнейшей обработки, и приложения NT могут запускаться в соответствии с тактами CPU, которые больше не заняты задачами реального времени, работающими внутри HAL.

Проблема заключается в том, что эта работа в реальном масштабе времени “невидима” для остальной системы (кроме потерянных на работу ядра реального времени тактов CPU и задач, работающих внутри ядра). А именно, HAL-резидентные задачи реального времени не могут получить прямой доступ к полному сервису, предоставляемому Windows NT (графический интерфейс, дисковые накопители, сеть и т.д.). В результате, разработчики, которые взялись за этот метод, должны найти возможность обеспечения взаимодействия HAL-резидентных задач с приложениями NT, которые могут иметь полный доступ ко всему сервису:

Достоинства и недостатки

При использовании метода, базирующегося на HAL, среда Windows NT модифицируется всего лишь слегка, и это означает для ОС совместимость с драйверами устройств и другими расширениями. Но этот вариант имеет несколько недостатков:

Нет совместимости между стандартной средой и средой реального времени

Суть в том, что ядро реального времени внутри HAL будет иметь либо совсем небольшой набор функций Win32, либо совершенно другой набор инструментов. И как результат, процессы, требующие исполнения в реальном масштабе времени, должны программироваться совершенно иным способом, чем обычные NT программы. Переносить код между NT и HAL становится затруднительно.

Нестандартная среда разработки

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

Нестабильность

То, что задачи реального времени работающие в HAL весьма нестабильны в работе, принимается как должное. В то время как среда NT обеспечивает MMU защиту для стандартных задач, ошибки в коде HAL-резидентных приложений реального времени могут легко привести к полному краху NT (“Голубой Экран”). И как результат, среда разработки является довольно хрупкой. Кроме того, приложения реального времени, работающие в HAL, не могут противостоять глобальным сбоям самого NT.

Дополнительные накладные расходы

Реализация HAL, описанная в прессе, для обработки прерываний в реальном масштабе времени использует метод “опроса прерывания”, который работает на высокой, постоянной частоте (20,000 Hz). Это прерывание с фиксированной частотой, вызывает дополнительные накладные расходы на диспетчеризацию всей системы, обрабатывая прерывание тогда, когда не требуется никакой работы в реальном масштабе времени. Также, увеличивается время ожидания начала работы, так как события реального времени не могут быть обработаны до следующего интервала опроса. Настоящее ядро реального времени управляется событиями, немедленно отвечая на прерывания в момент их возникновения.

Большие требования к памяти

Использование расширения HAL только добавляет и без того большие требования NT к памяти. В результате, это решение остается неудовлетворительным для многих систем реального времени с ограниченными ресурсами памяти, которые могли бы извлечь пользу из интерфейса Win32.

Реализация реального времени вне Windows NT

Второй вариант добавления возможностей реального времени в Windows NT - это запуск NT как задачи с самым низким приоритетом под управлением ОС реального времени. Так как остальные задачи могут работать с более высоким приоритетом, чем NT, они могут приостановить выполнение NT и достигнуть лучшего детерминизма реального времени. Для большей надежности, эти задачи работают в адресном пространстве отдельном от NT:

К сожалению, этот метод разделяет многие из основных недостатков метода HAL-расширения, описанного выше. Разработчик должен, как и раньше, работать с двумя абсолютно различными интерфейсами и выбирать между ними, в зависимости от того, требуется ли ему детерминизм реального времени или нет. Инструменты разработки для этих приложений в значительной степени различны. Перенос исходных кодов между этими средами весьма сложен. И опять таки, требование к объему памяти для этой среды значительно выше, чем просто к Windows NT.

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

Вместо того чтобы брать ОС (Windows NT), исходные коды которой не доступны, и пытаться добавить в нее возможности реального времени, намного лучше заставить работать приложения Win32 на ОС, специально созданной для работы в реальном масштабе времени. Пример такого метода - это реализация инструментального пакета Willows Win32 в среде операционной системы QNX ® , построенной на базе микроядра.

Добавление Win32 API в ОС реального времени.

В попытке ввести в мир Win32 те полезные возможности, которые POSIX внес в окружение систем UNIX, Европейская Ассоциация Производителей Компьютеров (European Computer Manufacturers Association или ECMA) утвердила Интерфейс Программирования Приложений для Windows (Application Programming Interface for Windows или APIW). Так же как группы стандартов POSIX определили POSIX исключительно в пределах интерфейса, а не в пределах реализации, так и ECMA вместе с OSF определили стандарт APIW. Назначение APIW - определить стандарт интерфейса Win32 для разработки в открытых системах кросс платформенных программ, которые не обязательно должны работать только в операционных системах, зависящих от Microsoft или Intel.

ОС QNX подтверждает состоятельность этого “независимого от реализации” метода: это высокопроизводительная ОС на базе микроядра, которая также поддерживает интерфейс стандарта POSIX. Как и POSIX API, APIW, определенный ECMA, может быть принят QNX, позволяя ОС обеспечивать высокопроизводительную платформу реального времени для работы приложений, написанных для Win32 API. Такой подход устраняет множество недостатков, описанных для двух предыдущих методов:

Устойчивая среда

QNX представляет модель среды исполнения, по крайней мере, такой же степени надежности, как и Windows NT, с процессами, выполняющимися в отдельных MMU-защищенных адресных пространствах. И как результат, среда реального времени, которую QNX предоставляет для Win32 программ, более “жесткая” чем среда, в которой выполняются HAL- резидентные задачи без защиты памяти:

Совместимость стандартной среды и среды реального времени

Приложения реального масштаба времени могут быть написаны с полной поддержкой Win32 API, включая доступ к графическому интерфейсу. Это намного предпочтительнее, чем иметь только ограниченный API внутри HAL или собственный API, управляемый ОС, которая запускает NT как задачу. Разработчикам не нужно изучать новый набор функций и средства разработки, и уже существующий исходный код Win32 может быть немедленно откомпилирован и запущен в среде реального времени.

Нет накладных расходов

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

Компактная платформа

Реализация Win32 API в QNX, выражается в том, что среда исполнения получается компактнее, чем Windows 95, и значительно компактнее, чем Windows NT. Несмотря на свою компактность, эта среда обеспечивает устойчивость полной защиты памяти, в дополнение к детерминизму реального времени, поддержке Win32 API и POSIX API. Это удовлетворяет встраиваемые в ПЗУ или в flash-память системы намного больше, чем настольные ОС типа Windows NT.

Эта среда дает дополнительную выгоду: благодаря совместимости QNX со стандартами POSIX и UNIX, исходный код UNIX систем может быть также откомпилирован и запущен. Перенос исходных кодов UNIX на QNX платформу требует такой же объем затрат, как и перенос исходных кодов между разными версиями UNIX от разных производителей. В результате, разработчики системы реального времени могут спокойно переносить исходный код как из мира Win32, так и из мира UNIX прямо в свою среду реального времени. Это минимизирует объем кода, который должен быть написан с нуля, и что более важно, помогает сократить время выхода продукта на рынок.

Реализация Win32 API в QNX

Для реализации Win32 API в ОС QNX, Willows Software () и QNX Software Systems перенесли пакет Willows RT в QNX и добавили оптимизацию для QNX, для лучшей работы окружения Willows. Этот пакет работает как независимый от платформ интерфейс между приложениями, вызывающими Win32 API и основной операционной системой. С точки зрения прикладных программ, этот интерфейс, выполненный как разделяемая библиотека, выступает в виде оперативной среды Windows со всеми ее возможностями и функциями, которые программа ожидает увидеть. С точки зрения разработчика, нет необходимости овладевать новой средой для рекомпиляции существующих приложений Win32.

Willows RT изначально был разработан как Willows Toolkit для X Window System for Unix и для графической среды Macintosh. Несмотря на то, что существует реализация X Window для QNX, работа Willows RT под X в среде QNX не удовлетворила бы требованиям компактности для рынка встраиваемых систем реального времени. Итак, Willows RT был перенесен в оконную систему на базе микроядра - Photon microGUI ® , которая работает в среде QNX (смотрите Error! Reference source not found. для более подробной информации). Photon может выполнять те же функции, что и X Window, но занимает меньший объем памяти (около 500Кб). Наряду с маленьким размером самой QNX, он открывает новое решение - Willows-на-QNX, которое требует намного меньше памяти, чем Windows NT и дает возможность работать приложениям Win32 в реальном масштабе времени.

Компоненты Willows API

В Willows API входят 3 основные компоненты:

• бинарный интерфейс Willows (Willows Binary Interface)
• библиотека Willows (Willows Library)
• уровень абстракции платформы Willows (Willows Platform-abstraction Layer)

Бинарный интерфейс Willows

Приложения Win32 взаимодействуют с библиотекой Willows таким же образом как и со средой Windows: вызов функций API, прием сообщений, загрузка ресурсов и даже запуск других приложений Win32. Существующие приложения Win32 и динамические библиотеки (DLLs) для доступа к Win32 API на не-Intel платформах взаимодействуют с бинарным интерфейсом Willows. (Этот интерфейс перенаправляет все запросы Windows API к библиотеке Willows, чтобы дать возможность инородным приложениям достигнуть скорости функционирования как на родной платформе.) Подобным же образом, библиотека Willows взаимодействует с областью драйверов, создавая запросы к графическим, оконным или системным операциям и принимая ответы или асинхронные сообщения.

Willows API может опознавать 16-ти разрядные Intel объекты, такие как динамические библиотеки (DLL), директивы Visual Basic (VBX), драйверы (DRV) и пользовательские средства управления произведенные “третьими фирмами”. Следовательно, разработчики могут совмещать в прикладной программе исходные коды и бинарные модули. Также, они могут переносить свои приложения, не дожидаясь, когда кто-нибудь из “третьих фирм” перенесет свои библиотеки. Файлы данных и графические файлы могут также использоваться без всяких изменений и программы могут продолжать загружать данные из DLL без каких-либо модификаций, что ускорит продвижение продукта на рынок.

Виртуальная Машина

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

Для переноса Willows RT в QNX, для которой Intel процессор является родным, такая адаптация к аппаратному обеспечению не нужна. В результате этого, родной код Wn32 может работать с требуемой скоростью, не зависимо от того, производился ли перенос исходного кода Win32 или изменилась среда функционирования DLLs, для которых исходный код не доступен. Такое естественное выполнение сохраняет способности программ достигать производительности реального масштаба времени на ОС QNX.

Эмулятор DOS

Эмулятор DOS имитирует прерывания и функциональный интерфейс DOS. Сюда включены все функции DOS, используемые Win32 API, включая управление процессами и операции ввода-вывода. Доступ к параллельным и последовательным портам производится путем отображения функций непосредственно на устройства или фильтры вывода.

QNX поддерживает доступ к родным носителям информации DOS, которые Willows RT использует, чтобы читать и записывать файлы на такие носители как жесткие и гибкие диски. В результате, файлы могут спокойно перемещаться между системами QNX/Willows и родным окружением Windows/DOS. Сетевые соединения через TCP/IP c SMB (или CIFS) и NFS могут также использоваться для совместного использования сетевых файлов между системами QNX/Willows и Windows95 или Windows NT.

16/32-х битный Обработчик запросов

16/32-х битный Обработчик запросов (16/32 Thunking Layer) манипулирует запросами между 16-битовым кодом Windows и библиотекой Willows. 16-битовый код работает в защищенном режиме, используя 16-битовый стек и сегмент/смещение для адресации. Каждый запрос идентифицируется “методом”, который обрабатывает соответствующий тип запроса. Данный метод может варьироваться от чего-нибудь простого, вроде таких как запрос к библиотеке и возвращение результата в определенных регистрах, до более сложных операций, которые преобразуют адреса и структуры данных в обоих случаях, как во время вызова, так и в момент возврата из процедуры.

16/32-битный Загрузчик

16/32-битный Загрузчик загружает программы, производит распределение кода и данных программ, динамических библиотек и драйверов. Загрузчик работает совместно с виртуальной машиной и обработчиком запросов, для размещения сегментов кода и данных, включая отсутствующие сегменты, которые будут загружены в дальнейшем по запросам приложений. Загрузчик также связывает библиотеку Willows с DLL для переназначения вызовов к библиотеке.

Библиотека Willows

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

Реализация библиотеки Willows согласована и совместима с требованиями APIW, введенного ECMA и OSF как кросс платформенный Windows API. Она написана на языке C и обеспечивает доступ как из программ, написанных на C, так и на C++.

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

Библиотека поддерживает:

• окна MDI, общие диалоги и функции управления диалогами

• реализацию многозадачности внутри одного процесса

• буфер обмена (clipboard) и динамический обмен данными (DDE)

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

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

Уровень абстрагирования от платформы

Этот уровень содержит весь зависящий от платформы код для создания и управления окнами, отображения в этих окнах, и доступа к системно-зависимым ресурсам. Он содержит три подсистемы, которые доступны через вызовы библиотеки Willows:

Интерфейс администратора окон

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

Вся связь с менеджером рабочего стола (desktop window manager) производится кодом, приспособленным для конкретной платформы, который затем переправляет информацию независимой от платформы части администратора окон. Большинство внешних событий, доступ к которым из графических программ обеспечивает Photon, также перехватываются на этом уровне и преобразуются в стандартный набор команд, которые может обрабатывать библиотека. К таким событиям относятся сообщения о создании, перерисовке и удалении окон и сообщения о местоположении и размере окон.

Интерфейс графических устройств

Интерфейс графических устройств (Graphics Device Interface) обеспечивает средства для вывода изображений непосредственно в окна или на принтеры. Он поддерживает основные графические операции, такие как рисование линий, прямоугольников и эллипсов, а также более сложные операции над объектами, такими как перо, кисть, регион и графический образ. Он также имеет полный набор функций для вывода текста, от выбора шрифта и цвета до специальных эффектов, таких как подчеркивание и перечеркивание. Библиотека Willows и Интерфейс Графических Устройств поддерживают широкий спектр устройств, от простейших с малой разрешающей способностью и ограниченной цветовой гаммой, до дисплеев с высокой разрешающей способностью и большим количеством цветов, а также большой набор принтеров. Все эти услуги отображаются непосредственно на средства, предоставляемые Photon microGUI.

Интерфейс системных услуг

Интерфейс системных услуг (System Services Interface) обеспечивает зависимый от платформы код для доступа к средствам файловой системы, распределения памяти, сетевого взаимодействия и доступа к устройствам. Например, он перекладывает все запросы, связанные с работой в сети и коммуникациями на соответствующие функции, предоставляемые операционной системой QNX. Он также поддерживает функции межзадачного обмена (IPC), такие как clipboard и DDE, реализованные в библиотеке Willows. Кроме того, он содержит зависимый от платформы код, ассоциируемый с динамическими библиотеками, и позволяющий библиотеке окон Willows (Willows Window Library) поддерживать в QNX семантику динамически загружаемых библиотеки.

Взаимосвязь между платформами Win32

Так как Вы можете спокойно переносить приложения Win32 между Windows и QNX, то становится относительно просто создавать распределенные системы реального времени, где каждый узел в сети может работать под управлением той ОС, которая в большей степени удовлетворяет желаниям пользователя, но где все узлы используют один и тот же API и коды прикладных программ. Конечно, теперь, когда программа, построенная из одних и тех же исходных кодов Win32, может работать в различных операционных системах одной локальной сети, становится важным обеспечение взаимосвязи этих распределенных программ. Отвечая этому требованию, QXN поддерживает сетевые файловые системы SMB (CIFS) и NFS. Более того, Photon microGUI дает Вам возможность просматривать и управлять экраном узла QNX (или окном конкретного приложения) с экрана Windows 95 или Windows NT. В результате, графические приложения реального времени могут работать на платформах жесткого реального времени, а отображаться на обычных системах, подключенных к сети.

Дополнительные услуги QNX

Как ОС реального времени на базе микроядра, QNX предлагает приложениям Win32 набор услуг, не доступных в Windows NT. Сюда входит устойчивое быстродействие в реальном масштабе времени, распределенная обработка данных и отказоустойчивая сеть.

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

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

Заключение

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

С другой стороны, реализация Win32 API на ОС реального времени QNX, позволяет разработчикам использовать только один API - Win32. Это позволяет процессам реального времени работать в надежной, отлаженной среде. И, благодаря малой требовательности QNX к объему оперативной памяти, появляется возможность использовать Win32 для небольших встраиваемых систем.

Как тщательно продуманная ОС реального времени, оптимизированная для использования в критичных к сбоям приложениях, QNX также предлагает разработчику дополнительные возможности - такие как отказоустойчивость сети, распределенная обработка информации и полная совместимость с POSIX и UNIX, что практически не возможно в NT. Более того, QNX делает относительно простым объединение платформ Win32, которое дает разработчику свободу выбора соответствующей ОС для каждой задачи. И в конечном итоге, разработка Willows/QNX представляет объединение менталитета “отрытых систем” и стандартов переносимости исходных кодов.

QNX и Photon microGUI являются зарегистрированными торговыми знаками QNX Software Systems.
Все другие торговые знаки и зарегистрированные торговые знаки принадлежат соответствующим владельцам.

Формат командной строки:

ROUTE [-f] [-p] [-4|-6] command

Подсказку по параметрам командной строки можно получить используя встроенную справку (route /?):

-f - Очистка таблиц маршрутов от записей всех шлюзов. При указании одной из команд таблицы очищаются до выполнения команды.

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

-4 - Обязательное использование протокола IPv4.

-6 - Обязательное использование протокола IPv6.

command - Одна из следующих команд:

- PRINT - Печать маршрута
- ADD - Добавление маршрута
- DELETE - Удаление маршрута
- CHANGE - Изменение существующего маршрута

destination - Адресуемый узел.

MASK - Указывает, что следующий параметр интерпретируется как маска сети.

netmask - Значение маски подсети для записи данного маршрута. Если этот параметр не задан, по умолчанию используется значение 255.255.255.255.

gateway - Шлюз.

interface - Номер интерфейса для указанного маршрута.

METRIC - Определение метрики, т.е. цены для адресуемого узла. Чем ниже значение метрики, тем выше приоритет узла при построении маршрута.

Поиск всех символических имен узлов проводится в файле сетевой базы данных NETWORKS. Поиск символических имен шлюзов проводится в файле базы данных имен узлов HOSTS.

Для команд PRINT и DELETE можно указать узел и шлюз с помощью подстановочных знаков или опустить параметр "шлюз".

Если адресуемый узел содержит подстановочные знаки * или?, он используется в качестве шаблона, и печатаются только соответствующие ему маршруты. Знак "*" соответствует любой строке, а "?" - одному знаку.

Примеры: 157.*.1, 157.*, 127.*, *224*.

Соответствие шаблону поддерживает только команда PRINT.

Диагностические сообщения:

Недопустимое значение MASK вызывает ошибку, если (УЗЕЛ & МАСКА) != УЗЕЛ.

Например:
route ADD 157.0.0.0 MASK 155.0.0.0 157.55.80.1 IF 1 - Добавление маршрута завершится ошибкой, поскольку указан недопустимый параметр маски. (Узел & Маска) != Узел.

Примеры:

route PRINT - отобразить таблицу маршрутов
route PRINT -4 - отобразить таблицу маршрутов только для IPv4
route PRINT -6 - отобразить таблицу маршрутов только для IPv6
route PRINT 157* - отобразить таблицу маршрутов только для узлов, начинающихся со 157

Если сетевой интерфейс (IF) не задан, то производится попытка найти лучший интерфейс для указанного шлюза.

route ADD 3ffe::/32 3ffe::1 - добавить новый маршрут для узла с IPv6

route CHANGE 157.0.0.0 MASK 255.0.0.0 157.55.80.5 METRIC 2 IF 2 - изменить существующий маршрут для узла IPv4

Параметр CHANGE используется только для изменения шлюза или метрики.

route DELETE 157.0.0.0 - удалить маршрут для IPv4.

route DELETE 3ffe::/32 - удалить маршрут для IPV6

Примеры использования команды ROUTE

route print - отобразить текущую таблицу маршрутов.

Пример отображаемой таблицы:

Список интерфейсов
24...00 50 ba 5d 0c c4 ......D-Link DFE-538TX 10/100 адаптер
13...00 19 db ce 97 9c ......Сетевая карта Realtek RTL8169/8110 Family NIC
1...........................Software Loopback Interface 1
17...00 00 00 00 00 00 00 e0 Адаптер Microsoft ISATAP
12...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
===========================================================================

IPv4 таблица маршрута

===========================================================================
Активные маршруты:
===========================================================================

Постоянные маршруты:
===========================================================================

IPv6 таблица маршрута
===========================================================================
Активные маршруты:
===========================================================================

Постоянные маршруты:
Отсутствует

Список интерфейсов - отображаются идентификаторы (ID), физические (MAC) адреса и названия сетевых адаптеров. В примере:
24 - идентификатор интерфейса
00 50 ba 5d 0c c4 - MAC-адрес сетевого адаптера
D-Link DFE-538TX 10/100 адаптер - название сетевого адаптера.

Сетевой адрес (Network Destination) - IP-адрес, адрес сети, или адрес 0.0.0.0 используемый для шлюза по умолчанию (Default Gateway). Это конечная точка маршрута

Маска сети (Netmask) - маска сети.

Адрес шлюза (Gateway) - IP-адрес шлюза, через который будет выполняться отправка пакета для достижения конечной точки.

В Windows Vista / Windows 7 / 8 и более поздних версиях, для адресов, достижимых локально, в данной колонке отображается On-link . Другими словами, значение On-link в колонке "Шлюз" означает, что шлюз не используется, адрес назначения достижим напрямую, без маршрутизации.

Интерфейс (Interface) - IP-адрес сетевого интерфейса, через который выполняется доставка пакета конечной точке маршрута.

Метрика (metric) - значение метрики (1-9999). Метрика представляет собой числовое значение, позволяющее оптимизировать доставку пакета получателю, если конечная точка маршрута может быть достижима по нескольким разным маршрутам. Чем меньше значение метрики, тем выше приоритет маршрута.

route print 192.* - отобразить таблицу маршрутов только для адресов, начинающихся с 192.

route add 0.0.0.0 mask 0.0.0.0 192.168.1.1 - установить в качестве шлюза по умолчанию (основного шлюза) адрес 192.168.1.1

route -p add 10.0.0.0 mask 255.0.0.0 10.0.0.1 - добавить маршрут для подсети 10.0.0.0/255.0.0.0 и запомнить его в реестре. Это постоянный статический маршрут. Если маршрут добавлен без использования параметра -p то он сохраняется только до перезагрузки системы (до перезапуска сетевого системного программного обеспечения). Если же, при добавлении маршрута искользовался данный параметр, то информация о маршруте записывается в реестр Windows (раздел HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\PersistentRoutes) и будет использоваться постоянно при активации сетевых интерфейсов.

route delete 10.0.0.0 mask 255.0.0.0 - удалить маршрут для подсети 10.0.0.0/255.0.0.0 .

route add 10.10.10.10 192.168.1.158 - добавить маршрут для узла с IP-адресом 10.10.10.10 . Если маска в команде не задана, то подразумевается ее значение равное 255.255.255.255 , т.е конечная точка назначения является одиночным IP-адресом узла.

route delete 10.10.10.10 - удалить маршрут созданный предыдущей командой

route change 10.0.0.0 mask 255.0.0.0 10.10.10.1 - изменить адрес шлюза для существующего маршрута к сети 10.0.0.0/255.0.0.0 на значение 10.10.10.1 Допускается использование данной команды только для изменения адреса шлюза и метрики.

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

Не относятся к петлевому интерфейсу (интерфейсу с IP 127.0.0.1 и маской -255.0.0.0)
- не являются маршрутами для многоадресной (multicast) рассылки (IP 224.0.0.1 маска 255.0.0.0)
- не являются узловыми маршрутами (когда маска равна 255.255.255.255) .

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

Структура реальных таблиц маршрутизации стека TCP/IP в целом соответствует упрощенной структуре рассмотренных ранее таблиц. Отметим, однако, что вид таблицы IP-маршрутизации зависит от конкретной реализации стека TCP/IP. Приведем пример нескольких вариантов таблицы маршрутизации, с которыми мог бы работать маршрутизатор R1 в сети, представленной на рис. 1.

Начнем с «придуманного» предельно упрощенного варианта таблицы маршрутизации (табл. 1). Здесь имеются три маршрута к сетям (записи 56.0.0.0,116.0.0.0 и 129.13.0.0), две записи о непосредственно подсоединенных сетях (198.21.17.0 и 213.34.12.0), а также запись о маршруте по умолчанию.

Таблица 1. Упрощенная таблица маршрутизации маршрутизатора R1

Адрес сети назначения	Адрес следующего маршрутизатора	Адрес выходного интерфейса	Расстояние до сети назначения 15 13 2 1 (подсоединена) 1
56.0.0.0	213.34.12.4	213.34.12.3	15
116.0.0.0	213.34.12.4	213.34.12.3	13
129.13.0.0	198.21.17.6	198.21.17.5	2
198.21.17.0	198.21.17.5	198.21.17.5	1(подсоединена)
213.34.12.0	213.34.12.3	213.34.12.3	1(подсоединена)
Маршрут по умолчанию	198.21.17.7	198.21.17.5	-

Более сложный вид имеют таблицы, которые генерируются в промышленно выпускаемом сетевом оборудовании.

Если представить, что в качестве маршрутизатора R1 в данной сети работает штатный программный маршрутизатор операционной системы Microsoft Windows ХР, то его таблица маршрутизации могла бы выглядеть так, как табл. 2.

Рис. 1 Пример маршрутизируемой сети

Таблица 2. Таблица программного маршрутизатора ОС Windows ХР

Сетевой адрес	Маска	Адрес шлюза	Интерфейс	Метрика
127.0.0.0	255.0.0.0	127.0.0.1	127.0.0.1	1
0.0.0.0	0.0.0.0	198.21.17.7	198.21.17.5	1
56.0.0.0	255.0.0.0	213.34.12.4	213.34.12.3	15
116.0.0.0	255.0.0.0	213.34.12.4	213.34.12.3	13
129.13.0.0	255.255.0.0	198.21.17.6	198.21.17.5	2
198.21.17.0	255.255.255.0	198.21.17.5	198.21.17.5	1
198.21.17.5	255.255.255.255	127.0.0.1	127.0.0.1	1
198.21.17.255	255.255.255.255	198.21.17.5	198.21.17.5	1
213.34.12.0	255.255.255.0	213.34.12.3	213.34.12.3	1
213.34.12.3	255.255.255.255	127.0.0.1	127.0.0.1	1
213.34.12.255	255.255.255.255	213.34.12.3	213.34.12.3	1
224.0.0.0	224.0.0.0	198.21.17.6	198.21.17.6	1
224.0.0.0	224.0.0.0	213.34.12.3	213.34.12.3	1
255.255.255.255	255.255.255.255	198.21.17.6	198.21.17.6	1

Если на месте маршрутизатора R1 установить один из популярных аппаратных маршрутизаторов, то его таблица маршрутизации для этой же сети может выглядеть совсем иначе (табл. 3).

Таблица 3. Таблица маршрутизации аппаратного маршрутизатора

И наконец табл. 4 представляет собой таблицу маршрутизации для того же маршрутизатора R1, реализованного в виде программного маршрутизатора одной из версий операционной системы Unix.

Таблица 4. Таблица маршрутизации Unix-маршрутизатора

Адрес назначения	Шлюз	Флаги	Интерфейс
127.0.0.0	127.0.0.1	UH	1	154	1о0
Маршрут по умолчанию	198.21.17.7	UG	5	43270	1е0
198.21.17.0	198.21.17.5	U	35	246876	1е0
213.34.12.0	213.34.12.3	U	44	132435	le1
129.13.0.0	198.21.1.7.6	UG	6	16450	1е0
56.0.0.0	213.34.12.4	UG	12	5764	le1
116.0.0.0	213.34.12.4	UG	21	23544	le1

ПРИМЕЧАНИЕ
Заметим, что поскольку между структурой сети и таблицей маршрутизации нет однозначного соответствия, для каждого из приведенных вариантов таблицы можно предложить свои «подварианты», отличающиеся выбранным маршрутом к той или иной сети. В данном случае внимание концентрируется на существенных различиях в форме представления маршрутной информации разными реализациями маршрутизаторов.

Несмотря на достаточно заметные внешние различия, во всех трех «реальных» таблицах присутствуют все ключевые данные из рассмотренной упрощенной таблицы, без которых невозможна маршрутизация пакетов.

К таким данным, во-первых, относятся адреса сети назначения (столбцы «Адрес назначения» в аппаратном маршрутизаторе и маршрутизаторе Unix или столбец «Сетевой адрес» в маршрутизаторе ОС Windows ХР).

Вторым обязательным полем таблицы маршрутизации является адрес следующего маршрутизатора (столбцы «Шлюз» в аппаратном маршрутизаторе и маршрутизаторе Unix или столбец «Адрес шлюза» в маршрутизаторе ОС Windows ХР).

Третий ключевой параметр - адрес порта, на который нужно направить пакет, в некоторых таблицах указывается прямо (столбец «Интерфейс» в таблице маршрутизатора ОС Windows ХР), а в некоторых - косвенно. Так, в таблице маршрутизатора Unix вместо адреса порта задается его условное наименование - 1е0 для порта с адресом 198.21.17.5, lei для порта с адресом 213.34.12.3 и 1о0 для внутреннего порта с адресом 127.0.0.1. В адпаратном маршрутизаторе поле, обозначающее выходной порт в какой-либо форме, вообще отсутствует. Это объясняется тем, что адрес выходного порта всегда можно косвенно определить по адресу следующего маршрутизатора. Например, определим по табл. 3 адрес выходного порта для сети 56.0.0.0. Из таблицы следует, что следующим маршрутизатором для этой сети будет маршрутизатор с адресом 213.34.12.4. Адрес следующего маршрутизатора должен принадлежать одной из непосредственно присоединенных к маршрутизатору сетей, и в данном случае это сеть 213.34.12.0. Маршрутизатор имеет порт, присоединенный к этой сети, и адрес этого порта 213.34.12.3 мы находим в столбце «Шлюз» второй строки таблицы маршрутизации, которая описывает непосредственно присоединенную сеть 213.34.12.0. Для непосредственно присоединенных сетей адресом следующего маршрутизатора всегда является адрес собственного порта маршрутизатора. Таким образом, для сети 56.0.0 адресом выходного порта является 213.34.12.3.

Стандартным решением сегодня является использование поля маски в каждой записи таблицы, как это сделано в таблицах маршрутизатора ОС Windows ХР и аппаратного маршрутизатора (столбцы «Маска»). Механизм обработки масок при принятии решения маршрутизаторами рассматривается далее. Отсутствие поля маски говорит о том, что либо маршрутизатор рассчитан на работу только с тремя стандартными классами адресов, либо для всех записей используется одна и та же маска, что снижает гибкость маршрутизации.
Поскольку в таблице маршрутизации маршрутизатора Unix каждая сеть назначения упомянута только один раз, а значит, возможность выбора маршрута отсутствует, то поле метрики является необязательным параметром. В остальных двух таблицах поле метрики используется только для указания на то, что сеть подключена непосредственно. Метрика 0 для аппаратного маршрутизатора или 1 для маршрутизатора ОС Windows ХР говорит маршрутизатору, что эта сеть непосредственно подключена к его порту, а другое значение метрики соответствует удаленной сети. Выбор метрики для непосредственно подключенной сети (1 или 0) является произвольным, главное, чтобы метрика удаленной сети отсчитывалась с учетом этого выбранного начального значения. В маршрутизаторе Unix используется поле признаков, где флаг G (Gateway - шлюз) отмечает удаленную сеть, а его отсутствие - непосредственно подключенную.

Признак непосредственно подключенной сети говорит маршрутизатору, что пакет уже достиг своей сети, поэтому протокол IP активизирует ARP-запрос относительно IP-адреса узла назначения, а не следующего маршрутизатора.

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

Флаги записей присутствуют только в таблице маршрутизатора Unix.

• U - маршрут активен и работоспособен. Аналогичный смысл имеет поле статуса в аппаратном маршрутизаторе.
• Н - признак специфического маршрута к определенному хосту.
• G - означает, что маршрут пакета проходит через промежуточный маршрутизатор (шлюз). Отсутствие этого флага отмечает непосредственно подключенную сеть.
• D - означает, что маршрут получен из перенаправленного сообщения протокола ICMP. Этот признак может присутствовать только в таблице маршрутизации конечного узла. Признак означает, что конечный узел при какой-то предыдущей передаче пакета выбрал не самый рациональный следующий маршрутизатор на пути к данной сети, и этот маршрутизатор с помощью протокола ICMP сообщил конечному узлу, что все последующие пакеты к данной сети нужно отправлять через другой маршрутизатор.

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

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