Имеются: программа и 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.

а что о них говорить? кусок зарезервированного/занятого АП, доступный на чтение и на запись.



ну да, все ясно. но DLL попрежнему ничем не владеет) все созданные функциями DLL объекты/классы распологаются в АП процесса и являют для него просто кусками памяти с данными, разве не так?


ну и на здоровье. я в курсе, что один процесс может обращаться к ВАП другого процесса. но повторюсь, нет у DLL своего АП!!! а значит не к чему получать доступ.

так, теперь с другим оппонентом)



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


никто(я в частности) нигде(в этой ветке) про это не говорил. все верно. что объявили, то и экспортруем. остальное - просто кусок данных.


"объекты классов"...так объекты или классы? в делфи объекты(object) оставлены для обратной совместимости и не рекомендованы к использованию. сорь, придираюсь к тексту... так, о чем мы?
полностью согласен с тем, что обмен ЭКЗЕПЛЯРАМИ классов между DLL и приложенияем не есть хорошо. но в делфи в частности можно, используя например FastShareMem, передавать и стринги и классы(ссылки) между кодом в DLL и приложением.

про последний абзац... приведенные примеры неверны, имхо.
потому, что окно - это объект ядра системы, память, где он распологается, мы напрямую трогать не должны."хе-хе" ;) это участь драйверов, шлюзов, кода самого ядра. а хэндл, что мы имеем в результате работы CreateWindowEx и набор функций для изменения его состояния из системной dll (которая, кстати, тоже в АП процесса висит), это только рычажки, дергая которые мы изменяем объект ядра.


ой, ну что ты, Рихтер, по сравнению с "современным" программистом, как мы с вами, просто неандерталец какой-то!   
да все ООП по сути обертка над процедурным программированием, сделанная для удобства/изза лени программистов.
и вообще на более низком уровне ООП нет никакого ООП, интерфейсов (СОМ), и проч. высокоуровневого бреда,
есть только набор функций ядра. которые в свою очередь являются набором команд ЦПУ.

и ВООБЩЕ, из-за чего весь сыр-бор?!
для меня очевидно, что код и данные динамически загружаемых библиотек в процессе находится в его ВАП. все. точка.
пока ничего внятного ("радиопремник у Васи" не в счет), опровергающее это утверждение, я не услышал.
ни ссылок на известные труды по архитектуре Windows, ни ссылок на MSDN. несерьезно как-то товарищи.

  с уважением.

з.ы. простите, если что, за то, что перешел на "ты") "Вы"кать надоело.

вот код:

библиотека:


проект:


и вот давайте, объясните. каким образом здесь чего по вашему работает?!
ведь про Proc2 ну ничего сама программа не знает. ну не иначе в одном АП код DLL и код приложения находятся?
или продолжим дебаты про применик у соседа?

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


А то говорит , что эти данные не располагаются на стеке, имхо

 или владеет всем...

здесь с терминалогией разобратся имхо надо

к чему ты его привел?

причем тут стек? стек потока тоже в ВАП находится.


к тому, что он показывает, что код загруженной DLL находится в том же ВАП, где и код программы.

  Вот пожалуйста, а еще говоришь, что хорошо объяснил учебник Рихтера! Еще один наступил на те же грабли. Между тем, что иногда работает и всегда работает есть большая разница. FastShareMem - заставляет использовать обе программные единицы один общий менеджер кучи, только и всего. Не ужели не ясно, что объект класса TButton в программе и объект класса TButton в Dll это объекты совершенно разных классов. Передавать ссылку на объект можно только внутри программы или внутри Dll, но никак не между программой и Dll. Если передать ссылку в программу, то программа будет думать, что перед ней экземпляр ее класса TButton, тогда как на самом деле это экземпляр класса TButton dll. В результате будет тоже самое, что привести TButton к TLabel - т.е. к неопределенным последствиям. 
  Когда я говорил о передаче класса, я имелл виду именно передачу класса, а не что иное. Если бы Dll могла передать класс TButton программе и программа на основе него создала свой экземпляр объекта, то все было бы нормально. Но это невозможно, потому программа приводит объект к чужому классу. Последствия такого приведения будут приводить к невероятным ошибкам.





Вот пожалуйста и опровержение. Объекты создает Dll, но они совершенно не принадлежат процессу. 



  Не все так просто. Современные объекты уже сильно развитые сущности. Развитые механизмы управления уже не позволяют обращаться с ними как со структурами имеющими ссылки на функции. Так что приведенный пример это тоже уже дела минувших дней. Простейшие объекты такие как строки или  динамические массивы требуют всего лишь общего менеджера памяти, но такие сложные объекты как форма не позволят производить такие вещи. Впервые я столкнулся с этой проблемой при передаче компонента TImage. Он является уже развитым представителем. Банальная операция чтения пиксела приводит к уничтожению его содержимого, а все потому, что он не может идентифицировать свой контейнер изображения и делает вывод, что он просто не создан и создает его заново уничтожая старый. Он то ожидает там объект класса TBitmap описанного в программе, а находит объект класса TBitmap описанного в Dll. Я же говорил уже что это различные классы. Информация о классах во время исполнения один из механизмов, который перестает работать при передаче объектов. Результат неправильной работы чреват неопределенными последствиями.  
  Это как минимум, а если представить, что Dll и программа компилировались разными версиями компилятора, что очень часто и бывает, то такая передача окончится катастрофой при первом же обращении к методам или данным. А если говорить о разных языках программирования, то устройство классов там вообще различное. Объект должен создаваться только в Dll и управляться по средством экспортирумых функций. Причем передача указателя на объект в программу вообще недопустима. Объект созданный в Dll должен быть в ней же и уничтожен. Программа получает только идентификатор объекта позволяющий отличить его от другого объекта созданного той же Dll. Для окон это будет глобальный идентификатор, но что-то у меня сомнения, что он создается именно в системной памяти. Интерфейс является таким же идентификатором, но создан для реализации механизмов ООП т.е. для доступа к объекту которым фактически владеет Dll, хотя формально он и принадлежит программе, так как находится в ее адресном пространстве, которая сама по себе не умеет с ним работать. 


  Винда сама по себе до сих была процедурно-ориентированной. Но на сегодняшний день они полностью отказались от этой концепции и все новые технологии строятся по принципам ООП. Вместо со старыми принципами вида пошла по пути отказа от механизмов Dll, как устаревших и не способных реализовать современные объектные концепции. Dll будут оставаться как механизм совместимости старого софта. 
  Не нужно думать, что все что он написал это чисто его выводы и сведения. Часть это банальная адаптация текста MSDN, который никогда не отличался доступностью изложения. Меньше нужно молиться на "богов". Я продолжаю настаивать на том, что объяснение Рихтера не самое удачное, потому что благодаря нему каждый второй программист ступает на те же вилы. Dll - это чужой модуль и как бы винда его не породняла с программой, он все равно останется для нее чужим. А к чужакам нужно  
 относиться всегда с опаской и использовать только те механизмы, которые документированы.

Вот и про это я и пытался в аське объяснить. Рихтер хорошо, не не значит, что абсолютно правильно. 

Все же я был прав, Metal?

P.S.: специально для тебя перевод MSDN откопал:



Вот здесь.

Незнаю, насколько достоверно, но...

Во, еще нашел =). У Рихтера заметь! Читаем, Глава 17:



Теперь тоже говоришь, что у DLL нет адресного пространства???

Это сообщение отредактировал(а) aktuba - 8.1.2007, 08:10

aktuba, В данном случае речь как раз о регионе виртуального адресного пространства exe. Это и есть тот диапазон адресов куда будет отображаться образ Dll.

Alexeis, про RTTI я тоже в курсе. тут она "своя" для процесса и DLL, созданной в delphi. но этот механизм тоже наверняка можно "довести до ума", т.е. объединить две RTTI. что тоже не есть хорошо, ибо после выгрузки библиотеки придется их как-то "расклеивать".
но это, повторюсь, высокоуровневые механизмы, надстройка ООП над обычным ПОП. реализация ООП в разных языках, да что там языках, разных версиях Delphi - различается. и еслиб Borland и сделала механизм, позволяющий использовать одну RTTI для процесса и "родных" ДЛЛ, то легче от этого бы не стало, глюков бы не убавилось.

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

  С основами ассемблера я знаком и знаю, что на уровне процессор поддерживается только процедурное программирование. Я не сомневаюсь, что при большом желании такие ситуации можно разрулить, но ЗАЧЕМ???!!! Такое можно оправдать только учебными целями. Delphi не стоит на месте и то что удалось разрулить ручками в одной версии вероятно не удастся в другой. Если такие задачи вправду так остро стоят, то стоит задуматься о переходе на .net там все модули (сборки) изначально объектные и таких проблем просто не возникает. 
  Это не глюки, а результат использования недокументированных возможностей. Никто этим заниматься не будет. Для win32 борланд написала механизм BPL. В его основе лежит то, что класс определен в отдельном модуле, а все прочие программные модули используют единственное и уникальное описание класса. Это точно будет работать, потому тут механизм передачи объекта документирован, а при возникновении настоящего глюка всегда можно обратиться в поддержку Borland.
  И уж для коллекции еще раз приведу 3й механизм. Интерфейсов созданный для совместимости с технологией COM и использования объектов созданных вне приложения, хоть и расположенных в ее адресном пространстве. Для меня все равно этот механизм понятней как отношения клиента и сервера, нежели отношение владения объектом, в то время как ничего кроме как передачи указателя программа самостоятельно делать не может. Кроме того скажем при использовании COM объекта по средством чужого приложения не позволяет получить даже сам указатель на реальный объект. Я считаю, что все перечисленное хорошо объединяется в группу отношения взаимодействия чужого модуля с программой.

  Dll же как чисто процедурный механизм может считаться дружественным (т.е. модуль свой и все в нем свое). Но времена процедурного программирования уже прошли и Delphi определяет уже чисто объектную модель создания программы. В этой объектной модели отношение программа <-> Dll уже не могут строится по схеме дружественности, за исключением взаимодействия программа <-> ОС, где реализуется подход совместимости с процедурным программированием, который лежит в основе API и который на настоящий момент уже, очевидно, устарел.


Да личного АП нет, в первом посте под своим АП я подразумевал, то АП куда она первоначально загружается. Физически библиотека там, потому оно как бы ее, но на самом деле это некая системная область управляемая ОС. Кто кроме нее в этой области фиг его знает . Может это, вообще, просто физическое адресное пространство.

  *THUMBS UP*
из-за утверждения о "Отдельном АП у DLL и у приложения" спор и начался))))
все, дискуссию считаю завершенной! спасибо! интересно было мнениями обменятся )