http://bugs.winehq.org/show_bug.cgi?id=60346 --- Comment #5 from daoxiang <15959866515@163.com> --- I have the Windows-side results now, measured rather than inferred, and they make this much more concrete. The AUMID path is a dead end: Wine matches Windows there. The window property store does not. Measured on native Windows using GitHub Actions `windows-latest`, with both MSVC and MinGW builds producing the same result, a window with no AppUserModelID set gives: ``` GetValue -> S_OK, *var initialised to VT_EMPTY GetCount -> E_FAIL, *count set to 0 GetAt -> E_FAIL, *key left untouched ``` As a control, after setting a property on the same store, `GetValue` retrieves it (`S_FALSE` in this test, with the value populated). So the store itself is usable; the results above are the behaviour for an absent property. Wine currently returns `E_NOTIMPL` from all three methods and leaves the output untouched. So there are two differences: the HRESULTs and, for `GetValue` and `GetCount`, the output values. The attached patch changes them to match the Windows results: ``` GetCount: *count = 0; return E_FAIL; GetAt: return E_FAIL; GetValue: PropVariantInit(var); return S_OK; ``` The test program used for this (`verify-windows.c`) and its output are attached. It is a plain Win32 program. With MSVC: ``` cl /D_WIN32_WINNT=0x0601 verify-windows.c /link shell32.lib ole32.lib propsys.lib uuid.lib user32.lib ``` or with MinGW: ``` x86_64-w64-mingw32-gcc -O2 -o verify-windows.exe verify-windows.c -lshell32 -lole32 -luuid ``` Running it on Windows prints the results above. Two corrections to my earlier comments: * I suggested following up on an AUMID gap because `GetCurrentApplicationUserModelId` still returns `APPMODEL_ERROR_NO_APPLICATION` after `SetCurrentProcessExplicitAppUserModelID` succeeds. I checked this on Windows, and Windows does the same thing for this classic Win32 process. Wine therefore matches the behaviour I was trying to fix, so I am not proposing any change there. * My first patch initialised the `PROPVARIANT` but still returned `E_NOTIMPL`. That was wrong. Windows returns `S_OK` with `VT_EMPTY` when the property is absent. What this still does not show is an application that is visibly broken by the difference. The original caller I found, NetEase UU Remote, checks the failure and continues normally. So the case for this patch is the Windows/Wine behavioural difference itself, not a known application regression. If that is not enough reason to implement these methods, that's fair. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.