Вопрос по пути ;)

Applications development, KoOS API questions
  • Похоже что никак. Когда запускается новое приложение программе передается имя файла, а путь отсекается :(
  • Как-то можно.Марат реализовал эту возможность(это было несколько дистрибутивов назад).
    А вот как ей пользоваться - я непонял.
  • Serge wrote:программе передается имя файла, а путь отсекается
    Кто это тебе сказал такую глупость? Есть баг, что при запуске программ 19-й функцией (и другими, которые требуют только имя файла для запуска) передаётся только имя файла. В случае же запуска программы 58-й функцией программе передаётся полный путь.

    Для того, чтобы получить путь к самому себе, нужно в заголовке в поле I_ICON (следующее за I_PARAM) поместить адрес буфера достаточной длины. Какова "достаточная длина" не знает никто, так что предлагаю принять её равной, допустим, 4096. Многовато, но уж точно не мало. При запуске программы ядро запишет в буфер по этому адресу путь к программе именно в том виде, который тебе нужен, т.е. полный путь + имя файла.
    in code we trust
  • Да, типа сахар в холодильнике в банке с этикеткой "сметана" ;) Никогда бы не догадался, что поле I_ICON отвечает за путь к выполняемому файлу процесса ;) А нафига тогда I_PARAM нужен?
  • I_ICON задумывался для хранения адреса иконки приложения. Идея в жизнь так и не воплотилась, но название осталось. Называй I_APPPARAM, например, если тебе так больше нравится.
    I_PARAM содержит адрес буфера для параметров, переданных приложению при запуске.
  • rabid rabbit
    Все как описывает mike.dld, но размер буфера может изменяться от 12*2+2 (например, db '/hd0/1/',0 - возвращается в растянутом виде, где каждое звено между косюшками занимает 11 байт, вместе со всеми пробелами) до очень большого значения.
    Надо будет в документацию добавить информацию по этому поводу, чтобы люди не путались.
    И еще возврат пути реализован только для заголовка MENUET01
    Вот, пожалуй, и все.
  • а почему-бы не помещать путь к программе в качестве первого параметра?
  • rabid rabbit
    Потому что так уже сложилось "исторически" и уже есть одно серьезное приложение, которое использует данный параметр, это Тинипад который написал mike.dld
    И к тому же перестановка слагаемых суммы не меняет, нет видимых причин просто так менять код, никаких неудобств я в таком положении вещей не вижу, но готов выслушать твои выводы, если таковые имеются.
  • ну, например MHTPACK (так вроде, который исполняемые файлы упаковывает) принципиально не хочет паковать прогу, у которой I_ICON != 0. Хотя, может он и от проги с I_PARAM !=0 откажется, я не проверял.
  • mtappack не пакует программы, использующие путь, поскольку для поддержки этого при распаковке нужен дополнительный код. Программы, использующие параметры, он упаковывает. Все остальные упаковщики, по-моему, просто игнорируют это поле, что приводит к неправильной работе...
    Между прочим, что делать в 70-й функции для (будущей) соответствующей подфункции запуска? Там-то нет ограничений 8.3...
  • Надо хранит путь и рабочий каталог в памяти ядра. Увеличить размер структур по 0x80000 и записывать их туда.
  • Но память ядра приложению недоступна!?
  • rabid rabbit
    Это проблема приложений, а не проблема ядра. Она вполне решаема переписыванием упаковщиков, а вот сложившиеся вещи в ядре трогать лишний раз не стоит, без крайней необходимости.

    diamond
    А все также - возвращаешь путь, а в первом байте указываешь ASCII или UNICODE данные.

    Serge
    Зачем занимать память ядра? Ядру ведь нет дела до того, откуда загружено приложение. Приложение само должно знать и хранить свой путь, так как он требуется именно для приложения.
    К тому же опять писать лишние и практически бессмысленные функции. Но это ИМХО.
  • Зачем занимать память ядра? Ядру ведь нет дела до того, откуда загружено приложение. Приложение само должно знать и хранить свой путь, так как он требуется именно для приложения.
    К тому же опять писать лишние и практически бессмысленные функции. Но это ИМХО.
    Правильно. Давайте хранить все программы и данные в корневом каталоге загрузочного диска :) Похоже, что путь "../data/my_save.dat" вызовет у файловой системы полуобморочное состояние. Рано или поздно все равно придется делать GetCurrentDir/SetCurrentDir или жить с рамдиском без папок, "как завещал великий Вилле" :)
    Сам он с этого пути уже свалил.
  • Who is online

    Users browsing this forum: No registered users and 2 guests