| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
EXE, DLL и ShareMem [D7, Win95/98, WinME, NT4, Win2k, WinXP]
Mielofon © (2005-01-24 09:01:00)Добрый день.
Проблема у нас в следующем:
Есть EXE который собран без ShareMem. И есть DLL (плугин например) которую надо бы подключить к этому EXE и который имеет ShareMem.
Так вот если в EXE нет ShareMem-а, то в конструкции
h := LoadLibrary('d:\DLLka.DLL');
FreeLibrary(h);
падаем на FreeLibrary :-(
Что делать?
Неиспользовать ShareMem мы не можем. Хотя согласны, что можно использовать альтернативу ему (commm.pas, ShareMemRep.pas), но ничего хорошего не нашли.
Все таки:
1. Можно ли заставит работать связку EXE-БезShareMem + DLL-ShareMem?
Digitman (2005-01-24 11:32:00) [21]
> Падение уже просто при LoadLibrary, FreeLibrary
и это - ОДНОЗНАЧНО проблема разработчика той ДЛЛ, которую пытаются загрузить/выгрузить. Т.е. твоя проблема.
KSergey (2005-01-24 11:15:00) [22]> Падение уже просто при LoadLibrary, FreeLibrary.
А если честно - вообще есть уверенность, что dll написаны корректно? ;)
REA (2005-01-24 10:54:00) [23]Попробуй совет [7] - собрать все DLL с rtl. Заодно и места поменьше будут занимать.
Mielofon (2005-01-24 10:32:00) [24]
> Mielofon (24.01.05 10:15) [9]
> А вот EXE не совсем наш :-( И поэтому вставить в него ShareMem
> мы не можем.
>
> Тогда этоо проблемы разработчиков EXE. Требовать в качестве
> параметров объекты и при этом не использовать ШареМм
EXE ничего не требует.
Если в нем просто делается LoadLibrary и сразу за ним FreeLibrary, то это уже повод что бы упасть при FreeLibrary. :-(
Никто ничего из EXE не успевает дернуть..
Объекты в качестве параметров используются при общениии между 2-мя нашими DLL-ками (в обоих ShareMem включен).
> Есть возможность сказать, что в DLL память своя и трогать
> ее из EXE ни к коем случае не надо?
> У DDL и EXE общее адресное пространство, поэтому если EXE'шник
> захочет, он всегда сможет писать в память выделенную в DLL
Никто ничего не пишет :-(
Падение уже просто при LoadLibrary, FreeLibrary.
Хотя я как раз думал, что если я не буду трогать память выделеную в DLL, то и проблем не будет - оказалось я не прав :-(
jack128 (2005-01-24 10:25:00) [25]Mielofon (24.01.05 10:15) [9]
А вот EXE не совсем наш :-( И поэтому вставить в него ShareMem мы не можем.
Тогда этоо проблемы разработчиков EXE. Требовать в качестве параметров объекты и при этом не использовать ШареМм
Mielofon (24.01.05 10:15) [9]
Функция возвращает например указательна объект, который создан в DLL1. А мы с ним работаем в DLL2 как с родным. Т.е. дергаем его методы и т.д. В процессе работы происходит перераспределение памяти. :-(Ну и что?? Если d используешь ShareMem, то этот не страшно.
Mielofon (24.01.05 10:15) [9]
и хочешь что бы ее могли использовать другое, то не пользуйся ShareMem-ом?
ShareMem must be the
first unit in your library's USES clause AND your project's (select
Project-View Source) USES clause if your DLL exports any procedures or
functions that pass strings as parameters or function results. Тоже касается объектов, дин массивов и тд. Если ничего этого нету, то и ShareMem не нужен.
Mielofon (24.01.05 10:15) [9]
Есть возможность сказать, что в DLL память своя и трогать ее из EXE ни к коем случае не надо?
У DDL и EXE общее адресное пространство, поэтому если EXE'шник захочет, он всегда сможет писать в память выделенную в DLL
Mielofon (2005-01-24 10:15:00) [26]А вот EXE не совсем наш :-( И поэтому вставить в него ShareMem мы не можем.
Одна DLL1 (c ShareMem) дергает функции из другой DLL2 (с ShareMem)
Функция возвращает например указательна объект, который создан в DLL1. А мы с ним работаем в DLL2 как с родным. Т.е. дергаем его методы и т.д. В процессе работы происходит перераспределение памяти. :-(
Самое то главное: если пишешь DLL и хочешь что бы ее могли использовать другое, то не пользуйся ShareMem-ом?
Я честно говоря думал, что если я не буду в EXE перераспределять память которая выделена в DLL, то моему EXE-шнику пофиг что там в DLL (ShareMem, не ShareMem). А практика показала, что не так :-(
Есть возможность сказать, что в DLL память своя и трогать ее из EXE ни к коем случае не надо?
REA (2005-01-24 09:40:00) [27]Есть вариант переделать DLL в Packages. Тогда необходимость в ShareMem вообще отпадет, а функциональность останется. Хотя возможно придется вынести общий код в отдельные Packages.
Digitman (2005-01-24 09:39:00) [28]
> Это большой код и переписать его сейчас мы не в силах.
да что там переписывать-то ?
в dpr-файле хост-приложения просто добавить в uses первой позицией Sharemem - и всех делов !
> У нас 3 (основных, на самом деле больше) DLL на 10-ть Мег,
> >20 Мег кода.
> И мы писали их под ShareMem.
и незачем было так извращаться.
если все проекты собраны с ран-тайм пакетами, никаких Sharemem вовсе не требуется
а если проекты собирались , ч.н. "куда кривая вывезет" (т.е. какие-то проекты - с BwRTP, какие-то - без BwRTP), то надо было сразу делать это с полным пониманием - задействование единого менеджера памяти осуществляется двумя базовыми способами :
1. Сборка ВСЕХ проектов с BwRTP и безо всяких Sharemem - миним.размер генерируемого исп.кода, но зависимость от bpl
2. Сборка ВСЕХ проектов с Sharemem без BwRTP - избыточность генерируемого исп.кода, зависимость от модуля, реализующего менеджер памяти, но независимость от bpl
jack128 (2005-01-24 09:33:00) [29]Mielofon (24.01.05 9:23) [2]
И все у нас работает при условии использовании ShareMem.
Так и должно быть. Более того при передаче объектов очень желательно, хотя и не обязательно компилировать длл и ехе с run time пактами..
Mielofon (24.01.05 9:23) [2]
Это большой код и переписать его сейчас мы не в силах. :-(
Добавить в EXE uses ShareMem - это большой код??
KSergey (2005-01-24 09:32:00) [30]Да, я так понял, что "указатели на объекты" - это относится к взаимодействию dll
Есил же это относится и к exe - то иного пути нет вообще: либо ShareMem, либо менять архитектуру.
KSergey (2005-01-24 09:30:00) [31]Да плевать сколько там у вас кода!
Интересуют интерфейсные функции между exe и dll
> [2] Mielofon (24.01.05 09:23)
> А основная проблема в том, что мы передаем указатели на
> объекты и пользуемся ими (объектами) как своими
Если память под объекты выделяется и освобождается в одном модуле - то не вижу проблемы
Если же это происходит в разных модулях - то бить за это надо.
Впрочем, не всегда это происходит явно, возможно.
Юрий Зотов (2005-01-24 09:28:00) [32]Так пропишите ShareMem в EXE-шнике, вот и все дела. Одна строчка, и переписывать ничего не придется.
Mielofon (2005-01-24 09:23:00) [33]>Вот это не очень понятное заявление.
>А вообще, все различие использования/не использования ShareMem >относится лишь к передаче/получению переменных типа String или >других динамических объектов через интерфейсные функции.
У нас 3 (основных, на самом деле больше) DLL на 10-ть Мег, >20 Мег кода.
И мы писали их под ShareMem.
Передача переменных типа String или динамических переменных это верхушка айсберга, которую мы готовы переписать.
А основная проблема в том, что мы передаем указатели на объекты и пользуемся ими (объектами) как своими - это скрытая часть айсберга. И все у нас работает при условии использовании ShareMem.
Это большой код и переписать его сейчас мы не в силах. :-(
KSergey (2005-01-24 09:14:00) [34]> Mielofon (24.01.05 09:01)
> Неиспользовать ShareMem мы не можем.
Вот это не очень понятное заявление.
От чего же?
А вообще, все различие использования/не использования ShareMem относится лишь к передаче/получениюпеременных типа String или других динамических объектов через интерфейсные функции.
Вот на них было бы любопытно взглянуть. Тогда можно сказать что-то определенное.
| |
Страницы: 