LINUX.ORG.RU
ФорумTalks

Читал про UEFI, много думал.

 , ,


4

3

Господа, читайте и изучайте UEFI, если всё ещё не. Это базовая база нынче!

Я когда-то писал на ассемблере в школе-универе для развлечения бут-сектора для дискет и HDD, MBR это называлось - это такой 512-байтный самый первый сектор диска, который автоматически считывался BIOS на x86 в память по фиксированному адресу и управление туда передавали. У меня был ThinkPad 755C для развлечений. Далее ты всё должен был делать сам. В 512-байтный код надо было запихнуть самодельный примитивный парсер корня FAT12/FAT32, чтобы он нашёл в корне ФС некий условный файл /kernel.bin и передал туда управление - это твой условной grub или вообще сразу же ядро самописной маленькой OS - я писал детскую OS, которая переводила cpu в protected mode и умела параллельные задачи запускать - мигание какой-то лампочкой клавиатуры и считывание каких-то байтиков с неё и какой-то крутящийся курсор. Это был мой kernel.bin бугага.

А нынче эти времена поменялись. Теперь нет никакого BIOS - точнее теперь эту сущность стали называть просто бездушно firmware и это firmware должно соответствовать спецификации UEFI. UEFI - это стандарт внешних и (где-то внутренних) признаков, которые этот BIOS должен проявлять. Раньше как было - BIOS на каждой матери был устроен как захотят, главное чтобы умел int 10h (видео), int 13h (диск), int 16h (клавиатура) и какие-то другие программные прерывания обрабатывать. Ну и ещё было выражение «зайти в BIOS» - это какая-то F1 клавиша и синий экран с менюшками и там можно было save changed and exit - но такой фигни могло и не быть и BIOS всё равно у тебя был. Внутри этих прерываний был чёрный ящик тащемта и работало оно только в 16-bit real mode. Теперь всё это выкинуто нахер. UEFI - это прям как маленькая OS, которая изначально работает в protected mode, там есть концепции драйверов, даже приложений. Есть разные фазы загрузки всего. Оно умеет парсить FAT32 и доставать оттуда загрузчики и приложения и исполнять всё это.

UEFI умеет парсить FAT32, в которой лежат файлики .efi в формате windows PE (MZ в начале файла, микрософт оставила свой след, бугага). В FAT32 есть разные папочки, в них разные .efi файлики, часть из которых имеет фиксированные имена и содержит дефолтные загрузчики и загрузчик этой вашей убунты оформлен как /boot/efi/EFI/ubuntu/grubx64.efi а сама /boot/efi есть точка монтирования vfat-раздела на диске, и этот раздел «осознаётся» UEFI firmware на старте системы.

Ещё у UEFI есть стандарт на хранение кучи key=value переменных - «efivars» которые открыты на чтение-запись, часть из которых имеет фиксированные имена и форматы, а часть пользовательские, можно даже туда телефон бабушки положить и он будет лежать во флешке на матери. Эти переменные можно в линуксах увидеть тут: ls -l /sys/firmware/efi/efivars - оно невозбранно смонтировано как type efivars. В этих переменных лежит и порядок загрузки с разных разделов и ещё всякой дофига фигни, а GUI вашего BIOS нынче просто просматривет эти переменные, а не хранит «настройки BIOS» в каком-то своём формате в чёрном ящике.

Вместо BIOS-прерываний типа int 16h теперь какая-то там системная таблица протоколов, в которой можно найти EFI_SIMPLE_TEXT_INPUT_PROTOCOL и поюзать клавиатуру.

UEFI стартует за несколько разных строго определённых «фаз», в UEFI есть свой шелл с фиксированными командами, в UEFI есть драйверы, есть приложения, есть спецификация на гуй и вообще дохрена всего, я охренел.

Короче господа, изучайте UEFI чтобы не быть чертилой. Это нечто неиллюзорно большое, куда АНБ конечно же напихала своих драйверов и приложений и пока ваш ноут грузится, он может успеть и в интернет сходить, но хорошая новость может быть в том, что UEFI позволяет вам там это выключить или поменять логотип вашего тынкпада на загрузке.



Последнее исправление: lesopilorama (всего исправлений: 4)
Ответ на: комментарий от ya-betmen

есть. он сам. его скелет, так сказать. стандарт открытый. а вот начинка этого скетела проприетарная. в этом и проблема.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

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

Не от процов, а от материнок и их драйверов.

и дёргали вызовы какого-то посредника

ACPI. ACPI-драйвера так и устроены, там псевдо-код.

anonmyous ★★
()
Ответ на: комментарий от Iron_Bug

а вот UEFI может и само делать много чего

Ничего он не может делать, после того, как ему сказали ExitBootServices(). Он в защ режиме работает, и если вы перенастроили ММУ, то всё, его код больше не замаплен.

anonmyous ★★
()
Ответ на: комментарий от Iron_Bug

как раньше ценились компы без ME, так сейчас будут цениться компы без UEFI.

Вот ведь каша в голове у человека… UEFI тут вообще не при чём: SMM как был до него, так никуда и не девался.

по крайней мере, для сетевых экранов это единственное безопасное решение. ну, либо полностью опенсорцный UEFI, если железо позволяет.

Он куда более опенсорсный, чем любой биос. ТианоКоре возьмите.

anonmyous ★★
()
Ответ на: комментарий от anonmyous

Он куда более опенсорсный, чем любой биос. ТианоКоре возьмите.

а есть варианты с полностью открытыми сорцами дров? и да «более опенсорцный» звучит как «немного беременный». софт бывает опенсорцный и не опенсорцный. понятия «более» или «менее» там не применимы.

и да, мне без разницы, гда зашиты зонды. мне вообще идея зондов не нравится. а вам, видимо, очень даже.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от Iron_Bug

и да «более опенсорцный» звучит как «немного беременный». софт бывает опенсорцный и не опенсорцный. понятия «более» или «менее» там не применимы.

Мля, вам выложили ВЕСЬ уефи в открытый доступ, но вы ругаете Интел, который это сделал. Ссылаясь на то, что вендоры таки добавляют проприетарные дрова… Мега-логика.

anonmyous ★★
()
Ответ на: комментарий от anonmyous

нет, туда выложили только пустую обёртку. а вот дрова никто не выкладывал. мне насрать, кто добавляет проприетарщину. это у вас извращённая логика: «вот тут опенсорц, он сам добровольно выгружается». а что там проприерасты и вот это всё - мы туда просто не будем смотреть, это виноваты какие-то «вендоры». вообще-то это, по сути, малварь. неизвестный бинарный код, сорцов которого никто не видел. и насколько он выгружается и что он может делать - это большой вопрос. привилегии на доступ ко всем ресурсам у него максимальные.

и, главное, что всё это абсолютно не нужно для получения каких-то параметров харда. а этот заменитель биоса нужен только для этого. и что обращение к ACPI через костыли сделано, совершенно искусственно - это тоже ненормально.

Iron_Bug ★★★★★
()
Ответ на: комментарий от anonmyous

ну, коребут пока не может только лишь всё. и это понятно. но это, по сути, вторая борьба с проприетарщиной, уже на новом уровне. но зачем?! если можно было её там вообще не разводить, обойдясь какой-нибудь тупой таблицей параметров харда. для загрузки оси этого вполне бы хватило. а теперь там ещё одна ось, кривая и которую надо патчить, чтобы она была опенсорцной. и опять те же грабли с неподдерживаемым железом и вот этим всем, которые с Linux мы уже проходили.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

нет, туда выложили только пустую обёртку. а вот дрова никто не выкладывал.

https://github.com/tianocore/edk2-platforms/tree/master/Drivers/ASIX/Bus/Usb/UsbNetworking

Совсем никто не выкладывал?

«вот тут опенсорц, он сам добровольно выгружается». а что там проприерасты и вот это всё - мы туда просто не будем смотреть, это виноваты какие-то «вендоры».

Пфф, да я вам ещё раз говорю. Если вы перенастроите ММУ как вам надо, то никакой уефай, включая и драйверы, вас больше не побеспокоит! Он сделан для загрузчиков.

бинарный код, сорцов которого никто не видел.

Ну вот я ссылку дал выше. Можете посмотреть, можете дальше ерунду нести.

и насколько он выгружается и что он может делать - это большой вопрос.

Насколько вы ММУ настроите, чтобы его в вашем адресном пространстве не было, настолько и выгружается…

anonmyous ★★
()
Ответ на: комментарий от anonmyous

ссылка на какую-то часть usb-шных дров - ага, отличное «доказательство» открытости всей фигни. только вот как-то неубедительно. и платформ, однако, поболее, чем одна или даже две.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

ссылка на какую-то часть usb-шных дров - ага, отличное «доказательство» открытости всей фигни.

Не понял, а на что я должен вам ссылку давать, на все драйвера сразу? Сами там пошарить по каталогам как-нибудь сподобитесь.

и платформ, однако, поболее, чем одна или даже две.

Понятно, по каталогам ходить не умеем… https://github.com/tianocore/edk2-platforms/tree/master/Platform Достаточно платформ?

Ссылка на основной EDK2 вот: https://github.com/tianocore/edk2 Там драйверов ещё больше.

anonmyous ★★
()
Ответ на: комментарий от yars068

Этих 512 (строго говоря, 446) байт недостаточно, чтобы разместить там даже примитивный драйвер файловой системы.

Примитивный драйвер не нужен, нужен огрызок, который сможет распарсить содержимое корня, найти среди файликов в корне нужный и узнать из каких секторов его можно достать. Файлик небольшой, несколько килобайт, не будет занимать дофига разных секторов, чтобы на манипуляцию с этим множеством секторов понадобилась какая-то йоба-логика. В общем, вот это вот удавалось без проблем примерно в половину 512 байт запихать. У меня даже исходники остались, могу дать почитать, ехехе.

Там вся логика – считать N байт по указанному адресу с устройства 0x80 в заданный регион оперативной памяти и сделать jmp в начало этого региона.

MBR с жёсткого диска BIOS сам читал автоматом в адрес 0x7c00 и jmp туда самостоятельно, это кодить было не надо, это дефолтное поведение всех материнок было.

lesopilorama
() автор топика
Последнее исправление: lesopilorama (всего исправлений: 1)
Ответ на: комментарий от Iron_Bug

а идею UEFI пропихивал Intel.

А мне показалось, что Microsoft. Ну видимо все гиганты поработали. От microsoft там осталось то наследие, что дефолтной файловой системой, понимаемой UEFI является FAT32, а формат файлов .efi - это Windows PE.

lesopilorama
() автор топика
Ответ на: комментарий от yars068

За исходником lilo далеко ходить не придётся, он как раз при установке создаёт вот эти 512 байт :

Я не понял к чему это. Но в целом 512 байт это достаточно дохрена машинного кода intel

lesopilorama
() автор топика
Ответ на: комментарий от lesopilorama

Файлик небольшой, несколько килобайт, не будет занимать дофига разных секторов, чтобы на манипуляцию с этим множеством секторов понадобилась какая-то йоба-логика

В ФАТ нет понятия сектора, там всё меряется кластерами. И если файл более одного кластера, то логика «манипуляций» будет одинакова для файлов любого размера. «Манипуляции» - элементарные, они много не едят. Едят преобразования C/H/S, деления всякие. Одно только собственно деление на x86 ASM-e - 14 байт кода. А чтобы только вычислить начало файла, надо как минимум перевести кластер в сектор, это три умножения и одно деленние, не считая плюсов и минусов. Давай свой код, посмотрим, как ты смог, а никто не смог.

lenin386 ★★★★
()
Ответ на: комментарий от yars068

Основное тело lilo лежит в файловой системе, в бут секторе лежит только код, который при отсутствии основного тела, сможет только «li» на экран выдать. Вы не знали этого штоле, линуксодиды?

lenin386 ★★★★
()
Ответ на: комментарий от lenin386

В ФАТ нет понятия сектора, там всё меряется кластерами. И если файл более одного кластера, то логика «манипуляций» будет одинакова для файлов любого размера. «Манипуляции» - элементарные, они много не едят. Едят преобразования C/H/S, деления всякие. Одно только собственно деление на x86 ASM-e - 14 байт кода. А чтобы только вычислить начало файла, надо как минимум перевести кластер в сектор, это три умножения и одно деленние, не считая плюсов и минусов. Давай свой код, посмотрим, как ты смог, а никто не смог.

Ты описал какую-то элементарную херню, которая у тебя поела от силы байт 30 уже и дальше заявил, что в в 512 байт ничего точно бы не влезло и никто не смог. Как не смог, если у тебя ещё после поедания твоих 30 байт ещё дохрена осталось, а ты уже почти всё сделал. Да все давно смогли, откуда у тебя инфа, что никто)

lesopilorama
() автор топика
Последнее исправление: lesopilorama (всего исправлений: 1)
Ответ на: комментарий от lenin386

Ну, я, честно говоря, код Lilo не смотрел (здесь должен быть смущённый смайл).

yars068 ★★★★★
()
Ответ на: комментарий от lesopilorama

Ты описал какую-то элементарную херню, которая у тебя поела от силы байт 30 уже и дальше заявил, что в в 512 байт ничего точно бы не влезло и никто не смог.

Ну, какбэ, не 30, а 60. А 60 - это на минутку четвёртая часть от 250, в которые ты якобы уложился. А это только перевод кластера в сектор. Ты даже дисковое прерывание ещё не вызвал. А это ещё байт 20. А прерыванию в c/h/s подавай. Опять делить. Код давай, гений.

lenin386 ★★★★
()
Последнее исправление: lenin386 (всего исправлений: 3)
Ответ на: комментарий от lesopilorama

Lilo, кстати, не может смотреть дальше 1023-го цилиндра, емнип. Мопед не мой, а со слов @bormant’а :) Он когда-то про это рассказывал где-то.

yars068 ★★★★★
()
Последнее исправление: yars068 (всего исправлений: 1)
Ответ на: комментарий от lenin386

Давай свой код, посмотрим, как ты смог, а никто не смог.

Вот только что создал репу. Поконвертил всё из cp866 в utf-8 и пока опубликовал только папочку bootread – как раз код загрузочного сектора, который искал какой-то один файл и жрал его в память.

https://github.com/logicarea/intel-assembler-fat12-os

https://github.com/logicarea/intel-assembler-fat12-os/blob/master/bootread/boot.asm – по-сути вот всё тут

boot.bat – как это собрать

https://github.com/logicarea/intel-assembler-fat12-os/blob/master/bootread/lba.inc – тут видимо собраны все необходимые мне преобразования дорога/поверхность/сектор и чё-то такое, что ты там выше обсуждал.

Йоба, судя по комментам, я тогда понимал что-то про кластеры в FAT

lesopilorama
() автор топика
Последнее исправление: lesopilorama (всего исправлений: 3)
Ответ на: комментарий от lesopilorama

В общем, судя по тому, что я вижу в своём гениальном мегакоде - оно реально представляет собой 512-байтный сектор с байтиками 0x55, 0xaa на конце и какой-то структурой в начале, видимо описывающую FAT12. Далее этот код как-то ищет файл и жрёт его в память. В комментах упоминается, что в корне может быть максимум 16 записей. Или в кластере. Я хер знает уже.

https://github.com/logicarea/intel-assembler-fat12-os/blob/master/bootread/boot.asm#L56 – тут упоминается одно имя файла, который ищется, а на деле в коде другой какой-то TXT на конце (какая-то маскировка от врага?) и названия уже не помню почему такие, аккие-то кодовые имена этой гениальной OS, типа FASTSOFT и чё-то такое.

lesopilorama
() автор топика
Ответ на: комментарий от lenin386

Ну, так у тебя всё гвоздями прибито к формату floppy 1.44. Ни на каком другом носителе это не заработает.

Так тебе никто и не говорил, что оно рассчитано на что угодно включая NVME любых типов с рейдами. Про дискеты с самого начала речь и шла. А дискета - это просто диск с FAT12. Любой диск FAT12 бы взлетел, никакой дискетной специфики тут нет, все сектора читаются биосовыми прерываниями int 13h. Про FAT12 речь изначально и шла.

От флоппи там только «1.44» в комментах, но биосу глубоко пофиг с чего эту FAT12 считывать реально.

lesopilorama
() автор топика
Последнее исправление: lesopilorama (всего исправлений: 1)
Ответ на: комментарий от lesopilorama

У тебя там константы забиты типа секторов в кластере и множество других. Они будут другими даже для отформатированной другой программой floppy, не говоря уже о жестком диске. Эти константы надо честно читать и вычислять производные. Оно даже на другой дискете не заработает.

lenin386 ★★★★
()
Ответ на: комментарий от lesopilorama

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

lenin386 ★★★★
()
Последнее исправление: lenin386 (всего исправлений: 1)
Ответ на: комментарий от lenin386

У тебя там константы забиты типа секторов в кластере и множество других. Они будут другими даже для отформатированной другой программой floppy, не говоря уже о жестком диске. Эти константы надо честно читать и вычислять производные. Оно даже на другой дискете не заработает.

Работало на куче разных рандомных дискет. Так что, наврал ты нам в каком-то месте наверное.

lesopilorama
() автор топика
Ответ на: комментарий от lenin386

И номер кластера ты с номером сектора попутал и хренотень у тебя читается, а не файл.

Ну выходит, что когда оно у меня работало, оно было не в курсе, что не надо работать. Не будем ему рассказывать, чтобы не перестало!

lesopilorama
() автор топика
Ответ на: комментарий от Iron_Bug

Всё это опять же не имеет никакого отношения к UEFI. Если бы UEFI по какой-то причине не появился, то все те же зонды были бы в BIOS. BIOS не является никакой панацеей сам по себе.

X512 ★★★★★
()
Ответ на: комментарий от lesopilorama

Оно — не работало, и работать могло только на одной дискете либо по случайности, либо в результате долгих попыток, ты подогнал цыфирь. Твой код — смешон. Ты постоянно путаешь секторы и кластеры, в нескольких местах. Ну, давай, потрачу время, откоменчу твой код.

lenin386 ★★★★
()
Последнее исправление: lenin386 (всего исправлений: 2)
Ответ на: комментарий от lesopilorama
push	ax		;Этот кластер
	mov	cx,ax
	add	cx,1+9*2+14-1	;BOOT+FAT+ROOT-MICROSOFT_GLUK#2

Вот тут ты типа переводишь номер кластера в номер сектора, чтобы потом сконвертировать в CHS процедурой, которую оттуда-то сπ, но она тоже не правильная, потому что ты даже CHS не считываешь. А это всё вариативные параметры даже на дискете. На пятидюймовой дискете 15 секторов на дороге, на 720k - 9. На жестком диске вообще всё не так. + 1 - правильно. +9*2 - правильно, хотя такое работать не будет уже на по другому отформатированной floppy. Количество секторов на FAT и её количество - может быть различно. Эти числа надо вычитывать, из специальной области. А вот дальше - ты от бессилия начал подгонять цыфирьки, чтоб заработало. Что за число 14 и MICROSOFT_GLUK#2 - я не знаю. Догадываюсь, как ты к ним пришёл, но лучше не комментировать. Вообще, тут должно быть nrec_in_root*32 / 512, которые тоже надо вычитывать, но не получается, «MICROSOFT_GLUK#2» мешает.

	mov	ax,0201h	;Читать, один.
	int	13h

Читать, один. СЕКТОР. А надо - КЛАСТЕР. Ага. Оно сработало потому, что у тебя в данном конкретном случае, у тебя получился размер кластера - один сектор. Такое бывает абсолютно не всегда, даже на floppy. Это разные понятия, если кластер был всегда равен сектору, такого понятия не было бы.

lenin386 ★★★★
()
Последнее исправление: lenin386 (всего исправлений: 6)
Ответ на: комментарий от lenin386

Ассемблер может в именованные константы? Думаю, нет, только если оформить комментарием, что это за число.

yars068 ★★★★★
()
Ответ на: комментарий от lesopilorama

. В комментах упоминается, что в корне может быть максимум 16 записей.

Количество записей в корне - задаётся в поле n_records_in_root. И оно равно 224 на дискетах, отформатированных программой format флоппи на 1.44. Просто разложение корневой директории на цепочку кластеров либо не влезло, либо не было осилено. 16 - это 512/32. 512 - размер сектора, 32 - длина файловой записи в fat. Опять, тут путает сектора и кластеры.

lenin386 ★★★★
()
Последнее исправление: lenin386 (всего исправлений: 2)
Ответ на: комментарий от lenin386

Есть там явно ещё одна ошибка, иначе из-за минусования этого мс_глюк должен вычитываться файл без первого сектора и не до конца. Но тут правды мы уже не узнаем, потому что содержимое этого кернел.ехе, или как там его, не известно.

lenin386 ★★★★
()
Последнее исправление: lenin386 (всего исправлений: 3)
Ответ на: комментарий от lesopilorama

я тогда понимал что-то

		org	300h-2
		db	055h,0AAh	;Зачем и отнимали 2

Для дискет последнее необязательно. ~Что и показывает предыдущая строчка.~

vM ★★
()
Последнее исправление: vM (всего исправлений: 1)
Ответ на: комментарий от Iron_Bug

сейчас будут цениться компы без UEFI

Для x86-серверов сейчас есть «прямая» загрузка. Без UEFI и эмуляции legacy BIOS.

vM ★★
()
Ответ на: комментарий от lesopilorama

Примитивный драйвер не нужен, нужен огрызок, который сможет распарсить содержимое корня, найти среди файликов в корне нужный и узнать из каких секторов его можно достать.

Зачем это записывать в файлики? Зашьем это в сектора, о которых наше чуднокодие знает без парсений.

vM ★★
()
Ответ на: комментарий от vM

Зачем это записывать в файлики? Зашьем это в сектора, о которых наше чуднокодие знает без парсений.

Дык чтобы просто новое ядро «KERNEL.BIN» в корень кинул и заработало. Чтобы не запускать спецтулзы, которые перепрошивают бут-сектор.

lesopilorama
() автор топика
Ответ на: комментарий от lenin386

Вот тут ты типа переводишь номер кластера в номер сектора, чтобы потом сконвертировать в CHS процедурой, которую оттуда-то сπ, но она тоже не правильная, потому что ты даже CHS не считываешь.

Твои теории мало интересны после того, как оно у меня работало. Ты мне чё предлагаешь-то? Что-то начать лучше понимать? А зачем, и так ништяк работало. Значит понимание было достаточным на уровне решения той задачи. Если оно не идеально правильно, то и хер с ним, значит не требовалось идеально правильное, главное чтоб работало.

lesopilorama
() автор топика
Ответ на: комментарий от lenin386

Оно сработало потому, что у тебя в данном конкретном случае, у тебя получился размер кластера - один сектор.

Ну и за**бись. Цель же была в том, чтобы сработало, а не в том, чтобы не сработало. Ну и не думаю, что оперирование кластерами вместо секторов бы сильно увеличило объём кода. Пара фиксов мелких.

lesopilorama
() автор топика
Ответ на: комментарий от lenin386

Оно — не работало

Ахаха, начинается опровергание реальных объективных фактов. Забавно. Ну ладно, это бывает в интернете!

Тебе ж сказали изначально, что делалось под дискету и под FAT12. Ты потом разосрался, что в 512 байт невозможно запихнуть что-то, что понимает FAT12, а оказалось что можно. Теперь ты разосрался, что код работает только под дискету и что он кривой! Дык ёпте, он под дискету и делался. То, что на дискетах кластер и сектор - это одно и то же - это ж просто подарок, можно поэкономить немного кода. Ты какой-то опровергатель и борцун похоже, лишь бы что-то поопровергать. Хорошо что от тебя в этом деле ничего не зависело и код молча работал) Ты даже не попробовал взять дискету и туда это накатить и загрузиться)

lesopilorama
() автор топика
Последнее исправление: lesopilorama (всего исправлений: 2)
Ответ на: комментарий от lesopilorama

что в 512 байт невозможно запихнуть что-то, что понимает FAT12, а оказалось что можно

Конечно, нельзя. FAT12 оно у тебя не понимает. Например, если бы ты поудалял свой kernel несколько раз, и перезеписал новую версию, оно бы читаться перестало. Это, по-твоему, нормальная работа? Нет, это не работа. Если бы так работал загрузчик мистера Билла Гейтса, он бы копался на помойках.

что на дискетах кластер и сектор - это одно и то же - это ж просто подарок

Да нет же. Тебе сделать образ дискеты, где кластер и сектор - не одно и тоже? Вот, упорный. Ну, давай, покажу на примерах тебе, что это - не работает.

lenin386 ★★★★
()
Ответ на: комментарий от lenin386

Конечно, нельзя. FAT12 оно у тебя не понимает. Например, если бы ты поудалял свой kernel несколько раз, и перезеписал новую версию, оно бы читаться перестало.

Начинается срачь о критериях понятий. Не интересно. Добился работы на нужном мне уровне, не заявлял что мой код умеет дефрагментацию делать. Если твой код не умеет делать автоматически дефрагментацию FAT12 на лету, то вряд-ли его можно назвать «понимающим FAT12» в полной мере, бугага.

Да нет же.

Да да же. Дальше не читали тебя.

lesopilorama
() автор топика
Ответ на: комментарий от lesopilorama

Добился работы на нужном мне уровне,

Это весьма херовый уровень. Такой уровень нафиг никому не нужен - распознавание 1/14 части корневой директории на единственном формате floppy. Я так могу сказать, что в 10 байт поддержку FAT впихну, на нужном мне уровне.

Да да же. Дальше не читали тебя.

Ну, до свидания тогда. Хотел на тебя ещё время потратить, ты запретил.

lenin386 ★★★★
()
Последнее исправление: lenin386 (всего исправлений: 4)
Ответ на: комментарий от lenin386

Это весьма херовый уровень

Отличный, называется «работает».

Такой уровень нафиг никому не нужен - распознавание 1/14 части корневой директории на единственном формате floppy.

Так тебе никто ничего не предлагал вообще, что значит нужен не нужен, у тебя можно подумать есть выбор соглашаться на это или нет. Тебе такое никто даже не предлагал, с барского плеча показали исходник, который работает, а так бы ты сидел в одиночестве вообще. А прикинь, сколько ещё есть исходников, которые в разы лучше, но тебе их не показали? Но ты не осилил даже этого, судя по твоему нытью несколькими постами ранее, что всё это невозможно в 512 байтах. А оказалось, возможно и ещё дохрена места осталось и ещё если за дело возьмутся профессиональные демо-мейкеры которые всё это пожмут и пооптимизируют, то можно даже сделать интереснее. Мы думаем, что ты уныл и пустозвонен достаточно.

lesopilorama
() автор топика
Ответ на: комментарий от lesopilorama

Он, кстати, не работает. Я его собрал, исправив синтаксические ошибки. И он - не работает.

А прикинь, сколько ещё есть исходников, которые в разы лучше, но тебе их не показали?

Их нет, потому что вместить нормальную поддержку FAT в 446 байт - не возможно.

и ещё если за дело возьмутся профессиональные демо-мейкеры которые всё это пожмут и пооптимизируют

Я знал, откуда ветер дует. Мозг дэмки сносят отлично, да. Кажется, что всё в килобайт можно засунуть.

lenin386 ★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.