ffi pid по hwnd Опции

[cirus]

Не проще посмотреть пример чтения памяти?
https://forum.uokit.com/index.php?s=&sh...st&p=437715

работает на пилоте, на блокноте не хочет.

Открой Cheat Engine 32 бита и попробуй что-нибудь найти в 64 битном блокноте.

[Cockney]

Если функция что-то возвращает, то это не значит, что она работает корректно

Крамольную вещь напишу - мне кажется лучше всего полагаться на поведение, описанное в документации. Если там написано, что все что не 0 это ок, значит так оно и есть.

Полученное значение слишком мало, чтобы быть указателем ~800 и увеличивается при каждом запуске, что характерно для создания новых указателей

Хендл не обязан быть указателем в том понимании которое ты закладываешь. Он просто как тип совместим с ним. Например, getmodulehandle вернет указатель, из которого можно читать, а все остальные функции могут и не дать таких гарантий. И инкремент это не признак указателя, это простейший счётчик дескрипторов, чем хендл и является

[DarkMaster]

Не проще посмотреть пример чтения памяти?

Гут ссылка. Тем не менее есть вопрос =)
ты объявляешь:
bool ReadProcessMemory(int hProcess, int lpBaseAddress, void *lpBuffer, int nSize, int *lpNumberOfBytesRead)
при том что
BOOL ReadProcessMemory(
[in] HANDLE hProcess,
[in] LPCVOID lpBaseAddress,
[out] LPVOID lpBuffer,
[in] SIZE_T nSize,
[out] SIZE_T *lpNumberOfBytesRead
);

Т.е. вместо указателей опять объявлены сами данные. Как? Почему? Тоже самое в в GetProcessHandleFromHwnd аналогично. При этом, если закидывать указатели, то не работает, а с данными шуршит. В чем прикол? У меня походу какое-то глобальное непонимание манов =\

[DarkMaster]

Крамольную вещь напишу - мне кажется лучше всего полагаться на поведение, описанное в документации.

Так в том и вопрос. В документации на входе и выходе другие типы данных... Я пытаюсь это понять и прошу объяснить.

[cirus]

struct HWND__ { int unused; }; typedef struct HWND__ *HWND;
struct HBITMAP__ { int unused; }; typedef struct HBITMAP__ *HBITMAP;
struct HBRUSH__ { int unused; }; typedef struct HBRUSH__ *HBRUSH;

Это всё одно и тоже, по сути int. Нет смысла играться с приведением к нужному типу.

[Cockney]

Так в том и вопрос. В документации на входе и выходе другие типы данных... Я пытаюсь это понять и прошу объяснить.

Я искренне не понимаю в чем проблема. Покажи хоть ссылку на вход/выход свой, ибо то что я скидываю - там должно быть все понятно.

[DarkMaster]

Банально взять тот же ReadProcessMemory
по майкрософту он
BOOL ReadProcessMemory(
[in] HANDLE hProcess,
[in] LPCVOID lpBaseAddress,
[out] LPVOID lpBuffer,
[in] SIZE_T nSize,
[out] SIZE_T *lpNumberOfBytesRead
);
HANDLE это цепочка
typedef void * PVOID;
typedef PVOID HANDLE;
Т.е. по сути у нас должен отправиться указатель на данные. Ну т.е. типа принимающая функция ее должна разыменовать и работать с данными. cirus передает не указатель на данные, а непосредственно int с данными:
bool ReadProcessMemory(int hProcess, int lpBaseAddress, void *lpBuffer, int nSize, int
При этом указатель не пашет, а инт пашет. Учитывая сказанное тобой выше про то, что хэндл это не совсем указатель единственное, что мне приходит в голову, что есть некоторый лист хэндлов, а тип данных тут от балды и в целевой функции нет разыменовывания и данные используются напрямую (типа индекса в листе). Но зачем тогда городить указатели, а не объявить изначально хэндл интом я вообще не понимаю. Указатель должен указывать на адрес, а он(когда там хэндл) указывает на не аллоцированную область.

Вся цепочка проблем с которыми я столкнулся по сути одинаковая в каждой функции. Я хэндл воспринимал, как указатель на данные (а по typedef так и есть), а там сами данные...

[Cockney]

Ну давай попробуем по порядку:

1) Любой указатель можно представить как int, т.к. по сути указатель и есть число, обозначающее номер ячейки памяти

2) Функция принимает:

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

Т,е. даже из самой сигнатуры становится понятно, что чтение будет из LPCVOID lpBaseAddress и хендл здесь является тем чем и должен - просто дескриптором процесса, в котором аллоцирован блок памяти, доступный по LPCVOID lpBaseAddress (может быть и смещенным).

Откуда у тебя убеждение что хендл == указатель на данные я не понимаю. То что он тайпдефнут как void* или еще что-то не делает его НЕ int'ом. Это все то же число которое можно представить и как int и как void* и как char*. Конкретное его значение интерпретируется в кишках системы везде по разному - где-то это реально поинтер на данные, где-то индекс в буффере ядра, о чем и пишут где-то мелкомягкие. пользователю достаточно этот хендл гонять из функции в функцию и не пытаться его разыменовать/прочитать и т.д.

[DarkMaster]

Откуда у тебя убеждение что хендл == указатель на данные я не понимаю.

ну типа звездочка = указатель, если совсем по дубовому. Ну а указатель = адрес в памяти. Такая логика была.

[Cockney]

Использование void* не в качестве указателя обусловлено необходимостью поддерживать родную для системы битность. Ну т.е. если написать int, то не факт что в скомпилированном приложении он будет 32(64) бита занимать, а void* всегда либо 32 либо 64 в зависимости под какую битность собираешь. Но это вроде даже в Си уже улучшили, просто мелкомягкие не обновили доки + хедеры.

Собственно HANDLE так вот и прячет детали реализации от юзера апи

[Aqualon]

Да, возвращает GetWindowThreadProcessId действительно thread id, но там есть out параметр для пида.
Скопипасчу пример кода из адаптера для винапи который я сделал.

Код

local WinUser = ffi.load('User32')
ffi.cdef[[
   int __stdcall GetWindowThreadProcessId(int hWnd, int *lpdwProcessId);
]]
local WinApiInterface = {}

function WinApiInterface.GetWindowThreadProcessId(handle)
    local pid = ffi.new("int[1]")
    local threadId = WinUser.GetWindowThreadProcessId(handle, pid)
    assert(threadId ~= 0, 'GetWindowThreadProcessId error: incorrect handle passed: '..handle)
    return {
        pid = pid[0],
        threadId = threadId
    }
end

return WinApiInterface

[DarkMaster]

assert(threadId ~= 0, 'GetWindowThreadProcessId error: incorrect handle passed: '..handle)

handle лучше завернуть в tostring(handle), т.к. если там будет C тип либо nil/false/true/table/usertype - выбьет ошибку. Он не сможет выполнить .. строки.

Сообщение отредактировал DarkMaster - 20.2.2024, 7:43

[DarkMaster]

Использование void* не в качестве указателя обусловлено необходимостью поддерживать родную для системы битность. Ну т.е. если написать int, то не факт что в скомпилированном приложении он будет 32(64) бита занимать, а void* всегда либо 32 либо 64 в зависимости под какую битность собираешь. Но это вроде даже в Си уже улучшили, просто мелкомягкие не обновили доки + хедеры.

Собственно HANDLE так вот и прячет детали реализации от юзера апи

Я уже раз десятый перечитваю это... Ну разве не костыли и быдло код?)

[Cockney]

А есть ли у тебя опыт поддержки кодовой базы в миллионы строк кода на протяжении лет 20-30 ? Это с высоты текущих лет все кажется быдлокодом и костылями, а во времена когда это писалось просто не было даже намека на современные возможности/подходы к разработке.

[DarkMaster]

А есть ли у тебя опыт поддержки кодовой базы в миллионы строк кода на протяжении лет 20-30 ?

А я и не претендую. Просто смотрю на это и впадаю в прострацию какую-то. Напоминает, как я лет 15 назад массив двумерный сортировал... вторая размернасть была равна двум и внутри инты. Я просто обявил указатель на long long чтобы при сортировке учитывались оба элементра. Сейчас за такое стыдно) А тут серьезные люди.

[Cockney]

Ну это прям разные случаи. От тебя не зависело до половины пользователей ПК в мире)


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