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

Applications development, KoOS API questions
  • 0CodErr wrote:А ты про ядро или ЯВУ?
    Про ядро.
    А если надо UTF-16 передать или UTF-32? Фиксированная кодировка это не гибко
    Не надо utf16/32. Должна быть одна кодировка Пусть будет utf8.
    За всем этим может следить ядро и конвертировать лишь при необходимости, если не будут совпадать кодировки передающего и принимающего параметры.
    Не надо нагружать ядро лишней работой.
  • 0CodErr
    То есть в таком случае ты предлагаешь 100500 раз переключать кодировки?
    Использовать параметр версии это тоже самое, что и новый заголовок.
    Spoiler:Где у меня написано "кодировка argv[0] всё равно фиксирована"? :wink:
  • Pathoswithin wrote:Где у меня написано "кодировка argv[0] всё равно фиксирована"? :wink
    А ты уже отредактировал сообщение, хитрец :P
    Pathoswithin wrote:Использовать параметр версии это тоже самое, что и новый заголовок.
    Не параметр. Я не предлагаю менять версию. Просто, как оказалось, в заголовке есть поля, которые можно считать зарезервированными. Потому что для номера версии вполне хватило бы word или даже byte.
    В заголовке программы вместо

    Code: Select all

    version        dd 1
    можно сделать

    Code: Select all

    version        dw 1
    encoding       db ?
    reserved       db ?
    Pathoswithin wrote:То есть в таком случае ты предлагаешь 100500 раз переключать кодировки?
    Ты просто посмотри, как работают реальные программы. В основном везде используется одна и та же кодировка за редким исключением. Переключать если придётся, то, всего несколько раз, но не 100500 это точно.
    Serge wrote:Не надо нагружать ядро лишней работой.
    Ну хорошо, приложения сами будут это делать. Легче от этого? Шило на мыло. В ядре — это значит централизованно только в одном месте, а не в каждом приложении.
    Serge wrote:Про ядро.
    В основном предлагаемые изменения в первую очередь касаются файловых функций. В которых узкое место — это доступ к диску, а никак не дополнительные проверки, которые, будут практически незаметны. Плюс ещё время на int 64 добавь сюда.
    Serge wrote:Не надо utf16/32. Должна быть одна кодировка Пусть будет utf8.
    Ну и в итоге тормоза и дополнительные неудобства тебе обеспечены.
    UTF32 хороша тем, что можно очень легко обратиться к i-ому символу строки. Это сравнимо по скорости с ASCII. Только здесь 4 байта вместо 1-го. А вот в UTF8 тебе придётся сканировать всю строку до этого символа. Ну и с остальными строковыми функциями та же ситуация. Отказываться от UTF16, думаю, плохая идея. Потому что она в SysFn70 уже используется. Возможно, будет добавлена поддержка в SysFn2, там и 2 байта хватит, так как Basic multilingual plane вполне достаточно для ввода с клавиатуры.
    Ну а UTF8 получается, что самая худшая из них. Разве что совместимость с ASCII, но в Колибри, в которой 1,5 более менее серьёзных приложения, эта совместимость просто не нужна. Не с чем совмещаться.
  • Сейчас драйвера файловых систем работают на UTF-8 и всё в неё перекодируется, так что это "родная" кодировка. И совместимость с ASCII пригодилась.
    Всё что в пределах первых 8 байт заголовка принципиально одно и то же. Версия сейчас вообще не используется (кстати, можно использовать под путь для иконки).
  • Pathoswithin wrote:Версия сейчас вообще не используется (кстати, можно использовать под путь для иконки).
    Пока не надо с этим торопиться. Это потенциально целых 32 флага.
    Pathoswithin wrote:Сейчас драйвера файловых систем работают на UTF-8 и всё в неё перекодируется, так что это "родная" кодировка. И совместимость с ASCII пригодилась.
    Мой вариант позволяет выбрать ту кодировку, которая необходима, тогда, когда это необходимо. То есть, максимально гибко. Зачем искусственно ограничиваться? Мне не понятно.
    Если путь будет передаваться в UTF8, то нельзя будет присоединить к нему кириллическое "Папка1" в ASCII. Нужен, значит, конвертер. Только непонятно, зачем не русскоязычному пользователю использовать русифицированный вариант программы. В общем, UTF8 только усложняет всё. Должен быть выбор кодировки. Пусть лучше ядро конвертирует, чем приложению придётся таскать конвертер с собой.
  • Запустил вот GetPathC.kex в одной из старых сборок #2306
    Spoiler:
    1.PNG
    1.PNG (13.83 KiB)
    Viewed 4439 times
    Можете сравнить с тем, что выводится сейчас в первом сообщении этой темы viewtopic.php?f=2&t=3429#p67134
  • 0CodErr
    Потому, что ср866 базовая кодировка ядра и console.obj. Попробуй напечатать символ, который в cp866 не входит. Если сменить кодировку app_path на utf-8 приложение не сможет его правильно вывести на экран, но сможет распарсить на компоненты.
    0CodErr wrote:Мой вариант позволяет выбрать ту кодировку, которая необходима, тогда, когда это необходимо. То есть, максимально гибко. Зачем искусственно ограничиваться? Мне не понятно.
    Ты просто предлагаешь раздуть ядро, свалив на него функциональность, которой не хочется заниматься самому. Актуальность UTF32 в прикладных программах 0.(0)% В ядре должна быть одна кодировка. Устанавливать ascii/unicode режим работы ядра в зависимости от флагов в заголовке imho неудачная идея.
  • Serge wrote:Если сменить кодировку app_path на utf-8 приложение не сможет его правильно вывести на экран, но сможет распарсить на компоненты.
    Это сути не меняет:
    0CodErr wrote:Если путь будет передаваться в UTF8, то нельзя будет присоединить к нему кириллическое "Папка1" в ASCII. Нужен, значит, конвертер. Только непонятно, зачем не русскоязычному пользователю использовать русифицированный вариант программы. В общем, UTF8 только усложняет всё. Должен быть выбор кодировки. Пусть лучше ядро конвертирует, чем приложению придётся таскать конвертер с собой.
    Serge wrote:В ядре должна быть одна кодировка.
    Ну дык тогда логичнее сделать её UTF16:
    • Она уже используется в SysFn70;
      Её использование легко добавить в SysFn2
      Обработка строк UTF16 происходит быстрее(нужно меньше проверок)
    Serge wrote:Ты просто предлагаешь раздуть ядро, свалив на него функциональность, которой не хочется заниматься самому.
    Какая по большому счёту разница, где будет этот код? Разница в том, что ядро и так уже работает и с ASCII, и с UTF8, и с UTF16. По-твоему лучше ещё раз продублировать этот код в приложении вместо того, чтобы просто использовать готовый ядерный код? Можно многое вынести из ядра в драйвера и библиотеки. Но раз уж оно сейчас находится в ядре, то и вполне логично, что эту работу будет выполнять ядро.
    Serge wrote:Только не APPDATA, а PROC - данные всего процесса.
    Лучше APPDATA. Представь, что поток работает с UTF16, и тут БАЦ! и кодировка внезапно сменилась.

    Если AppPath будет только в UTF8, то CurrentDirectory и Params вполне могут быть в другой кодировке. Во первых, как приложению узнать, в какой? Во-вторых, снова нужен конвертер.

    SysFn70 может возвращать UTF16. Если теперь запустить такое приложение, то нам надо указать и имя файла, которое в UTF16, и параметры, только в какой кодировке не понятно?

    Что касается UTF16, то приложение может проверить, не выходит ли строка за рамки UCS2, и тогда можно работать с этой строкой с заметным ускорением.

    В общем, если даже делать для unicode одну кодировку, то лучше всего подходит для этого UTF16. переключение ASCII\unicode, разумеется, необходимо.
  • Лучше APPDATA. Представь, что поток работает с UTF16, и тут БАЦ! и кодировка внезапно сменилась.
    1. С чего это она так внезапно изменится ? Её только автор приложения может изменить.
    2.Чтобы не было таких внезапных БАЦ, не надо заводить в ядре режимов.
    Пусть лучше ядро конвертирует, чем приложению придётся таскать конвертер с собой.
    Ядро не безразмерно.
  • Serge wrote:1. С чего это она так внезапно изменится ? Её только автор приложения может изменить.
    :lol: Ну с таким же успехом и от мьютексов можно отказаться тогда. У нас приложения могут быть многопоточными.
    Serge wrote:Ядро не безразмерно.
    А никто не спорит же.
    0CodErr wrote:Какая по большому счёту разница, где будет этот код? Разница в том, что ядро и так уже работает и с ASCII, и с UTF8, и с UTF16. По-твоему лучше ещё раз продублировать этот код в приложении вместо того, чтобы просто использовать готовый ядерный код? Можно многое вынести из ядра в драйвера и библиотеки. Но раз уж оно сейчас находится в ядре, то и вполне логично, что эту работу будет выполнять ядро.
    Ну можно вынести часть ядерного кода в библиотеку. Но всё равно ведь и ядро и приложения будут его использовать. Только придётся ещё в обязательном порядке грузить эту библиотеку.
  • Вот маркеры кодировки строк в других ОС не используются, а установка кодировки для всего потока? Потому что это уже противоположная крайность получается.
  • Pathoswithin, те кто привык к винде, могут написать себе обёрток с суффиксами A\W по принципу

    Code: Select all

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

    А так обычно определяется как-то так

    Code: Select all

    function GetCurrentDirectory; external kernel32 name 'GetCurrentDirectoryA';
    function GetCurrentDirectoryA; external kernel32 name 'GetCurrentDirectoryA';
    function GetCurrentDirectoryW; external kernel32 name 'GetCurrentDirectoryW';
    В общем, можно продублировать сисфункции, а можно добавить одну, устанавливающую кодировку сразу для всех сисфункций.
  • По два раза на вызов переключать кодировку? Может более дубовый? Наоборот с классическим подходом можно один раз определить
    function GetCurrentDirectory; external kernel32 name 'GetCurrentDirectoryW';
    и получится то что ты хочешь.
  • Вот опять ты суть не улавливаешь.

    Да, они так и определены все с суффиксом

    Code: Select all

    function GetCurrentDirectory; external kernel32 name 'GetCurrentDirectoryW';
    А чтобы так не делать, вызываешь просто один раз SetEncoding и всё! Теперь с этого момента GetCurrentDirectory и все остальные функции будут работать в нужной кодировке, до тех пор, пока ты снова её не переключишь. Может даже и до самого ThreadTerminate будут в этой кодировке работать.
    Pathoswithin wrote:По два раза на вызов переключать кодировку?
    Ну нет, конечно же!
    ОДИН раз ты переключился, и дальше работаешь в юникоде. Если когда-нибудь захотел обратно в ASCII, то также только ОДИН раз вызываешь.
    Вероятно, тебя смутила фраза
    0CodErr wrote:те кто привык к винде, могут написать себе обёрток с суффиксами A\W
    но это, действительно, только для тех, кто привык так делать, то есть, использовать функции с суффиксами.
  • Who is online

    Users browsing this forum: Ahrefs [Bot] and 1 guest