Существует несколько подходов к этой проблеме. Большинство из них icky, и это полностью зависит от того, какой графический API вы хотите настроить, и какие функции использует целевое приложение. Большинство приложений DirectX, GDI + и OpenGL имеют двойной или триплексный буферизатор, поэтому в какой-то момент они все звонят:

void SwapBuffers(HDC hdc)

. Они также генерируют сообщения WM_PAINT в очереди сообщений, когда окно должно быть нарисовано. Это дает вам два варианта.

• Вы можете установить глобальный крючок или привязку к потоку в целевой процесс и захватить сообщения WM_PAINT. Это позволяет скопировать содержимое из контекста устройства непосредственно перед началом картины. Процесс можно найти, перечислив все процессы в системе и найдите известное имя окна или известный дескриптор модуля.
• Вы можете ввести код в локальную копию SwapBuffers в целевом процессе. В Linux это было бы легко сделать с помощью переменной окружения LD_PRELOAD или явно вызовом ld-linux.so.2, но в Windows нет эквивалента. К счастью, у Microsoft Research есть основа, которая может сделать это для вас по имени Detours. Вы можете найти это здесь: link .

Демосценовая группа Farbrausch сделала демонстрационный инструмент с именем kkapture, который использует библиотеку Detours. Их инструмент предназначен для приложений, которые не требуют ввода пользователя, поэтому они в основном запускают демонстрации с фиксированной частотой кадров, подключая все возможные функции времени, такие как timeGetTime (), GetTickCount () и QueryPerformanceCounter (). Это полностью рад. Вы можете найти презентацию, написанную ryg (я думаю?) Относительно внутренних элементов kkapture здесь . Я думаю, что это вас интересует.

Для получения дополнительной информации о крючках Windows см. Здесь здесь и здесь .

EDIT:

Эта идея заинтриговала меня, поэтому я использовал Detours для подключения к приложениям OpenGL и беспорядка с графикой. Здесь добавлен Quake 2 с зеленым туманом: [/g6]

Дополнительная информация о том, как работает Detours, так как я использовал его из первых рук:

на двух уровнях. Фактический захват работает только в том же пространстве процесса, что и целевой процесс. Таким образом, у Detours есть функция для инъекции DLL в процесс и принудительного запуска DLLMain, а также функций, которые предполагается использовать в этой DLL. Когда DLLMain запущен, DLL должна вызывать DetourAttach (), чтобы указать функции для перехвата, а также функцию «обход», которая является кодом, который вы хотите переопределить.

Таким образом, он в основном работает как это:

• У вас есть приложение для запуска, единственной задачей которого является вызов DetourCreateProcessWithDll (). Он работает так же, как и CreateProcessW, только с несколькими дополнительными параметрами. Это вставляет DLL в процесс и вызывает его DllMain ().
• Вы реализуете DLL, которая вызывает функции Detour и настраивает функции батута. Это означает вызов DetourTransactionBegin (), DetourUpdateThread (), DetourAttach (), за которым следует DetourTransactionEnd ().
• Используйте программу запуска, чтобы внедрить DLL, которую вы внедрили в процесс.

Однако есть некоторые оговорки. Когда DllMain запущен, библиотеки, которые позже импортируются с помощью LoadLibrary (), пока не отображаются. Поэтому вы не можете настроить все во время события вложения DLL. Обходной путь заключается в том, чтобы отслеживать все функции, которые были переопределены до сих пор, и попытаться инициализировать другие внутри этих функций, которые вы уже можете вызвать. Таким образом, вы обнаружите новые функции, как только LoadLibrary отобразит их в пространство памяти процесса. Я не совсем уверен, насколько хорошо это работает для wglGetProcAddress. (Возможно, у кого-то здесь есть идеи относительно этого?)

Некоторые вызовы LoadLibrary (), похоже, терпят неудачу. Я тестировал с Quake 2, а DirectSound и API waveOut по какой-то причине не удалось инициализировать. Я все еще расследую это.