Board.KolibriOS.org

hidnplayr wrote:

Siemargl wrote: Все поломать и переписать в UTF8 ради кого? Кому нужна эта универсальность ?

How about everybody who does not use CP866 or CP1251?

For example?
German, Italian, French, Spanish and more other have their single-byte encoding - just set this encoding as default locale in system.

Somewhere sad translator who knows Russian, German, and Greek ..., for example.

Siemargl:
There are several problems with old codepages, that is why unicode was invented in 1988.

Some problems:
-People who know different languages as GerdtR pointed out.
I can read/write dutch, french, english, which is all no problem in one codepage but I have also learned to read russian and even understand some of it. Remember Yogev Ezra? He speaks russian, hebrew and some more...
-Programs would need support for different codepages and even be able to convert from and to them.
For example, most of the internet nowadays is UTF8 (hooray!).
-We already have capability to print unicode (and so UTF8) text in kernel, so why not actually make things simpler and only use that instead of archaic codepages...

hidnplayr wrote:Siemargl:
There are several problems with old codepages, that is why unicode was invented in 1988.

Some problems:
-People who know different languages as GerdtR pointed out.
I can read/write dutch, french, english, which is all no problem in one codepage but I have also learned to read russian and even understand some of it. Remember Yogev Ezra? He speaks russian, hebrew and some more...
-Programs would need support for different codepages and even be able to convert from and to them.
For example, most of the internet nowadays is UTF8 (hooray!).
-We already have capability to print unicode (and so UTF8) text in kernel, so why not actually make things simpler and only use that instead of archaic codepages...

I understand you, but....

I think, for the run of universality of UTF8, we'll lost a lot of children in the bath.
More important things awaiting' us than rewriting all the old programs.

So, good support old CP's is better than new troubles, but
writin' new sysfn's and libraries must have mbcs updates in mind

Похоже я понял причину неработоспособности С-- в Колибри.

/../ папка хэндлится в WIN и LINUX на уровне ядра, в KOS нет.
Попробуй запустить из RUN: /sys/lib/../calc не сработает. Вот и вся загвоздка.

Потому и "../lib/io.h" и все в таком духе не работает.

Можно ли на уровне ядра сделать поддержку папки ".." ?

"../" поддерживается в начале относительного пути и значит подъём на одну папку вверх относительно текущей. Что должен значить путь "/sys/lib/../calc"?

Pathoswithin wrote:"../" поддерживается в начале относительного пути и значит подъём на одну папку вверх относительно текущей. Что должен значить путь "/sys/lib/../calc"?

/sys/calc

Возможно, надо обрабатывать множественные точки типа
/sys/lib/../../calc -> /calc

эта задача характерна для сборки сложных программ и библиотек компиляторами

Pathoswithin
Надо реализовать поддержку в середине пути, как в примерах Siemargl

.. и . обрабатывается на уровне ядра. Проблема скорее кроется или в newlib или в какой-то незамеченой ошибке. Тем более .. нормально обрабатывается в середине. Проблема только если .. в начале пути.

Хм... Действительно проблема с ядром имеется. Если читать файл ./myfile, то нормально, авот .. в середине пути не обрабатывается.

Хм.. но "." поддерживаются, если они присутствуют в папке. В "/sys" нет такой папки. А вот, например, в "/sys/3d" есть.

Spoiler:

1.PNG (19.26 KiB)

Viewed 11500 times

Короче, погляжу ядро, авось сделаю там обработку .. и .

... которую я скоро буду переделывать.

Ну или делай ты, мне только проще.