Page 5 of 16
Re: "Ночные" сборки KolibriOS
Posted: Wed Nov 23, 2016 10:11 pm
by Serge
Pathoswithin
Тогда пусть будет 2 байта для абсолютного пути. Потенциально сломаны все программы слинкованные с newlib или menuetlibc.
Не работает пока ваша юникода. см.чат.
Потому, что нарушена совместимость с POSIX и абсолютный путь превратился локальный
Code: Select all
if (filename[0]=='/')
{
strcpy(buf,filename);
}
else
{
getccwd(buf, 1024);
buildpath(buf, filename);
}
И это не проблема newlib или menuetlibc.
Не факт, что двухбайтный префикс сильно поможет. С именами типа "☺файляYYYY866.ttt" будут постоянно проблемы. ☺/tmp0/1/222/☺файляYYYY866.ttt валидный путь для файла файляYYYY866.ttt в каталоге /tmp0/1/222 или нет ?
Майкрософт не случайно сделала ASCII и Unicode версии системных функций.
Re: "Ночные" сборки KolibriOS
Posted: Wed Nov 23, 2016 10:25 pm
by Pathoswithin
Нет, маркер кодировки не является частью строки, это информация о ней, как ВОМ. Сначала маркер, потом строка: ☺/tmp0/1/222/файляYYYY866.ttt. Для cp866 как и раньше можно без маркера.
Re: "Ночные" сборки KolibriOS
Posted: Wed Nov 23, 2016 10:31 pm
by Serge
В результате с именами "♥мой_файл" будут проблемы.
Префикс перед именем - скверная идея.
Re: "Ночные" сборки KolibriOS
Posted: Wed Nov 23, 2016 10:39 pm
by Serge
Лучше всего сделать отдельные функции для utf кодировки.
Ещё в копилку
gboolean
g_path_is_absolute (const gchar *file_name)
{
g_return_val_if_fail (file_name != NULL, FALSE);
if (G_IS_DIR_SEPARATOR (file_name[0]))
return TRUE;
#ifdef G_OS_WIN32
/* Recognize drive letter on native Windows */
if (g_ascii_isalpha (file_name[0]) &&
file_name[1] == ':' && G_IS_DIR_SEPARATOR (file_name[2]))
return TRUE;
#endif
return FALSE;
}
Это
GLib Подобного кода написаны гигабайты. И весь этот код стал несовместим с Колибри.
Re: "Ночные" сборки KolibriOS
Posted: Wed Nov 23, 2016 11:05 pm
by Pathoswithin
Serge
А зачем префикс перед именем? Откуда такие имена возьмутся?
Re: "Ночные" сборки KolibriOS
Posted: Wed Nov 23, 2016 11:16 pm
by Siemargl
Pathoswithin wrote:Serge
А зачем префикс перед именем? Откуда такие имена возьмутся?
Ну например, что должна возвращать команда чтения каталога при унификации.
В общем, надо переделывать, только решить как.
Заодно предлагаю решить проблему рабочего каталога, который ни к чему не привязан.
Можно еще подумать про сетевые диски и относительные пути ../, .../, итп
Например, можно к 70.1, 70,2,... сделать их юникодные версии 70.31, 70.32
Re: "Ночные" сборки KolibriOS
Posted: Wed Nov 23, 2016 11:26 pm
by Serge
Pathoswithin wrote:Serge
А зачем префикс перед именем? Откуда такие имена возьмутся?
Т.е. я не могу прочитать "♥мой_файл" из текущего каталога ? Обязательно полный путь формировать надо ?
Siemargl wrote:Заодно предлагаю решить проблему рабочего каталога, который ни к чему не привязан.
Что значит не привязан ?
Re: "Ночные" сборки KolibriOS
Posted: Wed Nov 23, 2016 11:39 pm
by Siemargl
Serge wrote:Siemargl wrote:Заодно предлагаю решить проблему рабочего каталога, который ни к чему не привязан.
Что значит не привязан ?
А куда он указывает, на /rd/1 ???
Было бы нормальным, если бы это был рабочий каталог запускаемой программы, указанный явно при запуске или неявно был каталогом запуска программы.
Можно конечно, такую логику делать и руками, просто /rd/1 эквивалентно пустышке.
Re: "Ночные" сборки KolibriOS
Posted: Wed Nov 23, 2016 11:42 pm
by Serge
Pathoswithin
Если интересует, как обрабатывается Unicode в сишных программах, посмотри GLib. Там все строки хранятся в utf8. Для вызовов WinAPI строки конвертируются из utf8 в utf16. Linux понимает utf8. При этом специальные байты для обозначения кодировки не применяются.
Re: "Ночные" сборки KolibriOS
Posted: Wed Nov 23, 2016 11:44 pm
by Serge
Siemargl
Уже много раз обсуждалось. Наследуется от родительского процесса. Как и должно быть. Это не проблема ядра, там с текущим каталогом всё (почти) правильно.
Re: "Ночные" сборки KolibriOS
Posted: Wed Nov 23, 2016 11:57 pm
by Siemargl
Serge wrote:Siemargl
Уже много раз обсуждалось. Наследуется от родительского процесса. Как и должно быть. Это не проблема ядра, там с текущим каталогом всё (почти) правильно.
Ок. Я запускаю с рабочего стола еолайт. У него в иконке записан путь /sys/file managers/eolite
Дальше, запускаю из еолайта shell.
И что я вижу в pwd? /rd/1/
Отлично отнаследовалось.
Меняем каталог cwd, запускаем из шелл, например kfm или kfar - Они опять в /rd/1
Получается, что рабочего каталога по умолчанию у программы нет.
Кстати, шрифты действительно накрылись.
Re: "Ночные" сборки KolibriOS
Posted: Thu Nov 24, 2016 12:17 am
by Serge
Siemargl
Всё правильно. Shell расположен в /rd/1. Скопируй shell в /tmp0/1 и запусти оттуда.
Re: "Ночные" сборки KolibriOS
Posted: Thu Nov 24, 2016 12:25 am
by Serge
Меняем каталог cwd, запускаем из шелл, например kfm или kfar - Они опять в /rd/1
На что меняем ? Ты про это:
Kfar и KFM после запуска показывают на левой панели /rd/1/ и /hd0/1/ на правой. Это by design.
Оба кстати меняют текущий каталог при навигации.
Re: "Ночные" сборки KolibriOS
Posted: Thu Nov 24, 2016 2:59 am
by Pathoswithin
Вообще-то, меня интересовало как сишные программы получают в юникоде путь запуска.
Siemargl
"../" в относительных путях поддерживается... но это нигде не документировано.
Re: "Ночные" сборки KolibriOS
Posted: Thu Nov 24, 2016 3:44 am
by Serge
В никсах передаётся в вершине стека. Подробно расписано в
System V Application Binary Interface страница 54
Process Stack and Registers Кодировка строк не определена, могут быть и в utf-8. Строки нуль терминированные.
В Windows при помощи GetCommandLineW(). Сама строка скорее всего так же хранится в стеке. Потом рантайм разбирает строку на на аргументы. Примерно так LPWSTR* lpArgv = CommandLineToArgvW( GetCommandLineW(), &argc );