Перейти к содержанию

Antonshka

Пользователи+
  • Публикаций

    189
  • Зарегистрирован

  • Посещение

  • Победитель дней

    6

Antonshka стал победителем дня 17 сентября

Antonshka имел наиболее популярный контент!

Репутация

32 Rookie

Информация о Antonshka

  • Звание
    Спамер

Посетители профиля

Блок последних пользователей отключён и не показывается другим пользователям.

  1. Antonshka

    На чем писать GUI?

    Привет! Дочитываю книгу Щупака, по WinAPI. По словам самого автора - Петцольд, насколько я видел, пишет о том же самом что и Щупак, правда часто в более краткой форме, Фень Юань, - пишет более подробно, но у него все про GDI. Потому, дочитав Щупака, я решил перейти уже к написанию своего собственного приложения. Писать я буду на чистом WinAPI. Для того чтобы закрепить материал, в первую очередь, и для того чтобы просто уметь это делать именно на нем. Но что потом? Так и писать GUI приложения на чистом WinAPI? На чем вы пишите GUI для своих приложений? Читал сегодня, что на чистом WinAPI, приложения и весят меньше, и работают быстрее. Что MFC неудобный, с точки зрения стиля (я его еще не изучал). Что Qt тоже имеет какие-то проблемы. Вообще в будущем есть намерение писать через DIrectX. Но если не через него, то через что?
  2. Инициализировать коммон контролы, то есть выполнить этот код?
  3. Забыл написать что проект на UNICODE. Итак, после нескольких часов поиска решение в интернете, стало ясно что: - элемент управления ToolTip относится к общим элементам управления (common controls). Есть еще стандартные элементы управления (user controls) - общие элементы управления определены в файле ComCtl32.dll - файл ComCtl32.dll находится в папке windows/sytem32 - файл ComCtl32.dll имеет разные собственные версии - версия файла ComCtl32.dll влияет на то с какой версией структуры TOOLINFO код API, находящийся в ComCtl32.dll, может работать - для инициализации элемента ToolTip нужно определить и заполнить структуру TOOLINFO - существует три версии структуры TOOLINFO, отличающиеся количеством полей версия 1 - TTTOOLINFO_V1_SIZE //Для ComCtl32.dll версии 4.0 и выше версия 2 - TTTOOLINFO_V2_SIZE //Для ComCtl32.dll версии 4.7 и выше версия 3 - TTTOOLINFO_V3_SIZE //Для ComCtl32.dll версии 6.0 и выше - структура TOOLINFO помимо прочих своих полей, имеет поле cbSize, которое нужно заполнить, записав в него размер самой же структуры, то есть размер структуры TOOLINFO. - поле cbSize структуры TOOLINFO используется системой для определения версии API кода, который нужно использовать для работы с ней - заголовочный файл "commctrl.h", который необходимо подключить к проекту для того чтобы работать с общим элементам управления, основываясь на значении макроса _WIN32_WINNT, выбирает для работы с ToolTip соответствующую версию структуры TOOLINFO. - _WIN32_WINNT - этот макрос определяет в каких версиях Windows может выполняться ваш код - в моем проекте макрос _WIN32_WINNT имеет значение 0x0A00, что значит Windows 10 и выше, а это значит что проект использует самую новую, самую последнюю версию структуры TOOLINFO из заголовочного файла "commctrl.h", структуру о с размеров - TTTOOLINFO_V3_SIZE - если вы явно не укажете в своем проекте что хотите использовать ComCtl32.dll версии 6.0 и выше, то по умолчанию будет использоваться версия 5.0, а это значит что будет использоваться API код для работы со структурой версии TTTOOLINFO_V2_SIZE. Таким образом, файл "commctrl.h" предоставляет нам структуру версии TTTOOLINFO_V3_SIZE, в то время как ComCtl32.dll работает с версией TTTOOLINFO_V2_SIZE. Размер структуры TTTOOLINFO_V3_SIZE на 4 байта больше чем TTTOOLINFO_V2_SIZE. Из-за этого подсказка не отображается на экране. Решение может быть одним из следующих: - либо явно указать проекту что мы хотим использовать ComCtl32.dll версии 6.0 и выше, для этого нужно создать файл манифеста, в котором это указывается, или вместо файла манифеста воспользоваться прямым обозначением нашего намерения в файле .срр - либо переопределить макрос _WIN32_WINNT, до версии Windows 2000 - либо явно заполнить поле cbSize размером структуры TOOLINFO минус 4 байта Использование ComCtl32.dll версии 6.0 и выше меняет стиль отображения элементов управления. До версии 6.0 стиль элементов как в windows 95, 98. То есть до XP.
  4. Привет, никто не сталкивался с проблемой отображения автономного ToolTip? Делаю как в книге, и как на MSDN. Приложение запускается, но подсказку не отображает. Примитивный код С++ Ссылка на MSDN
  5. Вот опять, решение пришло в голову сразу после того как я написал здесь свой вопрос. Два дня я тщетно пытался его решить, но стоило мне запостить... Подумают что я спамер. А ведь действительно, два дня голову ломал. Ребята, которые тоже изучаете GDI, и имеете трудности в понимании режимов отображение, вот решение вопроса установки логической единицы равной 1/16 дюйма, как я полагаю: если умножить не на 16 SetWindowExtEx(hdc, (GetDeviceCaps(hdc, HORZSIZE) / 25.4) * 16, (GetDeviceCaps(hdc, VERTSIZE) / 25.4) * 16, NULL); но на 1 SetWindowExtEx(hdc, (GetDeviceCaps(hdc, HORZSIZE) / 25.4) * 1, (GetDeviceCaps(hdc, VERTSIZE) / 25.4) * 1, NULL); то вся ширина экрана в логических единицах будет равна числу 23.543 (дюймов, полученному из 598 мм / 25.4 мм). Почему вся ширина экрана? Потому что мы установили всю ширину экрана, а также всю высоту экрана, с помощью функции SetViewportExtEx(hdc, GetDeviceCaps(hdc, HORZRES), GetDeviceCaps(hdc, VERTRES), NULL); И если мы теперь попытаемся нарисовать к примеру прямоугольник, с шириной 23.543 единицы, Rectangle(hdc, 0, 0, 23.543, 11.7715); то он отобразится на экране точь в точь шириной во весь экран, а высотой в пол экрана, так как 23.543 / 2 = 11.7715. Теперь, если умножить 23.543 на 16, SetWindowExtEx(hdc, (GetDeviceCaps(hdc, HORZSIZE) / 25.4) * 16, (GetDeviceCaps(hdc, VERTSIZE) / 25.4) * 16, NULL); то мы в 16 раз увеличим диапазон ширины, для наших логических единиц. Тем самым, например при том же значении Y = 11.7715, прямоугольник отобразится уже в 16 раз меньше по высоте, так как логическая единица уменьшилась в 16 раз. Если провести аналогию, для лучшего понимания, то возьмем к примеру метровый кусок бревна, и распилим его на 23 части, каждая часть теперь будет равна 1/23 метра, или что тоже 100 см / 23 = 4.34 сантиметра. Пять таких частей вместе будут равны 4.34 х 5 = 21.7 сантиметрам. Но если мы теперь распилим бревно на более мелкие кусочки, а именно, 23 части умножим на 16, получим 368 частей, вот, - распилим на 368 частей. То в этом случае каждая часть будет равна 100 см / 368 = 0.271 см. И те же пять частей вместе, теперь уже не будут равны как раньше 21.7 сантиметрам, но будут равны 0.271 х 5 = 1.355 сантиметра. То есть умножая на 16, мы уменьшаем размер частички (логической единицы), мы более раздробляем промежуток ширины экрана, мы делаем логическую частичку меньше и меньше, чем больше то число на которое умножаем. Всем спасибо, наконец то!
  6. Снова возник вопрос для следующей задачи, - нужно сделать чтобы одна логическая единица была равна 1/16 дюйма. Вот решение из книги Petzold, где он сам эту задачу и ставит и решает, Вот выписка касательно этого решения Мой монитор по оси Х по результату HORZSIZE имеет 598 миллиметров. Переводя 598 в дюймы (598 / 25.4) получается 23.543 дюйма. И вот собственно сам вопрос, - почему нужно именно умножать, 23.543 на 16? А не делить? На 16, я так понимаю, потому что 1/16. 23.543 х 16 = 376,688 GetDeviceCaps(hdc, HORZRES) возвращает 1920 (пикселей по оси Х, ширина). Следовательно получается отношение 376 к 1920 , а именно 1920 / 376 = 5.106 (одна логическая единица будет равна 1/16 дюйма (1.587 миллиметра), или 5.106 пикселя, если в пикселях). Почему умножение на 16, как это работает? С одной стороны отношения, 23.543 дюйма умноженные на 16, с другой стороны, 1920 пикселей. Отношение дюймов к пикселям?
  7. Разобрался. Спасибо книге от Petzold. Ну и заморочка. Если кто-то так же затрудняется понять, то вот: Окно - это клиентская область приложения, то есть внешний вид программки без рамки и заголовка. Область вывода - тоже клиентская область приложения, то есть внешний вид программки без рамки и заголовка. (Область вывода может быть и клиентской областю с рамкой и заголовком, и даже всем экраном). Разница лишь в том у них, что позиция курсора, например наведенного на какое-нибудь место клиентской области, в случае "Области вывода" измеряется в пикселах, а в случае когда мы говорим и имеем в виду "Окно", то измеряется в логических единицах. А логическая единица может быть равна как одному пикселу, тогда позиции курсора в обоих терминах (Окно и Область вывода) измеряются в пикселах, так и нескольким пикселам, если самому предварительно это определить. Сейчас читаю книгу Щупака, но чувствую теперь, что в книге Petzold материал преподается более подробно и доходчиво. Так что советую книгу Petzold . Хотя я и ту и эту намерен прочитать.
  8. Привет, кто-нибудь, скажите мне, что в GDI подразумевается под Window и Viewport. Под понятиями "Окно" и "Область вывода". Я прочитал в книге Щупака, затем на MSDN, затем на нескольких сайтах, затем у Petzold, сейчас буду у Фень Юань. Не понимаю! Неужели трудно им сказать, к примеру, Окно - это сама программа, ее габариты, а Область вывода - это весь рабочий стол. Также приложить нормальную картинку где это изображено. Нет же, пишут пишут, а толку. Никак не зайдет тема о Режиме отображения и системах координат, с их физическими и логическими единицами. На пальцах так сказать, объясните, что это все. Или на картинке, где это все обозначается.
  9. То что мы используем функции нашей DLL и используем их в чужом адресном пространстве, - это понятно. Для того собственно мы их и пишем, чтобы их использовать. Мне не понятно как происходит взаимодействие инструкций игры с функциями в библиотеке. Сам механизм. Вот есть байты DLL в памяти игры, мы их туда загрузили, (по сути просто скопировали, как я понимаю). Есть также байты инструкций игры. И то и это представляют из себя функции. Как же теперь оживить нашу DLL? Что нужно сделать чтобы функции в DLL заработали, и заработали каждая для своей определенной игровой функции/инструкции. Я смотрел у тебя в профиле, видел только трейнеры. С удовольствием и интересом посмотрю.
  10. Я полагал что загрузка DLL - это простое копирование её байт в память игры. Затем навешивание каким-то образом потоков на нее. Также связывание определенных инструкций игры с определенными функциями в DLL. А в функциях DLL идет каким-то образом получение значений из регистров, с дальнейшим их использованием и применением обратно. Вот мое представление об схеме работы internal чита, при DLL. Моя картина в голове. Говорю же, мне нужно общее представление об ее работе, на пальцах так сказать. Я же понятия не имею, как там все устроено.
  11. Посмотрю сейчас. Размер шрифта в первом видео, где стрим, для меня самый комфортный. Ни мелкий, ни крупный, самое-то. Я посмотрел твои трейнеры, - у тебя DLL отдельно от файла EXE. Не пробовал помещать DLL в ресурсы EXE, а затем просто оттуда считывать её байты в память игры? Поделись источниками, в которых есть что-нибудь действительно полезное про DLL и хуки. Для меня самое сложное в изучении программирования, - это найти нормальный источник. Где нет "воды", где не обсасывают одну мысль десять минут, где автор действительно объясняет, а не показывает лишь то что он это знает и умеет. Таких пруд пруди в инете. И ты сидишь и тратишь время, как идиот. Книги, ясное дело, самый лучший вариант. Я и намеревался почитать про DLL. Но сперва хотел понять общую картину.
  12. Привет всем, Вчера смотрел видео на канале Gamehacklab. Про написание трейнера на С++. (Замечательное видео, за исключением того что Автор зачем то в последствии уменьшил шрифт. Тяжело стало смотреть, у меня же зрение не очень. Но ничего, досмотрел. Вообще, не понимаю авторов подобных роликов, ну неужели не понимают они что тяжело людям смотреть. Выставят мизерный шрифт и давай записывать.) В видео, @Xipho выделил память и записал уже готовые байты новой и старой инструкции. Это понятно. Но в видео ничего не говорится к сожалению про метод "internal" чит. Так как тема на "external". Подскажите, какова общая схема создания и использования трейнера/приложения, который работает по средствам написанной dll. Как перенаправить потоки от оригинальных инструкций в соответствующие им функции в dll. Как получить данные из регистров и использовать их опять же в функциях dll. Есть ли разница в получении данных из регистров в 32 и 64 битных версиях. Хочу иметь общее представление, общую картину, план, как это реализовывается. Можно ли например написать DLL в которой будет основной код для инструкций игры, а также код для создания окна, кнопочек, менюшек, в общем разных контролов, затем написать небольшой EXE, в ресурсах которого будет эта DLL. То есть приложение/трейнер будет состоять всего из EXE файла, внутри которого будет нужная DLL. Затем, при запуске EXE, методом описанным в самой этой EXE, берется из ресурсов DLL, копируется напрямую в память игры, делаются хуки, и готово. Создается наверно отдельный поток на управление окном и контролами. В общем вопросы может быть глупые, но у меня пока просто нет понимания общей картины. Мне бы только понять план, о мелочах я читаю на MSDN.
  13. Я в свое время делал что-то подобное. Мне нужно было сохранить часть выделенной памяти в СЕ в файл в момент выполнения определенной игровой инструкции. Делал я это используя WinApi. Игра была 64 битная, поэтому было достаточно просто. Вот большая часть кода. Я не помню сейчас уже что там и к чему в точности. Не хочется вспоминать. Но из некоторых комментарием должно быть понятно. Есть еще часть скрипта для считывания данных из файла в память, но она здесь не нужна. Как написал @Xipho, нужно лишь прочитать про соглашения, про правила передачи аргументов.
  14. fbstp как раз таки преобразовывает Hex в String. Мне нужно наоборот, - String в Hex. Hex в String String в Hex Разобрался почему не работал способ с fbld. Нужно было перед инструкцией обнулить значение следующего адреса. Спасибо @Xipho за наводку. Вызов Atoi работает как надо Также в том первом способе что я написал выше, ошибка была в том, что нужно было умножать не на 10, а на 0A
×
×
  • Создать...

Важная информация

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