Итак, как происходит загрузка компа? Сначала пользователь нажимает на

3 Авг 2005 - 16:47 Unknown BIOS
romby team >> 8687 >> 381.67

Итак, как происходит загрузка компа?

Сначала пользователь нажимает на кнопку Power на своем системном блоке. В конечном итоге, это приводит к тому, что подаются нужные напряжения на материнку и процессор начинает считывать с физического адреса 0xFFFFF0, куда отображается содержимое флешки, т.е. БИОС. Далее БИОС начинает производить проверку и инициализацию всяческого оборудования, копирует себя за пределы первого мегабайта оперативы (на последний мегабайт оперативы). При проверке железа компа, БИОС выводит в определенный порт номер чекпойнта, где сейчас выполняется код. Поэтому есть возможность сделать диагностическое у-во, отображающее число в этом порту и называемое ПОСТ-картой, потому что POST расшифровывается как Power On Self Test, т.е. "самотест при включении".
Во время этой процедуры, БИОС ищет всевозможные у-ва для загрузки. Если в BIOS Setup в качестве загрузочного указано не существующее у-во, то БИОС об этом честно говорит:)
Примерно так:
"DISK BOOT FAILURE, INSERT SYSTEM DISK AND PRESS ENTER"
Если накопитель есть (и если это СД/флопповод и в него вставлен диск/дискета и пр.), то БИОСом считывается первый сектор, помещается в память по адресу 0x07C0:0x0000 и передается управление на него.
Первый сектор на винче (точнее, нулевой) - MBR.
выдрал из своей проги:

typedef struct tagPartInfo {
  BYTE  BootFlag;    //80h - active partition, else 00h
  BYTE  BeginHead;   //First head or side of partition
  WORD  BeginSecCyl; //First cylinder(10b) and sector(6b)
  BYTE  FileSysCode; //System identification byte
  BYTE  EndHead;     //End head or side of partition
  WORD  EndSecCyl;   //End cylinder(10b) and sector(6b)
  DWORD BeginAbsSec; //Offset of first sector
  DWORD TotalSects;  //Number of sectors in partition
} PartInfo;

typedef struct tagMBR {
  BYTE Code[0x1BE];  //Boot-loader code(446 bytes)
  PartInfo part[4];  //Partition table
  WORD Sign;         //Signature(always 55AAh)
} MBR;

прим. - BYTE - байт, WORD - слово, т.е. 2 байта, DWORD - 2 слова (double word), т.е. 4 байта, QWORD - 4 слова (quad word), т.е. 8 байтов
как видно, первые 446 байтов - сам код загрузчика, остальное - описание разделов винча. В принципе, совсем не обязательно, что MBR будет выглядеть так, но на платформе X86 и использовании Win/DOS он всегда такой. На других платформах и с другими осями возможны другие, но они как раз неудобны несовместимостью с ДОСом, Виндой и программами под них (напр., Patition Magic).
Далее загрузчик ищет активный раздел, считывает его первый сектор (в нем лежит сам загрузчик операционки) с помощью INT13h в память и передает управление на него. И в случае АшЫПки:) MBR пишет "Missing operating system".
Ужасная система, не правда ли?:) Наконец-то приняв управление от образа MBR в памяти;), загрузчик операционки ищет ее файлы, грузит их в память опять же с помощью злополучного прерывания INT13h и наконец-то грузится ось (ну, или супер-пупер-загрузчик оси, примером которого являетя NTLDR). Если же ось не найдена:), то именно этот загрузчик ругается об этом след. сообщениями:
- NT (W2k/WXP/NT4/NT3.x) - "NTLDR is missing"
- DOS - "Non-System disk or disk error".
При загрузке с дискеты, одна стадия проглатывается: в нулевом секторе на ней лежит не MBR, а загрузчик Оси, который идентичен тому, что встречается на винчах. Дело в том, что первый сектор раздела или дискетки содержит структуру, описывающую файловую систему, и в этой структуре специально с начала выделено некоторое место под код.
Конечно, можно спросить почему все сделано так, а не иначе, но "ответом ему была тишина".:( Если серьезно, то так сложилось. Скажем большое спасибо за это в частности M$, сопровождавшую развитие (тогда еще IBM) PC с самого начала.
Теперь отвечу на вопрос использования INT13h. Это прерывание специально заточено для работы со всяческими контроллерами, на которых висят диски. С помощью него программы могут писать, читать, форматировать и вообще вытворять с диском почти все что угодно:) Только вот и оно не без глюков:( Все наверное слышали про проблемы работы БИОСом с большими винчами. Так в них помимо процедур идентификации виновато еще и INT13h:( На самых новых БИОСах с поддержкой LBA48, это прерывание наделено поддержкой LBA48, т.е. всех ныне существующих винчей, но чем дальше отодвигаться в прошлое, тем меньший объем винта поддерживает INT13. Скажем, на материнках под первопень оно поддерживает 8ГБ винчи :-{ Хотя можно поставить винч и бОльший, например, 20ГБ и он полностью распознается БИОСом, но все равно будет возможность загрузить систему только с первых 8:( Это конкретная засада:( Конечно, можно тогда задать вопрос почему у ОСей таких проблем нету. Дело в том, что современные (и не очень) операционки используют свои процедуры работы с винтами, сводящиеся к работе по портам в драйверах. Древности в роде ДОС лишены этой возможности и идут через не всегда хорошие сервисы БИОСа...
Более того каждый контроллер Mass Storage (т.е. для работы с накопителями) может с помощью своего БИОСа проапгрейдить "стандартный" INT13h на поддержку своих дисков. Поэтому при наличии (SCSI-/IDE-/SATA-/RAID-)контроллера со своим БИОСом, под ДОСом видны диски на нем. Удобно:)

выводы:
- при возможности есть смысл глядеть в сторону не вынтел(x86)-платформу. Очень многие моменты там реализованы действительно красивее
- если БИОС винч хоть как-то видит (пускай на Авто, но детектит), то загрузиться с него принципиально возможно
- для загрузки ОСи надо, чтобы прописаны все загрузчики, в противном случае какой-нибудь из них выругается.
- каждый загрузчик должен быть правильно настроен, в т.ч. и существовал Active-раздел на винче.

PS: камнями и тухлыми яйцами не кидайтесь... если что - поправим
PPS: сообщения приведены для Аварда. у Ами и Феникс могут быть другие, но аналогичные по смыслу

Опять проблемы большого винта