OSDev

Я думаю, что возможно, но только до тех пор, пока нет давления рынка.


Я не понимаю, вы соглашаетесь или возражаете? У мну такое впечатление, что у вас всегда первый порыв - ввязаться в спор. Я отнюдь не возражаю против универсального АПИ для хранения конфигурационных данных и их двоичного представления. Здесь всё нормально. Я возражаю против бесконтрольной свалки и единого файла этой свалки. т.е. против реализации, от которой не отойти.


Ничего я не смешиваю.
1. Большинство текст-ориентированного ПО должно УНИФИЦИРОВАННО работать с текстами и не заморачиваться на автодетекты и перекодирования. Если я, как пользователь, запустил текстовый редактор, даже самый простейший, я хочу иметь возможность написать любой текст, не заморачиваясь техническими тонкостями и не впадая в прострацию от неправильных кракозябр на экране вместо ожидаемого текста.
2. Эту унификацию должна предоставлять ОС и набор системных библиотек. Если ОС нет дела до проблем пользовательского ПО - эта ОС морально устарела.
3. Невозможно провести чёткую грань между ОС и прикладным ПО. Всякий раз, когда ПО пытается создать файл "C:\Мои документы\Письмо начальнику.doc", а особенно если пользователь живёт в Китае, вы ощутите, что ПО и ОС неразделимы. И дело тут не в наименовании мьютексов.


Про достаточность будете объяснять в FAQ пользователю, который в ПО вдруг ввёл русские буквы или йероглифы там, где ПО и ОС этого совсем не ожидают.


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


Ааааа, я вижу вы не поняли суть претензии! Системной кодировкой должна быть UTF-8! Это решение снимает проблемы двухбайтовости, двух наборов библиотек и пр. UTF-8 разработан в 92 году, ещё до выхода WinNT 3.1! Поддержка суррогатных пар добавилась в Win2000.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Что значит "давление рынка"? Развитие технологий -- вещь довольно естественная, но точно спрогнозировать всё невозможно: кофейная гуща не обеспечивает необходимого качества предсказаний :) Например, при создании Винды ещё не было PnP, поэтому в NT4 его пришлось "прикручивать сбоку", заодно дорабатывая драйверную модель. Не было и графических процессоров; существовали лишь примитивные видюхи, где всю обработку данных и её запись в буфер кадра осуществлял центральный процессор. Соответственно, с появлением ГП пришлось перерабатывать графическую подсистему, причём, как показала практика, не один раз. Ну и т.д. и т.п. Заметьте, я речь веду о вещах, напрямую затрагивающих нижний уровень ОС; о всяких там свистелках-перделках, которые видит обычный пользователь, речи нет.



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



"Единого файла этой свалки" не существует: реестр состоит из нескольких "кустов", часть из которых -- отдельные файлы на диске, а часть существует только в ОЗУ (там находятся как раз динамические данные).

Что касается реализации, то от неё как раз вполне возможно отойти (и, кстати говоря, чуть ли не самым крупным "внутриядерным" отличием Хрюши от Винды-2000 была работа с реестром: там перелопатили реализацию весьма существенно). Все сколько-нибудь вменяемые программы работают с реестром только через стандартные функции, предоставляемые ОС; следовательно, внутреннюю реализацию можно менять как угодно, лишь бы внешний интерфейс был тот же самый. Ну а невменяемые программы (например, напрямую пытающиеся редактировать те или иные файлы реестра) можно и забить; собственно, к этим файлам доступа вроде как и нету вообще, но проверять лениво.

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



К ОС это прямого отношения не имеет; это вопрос стандартизации представления информации на внешних носителях. В связи с "тяжким наследием проклятого прошлого" решить его без костылей не представляется возможным в принципе. Нельзя, например, априори считать некий файл закодированным в том или ином формате, если этот формат не жёстко стандартизирован (как прикажете рассматривать обычный текстовый файл? Как ASCII? UTF-8? Ещё что-нибудь? 100% стандартов здесь не существует по историческим причинам). Можно, конечно, полностью отказаться от совместимости, но как воспримут это пользователи? Кроме того, что значит "унифицированно"? Простейший текстовый редактор в принципе не способен работать с документами, созданными в Ворде, и не из-за козней разработчиков последнего или там отсутствия унификации в кодировке, а из-за большого количества дополнительной информации, которую сохраняет Ворд и которая описывает оформление, всякие там рисуночки-таблички и прочая.



Знаете, если б Вы были блондинкой-секретаршей, то такое заявление было бы вполне разумным: обычному пользователю, тем более неквалифицированному, трахаться с установкой кучи ПО, кроме самой системы -- удовольствие ниже среднего, и, вообще говоря, он должен быть от этого избавлен. Да и не видит такой пользователь разницы между системой, прикладным ПО, а то и компьютером в целом (если у означенной секретарши Ворд заглючил, что она скажет местному айтишнику? Скорей всего что-нибудь вроде "Вася, подойди сюда, у меня компьютер сломался"). Но Вы же вроде как программист, а не блондинка, а в устах программиста, да ещё системщика, подобное высказывание выглядит, извините, бредом.

Как Вы вообще себе представляете решение проблем пользовательского ПО с помощью системных библиотек? Внедрять поддержку определённых форматов файлов в системные библиотеки? Но какое отношение формат файлов текстового редактора или там некоего САПР имеет к ОС? Внедрив же поддержку оных в систему, Вы тем самым жёстко завяжете систему на определённые форматы пользовательских данных, вообще никакого отношения к собственно системе не имеющих. После этого всякая попытка уйти от однажды внедрённых форматов (заменить, например, их на более эффективные или обладающие расширенными возможностями) будет невозможна, ведь они оказались привязанными к системе! Придётся тянуть с системой кучу древнего кода для обеспечения совместимости с тем, что, может быть, уже никому и не нужно, и т.д.

Или возьмём графическую составляющую. Нужно ли делать частью системы всякие высокоуровневые библиотеки, рисующие готовые окошки, всякие там файловые диалоги и т.п.? Уверен, что нет. Такие библиотеки могут поставляться вместе с системой, т.е. быть стандартными, но они не должны быть системными: ОС должна благополучно работать и без них (а не так, как в Винде, где оторвать графику от ядра весьма и весьма проблематично, хотя эта графика в ряде задач не нужна).

В общем, спасибо, но такая "унификация" мне не нужна. Лучше "морально устаревшая" система, зато компактная, быстрая и хорошо умеющая решать собственно системные задачи: управлять железом, распределять ресурсы между приложениями и предоставлять последним набор довольно низкоуровневых (зато эффективных и универсальных) сервисов. Ну а прикладные задачи пускай решаются прикладными задачами, а не системой. Ту же самую поддержку файлов определённых форматов можно сделать и в виде библиотек, которыми могут пользоваться разные прикладные программы -- вот только не надо эти библиотеки объявлять системными. Если, например, мне на компьютере не нужен машиностроительный САПР, на кой ляд мне устанавливать библиотеки, обеспечивающие работу с файлами в его формате? То же самое касается и любых других форматов, не относящихся прямо к системе.



Такую грань не сможет провести вышеупомянутая блондинка, однако профессиональный программист просто обязан её видеть. Обычному пользователю есть дело до наименования файла, но ему нет никакого дела до того, как именно ОС внутри себя обозначает этот файл или как программа должна именовать различные объекты при вызове функций API: этого пользователь просто не видит.



Извините, бред. В каких это системах пользователь вводит имена "задач, событий и прочих системных объектов"? Пользователь даже не знает об их существовании, он работает на уровне файлов и выше.



То, что UTF-8 появился в 1992 году, а WinNT 3.1 вышла позже, ничего не меняет: система разрабатывается не за месяц и даже не за год, и её разработка шла уже несколько лет. Быстро поменять что-либо, протестировать и т.п. проблематично чисто технически, ну а задерживать выпуск системы -- недопустимо с коммерческой точки зрения, надо полагать (а не учитывать требования рынка нельзя: обанкротишься).

Кстати, а Вы в курсе, что UTF-8 неудобен и для программиста, и для машины в силу переменной длины символов? В итоге получаем усложнение подпрограмм обработки таких строк и приличное падение скорости. Идти на это ради поддержания возможности использовать особо редкие символы во внутрисистемных именах лично я считаю нецелесообразным. Вот для файловых систем обеспечить возможность применения любых символов -- это другой вопрос, там они действительно могут понадобиться, ведь с именами файлов работают сами пользователи, а не только программисты. Но и в этом случае использование UTF-8 является дискуссионным вопросом.

Охххх! Вы опять столько нафлу... написали, да ещё с отсылками категории "бред", что опять пропадает всё желание спо... обсуждать. :)
Буду краток.
1. Мне нет нужды биться со стенками. Ваше мнение - это ваше мнение.
2. По поводу сравнения с блондинками – да, я не блондинка, я программист. Но я устал от блондинок, обращающихся ко мне по каждому чиху компьютера. Поэтому я хочу сделать систему, пригодную для любой блондинки и не рассчитывать, что за ней будут работать только профи. Вы же вправе надеяться, что к вашей системе никто, кроме профи, не подступится.
3. Если вы не понимаете, что 90% информации, предоставляемой пользователю через UI - текстовая и в обязательном порядке ПРОХОДИТ через уровень ОС для отображения пользователю (в т.ч. тот же ворд, до которого нет дела, пока он хранит текст в собственных документах, но обращается к функциям ОС для вывода его на экран), то можете оставлять текстовый уровень целиком на усмотрение прикладного ПО. Я же считаю, что ЛЮБАЯ работа с текстом так или иначе проходит через уровень ОС для вывода информации пользователю или ввода от него, а значит должна быть стандартизирована и выбрана наиболее адекватная и удобная кодировка. Не важно, браузер это, ворд, надписи в САПР, текст в диалоговых окошках... Можете попробовать сделать ядро своего ПО работающим с UTF-8 (или в другой кодировке), - я посмотрю, как вы намучаетесь, транслируя параметры огромной кучи системных вызовов в WCHAR.


Не был бы не "в курсе", не писал бы выше про суррогатные пары. Поймите, WCHAR не отменяет переменность длины символов! Поэтому UTF-16 не облегчает, а, наоборот, усложняет программирование и отладку ПО.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Yoda, заявка про то, что UTF-8 должна быть системной кодировкой - это реально бред. Во-первых, ее обработка значительно сложнее, чем UTF-16, а во-вторых, как уже было сказано, редко возникает необходимость обращаться к суррогатным парам (в то время как для UTF-8 разброс между 1-, 2- и даже 3-байтовыми кодами - это норма), более того для именования системных объектов можно ограничиться символами только из базовой плоскости. Также UTF-8 не спасает от несовместимости с однобайтовыми кодировками.

Нафлудил-нафлудил. Я флудераст известный :)



Аналогично. Правда, мнения желательно аргументировать, хотя это не всегда возможно (в конце концов, бывают же и вещи, связанные со "вкусом", а не некими объективными причинами).



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



Ой ли? Цифры сильно зависят от вида ПО. Много ли текстовой информации во вполне прикладных программах -- всяких там игрушках-стрелялках? А так ли много её в САПРах? Текстовые документы -- это далеко не всё. Хотя, конечно, текстовая информация занимает приличный объём пользовательского интерфейса.

То, что информация для отображения проходит через систему, это достаточно очевидно. Однако это не значит, что в процессе этого прохождения информация хоть как-то обрабатывается. Задача ядра системы в данном случае -- обеспечить передачу этой информации от клиента (прикладной программы) к серверу (графической подсистеме), заодно проверив ряд параметров по формальным критериям (например, если для запроса отрисовки чего-нибудь используются обычные операции ввода-вывода, ОС может проверить правильность положения буферов с информацией: находятся ли они целиком в адресном пространстве задачи, выровнены ли должным образом и т.п.; при этом собственно информация в этих буферах её не интересует).

Понятное дело, что сервер (графическая подсистема) должен уметь обрабатывать передаваемую ему информацию; применительно к тексту он должен обеспечивать его корректное воспроизведение для используемой кодировки (это не обязательно должна быть именно UTF-8, но что здесь надо поддерживать полный набор символов, сомнений не вызывает). Но это уже является делом именно графической подсистемы, а не ОС в целом. Жёстко же связывать между собой собственно ядро ОС и графическую подсистему не стоит: тогда возникнут трудности с модернизацией что того, что другого, да и оторвать графику от ядра станет проблематичным (а ведь хватает задач, где графика не нужна вообще или где она настолько примитивна, что полноценная графическая система приносит больше вреда, чем пользы).

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



1. Суррогатные пары обрабатывать не сложней, чем символы переменной длины в UTF-8; соответственно, UTF-16 не сложней, чем UTF-8. На самом деле, обработка суррогатных пар в UTF-16 даже проще: достаточно сразу выполнить два сравнения, чтобы определить, суррогатная это пара или нет. В UTF-8, если не ошибаюсь, придётся проверять байт за байтом, пока не удастся понять, какая же длина символа перед тобой, а этих байтов может быть вроде до 6 (хотя на практике, кажется, не больше 4 -- но я не помню подробностей, так что могу ошибаться).

2. Применительно к ядру системы я не считаю необходимым использовать полный UTF-16; я использую UCS-2, т.е. подмножество UTF-16, не содержащее суррогатных пар. Соответственно, все символы у меня строго двухбайтовые, и работать с такими строками легко и приятно. То, что при этом невозможно закодировать некоторые редкие символы, меня не волнует по двум причинам. Первая и самая главная заключается в том, что "ядерные" строки предназначены только для именования объектов системы, а не для непосредственного восприятия пользователями как таковыми (нет, их можно будет увидеть с помощью специальных утилит, но обычным пользователям эти средства не нужны (как не нужны и всякие извращённые символы в подобного рода именах; там, как говорил, вообще хватило бы 7-битного ASCII, просто иногда давать имена таких объектов на родном программисту языке удобно в смысле читабельности программы и т.п.). Вторая причина фактически связана с первой: с этими именами работают только программисты, а они по-любому должны учитывать особенности системы и т.д., т.е. на них вполне допустимо накладывать определённые технические ограничения. В данном случае ограничения очень либеральны: вы можете называть создаваемые вами системные объекты (задачи, семафоры, события, мутексы и т.д.), используя любые символы Уникода, которые можно закодировать двумя байтами UTF-16. На объекты файловых систем (каталоги и сами файлы) эти ограничения вообще никак не распространяются; там ограничения накладывают драйверы файловых систем, и связаны они со стандартами этих самых систем (если некая файловая система в принципе поддерживает только ASCII, то только его и можно будет использовать, но ОС-то здесь причём?).

+1. Даже модификаторы можно использовать как независимые символы. И самое главное, что UCS-2 можно в дальнейшем расширить до UTF-16.

Отвечу про кодировку насколько я слышал виндоус использует 2 байтовую кодировку. Где 2 байта на символ. Не больше.
В Юникод-16 есть символов переменной длины. Но в виндоусе насколько знаю они не обрабатываются, а используются символы фиксированной длины.
Поправит, если я неправ.


По поводу 2 байтовой кодировки и 4 байтовой. Есть закон мура, через 2 года 2 байтовой кодировка будет работать не хуже чем 1 байтовая. Значит через 4 года 4 байтовая будет востребована.

Сам я пока остановил свой выбор на 16 байтовой кодировки. 50 символов на язык умножить на заглавные и маленькие. Получаем 100 сиволов на язык. 65536/100=655 стран у нас меньше 300 что ли в олимпиаде обычно участвует около 150 стран. Поэтому 2 байтовой должно хватить с запасом. Для Китацев хватит 3-6 тысяч основных символов. Професор должен знать 25 тысяч иероглифов.

С другой стороны вдруг операционка доживёт до встречи с инопланетянами, тогда 16 битовой не хватит, а вот 4 байтовой достаточно. Символы однозначно должны быть постоянной длины.

Сурогатовые пары это бред. Каждый текстовый языка не повторим. И поэтому для его обработки требуются специальные модули. Пихать их в ядро систему не хочется.


По поводу убеждений SII что ОС она только ОС когда она работает с железом. Это определение 60-х годов. Да где-то оно может и нужно. Но явно не везде. Мне лично уже надоедает вечный ной блондинок. Почему не открывается, как поправить. Сделай так чтобы работало. Так что в офисной системе нужен один стандарт жёсткий, но с поддержкой 3D (САПР), графической векторной, математикой ещё не обдумывал как.


Yoda
Ну ка за проектируйте мне к завтрому. Систему для хранения голограмм и обработки.
А также систему распознавания мыслей человека.

Виндоус хотя и проектировали, но всё же полно вещей, которых сделано без тщательной проработки.

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

Реестор вообще мало зачем нужен. Хотя в линуксе таких микро реестров полно.

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

Независимо от года разработки и модных веяний ОС должна выполнять ряд базовых функций, и в первую очередь -- управлять железом. Если этого нет, нет и ОС; если это есть, но реализовано плохо, то и вся система будет плохой, в какую бы шикарную обёртку её ни завернули и какое бы классное прикладное ПО для неё ни существовало. А посему для начала надо разработать именно "систему 60-х годов" (ну а точней -- 1970-х) -- компактную, быструю, надёжную и одновременно обладающую развитым низкоуровневым API. Вот когда эта задача будет выполнена, на неё можно вешать всякие полезные и не очень примочки, и в частности, графику.



Этот ной всем надоел, однако задача пока что не решаемая в полном объёме (пока нет настоящего искусственного интеллекта, благодаря которому компутеры сами себя восстанавливать смогут после любой блондинки :) ).

Другое дело, что и без ИИ можно создать намного более надёжное ПО -- но для этого надёжным должен быть каждый его уровень. Ну а надёжность в первом приближении обратно пропорционально в лучшем случае объёму кода, а скорей, его квадрату или даже кубу (т.е. с удвоением размеров кода надёжность падает в 2-4-8 раз). Отсюда вывод: надо чётко разделять различные уровни ПО и не пытаться всё поместить в систему, а, напротив, строго разграничивать: мухи направо, котлеты налево.

Объясню подробнее. Сегодня пусть микроконтроллёр имеет частоту 4 МГц и память 4 мегабайта.
По закону мура через два года процессор будет иметь частоту 8 МГц и память 8 мегабайт.
Через 4 года 16МГц и 16 МБайт. Поэтому использовать 4 байтную кодировку можно. Пока вы будете разрабатывать появится нужная техника. И это не сильно скажется на производительности и объёме. Правда часть текстовых процедур всё-же усложнится.