>Наконец можно заменить "MENUET01" на "KOLIBRI ", тогда не будет никаких проблем с неподходящими программами.
Можно для прог Колибри писать трехбайтный заголовок KOS, а остальные байты отвести под версию в численном(а не текстовом виде), для которой предназначена программа (00630 - означает версия 00.6.3.1). Все же хотелось бы иметь универсальные бинарники, которые бы работали и в М32 и в КОС - для этого лучше не менять заголовок, а делать проверку версии в самой программе
Wildwest wrote:
Есть ли возможность проверять систему/версию (Меос, кос, эмуль) и если колибри, то использовать org std_application_base_address, а если меос или эмуль, то не использовать?
Wildwest
Новые программы не заработают в МеОС без перекомпиляции и наоборот. У них стартовый адрес будет примерно 0х80000024
а app_mem ещё больше. Ни МеОС, ни нынешняя Колибри не смогут их загрузить. Поэтому можно разрабатывать любой заголовок с возможностью автоматической загрузки ДЛЛ и вообще всё что придёт в голову.
Да и видимо в новом дистре программы будут упаковыны kpack-ом про который МеОС ничего не знает.
Вообще лучше сделать загрузку и PE и ELF, чтобы можно было пользоваться любым компилятором. Если есть способ прилинковать PE DLL к ELF программе и наоборот то замечательно. Я бы сделал mp3 декодер в виде DLL и звуковую библиотеку чтобы проще было программировать.
Кажется я понял почему у меня скомпилированные в Колибри программы приводят после запуска к полному зависанию системы.Виной всему - FASM для Колибри.
Если скомпилировать программу FASM-ом из виндовс,то программы в Колибри работают без зависания.А если скомпилировать FASM-ом из Колибри,то вне зависимости от уровня сложности программы, они могут легко привести к полному зависанию системы.Я проверял это даже на очень простеньких программах типа "Hello world!".Всё подтверждается.
На этом приколы Колибривского FASM-а не заканчиваются.Очень часто вместо сообщения об ошибке на доске отладки появляется сообщение " ошибка в строке xxx use32".А иногда на доске отладки появляются куски кода.При компиляции программ,находящихся в дальних директрориях часто появляется ошибка "out of memory".
Надо что-то с этим делать.Просто так оставлять это нельзя.
andrew_programmer
Я сейчас сильно занят но потом надо будет сравнить программы скомпилированные в KOС и WIN. Хотя я компилировал в Колибри и всё работало.
andrew_programmer
А можешь выложить или послать мне какую-нибудь "вешающую" программу? В идеале даже неправильная программа не должна вешать систему намертво.
Обнаружил интересные подробности.
Оказывается,зависание скомпилированной программы происходит только в том случае, если запустить её из Tinypad-а.А если запустить программу через файловые менеджеры,то всё нормально работает.Возможно баг в ядре связан с функциями работы с файлами.
>А можешь выложить или послать мне какую-нибудь "вешающую" программу?
Оказалось,что программы скомпилированные FASM-ом из виндовс и из Колибри - одинаковы.А вот если DLL Колибри-FASM-ом компилировать,то она не работает.Возможно по причине,описанной выше.
andrew_programmer
Скорее всего, это зависание вызвано теми же эффектами, что и замеченное в k0640pre "Меню->Графика->ANIMAGE виснет", которое исправлено в svn.321.
Если компилировать DLL и вообще любой файл не в формате binary, то заголовка не будет. Это связано с тем, что портированные функции read и write читают/пишут с начала файла, а не с текущей позиции.
Заметим тут же, что при запуске из Tinypad'а на самом деле происходит запуск FASM'а, который программу ещё раз компилирует и потом запускает. То есть проблема может быть или в ядре, или в FASM'е.