Board.KolibriOS.org

> В argv[0] перед путём к экзешнику ставится символ сердечко.
Это символ кодировки. Pathoswithin добавил.

Остальное проверю.

О как. Странное решение.
Так, довёл до ума. Убрал это сердечко(а я думал, что это я временный костыль добавил ). Точнее, если там середечко, то оно уберётся, если там что-то другое стоять будет, то не уберётся.
Исправил я вывод warning'ов. Теперь консоль информативна, но не замусорена) На а свои отладочные выводы пока оставил. Хотя, видимо, скоро уберу.
Из проблем пока: почему-то вылетает при обработке файла keyboard.h. Я испытывал на том textreader, что ты выкладывал.

Кстати, это сердечко означает кодировку UTF-8.

Хм. То есть в русских каталогах ничего не скомпилиться... А как-то попросить старый ASCII можно? Или преобразовать? Или только вручную? И вообще, где что написано про нововведение?

GerdtR
Боюсь нигде и никак. Автор регулярно кладёт на обратную совместимость.

А где вообще что-то написано про этот параметр? Авторы до меня клали на планирование дальнейшего развития. И никакой альтернативы мне так и не предложили. Из всех вариантов самый совместимый.

Pathoswithin
Самый совместимый в Win с двумя наборами функций *A и *W. А не так, когда ядерное API меняют на лету.

Так проблемы же не с API, а с argv[0].

Pathoswithin
Это не проблема argv[0]. Это проблема всех программ. О чем 0CodErr уже написал.

И это проблема, конечно. Раньше пути начинались со слэша. Вот представим, что есть путь "/sys/Path/MyFile.ext". Если приложение захочет проверить (Path == "/sys/Path/MyFile.ext"), то вместо простого StrCmp(Path, "/sys/Path/MyFile.ext") придётся немного мудрить ещё.

Главное, если путь из ASCII превратился в UTF8, зачем там этот байт ? Или он внезапно может стать UTF16, UTF-32, DBCS,что-то ещё ?

Serge wrote:Главное, если путь из ASCII превратился в UTF8, зачем там этот байт ? Или он внезапно может стать UTF16, UTF-32, DBCS,что-то ещё ?

Чтобы этот путь не меняя можно было передать в 70-ю функцию. Она понимает первые байты как маркеры кодировок. С другой стороны, так ли уж нужна поддержка CP866 и UTF-16 в файловых функциях? Может оставить только UTF-8 без всякого маркера?

akron1
По нормальному, я этот байт должен скипнуть из argv[0].

Хм... теоретически можно перевести весь c-- на utf8. Только тогда исходники тоже должны быть в utf8, но текстовые редакторы у нас с utf8 не работают(или уже что-то есть?).

Для оберон-07 вопрос решен с помощью BOM-сигнатуры в начале файла исходника. Да, редакторы (пока) не поддерживают UTF-8, но компилятору какая разница? Наличие BOM-сигнатуры указывает компилятору на использование кодировки UTF-8. Реально это влияет на подсчет символов в строках для выдачи сообщений об ошибках компиляции и длину строковых констант. Например, такой код правильный, если используется ANSI. Если UTF-8, то константы "ф", "ы", "п" будут уже два байта и программа не скомпилируется.

GerdtR wrote:Хм... теоретически можно перевести весь c-- на utf8. Только тогда исходники тоже должны быть в utf8, но текстовые редакторы у нас с utf8 не работают(или уже что-то есть?).

Не нужно. Максимум что нужно - добавить строковые литералы, например как это сделано в С11. Но с-- такой компилятор, что разобраться в исходниках - огромный труд.
Проще уж библиотечку конверсий UTF8<->UTF16<->CP866, etc

Я предлагаю считать, что для PE-приложений абсолютно всё в UTF-8 без всяких маркеров - вход/выход системных функций 2,4,70,что-у-нас-там-ещё-принимает-строки, argv[0], все библиотеки. Иначе откуда, скажем, box_lib может узнать, хочет приложение строку в cp866 или в utf-8? Делать флаги для всех-всех-всех библиотек - означает дикие метастазы legacy по всей системе.