Board.KolibriOS.org

Official KolibriOS board
It is currently Sat Mar 28, 2020 3:45 pm

Unanswered topics | Active topics


» » »

All times are UTC+03:00



Post new topic  Reply to topic  Page 10 of 16
  [ 236 posts ]  Go to page Previous 1 … 8 9 10 11 12 … 16 Next
  Print view Previous topic | Next topic 
Author Message
Serge
PostPosted: Sun Nov 27, 2016 10:19 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Quote:
И всё таки я не понял, зачем переводить на unicode путь который вписан в структуру?
Допустим есть приложение у которого путь вписан в структуру. И его надо переделать на unicode. Значит надо выделять буфер и прописывать в структуру указатель. Там, где раньше использовалось смещение относительно структуры надо загружать адрес буфера и т.д. Правка кода усложняется, особенно если это ассемблер. С новой функцией, сохраняющей текущий формат вызова ф.70 внести изменения будет проще.
Quote:
Вот тут что-то решили
Это были пожарные меры. Ты о префиксе на форуме даже не сообщил, только в чате обмолвился.
Quote:
Разница только в том, что потом можно носом ткнуть и сказать что предупреждал

Сидит мужик на дереве, рубит сук, на котором сидит. Проходит мимо другой: «Что ты делаешь, упадёшь же!» — «Проходи, не мешай работать». Ещё удар — сук ломается, мужик падает. Вскочил и грозит вслед уходящему кулаком: «У, колдун проклятый!»
Top
   
Reply with quote  
Leency
PostPosted: Sun Nov 27, 2016 10:26 pm 
Offline
Designer
User avatar

Joined: Thu Jan 25, 2007 3:33 pm
Posts: 5101
Serge
"Новая функция сохраняющая текущий формат вызова ф.70" это подфункция 70?

В Windows 7, 10 какая кодировка? UTF8?
Имена в NTFS в UTF8?

Если ввести новые функции, как это затронет файловые менеджеры?
Какие изменения (какие проверки для каких случаев) нужно будет внести?

_________________
Через тернии к звездам
Top
   
Reply with quote  
Serge
PostPosted: Sun Nov 27, 2016 10:40 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Leency
Да. Что мешает создать 70.10 70.11 и т.д ? Там 32 бита для подфункции.
В Windows UTF-16
Quote:
Если ввести новые функции, как это затронет файловые менеджеры?
Существующие сейчас никак.
Quote:
Какие изменения (какие проверки для каких случаев) нужно будет внести?
Появление новых функций не должно затрагивать существующий код. Дальше - уже забота прикладных программистов, как они будут использовать новые возможности. Давно есть возможность читать содержимое каталогов в UTF-16, не знаю пользуются ли ей кто-нибудь.

Для всех лучше когда изменения и нововведения полностью совместимы с уже написанным кодом.
По моему мнению лучший вариант - новые подфункции для ф.70 и ф.30 принимающие строки в utf8
Остаётся проблема с путём приложения. Сейчас приложение получает его в кодировке ср866. Эту проблему можно решить новым заголовком. Заодно и снять ограничение на длину пути, если это актуально.
Top
   
Reply with quote  
Siemargl
PostPosted: Sun Nov 27, 2016 11:10 pm 
Offline

Joined: Tue Mar 08, 2016 11:00 pm
Posts: 436
Serge wrote:
Остаётся проблема с путём приложения. Сейчас приложение получает его в кодировке ср866. Эту проблему можно решить новым заголовком. Заодно и снять ограничение на длину пути, если это актуально.

Пусть все получают путь в UTF8 и радуются, как и предлагала Мышь.
Сломается мало, а все что сломается должно и может переехать в англоязычные каталоги.

Ограничение на длину пути не считаю актуальным, более актуален размер буфера для параметров программы - он должен быть большим (см, например, сколько передается ar при сборке newlib - целый экран параметров, а он может быть и юникодным)

Но приведение в порядок/унификация функций 70+30 при апгрейде до юникода - вот это актуально.
Top
   
Reply with quote  
Serge
PostPosted: Sun Nov 27, 2016 11:39 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Siemargl
Старое ограничение на длину командной строки снято. Теперь 64Кб, включая ноль. Главное, чтобы приложение читало адрес из заголовка.
Quote:
Сломается мало, а все что сломается должно и может переехать в англоязычные каталоги.
Или сидит на старом ядре.
Не знаю. Может и так. У меня тоже нет большого желания городить новый заголовок и делать ещё один внутриядерный режим работы.
Top
   
Reply with quote  
Siemargl
PostPosted: Mon Nov 28, 2016 12:53 am 
Offline

Joined: Tue Mar 08, 2016 11:00 pm
Posts: 436
Serge wrote:
Siemargl
Старое ограничение на длину командной строки снято. Теперь 64Кб, включая ноль. Главное, чтобы приложение читало адрес из заголовка.
Quote:
Сломается мало, а все что сломается должно и может переехать в англоязычные каталоги.
Или сидит на старом ядре.
Не знаю. Может и так. У меня тоже нет большого желания городить новый заголовок и делать ещё один внутриядерный режим работы.

По моему, овчинка выделки не стоит. Слишком мелочь, чтобы существенно менять ядро.

Leency wrote:
0CodErr
В данный момент PathOsWithin делает много полезного, реально пишет код - то, чего многие другие не делают и хотя бы за это его нужно уважать.

Mario в свое время вывел правило: мнение программиста пишущего код важнее меня людей которые этого не делают. В более простом варианте в народе это правило звучит так: пиздеть не мешки ворочать. Перед телевизором мы все политики, в бане мы все философы, а как до дела дойдет...

Именно PathOsWithin взялся решать задачу юникода, не ты. Он потратил на это много времени, своего времени. И он принял определенные решения в процессе решения задачи и возможно не всегда оптимальные. Ты как человек который не взялся решать эту задачу можешь дать отзыв о его работе, предложить варианты и скажем провести голосование, но никак не оскорблять.
Плюс еще никто, включая достаточно опытных людей, не смог предвидеть полный масштаб последствий. Так что не вижу оснований для претензий.
Top
   
Reply with quote  
Pathoswithin
PostPosted: Mon Nov 28, 2016 3:32 am 
Offline
Mentor/Kernel Developer
User avatar

Joined: Thu Mar 26, 2015 5:16 pm
Posts: 1266
Ограничится подфункциями 70-ой не просто: параметр идёт глубоко, аж до файловых систем, а редактировать структуру нельзя. Проще сделать ещё две идентичные функции, а 70-ую оставить только ср866.

Путь запуска приложения сейчас в utf-8 с маркером, и да, есть ещё и пофигистичный вариант - просто убрать маркер. Тогда существующие приложения смогут работать только с путём в ASCII, зато больше ничего делать не придётся.

Serge wrote:
Допустим есть приложение у которого путь вписан в структуру. И его надо переделать на unicode.
... ?
Переделать на unicode это значит сменить кодировку всего текстового файла? То есть нельзя оставить отдельные строки в ср866? Впрочем, на ассемблере переместить статическую строку как раз просто.
Top
   
Reply with quote  
Serge
PostPosted: Mon Nov 28, 2016 3:46 am 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Quote:
Путь запуска приложения сейчас в utf-8 с маркером, и да, есть ещё и пофигистичный вариант - просто убрать маркер. Тогда существующие приложения смогут работать только с путём в ASCII, зато больше ничего делать не придётся.
Маркер само собой надо убирать. Так что да, будут проблемы если в path будут символы не попадающие в базовый набор. Неприятно, но не фатально.
Quote:
Переделать на unicode это значит сменить кодировку всего текстового файла? То есть нельзя оставить отдельные строки в ср866? Впрочем, на ассемблере переместить статическую строку как раз просто
Почему весь ? Только код работы с файловой системой.
Top
   
Reply with quote  
Leency
PostPosted: Mon Nov 28, 2016 12:47 pm 
Offline
Designer
User avatar

Joined: Thu Jan 25, 2007 3:33 pm
Posts: 5101
Leency wrote:
Serge
В Windows 7, 10 какая кодировка? UTF8?
Имена в NTFS в UTF8?

Если ввести новые функции, как это затронет файловые менеджеры?
Какие изменения (какие проверки для каких случаев) нужно будет внести?

Прошу ответить людей знающих, ибо я как прикладной программист не совсем понимат.

_________________
Через тернии к звездам
Top
   
Reply with quote  
Pathoswithin
PostPosted: Mon Nov 28, 2016 8:39 pm 
Offline
Mentor/Kernel Developer
User avatar

Joined: Thu Mar 26, 2015 5:16 pm
Posts: 1266
Весь юникод в windows это UTF-16, в linux - UTF-8.

Сами по себе нововведения никак не затронут, совместимость жеш. Если будешь делать поддержку юникода, что тебе будет удобней: байт кодировки перед указателем на строку в структуре 70 функции (сейчас там всегда 0) или отдельные идентичные функции для юникода?

Serge
Тогда я не понимаю, зачем переводить в unicode конкретно тот путь, который вписан в структуру? Он же статический.
Top
   
Reply with quote  
Serge
PostPosted: Mon Nov 28, 2016 9:24 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Quote:
Тогда я не понимаю, зачем переводить в unicode конкретно тот путь, который вписан в структуру? Он же статический.
Не обязательно статический. Может записываться перед вызовом.
Top
   
Reply with quote  
0CodErr
PostPosted: Wed Nov 30, 2016 2:36 am 
Offline

Joined: Sun Oct 30, 2011 6:43 pm
Posts: 1499
Ну вот и наконец-то началось конструктивное обсуждение :)

Вот, смотрите, какой вариант ещё есть:
    Посредством новой SysFn говорим ядру "моё приложение хочет работать с юникодом".
    И после этого все функции работают в режиме юникода.
    Надо будет только добавить в APPDATA новое поле encoding.
    Тогда функции вместо проверки префикса будут просто проверять APPDATA.encoding.
    Можно в зависимости от значения APPDATA.encoding добавить возможность работы с разными кодировками, например ASCII|UTF8|UTF16|UTF32.

    Есть нюанс с DrawText. Там есть флаг кодировки. Но и сейчас там проблема. Кодировки префикса и флага могут отличаться.

    Насчёт AppPath вариант такой:
    В заголовке программы вместо
    Code:
    version        dd 1
    можно сделать
    Code:
    version        dw 1
    encoding       db ?
    reserved       db ?
    Это будет обратно совместимо, если принять, что для ASCII значение encoding = 0.
    Так что, больше не надо никаких префиксов :)

Предлагаю добавить 2 SysFn: SetEncoding и GetEncoding. Пусть SetEncoding возвращает старую кодировку. То есть можно было бы писать
Code:
LastEncoding = SetEncoding(ENC_UTF16);
/* do somthing */
SetEncoding(LastEncoding);
Не знаю, нужно ли поддерживать сразу и BigEndian и LittleEndian? Просто пока предлагаю такие константы
Code:
ASCII = 0
UTF16 = 1 ; SysFn70 уже использует 1 = UTF-16LE
UTF8  = 2
UTF32 = 3
Преимущества этого подхода:
    не нужно новых заголовков
    не нужно дублирования функций
    не нужно префиксов
    возможность установки encoding с помощью одной SysFn сразу для всех функций
Top
   
Reply with quote  
Serge
PostPosted: Wed Nov 30, 2016 7:15 am 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Только не APPDATA, а PROC - данные всего процесса. Но мне эта идея не очень нравится. Появляется два режима работы и куча мест, где надо проверять флаги и делать ветвление.
Top
   
Reply with quote  
0CodErr
PostPosted: Wed Nov 30, 2016 3:50 pm 
Offline

Joined: Sun Oct 30, 2011 6:43 pm
Posts: 1499
Serge wrote:
Только не APPDATA, а PROC - данные всего процесса.
Ну можно и сразу для всего делать. Мне трудно сказать, как будет лучше.
Serge wrote:
Появляется два режима работы и куча мест, где надо проверять флаги и делать ветвление.
А ты про ядро или ЯВУ?
Просто можно продублировать обёртки для сисфункций
Code:
LastEncoding = SetEncoding(ENC_UTF16);
/* А здесь то же самое, что было раньше для ASCII или просто вызов уже существующей ASCII-обёртки */
SetEncoding(LastEncoding);
Top
   
Reply with quote  
Pathoswithin
PostPosted: Wed Nov 30, 2016 5:26 pm 
Offline
Mentor/Kernel Developer
User avatar

Joined: Thu Mar 26, 2015 5:16 pm
Posts: 1266
Не понял, что в этом хорошего? А если приложение хочет использовать ср866 для статических строк и UTF-16 для всего остального?
Top
   
Reply with quote  
Display posts from previous:  Sort by  
Post new topic  Reply to topic  Page 10 of 16
  [ 236 posts ]  Go to page Previous 1 … 8 9 10 11 12 … 16 Next

» » »

All times are UTC+03:00

Who is online

Users browsing this forum: No registered users and 2 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