Путь приложения

Applications development, KoOS API questions
  • Serge
    "Новая функция сохраняющая текущий формат вызова ф.70" это подфункция 70?

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

    Если ввести новые функции, как это затронет файловые менеджеры?
    Какие изменения (какие проверки для каких случаев) нужно будет внести?
    Из хаоса в космос
  • Leency
    Да. Что мешает создать 70.10 70.11 и т.д ? Там 32 бита для подфункции.
    В Windows UTF-16
    Если ввести новые функции, как это затронет файловые менеджеры?
    Существующие сейчас никак.
    Какие изменения (какие проверки для каких случаев) нужно будет внести?
    Появление новых функций не должно затрагивать существующий код. Дальше - уже забота прикладных программистов, как они будут использовать новые возможности. Давно есть возможность читать содержимое каталогов в UTF-16, не знаю пользуются ли ей кто-нибудь.

    Для всех лучше когда изменения и нововведения полностью совместимы с уже написанным кодом.
    По моему мнению лучший вариант - новые подфункции для ф.70 и ф.30 принимающие строки в utf8
    Остаётся проблема с путём приложения. Сейчас приложение получает его в кодировке ср866. Эту проблему можно решить новым заголовком. Заодно и снять ограничение на длину пути, если это актуально.
  • Serge wrote:Остаётся проблема с путём приложения. Сейчас приложение получает его в кодировке ср866. Эту проблему можно решить новым заголовком. Заодно и снять ограничение на длину пути, если это актуально.
    Пусть все получают путь в UTF8 и радуются, как и предлагала Мышь.
    Сломается мало, а все что сломается должно и может переехать в англоязычные каталоги.

    Ограничение на длину пути не считаю актуальным, более актуален размер буфера для параметров программы - он должен быть большим (см, например, сколько передается ar при сборке newlib - целый экран параметров, а он может быть и юникодным)

    Но приведение в порядок/унификация функций 70+30 при апгрейде до юникода - вот это актуально.
  • Siemargl
    Старое ограничение на длину командной строки снято. Теперь 64Кб, включая ноль. Главное, чтобы приложение читало адрес из заголовка.
    Сломается мало, а все что сломается должно и может переехать в англоязычные каталоги.
    Или сидит на старом ядре.
    Не знаю. Может и так. У меня тоже нет большого желания городить новый заголовок и делать ещё один внутриядерный режим работы.
  • Serge wrote:Siemargl
    Старое ограничение на длину командной строки снято. Теперь 64Кб, включая ноль. Главное, чтобы приложение читало адрес из заголовка.
    Сломается мало, а все что сломается должно и может переехать в англоязычные каталоги.
    Или сидит на старом ядре.
    Не знаю. Может и так. У меня тоже нет большого желания городить новый заголовок и делать ещё один внутриядерный режим работы.
    По моему, овчинка выделки не стоит. Слишком мелочь, чтобы существенно менять ядро.
    Leency wrote:0CodErr
    В данный момент PathOsWithin делает много полезного, реально пишет код - то, чего многие другие не делают и хотя бы за это его нужно уважать.

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

    Именно PathOsWithin взялся решать задачу юникода, не ты. Он потратил на это много времени, своего времени. И он принял определенные решения в процессе решения задачи и возможно не всегда оптимальные. Ты как человек который не взялся решать эту задачу можешь дать отзыв о его работе, предложить варианты и скажем провести голосование, но никак не оскорблять.
    Плюс еще никто, включая достаточно опытных людей, не смог предвидеть полный масштаб последствий. Так что не вижу оснований для претензий.
  • Ограничится подфункциями 70-ой не просто: параметр идёт глубоко, аж до файловых систем, а редактировать структуру нельзя. Проще сделать ещё две идентичные функции, а 70-ую оставить только ср866.

    Путь запуска приложения сейчас в utf-8 с маркером, и да, есть ещё и пофигистичный вариант - просто убрать маркер. Тогда существующие приложения смогут работать только с путём в ASCII, зато больше ничего делать не придётся.
    Serge wrote:Допустим есть приложение у которого путь вписан в структуру. И его надо переделать на unicode.
    ... ?
    Переделать на unicode это значит сменить кодировку всего текстового файла? То есть нельзя оставить отдельные строки в ср866? Впрочем, на ассемблере переместить статическую строку как раз просто.
  • Путь запуска приложения сейчас в utf-8 с маркером, и да, есть ещё и пофигистичный вариант - просто убрать маркер. Тогда существующие приложения смогут работать только с путём в ASCII, зато больше ничего делать не придётся.
    Маркер само собой надо убирать. Так что да, будут проблемы если в path будут символы не попадающие в базовый набор. Неприятно, но не фатально.
    Переделать на unicode это значит сменить кодировку всего текстового файла? То есть нельзя оставить отдельные строки в ср866? Впрочем, на ассемблере переместить статическую строку как раз просто
    Почему весь ? Только код работы с файловой системой.
  • Leency wrote:Serge
    В Windows 7, 10 какая кодировка? UTF8?
    Имена в NTFS в UTF8?

    Если ввести новые функции, как это затронет файловые менеджеры?
    Какие изменения (какие проверки для каких случаев) нужно будет внести?
    Прошу ответить людей знающих, ибо я как прикладной программист не совсем понимат.
    Из хаоса в космос
  • Весь юникод в windows это UTF-16, в linux - UTF-8.

    Сами по себе нововведения никак не затронут, совместимость жеш. Если будешь делать поддержку юникода, что тебе будет удобней: байт кодировки перед указателем на строку в структуре 70 функции (сейчас там всегда 0) или отдельные идентичные функции для юникода?

    Serge
    Тогда я не понимаю, зачем переводить в unicode конкретно тот путь, который вписан в структуру? Он же статический.
  • Тогда я не понимаю, зачем переводить в 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.
      Так что, больше не надо никаких префиксов :)
    Предлагаю добавить 2 SysFn: SetEncoding и GetEncoding. Пусть SetEncoding возвращает старую кодировку. То есть можно было бы писать

    Code: Select all

    LastEncoding = SetEncoding(ENC_UTF16);
    /* do somthing */
    SetEncoding(LastEncoding);
    Не знаю, нужно ли поддерживать сразу и BigEndian и LittleEndian? Просто пока предлагаю такие константы

    Code: Select all

    ASCII = 0
    UTF16 = 1 ; SysFn70 уже использует 1 = UTF-16LE
    UTF8  = 2
    UTF32 = 3
    Преимущества этого подхода:
    • не нужно новых заголовков
      не нужно дублирования функций
      не нужно префиксов
      возможность установки encoding с помощью одной SysFn сразу для всех функций
  • Только не APPDATA, а PROC - данные всего процесса. Но мне эта идея не очень нравится. Появляется два режима работы и куча мест, где надо проверять флаги и делать ветвление.
  • Serge wrote:Только не APPDATA, а PROC - данные всего процесса.
    Ну можно и сразу для всего делать. Мне трудно сказать, как будет лучше.
    Serge wrote:Появляется два режима работы и куча мест, где надо проверять флаги и делать ветвление.
    А ты про ядро или ЯВУ?
    Просто можно продублировать обёртки для сисфункций

    Code: Select all

    LastEncoding = SetEncoding(ENC_UTF16);
    /* А здесь то же самое, что было раньше для ASCII или просто вызов уже существующей ASCII-обёртки */
    SetEncoding(LastEncoding);
    
  • Не понял, что в этом хорошего? А если приложение хочет использовать ср866 для статических строк и UTF-16 для всего остального?
  • Who is online

    Users browsing this forum: No registered users and 7 guests