The cast there seems safe from looking at the struct definitions, and is also used elsewhere in the codebase (dlls/kernelbase/locale.c:5682).
It's obviously not a full implementation, but works well enough for my usecase and maybe others as well.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4851
Fixes balloon tooltips so that they can be drawn outside of the work area (required for system tray icons) and improves the shape of the tooltips so that they resemble their shape on Windows.
--
v4: Diff reduce
https://gitlab.winehq.org/wine/wine/-/merge_requests/3547
This MR uses the existing compositor side surface scaling in the driver (through wp_viewporter, currently used for Hi-DPI scaling) to emulate display mode changes. This works wonderfully in coordination with fullscreen since the compositor is required non only to scale the surface, but also to position it properly and provide opaque surroundings (note: some compositors don't implement the last two features properly!).
Since: 1. Wayland doesn't allow clients to change the actual display configuration, and 2. there is no queryable service that holds the display information in a consistent manner (à la xrandr), the MR uses the win32 device settings as the source of truth for the current display mode. We let win32u handle the display mode change in the default manner (i.e., just updating the registry settings), and provide access to the current mode when updating the display devices through a new `gdi_display_manager.get_adapter()` function.
In order to be able to consistently (across all processes) associate an adapter device with its corresponding `wl_output` the MR introduces per-adapter driver data.
Note for people trying this out: many modern games don't change the hardware display settings, but rather scale themselves in right way to achieve the visual effect of a mode change (similarly to how this MR works, but they do it on the application side). To exercise most of the functionality in this MR you need an application that actually uses the `ChangeDisplaySettings` win32 API.
Thanks!
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4947
Added suppot for DXGI_FORMAT_R8G8B8A8_UNORM to d2d_wic_render_target_init. For further testing i can provide and .exe that renders a red circle over a blue background.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5925
I haven't seen any software that uses this, but some older software out there might use it, so it's good idea to export it.
--
v5: ntoskrnl.exe: add KeNumberProcessors export.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1139
Log: get_dc_attr always failed for meta dc,so GdiGetCodePage always
return CP_ACP. And GetTextCharset is similar to this situation.
Finally, leading to an error result of text_mbtowc call by ExtTextOutA
and an error result of METADC_ExtTextOut.
Signed-off-by: chenjiangyi <chenjiangyi(a)uniontech.com>
Change-Id: Icb6a8d57848935bc5c1b3913c155148af43eca0d
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6385
Overriding the SDL_VIDEODRIVER variable (for Wayland support as an example)
on the Linux side can lead to some games under Wine failing to load (so treat
that variable as special).
--
v6: ntdll: Add SDL audio driver variables to the special variables list.
ntdll: Add SDL video driver variables to the special variables list.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5231
I think it would be very nice to have something like that to reduce the burden of implementing COM interfaces. This shows for instance on the windows.gaming.input module a 30% LoC reduction (from ~6800 to ~4700), even though the module already had a boilerplate helper macros already.
The MR introduces macros to automatically implement each IUnknown method, as well as all of them at once. It also includes a helper to implement IInspectable methods at once, as well as macros to forward both interface methods to a base interface or an outer object. Last, it provides higher-level macros to implement a main interface and any number of sub interfaces and generate IUnknown, forwarding and vtables for all of them at once, with IInspectable support when needed.
It uses widl to generate additional per-interface macros, for things like inheritance and vtable generation. The rest of the macros are otherwise shared in a Wine-specific header.
The implementation is split to show individual macro being used, although they are later replaced by higher-level macros. The individual helpers are still useful in some corner cases where specific behavior needs to be implemented, or for aggregating classes.
--
v3: include: Add a parameter to COM helper END to control QI traces.
windows.gaming.input: Use the new COM macros everywhere possible.
include: Introduce new macros for COM heritage implementation.
widl: Generate some INTERFACE_IMPL/FWD helper macros.
include: Introduce new macros for IInspectable WinRT implementation.
include: Introduce new macros for COM IUnknown implementation.
include: Introduce new macros for COM QueryInterface implementation.
widl: Generate some QUERY_INTERFACE helper macros.
include: Introduce new macros for COM AddRef/Release implementation.
include: Introduce new helper macros for COM implementation.
windows.gaming.input: Use the new INTERFACE_VTBL macros.
widl: Generate some INTERFACE_VTBL helper macros.
windows.gaming.input: Use a separate interface for IAgileObject.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6207