[PATCH] gdi32: Add DECLSPEC_HOTPATCH to GetDIBits

Zebediah Figura z.figura12 at gmail.com
Sun Jul 1 03:07:16 CDT 2018


On 30/06/18 11:34, Stefan Dösinger wrote:
> 
> 
>> Am 28.06.2018 um 17:28 schrieb Alex Henrie <alexhenrie24 at gmail.com
>> <mailto:alexhenrie24 at gmail.com>>:
>>
>> Although this patch fixes the bug in question, Zeb and I would like to
>> know: Since all exported Windows API functions support hotpatching,[1]
>> why do we add __attribute__((__ms_hook_prologue__)) attribute to
>> functions ad hoc instead of making it part of the definitions of
>> __stdcall and __cdecl in windef.h?
> Alex asked me at Wineconf to comment on this.
> 
> When I added __ms_hook_prologue__ to gcc a long time ago we did not
> anticipate a high number of functions to need it. In 32 bit x86 code it
> adds minor overhead - there is a 2 byte nop at the start of every
> function that uses it. Having it on all functions was considered
> unnecessary and wasteful. On x64 this nop is 8 bytes long.
> 
> At the time I worked on this Windows only made regular exported
> functions hotpatchable (what we have in our .spec files), but not e.g.
> COM methods. But Windows applications hook COM methods too, we wanted to
> be able to make static functions hotpatchable. On Windows this is a
> compiler
> option: https://docs.microsoft.com/en-us/cpp/build/reference/hotpatch-create-hotpatchable-image .
> Doing the same thing would not work for us because we still have to make
> sure that e.g. IDirect3DDevice9::Present does not contain code that
> Steam et all cannot handle.
> 

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? In the
latter case presumably we'd be adding it to the definition of __stdcall,
so that declaration would be carried through to the requisite WINAPI
flag. In the former case, firstly, 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?



More information about the wine-devel mailing list