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



ну да, все ясно. но 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 и у приложения" спор и начался))))
все, дискуссию считаю завершенной! спасибо! интересно было мнениями обменятся )