Новости
Описание
Текущая версия
История
Скриншоты
OS Menuet
Дистрибутивы
Загрузчики
Русификация
Программы
Разное
Статьи
FAQ
Hardware List
Рассылки
Публикация
Конкурс
О Menuet
Другие OS
Программисту
|
|
|
(c)VaStaNi 2003, Kharkov, Ukranian. Привет всем почитателям ассемблерных мучений и радости победы! Хорошо, конечно загружаться с винта, культурно и прочее..., но не хочет у меня bootmf32.dat () работать, хоть стреляй его!!! Спасибо конечно всем кто работал над этим кодом и фину за MENUET тоже хорошая штука, спасибо потому что, ... …потому, что такие упрямые и чокнутые самоучки-программисты как, я от неудач только ещё больше хотят победы... они просто так не сдаются, и берутся за дело! И вот, наконец-то! 13.09.2003 я закончил все проверки и отлов последних глюков, но не bootmf32.dat уже, а нечто нового… Итак, с сего дня приступил я, значит к прозе, которую ты уважаемый, пытаешься читать. Извини, дорогой, но сей автор любит все по порядку и по полочкам, в хронологическом порядке, поэтому, о чем этот бред ты узнаешь позже... Итак, как я и говорил, не отрабатывал bootmf32.dat положенного, причем именно дома!!! А на работе пошел гад(!), как будто все верно автор заколбасил! Обида? Западло? Конечно! Но не только, это стимул подчас! Иначе я, как и многие такие же упрямцы, не шел бы вперед, вверх, преодолевая, прежде всего себя, а затем и барьеры. Может еще кто-либо имел такой же результат, разочаровался и бросил эту затею с загрузкой..., а может, плюнул на MENUET, а заодно на ассемблер!?... Пишу, прежде всего, таковым! Дружище! Неудачи временны, победа всегда вслед упорству поиска ответа и оплата скрупулёзного труда! Радуйся! Автор этих строк, как будто всё выяснил с этим делом (хотя кто не заблуждается?), разнюхал и усовершенствовал, вернее сказать переработал, усек лишнее, оптимизировал и дополнил код. Т.е. исходником для меня и отправной точкой был bootmf32.asm и MENUET ver.0.73, когда в мае 2003 я только познакомился с ними из www.menuet.narod.ru. И вот, вооружившись, прежде всего DiskEdit Norton Utilites 2000, некими куцыми сведениями по FAT32 и FASM ver.1.46 (http://flatassembler.net) началось… Прежде всего, выяснилось, что всё вроде бы «на местах», но на оглавление диска RootDir прога выходит не верно. А поскольку на работе грузится ось, то скорее всего это мой винт того... т.к. я его мучил ранее Partition Magicами разных версий от PowerQuest Corporation, да и умирал он несколько раз и ручками приходилось оживлять BOOT... Приступил я к винту значит! На работе грузится ведь, значит должно работать! И вдоль я его и поперек - ничего не движется! Я его и дефрагментаторами и докторами 2-3 разных фирм - никак! Размеры кластеров менять пробовал и прочее - ничего! ...А хочется ведь! Не форматировать же 10Гб данных только, чтоб загрузить? Вообще много чего было, всего уже не упомнишь да и стоит ли... На всякий случай скажу, что может я и не прав в отношении bootmf32.asm, но стал я его уродовать и двигаться к цели и познавать, как сие работает и как должно работать, стало быть... Конечно в комплект «инструментов познания» надо добавить дебаггер. Под рукой “лежал” известнейший TD.EXE от борландов. А потом как обычно - аппетит приходит во время еды, да и усмотришь то, что кто-то не видел, а может некогда кому-то было... Не буду тебя больше мучить дорогой, и скажу без лишней скромности, что получился чудненький загрузочный код. Вернее сказать универсальный, перемещаемый (т.е. без жесткой адресной привязки) код загрузчика и конечно удобные и полезные его разновидности под FAT32 и FAT16. Да, да FAT16 я не обидел, т.к. во-первых, вдруг у кого-то малый винт и деньжат маловато, а хочется чего получше поставить на старушку PC, почему не MENUET OS!? Ведь он именно для него! И вообще я за универсальность и за возможности, за перспективу, за выбор! Во-вторых, если делать новое, то старое забывать нехорошо, во всяком случае, совместимость нужна, поэтому надо будет кому-то KERNEL научить все же с ним работать. Наверное пока недосуг основным авторам этого творения, просто вперед идти хочется больше чем оглядываться назад... А может в это время ось уже умеет работать с другими файловыми системами? Пока я упорно и периодично возился все лето много измениться могло, я обкатывал на 073 версии, а вот заглянул на страничку там уже о 075 разговор идет… Не пробовал еще… Но мы ведь о загрузчике говорим, а это отдельный стартовый код для любой оси, на этом этапе машина только приходит в себя после “сброса” об пол! Шучу! Не пробуй так! Далее, скажу, что мой код компилируется тобой по разному и получается либо программка типа COM под DOS, или DAT файл для пункта меню boot.ini (XP/NT), как предлагалось в bootmf32.asm или BIN файл, как образ BOOT сектора первого раздела жесткого диска. Но это лишь немного отличает его от исходного варианта. Следующая особенность - загрузка kernel.mnt из каталога OS и выдача сообщения на дисплей, что он искал значит и где, т.к. не нашел и следовательно не запустил искомое. В случае успешного поиска каталога OS и файла ядра kernel.mnt в нём, вы естественно увидите собственно его работу, т.е. первые этапы MENUET OS. Говоря об аварийных сообщениях предшественника, можно сказать, что там сообщений, как таковых в программе не было. Вместо этого он имеет условную компиляцию кода в отладочном режиме – Debug. И скомпилировав именно в этом варианте, можно пытаться гадать по коду ошибки на экране… что бы это могло быть? И самое основное - что предпринять? Ну а если тебе повезло, скажем, то конечно всё выглядит ОК. Но хорошо то оно только тогда, когда ты уверен, например, что твоё оружие осечек не даёт. Разве в бой сомнительное или случайное берут? Я думаю дело ясно. Итак, окрестил первое творение boot32mt.asm. Но дело то не в названии, конечно. Итак, он ищет директорию MENUET.074 по умолчанию, т.е. именно этот путь «прописан» в моем ASM коде, меняй его и наслаждайся ЗАГРУЗКОЙ! Зачем это? Думаю настоящим коллекционерам версий MENUETа этот код просто великолепный подарок, т.к. стоит изменить расширение с 074 на 075 скажем или на 065 и будет загружен и запущен файл именно этой версии. Тут и чайник понимает, что расширение директории в данном случае не что иное, как версия оси ! А кто сказал, что директория не должна или не может иметь расширения? Может! И давно! Используем ребятухи! Не люблю я все скопом, все в кучу, да еще в корень диска файлы насыпать, да еще если на системном... Понятно короче. А кто сказал, что диск C: обязательно системный - ненасытные буржуины из мелкомягких ? Почему надо обязательно ось на C: ? А если мне на другой хочется или временно я, скажем, привинтил винт и его юзать хочу !? Почему не могу !? НАДО !!! Так вот дружище, представь себе следующую конфетку - «сбросил» ты, значит свою «тачку», а она промурлыкала тебе как обычно и запускает, скажем F:\MENUET.075\kernel.mnt, причем ты точно знаешь, что F: у тебя не то чтобы загрузочный, а он вообще SLAVE !!! И стоит последним, четвертым по счету HD на IDE2, да еще и FAT16 у него и всего то 120Мб, со времен потопа!!!! И ты успешно грузишь ядро kernel.mnt именно оттуда! Да и при этом, твой C: имеет FAT32! Ну как? Впечатлил? Если нет, то ты братишка, что называется еще пороху не нюхал в железючностях и проблемностях этой нелегкой житухи... извини. Смею тебя уверить бывают в жизни ситуации. А про автомат Калашникова знаешь наверняка, надеюсь. Представь себе операционку, что так же надёжна, устойчива, неприхотлива и всегда стреляет с любого диска с любыми ресурсами! Разве без ассемблерщика здесь обойтись! Разве утратил в жизни смысл гениальное - это просто! Ведь это наш девиз! Мы – АССЕМБЛЕРЩИКИ подковываем блох! Некоторые, правда, смеются над нами как над динозаврами, но это от незнания больше или лени, простим их… А от последнего подарочка, надеюсь, некто просто будет писать кипятком от удовольствия (пардон!) т.к. надоело мне DiskEditом BOOT сектора менять, да и запороть диск недолго (бывало и такое, за все надо расплачиваться), поэтому заколбасил я в порыве вдохновения УНИВЕРСАЛЬНЫЙ ИНСТАЛЛЯТОР BOOT сектора, возможности которого немного звучали выше. Если у фанатика есть уж идея (под час навязчивая) то нужно ее родить (воплотить) иначе больной совсем будешь [:-))). В принципе от него недалеко и до мультизагрузчика любой оси, но таковых написано вполне, зато код этого инсталлятора поможет пытливым узнать, как они работают и как подменяются BOOTы по выбору пользователя при загрузке. Неплохо работает в этом стиле профессионально и качественно сделанная мультизагрузочная программа System Commander Deluxe от V Communications, Inc. Хоть и старенькая v.4.0 от 97г. изготовления значит у меня, но не хочу ее выкидывать! Хороша! Поддерживает FAT32, видит новые инсталляции осей, изменений BOOTов, определяет и NTвых загрузчиков, гибка в настройках и не требует новых партиций... Советую экспериментаторам различных осей и их конфигураций, кто еще ищет! Тут они про себя пишут, что они вот где: . Заглянул вот, любопытно, что нового есть… и что же – готовьте зелёные бумажки! 7я версия на прилавке, пожалуйста! Интересно теперь, что наши братья «робингуды» кряк людям дают ли и где дают то… Несправедливо с кряком то? А что справедливого в том, что людей вышвыривают на помойку, например. Я вот уже 4 месяца без работы. Вроде не дурак совсем, чего-то могу…, а буржуазная система таких честных в унитаз значит… Несогласный Я!!! /правильно Шариков высказывался/. Вот и упражняю, ум значит, чтоб не свихнуться совсем… у каждого свой наркотик в жизни, наверное… Данный файл входит в комплект архивного ACROBOOT.ZIP, который состоит из: Acrobatic BOOT.DOC - собственно его вы и читаете… FAT16\ boot16mt.asm - сырец на 3 варианта загрузки MENUETа на FAT16; FAT16\ boot_com.bat - командный файл компиляции boot16mt.com для FAT16; FAT16\ boot_dat.bat - командный файл компиляции boot16mt.dat для FAT16; FAT16\ boot_bin.bat - командный файл компиляции boot16mt.bin для FAT16; FAT32\ boot32mt.asm - сырец на 3 варианта загрузки MENUETа на FAT32; FAT32\ boot_com.bat - командный файл компиляции boot16mt.com для FAT32; FAT32\ boot_dat.bat - командный файл компиляции boot16mt.dat для FAT32; FAT32\ boot_bin.bat - командный файл компиляции boot16mt.bin для FAT32; ACROBOOT\ acroboot.asm - сырец инсталлятора/восстановителя BOOT сектора для HDD1 или HDD2 с автоопределением FAT32 или FAT16 и сохранением оригинала BOOTа; ACROBOOT\ build.bat - командный файл компиляции acroboot.com; ACROBOOT\ codfat16.inc - сырец только кода BOOT сектора для FAT16; ACROBOOT\ codfat32.inc - сырец только кода BOOT сектора для FAT32; NTLDR\ ntldr.asm - ( ! + ! ) сырец загрузки и запуска системного файла NTLDR операционных систем Windows XP(NT) для FAT32 из среды DOS; / откатано и проверено на XP / NTLDR\ create.bat - командный файл компиляции. Базовым файлом для глубокого рассмотрения принципов можно считать boot32mt.asm, т.к. именно этот код родился первым, первым отлаживался, оптимизировался и обкатывался, а уж производными были затем: boot16mt.asm, codfat32.inc, codfat16.inc, и конечно все «сливки» загрузки в acroboot.asm. А вот ntldr.asm (ntldr.com) для тех, кто работает регулярно в DOSе, обкатывая, например куски кода под железо или ещё зачем-либо, а затем имеется большое желание быстренько загрузить Windows XP(NT) прямо из DOSа! Базовый здесь тоже был boot32mt.asm. Кроме того, этот файл представляет «спортивный» интерес т.к. наиболее проблемен с точки зрения «втискивания» кода в ограниченный объём BOOT сектора 512 байт минус (великоватый по сравнению с FAT16, но диктуемый стандартом) объём системных данных сектора FAT32 = 90 байт в начале и 2 самых последних байта, которые являются BOOT сигнатурными (опознавательными). Итого, под собственно КОД программы остаётся 420 байт, КОТОРАЯ ОБЯЗАНА : 1. Найти BOOT сектор, посчитать системные данные с целью запоминания основных констант поиска и чтения кластеров FAT32. 2. Найти в корне диска директорию MENUET.074, например, и перейти в неё. 3. Найти в первых кластерах оглавления директории файл KERNEL.MNT, перейти в его первый кластер. 4. Затем читать все его кластеры до последнего и запустить, наконец. 5. В случае, если не находится именно эта директория или именно этот файл вывести внизу слева яркое сообщение на экран, где содержится вся информация, которую отрабатывал код но не нашёл. Базовых «аварийных» сообщений четыре, вот они: HDD 1m :\MENUET .074\KERNEL .MNT ??? - не найден на HDD1 Master; HDD 1s :\MENUET .074\KERNEL .MNT ??? - не найден на HDD1 Slave; HDD 2m :\MENUET .074\KERNEL .MNT ??? - не найден на HDD2 Master; HDD 2s :\MENUET .074\KERNEL .MNT ??? - не найден на HDD2 Slave. 6. После прочтения сообщения, пользователь нажимает любую клавишу и машина полностью перезагружается. Такая вот неслабая прихоть автора… Правда я несколько некорректен на счёт объёма, поправимся немножко, ведь впечатляет работоспособностью именно КОД, а не текст, а сам текст не содержит интеллекта, но необходим для сообщений в приличных прогах, либо является шаблоном для поиска, заготовкой… А поскольку всегда хочется лучше чем примитивно и больше чем скупо, то вычти из тех самых 420 байт длину текста сообщения. Сообщение у нас солидное по длине для такого рода программулины, посмотри выше на п.2.! А ведь тогда получается, что весь описанный выше «разум» этого самого BOOT сектора, под любимый многими FAT32 необходимо ВТИСНУТЬ в каких нибудь 384 байта (фактически 380 занял)! Вот это и есть ассемблер, мой дорогой и та самая подкованная блоха… А результат работы этой «блохи» ты можешь лицезреть самостоятельно. Перед тобой, надеюсь, находится листинг boot32mt.asm хотя бы на экране. Рассмотри его повнимательней, он предельно прост и прозрачен, оснащён комментариями в «существенных» местах программы. Итак, ты уже насмотрелся на этот «шедевр» и хочешь знать правильность своего впечатления, поэтому читаешь далее мои краткие пояснения, я и так разошёлся что-то мыслью по тексту. Итак, сначала объявляются все возможные константы, присваиваются значения констант из перечня возможных. Это касается и условной компиляции кода, т.е. получение различного по назначению выходного, рабочего кода от одного исходника boot32mt.asm путём задания значений констант, которые влияют на этот процесс. По сути, файл этот 3 в 1. Т.е. поскольку у этих 3х очень много общего и основного, я не стал плодить отдельные файлы, а оставил этот принцип, по аналогии прототипа - bootmf32.asm. Не забывай правильно выставить значение VARIANT перед компиляцией предлагаемыми командными файлами xxxx.bat. Думаю яснее ясного, что эта константа определяет выбор 1 из 3х. Далее необходимо отметить, что константы hdbase, hdid определяют параметры HDD с которым будет иметь программа, т.е. именно там и будет осуществлён поиск и загрузка файла. Это очень важно т.к. представь себе «тупость» машины после включения (сброса) – она не знает литер дисков! Ей нужно точно сказать, на самом низком уровне с основным разделом какого HDD нужно работать. Но тут немного мысли в сторону и тут появилась идея акробатики! Да, именно эти две константы и обеспечат тебе загрузку с другого диска MENUET OS, даже если он подключен как Slave! Вот для логических дисков, я задачу не ставил, да и стоит ли. Сам BOOT сектор загружается в память BIOSом по адресу 0x0000 : 0x7C00 и стартует процессор в эту же точку. А вот какой BOOT загружается – это определяют, прежде всего, установки BIOSа, да и мультизагрузчик тоже… Например тот, о котором упоминал выше. Допустим у тебя всё просто, в BIOSe установка - грузиться с C: диска (кстати, тут всегда постоянство и он всегда HDD1 и Master) и никаких «мультей» у тебя не установлено. Тогда, если заменить на C: BOOT сектор нашим вариантом (хотя бы с помощью DiskEdit Norton Utilites), да ещё и с параметрами hdbase и hdid как ты хочешь, то это и «отвязывает» тебя от C: диска! Но это если тебе надо, конечно. Ну не тебе так другому, да и вообще – возможность это уже кое-что! К стати сам C: обычно страдает больше всего, при повреждениях разного рода… это и вирусы разные разрушительные, т.к. цель уничтожить систему, да и свопы, темпы разные там пишут, поэтому сбой, бросок питания и привет! Но не пугайся сильно, это я про надёжность вообще, но как предпринятая мера это тоже вариант, почему и нет. Иногда люди и этим занимаются… Вот эти то фокусы с параметрами замены параметров и на каком HDD подменять BOOT сектор и осуществляет DOS программулина acroboot.com. Итак, о структуре листинга bootmf32.asm и его частях. Собственно читалка любого сектора диска в память это процедура с меткой hd_read:, что в самом конце листинга. Это база, основа значит чтения (поиска, анализа каталога диска, загрузки файла). Читает она так называемые абсолютные номера секторов диска, который должен быть в EAX при старте процедуры. А вот основной код программы начинается естественно с метки START:. Итак, первый встреченный ниже call hd_read грузит в память нулевой сектор (MBR), который содержит системную информацию о разделах HDD. Из всего этого берём только стартовое, начальное смещение первого раздела диска в виде номера сектора по адресу 0x1C6. Именно там и расположен наш драгоценный BOOT сектор! Но коду интересна его системная информация о разбиении диска и константы, которые определяют, как считаются кластеры, их размер и прочее. Это мы берём и подсчитываем, запоминаем для дальнейшего использования. Это та часть листинга, что сразу же после второго call hd_read,по листингу ниже. Почему далее мы вдруг натыкаемся на такой то текст? Зачем? Ведь это код программы, а не область данных? А процессору понятие область данных неведомо, это людям…, а ему адресацию подавай. Что посеешь – то пожнёшь. Затем и врезались в код, что этим мы очень просто осуществим привязку к началу текста (получим абсолютный фактический адрес) при любом положении программы в памяти. Это достигается при помощи call инструкции! Этот оригинальный приём я встречал не раз у виртуозов ASMа, ещё для самопальных 8ми битных компов ZX, да и хакеры такие финты любят, а это, как правило, профи! Стек, стек и ещё раз стек! С ним можно творить чудеса. Но нужно точно представлять, как он работает и какие инструкции с ним работают. В данном случае использовано то, что на стеке остаётся текущее значение IP регистра (счётчика), т.е. это адрес возврата из call, а это адрес в памяти (метка @H) сразу после самого кода команды call ! Ведь туда обязан вернуться процессор после финального RET в вызванной процедуре. Но это если вернётся, а мы по call попадаем на POP SI инструкцию, которая из стека возьмёт этот самый адрес в нужный нам регистр, вернёт значение регистра SP в прежнее состояние. Так что RET нам вовсе и не нужен, мы просто идём дальше по коду, отрабатывая его, а SI уже указывает на начало строки, Далее корректируем его чуть-чуть, сместив на метку @M, где начало имени нашего искомого каталога OS “MENUET.074”, который должен быть найден в корне диска. Почему у каталога расширение именно 074? Потому, что константа VER по умолчанию в самом начале листинга объявлена с этим значением. Изменив значение, ты, дорогой друг, получишь другое расширение и каталог OS естественно, в котором будет нужный и соответствующий версии файл ядра kernel.mnt. Красота! Не так ли? Печально только то, что для полноценной загрузки все ещё необходим msetup.exe в корне диска !? Да ещё и нужной версии! Но это выходит за рамки нашей цели, идеи, да и самой программы. От неё мы и так многого хотим. Будем надеяться, что в скором будущем кто-либо, например многоуважаемый господин Ville Mikael Turjanmaa, познакомится с моими потугами в загрузке MENUET OS, надеюсь оценит и примет верное, цивилизованное решение по устранению сего ограничения пользователя.? Поскольку абсолютный номер сектора начала корневого каталога диска уже вычислен, то сразу после текстовой информации начинается последовательное чтение в буфер собственно секторов оглавления корневого каталога. Читается CX секторов подряд и это не менее 1024 штук, что гораздо больше одного кластера любого размера. Помнишь ещё про мою неудачу? Так вот, причина была в том, что файла в самом первом кластере оглавления корня диска не было! Он «забит» был весь и не мог туда быть прописан. А зачем нам ограниченность эта с первым кластером, что теперь не пользоваться вообще, если не пишется, скажем, туда? Редактировать диск вручную что ли? А если человек не знает как, а если ему это и не надо знать то, он хочет пользоваться на то уж он и пользователь. Нет уж, хватит! Я с этим помучался уже. Даёшь отрыв от первых кластеров! Даёшь надёжность!… Да, но надо перебирать кластеры оглавления корня диска, наверное. Это хлопотно, т.к. это цикл в цикле. Перебирать кластеры, а в них сектора… Мутно как то… пробовал, да и код размером не балует… А зачем собственно? Можно проще и прямее. Нагло просто читать цепь секторов, да побольше, чтоб наверняка найти (у нас > 1024!). Ведь это корень диска, он, скорее всего кластеры один за другим пишет, а следовательно и сектора! Ну даже если и нет, что практически видел Disk Editом, то они всё равно рядышком были и если перебирать побольше, то всё ХО получается! Вот теперь наш расчёт на то, что в этих самых последовательно лежащих на диске секторах, несущих информацию о размещении каталогов и файлов корня диска встретится полное имя нашего искомого каталога, да ещё и его расширения “074” плюс байт атрибут-признака 0x10 (для каталога!). Всего 12 байт информации должно полностью совпасть, тогда это наш искомый каталог. Подобные задачи решаются x86ми процами классически строковыми командами. Так и делаем при помощи cmpsd трижды ( dword x 3 = 12 байт поиска ), получая каждый раз результат сравнения очередного dword. Но после любого несовпадения не забываем восстанавливать DI и SI, дабы возвратиться в начало строк гарантированно. Если перебор всех CX секторов завершился неудачно, выходим после loopw new_file_search и используя SI как ссылку на текст, выводим на экран текст, что и с какими параметрами диска искалось, проанализировав фактические значения hdbase, hdid в теле процедуры hd_read. Далее ждём нажатия «клавы» и если было таковое, то скрашиваем горечь неудачи переходом в RESET без лишних усилий пользователя. Если же каталог успешно найден, то SI уже указывает на начало следующей строки – имени файла, а из буфера чтения секторов черпается информация о номере кластера начала нашего каталога и вычисляется из него абсолютный номер сектора. Далее всё аналогично, т.е. производим перебор по секторам оглавления нашего каталога, ища заветное имя kernel.mnt и нормальный байт атрибут-признака для файла 0x20! Кстати он полностью совпадает с текстовым символом пробела, что облегчает нам вывод на экран при неудаче.? Нашёлся файл? Чудесно! Теперь переходя на Read_KERNEL: имеем в EAX абсолютный номер сектора, который содержит уже начало файла kernel.mnt!!! Грешно не загружать нужное, что и делаем для всех его кластеров. Затем стартуем в его начало через стек при помощи финального RETF. А на экране лицезреем знакомый процесс работы MENUETа! С чем и поздравляю! Обо всем не расскажешь, да и надо ли? Поэтому пытливый разберётся и дальше, а непытливому незачем всё это… Скажу только ещё, что для DOSовской COM программы последний участок кода, начиная с метки @startmovecode: перебрасывается вверх памяти. Мне понравился сегмент 0x8000. Туда затем прыгаем опять же через RETF и этот коротенький, но самодостаточный кусочек грузит и запускает файл. Это для того, чтоб загружаемый в память файл kernel.mnt не затёр собственно выполняемый код COM программы, ведь в его сегменте 0x1000 вполне могут быть загружены программы DOSа, а вдруг наша? Тогда перепишем собственный код телом загружаемого и, например, зависнем… Вариант DOS программы bootmf32.com натолкнул на нужную, как мне кажется, возможность загружать, скажем, Windows XP из DOSа или начальный DOS (Win95,98). Тут у нас kernel.mnt, там другой файл, ну и что тут теперь сложного? Так родился этот мутантик под названием ntldr.asm (.com). Кто внимательно присматривался к отличиям в загрузке DOSа или Windows 95 и NTшных Windows XP(NT), тот обратил наверное внимание на присутствие в корне C: их системного файла NTLDR. Собственно это он обрабатывает boot.ini он и грузить начинает. Он также присутствует в инсталлированном NTвом BOOT секторе оси! Дальше тебе всё ясно дружище? Аналогия тут - как две капли перцовки… Ну пришлось, конечно, дебагнуть процесс, отладиться… Короче грузится NTLDR BOOTом по 0x2000 : 0x0000. Туда же и стартует по завершении, регистры на входе особого рояля не играют, разве что стек разместить надо, чтоб не прописался телом загрузочного файла, который не мал! (кое-что из значений регистров для перестраховки устанавливается по аналогии оригинала, см. листинг). Но закавыка серьёзная получается с таблицей векторов прерываний. Дело в том, что после «сброса» машина имеет «девственную» таблицу прерываний никем не тронутую и все «рабочие» вектора указывают на верные точки входа в процедуры BIOSа! А что может иметься в ней после того, как мы поработали в DOSе? Там ведь всего валом модифицировано! Сам DOS, оживая, уже берётся за это дело, поди восстанови, а это важно… Хороший, красивый, профессиональный вариант - знать, как и откуда берётся «правильная» таблица из BIOSа или как её инициализировать принудительно, да еще, чтоб на разных BIOSах (машинах и поколениях) это работало надёжно. Но у меня такой информации нет… Возможно, кто-то дополнит этот пробел и будет хорошая «цаца» всё же. А пока эта проблема была решена в файле вариантом простейшей инсталляции-патча. Скомпилированную программу ntldr.com подставляем вместо оригинального системного NTLDR и она себя пропатчит данными векторов, от Вашего BIOSа(!). Для этого грузимся в DOSе, скажем с системной дискеты, сохраняем NTLDR где-либо для финального восстановления. Затем ntldr.com пишем под именем NTLDR поверх оригинала, т.е. даём разрешение перезаписать файл. Затем грузим Ваш XP(NT) как обычно. Когда программа запускается, то всегда анализирует регистр SS и по нему определяет, что это инсталляция или обычный режим DOS. Для запущенной COM программы всегда SS > 0. При инсталляции же она «фотографирует» большую часть «девственной» таблицы векторов в своё тело файла, перезаписывая свой первый сектор. Для этого зарезервировано достаточное поле под данные, с началом по метке TabINT:. А при запуске в DOSe прога восстановит таблицу, когда будет точно обнаружено присутствие и расположение файла NTLDR. Затем вверх памяти перемещается коротенький загрузочно-стартовый код, который и позволит стартовать NTLDR и собственно XP(NT). Следует оговориться, однако, что прога только под FAT32! Старые NT, как мне известно, под ним не грузятся… Тут может помочь пытливым либо раскрученный FAT16 в boot16mt.asm, либо попробовать подсунуть NTLDR от XP для старенькой NT… Да, мы ведь не договорили до конца все шаги по инсталлу. Итак, когда таблица сохранена, выдано сообщение, жмём что-либо и сразу перегружаемся. Пока машина борется с BIOSом, вставляем системную дискету, дожидаемся загрузки, восстанавливаем честное имя подменённому NTLDR как ntldr.com и скопируем его в удобный каталог, где его DOS всегда может найти по PATH строке… Наконец восстанавливаем системный оригинальный NTLDR из тех самих закромов, где припрятан был… Теперь проверяем всё в работе и мысленно благодарим автора. Кажется всё. Ну что ж други мои, на сем прощавайте, бывайте всячески здравы, счастливы и довольны! Спасибо за внимание! ДАЙ ВАМ БОГ ВСЯЧЕСКИХ БЛАГ ! ! ! 10 октября 2003 года, Харьков, Украина. Valyiskih Stanislav Nikolaevich. P.S. К великому сожалению автор не только безработный, но, наверное и не имущий т.к. на телефонизацию, «мыло», Интернет его заработков так и не хватило…. (На многое другое кажется тоже…) Посему ответить на возможные вопросы или пожелания не представляется возможным, хотя очень бы хотел. Единственно смогу периодически просматривать сайт либо из Интернет кафешек либо друзей просить… Надеюсь на положительные отзывы. Хотелось бы от кого нибудь получить совет, ссылки, направление как скажем, без криминала интеллектом в Интернете хлеб насущный зарабатывать… А что мы на сайте всё про кодинг? А про жизнь? Предложил бы также, админам подобных сайтов для фанов разработки иметь тематическую доску пожеланий, идей, проектов, возможных направлений развития, круглый стол обсуждения проблем и методов их решения, конкурсная редакция и оптимизация кода. Жалко тратить усилия по басне: «Однажды лебедь, рак и щука….» Коллектив это уже сила! Один разум хорошо – несколько гораздо лучше! Если жив буду, то презентую ASYNC.INC для ядра KERNEL.ASM. Это полный контроль любых COM портов на уровне ядра по IRQ 3, 4 COM1…COM16 !!! …Detect Chip UART, Plug & Play…, Rx FIFO…, … … В принципе хорошая beta уже созрела. Есть ли желающие катать её? При наличии помощи техинфой на родном языке по USB порту есть бешеное желание его «раскрутить» под эту ось. Пора подключать принтера, фото, сканеры… Да и свои «поделки» надо бы на него перетащить… АССЕМБЛЕРЩИКИ ВСЕХ СТРАН СОЕДИНЯЙТЕСЬ !!! P.P.S....скачал я в тот день "сборку" Ивана Поддубного и .... успешно угробил диск C:!!! Как уж там работает RD2HD не знаю, не разбирался, но "медицина показала", что сектор оглавления диска, где был файл menuet.img изуродован. Сам файл в положении Erase, а данные смещены вверх где то на 7 байт. Руками кое как сместил данные вниз, потерял один каталог. К счастливой случайности это был новый каталог MENUET.075. Пережить кое-что пришлось... Да и эмоций было... К стати не ожидал, но при аварии помогла прога ntldr.com, что в этом самом моём ZIPе. Т.к. после ручного восстановления надобыло грузануть XP, а уж из неё всё досконально проверить и восстановить профи-прогами... НАДЕЮСЬ что мои скромные труды не пропадут зря и НАРОДУ всё же будет доступен мой труд на его суд... Если есть возможность "повлиять" на автора(ов) ядра на "их языке" прошу переслать файл хотябы с краткой конкретикой о предложении "цивилизованной" загрузки оси из каталога, да образов тоже... Ведь это просто... Я бы и сам, но листингов 075 не вижу, а старое как то не хочется. Очень хотелось бы т.к. у меня виды на неё по причине сетевухи RTL8139 на обеих концах. Да и вообще пора, считаю грузить собственно файлы с HDD, а не только образ RD! Конечно с директории!!! |
