IRandomAccessStream doesn't belong in windows.storage
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/318d3b8ecb036f04dcf6365235a... Best wishes, Weather.
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/318d3b8ecb036f04dcf6365235a...
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>
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/318d3b8ecb036f04dcf6365235a...
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>
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/318d3b8ecb036f04dcf6365235a...
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>
participants (3)
-
light gray -
Nikolay Sivov -
Rémi Bernon