- •1. Операционные системы
- •2. Функциональные компоненты локальной ос
- •3. Назначение и функции сетевой ос
- •4. Функциональные компоненты сетевой ос
- •5. Коммуникационные средства
- •6. Классификация ос
- •8. Архитектура ос
- •9. Монолитные и многоярусные ядра
- •10. Функциональные компоненты Linux
- •11. Структура ядра
- •12. Функции слоёв ядра
- •13. Вспомогательные модули
- •14. Микроядерные системы
- •15. Объектная модель функционирования
- •16. Состав исполнительной системы WinNt
- •17. Совместимость
- •18. Множественные прикладные среды. Способы реализации
- •19. Интерфейсы ос
- •20. Файловая система
- •21. Логическая организация файла
- •22. Физическая организация файла
- •23. Общая модель фс
- •Непрерывное
- •2) Цепочечная
- •3) Фиксированный
- •Битовые карты (таблицы) – каждому блоку ставится в соответствие свой бит (1 – занят, 0 – свободен)
- •Цепочки сводных свободных порций
- •Список свободных блоков
- •Индексированный
- •24. Функции фс
- •25. Фс unix-подобных ос
- •26. Структура фс
- •27. Структура фс базовых unix-подобных ос
- •28. Архитектура виртуальной фс
- •29. Последовательность действий при монтировании
- •30. Файловые дескрипторы и трансляция имён
- •31. Физическая организация fat
- •32. Физическая организация ntfs
- •33. Управление процессами
- •34. Контекст и дескриптор
- •35. Структура контекста процесса
- •36. Планирование и диспетчеризация
- •37. Алгоритмы планирования
- •38. Планирование и диспетчеризация в unix системах
- •39. Управление процессами в unix-подобных системах
- •40. Атрибуты, инфраструктура процесса
- •41. Создание процессов
- •42. Этап exec()
- •43. Межпроцессные взаимодействия (ipc)
- •44. Каналы (pipe)
- •45. Fifo
- •46. Пространство имен
- •47. Сообщения
- •48. Семафоры
- •49. Разделяемая память
- •50. Сигналы
- •51. Последовательность событий
- •52. Функции управления процессами
- •53. Сообщения в микроядерных ос.
- •54. Процессы и потоки в WinNt
- •55. Базовая структура процесса, создание процесса в WinNt
- •56. Основные различия управления процессами в различных средах
- •57. Состав потока в WinNt и контекст потока
- •58. Передача сообщений с помощью lpc (локальный вызов процедур)
- •59. Распределенные системы. Удаленный вызов процедур. Rpc (Remote Procedure Call)
- •60. Система ввода-вывода в Win nt
- •61. Реализация свв в Windows nt
- •62. Унифицированная модель драйвера
- •63. Формат пакета irp
- •64. Структура драйвера
- •65. Редиректор и сервер. Встроенные сетевые компоненты
15. Объектная модель функционирования
Функционирование Windows NT – взаимодействие приложений прикладного уровня и серверов – клиент-серверное (ПОПЫТКА использовать микроядерную систему), но стали развивать идею оконного интерфейса, и ядро получилось большое. Исполнительная система – иерархическая структура системы ввода/вывода, драйверы – классическая иерархическая структура.
В качестве объектов рассматриваются ресурсы ОС (файлы, процессы, средства синхронизации, аппаратные ресурсы). Принципы ООП сохраняются. Это дает возможность сохранять хорошие решения и легко их изменять. Можно создавать новые объекты на основе уже существующих. Защита информации, наследование, тиражирование за счет инкапсуляции. Это дает структурированность системы (было использовано в Windows NT).
16. Состав исполнительной системы WinNt
HAL – Hardware Abstraction Level.
Существуют сети микроядер, взаимодействующих между собой – это массивно-параллельные машины. На основе микроядерных систем можно строить системы для распределенного решения задач. Бывает модель SMP (симметричная мультипроцессорная система).
17. Совместимость
Совместимость ОС – свойство, позволяющее выполнять приложения, написанные для других ОС.
Двоичная совместимость – исполняемый файл. Определяется архитектурой процессора, совпадение API. Внутренняя структура файла должна соответствовать структуре, используемой в данной ОС. При несовпадении структуры необходима эмуляция двоичного кода. Эмуляция используется в системах кросс-разработки.
На уровне исходных кодов – совместимость на уровне компиляторов, совместимость библиотек, системных вызовов.
Работа эмулятора – входной команде сопоставляется эквивалентная ей подпрограмма (долгий процесс). Разрабатывается целый пласт ПО, ориентированный на достижение двоичной совместимости: эмуляторы, кроссплатформенные системы, интегрированные среды разработки (IDE) (Eclipse, NetBeans).
Эмуляция двоичного кода используется в системах кросс-разработки – системах, предназначенных для разработки программ в 2х машинной конфигурации.
Состав системы кросс-разработки:
Средства редактирования
Средства компиляции
Средства отладки
Все это находится на инструментальной машине, а в готовом виде передается на целевую. Использование кросс-средств: системы программирования МК (Intel, Atmel и др.). ОС WinCE, PalmOS. Такие ОС включают в себя набор компиляторов и ассемблеров на инструментальной машине под ее ОС, библиотеки, выполняющие большую часть функций целевой ОС, средства отладки.
18. Множественные прикладные среды. Способы реализации
Альтернатива эмуляции – множественные прикладные среды, в которую входит набор функций прикладного интерфейса API. Они имитируют обращение к библиотечным функциям прикладной среды, а на самом деле обращаются к своим внутренним библиотекам. Это называется трансляцией библиотек. Это чисто программный комплекс.
Чтобы программа, написанная под одной ОС работала под другой, необходимо обеспечить бесконфликтное взаимодействие способов управления процессами в разных ОС.
Способы реализации прикладных программных сред
В зависимости от архитектуры:
1. Прикладная программная среда в виде приложения (верхний слой ядра родной ОС).
Пользовательский режим работы, трансляция системных вызовов (вызовов API) в вызовы «родной» ОС. Соответствует классическим многослойным ОС (Unix, Windows).
2. Наличие нескольких прикладных сред, функционирующих равноправно. Каждая в виде отдельного слоя ядра.
Привилегированный режим работы. API обращается к функциям нижележащего (привилегированного) слоя ОС. На систему ложится задача распознавания и адаптации вызова. Требуется большое количество ресурсов. В ядро передаётся набор идентифицирующих характеристик для распознавания.
3. Микроядерный принцип.
Любая прикладная среда оформляется в виде отдельного сервера пользовательского режима. Приложения, используя API, обращаются системными вызовами к соответствующей прикладной среде через микроядро. Прикладная среда обрабатывает запрос и через микроядро возвращает результат. Могул использоваться функции микроядра. Возможно многократное обращение к другим ресурсам (во время работы микроядра).