March 2023 - wine-gitlab

[PATCH 0/1] MR2266: makedep: Support resource files for embedded TESTDLL.
by Rémi Bernon (＠rbernon) 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

3 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 (＠rbernon) 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

3 7

[PATCH v2 0/5] MR2298: winewinrt: Introduce new WinRT common module.
by Rémi Bernon (＠rbernon) 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

5 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

[PATCH v4 0/1] MR2306: msado15: Implement _Recordset Open
by Alistair Leslie-Hughes (＠alesliehughes) 07 Mar '23

07 Mar '23

-- v4: msado15: Implement _Recordset Open https://gitlab.winehq.org/wine/wine/-/merge_requests/2306

2 1

[PATCH 0/1] MR2346: winsqlite3: Add stub DLL.
by Tareque Md Hanif (＠tmdh) 07 Mar '23

07 Mar '23

Required to run winget package manager. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2346

2 1

Re: [PATCH v3 0/8] MR2292: windows.perception.stub: Implement ISpatialSurfaceObserverStatics2::IsSupported() - approved
by Alexandre Julliard (＠julliard) 07 Mar '23

07 Mar '23

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2292

1 0

Re: [PATCH v2 0/1] MR2339: t2embed/tests: Fix the TTGetEmbeddingType() test in UTF-8 locales. - approved
by Alexandre Julliard (＠julliard) 07 Mar '23

07 Mar '23

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2339

1 0

Re: [PATCH v2 0/1] MR2338: maintainers: Assume maintainership of IME support. - approved
by Alexandre Julliard (＠julliard) 07 Mar '23

07 Mar '23

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2338

1 0

2025

2024

2023

2022

wine-gitlab March 2023