Ктонибудь занимался разработкой собственной файловой системы и ее загрузчиком? Подкиньте информации по теме. Пока есть только некоторые идеи , собственно нужно иметь хорошее представление о файловых системах и методах загрузки с нее. Заранее спасибо.
По загрузчикам в инете тонна инфы. Собственно все они базируются на int 13h. Что касается самой файловой системы: В молодости, когда у нас ещё не знали про NTFS, я начал разрабатывать теорию файловой системы. Каково было моё удивление когда я увидел NTFS Мало того что в ней есть всё лучшее что придумал я, так ещё и куча того до чего я не додумался. Какой смысл изобретать велосипед? Сейчас файловых систем множество - FAT NTFS CDFS UDFS и т.д. Используй то, что подходит для твоих задач.
MirrorBlack в том то и смысл что нужна не стандартная , стандартная это конечно хорошо , но не то , хотя как пример расмотреть конечно стоит , где можно описание и программирование почитать ?
MirrorBlack фс - не обязово связана с дисками. а имена в ней с файлами. это просто удобное и привычное представление чего либо. так что не все так просто
_basmp_ Я после такого ответа в ступоре... Из названия файловая система следует именно то, что это файловая система. Не важно как мы назовём файл - хранилище, объект и т.д. Так же не важно как будут называться ссылки - адрес, смещение и т.д. Смысл не меняется.
MirrorBlack очевидно, что мы говорим про разные вещи. - вы под фс понимаете технологию хранения файлов на диске. тут возможно оч много вариантов. нтфс далеко не топ. - я под фс понимаю древовидное пространство имен через которое пользователь/программист получает доступ к информации, ресурсам, программам. то, что в моем случае связь с дисками или вообще чемто материальным не обязательна хорошо видно на примере юних. папочки дев и проц. кроме того на фс выводится и сеть. есть варианты где на фс выводится енвиронмент, буфер обмена, оконная и граф подсистемы итд. есть варианты где каждый поток может иметь свой образ фс или даже одинаковые образы, но с разными сущностями за одинаковыми именами включая удаленные и виртуальные. есть варианты где, напр, окна и батоны строятся созданием в спецдиректории папок и файлов в них. а свойства и функционал выглядят как некий текст в них (наподобие ини файлов). такой гуй может быть легко просмотрен, отредактирован, проэкспортирован, скопирован, старгзипан и развернут. такой подход значительно упрощает жизнь и утоньшает ось. хотя после простейшей идеи, да и реализации фс выни нужно время на привыкание
_basmp_ Вопрос был поставлен про ФС в "моём понимании" И диск в "моём понимании" не обязательно физический. calidus Начни с FAT16 как наиболее лёгкой. Только есть маааленький нюанс. Ну предположим сваял ты нечто по образу FAT, написал загрузчик. Вот тут и возникает вопрос - загрузчик чего? После старта компа и загрузки BIOS процессор находится в реальном режиме. Конечно ты можеш пользоваться всеми функциями BIOS, но их мало. Работа с графикой сущий АД. Как довесок к этой оптимистичной картине - можно пользовать только 1 метр памяти. Если скажеш какие цели стоят - советы будут более конструктивными
MirrorBlack да там не совсем понятно. загрузчик вполне мож быть генерируемым на лету. а сама привязка фс к диску может тоже быть изменяемой. скам, вначале нек мин часть будет эмулировать фат, а после полной загрузки чтото более серьезное отобразить
MirrorBlack вопрос не стоит использовать файловую систему для винды , это только как бокс хранящий всякие файлы ...загрузчик в данном случае это программа читающая ФС и выбирающая нужный файл для его запуска с нее. Можно привести в пример виртуальный сидюк , но у сидюка всегда уже известная ФС , и он использует стредства которые хотелось бы обойти , не нужно выводить диск как это делает вирт сд. Что то вроде жесткого для хранения своих данных и со своей файловой системой.
calidus Это и так ясно А вот здесь не ясно... Если я теперь правильно понял, загрузчик это драйвер ФС под Windows?
=) можно и драйвером ....но я думаю отказаться от него , проблематично с защитой. Этот просто ехе шка или дллка ... Что то вроде вот такого . This document is still work-in-progress, it will be cleaned up and re-orgranised as progress is made and ideas are refined. The idea is to design a simple indexing filesystem. The 'point' being merely for amusement, though if it does result in a usable/useful design, that wouldn't be such a terrible thing. Unofficially titled Frankstein's File System or FFS (For F***'s Sake?) for short. Though people might want to settle on the more conservative Simple Indexing FileSystem (SIFS). Any other ideas are welcome. All ideas/objections/insults are welcome. The only restrictions are that it should be simple (straightforward and easy to implement) and indexing (surprisingly? This really just feeds off the simplicity aspect.) Features: Exactly what, how, and how many of these should be included is up for debate, just as long as we don't over-complicate the design. Bootsector The Index!! -- not really part of the 'interface' but obviously a necessary part of the design. Will basically map the files onto the disk (in some way.) Files Directories/Folders - maybe not entirely essential, but definitely useful. Time/Date stamp - again, useful. Attributes - somewhat useful? Exact attributes to be decided. Permissions/Ownership - security. Requirement depends on use, but it's a desirable feature. Journalling? - Probably a little too much overhead/complication, but error recovery/robustness aren't bad things. Basic Structure: The top-level structure of the filesystem consists of a collection of sections, layed-out sequentially on the disk. Each section will be of a pre-defined class to identify its contents; sections may appear in any order on the disk, and sections of the same class could appear more than once for different data, unless otherwise noted. To be compatible with the bootstrap mechanism of current PCs, the first sector should be reserved for a bootstrap program, with execution beginning at offset zero of this sector. The purpose of this program is to load a file (or files) from the disk in order to start the Operating System, however, only this first sector is initially loaded and the program itself is responsible for loading any other necessary sectors and/or files. With only limited space (one sector; generally 512 bytes) in which to do this, the program would struggle to load files from the disk without extra information to aid it. For this reason, we reserve a small number of bytes at the end of the boot-sector in which to store the minimal necessary parameters required to load a file from the filesystem; leaving the rest of the bytes preceeding this for the boot program itself. Bytes 510 and 511 (the 'last two' of a 512 byte sector, but sectors may actually be larger) of a bootsector are convetionally reserved for a boot-sector signature of "55 AA" (hex) to indicate the sector does indeed contain a valid boot program. Is this technically needed? It's required for the MBR, but when the MBR progam loads the bootsector from a partition does it actually check? Need to look at grub/lilo/etc. This gives the following layout for the boot sector: +-----------------------------------------------------------+ | | | | | | | | | | | Boot Program | | | | | | | | | | | | | +-----------------------------------------------------------+ | | | Parameters _____| | |55 AA| +-----------------------------------------------------------+ And a general overview of the entire filesystem: +-----------------------------------------------------------+ | Boot Sector | +-----------------------------------------------------------+ | | | | | Section | | | | | +-----------------------------------------------------------+ | | | | | Section | | | | | +-----------------------------------------------------------+ | ... | +-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --+ Sections: Each section consists of a header, followed by its content data. The header contains basic information that is common to all sections, such as the class, length, ... This format allows a basic implementation to parse the structure of the filesystem, even if it contains sections of classes it does not support. For this reason, implementations should ignore any sections of classes they do not understand; this does mean that any defined extensions should not break a basic implementation by including essential information in a non-standard section, as this could cause the basic implementation to corrupt the filesystem. All standard sections are those essential to basic use of the filesystem, i.e. traversing directories and reading/writing files. Such flexibility also allows easy error recovery; a disk repair tool could traverse/search the sections independently of on-disk data, thus allowing it to recover lost files even when the data required for normal filesystem access to them is lost. Section Header: Class — four character ascii string Length — unsigned 32-bit length; congruent to 512 ..? Section Classes: The class of a section is specified by a four character ASCII string, giving the name of the section. Names consist of a limited alphabet of alpha-numeric characters, plus underscore, all other characters/symbols/whitespace should be avoided. All names beginning with an uppercase alphabet character (A–Z) are reserved for the standard and its future extensions, leaving all other names free for personal use and OS dependent features (since implementations will ignore unrecognised sections, this should not cause any problems.) Names are, therefore, necessarily case-sensitive. "FILE" — file - files exist only in directory entries? "DIR_" — directory - contains records for the files it contains "INDX" — index - map of sector allocations "DATA" — start of file data? "INFO" — extra information - like what? "JRNL" — journal "END_" — current end of sections (i.e. no more sections follow this one) File Record: Name - 64 chars with option to be exetended, or 255? (ascii? uincode? utf8?); zero-terminated or length prefix? Size - 32 or 64 bits? (32 = max 4GB, 64 = max 16 million TB) Created/Modified/Accessed date-time -- elements (bits allocated for year, month, day, etc) or counter (seconds: 32-bit = 136 years, 40-bit = 34841 years, 64-bit = 584 billion years; milliseconds: 48-bit = 8919 years, 64-bit = 584 million years)? reference point (1900, 1970, 2000)?? attributes? owner? access rights/permissions? Index: hmmm... -------------------------------------------------------------------------------- Appendix A – A standard FFS bootstrap program include here the code for a simple (x86) bootstrapper that loads a file by name from the filesystem, and transfers execution to it. Виртуальные сдки используют драйверную систему , я сказал что эти сложности мне не нужны , и толку от них мало в моем случае.
calidus Тогда всё просто. 1) Создаёш на диске некий файл (например МойДиск.dsc) 2) Размер файла min должен быть таким, чтоб разместилась FAT16 3) Пишеш, читаеш, уменьшаеш и увеличиваеш размер файла. Чтоб для начала было совсем просто, используй FAT16 и файл фиксированого размера. Чтоб для начала особо не парится с записью в файл, можно его отобразить на память.
