We can't return the unicode string size, this returns sizes to small
for multi-byte characters.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54295
--
v10: userenv: Fix GetProfilesDirectoryA return value
kernel32: Rework ExpandEnvironmentStringsA to return ansi size and fix corner cases.
kernel32: Rework ExpandEnvironmentStringsW error handling.
ntdll: Rework RtlExpandEnvironmentStrings/_U to account for corner cases.
kernel32: Add ExpandEnvironmentStringsA tests for japanese.
kernel32: Add more tests for ExpandEnvironmentStringsA.
kernel32: Add tests for ExpandEnvironmentStringsW.
ntdll: Add more tests for RtlExpandEnvironmentStrings/_U.
userenv: Add another test for GetProfilesDirectoryA
https://gitlab.winehq.org/wine/wine/-/merge_requests/4045
This adds support for converting to different WIC formats, in one case to more closely match native d3dx9, and in the other to convert to a format that can actually be represented by d3d9.
--
v2: d3dx9: Add support for decoding 48bpp RGB PNG files.
d3dx9: Report 24bpp RGB as 32bpp XRGB for JPG and PNG files.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6704
This starts using MDT_RAW_DPI in the drivers, and provides the necessary raw/virt monitor information to wineserver. For now, this should not change much, as MDT_RAW_DPI is still the same as MDT_DEFAULT_DPI, but later it will return the DPI of the physical mode while MDT_DEFAULT_DPI will return a DPI for the possibly virtualized current display mode.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6743
Also implement GetProcessWorkingSetSize on top this.
--
v4: kernelbase: Implement GetProcessWorkingSetSizeEx().
ntdll: Implement QUOTA_LIMITS_EX for NtQueryProcessInformation(ProcessQuotaLimits).
https://gitlab.winehq.org/wine/wine/-/merge_requests/5507
This MR is the first of multiples MRs adding support for the Bluetooth stack API in Wine:
1. The winebth.sys driver, which talks to BlueZ and implements several key IOCTLs for communicating with Bluetooth devices and radios.
2. A bthserv service, which is responsible for keeping track of the authentication agent, and relaying authentication requests and responses to and from the driver.
3. Userspace APIs (bluetoothapis.dll, bthprops.cpl, Windows.Devices.Bluetooth, etc).
winebth.sys is split into two "sub" drivers:
`winebth.sys`: The main entrypoint, loaded by winedevice. It listens for changes to Bluetooth devices and radios and authentication events on BlueZ, passing them on the bthenum. It also handles most IOCTL operations on Bluetooth radio PDOs.
`bthenum`: Responsible for creating nodes for discovered Bluetooth devices and associated services. It also tries to validate any IOCTLs relating to bluetooth devices before passing them to winebth.sys. (Not in this MR, likely in part 2)
The unix code is split between dbus.c, unixlib.c and winebluetooth.c, where winebluetooth is a simple wrapper around unixlib for the sake of organization.
--
v30: dlls/winebth.sys: Register and enable BTHPORT_DEVICE and BLUETOOTH_RADIO interfaces for radio PDOs.
dlls/winebth.sys: Derive a unique hardware ID for radio PDOs from their corresponding BlueZ object path.
dlls/winebth.sys: Create radio PDOs from the list of org.bluez.Adapter1 objects on BlueZ.
dlls/winebth.sys: Add a basic unixlib stub using DBus.
dlls/winebth.sys: Add base winebth.sys driver.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6621
--
v2: win32u: Do not convert back to integer before finding intersections.
win32u: Correctly handle transforms which flip in get_arc_points().
win32u: Normalize inverted rectangles in dibdrv_RoundRect().
https://gitlab.winehq.org/wine/wine/-/merge_requests/6722
This MR is the first of multiples MRs adding support for the Bluetooth stack API in Wine:
1. The winebth.sys driver, which talks to BlueZ and implements several key IOCTLs for communicating with Bluetooth devices and radios.
2. A bthserv service, which is responsible for keeping track of the authentication agent, and relaying authentication requests and responses to and from the driver.
3. Userspace APIs (bluetoothapis.dll, bthprops.cpl, Windows.Devices.Bluetooth, etc).
winebth.sys is split into two "sub" drivers:
`winebth.sys`: The main entrypoint, loaded by winedevice. It listens for changes to Bluetooth devices and radios and authentication events on BlueZ, passing them on the bthenum. It also handles most IOCTL operations on Bluetooth radio PDOs.
`bthenum`: Responsible for creating nodes for discovered Bluetooth devices and associated services. It also tries to validate any IOCTLs relating to bluetooth devices before passing them to winebth.sys. (Not in this MR, likely in part 2)
The unix code is split between dbus.c, unixlib.c and winebluetooth.c, where winebluetooth is a simple wrapper around unixlib for the sake of organization.
--
v29: dlls/winebth.sys: Register and enable BTHPORT_DEVICE and BLUETOOTH_RADIO interfaces for radio PDOs.
dlls/winebth.sys: Derive a unique hardware ID for radio PDOs from their corresponding BlueZ object path.
dlls/winebth.sys: Create radio PDOs from the list of org.bluez.Adapter1 objects on BlueZ.
dlls/winebth.sys: Add a basic unixlib stub using DBus.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6621
This MR is the first of multiples MRs adding support for the Bluetooth stack API in Wine:
1. The winebth.sys driver, which talks to BlueZ and implements several key IOCTLs for communicating with Bluetooth devices and radios.
2. A bthserv service, which is responsible for keeping track of the authentication agent, and relaying authentication requests and responses to and from the driver.
3. Userspace APIs (bluetoothapis.dll, bthprops.cpl, Windows.Devices.Bluetooth, etc).
winebth.sys is split into two "sub" drivers:
`winebth.sys`: The main entrypoint, loaded by winedevice. It listens for changes to Bluetooth devices and radios and authentication events on BlueZ, passing them on the bthenum. It also handles most IOCTL operations on Bluetooth radio PDOs.
`bthenum`: Responsible for creating nodes for discovered Bluetooth devices and associated services. It also tries to validate any IOCTLs relating to bluetooth devices before passing them to winebth.sys. (Not in this MR, likely in part 2)
The unix code is split between dbus.c, unixlib.c and winebluetooth.c, where winebluetooth is a simple wrapper around unixlib for the sake of organization.
--
v28: dlls/winebth.sys: Register and enable BTHPORT_DEVICE and BLUETOOTH_RADIO interfaces for radio PDOs.
dlls/winebth.sys: Derive a unique hardware ID for radio PDOs from their corresponding BlueZ object path.
dlls/winebth.sys: Create radio PDOs from the list of org.bluez.Adapter1 objects on BlueZ.
dlls/winebth.sys: Add a basic unixlib stub using DBus.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6621
I added a new test method, please tell me if I should merge that into an existing one, but as far as I understood, there is no tests for the querying yet.
--
v2: wbemprox: Add property "ExecutablePath" to Win32_Process
https://gitlab.winehq.org/wine/wine/-/merge_requests/6734
This MR is the first of multiples MRs adding support for the Bluetooth stack API in Wine:
1. The winebth.sys driver, which talks to BlueZ and implements several key IOCTLs for communicating with Bluetooth devices and radios.
2. A bthserv service, which is responsible for keeping track of the authentication agent, and relaying authentication requests and responses to and from the driver.
3. Userspace APIs (bluetoothapis.dll, bthprops.cpl, Windows.Devices.Bluetooth, etc).
winebth.sys is split into two "sub" drivers:
`winebth.sys`: The main entrypoint, loaded by winedevice. It listens for changes to Bluetooth devices and radios and authentication events on BlueZ, passing them on the bthenum. It also handles most IOCTL operations on Bluetooth radio PDOs.
`bthenum`: Responsible for creating nodes for discovered Bluetooth devices and associated services. It also tries to validate any IOCTLs relating to bluetooth devices before passing them to winebth.sys. (Not in this MR, likely in part 2)
The unix code is split between dbus.c, unixlib.c and winebluetooth.c, where winebluetooth is a simple wrapper around unixlib for the sake of organization.
--
v27: dlls/winebth.sys: Register and enable BTHPORT_DEVICE and BLUETOOTH_RADIO interfaces for radio PDOs.
dlls/winebth.sys: Derive a unique hardware ID for radio PDOs from their corresponding BlueZ object path.
dlls/winebth.sys: Create radio PDOs from the list of org.bluez.Adapter1 objects on BlueZ.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6621
First change is to avoid creating and mapping windows concurrently, this is completely racy and can cause random results later on depending on which window ends up being focused and depending on the X11 events. In addition, FVWM focus tracking suffers from various race conditions already, which only makes it worse.
Second change is to avoid failing the tests because of spurious window resize messages on the dummy window. I'm not sure what the window is for exactly but I believe it's not meaningful in the message sequence as it never appears there. As it is maximized, the window is sometimes resized by some WMs when the display mode changes, which cause the spurious WM_SIZE messages.
--
v3: d3d8/tests: Use static class for the dummy window.
d3d8/tests: Avoid creating visible windows concurrently.
d3d9/tests: Use static class for the dummy window.
d3d9/tests: Avoid creating visible windows concurrently.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6700
On Thu Oct 24 16:32:46 2024 +0000, Vijay Kiran Kamuju wrote:
> changed this line in [version 28 of the diff](/wine/wine/-/merge_requests/4661/diffs?diff_id=139983&start_sha=704c7862cdae2a5c380fe8e52a0889864ffbb9e6#02bb3b4ad98d91472456efe7c9f200666067cf8d_5682_5665)
I removed the GdipSetEffectParameters implementation till tests are working.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4661#note_85981
On Thu Oct 24 16:32:46 2024 +0000, Vijay Kiran Kamuju wrote:
> changed this line in [version 28 of the diff](/wine/wine/-/merge_requests/4661/diffs?diff_id=139983&start_sha=704c7862cdae2a5c380fe8e52a0889864ffbb9e6#02bb3b4ad98d91472456efe7c9f200666067cf8d_5682_5665)
I removed the GdipSetEffectParameters implementation till tests are working.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4661#note_85980
On Thu Oct 24 16:32:45 2024 +0000, Vijay Kiran Kamuju wrote:
> changed this line in [version 28 of the diff](/wine/wine/-/merge_requests/4661/diffs?diff_id=139983&start_sha=704c7862cdae2a5c380fe8e52a0889864ffbb9e6#02bb3b4ad98d91472456efe7c9f200666067cf8d_5676_5665)
I removed the GdipSetEffectParameters implementation till tests are working.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4661#note_85979
On Thu Oct 24 16:32:45 2024 +0000, Vijay Kiran Kamuju wrote:
> changed this line in [version 28 of the diff](/wine/wine/-/merge_requests/4661/diffs?diff_id=139983&start_sha=704c7862cdae2a5c380fe8e52a0889864ffbb9e6#7c8ca2b5a97a42676b2979286a5fe74c047f321f_5537_5441)
I removed the implementation of GdipSetEffectParameters.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4661#note_85978
On Thu Oct 24 16:32:44 2024 +0000, Vijay Kiran Kamuju wrote:
> changed this line in [version 28 of the diff](/wine/wine/-/merge_requests/4661/diffs?diff_id=139983&start_sha=704c7862cdae2a5c380fe8e52a0889864ffbb9e6#02bb3b4ad98d91472456efe7c9f200666067cf8d_5668_5665)
I removed the implementation for GdipSetEffectParameters, till I can perfect the tests.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4661#note_85977
On Thu Oct 24 17:14:33 2024 +0000, Vijay Kiran Kamuju wrote:
> I have changed the structure a bit to fix a bit of issues
I removed the implementation of GdipSetEffectParameters, till I can perfect the tests for it.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4661#note_85976
This should be functionally no-op as the new state tracker has no side effect other than printing traces. It introduces a new pending/current states on the win data to track the requested changes, as well as the associated request serial for each of the property being changed.
Later, this tracker will help making the requests more asynchronous (removing the need for wait_for_withdrawn_state), avoid duplicate requests, and better decide whether the received updates are expected or should be applied back to the win32 window state:
- any update that is older than our last request, expected and matching our request, or unexpected but no-op can be ignored,
- any update that wasn't requested or doesn't match the request (because the WM decided so) will need to be applied on the win32 state.
Tracking the current X11 window state separately will also allow us to later delay these updates on the win32 state, possibly by posting an internal message for win32u to call us back to get the necessary changes, when every other message has been processed and avoid calling SetWindowPos / syscommand directly from within the driver event handlers.
--
v2: winex11: Track window config requests and updates.
winex11: Introduce a new window_set_config helper.
winex11: Track _NET_WM_STATE window property requests and updates.
winex11: Introduce a new window_set_net_wm_state helper.
winex11: Introduce a new window_set_wm_state helper.
winex11: Track _XEMBED_INFO window property changes.
winex11: Track WM_STATE window property requests and updates.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6729
This should be functionally no-op as the new state tracker has no side effect other than printing traces. It introduces a new pending/current states on the win data to track the requested changes, as well as the associated request serial for each of the property being changed.
Later, this tracker will help making the requests more asynchronous (removing the need for wait_for_withdrawn_state), avoid duplicate requests, and better decide whether the received updates are expected or should be applied back to the win32 window state:
- any update that is older than our last request, expected and matching our request, or unexpected but no-op can be ignored,
- any update that wasn't requested or doesn't match the request (because the WM decided so) will need to be applied on the win32 state.
Tracking the current X11 window state separately will also allow us to later delay these updates on the win32 state, possibly by posting an internal message for win32u to call us back to get the necessary changes, when every other message has been processed and avoid calling SetWindowPos / syscommand directly from within the driver event handlers.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6729
First change is to avoid creating and mapping windows concurrently, this is completely racy and can cause random results later on depending on which window ends up being focused and depending on the X11 events. In addition, FVWM focus tracking suffers from various race conditions already, which only makes it worse.
Second change is to avoid failing the tests because of spurious window resize messages on the dummy window. I'm not sure what the window is for exactly but I believe it's not meaningful in the message sequence as it never appears there. As it is maximized, the window is sometimes resized by some WMs when the display mode changes, which cause the spurious WM_SIZE messages.
--
v2: d3d8/tests: Use static class for the dummy window.
d3d8/tests: Avoid creating visible windows concurrently.
d3d9/tests: Use static class for the dummy window.
d3d9/tests: Avoid creating visible windows concurrently.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6700
We will need to inform wineserver of the available monitor physical/virtual rects and dpi in order for it to be able to correctly find windows from mouse input position, as well as for desktop clipping rectangles, so keep the monitors in a list until we've listed them all.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6725
On Wed Oct 23 04:23:48 2024 +0000, Zhiyi Zhang wrote:
> It's not clear to me how to fix this properly. I also wonder why Wine
> doesn't encounter this error.
> It seems that MIDL maps `boolean` to `bool`. Please see
> https://github.com/tpn/winsdk-10/blob/9b69fd26ac0c7d0b83d378dba01080e93349c…
> ```
> struct __declspec(uuid("3c00fd60-2950-5939-a21a-2d12c5a01b8a"))
> IReference<bool> :
> IReference_impl<ABI::Windows::Foundation::Internal::AggregateType<bool,
> boolean>> {
> static const wchar_t* z_get_rc_name_impl() {
> return L"Windows.Foundation.IReference`1<Boolean>"; }
> };
> typedef IReference<bool> __FIReference_1_boolean_t;
> #define ____FIReference_1_boolean_FWD_DEFINED__
> #define __FIReference_1_boolean ABI::Windows::Foundation::__FIReference_1_boolean_t
> ```
> So this might be a bug in WIDL? @jacek @rbernon
It's probably specific to the C++ generated code, which should output `bool` in place of `boolean`.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6594#note_85838
On Sat Oct 12 06:40:19 2024 +0000, Zhiyi Zhang wrote:
> I don't think this is a bug in Wine. Native headers have both
> `Windows.Foundation.IReference<BYTE>` and
> `Windows.Foundation.IReference<boolean>` and no conflicts.
It's not clear to me how to fix this properly. I also wonder why Wine doesn't encounter this error.
It seems that MIDL maps `boolean` to `bool`. Please see https://github.com/tpn/winsdk-10/blob/9b69fd26ac0c7d0b83d378dba01080e93349c…
```
struct __declspec(uuid("3c00fd60-2950-5939-a21a-2d12c5a01b8a"))
IReference<bool> : IReference_impl<ABI::Windows::Foundation::Internal::AggregateType<bool, boolean>> {
static const wchar_t* z_get_rc_name_impl() {
return L"Windows.Foundation.IReference`1<Boolean>"; }
};
typedef IReference<bool> __FIReference_1_boolean_t;
#define ____FIReference_1_boolean_FWD_DEFINED__
#define __FIReference_1_boolean ABI::Windows::Foundation::__FIReference_1_boolean_t
```
So this might be a bug in WIDL? @jacek @rbernon
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6594#note_85837
--
v3: ntdll/tests: Add tests for completion port signaling.
kernelbase: Set the proper error code in GetQueuedCompletionStatus{Ex} when the handle is closed.
server: Signal completion port waits on handle close.
ntdll: Handle user APCs explicitly in NtRemoveIoCompletionEx().
https://gitlab.winehq.org/wine/wine/-/merge_requests/6630
--
v2: ntdll/tests: Add tests for completion port signaling.
kernelbase: Set the proper error code in GetQueuedCompletionStatus{Ex} when the handle is closed.
server: Signal completion port waits on handle close.
ntdll: Handle user APCs explicitly in NtRemoveIoCompletionEx().
ntdll: Assign completion to thread when wait for completion is satisfied.
ntdll: Introduce a separate per-thread object for internal completion waits.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6630
First change is to avoid creating and mapping windows concurrently, this is completely racy and can cause random results later on depending on which window ends up being focused and depending on the X11 events. In addition, FVWM focus tracking suffers from various race conditions already, which only makes it worse.
Second change is to avoid failing the tests because of spurious window resize messages on the dummy window. I'm not sure what the window is for exactly but I believe it's not meaningful in the message sequence as it never appears there. As it is maximized, the window is sometimes resized by some WMs when the display mode changes, which cause the spurious WM_SIZE messages.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6700
Replicate native behavior.
This fixes Giana Sister: Twisted Dreams crashing during the intro
video. The game expects to be able to fit a few audio samples in a
fixed size memory area.
--
v2: winegstreamer: Split large WMA samples.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6629
This MR is the first of multiples MRs adding support for the Bluetooth stack API in Wine:
1. The winebth.sys driver, which talks to BlueZ and implements several key IOCTLs for communicating with Bluetooth devices and radios.
2. A bthserv service, which is responsible for keeping track of the authentication agent, and relaying authentication requests and responses to and from the driver.
3. Userspace APIs (bluetoothapis.dll, bthprops.cpl, Windows.Devices.Bluetooth, etc).
winebth.sys is split into two "sub" drivers:
`winebth.sys`: The main entrypoint, loaded by winedevice. It listens for changes to Bluetooth devices and radios and authentication events on BlueZ, passing them on the bthenum. It also handles most IOCTL operations on Bluetooth radio PDOs.
`bthenum`: Responsible for creating nodes for discovered Bluetooth devices and associated services. It also tries to validate any IOCTLs relating to bluetooth devices before passing them to winebth.sys. (Not in this MR, likely in part 2)
The unix code is split between dbus.c, unixlib.c and winebluetooth.c, where winebluetooth is a simple wrapper around unixlib for the sake of organization.
--
v26: dlls/winebth.sys: Register and enable BTHPORT_DEVICE and BLUETOOTH_RADIO interfaces for radio PDOs.
dlls/winebth.sys: Derive a unique hardware ID for radio PDOs from their corresponding BlueZ object path.
dlls/winebth.sys: Create radio PDOs from the list of org.bluez.Adapter1 objects on BlueZ.
dlls/winebth.sys: Add a basic unixlib stub using DBus.
dlls/winebth.sys: Add base winebth.sys driver.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6621
ole32: fixed incorrect write dword high part datetime to buffer with OFFSET_PS_MTIMEHIGH in UpdateRawDirEntry
@Mystral, @julliard, @hans, I think this is higher priority for code review than my previous PRs.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6710