Antonshka

Как можно указать для EXE приложения путь к поиску DLL, которая прилинкована статически, через .lib файл, и которая расположена не в корневом каталоге этого приложения? Например EXE расположен в "D/:Tool/Run.exe". А DLL в "D/:Tool/Pack/Math.dll". MSDN - Search Order for Desktop Applications - согласно написанному, можно использовать DLL redirection, но при таком способе нужно создать в реестре ключ, и перезапустить компьютер. Это не подходит. Через manifest, но я не нашел примеров.

Это да, но я надеялся не таким способом. Не способом перевода байт в вид 0x0. А затем ручным внесением его в файл в виде определения массива.

Я понял про что ты говоришь. Я имел ввиду что это неудобно, переводить файл в байты, и писать их в массив. Думал есть что-нибудь попроще. Но оказалось что нет. Статическая библиотека это просто архив кода. В конечный .lib файл не входят его ресурсы. Вот DLL да, она их может содержать. После создания .lib файла, в папке Release или Debug будет лежать файл ресурсов с расширением .res. Его можно подключить после к проекту, который будет использовать библиотеку, но это не то что мне хотелось. Так что вот, либо переводить в байты, либо включать .res файл, либо никак.

Объясните пожалуйста, DLL хранится в оперативной памяти в одном экземпляре То есть каждое приложение использующее DLL имеет в своем адресном пространстве только переменные из этой DLL, но не сами функции? Тогда в чьем адресном пространстве находится сами функции? Если я изменю функцию например для memcpy, то получается что все приложения будут использовать модифицированную версию? Никак не пойму.

Точно не знаю, но предполагаю что в обычном виде. Без 0x. Просто, - ec d3 e5 ec d8 ea (это я открыл файл .res в HEX Editor). А тот человек по сути просто создавал переменную, массив. Вида 0xec, 0xd3, 0xe5, 0xec, 0xd8, 0xea.

Почему DLL может содержать в себе ресурсы, а LIB не может. Если у них основная разница в том что одна линкуется динамически, а другая ститически?

Приветствую, никто не сталкивался с такой задачей? Например, есть статическая библиотека, .lib файл, в его ресурсах есть курсор, этот курсор используется некоторым классом этой самой библиотеки. Если попытаться подключить эту библиотеку к иному какому проекту, то курсор уже не определяется. Как стало известно из интернета, курсор не определяется потом что .lib файл не имеет собственного HINSTANCE. И когда программа пытается отыскать ресурс курсора, она ищет его в своих собственных ресурсах, а не в тех что от .lib файла. Один человек решил эту проблему переводом иконки в байт код вида 0x0. Затем добавлением его в .lib файл в виде Byte[] arrayOfIcon = { 0X02, 0X0F, ... }. Затем вызовом winapi функций LookupIconIdFromDirectoryEx и CreateIconFromResourceEx. Мудренный способ конечно. Вот его описание Может есть попроще способ?

Кажется я не так выразился, и ты меня не понял. Вот пример - есть адрес, 0041A510. Его можно использовать как для 1 байтового значения, так и для четырех, смотря на выставленный тип. Когда ты делаешь сканирование, сканируй значение этого адреса как 4 байтовое, а затем, когда уже добавишь верный указатель в таблицу, выстави его на 1 байт. Также, если у тебя адрес не выравнен по четырем байтам, то есть не 0041A510, а 0041A511, или 0041A512. То сканируй значение выравненного адреса, то есть значение адреса 0041A510, или 0041A514. Затем, в конце, просто сместишь указатель на один, два, или три байта.

Не помню как там ищутся указатели в СЕ, но что если искать четырех байтовое, а после нахождения, просто сменить тип, на 1 байт?

@DragonForce, я на таком же уровне сейчас. Я не увидел в твоем коде самого хука. Что именно ты хукаешь? Вызов ReadFile из main, или ReadFile в Kernel32.dll? Или подменяешь адрес ReadFile в разделе импорта?

Если найдешь решение, то напиши его здесь. Напиши рабочий код, ссылки, названия книг. Все что тебе помогло. Это хорошая привычка, так завершать темы, хотя, наверно, и не обязательная.

Нужно пройтись по всем строкам файла. Ведя общий их учет. Используй цикл for и используй итератор lines() из стандартной lua библиотеки.

А в каком каталоге должен сохраняться файл? Если в том же где и само приложение, то нужно использовать TrainerOrigin : A variable that contains the path of the trainer that launched cheat engine (Only set when launched as a trainer) либо getCheatEngineDir(): Returns the folder Cheat Engine is located at Если в каком-то ином, то нужно либо заранее прописать путь, либо использовать командную строку WIndows, для определения например пути к моим документам, рабочему столу, Temp, и т.д. CEEdit имеет событие OnKeyPress. Можно использовать его для вызова функции записывающей в файл. Функцию нужно прописать прямо в Lua Engine. Как в Lua обращаться с файлами, можно узнать из документации Lua языка.

Да, так определенно лучше. Да, только похоже что ты по привычке написал С++ вариан not'a. В Lua not так и пишется - not. Правда вчера я не понял почему not не сработал вот в этой ситуации --Допустим процесс открыть не удалось if (not getOpenedProcessID()) then -- Так не работает, несмотря на то что getOpenedProcessID() вернул 0 if (not (getOpenedProcessID())) then -- И так тоже не работает if (getOpenedProcessID() == 0) then -- Так работает print("Can't open process") --closeCE() --return caFree end Из celua.txt getOpenedProcessID() : Returns the currently opened process. If none is open, returns 0 Пришлось сравнивать с нолем, вместо not. Хотя в С++ в таких ситуациях not отрабатывает нормально.

Можно так: - Открытие процесса записать в самое начало Lua Engine. openProcess(processid) : causes cheat engine to open the given processid openProcess(processname): causes cheat engine to find and open the given process - В СЕ дизайнере создать форму, на форме создать таймер, с интервалом 5000 милисекунд. В событии таймера (OnTimer) проверять, если скрипт в таблице не активирован, то активировать, а если активирован, то деактивировать.

Я инжектил DLL через Cheat Engine. По исходникам, - на некоторое время я все это дело забросил. Ничего толком работающего нет. Все внимание сейчас направлено на WinAPI GUI Wrapper.

Может Microsoft теперь сменила схему. Я вчера попробовал по твоему совету WS_EX_LAYERED для дочерних элементов без записи в манифесте <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/> , но с вызовом INITCOMMONCONTROLSEX icc; icc.dwSize = sizeof(INITCOMMONCONTROLSEX); icc.dwICC = ICC_WIN95_CLASSES; InitCommonControlsEx(&icc); - ничего не вышло, дочерние не отображались. Я на Windows 11 сейчас. Я бы рад использовать только InitCommonControlsEx, без манифеста. Для расширенных стилей я так понял в манифесте нужно прописать шестую версию

InitCommonControlsEx как я понял нужно вызывать для загрузки Comctl32.dll. Чтобы была возможность использовать Tooltip, Toolbar, и им подобные. Без записи в манифесте <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/> контролы со стилем WS_EX_LAYERED не будут отображаться совсем. Только лишь главное родительское окно, для которого по видимо эта возможность установлена по умолчанию. Ага, также при стиле WS_EX_LAYERED можно и у дочернего элемента изменять его собственную прозрачность. Исчезновение мерцания, как я понял из MSDN, связано с тем что система использует для компоновки финального изображения слои. Спасибо за помощь. Хорошо что все так хорошо закончилось.

Всё же есть решение - Layered Windows Чтобы проект Visual Studio поддерживал Layered Windows, необходимо в файле манифеста указать следующее Главное окно и все его контролы нужно создать со стилем WS_EX_LAYERED. Далее для всех них нужно вызвать API функцию SetLayeredWindowAttributes. О всех подробностях реализации можно почитать на MSDN, ссылка вверху. Вот тестовый пример. Абсолютно никаких мерцаний. Ни у главного окна (оно использует здесь между прочим двойную буферизацию), ни у самих контролов.

Проверил сейчас прозрачный текстовый контрол в Cheat Engine на перемещение (инициирование обновления его прозрачного фона) function UDF1_FormClick(sender) UDF1.CELabel1.Top = UDF1.CELabel1.Top + 5 end И знаете что? Он тоже мерцает! Это просто немыслимо...

Отладочные тесты показали, что для ПРОЗРАЧНОГО текстового контрола, 100%-ое устранение мерцания невозможно. Вся загвоздка в стиле этого самого текстового контрола. Чтобы фон текстового контрола был прозрачным, нужно обязательно использовать стиль WS_EX_TRANSPARENT. При нем фон текстового контрола стираться всякий раз когда обновляется нижележащий элемент. Вот последовательность: 1) обновляется фон нижележащего элемента (допустим это главное окно приложения). Клиентская область текстового контрола соответственно тоже вся обновилась, в ней стало отображаться то, что находится под ней, но сам текст при этом теперь не виден, так как абсолютно вся область текстового контрола была обновленна 2) начинает рисоваться текст в текстовом контролле (пусть даже и с двойной буферизацией) Между первым и вторым пунктами и происходит исчезновение самого текста, то есть происходит мерцание. И это никак не пофиксить.

Да, BitBlt в твоем примере просто копирует биты из одного DC в другой DC, без предварительного стирания фона этим же BitBlt. Я говорил про то, что если потянуть за уголок главного окна, то и ему, и всем его дочерним окнам, будут посланы сообщения WM_ERASE, потом WM_PAINT. То есть я говорил про то что фон будет стерт собщением WM_ERASE, но не самим BitBlt. Обязательно, если ничего не выйдет. Сперва потренируюсь на SS_OWNERDRAW.

Ага, я не то скопи-пастил. Хотел RDW_ERASENOW | RDW_ERASE. То есть я пробовал без RDW_ERASENOW | RDW_ERASE. Я смотрел все серии. Давно еще. Про буферизацию пересматривал на днях. Как я заметил на видео, ты не обрабатываешь сообщение WM_ERASEBKGND, возвращая TRUE. Для отмены стирания фона. case WM_ERASEBKGND: return TRUE; И в функции DrawFrame у тебя не установлен флаг RDW_ERASE, при вызове функции RedrawWindow. Наверно поэтому у тебя изображение не мерцает. Просто я подумал, как в твоем примере будет вести себя отображение, если начать изменять размер главного окна, потянув его за уголок. Ведь будет послано сообщение WM_ERASE и WM_PAINT для всех элементов окна, включая его самого. И по идее вначале будет стерт весь фон, а потом выполнен case WM_PAINT. В WM_PAINT у тебя используется глобальный backDC, и так как он всегда имеет в себе изображение, то BitBlt в WM_PAINT отработает корректно. Но перед этим будет стерт весь фон. И по идее должно произойти мерцание. Это меня немного сбило с толку, когда я пытался вникнуть в твою реализацию двойной буферизации. Я пробовал уже делать двойную буферизацию для самого главного окна, и параллельно для текстового контрола, но увы, он все равно мерцал. Я даже пробовал просто создавать дочернее окно, со стилем WS_EX_TRANSPARENT, и используя двойную буферизацию для него, функцией TextOut выводить строку. И все равно, даже и так мерцало. Буду пробовать сейчас через BS_OWNERDRAW . А потом, если не выйдет, через CustomDraw. Самое интересное, что ни один контрол не мерцает вообще, никогда. Только вот этот, текстовый.

Попробовал убрать RDW_INVALIDATE. RDW_ERASE, - все равно мерцает. А возможно с BS_OWNERDRAW для кнопки добиться отображения только текста, без фона самой кнопки? Если да, то как сделать фон прозрачным? Через TransparentBlt? Например у меня под текстовым контролом будет какая-нибудь картинка.

Пример кода мерцающего контрола. Если быстро перемещать ползунок прокрутки вверх-вниз, то будет видно как текстовый контрол мигает.