Пытаюсь понять код user32.dll и gdi32.dll

[Beermonza]

Дело в том, что эта gdi32.dll - одна большая портянка со скачками, чтобы выполнить что-то приходится скакать по всему коду библиотеки. Так от того, что эта штука универсальная, и должна предоставлять пользователю всё разнообразие результатов, от тех параметров, что он вводит. Мне же не требуется проверок на выводимый результат. Нужно передать данные 1 в 1, ...отпадает пара-тройка скачков. Далее, мне не нужно проверять правильно ли я взял контекст, поскольку я его взял правильным образом из той же GetDC, она берется один раз в начале работы с окном, и потом с закрытием контекст освобождается, это прописано в документации, ...следовательно, еще парочка прыжков убирается. Но прыжки не простые, в их частях еще проверки и прыжки на все случаи жизни "если то, да сё", ...а если уже один с флагом SRCCOPY отпал, то и ч по ссылке ниже и следующие прыжки тоже, а их там 23 штуки, ...и дальше я сбился со счета. Так же по любой проверке на 1М писанины, и в конце только выполнение в 3 строки. Убираем лишнее - вот он и прирост производительности.

И как он может работать не корректно, если это часть истинной библиотеки, а не самоделка?

Сообщение от Ulex

А как таймер победили?
У меня моя погремушка только один раз отрисовывает и всё.

Сидит код в таймере стандартном TTimer (есть такой в Delphi). На него много нареканий, типа "медленный и быстрее 50 мс ворочиться не желает". Друзья мои, все зависит от быстроты внутреннего кода, если код успевает выполниться за 10 мс, то таймер будет выдавать результат как положено каждые 10 мс. Если код выполняется только за 100 мс, то как не ставь интервал 10 мс, таймер его оттянет до времени, когда внутренний код завершится, ...в том и его плюс, сбоя не будет как с точным таймером.

[Ulex]

А, ну вот, у меня такой вариант заработал:

	xor	eax, eax
	push	eax
	push	-1
	push	00CC0020h
	push	eax
	push	eax
	push	[hCpbltDCTempLOC]
	push	[sizeYclient]
	push	[sizeXclient]
	push	eax
	push	eax
	push	[hDC]
	call	to_sysenter
	jmp	end_sysenter
to_sysenter:
	mov	eax,100Dh          
	mov	edx,7FFE0300h      
	call	dword ptr [edx]    
end_sysenter:

Особенного роста производительности не заметил. Почему то загрузка проца болтается сильно. Сейчас потестил ещё, нет у меня никакой разницы против SetDIBitsToDevice. И в том и в другом случае где-то от 8-20 процентов.

И как он может работать не корректно, если это часть истинной библиотеки, а не самоделка?

Да очень запросто, сам вывод на экран выполняет системный вызов, вот этот:

mov eax,100Dh
mov edx,7FFE0300h
call dword ptr [edx]

и он не документирован. Товарищи из MS могут его запросто менять в любой удобный для себя момент (собственно это ядро системы). При этом они вам ничего не должны. Есть документированная функция BitBlt - вот результат её работы документирован и поэтому предсказуем. То что вы взяли gdi32 и повторили её код, означает только лишь то, что вы повторили его для ОС WinXP SP3 (в моём случае). Но это совершенно не означает, что код библиотеки не меняется от версии к версии ОС Win.
Вобщем - это уже самоделка.

[JTG]

Вот-вот. Номера системных вызовов отличаются даже в разных билдах одной версии ОС, не говоря уже о разных версиях.

0x119f
Windows XP SP1/2/3 - NtUserGetKeyNameText
Windows Server 2003 SP1/2 - NtUserGetKeyState
Windows Vista SP1/2 - NtUserGetDC
Windows 7 - NtUserGetControlBrush

0x100D
Windows 2000 SP2 ~ Windows Server 2008 SP1 - NtGdiBitBlt
Windows 7 - NtGdiBeginPath

http://j00ru.vexillium.org/win32k_syscalls/

[Beermonza]

Я этого просто не знал. Могу сделать пример и отправить всем на проверку.