C++/CX exposes `IPropertyValue` through `Platform::Details::CreateValue`, which returns a `Platform::Object` (which just seems to be a `IPropertyValue` object + C++ RTTI) containing the boxed value.
Apps don't seem to call `CreateValue` directly with a typecode. The code for boxing values gets generated when a value type gets assigned to a `Platform::Object` variable, as documented [here.](https://learn.microsoft.com/en-us/cpp/extensions/boxing-cpp-componen… The generated code will:
1. Call `__abi_make_type_id` with a `struct __abi_type_descriptor *` value, which is just a typecode + string pair. This returns a `Platform::Type` object.
2. Call `Platform::Type::GetTypeCode` on the returned `Platform::Type` object to get back the typecode.
3. Call `Platform::Details::CreateValue` with the typecode and a pointer to the actual value that needs to be boxed.
Apart from the usual WinRT methods, `Platform::Type` obejcts also impement the `IEquatable` and `IPrintable` interfaces. I don't know what their vtables look like, though.
The `Platform::Type` and `Platform::Object` classes also have associated RTTI (can be demonstrated by calling `__RTtypeid`), which we'll also need to emit at some point in the future.
--
v9: vccorlib140: Use the correct symbol name for InitControlBlock on i386 and arm.
vccorlib140: Implement Platform::Details::CreateValue.
vccorlib140: Add stub for Platform::Details::CreateValue.
vccorlib140: Implement Platform::Type::{Equals, GetTypeCode, ToString, FullName::get}.
vccorlib140: Implement __abi_make_type_id.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8831
C++/CX exposes `IPropertyValue` through `Platform::Details::CreateValue`, which returns a `Platform::Object` (which just seems to be a `IPropertyValue` object + C++ RTTI) containing the boxed value.
Apps don't seem to call `CreateValue` directly with a typecode. The code for boxing values gets generated when a value type gets assigned to a `Platform::Object` variable, as documented [here.](https://learn.microsoft.com/en-us/cpp/extensions/boxing-cpp-componen… The generated code will:
1. Call `__abi_make_type_id` with a `struct __abi_type_descriptor *` value, which is just a typecode + string pair. This returns a `Platform::Type` object.
2. Call `Platform::Type::GetTypeCode` on the returned `Platform::Type` object to get back the typecode.
3. Call `Platform::Details::CreateValue` with the typecode and a pointer to the actual value that needs to be boxed.
Apart from the usual WinRT methods, `Platform::Type` obejcts also impement the `IEquatable` and `IPrintable` interfaces. I don't know what their vtables look like, though.
The `Platform::Type` and `Platform::Object` classes also have associated RTTI (can be demonstrated by calling `__RTtypeid`), which we'll also need to emit at some point in the future.
--
v8: vccorlib140: Use the correct symbol name for InitControlBlock on i386 and arm.
vccorlib140: Implement Platform::Details::CreateValue.
vccorlib140: Add stub for Platform::Details::CreateValue.
vccorlib140: Implement Platform::Type::{Equals, GetTypeCode, ToString, FullName::get}.
vccorlib140: Implement __abi_make_type_id.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8831
`IMap` is implemented on top of a `rb_tree` guarded with an `SRWLOCK`. We need the map to be thread safe as:
* `PropertySet` is marked as `IAgileObject`.
* I plan to use `PropertySet` as the backing store for [`DeviceInformation::Properties`](https://learn.microsoft.com/en-us/uwp/api/windows.devices.enumeration.deviceinformation.properties?view=winrt-26100). These properties can be updated by apps after receiving an [`Updated`](https://learn.microsoft.com/en-us/uwp/api/windows.devices.enumeration.devicewatcher.updated?view=winrt-26100#windows-devices-enumeration-devicewatcher-updated) event from the device watcher with [`DeviceInformation::Update`](https://learn.microsoft.com/en-us/uwp/api/windows.devices.enumeration.deviceinformation.update?view=winrt-26100). The current `DeviceWatcher` implementation dispatches the event delegates for `Update` from a separate thread.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8685
This MR introduces an initial implementation for `ReadPackageFromStream` in order to be able to decompress/read OPC packages, and enumerate their parts.
This is for supporting AppX packages, which themselves are OPC packages as well. As such, the code does not implement support for reading relationships or interleaved archives, as AppX does not support either (`APPX_E_RELATIONSHIPS_NOT_ALLOWED`, `APPX_E_INTERLEAVING_NOT_ALLOWED`).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8837
[Chromium obtains an agile reference](https://source.chromium.org/chromium/chromium/src/+/main:device/… to WinRT activation factories with RoAgileReference. As we currently do not support marshaling WinRT objects, this fails. However, as objects marked with IAgileObject don't need to be marshaled across apartments, we can trivially implement `RoAgileReference` for such objects, as most activation factories tend to be agile.
--
v2: combase: Don't marshal objects that implement IAgileObject in RoGetAgileReference.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8697
Thanks for feedback.
I'll take a closer look at how Carla experimental features work which allow the VST DLLs to be loaded directly.
Maybe yabridge is taking unnecessary control of windowing that Wine may be able to handle internally instead. Carla's VST DLL handler may help clarify where exactly diff occurs.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6569#note_113875
--
v2: d3dx10: Exclusively use shared code for parsing all files in get_image_info().
d3dx10: Add support for d3dx10+ image file formats in shared code.
d3dx10: Exclusively use shared code for parsing DDS files in get_image_info().
d3dx10: Add support for DXGI formats in d3dx_helpers.
d3dx10: Only validate header size for DDS files in d3dx10.
d3dx10: Add support for parsing DXT10 DDS headers to shared code.
d3dx10/tests: Add more DDS file header handling tests.
d3dx10/tests: Add more DDS file DXGI format mapping tests.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8705
It's not really a matter of DLL format or conversion, in both cases the module is run the same way from Wine perspective.
The difference is that when using yabridge, yabridge redirects the X11 window creation and takes the role of the window manager for Wine windows, embedding them inside its own windows that are in turn managed by the host WM. When running the modules directly, the host window manager does everything.
The problems probably come from yabridge behavior as a proxy window manager, how it manage Wine windows positions and and how it translates coordinates back and forth. This is what was improved in the yabridge wine10 branch, but it's still not completely right apparently.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6569#note_113863
C++/CX exposes `IPropertyValue` through `Platform::Details::CreateValue`, which returns a `Platform::Object` (which just seems to be a `IPropertyValue` object + C++ RTTI) containing the boxed value.
Apps don't seem to call `CreateValue` directly with a typecode. The code for boxing values gets generated when a value type gets assigned to a `Platform::Object` variable, as documented [here.](https://learn.microsoft.com/en-us/cpp/extensions/boxing-cpp-componen… The generated code will:
1. Call `__abi_make_type_id` with a `struct __abi_type_descriptor *` value, which is just a typecode + string pair. This returns a `Platform::Type` object.
2. Call `Platform::Type::GetTypeCode` on the returned `Platform::Type` object to get back the typecode.
3. Call `Platform::Details::CreateValue` with the typecode and a pointer to the actual value that needs to be boxed.
Apart from the usual WinRT methods, `Platform::Type` obejcts also impement the `IEquatable` and `IPrintable` interfaces. I don't know what their vtables look like, though.
The `Platform::Type` and `Platform::Object` classes also have associated RTTI (can be demonstrated by calling `__RTtypeid`), which we'll also need to emit at some point in the future.
--
v7: vccorlib140: Use the correct symbol name for InitControlBlock on i386 and arm.
vccorlib140: Implement Platform::Details::CreateValue.
vccorlib140: Add stub for Platform::Details::CreateValue.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8831