 |
|
|
|
Эпоха DOS vs эпохи UEFI. Взаимодополняющие антагонисты
Эпоха DOS vs эпохи UEFI Чем ближе находится уровень абстракции приложения к реальному аппаратному обеспечению, тем больше возможностей по управлению железом и по доступу к недокументированным функциям Дабы читателя не вводила в заблуждение комбинация слов DOS и UEFI, сразу отмечу, что статья посвящена скорее не тому, как UEFI позволяет загружать разделы на 2 и более Тб или управлять ими, а ситуации с точки зрения прикладного и системного программиста. Формально UEFI – это замена BIOS, но за счет EFI Shell предоставляется платформа для тестирования и, более того, создания на этой платформе нормального 64-битного приложения. Причем возможностей у него будет на порядок больше, нежели у такого же приложения, но для 32-битной ОС. За счет модульности и самой концепции EFI создается впечатление, что работаешь с классической микро-ОС типа MS-DOS 5.0, но с более мощными возможностями, которых не было у «старой» DOS, на основе которой можно создавать только 16-битные и, с небольшими трудностями за счет экстендеров, 32-битные. Классический DOS – это архитектурные ограничения в 16 бит Сейчас уже можно с определенной долей уверенности сказать, что эпоха DOS (Disk Operating System) в той классической реализации Microsoft/IBM, по которой многие ее собственно и знают, ушла безвозвратно. Да, для своего времени система была просто изумительна. Несмотря на кажущуюся с первого взгляда простоту, она была вполне эффективна для решения многих задач, а именно: управление файлами, работа с оперативной памятью (первоначально только в пределах первого мегабайта), прямой доступ к портам ввода/вывода и т.п. В чем же заключалась изюминка такой простоты? А в том, что за счет отсутствия необходимости создавать различные уровни абстракции, у пользователя был прямой доступ к оборудованию. За счет этого можно было создавать приложения, «раскручивающие» железо на все 100%. Конечно, никто не отменял наличия деструктивных факторов – вирусной активности, неправильно спроектированного ПО и прочих неприятных моментов. Однако в большинстве случаев работа выполнялась корректно и быстро. Давайте вспомним, как вообще происходила загрузка рабочей станции в эпоху MS-DOS/PC-DOS/Dr-DOS. Первым делом отрабатывала POST (Power On Self Test) программа из ПЗУ, которую все привыкли называть BIOS (Basic Input/Output System). Инициализировались низкоуровневые подсистемы, в том числе видео- и дисковые контроллеры. И затем управление передавалось непосредственно на загрузочное устройство, на котором, в свою очередь, находился MBR (Master Boot Record) – небольшая подпрограмма, решающая, а что и откуда будет загружено далее. Под «что» подразумевается, конечно, операционная система, а под «откуда» – необходимый раздел на жестком диске. Далее происходила посекторная загрузка драйвера, умеющего работать с форматом файловой системы, на которой и находились дальнейшие данные – в случае с реализацией DOS от компании IBM это был файл IBMBIO.COM [1] (IO.SYS для Microsoft). И затем следовала подгрузка в ОЗУ ядра самой DOS – IBMDOS.COM (MSDOS.SYS). Понятно, что в качестве формата файловой системы выступала FAT16. На фоне современных журналируемых систем NTFS/EXT4/ZFS она кажется настолько примитивной и имеет столько ограничений в архитектуре, что возникает закономерный вопрос: почему тогда не придумали что-либо лучшее? Статью целиком читайте в журнале «Системный администратор», №1-2 за 2014 г. на страницах 50-54. |
АНТОН БОРИСОВ, системный аналитик компании Сhiltеrn Ventures, Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
