March 2023 - Wine-gitlab - list.winehq.org

[PATCH v2 0/6] MR2347: Various fixes for dbghelp's ELF integration.
by eric pouech (＠epo) 08 Mar '23

08 Mar '23

This series fixes a couple of issues related to dbghelp lookup in ELF modules: - get the correct wine loader in 64bit multi-arch setup - don't fail in 32bit multi-arch setup when trying to access 64bit ELF modules above 4G - handle libwine.so removal and let vdso lookup work again - adding a couple of tests -- v2: dbghelp: Fix vdso.so lookup. dbghelp: Don't set ELF loader when wine's loader isn't accessible. dbghelp/tests: Add tests for SymRefreshModuleList() on non-live target. dbghelp: Use 'wine' as loader on multi-arch configuration. dbghelp/tests: Preserve last error in process_get_kind(). dbghelp/tests: Better use global variables. https://gitlab.winehq.org/wine/wine/-/merge_requests/2347

2 6

[PATCH v6 0/7] MR2221: imm32/tests: Test ImmInstallIMEW with an actual IME.
by Rémi Bernon 08 Mar '23

08 Mar '23

Redirecting its calls to the test executable for easier testing and to wokaround some Windows IME caching mechanism that prevent the IME module from reloading. -- v6: imm32/tests: Test ImmGetIMEFileName with the installed IME. imm32/tests: Test ImmGetDescription with the installed IME. imm32/tests: Redirect IME function to the main module. imm32/tests: Test ImmInstallIMEW with an actual IME. makedep: Support resource files for embedded TESTDLL. makedep: Rename TESTDLL generated .res to avoid conflicts. imm32/tests: Add broken test results for w10v22H2. https://gitlab.winehq.org/wine/wine/-/merge_requests/2221

1 8

[PATCH 0/5] MR2341: wined3d: move stubs out of state tables
by Max Figura (＠maxfigura) 08 Mar '23

08 Mar '23

Removing WINED3D_RS entries from state tables and moving stubs to wined3d_device_apply_stateblock. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2341

4 7

[PATCH v2 0/2] MR2337: pdh: Implement PdhVbGetDoubleCounterValue().
by Mohamad Al-Jaf (＠maljaf) 08 Mar '23

08 Mar '23

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54618 If the handle passed is `(void *)0xdeadbeef` it crashes in Wine, but not in Windows. I'm guessing this is not very important. -- v2: pdh/tests: Add PdhVbGetDoubleCounterValue() tests. pdh: Implement PdhVbGetDoubleCounterValue(). https://gitlab.winehq.org/wine/wine/-/merge_requests/2337

3 5

[PATCH v5 0/7] MR2221: imm32/tests: Test ImmInstallIMEW with an actual IME.
by Rémi Bernon 08 Mar '23

08 Mar '23

Redirecting its calls to the test executable for easier testing and to wokaround some Windows IME caching mechanism that prevent the IME module from reloading. -- v5: imm32/tests: Test ImmGetIMEFileName with the installed IME. imm32/tests: Test ImmGetDescription with the installed IME. imm32/tests: Redirect IME function to the main module. imm32/tests: Test ImmInstallIMEW with an actual IME. makedep: Support resource files for embedded TESTDLL. makedep: Rename TESTDLL generated .res to avoid conflicts. imm32/tests: Add broken test results for w10v22H2. https://gitlab.winehq.org/wine/wine/-/merge_requests/2221

2 8

[PATCH 0/1] MR2266: makedep: Support resource files for embedded TESTDLL.
by Rémi Bernon 08 Mar '23

08 Mar '23

Split from https://gitlab.winehq.org/wine/wine/-/merge_requests/2221, this would let us customize testdll version info. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2266

2 5

[PATCH 0/6] MR2347: Various fixes for dbghelp's ELF integration.
by eric pouech (＠epo) 08 Mar '23

08 Mar '23

This series fixes a couple of issues related to dbghelp lookup in ELF modules: - get the correct wine loader in 64bit multi-arch setup - don't fail in 32bit multi-arch setup when trying to access 64bit ELF modules above 4G - handle libwine.so removal and let vdso lookup work again - adding a couple of tests -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2347

3 7

[PATCH v4 0/6] MR2221: imm32/tests: Test ImmInstallIMEW with an actual IME.
by Rémi Bernon 08 Mar '23

08 Mar '23

Redirecting its calls to the test executable for easier testing and to wokaround some Windows IME caching mechanism that prevent the IME module from reloading. -- v4: imm32/tests: Test ImmGetIMEFileName with the installed IME. imm32/tests: Test ImmGetDescription with the installed IME. imm32/tests: Redirect IME function to the main module. imm32/tests: Test ImmInstallIMEW with an actual IME. makedep: Support resource files for embedded TESTDLL. imm32/tests: Add broken test results for w10v22H2. https://gitlab.winehq.org/wine/wine/-/merge_requests/2221

2 7

[PATCH v2 0/5] MR2298: winewinrt: Introduce new WinRT common module.
by Rémi Bernon 08 Mar '23

08 Mar '23

The idea I have is to use this module to declare class stubs until there is a good reason to split them to dedicated modules. WinRT modules aren't usually loaded directly, and instead the registry is queried to figure which module to load for which class. This would help avoiding unnecessary proliferation of stub WinRT modules, while at the same time allowing to factor WinRT foundation code (such as vector / async, etc...) between the modules that seem to deserve to be implemented separately. The relevant classes could then be split out to dedicated modules on a as-needed basis, when they get fleshed out. -- v2: winewinrt: Move Vector<HSTRING> from windows.media.speech. windows.media.speech: Use Vector<IInspectable> from winewinrt. winewinrt: Rename Vector<IInspectable> structs and methods. winewinrt: Move Vector<IInspectable> from windows.gaming.input. winewinrt: Introduce new WinRT common module. https://gitlab.winehq.org/wine/wine/-/merge_requests/2298

4 11

Re: [PATCH v3 0/8] MR2292: windows.perception.stub: Implement ISpatialSurfaceObserverStatics2::IsSupported()
by Mohamad Al-Jaf (＠maljaf) 08 Mar '23

08 Mar '23

On Tue Mar 7 07:47:49 2023 +0000, Rémi Bernon wrote: > There's the IDL side and the C implementation side. The `requires` > keyword is only checked and enforced on the IDL side, although I'm not > sure it's even very strict, and it means that if a class declares the > `ISpatialSurfaceObserverStatics2` interface, it needs to declare the > `ISpatialSurfaceObserverStatics` interface too. > On the C side, nothing is enforced, and although you are supposed to > implement the interfaces that were declared in the IDL, it will only be > a problem to not have them when something queries it. Some interfaces > like `IAgileObject` are completely trivial to add, so we usually add > them right away (although I think incorrectly putting them with the > default interface), but otherwise you don't have to implement interfaces > that are never used. > Then, even on the IDL side, declaring an interface doesn't necessarily > mean you need to have its definition either, and a forward declaration > is sometimes enough. You only need the definition for the default > runtimeclass interfaces, as the interface UUID is then required for some > things (I'm not sure anymore about the details). I see, that makes sense, thanks for the thorough explanation. > Then, even on the IDL side, declaring an interface doesn't necessarily mean you need to have its definition either, and a forward declaration is sometimes enough. You only need the definition for the default runtimeclass interfaces, as the interface UUID is then required for some things (I'm not sure anymore about the details). I thought it would be incorrect to add just forward declarations, I wish I knew this earlier. I'm also working on adding the `IHolographicSpace` interface and I'm already done with the headers. I only added the default runtimeclass interfaces, but there were so many dependencies even with just that. I've already added the definitions for them, but now I'm wondering if it was even necessary. It took a significant amount of time too. I'll submit it when I'm done with the implementations. Speaking of which, I'm not sure which functions to implement. It's not clear which one is supposed to be called first by the apps. There are 3, IsConfigured, IsSupported, and IsAvailable. According to Microsoft Learn, IsSupported is always true on 64-bit Windows, but false on 32-bit. > On Desktop PCs running 64-bit Windows, this is always true. If IsAvailable is false because the > user has not yet set up their Mixed Reality headset, calling CreateForCoreWindow anyway will guide them through the setup flow. > > On HoloLens, this is always true. > > On any other system, including Desktop PCs running 32-bit Windows, this is false, as Mixed Reality headsets are not supported on those systems. IsConfigured is also similar: >On Desktop PCs running 64-bit Windows, this is initially false. Once the user has set up Mixed Reality through the Mixed Reality Portal, this becomes true. If this is false, but IsSupported is true, calling CreateForCoreWindow anyway will guide the user through the setup flow. I'm thinking it would be a good idea to implement all 3. What do you think? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2292#note_26370

1 0