- •Операционные системы
- •1. Назначение и функции операционных систем. История развития
- •1.1. Основные функции операционных систем
- •1.2. Эволюция ос
- •1.2.1. Первый период (1945 -1955)
- •1.2.2. Второй период (1955 - 1965)
- •1.2.3. Третий период (1965 – 1980)
- •1.2.4. Четвертый период (1980 - настоящее время)
- •2. Классификация операционных систем
- •2.1. Классификация ос в зависимости от особенностей алгоритмов управления ресурсами
- •2.1.1. Поддержка многозадачности
- •2.1.2 Поддержка многопользовательского режима
- •2.1.3 Вытесняющая и невытесняющая многозадачность
- •2.1.4 Поддержка многонитевости.
- •2.1.5 Наличие механизма многопроцессорной обработки
- •2.2. Классификация ос в зависимости от особенностей аппаратных платформ
- •2.3. Классификация ос по областям использования
- •2.4. Особенности методов построения ос
- •3. Управление процессами
- •3.1. Состояния процессов
- •3.2. Контекст и дескриптор процесса
- •3.3. Алгоритмы планирования процессов
- •3.4. Средства синхронизации и взаимодействия процессов
- •3.4.1. Проблема синхронизации
- •3.4.2 Критическая секция
- •3.4.3 Тупики
- •3.4.4 Нити
- •4. Управление памятью
- •4.1. Типы адресов
- •4.2. Методы распределения памяти без использования дискового пространства
- •4.2.1. Распределение памяти фиксированными разделами
- •4.2.2. Распределение памяти разделами переменной величины
- •4.2.3. Перемещаемые разделы
- •4.3 Методы распределения памяти с использованием дискового пространства
- •4.3.1. Понятие виртуальной памяти
- •4.3.2. Страничное распределение
- •4.3.3. Сегментное распределение
- •4.3.4. Странично-сегментное распределение
- •4.3.5. Свопинг
- •4.4. Иерархия запоминающих устройств. Принцип кэширования данных
- •5. Управление вводом-выводом
- •5.1. Физическая организация устройств ввода-вывода
- •5.2. Организация программного обеспечения ввода-вывода
- •5.2.1. Обработка прерываний
- •5.2.2. Драйверы устройств
- •5.2.3. Независимый от устройств слой операционной системы
- •5.2.4. Пользовательский слой программного обеспечения
- •6. Файловая система
- •6.1. Правила именования и типы файлов
- •6.2. Логическая организация файла
- •6.3. Физическая организация и адрес файла
- •6.4. Права доступа к файлу
- •6.5. Кэширование диска
- •6.6. Общая модель файловой системы
- •6.7. Современные архитектуры файловых систем
- •7. Управление распределенными ресурсами
- •7.1. Базовые примитивы передачи сообщений в распределенных системах
- •7.2. Способы адресации
- •7.3. Блокирующие и неблокирующие примитивы
- •7.4. Буферизуемые и небуферизуемые примитивы
- •7.5. Надежные и ненадежные примитивы
- •8. Современные концепции проектирования операционных систем
- •8.1. Расширяемость
- •8.2. Переносимость
- •8.3. Совместимость
- •8.4. Безопасность
- •9. Варианты построения информационных приложений
- •9.1. Типовые компоненты информационных приложений
- •9.2. Централизованные многотерминальные системы
- •9.3. Файл-серверные приложения
- •9.4. Приложения клиент-сервер
- •9.5. Распределенные вычисления
- •9.6. Офисные системы
- •9.7. Информационные системы на основе Internet/Intranet-технологии
- •10. Концепции windows nt
- •10.1 Структура: nt-executive и защищенные подсистемы
- •10.2. Множественные прикладные среды в Windows nt
- •10.3. Объектно-ориентированный подход в Windows nt
- •10.4. Процессы и нити
- •10.5. Алгоритм планирования процессов и нитей
- •10.6. Сетевые средства Windows nt
- •10.7. Совместимость линейки операционных систем Windows nt с Novell NetWare
- •Оглавление
8.3. Совместимость
Одним из аспектов совместимости является способность ОС выполнять программы, написанные для других ОС или для более ранних версий данной операционной системы, а также для другой аппаратной платформы.
Необходимо разделять вопросы двоичной совместимости и совместимости на уровне исходных текстов приложений. Двоичная совместимость достигается в том случае, когда можно взять исполняемую программу и запустить ее на выполнение на другой ОС. Для этого необходимы: совместимость на уровне команд процессора, совместимость на уровне системных вызовов и даже на уровне библиотечных вызовов, если они являются динамически связываемыми.
Совместимость на уровне исходных текстов требует наличия соответствующего компилятора в составе программного обеспечения, а также совместимости на уровне библиотек и системных вызовов. При этом необходима перекомпиляция имеющихся исходных текстов в новый выполняемый модуль.
Совместимость на уровне исходных текстов важна в основном для разработчиков приложений, в распоряжении которых эти исходные тексты всегда имеются. Но для конечных пользователей практическое значение имеет только двоичная совместимость, так как только в этом случае они могут использовать один и тот же коммерческий продукт, поставляемый в виде двоичного исполняемого кода, в различных операционных средах и на различных машинах.
Обладает ли ОС двоичной совместимостью или совместимостью исходных текстов с существующими системами, зависит от многих факторов. Самый главный из них - архитектура процессора, на котором работает новая ОС. Если процессор, на который переносится ОС, использует тот же набор команд (возможно с некоторыми добавлениями) и тот же диапазон адресов, тогда двоичная совместимость может быть достигнута достаточно просто.
Гораздо сложнее достичь двоичной совместимости между процессорами, основанными на разных архитектурах. Для того, чтобы один компьютер выполнял программы другого (например, DOS-программу на Mac), этот компьютер должен работать с машинными командами, которые ему изначально непонятны. Например, процессор типа 680x0 на Mac должен исполнять двоичный код, предназначенный для процессора 80x86 в PC. Процессор 80x86 имеет свои собственные дешифратор команд, регистры и внутреннюю архитектуру. Процессор 680x0 не понимает двоичный код 80x86, поэтому он должен выбрать каждую команду, декодировать ее, чтобы определить, для чего она предназначена, а затем выполнить эквивалентную подпрограмму, написанную для 680x0. Так как к тому же у 680x0 нет в точности таких же регистров, флагов и внутреннего арифметико-логического устройства, как в 80x86, он должен имитировать все эти элементы с использованием своих регистров или памяти. И он должен тщательно воспроизводить результаты каждой команды, что требует специально написанных подпрограмм для 680x0, гарантирующих, что состояние эмулируемых регистров и флагов после выполнения каждой команды будет в точности таким же, как и на реальном 80x86.
Это простая, но очень медленная работа, так как микрокод внутри процессора 80x86 исполняется на значительно более быстродействующем уровне, чем эмулирующие его внешние команды 680x0. За время выполнения одной команды 80x86 на 680x0, реальный 80x86 может выполнить десятки команд. Следовательно, если процессор, производящий эмуляцию, не настолько быстр, чтобы компенсировать все потери при эмуляции, то программы, исполняющиеся под эмуляцией, будут очень медленными.
Выходом в таких случаях является использование так называемых прикладных сред. Учитывая, что основную часть программы, как правило, составляют вызовы библиотечных функций, прикладная среда имитирует библиотечные функции целиком, используя заранее написанную библиотеку функций аналогичного назначения, а остальные команды эмулирует каждую по отдельности.
Соответствие стандартам POSIX также является средством обеспечения совместимости программных и пользовательских интерфейсов. Во второй половине 80-х правительственные агентства США начали разрабатывать POSIX как стандарты на поставляемое оборудование при заключении правительственных контрактов в компьютерной области.
POSIX – собрание международных стандартов интерфейсов ОС в стиле UNIX. Использование стандарта POSIX (IEEE стандарт 1003.1 – 1988 г.) позволяет создавать программы стиле UNIX, которые могут легко переноситься из одной системы в другую.