Board.KolibriOS.org

Что, кстати, насчёт той viewtopic.php?f=38&t=1277&start=600#p67688 идеи? Ну пусть это будет не кавычка, пусть слэш будет.

... null.
Если уж на то пошло, в новых функциях я планирую немного сменить формат: сначала указатель на строку (dword), а если он равен нулю, то после него непосредственная строка. А то diamond как-то криво сделал. А зачем это надо? Пример можешь привести?

Вот зря. Посмотри код file_system_lfn, найди место где подфункция проверяется на допустимое значение. Структура кода далека от идеала.

file_system_lfn я уже переписал, а валидацию давно сделала CleverMouse, вместе с dyndisk_handler. Его код это отдельная тема, в данном случае я имел в виду API viewtopic.php?f=35&t=475&start=29

Что зачем надо? Чтобы сравнить скорость обработки UTF8 и UTF16, например. Или опять дурачка включаешь?
Вот хочу я, к примеру, обрабатывать 100 Гб в час. 1 миллиард символов ASCII это примемрно 1 Гб, просто, чтобы было понятно сколько это. Тогда за сутки это будет более 2-ух Тб. Вот и считай, какие будут каждый день накладные расходы на каждый символ в случае UTF8.
Вообще, как я уже писал выше, можно проверять, не выходит ли UTF16 строка за рамки UCS2, и, если нет, то обработка будет куда быстрее(так как 2 байта на символ). В подавляющем большинстве случаев будет вполне достаточно UCS2.

А что насчёт тебя?

Ты теоретизируешь - сделай бенчмарк и потести, что будет быстрее - UTF8 или 16.

IMHO, UCS2 была бы быстрее, но если нужно обрабатывать кодепойнты, то разницы не будет.
А как замена ASCII, UTF8 идеальна.

Siemargl, это было логично делать в unix-ах, где было уже полно работающего софта. У нас этого софта 1,5 программы. Смысла мало.

Да, я как раз об этом. В основном изменения будут касаться файловых функций. Вот у нас там так

  * +8: dword: encoding:
    * 0 = cp866 -> byte per char
    * 1 = UTF-16LE -> word per char

word per char намекает, что работать можно как с UCS2.

Всё придумано до нас Достаточно погуглить. Обычно говорят, что UTF-8 и EBCDIC более подходит для передачи по сети из-за endianness. Но для обработки внутри программы советуют UCS2/UTF-16/UTF-32.

Вот ещё есть https://en.wikipedia.org/wiki/Comparison_of_Unicode_encodings

*facepalm* Опять флудера включаешь?Вот хочу я, к примеру, чтоб пути к файлам были в UTF-16, из сети получать что-то в UTF-8, а статические текстовые строки в ср866.

Ты узко мыслишь просто. Иди дальше играй в игрушки

Ты таки хочешь перемешать всё в кучу? Хотя это и плохая идея, но и этому ничего не мешает. Да, системный вызов добавится в этом случае. И я тебе приводил пример как это делается в одном месте

function GetCurrentDirectory; external kernel32 name 'GetCurrentDirectoryW';

А потом просто везде используют эту юникодную GetCurrentDirectory.
А ты, вероятно, собираешься делать как-то так

call GetCurrentDirectoryA
..........................
call GetCurrentDirectoryW
..........................
call GetCurrentDirectoryA
..........................
call GetCurrentDirectoryW
..........................
call GetCurrentDirectoryA
..........................
call GetCurrentDirectoryW

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

Ну если всё равно будут новые функции, то можно и параметром передавать. А если он 0, то тогда имя в структуре. Хотя, может, привычнее всё в структуре размещать. Ещё идея: вместо ebx использовать ecx или edx, чтобы не делать лишний раз push\pop в обёртках.

Так, вам осталось сделать свой вклад - выбрать номера двух новых функций для UTF-8 и UTF-16 (например 80 или 32).

Как насчет 80 и 90?

_________________
Звиздеть не мешки ворочать

Ну предлагайте конкретней, какую куда?

P.S. Решения от фонаря мне даются труднее всего.

Pathoswithin, ты про клоны SysFn70? А как же остальное? Или там подфункции будут?
Ну пусть SysFn80 будет. Можно же указывать encoding в регистре. Например, для UTF16 edx = 1, а для UTF8 edx = 2.