Thread - как ее юзать

Мужики! Всем спасибо за помощь! Быль просто в экстазе, когда моя прога нашла все процессы запущенные на тачке. Как и было на советаванно експерементирую на калькуляторе(бедный чего ему только не достаеться. Получил его хендл но не разберусь с VirtualAllocEx

Мой win32.hlp вообще говорит что она только под NT прет, но в моем kernel-e(win98) она лежит. Ну впринципе, этому я тоже рад

Проблема в другом, она вызываеться у меня ес проблем, но как ей пользоваться? Эта проблема в очеродной раз связана с моим знанием(а точнее не знаниеманглийского)

Код (Text):

1.  
2. LPVOID VirtualAllocEx(
3.     HANDLE hProcess,    // это ясно - хендл проги(найденой)
4.     LPVOID lpAddress,   // ???
5.     DWORD dwSize,   // размер регестрируеммого куска
6.     DWORD flAllocationType, // тип(даны три штуки, какой зачем, не пойму)
7.     DWORD flProtect     // тип доступа(я так понял) - тут вроде все ясно. PAGE_EXECUTE_READWRITE  - кодовая,читать/писАть.
8.  

Если кому не влом, порадуйте старика, поясните.

 

warsem

VirtualAllocEx/CreateRemoteThread существуют только в NT

системах, так что пока про win98 забудь.

Хотя есть либа реализующая эти функции под 9x, но

пока думаю тебе не стоит заморачиваться с ней.



cresta

Не знаю, но почему-то по твоим постам на форуме сложилось такое впечатление %)

Это не вина утилиты, это издержки такого подхода, там помоему в какой-то структуре был член ExitProcess или какой-то другой совпадающий с именем API, из-за

этого был конфликт с инклудами

 

Вот с вопросом пояснить описание ф-ии на Русском стала актуальна тема про Справочник по API на Русском. ^) На мой взгляд, стоит писать такие вопросы туда. Глядишь пополниться

 

Asterix

"VirtualAllocEx/CreateRemoteThread существуют только в NT

системах" - а как быть с тем, что я нашел их в кернеле, и они вызывабться?



PavPS

я ее и создовал когда-то



И плз, поясните параметры для VirtualAllocEx. Особенно lpAddress - как то он здесь вообще "не в тему"

 

warsem



LPVOID lpAddress - это начальный адрес, от которого будет выделяться кусок памяти размером dwSize. Если не знаешь, от какого места запросить память, сделай NULL, система сама определит безопасный начальный адрес. Если потом в процессе работы программы вдруг не хватит этого куска памяти, и возникнет исключение, то вызываешь снова VirtualAllocEx с первым параметром, равным уже не NULL, а полученным от предыдущего вызова.

DWORD flAllocationType - флаги, определяющие состояние куска памяти.

MEM_COMMIT - память сразу готова к употреблению MEM_RESERVE - память зарезервирована, и пока не используется. Чтобы получить к ней доступ, надо ещё раз вызвать VirtualAllocEx, с параметром MEM_COMMIT.

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



Asterix

Я не запрашивал твоего мнения о моих постах.

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

 

cresta

Хмм. Забавно. Ты обиделся что-ли?

У меня не было такой цели, просто настроение сегодня такое %)

И, кстати, помоему я ответил на твои вопросы, по

поводу нахождения адресов API.

Я тоже

 

warsem

Это заглушки чтоб загрузчик не ругался если в программе

они используются и она будет запущена под win98.

 

Asterix

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

И у меня тоже бывает настроение. Сегодня такое >



Ладно, проехали.

 

Самый надежный вариант.

Можешь написать свой код сканирующий таблицу экспорта,

но зачем?

 

Просто я вижу, что vc выдает такое:

Код (Text):

1. 00401000 > . 7A2DE677       DD kernel32.Beep
2. 00401004 > . E9A6EB77       DD kernel32.Process32Next
3. 00401008 > . 6379E777       DD kernel32.CloseHandle
4. 0040100C > . 2E6AE777       DD kernel32.lstrcmpiA
5. 00401010 > . B706E777       DD kernel32.OpenProcess
6. 00401014 > . 95A5EB77       DD kernel32.Process32First
7. 00401018 > . E7B1EB77       DD kernel32.CreateToolhelp32Snapshot
8. 0040101C > . B55CE777       DD kernel32.ExitProcess
9. 00401020   . 00000000       DD 00000000
10. 00401024 > . 6AC9D377       DD USER32.wsprintfA
11. 00401028 > . D7ADD577       DD USER32.MessageBoxA
12. 0040102C   . 00000000       DD 00000000

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

Но похоже, это мало что даёт. Сопоставить затем сложно очень каждый вызов нужному адресу

 

Это только в отладчике так, в файле там реальных адресов

API нет естно.

 

q_q

Почему отказываться от invoke? Всё и с invoke прекрасно работает, без лишних jmp.

 

Quantum

Потому что для invoke необходимы прототипы.

 

2 warsem



Советую найти книгу Чарльза Петцольда "Programming Windows". Наверное, на русском она тоже есть. Это один из немногих людей (ИМХО), который не только знает, что говорит, но и умеет преподнести свои знания. Такое встречается не часто. Судя по ответам, ты не совсем четко понимаешь, что нужно делать, и здесь Петцольд очень поможет.

 

Programming Windows 95? Великолепная книжка... ~1100 страниц (на русском)... IMHO лучшая по программированию под винду. Жаль не все темы в ней рассмотрены.

 

q_q

extern _imp__ExitProcess@4 : dword

ExitProcess textequ <_imp__ExitProcess@4>

Ничто не мешает поступить хитрее:

Код (Text):

1. pr1 typedef PROTO :DWORD
2. externdef _imp__ExitProcess@4:PTR pr1
3. ExitProcess equ <_imp__ExitProcess@4>

И продолжаем активно использовать invoke. Об этом в описании L2EXTIA чётко написано.

 

Maque

_BC_

Скажите лучше где надыбать, ведь правда пишу толко по "наводке". Одну функцию вызову, вопросы по следующей

 

Quantum

Хорошо.

Однако возникает вопрос: "Если все так просто, то почему до сих пор (L2EXTIA датирована 2001 годом) в пакете masm32 не исправленные inc-файлы?"

 

q_q

Потому что утилита не нуждается в улучшении.

 

q_q

У меня они давно исправлены. Никаких багов не наблюдал. Единственный ньюанс связан с функцией wsprintf, т.к. она не прописана в оригинальном инклуде user32, а в файле windows.inc. Поэтому приходится исправлять её прототип вручную, но это всё равно не баг.