Реальный и защищенный режимы работы процессора. Интерфейс прикладного программирования. Функции ADI и их реализация

Источник: Зубков С.В. Assembler для DOS, Windows и UNIX, 2000

Реальный режим (real mode) – режим, в котором процессор ведет себя идентично 8086 – адресация не выше одного мегабайта памяти, размер всех сегментов ограничен и равен 64 Кб, только 16-битный режим.

Защищенный режим (protected mode) – режим процессора, в котором действуют механизмы защиты, сегментная адресация с дескрипторами и селекторами и страничная адресация.

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

Источник: Википедиа

Интерфе́йс программи́рования приложе́ний (англ. Application Programming Interface, API; по-русски произносят [ а́пи ]) — набор стандартных библиотечных методов, который программист может использовать для доступа к функциональности другой программы. Использование API является методом достижения абстракции. Как правило, API определяет способы взаимодействия между программами более низкого уровня и более высокого уровня со стороны более высокого уровня.

Например, практически все операционные системы (Unix, Windows, MacOS, и т. д.) имеют некоторый API, поэтому программисты могут создавать приложения согласованные с этой операционной системой. Несмотря на то, что API созданы для программистов, в конечном счёте они полезны для пользователей, потому как гарантируют, что все программы использующие общий API будут иметь похожий пользовательский интерфейс, а это способствует более лёгкому пониманию новых программ.

С другой стороны, отличия в API различных операционных систем существенно затрудняют перенос приложений между платформами. Существуют различные методы обхода этой сложности — от написания «промежуточных» API (Qt, Gtk, и т. п.) и введения стандартов на API в языках программирования (например, стандартная библиотека языка C) до написания интерпретируемых языков, реализуемых на разных платформах (sh, perl, php, tcl, Java, и т. д.)

Так же необходимо отметить, что в распоряжении программиста часто находится несколько различных API, позволяющих добиться одного и того же результата. При этом система интерфейсов имеет структуру «леса» — существуют API различных уровней, обеспечивающие выполнение каких-то операций. При этом реально API высокого уровня абстракции программно реализованы на основании API более низкого уровня.

Например: для того, чтобы увидеть в браузере строчку «Hello, world!» достаточно лишь создать HTML-документ с минимальным заголовком, и простейшим телом, содержащим данную строку. Что произойдёт, когда браузер откроет этот документ? Программа-браузер передаст имя файла (или уже открытый дескриптор файла) библиотеке, обрабатывающей HTML-документы, та, в свою очередь, при помощи API операционной системы прочитает этот файл, и разберётся в его устройстве, повызывает через API библиотеки стандартных графических примитивов операции типа «очистить окошко», «написать выбранным шрифтом Hello, world!», при этих операциях библиотека графических примитивов обратится к библиотеке оконного интерфейса с соответствующими запросами, уже эта библиотека обратится к API операционной системы с запросами вида «а положи-ка мне в буфер видеокарты вот это».

При этом практически на каждом из уровней реально существует несколько возможных альтернативных API. Например: мы могли бы писать исходный документ не на HTML, а на LaTeX, для отображения могли бы использовать любой браузер, различные браузеры, вообще говоря, используют различные HTML-библиотеки, плюс к тому, все это может быть (вообще говоря) собрано с использованием различных библиотек примитивов и на различных операционных системах.

Основными сложностями существующих многоуровневых систем API, таким образом, являются:

• Сложность портирования программного кода с одной системы API на другую (при смене ОС, например)
• Потеря функциональности при переходе с более низкого уровня на более высокий. Грубо говоря, каждый «слой» API создаётся для облегчения выполнения некоторого стандартного набора операций. Но при этом реально затрудняется, либо становится принципиально невозможным, выполнение некоторых других операций, которые предоставляет более низкий уровень API.