Дня доброго.
Тема создана для темы:
Иногда они возвращаются.... Хранение методов в памяти.
Там есть процедурка
function MethodToProcedure(self: TObject; methodAddr: pointer) : pointer;

Я так и не понял, как она работает, и вот пришло расскаивание - мне нужна ее 64-х битная сестра-близнец.

Помогите.

Вернее, я сейчас понимаю, как там все работает - выделяется кусок памяти, в нее записывается код на ассемблере, и возвращается адрес этого куска памяти как указатель. Код запускает выполнение по этому адресу (создает поток, например), выполняется ассемблеровский код, который передает управление по адресу methodAddr.

Мне нужен такой же асм. код под 64-х битное приложение.

(1) на 64-х может сразу не прокатить. там может быть защита на выполнение кода в данных. нужно как то особо память выделять чтобы давало доступ на выполнение.

+(2) в 64-x еще есть заморочка про вызовы функций. в 32 там всякие stdcall, cdecl и т.п. В 64-x только один способ.

(0) код в lazarus (fp x64) не работает?

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

(3) Какой?

(2) гхммм.
В разделе защиты памяти ничего про это не говорится.
https://msdn.microsoft.com/en-us/library/windows/desktop/aa366786(v=vs.85).aspx

(4) Нет, в Дельфях.

(6) забыл как называется. поню что параметры сначала в регистрах, остальное в стек. на MSDN по русски расписано все подробно. щас голова болит искать неохота.

Робко интересуюсь конечной целью сего действа

(9) fastcall

(7) ну я щас точно не помню. прсто когда я делал когда то jit компилятор у меня такая фигня была. на 32 работало, на 64 глюк. надо искать свою писанину. поню только что какие то атрибуты выделенной памяти присваивал.

(10) Хочу из созданного потока вызывать методы объекта, создавшего поток.

(11) не. это не то.

(10) Thread-callback функция размещена в секции published объекта.

https://msdn.microsoft.com/ru-ru/library/ms235286.aspx

(10) он себя когда нибудь погубит этими килабайтами и стеками

(13) вангую много-много геморов с синхронизацией потоков, даже если сам вызов удастся... странная идея

(18) Это все понятно, дыры заткнем ожиданиями на мьютексах, но пока их нет. В 32-х разрядах все работает как часы.

в гугле, как всегда, всё готовое уже есть
http://stackoverflow.com/questions/8283490/how-to-turn-a-method-to-a-callback-procedure-in-64bit-delphi-xe2

там и про память чо я говорил
Q := VirtualAlloc(nil, lCount, MEM_COMMIT, PAGE_EXECUTE_READWRITE);

https://yandex.ru/yandsearch?&clid=2186620&text=MethodToProcedure%20x64

самая первая ссылка.
H A D G E H O G s, ты тролль

(22) Бугага. nice

Искал воот так:

https://yandex.ru/search/?text=MethodToProcedure%2064x&clid=2186620&lr=213

Всего одна ошибка в строке поиска и такие проблемы.

Спасибо огромное.

можно придумать десяток надежных способов передачи события и данных между потоками стандартными средствами, без всякого хака

(26) Проблема не в данных, проблема в области видимости.

(26) да тут потоки не главное. это про то, как приляпать к объекту callback, который будет вызывать например windows, в котором используются данные конкретного объекта (здесь этот объект - поток)

+(28) этот хак используется в Delphi везде. Даже обычная кнопка на форме так работает. Ибо windows так устроена.

(робко) а может лучше на fp? ...

а то под linux то как?

(28)все равно не понятно зачем для этого размещать код в области данных :)
есть же наверно в delphi процедурный тип

(31) ну предложи другой вариант

(31) интерпретируемый интерпретатор

я для своей поделки использовал


HANDLE CreateFileMapping( HANDLE hFile,  //дескриптор физического файла LPSECURITY_ATTRIBUTES lpFileMappingAttributes,  //игнорируется. Должно быть NULL DWORD flProtect,  //флажки защиты доступа DWORD dwMaximumSizeHigh,  //старшие байты размера DWORD dwMaximumSizeLow,  //младшие байты размера LPCTSTR lpName  //имя проекции );

Чота слабо припоминаю, что в новых версиях Delphi что то  поменялось по этой теме. щас загуглю.

(34) при указании соответствующих флагов этот файл видится из любых потоков/процессов

(34) (36) Што это? Зачем это?

(36) веткой ошибся

(37) через этот файл (или поток, там то же есть) можно передавать данные между потоками.

Как я понимаю тебе ведь нужно тупо данные передавать, иначе ты-бы юзал динамическое связывание DLL

(39) Ты действительно ошибся веткой :-)

vde69 кажися написал какого то бота для генерации постов на тему программирования и он щас над нами глумится

(39) Проблема описана в сообщении (11) в ветке
Delphi. Методы объектов как то по другому хранятся в памяти?

Ее и решаем.

А. Вспомнил. В Delphi же сейчас есть записи с методами. Методы записей наверное обычные процедуры. Можно вместо класса использовать такие записи.

(43) Бррр, моя душа ерепениться от таких нововведений.

(42) попробуй (43). у меня теперя delphi нету. перешел на lazarus

(44) нуачо. как раз для твоего случая

и без хаков.

(45) Нет, у меня готовая dll-ка 32-х разрядная, отлаженная. Осталось ее сестричку под 64-x сделать и все.

судя по (13) >>>>Хочу из созданного потока вызывать методы объекта, создавшего поток.

я понимаю дело так

есть основной загрузчик, этот загрузчик резервирует память и помещает в нее некий код, после запускает отдельный процесс который должен использовать код созданый загрузчиком?

почему запускаемый загрузчиком новый процесс не может загрузить DLL позднего связывания и спокойно юзать все, что надо?

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


еще по сабжу: в подобных поделках нужно использовать SDK операционки а не дельфей и тог-да не будет проблем ни с правами ни с чем еще...

(49) Помнишь, я приходил к тебе на собеседование. Скажи сферу деятельности предприятия, в котором проходило наше собеседование?

(50) ...где попкорн?

(49) какой ты сложный, чувак

(32)вот такое разве нельзя сделать на delphi?

    //класс с функцией членом foo
    class c
    {
    public:
        int foo(int i)
        {
            return 6 + i;
        };
    };

    typedef int (c::*fType)(int); //объявление типа fType как указателя на функцию класса с параметром типа int и возвращающей int

    fType pf = &c::foo; //присваивание адреса функции foo класса с в переменную pf

    c* pc = new c(); //создание объекта типа с в переменную pc

    int r = (pc->*pf)(2); //вызов функции из переменной pf с параметром 2, результат: r = 8;

    delete pc; //уничтожение объекта

Не. Нужно метод объекта вызвать как обычную функцию, но в этом методе объекта иметь доступ к полям объекта.
Надо примерно так. (сомневаюсь что правильно написал)
    class c
    {
    public:
        int X;
        int foo(int i)
        {
            return 6 + X;
        };
    };

    typedef int (*fType)(int);

    fType pf = (fType)&c::foo;
    c* pc = new c();
    int r = pf(2);
    delete pc;

TMethodToProc = packed record
    popEax: Byte;
    pushSelf: record
      opcode: Byte;
      Self: Pointer;
    end;
    pushEax: Byte;
    jump: record
      opcode: Byte;
      modRm: Byte;
      pTarget: ^Pointer;
      target: Pointer;
    end;
  end;    

function MethodToProcedure(self: TObject; methodAddr: Pointer): Pointer;
var
  mtp: ^TMethodToProc absolute Result;
begin
  New(mtp);
  with mtp^ do
  begin
    popEax := $58;
    pushSelf.opcode := $68;
    pushSelf.Self := Self;
    pushEax := $50;
    jump.opcode := $FF;
    jump.modRm := $25;
    jump.pTarget := @jump.target;
    jump.target := methodAddr;
  end;
end;

(55) да уже давно решили. тут просто болтовня уже.

А зачем вообще такое нужно кроме случаев юзания чужого скомпиленного кода?

(54) все правильно, за малым исключением того что X не инициализирован.
"иметь доступ к полям объекта" - ну кабы это не проблема если эта функция-член не stаtic.
можно добавить к классу конcтруктор:
c() {X = 10;}
и тогда после:
int r = pf(2);
r будет равна 16

ну вызов только так надо делать
int r = (pc->*pf)(2)
с использованием экземпляра класса, а как иначе-то?

(58) а так?

   class c
    {
    public:
        int X;
        int foo(int i)
        {
            return 6 + X + i;
        };
    };

(60)без проблем

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

но тогда в ней (разумеется) не получить доступ к данным экземпляра класса.

на обджект паскале все тоже должно быть, я думаю..

кстати функцию-член можно запросто сделать и виртуальной (метод)

(64) да там всё точно так же.
а так что будет

   class c
    {
    public:
        int X;
        int foo(int i)
        {
            return 6 + X + i;
        };
    };

ой
   class c
    {
    public:
        int X;
        int foo(int i)
        {
            return 6 + this->X + i;
        };
    };

6 + this->X + i;
6 + X + i;
это одно и тоже, эквивалент, после компилятора даже код будет бинарно одинаковый

они щас умные, что звиздец..

Вашу бы енергию, да в мирное русло...

например в объектах можно так написать:
void Kill_Himself()
{
  delete this;
};
применяют для когда объект сам управляет своим временем жизни

в каждом COM объекте кстати такой код есть :)

(58) не знаю как у тебя получилось 16. у меня такое даже не компилится и правильно делает.

приведение типов: невозможно преобразовать "int (__thiscall wmain::c::* )(int)" в "fType"

(63) >>тогда в ней (разумеется) не получить доступ к данным экземпляра класса.

Многие Win32 callback'и имеют дополнительный нетипизированный параметр.
Туда можно передать this и иметь доступ к экземпляру класа.

Если callback твой - добавь параметер для this.

(50) здание точно не помню, это или цивильное здание с шлюзом на 1 человека или говно дом напротив биржи. (фин холдинг был... а направлений там много было ...)

но дело не в этом а в том, что я не понимаю главное: нужно использовать "свое" адресное пространство или "чужое"??? из сабжа я понял, что "чужое", если это не так - то разумеется я чушь порол :)

(75) Все, теперь я понял, что ты - настоящий :-)
Адресное пространство - свое.

(76) тогда процедурный тип сделай и должно все штатно без плясок взлететь