Войти
ФлеймФорумПрограммирование

Одна из причин, почему я до сих пор не забросил VB6. (14 стр)

Страницы: 19 10 11 12 13 14
#195
22:48, 21 окт. 2016

Old_Maple
> Ну ладно.:-) Внимание! Вопрос для умников!
> Можно ли в VB6 создать функцию или процедуру, взять ее адрес, определить размер
> в байтах, скопировать в другую область памями и вызвать-таки ее оттуда? Ну как
> вам такая задачка? ;-)
Можно
Вот пример копирования нескольких функций в память и выгрузка из памяти основного EXE http://bbs.vbstreets.ru/viewtopic.php?f=99&t=52469
Вот пример копирования функции в память другого процесса и работа с ней http://bbs.vbstreets.ru/viewtopic.php?f=28&t=52433#p6785505

#196
21:03, 23 окт. 2016

the trick
> Можно
> Вот пример копирования нескольких функций в память и выгрузка из памяти
> основного EXE http://bbs.vbstreets.ru/viewtopic.php?f=99&t=52469
> Вот пример копирования функции в память другого процесса и работа с ней
> http://bbs.vbstreets.ru/viewtopic.php?f=28&t=52433#p6785505
Спасибо за ссылки. Интересно. Но, увы, не совсем это то, что хотелось бы мне.
Имелось ввиду другое. Определить адрес функции посредством AddressOf и определение размера в байтах данной функции.
Потом копирование данной функции в другую область памяти и вызвать ее оттуда.
Достаточно перечислить API-функции посредством которых это можно сделать. :)

#197
0:48, 24 окт. 2016

Old_Maple
> Имелось ввиду другое. Определить адрес функции посредством AddressOf и
> определение размера в байтах данной функции.
> Потом копирование данной функции в другую область памяти и вызвать ее оттуда.
> Достаточно перечислить API-функции посредством которых это можно сделать. :)
В точности то что я скинул, в двух вариантах:
1. Копирование в своем процессе и запуск на исполнение;
2. Копирование в чужой процесс и запуск там через удаленный поток.
Там же описываются все ньюансы и ограничения при работе с такими функциями. Размер функции там тоже определяется посредством AddressOf.

#198
10:08, 24 окт. 2016

the trick, спасибо. Попробую разобраться.

#199
11:53, 24 окт. 2016

the trick, к сожалению, я думал, что для определения размера любой пользовательской функции (процедуры) существует некая API-функция. Заключение тела любой пользовательской функции в "функции-кавычки" (типа BEGIN_OF... и END_OF_SHELLCODE), чтобы вычислить размер тела нужной функции - не очень практично. Быть может существует иная практика определения размера тела функции? Например, при передаче по сети от сервера клиенту конкретной функции, необходим адрес и размер именно конкретной функции, чтобы запустить ее у клиента.

#200
13:03, 24 окт. 2016

Old_Maple
> the trick, к сожалению, я думал, что для определения размера любой
> пользовательской функции (процедуры) существует некая API-функция.
Нет. Ты можешь использовать дизассемблер, но это все-равно ненадежно.
Old_Maple
> Заключение тела любой пользовательской функции в "функции-кавычки" (типа
> BEGIN_OF... и END_OF_SHELLCODE), чтобы вычислить размер тела нужной функции -
> не очень практично.
Почему?
Old_Maple
> Например, при передаче по сети от сервера клиенту конкретной функции, необходим
> адрес и размер именно конкретной функции, чтобы запустить ее у клиента.
Так проще использовать DLL с нужной функцией.

#201
13:24, 24 окт. 2016

the trick

Нет. Ты можешь использовать дизассемблер, но это все-равно ненадежно.

Понятно.
the trick
Почему?

Просто хотелось получить более лаконичный код. :)
the trick
Так проще использовать DLL с нужной функцией.

Не всегда это проще - писать на каждую функцию или процедуру свою DLL.
А передавать весь массив функций и процедур клиенту бывает нецелесообразно.
На сервере могут создаваться новые функции, которые только и нужно передать клиенту в режиме он-лайн.
Думаю, что в он-лайн играх такая вещь будет востребована. Впрочем, может быть и иной взгляд на эту реализацию.
#202
13:31, 24 окт. 2016

Old_Maple
> На сервере могут создаваться новые функции, которые только и нужно передать
> клиенту в режиме он-лайн.
  Для этого есть либо скрипты, либо управляемые языки, в которых в базовые возможности заложена сериализация и передача исполняемого кода по сети. Ни в кресты, ни в VBA такой возможности не закладывали. Но вообще передавать код клиенту не безопасно, все вычисления должны вестись на сервере.

#203
12:57, 11 ноя. 2016

Zefick
>   Для этого есть либо скрипты, либо управляемые языки, в которых в базовые
> возможности заложена сериализация и передача исполняемого кода по сети. Ни в
> кресты, ни в VBA такой возможности не закладывали. Но вообще передавать код
> клиенту не безопасно, все вычисления должны вестись на сервере.
Ну, хорошо. Допустим, не хватает ресурсов на сервере, чтобы каждому подключенному клиенту что-то там вычислять и отправлять готовые результаты. Тогда имеет смысл отправить клиенту dll-ку с конкретной функцией. Клиент у себя проведет вычисления и получит результат. Но здесь встает проблема не столько с подключением данной dll-ки и функции из нее, посредством "LoadLibrary+GetProcAddress+CallWindowProc", сколько с передачей данных для подключаемой функции. Особенно, если эти входные данные, для вызываемых функций, имеют различные форматы. (Например: Клиенту отправлены в виде строковых переменных - имя_dll, имя_функции и аргументы функции в виде блока.) Придется проводить целый синтаксический разбор присланного пакета клиенту.
Да еще потом посредством ASM'а и Get|PutMem'а переводить как-то в удобоваримый вид. Может быть есть более легкий путь? :)

#204
13:12, 11 ноя. 2016

Old_Maple
> Придется проводить целый синтаксический разбор присланного пакета клиенту.
  Для этого уже давно придумали кучу RPC. Это всё элементарные вещи, кто мешает уже нормально взять и изучить, а не изобретать велосипеды?

#205
13:12, 11 ноя. 2016

Old_Maple
> Ну, хорошо. Допустим, не хватает ресурсов на сервере, чтобы каждому
> подключенному клиенту что-то там вычислять и отправлять готовые результаты.
> Тогда имеет смысл отправить клиенту dll-ку с конкретной функцией. Клиент у себя
> проведет вычисления и получит результат. Но здесь встает проблема не столько с
> подключением данной dll-ки и функции из нее, посредством
> "LoadLibrary+GetProcAddress+CallWindowProc", сколько с передачей данных для
> подключаемой функции.
Приведи пример такого взаимодействия на другом ЯП, я просто тебя не могу понять. Вообще очень отдаленно это напоминает DCOM, кторый также из коробки поддерживается в VB6. Для вызова функции по указателю нужно вызывать DispCallFunc, которая поддерживает различные соглашения вызова и переменное число параметров.

#206
15:50, 11 ноя. 2016

the trick
> Для этого уже давно придумали кучу RPC.
the trick
> Вообще очень отдаленно это напоминает DCOM, кторый также из коробки
> поддерживается в VB6.
Вот-вот. Опять значит связываться с маршаллингами/сериализациями. Куча кода... :)
Я ведь потому и спросил, что хотелось чего-то покороче (лаконичней).
the trick
> Для вызова функции по указателю нужно вызывать DispCallFunc, которая
> поддерживает различные соглашения вызова и переменное число параметров.
А вот про DispCallFunc, увы, не знал. Надо будет поюзать. Спасибо.
the trick
> Приведи пример такого взаимодействия на другом ЯП, я просто тебя не могу
> понять.
Если бы я нашел это в другом языке программирования, то, наверное, было бы проще. :)

#207
16:41, 11 ноя. 2016

Old_Maple
> Вот-вот. Опять значит связываться с маршаллингами/сериализациями. Куча кода...
> :)
Ничего не нужно. Со стороны программиста это выглядит как будто просто вызывается метод объекта. Не знаю, видел ли ты когда-нибудь как работают на VB6 с Word, Excel, хотя это отдельный out-of-process сервер.

#208
9:46, 28 янв. 2017

the trick
> Не знаю, видел ли ты когда-нибудь как работают на VB6 с Word, Excel...
Увы, я работал только с Excel на VBA, для того, чтобы создать менеджер спецификаций к чертежам. :)

Страницы: 19 10 11 12 13 14
ФлеймФорумПрограммирование

Тема в архиве.