May 2025 - Wine-Devel - list.winehq.org

Re: IRandomAccessStream doesn't belong in windows.storage

by Nikolay Sivov

On Wed, May 21, 2025 at 10:37 AM light gray <tpapata1386(a)gmail.com> wrote: > That's quite puzzling because in W11 24H2 it's shcore.dll instead. > [image: image.png] > Even if W10 22H2 has it as `windows.storage.dll` I think it's still better > to implement it in shcore.dll instead because of the > `CreateRandomAccessStream..` functions. > Once we need those functions I think we could move it, to be able to create this object directly or through activation. But if we don't need them, it doesn't matter where it is. > > On Wed, 21 May 2025 at 11:56, Rémi Bernon <rbernon(a)codeweavers.com> wrote: > >> On 5/21/25 10:18, light gray wrote: >> > Hi devs! >> > >> > I've recently noticed that there's a new `windows.storage` WinRT library >> > within Wine, and the library houses a stubbed implementation for >> > `IRandomAccessStream`. >> > There's an issue however. Looking at Windows registry keys to see which >> > libraries register which runtime classes, it appears `shcore` houses the >> > implementation for `IRandomAccessStream`. Not `windows.storage`. >> > While inherently this isn't a problem since applications acquire runtime >> > classes via `RoGetActivationFactory`, this could pose an issue later >> down >> > the line when more WinRT interfaces get implemented within Wine. Mainly >> > with how different classes are registered at compile time. Not only >> that, >> > it would also make implementing functions such as >> > `CreateRandomAccessStreamOnFile` a bit more complicated. >> > As a reference, the following is my own experimental implementation of >> > `IRandomAccessStream`: >> > >> https://github.com/Weather-OS/WineCoreUAP/commit/318d3b8ecb036f04dcf6365235… >> > >> > Best wishes, Weather. >> > >> >> In the Windows version I have been checking with (W10 22H2 or something >> like that), Windows.Storage.Streams.RandomAccessStream runtime class is >> registered from windows.storage.dll. >> >> There has been other instances where the classes are moved around, I >> think we can assume it does not really matter. >> >> -- >> Rémi Bernon <rbernon(a)codeweavers.com> >> >> >> > >

May 21, 2025

Re: IRandomAccessStream doesn't belong in windows.storage

by light gray

That's quite puzzling because in W11 24H2 it's shcore.dll instead. [image: image.png] Even if W10 22H2 has it as `windows.storage.dll` I think it's still better to implement it in shcore.dll instead because of the `CreateRandomAccessStream..` functions. On Wed, 21 May 2025 at 11:56, Rémi Bernon <rbernon(a)codeweavers.com> wrote: > On 5/21/25 10:18, light gray wrote: > > Hi devs! > > > > I've recently noticed that there's a new `windows.storage` WinRT library > > within Wine, and the library houses a stubbed implementation for > > `IRandomAccessStream`. > > There's an issue however. Looking at Windows registry keys to see which > > libraries register which runtime classes, it appears `shcore` houses the > > implementation for `IRandomAccessStream`. Not `windows.storage`. > > While inherently this isn't a problem since applications acquire runtime > > classes via `RoGetActivationFactory`, this could pose an issue later down > > the line when more WinRT interfaces get implemented within Wine. Mainly > > with how different classes are registered at compile time. Not only that, > > it would also make implementing functions such as > > `CreateRandomAccessStreamOnFile` a bit more complicated. > > As a reference, the following is my own experimental implementation of > > `IRandomAccessStream`: > > > https://github.com/Weather-OS/WineCoreUAP/commit/318d3b8ecb036f04dcf6365235… > > > > Best wishes, Weather. > > > > In the Windows version I have been checking with (W10 22H2 or something > like that), Windows.Storage.Streams.RandomAccessStream runtime class is > registered from windows.storage.dll. > > There has been other instances where the classes are moved around, I > think we can assume it does not really matter. > > -- > Rémi Bernon <rbernon(a)codeweavers.com> > > >

May 21, 2025

Re: IRandomAccessStream doesn't belong in windows.storage

by Rémi Bernon

On 5/21/25 10:18, light gray wrote: > Hi devs! > > I've recently noticed that there's a new `windows.storage` WinRT library > within Wine, and the library houses a stubbed implementation for > `IRandomAccessStream`. > There's an issue however. Looking at Windows registry keys to see which > libraries register which runtime classes, it appears `shcore` houses the > implementation for `IRandomAccessStream`. Not `windows.storage`. > While inherently this isn't a problem since applications acquire runtime > classes via `RoGetActivationFactory`, this could pose an issue later down > the line when more WinRT interfaces get implemented within Wine. Mainly > with how different classes are registered at compile time. Not only that, > it would also make implementing functions such as > `CreateRandomAccessStreamOnFile` a bit more complicated. > As a reference, the following is my own experimental implementation of > `IRandomAccessStream`: > https://github.com/Weather-OS/WineCoreUAP/commit/318d3b8ecb036f04dcf6365235… > > Best wishes, Weather. > In the Windows version I have been checking with (W10 22H2 or something like that), Windows.Storage.Streams.RandomAccessStream runtime class is registered from windows.storage.dll. There has been other instances where the classes are moved around, I think we can assume it does not really matter. -- Rémi Bernon <rbernon(a)codeweavers.com>

May 21, 2025

IRandomAccessStream doesn't belong in windows.storage

by light gray

Hi devs! I've recently noticed that there's a new `windows.storage` WinRT library within Wine, and the library houses a stubbed implementation for `IRandomAccessStream`. There's an issue however. Looking at Windows registry keys to see which libraries register which runtime classes, it appears `shcore` houses the implementation for `IRandomAccessStream`. Not `windows.storage`. While inherently this isn't a problem since applications acquire runtime classes via `RoGetActivationFactory`, this could pose an issue later down the line when more WinRT interfaces get implemented within Wine. Mainly with how different classes are registered at compile time. Not only that, it would also make implementing functions such as `CreateRandomAccessStreamOnFile` a bit more complicated. As a reference, the following is my own experimental implementation of `IRandomAccessStream`: https://github.com/Weather-OS/WineCoreUAP/commit/318d3b8ecb036f04dcf6365235… Best wishes, Weather.

May 21, 2025

Re: irc.libera.chat ?

by zhengxianwei

Thank you for helping me understand the difference between a mailing list and IRC On Sun, May 18, 2025 at 5:31 PM Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > Hi, > > > Am 17.05.2025 um 13:54 schrieb zhengxianwei <baikaishiuc(a)gmail.com>: > > > > May I ask, what's the difference between asking questions on > irc.libera.chat and asking here? > > > > Will this place gradually be phased out, with activity gradually > shifting over there? > > Both of them are valid and both of them will exist in the future. > > IRC is a more real-time communication system. If you are lucky, and a > person who can answer your questions is sitting at their computer, it is > easy to have a quick back and forth communication. On the other hand, in > plain IRC you don't see messages that are sent while you are offline (*). > > Mails to the mailing list are stored and delivered later, so someone who > is currently on vacation can see it in 3 weeks. > > Both have their place, and will continue to be used by the Wine project. > Although I must admit I look less and less at IRC messages, in particular > since my employer switched its internal communications to Matrix. Now my > IRC client is an extra program I have to start up and often forget about. > > I hope this provides some clarification. > > Cheers, > Stefan > > (*): There are separate tools like ZNC that can store IRC messages for you > while your computer is off, but they need separate setup. > > > >

May 19, 2025

Re: How to use AddressSanitizer with Wine? (80% PE approach)

by Bernhard Übelacker

Am 06.05.25 um 14:49 schrieb Bernhard Übelacker: > Am 28.04.25 um 06:44 schrieb Alex Henrie: >> On Sat, Apr 26, 2025 at 4:36 PM Bernhard Übelacker >> <bernhardu(a)mailbox.org> wrote: >> >>> For enabling ASan(PE) I collected some "notes to myself", which I hope >>> are enough accurate to enable someone else to reproduce the results. >> >>> [6] https://gitlab.winehq.org/bernhardu/wine/-/blob/asan- >>> pe_2025-04-05_wine-10.6/README-ASan.md?ref_type=heads >> >> Thank you for sharing! Goodness, it's a lot more complicated than I >> had hoped. Notwithstanding the difficulty, following your instructions >> closely I was able to build and run Wine with the llvm-mingw AUR >> package.[1] My LLVM variables look like this: >> >> export LLVM_INST_PATH=/opt/llvm-mingw >> export x86_64_LLVM_CLANG_RT_LIB=$(find $LLVM_INST_PATH -name >> libclang_rt.asan_dynamic-x86_64.dll.a) >> export i386_LLVM_CLANG_RT_LIB=$(find $LLVM_INST_PATH -name >> libclang_rt.asan_dynamic-i386.dll.a) >> >> For my own sanity, I created scripts named configure64.sh, build64.sh, >> configure32.sh, build32.sh, and run.sh for the various steps of the >> instructions. I think it would be a lot easier to use your ASan branch >> if the commands were already in scripts. >> >>> Unfortunately I have one patch with LLVM still in progress, >>> therefore a self-built LLVM would be needed, to build wine. >>> But this is just needed for HEAP_REALLOC_IN_PLACE_ONLY re-allocations, >>> and running with "windows_hook_rtl_allocators=0" should not be >>> affected by this, >>> and that way building wine from the plain nightly llvm-mingw package >>> should work. >> >> Could you note that in the README please? Upstream llvm-mingw combined >> with windows_hook_rtl_allocators=1 resulted in the cryptic error >> "wine: could not load kernel32.dll, status c0000135" when trying to >> initialize and use the Wine prefix. >> >> I ran a few parts of the Wine test suite and I've submitted my first >> patch based on the results.[2] Furthermore, since the instructions in >> the wiki were outdated and nonfunctional, I've replaced them with a >> link to your repository.[3] Thanks very much for all the work you put >> into it! >> >> -Alex >> >> [1] https://aur.archlinux.org/packages/llvm-mingw >> [2] https://gitlab.winehq.org/wine/wine/-/merge_requests/7925 >> [3] https://gitlab.winehq.org/wine/wine/-/wikis/Building-Wine#memory-- >> address-checkers > > > Hello Alex, > thanks for testing and fixing found issues. > I missed also in the readme I am using currently a new-style-wow64 > configure. > Unfortunately I did not get around to put those parts into scripts. > However, I rebased to current release > and new test runs are in the asan_reports_x86(_64) subdirectories. > > https://gitlab.winehq.org/bernhardu/wine/-/tree/asan- > pe_2025-04-26_wine-10.7?ref_type=heads > > Kind regards, > Bernhard Hello, I rebased the current state of the this ASan experiment here [1]. Results of running the conformance tests can be found in [2] [3]. [1] https://gitlab.winehq.org/bernhardu/wine/-/tree/asan-pe_2025-05-06_wine-10.… [2] https://gitlab.winehq.org/bernhardu/wine/-/tree/asan-pe_2025-05-06_wine-10.… [3] https://gitlab.winehq.org/bernhardu/wine/-/tree/asan-pe_2025-05-06_wine-10.… Kind regards, Bernhard

May 18, 2025

Re: irc.libera.chat ?

by Stefan Dösinger

Hi, > Am 17.05.2025 um 13:54 schrieb zhengxianwei <baikaishiuc(a)gmail.com>: > > May I ask, what's the difference between asking questions on irc.libera.chat and asking here? > > Will this place gradually be phased out, with activity gradually shifting over there? Both of them are valid and both of them will exist in the future. IRC is a more real-time communication system. If you are lucky, and a person who can answer your questions is sitting at their computer, it is easy to have a quick back and forth communication. On the other hand, in plain IRC you don't see messages that are sent while you are offline (*). Mails to the mailing list are stored and delivered later, so someone who is currently on vacation can see it in 3 weeks. Both have their place, and will continue to be used by the Wine project. Although I must admit I look less and less at IRC messages, in particular since my employer switched its internal communications to Matrix. Now my IRC client is an extra program I have to start up and often forget about. I hope this provides some clarification. Cheers, Stefan (*): There are separate tools like ZNC that can store IRC messages for you while your computer is off, but they need separate setup.

May 18, 2025

Re: How to add multiple versions of the same DLL (with the same base name) in apisetschema.spec?

by zhengxianwei

Fixed! Cool, Thanks On Sat, May 17, 2025 at 9:48 PM Alexandre Julliard <julliard(a)winehq.org> wrote: > zhengxianwei <baikaishiuc(a)gmail.com> writes: > > > Hello, > > > > I'm planning to add the following line to apisetschema.spec: > > > > api-ms-win-power-setting-l1-1-1 = powrprof.dll > > > > However, this causes a hash conflict with the existing line: > > > > apiset api-ms-win-power-setting-l1-1-0 = powrprof.dll > > > > May I ask how you usually resolve such conflicts? > > The last version number is ignored, l1-1-0 and l1-1-1 mean exactly the > same thing, you don't need to change anything. > > -- > Alexandre Julliard > julliard(a)winehq.org >

May 18, 2025

Wine staging 10.8 release

by Alistair Leslie-Hughes

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 10.8 (344 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * odbc32: SQLColAttributesW accept field id SQL_COLUMN_NAME. Removed (No longer required). * None Added: * None Updated: * vkd3d-latest * odbc32-fixes Where can you help * Run Steam/Battle.net/GOG/UPlay/Epic * Test your favorite game. * Test your favorite applications. * Improve staging patches and get them accepted upstream. * Suggest patches to be included in staging. As always, if you find a bug, please report it via https://bugs.winehq.org Best Regards Alistair.

May 17, 2025

Re: How to add multiple versions of the same DLL (with the same base name) in apisetschema.spec?

by Alexandre Julliard

zhengxianwei <baikaishiuc(a)gmail.com> writes: > Hello, > > I'm planning to add the following line to apisetschema.spec: > > api-ms-win-power-setting-l1-1-1 = powrprof.dll > > However, this causes a hash conflict with the existing line: > > apiset api-ms-win-power-setting-l1-1-0 = powrprof.dll > > May I ask how you usually resolve such conflicts? The last version number is ignored, l1-1-0 and l1-1-1 mean exactly the same thing, you don't need to change anything. -- Alexandre Julliard julliard(a)winehq.org

May 17, 2025