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

Applications development, KoOS API questions
  • Newlib пока не умеет с локалями работать. Все преобразования в пределах базового набора ASCII.
  • Похоже, это может вызвать некоторые проблемы, например,
    viewtopic.php?f=45&t=3237&start=45#p67156
    viewtopic.php?f=5&t=1602&p=67163#p67114
    Также, у нас приложения на путь резервируют 1024 байта(как раз на 1024 символа).
    С UTF-8 уже 1024 байта может быть недостаточно для 1024 символов.

    Вот что я предлагаю:
    Ядро ведь всё равно не даст приложению больше, чем 2 Гб.
    Можно использовать старший бит указателя на путь в заголовке, чтобы сообщить ядру, что приложение хочет принять путь в Unicode.
    Только лучше не UTF-8, а UTF-16. Насколько знаю, Newlib умеет работать с wchar. И посчитать размер буфера проще, это 1024 * 2 = 2048 байтов.
    Это не проблема, чтобы добавить в линкер-скрипт

    Code: Select all

    LONG(___pgmname | 0x80000000);     /*  full path    */
    Siemargl wrote:Мне кажется, что воткнуть в начало пути байт кодировки было не самым удачным решением в принципе.
    И это проблема, конечно. Раньше пути начинались со слэша. Вот представим, что есть путь "/sys/Path/MyFile.ext". Если приложение захочет проверить (Path == "/sys/Path/MyFile.ext"), то вместо простого StrCmp(Path, "/sys/Path/MyFile.ext") придётся немного мудрить ещё.
  • Сейчас максимальная длина пути 4096 байт в UTF-8.
    Проблема в том, что приложение не знает откуда оно будет запущено. Я выбрал такой подход из-за того, что к концу строки можно добавить имена в ASCII и не беспокоится об остальном пути. То есть, все существующие приложения могут быть запущены откуда угодно, а проблем с совместимостью вроде почти не возникло.
  • 0CodErr wrote:Похоже, это может вызвать некоторые проблемы, например,
    вместо простого StrCmp(Path, "/sys/Path/MyFile.ext") придётся немного мудрить ещё.
    О чём я и предупреждал.
  • Никаких UTF-16. Оно имело смысл лет этак двадцать назад, когда 65536 символов ещё хватало всем, но сейчас у неё нет никаких преимуществ перед UTF-8.
    Сделаем мир лучше!
  • 0CodErr wrote:....
    Также, у нас приложения на путь резервируют 1024 байта(как раз на 1024 символа).
    С UTF-8 уже 1024 байта может быть недостаточно для 1024 символов.
    ....
    Странно, я вроде бы встречал 4096 символов в программах в буфере на полное имя файла.

    Так, поразбираемся
    SysFn70.1 не поддерживает UTF-8, нужно расширять варианты кодировок в ядре.
    Буфер для имени для SysFn70.1 не более чем 512 байт
    OpenDialog, Filebrowser - не поддерживают многобайтные кодировки

    NTFS - м.б.проблема - каждое имя каталога до 256 символов (UTF16), полный путь в сборе 32к
    https://msdn.microsoft.com/en-us/library/aa365247.aspx, хотя рекомендуется до Win10 ограничиваться 256 символами на весь путь (260 с именем диска).
    FAT32 - 255 в виде символов UCS2
    XFS, EXTx - 255 байт
    Joliet - 64 символа UCS2
    UDF - 255 байт

    Итого будут проблемы с длиной имени:
    -при массовом применении UTF-8, если массово используются 3-4х-байтовые буквы
    -возможно, с NTFS когда символы не помещаются в UCS2 (а может на такие можно честно ругаться и не поддерживать?)
    -UDF (DVD диски)
    -в ядре с поддержкой кодовых точек UTF16

    Вот ответ системы как описать - простите, ваше имя длиной в 250 букв, но оно не влезает?
    Т.е не существует константы MAX_PATH
    CleverMouse wrote:Никаких UTF-16. Оно имело смысл лет этак двадцать назад, когда 65536 символов ещё хватало всем, но сейчас у неё нет никаких преимуществ перед UTF-8.
    Это UCS2 ограничена 16 бит на символ.
  • Siemargl wrote:Странно, я вроде бы встречал 4096 символов в программах в буфере на полное имя файла.
    Здесь вот пишут, что 1024:
    viewtopic.php?f=24&t=1456&p=29598#p29598
    viewtopic.php?f=7&t=1936#p37925
    viewtopic.php?f=1&t=2297&p=48469#p48469
  • Не знаю, кто когда чего писал, а сейчас в ядре есть константа maxPathLength = 1000h.
  • Раньше та информация была актуальной, а maxPathLength появилась сравнительно недавно в #6468. Вот только написанные ранее приложения о ней не знают.
  • Она появилась ещё в #1304, а до того значения тоже были 1000h.
  • В #1304

    Code: Select all

    max_cur_dir equ 0x1000
    используется в SysFn30.
    А потом ты убрал max_cur_dir и стал использовать maxPathLength.
    Но max_cur_dir это длина пути текущей директории, а не размер буфера, в который ядро пишет путь приложения.
    Вообще-то, почти 7 лет прошло с появления max_cur_dir.
    Думаешь, там
    viewtopic.php?f=24&t=1456&p=29598#p29598
    viewtopic.php?f=7&t=1936#p37925
    viewtopic.php?f=1&t=2297&p=48469#p48469
    не знали про неё?. :)
  • Вопрос не в том, знали - не знали.
    Вопрос -куда мы хотим стремиться?

    Я не против utf8, при условии нормальной ее поддержки системой.
    Тем не менее, в ядре пока по дефолту 866
  • Первоначально размер буфера был 36 (тридцать шесть) байт - #5.
    В #91 diamond написал новый загрузчик приложений и увеличил буфер до 1024 байт.
    Его размер не менялся до #6502, пока Pathoswithin не ввёл utf-8. При этом изменение размера нигде не объявлено, а проверки на размер в ядре нет. Теперь ядро может записать туда до 4К и затереть память приложения. На совместимость традиционно забили.
    max_cur_dir был установлен в 4К потому, что память для него выделялась KernelAlloc(), а у неё страничная гранулярность.
  • А разве размер изначально где-то был объявлен? В коде было где как: и 1024, и 4096, и даже 260. Теперь везде одна константа. Где приложения работали, там по прежнему работают.
  • Who is online

    Users browsing this forum: No registered users and 6 guests