Exe как Dll

← →
s_ (2007-04-05 09:15) [0]

Каким образом сделать в исполняемом файле (exe-файле)экспортируемые функции, как в dll. Если можно с примером. Заранее спасибо.

← →
Сергей М. © (2007-04-05 09:18) [1]

Для PE-модулей безразлично, каким конкретно модулем экспортируется некий адрес, будь то хоть ЕХЕ хоть DLL. Разницы никакой.

Иными словами, экспортируй в ЕХЕ то что тебе нужно точно так же как ты экспортируешь оное в DLL.

← →
s_ (2007-04-05 09:50) [2]

У меня не получается. Вот код:
{Экспортируемое приложение} program Project1; uses Forms, Unit1 in "Unit1.pas" {Form1}; {$R *.res} function Exprt(s:String):String;Export; begin Result:=s+" Exports" end; exports Exprt; begin Application.Initialize; Application.CreateForm(TForm1, Form1); Application.Run; end. ................... {Приложение для импорта} function Exprt(s:String):String;stdcall;External "project1.exe"; implementation {$R *.dfm} procedure TForm1.Button1Click(Sender: TObject); var es:String; begin es:=Exprt("Call"); Memo1.Lines.Add(es); end;

Второе приложение не запускается.
Там какаято ошибка инициализации.

← →
Сергей М. © (2007-04-05 10:17) [3]

А я и не говорил, что задуманное тобой обязательно будет работать.
Но процедура Exprt, как видишь, экспортируется без проблем)

Предлагаю не заниматься ерундой и реализовать экпорируемую процедуру как и положено - в DLL.

← →
_Аноним (2007-04-05 10:17) [4]

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

← →
Сергей М. © (2007-04-05 10:36) [5]

> _Аноним (05.04.07 10:17) [4]

А в нулевых отсутствует таблица релокации. Все остальное совершенно не важно.

← →
s_ (2007-04-05 10:44) [6]

> _Аноним (05.04.07 10:17)
А в dll -ке работает!!!

← →
s_ (2007-04-05 10:52) [7]

> Предлагаю не заниматься ерундой и реализовать экпорируемую
> процедуру как и положено - в DLL.

Ну, если возможно экспортировать из exe -шки, то всё-таки интересно КАК импортировать эту функцию в другом приложении?

← →
vl_chel © (2007-04-05 10:59) [8]

Ели Вы используете exe файл как библиотеку то при этом (в отличии от dll) не отработают секции инициализации. Для Вашего кода в принципе это не критично.
Но параметры и правила вызова функций должны совпадать если stdcall то и в описании и в подключении:

>> function Exprt(s:String):String;Export

>>function Exprt(s:String):String;stdcall;External "project1.exe";

← →
vl_chel © (2007-04-05 11:02) [9]

Сергей М. © (05.04.07 10:17) [3]
Ответ не только правильный но и мудрый

String не обязательно AnsiString может быть и ShortString (из кода не видно)

← →
Сергей М. © (2007-04-05 11:13) [10]

> s_ (05.04.07 10:52) [7]

> КАК импортировать эту функцию в другом приложении?

Обычным образом. Точно так же как и из DLL.

Но, повторяю, в общем случае работать эта схема не будет.

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

← →
Сергей М. © (2007-04-05 11:16) [11]

> vl_chel © (05.04.07 10:59) [8]
> не отработают секции инициализации. Для
> Вашего кода в принципе это не критично.

Как раз для подобного кода это еще как критично !)

← →
s_ (2007-04-05 11:34) [12]

> vl_chel ©
Да не важно String, PChar, Integer..., мне главное определить, возможно ли импортировать в другом приложении?

Вот пожалуйста абсолютно рабочий код для dll

library Project1; uses Forms, Unit1 in "Unit1.pas" {Form1}; {$R *.res} function Exprt(s:PChar):PChar;Export; begin Result:=PChar(s+" Exports") end; exports Exprt; begin Application.Initialize; Application.CreateForm(TForm1, Form1); Application.Run; end. ................... {Приложение для импорта} function Exprt(s:PChar):PChar;External "project1.exe"; implementation {$R *.dfm} procedure TForm1.Button1Click(Sender: TObject); var es:String; begin es:=Exprt("Call"); Memo1.Lines.Add(es); end;

Но когда я делаю из первого кода exe-шку, при нажатии на кнопку в функции Exprt происходит ошибка Access violation

← →
DiamondShark © (2007-04-05 11:38) [13]

> Вот пожалуйста абсолютно рабочий код для dll

> Result:=PChar(s+" Exports")

Это абсолютно нерабочий код даже для монолитных приложений.

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

← →
Сергей М. © (2007-04-05 11:46) [14]

> s_ (05.04.07 11:34) [12]

> мне главное определить, возможно ли импортировать в другом
> приложении

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

Но импорт процедуры и собственно вызов/исполнение импортируемой процедуры - две разные разницы.

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

← →
Сергей М. © (2007-04-05 11:47) [15]

> Вот пожалуйста абсолютно рабочий код для dll

Но при этом абсолютно бестолковый и бессмысленный.

← →
vl_chel © (2007-04-05 12:37) [16]

>>DiamondShark © (05.04.07 11:38) [13]

Из опыта работы на D6 всегда из библиотеки возвращал строки как PChar
пока библиотека в памяти никогда AV не возникала. Может я везунчик :))

>>Сергей М. © (05.04.07 11:16) [11]
критичности по секции инициализации модуля не вижу, если там AnsiString то они при работе используют механизм подсчета ссылок, при нем _AdRef и _Release вызываются автоматом, этот механизм очень неплохо работает

← →
Сергей М. © (2007-04-05 13:01) [17]

> критичности по секции инициализации модуля не вижу

Какого модуля-то ?

Ни один ведь не инициализируется, если ты о юнитах, из которых построен EXE-модуль... А среди них запросто м.б. и юнит, где реализован менеджер памяти, который тоже требует инициализации... Строка же Result:=s+" Exports" гарантированно обращается к менеджеру

← →
s_ (2007-04-05 13:22) [18]

> Но, повторяю, в общем случае работать эта схема не будет
А КАК же сделать, чтобы наконец Р А Б О Т А Л АААААААААААА!

← →
Elen © (2007-04-05 13:54) [19]

> А КАК же сделать, чтобы наконец Р А Б О Т А Л АААААААААААА!

А что за срочная необходимость такого изврата?

← →
clickmaker © (2007-04-05 14:13) [20]

> [18] s_ (05.04.07 13:22)

скомпили DLL, потом поменяй расширение на exe

← →
Сергей М. © (2007-04-05 14:46) [21]

> s_ (05.04.07 13:22) [18]
> КАК же сделать, чтобы наконец Р А Б О Т А Л АААААААААААА!

А зачем ?)
Чем DLL-то не устраивает ?

← →
s_ (2007-04-05 16:00) [22]

А зачем ?)
> Чем DLL-то не устраивает ?

Я же задал в полне понятный вопрос, взможно ли исполнять импортируемую функцию из exe-шки?
Ну, если нет, то для чего сделали возможным экспортировать функции в исполняемом файле?
А зачем ?)
Например:
Я работаю с двумя приложениями, и в одном из них хочу использовать функции другого приложения.

Заранее говорю, что не хочу использовать там всякие DDE и т.п.

← →
clickmaker © (2007-04-05 16:02) [23]

> и в одном из них хочу использовать функции другого приложения

в этих случаях лучше общие функции выносить в DLL, которую могут юзать оба exe
Или писать EXE как COM-сервер

← →
Сергей М. © (2007-04-05 16:18) [24]

> s_ (05.04.07 16:00) [22]

> Я же задал в полне понятный вопрос, взможно ли исполнять
> импортируемую функцию из exe-шки?

Вполне понятно тебе и ответили - возможно.
Но не в твоем случае.

← →
s_ (2007-04-05 16:27) [25]

Вы можете мне сказать
для чего сделали возможным ЭКСПОРТИРОВАТЬ функции в исполняемом (exe) файле????? :((((

← →
Сергей М. © (2007-04-05 16:31) [26]

> s_ (05.04.07 16:27) [25]

Потому что исполняемый файл представляет собой точно такой же PE-модуль, как и DLL.

Возможность импорта-экспорта заложена в любом модуле, имеющем формат Portable Executable.

← →
s_ (2007-04-05 16:42) [27]

> Сергей М. © (05.04.07 16:18) [24]
> Но не в твоем случае

А как можно переделать программу, чтобы было в моём случае?
Или это невозможно?

← →
Сергей М. © (2007-04-05 16:44) [28]

> s_ (05.04.07 16:42) [27]

Тебе это не по силам.
Да и не нужно.
см. [23]

← →
Сергей М. © (2007-04-05 17:00) [29]

> s_

Чтобы не быть голословным по поводу "определенных" случаев, когда "это" гарантированно работает, предлагаю экспортировать/импортировать/вызвать следующую процедуру:

procedure MagicEXEImportExportTest; begin exit; end;

Пробуй.
Удивись.
Вникни, ПОЧЕМУ это работает, а что-то другое не работает.
Думай.
Задавай вопросы.
Делай выводы.
Принимай соотв.решение.

← →
Leonid Troyanovsky © (2007-04-05 20:01) [30]

> s_ (05.04.07 16:27) [25]

> для чего сделали возможным ЭКСПОРТИРОВАТЬ функции в исполняемом
> (exe) файле????? :((((

Например, чтобы загруженная им библиотека, могла получить
доступ к этим функциям через GetProcAddress.
Только не спрашивай, зачем это надо.

--
Regards, LVT.

← →
Loginov Dmitry © (2007-04-05 20:46) [31]

> Каким образом сделать в исполняемом файле (exe-файле)экспортируемые
> функции, как в dll. Если можно с примером. Заранее спасибо.

Точно также, как и при экспорте из DLL. В случае, если если библиотека загружена в адресное пространство того самого ЕХЕшника, то не нужно беспокоится о инициализации объектов и т.п. Раз ЕХЕ запущен, значит все данные инициализированы. Но совсем другое дело, если требуемые функции экспортируются каким-либо сторонним ЕХЕ. В таком случае используй СОМ.

← →
Loginov Dmitry © (2007-04-05 20:51) [32]

В любом случае экспорт функций в ЕХЕшнике - это извращение. При работе DLL и EXE в одном адресном пространстве наиболее распространенный вариант использования функций EXE из DLL - это вызов экспортируемой функции из DLL с передачей в качестве параметра адреса функции, находящейся в EXE (с точки зрения DLL такие функции являются callback-функциями)

← →
Leonid Troyanovsky © (2007-04-05 23:01) [33]

> Loginov Dmitry © (05.04.07 20:51) [32]

> качестве параметра адреса функции, находящейся в EXE (с
> точки зрения DLL такие функции являются

У длл не должно быть своей точки зрения, бо в чужой
монастырь со своим уставом не лезут.

2All: Хочется повториться: длл - это рудиментарная форма
технологии клиент-сервер в условиях дефицита ресурсов.

Не мучайте старушку, в конце-концов.

--
Regards, LVT.

← →
Германн © (2007-04-05 23:46) [34]

> Leonid Troyanovsky © (05.04.07 23:01) [33]
>
...
>
> 2All: Хочется повториться: длл - это рудиментарная форма
> технологии клиент-сервер в условиях дефицита ресурсов.
>
> Не мучайте старушку, в конце-концов.
>
> --
> Regards, LVT.
>

Точно. Долой kernel32.dll и все другие! Даёшь дополнительные сотни метров свободного пространства в System32!
:)

я помню интересовался этим вопросом года 2-3 назад. по результатам обсуждения Игорь Шевченко вынес вердикт - в дельфи этого сделать нельзя.

По-моему в Delphi можно сделать всё!!!!
Главное - иметь желание.

> SergGG © (06.04.07 10:00) [36]

Все да не всё)

Нельзя, к примеру, заставить дельфийский линкер генерировать таблицу релокаций для ехе-модулей.

> Сергей М. © (06.04.07 10:10) [37]

> Нельзя, к примеру, заставить дельфийский линкер генерировать
> таблицу релокаций для ехе-модулей

Как раз он таки всегда ее генерирует. Только в последних версиях BDS есть опция SETPEOPTFLAGS, с помощью которой можно запретить генерировать таблицу релокаций в исполняемом файле

> DrPass © (06.04.07 10:44) [38]
>
>

> Как раз он таки всегда ее генерирует.

Да что ты говоришь !?) А мужики-то и не знают))..

То-то я смотрю - по какому ImageBase ни загружай собранный в D7 exe-модуль, абсолютные адреса, сгенерированные линкером, всегда будут корректными))

> DrPass © (06.04.07 10:44) [38]

Да, действительно, я был не прав - в D7 флаг IMAGE_FILE_RELOCS_STRIPPED по умолчанию не установлен, и соответственно RT по умолчанию генерируется.

Delphi тут не при чем. Загрузчик не использует секцию relocation для не-dll.

Сергей, ты об этом тоже знаешь :)

> Игорь Шевченко © (06.04.07 12:48) [41]

> Загрузчик не использует секцию relocation для не-dll

Тоже верно.
Так что главная засада остается главной засадой - без релокации и без инициализации подавляющее большинство подобных затей терпят фиаско.

Я вот тут репу почесал) и, пожалуй, поддержу SergGG © (06.04.07 10:00) [36] - было бы желание, а уж устроить принудительную релокацию при наличии RT и принудительную инициализацию - дело техники)

← →
s_ (2007-04-06 13:42) [44]

> Сергей М. © (06.04.07 12:59) [42]
Вы же писали, что ВОЗМОЖНО [24]. А теперь вы говорите
> без релокации и без инициализации подавляющее большинство подобных затей терпят фиаско.
Как же сделать, чтобы было и с релокацией, и с инициализацией.
Или Это все -таки невозможно.
А если невозможно, то чего Вы мне тут голову морочите.
Сказали бы, что для Exe-шки НЕВОЗМОЖНО и точка.

> s_ (06.04.07 13:42) [44]

Я ж тебе говорю - тебе это не по силам)

Это ж не "батон на форму кинуть" - алгоритмы нетривиальные, требуют довольно глубоких знаний "поторохов" опер.системы и логики инициализации Делфи-приложений.

Так что, если ты завелся "нипадецки", начни с формулировки вопроса о релокации в форуме "WinAPI".

> s_ (06.04.07 13:42) [44]

> Как же сделать, чтобы было и с релокацией, и с инициализацией

Так и сделать - реализовать соответствующие алгоритмы.
Предлагаешь бросить все и специально для тебя их реализовать ?)

> Сергей М. © (06.04.07 13:19) [43]

> устроить принудительную релокацию при наличии RT и принудительную
> инициализацию - дело техники)

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

> DrPass © (06.04.07 15:25) [47]

> Такой фигней заниматься - это только в целях самобразования,
> и когда до чертиков свободного времени есть

Совершенно верно.

> s_ (05.04.07 16:00) [22]

> Я же задал в полне понятный вопрос, взможно ли исполнять
> импортируемую функцию из exe-шки?

Импортируемую из exe функцию выполнить возможно.
Даже без вторжения в релокацию и даже из чужого exe,
если импортер, например, имеет окно в первичном потоке.
Но, в этом случае, нужна еще специальным образом
изготовленная длл.

--
Regards, LVT.

Exe как Dll Найти похожие ветки