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.