Board.KolibriOS.org

Gluk
Как это после компиляции?

Gluk

Код будет работать правильно до первого обращения к данным.

Asper: "Как это после компиляции?" - мы скомпилировали код в бинарный файл, потом загрузили в память другого процесса, начиная с адреса, не равного нулю, где и передали уму бразды правления.

Serge, то есть никаких проблем с переходами (в т.ч. дальними) и вызовами функций не будет?

Gluk
Значит всё-таки после загрузки в память, тогда понятно.

Gluk
Если ты опишешь ситуацию подробно будет проще дать ответ.
С ветвлениями проблем не будет точно. С переходами jmp и call проблем не будет если только это не переходы по абсолютному адресу или косвенные переходы/вызоы call [label] jmp [label]. Но всё это будет замечательно работать до первого обращения к глобальным данным. То есть для среднестатистического кода шансы равны нулю.

Serge, большое спасибо за ответ, именно такая информация мне нужна была. Более конкретно спросить не мог, так как задача, как я ее понимаю, именно такой общности.

Для победы над обращениями к памяти нужно добавлять к адресу данных адрес начала размещения загруженного в память кода?

org в помощь.

Asper, если я правильно понял что делает эта директива, она не подойдет ввиду того, что при компиляции неизвестен адрес, по которому будет загружен код, и размещены данные

Да это так. А зачем тебе это?

Asper, цитата отсюда:

"Потоки виджетов:
Это - отдельные потоки процесса панели, рисующие в битмап, который выводит основной процесс на себя, потокам виджетов дается доступ к графической библиотеке (pixlib?) для упрощения рисования, и возможно средства для векторного рисования. Также виджет может задавать активные области в пределах себя (кнопки), ну и другие сервисы по необходимости. Сам код виджета подгружается из файла, структура которого будет оговорена, и который можно будет создать в fasm и других компиляторах (~других языков)."

Может быть не париться и сделать их в виде библиотечных файлов, которые поддерживают определённый интерфейс, а уже управляющая программа будет отвечать, за реализацию данного интерфейса?

Gluk

В твоём случае виджеты надо делать в виде длл. Они позиционно независимы. Ядро обработает релокации и тебе не надо будет думать о базовом адресе кода.

Asper, Serge, так уже делает Sorcerer.

Я правильно понимаю, что в этом случае виджеты будут неактивны до наступления события, и не смогут работать синхронно?

А упавший виджет уронит панель?

А я смогу обеспечить один экземпляр кода виджета для нескольких экземпляров виджета, не лишая его возможности использования локальной памяти?

я пока что думаю что ответы будут Да, Да, Нет(?), что меня не вполне устраивает.

мне чем dll даже больше нравится вариант самостоятельных процессов с использованием расшареной памяти (так еще безопаснее)

не говоря уже про то, что dll это что-то сложное, и с привкусом HLL..

Gluk wrote:Я правильно понимаю, что в этом случае виджеты будут неактивны до наступления события, и не смогут работать синхронно?

Ты программист, всё в твоих руках.
Если поставишь то да.

А, если например так то нет.

Gluk wrote:А упавший виджет уронит панель?

Он уронит её и в обоих случаях.

Gluk wrote:А я смогу обеспечить один экземпляр кода виджета для нескольких экземпляров виджета, не лишая его возможности использования локальной памяти?

С памятью ты ещё намучаешься, если будешь использовать свой подход.

Asper wrote:Он уронит её и в обоих случаях.

ну демка, выложенная в соответствующей теме, при падении одного из потоков-панелей не только продолжает работать, но и восстанавливает павшую панель (можно -побаловаться- проверить убиванием панелей ч/з диспетчер). А там как раз одно приложение и несколько потоков.