АкушерствоАнатомияАнестезиологияВакцинопрофилактикаВалеологияВетеринарияГигиенаЗаболеванияИммунологияКардиологияНеврологияНефрологияОнкологияОториноларингологияОфтальмологияПаразитологияПедиатрияПервая помощьПсихиатрияПульмонологияРеанимацияРевматологияСтоматологияТерапияТоксикологияТравматологияУрологияФармакологияФармацевтикаФизиотерапияФтизиатрияХирургияЭндокринологияЭпидемиология

Реализация функций API на уровне ОС

Прочитайте:
  1. B) передние рога на уровне поясничного утолщения спинного мозга слева
  2. E Определение в крови уровней мочевины и креатинина
  3. IV. Исследование функций фагоцитов
  4. Анатомо-морфологическая база высших психических функций
  5. Анатомо-морфологическая база высших психических функций.
  6. Афазия. Виды, локализация функций в коре головного мозга.
  7. Билет 15. Проблема локализации высших психических функций
  8. Билет 19. Учение о системной динамической локализации высших психических функций
  9. Болезнь начинается не в физическом теле: она зарождается на уровне вибраций, излучаемых нашими убеждениями.
  10. В зависимости от того, какая из функций памяти страдает больше, можно также особо выделить следующие виды амнезии.

При реализации функций API на уровне ОС за их выполнение ответственность несет ОС. Объектный код, выполняющий функции, либо непосредственно вхо-


дит в состав ОС (или даже ядра ОС), либо поставляется в составе динамически загружаемых библиотек, разработанных для данной ОС. Система программиро­вания ответственна только за то, чтобы организовать интерфейс для вызова это­го кода.

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

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

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

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

Хорошо известным примером API такого рода может служить набор функций, предоставляемых пользователю со стороны ОС типа Microsoft Windows — WinAPI (Windows API). Надо сказать, что даже внутри этого корпоративного API суще­ствует определенная несогласованность, которая несколько ограничивает пере­носимость программ между различными ОС типа Windows. Еще одним приме­ром такого API можно считать набор сервисных функций ОС типа MS-DOS, реализованный в виде набора подпрограмм обслуживания программных преры­ваний.


Дата добавления: 2015-01-18 | Просмотры: 527 | Нарушение авторских прав



1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 |



При использовании материала ссылка на сайт medlec.org обязательна! (0.003 сек.)