Board.KolibriOS.org

Короче, ввод пути - не проблема, вариантов много. Можно тупо продублировать функции. Для 70 можно сделать проще: если отказаться от возможности указывать кодировку для непосредственной строки в структуре, то для строки по адресу действительно можно указывать кодировку в байте 20 перед указателем, который сейчас всегда 0.

Получение пути запуска. Тут сложнее, так чтоб вообще без маркера есть только три варианта: либо новая версия заголовка MENUET03 для utf-8, а в MENUET01 вернуть ср866, либо функция для получения пути запуска в юникоде (только боюсь никто пользоваться ею не будет, и юникода не получится), либо вообще забить на юникод до поддержки РЕ.

Siemargl
С путями и именами файлов в posix нормально. Все это приняли, даже MS.

Там не всегда 0. Какая то функция там требует обязательно строку, а не 0+указатель - нашел - SysFn70.9

Можно, конечно поправить, но пока так

Знак кодировки надо убирать. Это источник бесконечных проблем.
Функции сдублировать. Многие программы на ассемблере используют структуру ф.70 для имени файла. Перевести их на указатель будет сложно.
Новый заголовок представляется мне лучшим решением. В этом случае в структуре PROC ставить флаг поддержки utf-8.

Не лучше ли для новых приложений не совместимых с МенуетОС использовать другой заголовок? Например, KOLIBRI или KEX. Или с этим есть какие-то трудности?

Serge
Нет, использовать структуру ф.70 для имени файла в cp866 будет по прежнему можно, а вот указывать кодировку - только для строки по указателю.
И в итоге все равно новый заголовок...

Это половинчатое решение. В большинстве примеров, которые я видел, путь вписан в структуру. Для перехода на utf-8 придётся много править.

Serge
Разве дублирование кода не является плохим решением в программировании?

Есть ли другое решение?

_________________
Звиздеть не мешки ворочать

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

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

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

_________________
Звиздеть не мешки ворочать

Суть проблемы.
Ожидания:
1. Автор что-то сделал.
2. Другие находят то, что получилось плохо, и предлагают как сделать лучше.
Реальность:
1. Автор что-то сделал.
2. Проходит время.
3. Другие начинают обвинять автора.
4. Автор сам думает, как всем угодить.

Serge
Путь, который вписан в структуру, останется в ср866. Обычно это абсолютный путь в пределах рамдиска (ascii), ему и юникод не нужен, и с символов ☺☻ он точно никогда не начинается. Так что решение полноценное.

По поводу моего ника, есть такое слово и такое слово

Ты удивлён ?

Раньше подобные изменения предварительно обсуждались:
Работа с файловой системой
Удаление 58 сис. функции из ядра.
Новая модель ядра
Плоская модель памяти
Автомонтирование дополнительного раздела с приложениями

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


menuetlibc вписывает путь в структуру. Я предполагаю, что diamond и Марат чаще вписывали путь в структуру. Это усложнит перевод их программ на unicode по сравнению с новыми функциями.

В данную минуту я слабо разбираюсь в вопросе, а потому не знаю что тебе ответить.
Но есть три вопроса:
Какая кодировка по умолчанию используется в испанской версии колибри?
Как без поддержки юникода в определенной локали одновременно отображать (и использовать) в пути символы из похожих кодировок: cp437 и cp866, например?
Pathoswithin
С какой целью ты начал внедрение поддержки unicode?

Это писал diamond. Кстати оба планировали и обсуждали предстоящие изменения. Поэтому я не помню, чтобы они что-то серьёзно поломали.
Это неизбежное зло, если код принимает данные в двух разных форматах. Добавить новые подфункции принимающие utf8 к ф.70 лучше, чем менять поведение существующих.
Фактически и добавление / к префиксу и изменеие байта со смещением 0x14 в параметрах ф.70 это латание дыр на скорую руку. Новые костыли.

Мне в Eolite надо будет добавлять эти функции для работы с UTF или интерфейс будет тот же, а функции будут добавлены в ядре?

Как мне узнать в каком формате имя файла?

_________________
Звиздеть не мешки ворочать

Serge
Читал я те обсуждения. Создалось впечатление, что пока как-то не сделаешь, всем всё пофиг. Разница только в том, что потом можно носом ткнуть и сказать что предупреждал. Но что мне с того? Вот тут что-то решили, но теперь всё равно переделывать, проблемы то всплывают только на практике.
Я эти изменения внёс несколько месяцев назад, а заметили только сейчас. Так сильно поломалась совместимость.
Я люблю качественную критику, а не обвинения.

И всё таки я не понял, зачем переводить на unicode путь который вписан в структуру?

Mega_Myr
Странный вопрос. До этого была только ср866 и всё.

Leency
Можно сделать либо параметр кодировки в 70 функции, либо отдельные функции для каждой кодировки.