W010749 Контрольная работа Множественные прикладные среды

Содержание

Введение 3

1 Реализация прикладных сред 4

2 Организация множественных прикладных сред 7

3 Виртуальные машины в реализации множественных прикладных сред 8

Заключение 12

Список литературы 13

Введение

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

И в настоящее время вспомогательное программное обеспечение дает возможность пользователям отдельных ОС включать посторонние программы (к примеру, Mac и UNIX дают возможность исполнять программы для DOS и Windows). Однако в зарождающемся поколении операционных систем ресурсы для выполнения чужих программ делаются обычной составляющей системы. Подбор операционной системы более никак не станет очень сдерживать выбор прикладных программ. Несмотря на то, что стычка пользовательских интерфейсов программ для Mac, Windows и UNIX на одном и том же экране и вынудит пользователя немного постараться, однако все равно, множественные прикладные среды операционных систем вскоре будут такими же обычными, как мыши и меню.

Множественные прикладные среды гарантируют совместимость данной ОС с приложениями, прописанными для иных ОС и процессоров, на бинарном уровне, а никак не на уровне исходных текстов. Для пользователя, приобретшего в собственное время пакет (к примеру, Lotus 1-2-3) для MS DOS, немаловажно, чтобы он имел возможность включать этот полюбившийся ему пакет без каких-либо видоизменений и на собственной новой машине, выстроенной, к примеру, на RISC-процессоре, и функционирующей под управлением, в частности, Windows NT. 

1 Реализация прикладных сред

При осуществлении множественных прикладных сред разработчики встречаются с несовместимыми требованиями. С одной стороны, задачей любой прикладной среды считается осуществление программы по возможности таким образом, равно, как если бы она выполнялась на "родной" ОС. Однако потребности этих программ имеют все шансы входить в конфликт с конструкцией современной операционной системы. Специальные драйверы устройств могут быть в противоречии требованиям безопасности. Могут вступать в конфликт схемы управления памятью и оконные системы. Исключительно экономические проблемы (к примеру, цена лицензирования программ и угроза судебного преследования) кроме того могут оказать влияние на проектирование чужих прикладных сред. Однако наиболее огромной возможной проблемой считается продуктивность - прикладная среда обязана выполнять программы с оптимальной быстротой.

Этому запросу никак не могут угодить широко применяемые ранее эмулирующие системы. С целью уменьшения периода на выполнение чужих программ прикладные среды применяют имитирование программ на уровне библиотек. Эффективность данного подхода связана с тем, что большая часть современных программ работают под управлением GUI (графических интерфейсов пользователя) типа Windows, Mac либо UNIX Motif, при этом приложения расходуют значительную часть времени, производя определенные хорошо предсказуемые вещи. Они постоянно осуществляют вызовы библиотек GUI для манипулирования окнами и для иных соединенных с GUI действий. И это в таком случае то, что дает возможность прикладным средам компенсировать время, затраченное на эмулирование команды за командой. Усердно изготовленная прикладная среда обладает в личном составе библиотеки, имитирующие внутренние библиотеки GUI, однако прописанные в родном коде, то есть она совместима с программным интерфейсом другой ОС. В некоторых случаях такого рода аспект называют трансляцией для того, чтоб различать его от наиболее медлительного процесса эмулирования кода по одной команде за один раз.

К примеру, для Windows-программы, функционирующей на Mac, при интерпретировании команд 80x86 производительность может быть весьма невысокой. Однако если производится вызов функции раскрытия окна, модуль прикладной среды может перевести его на перекомпилированную для 680x0 подпрограмму раскрытия окна. Так как библиотекам GUI никак не нужно дешифрировать и моделировать каждую команду, в таком случае в частях программы, имеющих отношение к вызовам GUI ABI (Application Binary Interface - бинарный интерфейс прикладного программирования), эффективность может стремительно увеличиться. В следствии на подобных зонах кода скорость работы программы может быть достигнута (а возможно, и превосходить) темп работы на своем родном процессоре.

Сегодня в стандартных программах значимая доля кода занята вызовом GUI ABI. Apple заявляет, что программы для Mac расходуют вплоть до 90 % процессорного времени на осуществление подпрограмм из Mac toolbox, а никак не на неповторимые для данных программ действия. SunSelect свидетельствует, то что программы для Windows расходуют от 60 вплоть до 80 % времени на работу в ядре Windows. В следствии при эмуляции программы на базе GUI потери производительности имеют все шансы быть значительно меньше. SunSelect утверждает, то что его новейшая прикладная среда Windows, WABI (Windows Application Binary Interface - бинарный интерфейс прикладных программ Windows), вследствие очень оптимизированным библиотекам, на отдельных платформах при выполнении одних и тех же тестов способен обогнать настоящий Microsoft Windows.

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