OSDev

Dron, я думаю, в 99% случаев будет достаточно и 16 бит. Ведь на протяжении 20 лет как-то хватало даже 8 бит :)

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

Zidan, в RAID используется просто двойное хранение информации.
RAID-1 использует просто 2 диска, содержащих идентичную информацию. При повреждении одного - остаётся информация на втором. Поэтому общий объём полезных данных 1/2.
RAID-5 использует 3 диска: 2 под хранение информации, а третий под информацию для восстановления. Поэтому общий объём полезных данных 2/3. Информация для восстановления это просто побайтовая XOR между 1 и 2 дисками.

решил привести кодировку символов к которой пришел - может подскажете как она называется

схема такая
00 - знач символ
01 - тоже знач
10 - +предыдущая длина
11 - + 2 х предыдущая длина

вот примеры кода:


что бы было понятнее расшифровка символа подлинее

х - значащие биты
остальные биты - биты длины, первая 11 - после нее 4 бита, вторая 11 после нее 8 бит, и 10 после нее такая же длина как предыдущая - 8 бит. Предпоследний бит - конец символа.

правда вопрос ее использования еще не решен - я то теоретик и незнаю насколько процероемкий алгоритм выйдет в результате


з.ы.
про систему RAID и ECC дайте ссылок, хотя наверно в поисковике найти проблемой не будет.

Zidan, Жесть... че-то я не понял про длину... :) зачем вообще хранить длину для символа?

Есть стандарты... надо ими пользоваться.
http://www.unicode.org/

При этом код символа всегда имеет длину 32 бита...
Но его можно представить в разных формах.

Chizh, Раньше хватало 256 значений потому - что кроме России остального мира практически не существовало... да и то возникли многочисленные разночтения.

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

А теперь внимание, вопрос... :) зачем тратить на английские буквы по 16 бит, когда они прекрасно умещаются в 8? :)
Конечно с UTF8 больше возни.. но трудности нас не пугают. Это универсальнее.

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

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

Не только при необходимости, а всегда, если нужна именно интернационализация. При этом оригинальный текст всего в одном экземпляре (его вообще можно хранить в ASCII), а переводов на разные языки в 10-100 раз больше.
Вообще я предлагал использовать тип wchar_t только для самих функций API, к тому же Сишные функции под него заточены. А храниться файлы могут как угодно, входной формат всё равно не угадаешь.

Chizh, А я вообще думаю что у меня в системе будет тока одна кодировка! UTF8.

Хотя конечно с поддержкой импорта придется возиться... ну чтобы документы из внешних источников корректно разбирать.
Но сделать преобразование из разных в UTF8 проще чем из разных в разные (iconv... sic!)

Zidan, Тебе всетаки надо взглянуть на UTF-8... в принципе оно не идеально... но стоит учитывать что символов меньше одного байта наверное не будет никогда, а максимальный юникод на данный момент занимает 5 байт... следовательно длину можно ограничить 2 битами!

Нет никакого смысла отводить для этого целый байт!

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

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

Zidan, Зачем нужен рандомный доступ к строке???

А насчет платформонезависимости...
Вряд ли возможно учесть все платформы...

В любом случае необходимо проанализировать все желаемые платформы и составить некоторое множество универсальных возможностей.
Эти универсальные возможности реализуются на универсальном языке. Получается универсальное ядро.
Осталось только обеспечить совместимость реальных возможностей с универсальными... Для этого делается HAL - hardware abstracttiion layer, Типа слой аппаратной абстракции. Который адаптирует реальные возможности к универсальным.

Кстати универсальные возможности не обязательно должны быть такими, чтобы на всех платформах присутствовали.
Главное чтобы их было возможно запрограммировать в HAL.

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