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

← →
lipskiy (2002-03-25 01:02) [0]

Цель такая - запущена программа, есть подключение к интернету. Программа видит связь, лезет на какой-то определенный ресурс и забирает оттуда файл с инструкциями (кодом). Забрав его к себе, программа открывает файл и выполняет инструкции.

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

Вопрос такой - в каком виде могут находиться инструкции в таком файле? Какими средствами его можно сделать и как выполнить в программе?

← →
Лёша (2002-03-25 03:32) [1]

Я тоже сейчас над этим работаю.

Можно подрихтовать TOLEConteiner и загружать туда ActiveX файлы из инета или ещё откуда. GUID может браться из реестра или из того же инета.

Недостаток этого подхода не только в том, что с Kyrlix подобного не сделаешь(хотелось бы, конечно, чтоб и там работало). А в том, что нет обмена между программой и загруженной библиотекой. Т.е. загружаешь dll, он запускает, скажем, команды из секции initialization (если на Делфи пишешь) и как бы больше и не работает. Для дальнейшего его использования приходится строить конструкции с DDE или WMCOPYDATA.

Возникает естественное желание: чтобы эти библиотеки вклинивались в программу во время ее выполнения. И работали с ней как единое целое (так же как ActiveX в HTML документе Експлорера, только вместе с программой). Т.е. вставлять/выставлять куски программного кода когда надо.

У меня сейчас такая же постановка задачи, только главная программа не должна останавливаться (перезагружатся). И о библиотеках я должен знать только имя и местоположение.

Механизм я придумал проще, чем с ActiveX (да под Линукс должен работать), но "некрасивый". Поэтому тоже жду каких-нибудь замечаний и советов.

← →
Mbo (2002-03-25 06:27) [2]

PasScript и т.п. не устроят?

← →
iZEN (2002-03-25 07:12) [3]

Почему же нельзя использовать DLL? Пока это единственный стандартный способ динамической подгрузки кода в Win32-программу во время её исполнения.

← →
drpass (2002-03-25 10:13) [4]

Используй DLL, разработай станартный интерфейс для плагина, по которому твоя прога может запросить у нее, что и с какими параметрами ей вызывать, и не извращайся :) LoadLibrary/GetProcAddress/FreeLibrary - чего может не хватать для счастья?

← →
VuDZ (2002-03-25 10:15) [5]

или CodeEnjection...

← →
vuk (2002-03-25 10:45) [6]

to VuDZ:
>или CodeEnjection...
А это-то зачем? :o)
"Нормальные герои всегда наоборот!" (c) Бармалей

Самый разумный вариант предложен drpass. Достаточно построить систему подключаемых модулей с хорошо продуманной структурой, которая сможет позволить подключаемому модулю управлять вызывающей програмой, и Вы сможете легко решить свою проблему. В качестве примера такой расширяемой системы может выступать сама IDE Delphi.

← →
VuDZ (2002-03-25 11:54) [7]

ну ситуации то разные бывают... и всё зависит от размера dll...

← →
lipskiy (2002-03-25 18:27) [8]

> Достаточно построить систему подключаемых модулей с хорошо
> продуманной структурой

!!!!!!!!!!

В том то и смысл, чтобы иметь возможность исполнять код без какой-либо заранее продуманной структуры!
Сейчас я даже представления не имею, что может выполнять такой код, в какой области основной программы и с какими ее данными работать. Какой там плагин! Плагин предполагает четкое место для встраивания в программу с четко оговоренным интерфейсом подсоединения. Я же не знаю ни того ни другого, вообще ничего не знаю заранее. Но тем не менее мне нужно иметь доступ к любым данным моей основной программы. Могу я из dll получить доступ хотя бы к глобальным переменным программы? Но только не передавая их в dll, как параметры, а просто из dll обратиться к ним в основную программу?

← →
lipskiy (2002-03-25 18:41) [9]

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

← →
vuk (2002-03-25 19:04) [10]

to lipsky:
>Плагин предполагает четкое место для встраивания в программу с
>четко оговоренным интерфейсом подсоединения.

Ну так плагины могут быть разные. Можно пойти примерно так, как сделано в самой Delphi - приложение не определяет, что и когда делают плагины. Вместо этого оно предоставляет среду выполнения для плагинов. В этом случае единственное, что нужно делать приложению - загрузить такой плагин и предоставить ему среду выполнения, все остальное он делает сам.

← →
lipskiy (2002-03-25 22:07) [11]

2 vuk
Вот это как раз то, что нужно.
Я об этом не знал.
Как это делается?

← →
vuk (2002-03-25 22:39) [12]

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

IEnvironment - это интерфейс, при помощи которого плагин обращается к среде выполнения, предоставляемой ему программой. Этот интерфейс реализуется где-то внутри программы. Я его не расписываю, т.к. не знаю, что у Вас там есть. Интерфейс может быть достаточно сложным, в том числе он может предоставлять доступ к другим интерфейсам внутри программы. Важно то, что IEnvironment является "дверью", через которую плягин может "войти внутрь".

IEnvironment = interface
["здесь GUID"]
//исключительно для примеру
function GetDatabaseServerName : string;
end;

IPlugin - интерфейс плагина, например такой:

IPlugin = interface
["здесь GUID"]
procedure Initialize( Env : IEnvironment );
procedure Execute;
end;

Тогда в DLL можно описать всего одну функцию:
function CreatePlugin : IPlugin;

Когда нужно приложение просто загружает библиотеку, находит нужную функцию, получает интерфейсную ссылку и передает плагину ссылку на IEnvironment. После этого плагин имеет возможность работать с тем, что ему предоставлено этим интерфейсом.

← →
Лёша (2002-03-25 23:22) [13]

2 lipskiy © (25.03.02 22:07)
Как сам определишь, так и будет делаться. Главное, что в твоей программе должна быть предусмотренна передача управления внешним плагинам (модулям, скриптам, хреновинам и.т.д.). Не знаю, как это делается в Делфи (как описал vuk © (25.03.02 22:39) или по другому), да тебе оно может и не подойдет.
Vuk дело говорит, именно так я над этим и работаю.
У тебя задача немного другая, чем у меня. Хотя мне кажется, что моя твою перекрывает. Поэтому уж не обессудь, я тоже тут поспрашаю.

2 Mbo © (25.03.02 06:27)

> PasScript и т.п. не устроят?

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

2 iZEN (25.03.02 07:12) & drpass © (25.03.02 10:13)
Ну так об этои и идёт речь. Больше не о чем.
Поэтому и хотелось бы услышать мнения и советы о реализации в рамках dll.
Сейчас вписываю СОМ-механизмы, но чем дальше иду, тем больше замечаю, что следую парадигме ActiveX.

← →
vuk (2002-03-26 00:37) [14]

to Лёша:
>Не знаю, как это делается в Делфи (как описал vuk или по
>другому),
В IDE Delphi подобным образом функционирует OpenToolsAPI при взаимодействии с мастерами(wizard), находящимися в dll. Конечно, не совсем так, но очень похоже и общая идея та же самая - приложение предоставляет набор сервисов, которыми пользуются подключаемые модули.

>Сейчас вписываю СОМ-механизмы
На мой взгляд COM здесь использовать вовсе не обязательно, хотя и вполне возможно.

>Поэтому и хотелось бы услышать мнения и советы о реализации в
>рамках dll.
Что конкретно интересует?

← →
Лёша (2002-03-26 03:37) [15]

2 vuk © (26.03.02 00:37)

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

Трехзвенка. На клиенте программа, к которой плагины и подключаются. Пользователь не знает, что такое SQL. Даже, если бы и знал, у него всеравно не получилось бы рабатать с базой в некоторых случаях. Поэтому ему предоставляется (и всё время пополняется) библиотека плагинов. В плагинах существует код отображения/редактирования данных. В основном это двоичные данные, но может быть и выборка. На брокере тоже подключаемые библиотеки, которые служат для связи с плагинами клиента. Получается конструкция:

Pluin<--> Client<--> PluginOfServer<--> Server<--> DataBase

В результате дейсвий инсталятора или админа в работающую систему добавляются Pluin и PluginOfServer. Клиент может перезагрузиться, сервер - никогда.

Приблизительно, в дух словах, всё. Понятно, что плагины не могут соединяться с БД. Соединения происходят из клиента. Работа плагинов отображается, скажем, как в MDI приложении (т.е. несколько сразу).

Вот и хотелось бы узнать: есть какие-нибудь наработки, описания или идеи чего подобного. Можно просто любые соображения.

Заранее спасибо.

← →
lipskiy (2002-03-26 12:11) [16]

> Поэтому уж не обессудь, я тоже тут поспрашаю.
Да пожалуйста, никаких проблем!
Тем более, что я сам над этим вопросом не работаю сейчас, а спросил только из интересу :) Для общего развития, тсзть.

← →
vuk (2002-03-26 12:54) [17]

to Лёша:
Не знаю, как у Вас это организовано, но, как мне кажется, это тот самый случай, когда вполне возможно использование DCOM. То есть сервер распадается на на множество маленьких, в какой-то мере самостоятельных, COM объектов. При этом плагины на клиентской стороне создают соответствующие объекты на сервере и работают с ними независимо.

← →
Юрий Зотов (2002-03-26 14:34) [18]

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

В Delphi - можно, особенности компилятора это позволяют. См. журнал "Программист", N3 за прошлый год, статья Криса Касперски. Там на C, я делал то же самое в Delphi, но по ряду соображений привести код не могу (да это и не требуется).

← →
Андрей Сенченко (2002-03-26 15:08) [19]

Хмы. А что - ShellExecute не подходит ?

Задача стоит четко - во время работы стянуть откуда-то какой-то кусок кода и выполнить. Вопроса как это "что-то" будет попадать туда "куда-то" не стоит.
Почему же тогда не принять столь тривиальное решение ? Зачем огород городить ?

← →
Юрий Зотов (2002-03-26 15:39) [20]

ShellExecute - это выполнение кода в другом процессе. Имеется же в виду выполнить внешний код в своем процессе - так, как будто он внутренний.

← →
Лёша (2002-03-27 01:14) [21]

2 vuk © (26.03.02 12:54)
Ну это уже больше относится ко внутренней реализации программы. О которой я спрашивать не смею, иначе проще было бы спросить: "А не написать ли бы вам всем всё за меня?" :)
Тем более, что у меня внутри всё намного сложнее.

Вот распределённая система: представляет из себя как бы компьютер. И мне надо в этой системе сделать PCI-слоты, и описать для разработчиков, архитектуру устройств, которые будут подключаться.

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

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

2 Андрей Сенченко © (26.03.02 15:08)

> Хмы. А что - ShellExecute не подходит ?

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

← →
vuk (2002-03-27 02:46) [22]

to Лёша:
Может Вам есть смысл "рыть" в сторону COM+? Там по сравнению с просто COM есть много различных сервисов. Может и для Вашей задачи что полезное найдется..

← →
Лёша (2002-03-27 06:49) [23]

2 vuk © (27.03.02 02:46)
Может быть и подойдёт (в общей задаче). Только моя программа заточена на событийность InterBase ( post_event). К томуже, имеется установка постоянно смотреть в сторону Lynux.
А Win9x?

Хотя, если мыслить глобально, это одно из реальных решений здесь предложенных. Только, конечно огромное спасибо, но, имхо, оно не попадает в рамки обсуждаемого. :(
СОМ+ можно использовать как дополнительную работу плагинов, тех что на сервере. А использовать СОМ+ для подключения... Ну надо ещё подумать, хотя не вижу перспектив.

Ещё раз спасибо.

← →
vuk (2002-03-27 10:37) [24]

to Лёша:
>Только моя программа заточена на событийность
Ну так в COM+ имеется система поддержки очередей сообщений для коммуникации между приложениями...

>К томуже, имеется установка постоянно смотреть в сторону Lynux.
В качестве клиента или в качестве сервера? Может тогда CORBA какие-то проблемы сможет решить?

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