On Thu Aug 29 16:15:21 2024 +0000, Elizabeth Figura wrote:
> The problem isn't the name, it's the HANDLE. I suppose we *could*
> manually fix that up later, but letting RPC take care of it for us seems
> fine enough to me.
Actually, I'm a bit confused, because now I'm not sure where RPC does do that? I was assuming it was a user-marshalled type which implicitly calls DuplicateHandle(), but that's not the case.
The lack of tests in this patch set is a little disturbing. Is it possible to test this behaviour? I don't know under what circumstances handle events are sent [and I can't easily find anyone successfully using DBT_DEVTYP_HANDLE online]. We do have support for testing PnP drivers, though, if that's necessary; see dlls/ntoskrnl.exe/tests/driver_pnp.c.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6315#note_80395
On Thu Aug 29 07:59:06 2024 +0000, Rémi Bernon wrote:
> I mean, DEV_BROADCAST_HANDLE has a dbch_nameoffset which you can use to
> put the device name in it, and use that for filtering? Or if you need an
> additional offset, dbch_reserved?
> (Then IMO it'd be better to not have to pass the device path through RPC
> for filtering on every message)
The problem isn't the name, it's the HANDLE. I suppose we *could* manually fix that up later, but letting RPC take care of it for us seems fine enough to me.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6315#note_80394
--
v8: winex11: Map message pos to physical DPI in move_resize_window.
win32u: Avoid changing thread DPI context in process_hardware_message.
win32u: Factor hardware message point DPI mapping together.
win32u: Use map_window_points with explicit DPI over screen_to_client.
win32u: Split hardware message window lookup to a separate helper.
win32u: Use per-monitor DPI window_from_point in process_mouse_message.
win32u: Parameterize window_from_point dpi.
server: Pass window's per-monitor DPI in set_window_pos.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5819
On Thu Aug 29 07:47:26 2024 +0000, Rémi Bernon wrote:
> This is a huge amount of changes and it doesn't seem really justified? I
> think you can do everything you need with DEV_BROADCAST_HDR already and
> do not need any internal structs, or am I missing something?
I mean, DEV_BROADCAST_HANDLE has a dbch_nameoffset which you can use to put the device name in it, and use that for filtering?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6315#note_80369
Rémi Bernon (@rbernon) commented about include/wine/dbt.h:
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this library; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA
> + */
> +
> +#ifndef __WINE_WINE_DBT_H_
> +#define __WINE_WINE_DBT_H_
> +
> +#include <wine/plugplay.h>
> +#include <wine/debug.h>
> +
> +struct device_notification_details
This is a huge amount of changes and it doesn't seem really justified? I think you can do everything you need with DEV_BROADCAST_HDR already and do not need any internal structs, or am I missing something?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6315#note_80368
On Thu Aug 29 07:07:25 2024 +0000, Hans Leidekker wrote:
> Can you share a trace? I'd like to see how the app calls this function.
I'm not able to find a currently log with a call to this function.
All the logs to have show this function wasn't supported in the ODBC v2.0 driver.
0024:trace:odbc:load_function_table failed to load SQLBindParam
This could of been another application I was testing at the time but I'm cannot remember which one.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6394#note_80366
The option is on by default with the virtual desktop, off by default
otherwise, but can be forced on/off in either case, letting it hide
the taskbar in virtual desktop mode too.
The standalone systray window still uses the separate ShowSystray option
which can be enabled when EnableShell is off. When EnableShell is on,
the systray area will always be visible in the taskbar.
--
v2: explorer: Use the EnableShell option to show or hide the taskbar.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6367
I'll close this MR, as I don't believe a DXGI to DXGI copy is ever necessary. If the transform provides a DXGI buffer, then I believe we can return it directly. And if it doesn't, and the application expects a DXGI buffer, then the copy will be from CPU memory to GPU.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5979#note_80354
PHP 8.2.7 check that vcruntime140.dll is have the linker version equal to the version of the linker of the toolchain used to build itself, and refuse to start otherwise, with this error message:
`PHP Warning: 'C:\windows\system32\VCRUNTIME140.dll' 2.39 is not compatible with this PHP build linked with 14.29 in Unknown on line 0`
Setting the linker version in winebuild to 14.29 allow php to pass this check.
If there are concerns to having this change global, I could try to make this as argument to winebuild with the value setted somewhere into the build system
Signed-off-by: Lorenzo Ferrillo <lorenzofersteam(a)live.it>
--
v3: winebuild: Use know 14.29 version for the linker version of dll files
https://gitlab.winehq.org/wine/wine/-/merge_requests/6377
Because WINENV is limited (32767 bytes), and HOSTENV can be much larger,
a whitelisting approach is used to keep WINENV as small as possible.
Currently, only the following envvars are propagated from the host env to WINENV
WINEPATH, WINEPWD, WINEHOME, WINETEMP, WINETMP, WINEQT_, WINEVK_, WINEXDG_SESSION_TYPE
Moreover, the NIXENV (env for running wine processes - not applications) on the
host system is not produced from WINENV anymore, but the global ENV
is propagated to all wine processes and threads.
This might be an alternative approach to MR!5231, MR!6140, bug #56941
and should provide a more deterministic behaviour of wine, because unrelated
envvars do have no influence on the env for running windows applications.
Initial tests (winemine, notepad, cmd, etc) seem to run fine, but some envvars might need additional
consideration. XVDK_* was mentioned, WINE*, MESA_*, VK_*, QT_*, LIBGL_* are other suspects.
Moreover, this is my first merge request, so your feedback is highly appreciated.
--
v19: include: Add http3 flag in winhttp.h.
msi: Implement the InstallAdminImage action.
msi: Add support for the ADMIN top level action.
msi: Remove traces from a couple of helpers.
cmd: Report an error from ftype or assoc if the value is empty.
cmd: Allow deleting associations via ftype.
cmd/tests: Test running a file with an association.
combase: Group the post quit info in a structure.
ieframe: Widen toolbar buttons to accommodate Dutch translation.
explorer: Don't display "Default" in the virtual desktop window title.
explorer: Make the "Wine Desktop" window title translatable.
odbc32: Correcly convert columns ID in SQLColAttribute/W for ODBC v2.0.
odbc32: Pass through field id SQL_MAX_COLUMNS_IN_TABLE in SQLColAttribute/W.
wmiutils: Handle paths with implied key.
windows.gaming.input: Zero 'value' in GetCurrentReading until first state change.
winegstreamer/video_encoder: Initially implement ProcessOutput.
winegstreamer/video_encoder: Add ICodecAPI stubs.
mf/tests: Test codecapi for h264 encoder.
mf/tests: Test h264 encoder sample processing.
This merge request has too many patches to be relayed via email.
Please visit the URL below to see the contents of the merge request.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6166