[PATCH 2/2] kernel32: resource: Changed QUEUEDUPDATES to match MS offset

[Nikolay Sivov]

On 07/09/2018 07:51 AM, Jon Doron wrote:

> The utility muirct.exe for some reason accesses the opaque
> HANDLE that is returned by BeginUpdateResource, it assumes
> a certain structure in which (on 32bit systems) there is a
> pointer to the wide repesentation of the file name in offset
> 0x18.
>
> Refer to: muirct!BldToolsEndUpdateResourceW called from
> muirct!CopyChecksumToFile
>
> Sample execution:
> MUIRCT.EXE -c "ui.exe" -e "de-DE\ui.exe.mui"
> ---
>   dlls/kernel32/resource.c | 7 ++++++-
>   1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/dlls/kernel32/resource.c b/dlls/kernel32/resource.c
> index 73f3cca363..c5f2d79db0 100644
> --- a/dlls/kernel32/resource.c
> +++ b/dlls/kernel32/resource.c
> @@ -635,7 +635,12 @@ DWORD WINAPI SizeofResource( HINSTANCE hModule, HRSRC hRsrc )
>   
>   typedef struct
>   {
> -    LPWSTR pFileName;
> +#ifdef _WIN64
> +    UCHAR Reserved[0x30];
> +#else
> +    UCHAR Reserved[0x18];
> +#endif
> +    LPWSTR pFileName;       // Must be in offset 0x18 on 32bit and 0x30 on 64bit
>       BOOL bDeleteExistingResources;
>       struct list root;
>   } QUEUEDUPDATES;
It'd be cleaner to use pointer-sized fields here.

More importantly, patch 1/2 will introduce failing tests, that normally 
should be marked with todo_wine, and you'd remove such marks in patch 2/2.
In this case it's easier to simply send patches in opposite order, 
because failing test will be reading fields from incompatible data 
structure.