Board.KolibriOS.org

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

Вот тут что-то решили

Разница только в том, что потом можно носом ткнуть и сказать что предупреждал

Если ввести новые функции, как это затронет файловые менеджеры?

Какие изменения (какие проверки для каких случаев) нужно будет внести?

Serge wrote:Остаётся проблема с путём приложения. Сейчас приложение получает его в кодировке ср866. Эту проблему можно решить новым заголовком. Заодно и снять ограничение на длину пути, если это актуально.

Сломается мало, а все что сломается должно и может переехать в англоязычные каталоги.

Serge wrote:Siemargl
Старое ограничение на длину командной строки снято. Теперь 64Кб, включая ноль. Главное, чтобы приложение читало адрес из заголовка.

Сломается мало, а все что сломается должно и может переехать в англоязычные каталоги.

Или сидит на старом ядре.
Не знаю. Может и так. У меня тоже нет большого желания городить новый заголовок и делать ещё один внутриядерный режим работы.

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

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

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

Serge wrote:Допустим есть приложение у которого путь вписан в структуру. И его надо переделать на unicode.

Путь запуска приложения сейчас в utf-8 с маркером, и да, есть ещё и пофигистичный вариант - просто убрать маркер. Тогда существующие приложения смогут работать только с путём в ASCII, зато больше ничего делать не придётся.

Переделать на unicode это значит сменить кодировку всего текстового файла? То есть нельзя оставить отдельные строки в ср866? Впрочем, на ассемблере переместить статическую строку как раз просто

Leency wrote:Serge
В Windows 7, 10 какая кодировка? UTF8?
Имена в NTFS в UTF8?

Если ввести новые функции, как это затронет файловые менеджеры?
Какие изменения (какие проверки для каких случаев) нужно будет внести?

Тогда я не понимаю, зачем переводить в unicode конкретно тот путь, который вписан в структуру? Он же статический.

• Посредством новой SysFn говорим ядру "моё приложение хочет работать с юникодом".
  И после этого все функции работают в режиме юникода.
  Надо будет только добавить в APPDATA новое поле encoding.
  Тогда функции вместо проверки префикса будут просто проверять APPDATA.encoding.
  Можно в зависимости от значения APPDATA.encoding добавить возможность работы с разными кодировками, например ASCII|UTF8|UTF16|UTF32.
  
  Есть нюанс с DrawText. Там есть флаг кодировки. Но и сейчас там проблема. Кодировки префикса и флага могут отличаться.
  
  Насчёт AppPath вариант такой:
  В заголовке программы вместо

  Code: Select all

  version        dd 1

  можно сделать

  Code: Select all

  version        dw 1
  encoding       db ?
  reserved       db ?

  Это будет обратно совместимо, если принять, что для ASCII значение encoding = 0.
  Так что, больше не надо никаких префиксов

LastEncoding = SetEncoding(ENC_UTF16);
/* do somthing */
SetEncoding(LastEncoding);

ASCII = 0
UTF16 = 1 ; SysFn70 уже использует 1 = UTF-16LE
UTF8  = 2
UTF32 = 3

• не нужно новых заголовков
  не нужно дублирования функций
  не нужно префиксов
  возможность установки encoding с помощью одной SysFn сразу для всех функций

Serge wrote:Только не APPDATA, а PROC - данные всего процесса.

Serge wrote:Появляется два режима работы и куча мест, где надо проверять флаги и делать ветвление.

LastEncoding = SetEncoding(ENC_UTF16);
/* А здесь то же самое, что было раньше для ASCII или просто вызов уже существующей ASCII-обёртки */
SetEncoding(LastEncoding);