Page 1 of 16

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

Posted: Sat Nov 12, 2016 1:21 pm
by 0CodErr
Может это теперь уже и норма. Но вот абракадабра выводится:
Spoiler:
1.PNG
1.PNG (38.38 KiB)
Viewed 9698 times
Вывести Path в Board:
Spoiler:

Code: Select all

ORG 0
BITS 32
; ------------------------------ ;
PATH_SIZE      equ 1024
PARAMS_SIZE    equ 256
STACK_SIZE     equ 256
; ------------------------------ ;
MENUET01       db 'MENUET01'
version        dd 1
program.start  dd START
program.end    dd END
program.memory dd END + PATH_SIZE + PARAMS_SIZE + STACK_SIZE
program.stack  dd END + PATH_SIZE + PARAMS_SIZE + STACK_SIZE
program.params dd END + PATH_SIZE
program.path   dd END
; ------------------------------ ;
START:
        mov    eax, 63
        mov    ebx, 1
        xor    ecx, ecx
        mov    esi, [32]
.next:
        mov    cl, [esi]
        jecxz  .done
        int    64
        inc    esi
        jmp    .next
.done:
        mov    cl, 13
        int    64
        mov    cl, 10
        int    64

        mov    eax, -1
        int    64
; ------------------------------ ;        
END:
GetPathB.kex (78 Bytes)
Downloaded 305 times
Вывести Path в Console:
Spoiler:

Code: Select all

ORG 0
BITS 32
; ------------------------------- ;
PATH_SIZE      equ 1024
PARAMS_SIZE    equ 256
STACK_SIZE     equ 256
; ------------------------------- ;
MENUET01       db 'MENUET01'
version        dd 1
program.start  dd START
program.end    dd END
program.memory dd END + PATH_SIZE + PARAMS_SIZE + STACK_SIZE
program.stack  dd END + PATH_SIZE + PARAMS_SIZE + STACK_SIZE
program.params dd END + PATH_SIZE
program.path   dd END
; ------------------------------ ;
con_init       dd 0
printf         dd 0
con_exit       dd 0
console        dd 0
; ------------------------------ ;
sz_test        db "Test",0
sz_con_init    db "con_init",0
sz_con_printf  db "con_printf",0
sz_con_exit    db "con_exit",0
sz_console     db "/sys/lib/console.obj",0
; ------------------------------ ;
START:
        push   sz_console
        call   LoadLibrary
        mov    ecx, eax
        mov    ebx, GetProcAddress
        push   ecx
        push   sz_con_init
        call   ebx
        mov    [con_init], eax
        push   ecx
        push   sz_con_printf
        call   ebx
        mov    [printf], eax
        push   ecx
        push   sz_con_exit
        call   ebx
        mov    [con_exit], eax

        push   sz_test
        push   -1
        push   -1
        push   -1
        push   -1
        call   [con_init]

        push   dword [32]
        call   [printf]
        add     esp, 4

        push   0
        call   [con_exit]

        mov    eax, -1
        int    64
; ------------------------------------- ;
LoadLibrary:
        mov    eax, 68
        mov    ebx, 19
        mov    ecx, [esp + 4]
        int    64
        ret    4
; ------------------------------------- ;
GetProcAddress:
        mov    edx, [esp + 8]
        xor    eax, eax
        test   edx, edx
        jz     .end
.next:
        xor    eax, eax
        cmp    [edx], dword 0
        jz     .end
        mov    esi, [edx]
        mov    edi, [esp + 4]
.next_:
        lodsb
        scasb
        jne    .fail
        or     al, al
        jnz    .next_
        jmp    .ok
.fail:
        add    edx, 8
        jmp    .next
.ok:
        mov    eax, [edx + 4]
.end:
        ret    8
; ------------------------------------- ;
END:
GetPathC.kex (275 Bytes)
Downloaded 311 times

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

Posted: Sat Nov 12, 2016 1:50 pm
by Serge
Newlib пока не умеет с локалями работать. Все преобразования в пределах базового набора ASCII.

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

Posted: Tue Nov 15, 2016 3:01 pm
by 0CodErr
Похоже, это может вызвать некоторые проблемы, например,
viewtopic.php?f=45&t=3237&start=45#p67156
viewtopic.php?f=5&t=1602&p=67163#p67114
Также, у нас приложения на путь резервируют 1024 байта(как раз на 1024 символа).
С UTF-8 уже 1024 байта может быть недостаточно для 1024 символов.

Вот что я предлагаю:
Ядро ведь всё равно не даст приложению больше, чем 2 Гб.
Можно использовать старший бит указателя на путь в заголовке, чтобы сообщить ядру, что приложение хочет принять путь в Unicode.
Только лучше не UTF-8, а UTF-16. Насколько знаю, Newlib умеет работать с wchar. И посчитать размер буфера проще, это 1024 * 2 = 2048 байтов.
Это не проблема, чтобы добавить в линкер-скрипт

Code: Select all

LONG(___pgmname | 0x80000000);     /*  full path    */
Siemargl wrote:Мне кажется, что воткнуть в начало пути байт кодировки было не самым удачным решением в принципе.
И это проблема, конечно. Раньше пути начинались со слэша. Вот представим, что есть путь "/sys/Path/MyFile.ext". Если приложение захочет проверить (Path == "/sys/Path/MyFile.ext"), то вместо простого StrCmp(Path, "/sys/Path/MyFile.ext") придётся немного мудрить ещё.

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

Posted: Tue Nov 15, 2016 3:37 pm
by Pathoswithin
Сейчас максимальная длина пути 4096 байт в UTF-8.
Проблема в том, что приложение не знает откуда оно будет запущено. Я выбрал такой подход из-за того, что к концу строки можно добавить имена в ASCII и не беспокоится об остальном пути. То есть, все существующие приложения могут быть запущены откуда угодно, а проблем с совместимостью вроде почти не возникло.

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

Posted: Tue Nov 15, 2016 4:51 pm
by Serge
0CodErr wrote:Похоже, это может вызвать некоторые проблемы, например,
вместо простого StrCmp(Path, "/sys/Path/MyFile.ext") придётся немного мудрить ещё.
О чём я и предупреждал.

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

Posted: Thu Nov 17, 2016 7:11 pm
by CleverMouse
Никаких UTF-16. Оно имело смысл лет этак двадцать назад, когда 65536 символов ещё хватало всем, но сейчас у неё нет никаких преимуществ перед UTF-8.

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

Posted: Thu Nov 17, 2016 9:26 pm
by Siemargl
0CodErr wrote:....
Также, у нас приложения на путь резервируют 1024 байта(как раз на 1024 символа).
С UTF-8 уже 1024 байта может быть недостаточно для 1024 символов.
....
Странно, я вроде бы встречал 4096 символов в программах в буфере на полное имя файла.

Так, поразбираемся
SysFn70.1 не поддерживает UTF-8, нужно расширять варианты кодировок в ядре.
Буфер для имени для SysFn70.1 не более чем 512 байт
OpenDialog, Filebrowser - не поддерживают многобайтные кодировки

NTFS - м.б.проблема - каждое имя каталога до 256 символов (UTF16), полный путь в сборе 32к
https://msdn.microsoft.com/en-us/library/aa365247.aspx, хотя рекомендуется до Win10 ограничиваться 256 символами на весь путь (260 с именем диска).
FAT32 - 255 в виде символов UCS2
XFS, EXTx - 255 байт
Joliet - 64 символа UCS2
UDF - 255 байт

Итого будут проблемы с длиной имени:
-при массовом применении UTF-8, если массово используются 3-4х-байтовые буквы
-возможно, с NTFS когда символы не помещаются в UCS2 (а может на такие можно честно ругаться и не поддерживать?)
-UDF (DVD диски)
-в ядре с поддержкой кодовых точек UTF16

Вот ответ системы как описать - простите, ваше имя длиной в 250 букв, но оно не влезает?
Т.е не существует константы MAX_PATH
CleverMouse wrote:Никаких UTF-16. Оно имело смысл лет этак двадцать назад, когда 65536 символов ещё хватало всем, но сейчас у неё нет никаких преимуществ перед UTF-8.
Это UCS2 ограничена 16 бит на символ.

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

Posted: Fri Nov 18, 2016 3:48 pm
by 0CodErr
Siemargl wrote:Странно, я вроде бы встречал 4096 символов в программах в буфере на полное имя файла.
Здесь вот пишут, что 1024:
viewtopic.php?f=24&t=1456&p=29598#p29598
viewtopic.php?f=7&t=1936#p37925
viewtopic.php?f=1&t=2297&p=48469#p48469

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

Posted: Fri Nov 18, 2016 5:38 pm
by Pathoswithin
Не знаю, кто когда чего писал, а сейчас в ядре есть константа maxPathLength = 1000h.

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

Posted: Fri Nov 18, 2016 6:49 pm
by 0CodErr
Раньше та информация была актуальной, а maxPathLength появилась сравнительно недавно в #6468. Вот только написанные ранее приложения о ней не знают.

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

Posted: Fri Nov 18, 2016 10:12 pm
by Pathoswithin
Она появилась ещё в #1304, а до того значения тоже были 1000h.

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

Posted: Fri Nov 18, 2016 10:39 pm
by 0CodErr
В #1304

Code: Select all

max_cur_dir equ 0x1000
используется в SysFn30.
А потом ты убрал max_cur_dir и стал использовать maxPathLength.
Но max_cur_dir это длина пути текущей директории, а не размер буфера, в который ядро пишет путь приложения.
Вообще-то, почти 7 лет прошло с появления max_cur_dir.
Думаешь, там
viewtopic.php?f=24&t=1456&p=29598#p29598
viewtopic.php?f=7&t=1936#p37925
viewtopic.php?f=1&t=2297&p=48469#p48469
не знали про неё?. :)

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

Posted: Sat Nov 19, 2016 12:37 am
by Siemargl
Вопрос не в том, знали - не знали.
Вопрос -куда мы хотим стремиться?

Я не против utf8, при условии нормальной ее поддержки системой.
Тем не менее, в ядре пока по дефолту 866

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

Posted: Sat Nov 19, 2016 12:47 am
by Serge
Первоначально размер буфера был 36 (тридцать шесть) байт - #5.
В #91 diamond написал новый загрузчик приложений и увеличил буфер до 1024 байт.
Его размер не менялся до #6502, пока Pathoswithin не ввёл utf-8. При этом изменение размера нигде не объявлено, а проверки на размер в ядре нет. Теперь ядро может записать туда до 4К и затереть память приложения. На совместимость традиционно забили.
max_cur_dir был установлен в 4К потому, что память для него выделялась KernelAlloc(), а у неё страничная гранулярность.

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

Posted: Sat Nov 19, 2016 3:28 am
by Pathoswithin
А разве размер изначально где-то был объявлен? В коде было где как: и 1024, и 4096, и даже 260. Теперь везде одна константа. Где приложения работали, там по прежнему работают.