[PATCH] gdi32: Add DECLSPEC_HOTPATCH to GetDIBits

[Stefan Dösinger]

Am 2018-07-01 um 10:07 schrieb Zebediah Figura:
> Sorry, I'm confused. Is the issue that static (COM) methods are
> hotpatchable and shouldn't be, or that they aren't and should be?
When I implemented this in 2009 Microsoft did not make them
hotpatchable. We decided we want to do be able to make them hotpatchable
though.

Windows applications that hotpatch 32 bit code need to be able to
process code that is different from the standard "8b-ff 55 8b-ec"
instruction sequence, or at least used to in 2009. Windows before XP
Service Pack 2 did not have the 2 byte NOP. This is why some apps
hotpatch functions without DECLSPEC_HOTPATCH successfully sometimes. But
because there are many, many possible opcodes, no Windows application
will handle all possible code that is out there.

> are there really applications that
> choke on "mov %edi,%edi", and, secondly, since GCC currently has freedom
> to put whatever it wants to there (like the PC thunk) wouldn't we need
> some way to guarantee it's compatible anyway?
I don't know anything that chokes on the mov edi, edi (8b ff). This is
why we had no problem with using DECLSPEC_HOTPATCH for things that are
not technically hotpatchable on Windows. Eliminating everything Steam et
all don't understand is hard (we don't know what it understands and what
it doesn't), so putting something there that it understands is a way
easier solution - even if we know that it technically incorrect.

(There are "easier" ways to hook COM methods than hotpatching bytecode -
create a proxy object, replace the vtable in the object, overwrite the
function pointer in the vtable. Afaik no Windows application goes that
route though)

I still think adding a 2 byte (or 8 byte) NOP to every WINAPI or CDECL
function is wasteful.