Имеются: программа и 2 dll.

Программа вызывает процедуру инициализации в 1 длл, потом во второй. При этом вторая длл должна получить переменную класса из первой длл и внести в неё изменения.

Суть проблемы:

Вторая длл получает переменную, но изменение её в этой длл, не изменяет её в первой длл.  

Как мне изменить переменную из первой длл через вторую длл, так что бы изменения коснулись обеих длл? 

 

указатель на эту переменную передай и изменяй че и где хошь!
А вообще имхо 

плохо работает с 

и надо быть очень аккуратным

Я попробую ещё раз...

У меня есть 2 DLL. В первой - созданн объект какогонибудь класса. Во второй есть процедура, которая должна на этот объект повлиять.

Вторая длл получает переменную, но изменение её в этой длл, не изменяет её в первой длл.

Как мне изменить переменную из первой длл через вторую длл, так что бы изменения коснулись обеих длл?

Потому что первая длл - скриптовый движок, а вторая - всего лишь набор дополнительных ф-ий, которые должны без труда подключатся к первой длл

ф-ии в скриптовом движке создаются через отдельные классы

Для того что бы добавить в движок новую функцию - надо создавать отдельный класс.

Я предполагал, что движок будет лежать в одной длл, а все фуии будут описанны в другой

А для того что бы Фи-я добавилась в движок, надо сделать ей create с некторыми параметрами, один из которых - Объект-список уже имеющихся фу-ий. Этот Объект-список есть в первой длл

а он нужен во второй. При этом надо чтобы при изменении во второй он изменился и в первой.

вот собственно в чем байда....

Я точно убью себя ап стену....   

Здесь что-то было по совместное использование DLL: http://www.podgoretsky.com/ftp/Docs/Delphi...ogLib/ch_02.htm

Адресное пространство Длл отображается в адресное пространство программы, но к сожалению Длл не может напрямую использовать объекты программы и программа не может использовать объекты соданные в длл. И длл не может использовать объекты созданные в другой длл. Если сильно надо, то такой механизм можно реализовать через интерфесы (например так как это сделано при использовании GDI+). Использование напрямую приведет к неопределенным последствиям.

Dronishe, приведи код , и приложения и двух dll вот и посмотрим что к чему
PS не в обиду те , но и объясняешь , что те надо ты с трудом, да и с первого раза не понимаешь , что те говорят!

нет такого понятия "Адресное пространство Длл". есть АП ПРОЦЕССА! а в него и "отражаются"/загружаются ВСЕ используемые в программе DLL. ведь что такое DLL? - это по сути просто кусок кода/данных, который физически находится на диске в другом файле... все.
а объекты/классы - это уже нагрузка ООП, и Делфи в частности.
читать много раз до полного просвещения: Глава 19. DLL основы

  Ух какой же ты вредный. Прям так и нет. Не увидел в умной книжке, значит все чего там нет неправда.
Dll это данные, которые не загружаются непосредственно в память процесса. Загружаются сначала в некое  промежуточное адресное пространство не принадлежащее процессу. А только затем оно отображается в память процесса. Что неправильного в том что я назвал его адресным пространством Dll? Ведь она находится в нем, а значит это ее адресное пространство. Если одну и ту же библиотеку загрузили 2е программы, то это адресное пространство отображается на 2 процесса. Оно действительно независимое с точки зрения ОС. Программа получает только проекцию. Таким образом при помощи того же хука получаем доступ к адресному пространству другого процесса. Если бы Dll принадлежала только адресному пространству процесса, то хрен бы другой процесс мог бы вытащить из нее данные. А так может. А может потому что Dll расположена в некоторой своей области. Если мы завершим процесс, то его адресное пространство уничтожится, в этом случае и Dll должна быть выгружена, но этого не происходит, потому что она находится в своем адресном пространстве и используется другими процессами.

Alexeis, а Вы где увидели? в другой умной книжке? сами нашли?
ну я не спорю, что ДЛЛ до отображения в АП процесса где-то в памяти уже висит, но это нас никак не касается, "достучаться" до той памяти мы не можем(стандартными средствами), и при работе с DLL после явной(динамической)/неявной(статической) загрузки ее в АП процесса нет для библиотеки понятия своего АП.
а хуки - это отдельный разговор, т.к. там загрузкой библиотеки в чужое АП рулит сама система.

Спасибо за внимание. Уже разобрался. Перенес всю работу с этой переменной в первую длл. Пришлось делать все через ";jge"  зато работает

MetalFan, тем не менее. Простота работы с dll лишь кажущаяся. То что нам доступны ее функции еще не означает, что код в dll является таким же кодом как и код в нашей программе. Совсем нет. Dll следует рассматривать скорее как сервер, а программу как клиент. Dll по своей сути это полноценная программа (не имеющая правда единой точки входа), со всеми вытекающими последствиями. Загрузка dll сходна скорее с мапингом области памяти чужого процесса. Представьте себе, что мы запустили чужую программу, остановили ее основной поток, спроецировали ее адресное пространство в нашу программу (memory maping) объявив его исполняемым и нашли точки входа всех ее функций, после чего вызываем их. 
  Вот с dll аналогично. Это совсем чужой модуль, который функционирует по своему, при этом он может обращаться ко своим внутренним переменным, объектам, объектам ядра, о которых мы понятия не имеем. Созданы ли они или нет, как созданы, как организованы внутренние связи? Все это нам не доступно. Dll для программы это некий черный ящик к доступ к которому строго регламентирован (потому и провел аналогию с сервером). Многие вольности и извороты, возможные в без проблем программе (ведь тут мы все контролируем!) недоступны там. Вообще какова бы ни была библиотека (динамически ли загруженная либо она загружается при загрузке программы автоматом, либо она относится к ядру ОС или это хук) используются общие механизмы работы с ней. Кажущаяся простота работы обманчива. Управление dll производится ОС, потому очень многое скрыто от глаз программиста, потому во избежании непонятных ошибок следует в точности соблюдать все правила работы с ней и не использовать ничего из того, что не задокументировано. 

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

почему же? обоснуйте. после отражения в память процесса таковым и является.

вот что пишет по этому поводу Рихтер. с ним то вы спорить не будете? или он в корне не прав? 
но Вы пока никак не доказали обратное.



каким таким "своим"? они все открытые объекты ядра будут относиться к процессу, куда загружена/отображена DLL, а не к самой длл. иначе как система освобоболит ресурсы при "убитии" процесса?
ну если в локальной процедуре в программе тоже обращаться к объектам ядра, это же не значит, что она имеет свое АП?

Romikgy, а если не "хе-хе"? просветите уж плиз)

Согласен , но что ты скажешь о глобальных переменных объявленных в dll ?

выше,
плюс т.к. дллки могут писатся на разных языках, то омен между dll и приложением объектов имхо затруднен
допустим я написал приложение на С++ а dll на дельфи, и в dll создаю объект класса TStringList как мне его передать в программу?
вот поэтому и пытаются делать обмен между dll и приложением только стандартными типами , как char , byte, word, dword и т.п. 

а если без хехе, то доступ даже к  АП другого процесса вполне разрешен, не то что к АП dll 

Я против такого объяснения, потому что из-за таких вот объяснений люди часто наступают на вилы. Создается иллюзия того, что dll это просто кусок кода такой же как и любой другой в программе. На самом деле windows предоставляет доступ к функциям так как если бы они были реализованы в самой программе. Но только и всего. Кто сказал, что все что имеется в dll экспортируется из нее? Совсем нет. Экспортируется  только часть функций предназначенных для экспорта. У длл есть секция инициализации, которая выполняется при ее загрузке. Там могут создаваться свои внутренние объекты и переменные которые недоступны извне. 


  Так то оно так. Формально доступ к ним хоть и можно получить, но что с ними делать? Одно дело атомарные типы, а другое объекты классов. Поскольку сами классы экспортировать нельзя, то сама программа и не может с ними работать. Программа может работать с объектами своих классов (описанных в ней). 

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

 Если ее адресное пространство полностью отображается в программу, то опять же можно считать, что всем владеет программа, но вот банальный пример, создали мы windows окно. Фактически программа получает только его дескриптор, а сам объект остается скрытым. Разве мы можем напрямую изменить состояние окна "EDIT"? Хотя формально он и создается в программе, но что толку от этого? Его структура нам неизвестна. На его состояние мы можем повлиять только посредством функций да и то если он захочет изменить состояние, а не захочет не изменит. Нам доступно только то, что хотели разрешить производители, тогда как изнутри с ним можно сделать намного больше. Потому я и утверждаю, что объектом владеет библиотека, потому что всегда мы просим ее что-то сделать, а не требуем. Если у меня радиоприемник, то я могу крутить его и вертеть по своему желанию, если радиоприемник есть у Васи, то я максимум могу попросить его настроить его на свою любимую радиостанцию, а Вася может с ним делать что угодно. В такой ситуации мы говорим, что радиоприемник  Васин, а не мой. 
  Во времена процедурного программирования, атомарных типов ситуация была похожа на то что описывается у Рихтера. А вот попробуйте скажем удалить объект GDI+. Нифига не выйдет! Максимум, что можно это освободить интерфейс. Аналогичная ситуация и с COM объектом. Мы его создали но не владеем в полной мере, хотя и имеем доступ к его памяти.

Добавлено @ 23:49 
Оговорюсь, имеем доступ, только если он реализован в dll.