Board.KolibriOS.org

Official KolibriOS board
It is currently Mon Jun 01, 2020 8:21 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 236 posts ]  Go to page Previous 19 10 11 12 1316 Next
Author Message
PostPosted: Wed Nov 30, 2016 5:35 pm 
Offline

Joined: Sun Oct 30, 2011 6:43 pm
Posts: 1499
Pathoswithin wrote:
кодировка argv[0] всё равно фиксирована.
Она не должна быть фиксирована. А если надо UTF-16 передать или UTF-32? Фиксированная кодировка это не гибко, тогда придётся таскать с собой конвертер и делать дополнительную конвертацию. За всем этим может следить ядро и конвертировать лишь при необходимости, если не будут совпадать кодировки передающего и принимающего параметры.
Pathoswithin wrote:
А если приложение хочет использовать ср866 для статических строк и UTF-16 для всего остального?
А этому ничего и не мешает. Тут ещё непонятно, что значит "для всего остального"? Ну и можно обёртки с суффиксами *A и *W сделать. Но, например, у меня не возникает необходимости часто переключаться между кодировками. Работает себе приложение в UTF16 и работает. То есть, в идеале достаточно будет просто значения encoding в заголовке. Хотя, например, в таблице экспорта библиотек ASCII.


Top
   
PostPosted: Wed Nov 30, 2016 5:56 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
0CodErr wrote:
А ты про ядро или ЯВУ?
Про ядро.
Quote:
А если надо UTF-16 передать или UTF-32? Фиксированная кодировка это не гибко
Не надо utf16/32. Должна быть одна кодировка Пусть будет utf8.
Quote:
За всем этим может следить ядро и конвертировать лишь при необходимости, если не будут совпадать кодировки передающего и принимающего параметры.
Не надо нагружать ядро лишней работой.


Top
   
PostPosted: Wed Nov 30, 2016 5:58 pm 
Offline
Mentor/Kernel Developer
User avatar

Joined: Thu Mar 26, 2015 5:16 pm
Posts: 1271
0CodErr
То есть в таком случае ты предлагаешь 100500 раз переключать кодировки?
Использовать параметр версии это тоже самое, что и новый заголовок.
Spoiler: Show
Где у меня написано "кодировка argv[0] всё равно фиксирована"? :wink:


Top
   
PostPosted: Wed Nov 30, 2016 6:52 pm 
Offline

Joined: Sun Oct 30, 2011 6:43 pm
Posts: 1499
Pathoswithin wrote:
Где у меня написано "кодировка argv[0] всё равно фиксирована"? :wink
А ты уже отредактировал сообщение, хитрец :P

Pathoswithin wrote:
Использовать параметр версии это тоже самое, что и новый заголовок.
Не параметр. Я не предлагаю менять версию. Просто, как оказалось, в заголовке есть поля, которые можно считать зарезервированными. Потому что для номера версии вполне хватило бы word или даже byte.
Quote:
В заголовке программы вместо
Code:
version        dd 1
можно сделать
Code:
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 более менее серьёзных приложения, эта совместимость просто не нужна. Не с чем совмещаться.


Top
   
PostPosted: Wed Nov 30, 2016 7:38 pm 
Offline
Mentor/Kernel Developer
User avatar

Joined: Thu Mar 26, 2015 5:16 pm
Posts: 1271
Сейчас драйвера файловых систем работают на UTF-8 и всё в неё перекодируется, так что это "родная" кодировка. И совместимость с ASCII пригодилась.
Всё что в пределах первых 8 байт заголовка принципиально одно и то же. Версия сейчас вообще не используется (кстати, можно использовать под путь для иконки).


Top
   
PostPosted: Wed Nov 30, 2016 7:51 pm 
Offline

Joined: Sun Oct 30, 2011 6:43 pm
Posts: 1499
Pathoswithin wrote:
Версия сейчас вообще не используется (кстати, можно использовать под путь для иконки).
Пока не надо с этим торопиться. Это потенциально целых 32 флага.
Pathoswithin wrote:
Сейчас драйвера файловых систем работают на UTF-8 и всё в неё перекодируется, так что это "родная" кодировка. И совместимость с ASCII пригодилась.
Мой вариант позволяет выбрать ту кодировку, которая необходима, тогда, когда это необходимо. То есть, максимально гибко. Зачем искусственно ограничиваться? Мне не понятно.
Если путь будет передаваться в UTF8, то нельзя будет присоединить к нему кириллическое "Папка1" в ASCII. Нужен, значит, конвертер. Только непонятно, зачем не русскоязычному пользователю использовать русифицированный вариант программы. В общем, UTF8 только усложняет всё. Должен быть выбор кодировки. Пусть лучше ядро конвертирует, чем приложению придётся таскать конвертер с собой.


Top
   
PostPosted: Wed Nov 30, 2016 8:04 pm 
Offline

Joined: Sun Oct 30, 2011 6:43 pm
Posts: 1499
Запустил вот GetPathC.kex в одной из старых сборок #2306
Spoiler: Show
Attachment:
1.PNG
1.PNG [ 13.83 KiB | Viewed 1397 times ]
Можете сравнить с тем, что выводится сейчас в первом сообщении этой темы viewtopic.php?f=2&t=3429#p67134


Top
   
PostPosted: Thu Dec 01, 2016 12:28 am 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
0CodErr
Потому, что ср866 базовая кодировка ядра и console.obj. Попробуй напечатать символ, который в cp866 не входит. Если сменить кодировку app_path на utf-8 приложение не сможет его правильно вывести на экран, но сможет распарсить на компоненты.
0CodErr wrote:
Мой вариант позволяет выбрать ту кодировку, которая необходима, тогда, когда это необходимо. То есть, максимально гибко. Зачем искусственно ограничиваться? Мне не понятно.
Ты просто предлагаешь раздуть ядро, свалив на него функциональность, которой не хочется заниматься самому. Актуальность UTF32 в прикладных программах 0.(0)% В ядре должна быть одна кодировка. Устанавливать ascii/unicode режим работы ядра в зависимости от флагов в заголовке imho неудачная идея.


Top
   
PostPosted: Fri Dec 02, 2016 9:33 am 
Offline

Joined: Sun Oct 30, 2011 6:43 pm
Posts: 1499
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, разумеется, необходимо.


Top
   
PostPosted: Sat Dec 03, 2016 2:11 am 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Quote:
Лучше APPDATA. Представь, что поток работает с UTF16, и тут БАЦ! и кодировка внезапно сменилась.
1. С чего это она так внезапно изменится ? Её только автор приложения может изменить.
2.Чтобы не было таких внезапных БАЦ, не надо заводить в ядре режимов.
Quote:
Пусть лучше ядро конвертирует, чем приложению придётся таскать конвертер с собой.
Ядро не безразмерно.


Top
   
PostPosted: Sat Dec 03, 2016 2:18 pm 
Offline

Joined: Sun Oct 30, 2011 6:43 pm
Posts: 1499
Serge wrote:
1. С чего это она так внезапно изменится ? Её только автор приложения может изменить.
:lol: Ну с таким же успехом и от мьютексов можно отказаться тогда. У нас приложения могут быть многопоточными.
Serge wrote:
Ядро не безразмерно.
А никто не спорит же.
0CodErr wrote:
Какая по большому счёту разница, где будет этот код? Разница в том, что ядро и так уже работает и с ASCII, и с UTF8, и с UTF16. По-твоему лучше ещё раз продублировать этот код в приложении вместо того, чтобы просто использовать готовый ядерный код? Можно многое вынести из ядра в драйвера и библиотеки. Но раз уж оно сейчас находится в ядре, то и вполне логично, что эту работу будет выполнять ядро.
Ну можно вынести часть ядерного кода в библиотеку. Но всё равно ведь и ядро и приложения будут его использовать. Только придётся ещё в обязательном порядке грузить эту библиотеку.


Top
   
PostPosted: Sat Dec 03, 2016 2:44 pm 
Offline
Mentor/Kernel Developer
User avatar

Joined: Thu Mar 26, 2015 5:16 pm
Posts: 1271
Вот маркеры кодировки строк в других ОС не используются, а установка кодировки для всего потока? Потому что это уже противоположная крайность получается.


Top
   
PostPosted: Sat Dec 03, 2016 3:03 pm 
Offline

Joined: Sun Oct 30, 2011 6:43 pm
Posts: 1499
Pathoswithin, те кто привык к винде, могут написать себе обёрток с суффиксами A\W по принципу
Code:
LastEncoding = SetEncoding(ENC_UTF16);
/* А здесь то же самое, что было раньше для ASCII или просто вызов уже существующей ASCII-обёртки */
SetEncoding(LastEncoding);
Просто вариант установки кодировки для всего потока более гибкий. Вместо вызова ...A или ...W в зависимости от ситуации, вызывается всегда одна и та же функция.

А так обычно определяется как-то так
Code:
function GetCurrentDirectory; external kernel32 name 'GetCurrentDirectoryA';
function GetCurrentDirectoryA; external kernel32 name 'GetCurrentDirectoryA';
function GetCurrentDirectoryW; external kernel32 name 'GetCurrentDirectoryW';


В общем, можно продублировать сисфункции, а можно добавить одну, устанавливающую кодировку сразу для всех сисфункций.


Top
   
PostPosted: Sat Dec 03, 2016 5:38 pm 
Offline
Mentor/Kernel Developer
User avatar

Joined: Thu Mar 26, 2015 5:16 pm
Posts: 1271
По два раза на вызов переключать кодировку? Может более дубовый? Наоборот с классическим подходом можно один раз определить
function GetCurrentDirectory; external kernel32 name 'GetCurrentDirectoryW';
и получится то что ты хочешь.


Top
   
PostPosted: Sat Dec 03, 2016 7:48 pm 
Offline

Joined: Sun Oct 30, 2011 6:43 pm
Posts: 1499
Вот опять ты суть не улавливаешь.

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


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 236 posts ]  Go to page Previous 19 10 11 12 1316 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited