February 2023 - Wine-Devel - list.winehq.org

Upcoming vkd3d 1.7 release

by Henri Verbeet

Hi all, The tentative release date for vkd3d 1.7 is March 22, in slightly under 4 weeks. Please test your applications for any regressions, review any API changes since vkd3d 1.6, and so on. While starting today it will become increasingly harder to make major code changes until the release, improvements to the API documentation and tests are welcome as always. For vkd3d 1.8, the release following 1.7, we're currently aiming for a date in late June. Regards, Henri

Feb. 24, 2023

Re: [PATCH] user32/tests: fixed size passed to ToUnicode

by Marcus Meissner

On Fri, Feb 24, 2023 at 06:06:28PM +0530, Biswapriyo Nath wrote: > Patches should be sent to GitLab repository. Link > https://gitlab.winehq.org/wine/wine This is really harming contributors that only want to submit the occasional patch FWIW. https://gitlab.winehq.org/wine/wine/-/merge_requests/2273 Ciao, Marcus

Feb. 24, 2023

Re: [PATCH] user32/tests: fixed size passed to ToUnicode

by Biswapriyo Nath

Patches should be sent to GitLab repository. Link https://gitlab.winehq.org/wine/wine

Feb. 24, 2023

[PATCH] user32/tests: fixed size passed to ToUnicode

by Marcus Meissner

Signed-off-by: Marcus Meissner <marcus(a)jet.franken.de> --- dlls/user32/tests/input.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dlls/user32/tests/input.c b/dlls/user32/tests/input.c index ee39b11fc12..be41078bf29 100644 --- a/dlls/user32/tests/input.c +++ b/dlls/user32/tests/input.c @@ -3186,7 +3186,7 @@ static void test_ToAscii(void) ok(character == '\r', "ToAscii for Return was %i (expected 13)\n", character); wstr[0] = 0; - ret = ToUnicode('A', SC_A, state, wstr, sizeof(wstr), 0); + ret = ToUnicode('A', SC_A, state, wstr, ARRAY_SIZE(wstr), 0); ok(ret == 1, "ToUnicode(A) returned %i, expected 1\n", ret); str[0] = '\0'; -- 2.39.2

Feb. 24, 2023

Wine staging 8.2 release

by Alistair Leslie-Hughes

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 8.2 (531 patches are applied to wine vanilla) The patchinstall.sh script is no longer available and users should use the staging/patchinstall.py instead. For those that wanted to use ODBC in windows applications, this is the release for you. For those using ADO to connect to a dababase via ODBC, you will still need to use the native version of msado15 and msdasql. Through some of the bugs have been identified and fixed in this wine release there is still more work to be done. Some cavets on the ODBC support * Only the Unicode drivers for MySql/PostgreSQL were tested. * Not all functions have been mapped, so lodge a bug if something is missing. Developers. If anybody has time to have a look over or reivew the patchset, that would be great. Don't be scared of the 43 patches, most of them are calls into the loaded driver (boiler plate stuff). Users. If you are a user of unixODBC with wine, it would be great if you could post on bug 54499, the database used or if you prefer to use the standard windows driver. Known issues. * Using SQLDriverConnectW to connect to an ANSI ODBC driver will fail (works on windows). * The Driver DLL is possible loaded multiple times (Should have map of driver/function table). Upstreamed (Either directly from staging or fixed with a similar patch). * None Added: * [52233] Black NPC's skin or minor rendering glitches in multiple games (Batman: Arkham Knight, Steel Division: Normandy 44) * [48220] dxruby needs WAVE form loading implemented * [45135] Black Rockman Shooter has no sound, implementation missing in dmime * [34751] Aura: Fate of the Ages: sounds aren't played, but music works fine * [9027] No sound for rise of nations - all versions * [54499] Native ODBC drivers should be able be used. Updated: * Install scripts updated to Python 3 * winex11-Fixed-scancodes (was winex11-key_translation) * ntdll-NtDevicePath * ntdll-Junction_Points Where can you help * Run Steam/Battle.net/GOG/UPlay/Epic * Test your favorite game. * Test your favorite applications. * Improve staging patches and get them accepted upstream. * Suggest patches to be included in staging. As always, if you find a bug, please report it via https://bugs.winehq.org Best Regards Alistair.

Feb. 18, 2023

How do I package the output of wine as a deb file?

by zhengxianwei

I've compiled wine on a 64-core machine, and I want to package it up and send it to another machine for installation. I checked 2 pages, but still not sure how to do this https://wiki.winehq.org/Building_Wine https://wiki.winehq.org/Packaging

Feb. 18, 2023

Re: Debugging channel weirdness

by Zebediah Figura

On 2/10/23 13:36, Rémi Bernon wrote: > On 2/10/23 20:04, Rémi Bernon wrote: >> On 2/10/23 19:12, Zebediah Figura wrote: >>> On 2/10/23 00:18, Rémi Bernon wrote: >>>>> (1) Why does setting channel->flags affect performance at all? I'm >>>>> thoroughly baffled by this one. >>>>> >>>>> (2) Why was this diff not applied in the first place? (Simple >>>>> oversight?) >>>>> >>>>> (3) Why does __WINE_DBCL_INIT even exist, if its only purpose is to >>>>> guard out a single assignment? >>>>> >>>>> --Zeb >>>>> >>>> >>>> Probably to allow changing the selected channels dynamically, >>>> through process monitor for instance. >>>> >>> >>> I'm not sure which question this answers, but I don't think I >>> understand it? winedbg and taskmgr just set the flags directly; they >>> don't touch __WINE_DBCL_INIT, and I don't see why they'd need to. >>> >>> >> >> They can't change the flags in each of the translation units debug >> channels. What they do is change the debug options in the process PEB. >> >> In order to support the runtime modification, the TU debug channels >> need to keep their __WINE_DBCL_INIT bit set, so >> __wine_dbg_get_channel_flags is always called, and the debug option >> updated from the PEB. > > Correction, it's actually not __WINE_DBCL_INIT but rather their default > value, which contains all the bits. The logic is otherwise the same, the > TU channel bits are only eventually cleared for the default options, for > the reasons described here. > >> >> Only channels which aren't explicitly specified clear their >> __WINE_DBCL_INIT bit, after copying the default debug options. >> >> The default options (all) cannot be modified dynamically, or at least >> only takes effect the first time __wine_dbg_get_channel_flags is >> called for a given TU debug channel. >> > Thank you, that explains why the logic is arranged like it is. I'm inclined to think we should find another way to achieve this; spending hours trying to debug a performance drop from disabling logging channels is really not something I want to happen to anyone else. I'll see what I can achieve. This doesn't explain why __WINE_DBCL_INIT exists, but I can only assume that at this point there's no particularly good reason.

Feb. 14, 2023

Hangover Update

by André Zwing

Hi, As you might know, Hangover development stalled years ago waiting for the WoW64 support in Wine to complete. With Wine 8.0 (and even better with Jaceks wow branch) this is now done. In October I started to connect Qemu to that WoW64 support in my spare time and it progressed until I finally was able to publish some of that work today. It's still missing instructions and even some patches, but it should give a good introduction on what this will look like. In fact I started to get wowarmhw running, so I could do the first steps on a x86-64 machine to run ARM32 binaries. But exactly this part is missing for now as things changed since then. So in case I made you curious, here's the code :) https://github.com/AndreRH/hangover

Feb. 11, 2023

Re: Debugging channel weirdness

by Rémi Bernon

On 2/10/23 20:04, Rémi Bernon wrote: > On 2/10/23 19:12, Zebediah Figura wrote: >> On 2/10/23 00:18, Rémi Bernon wrote: >>>> (1) Why does setting channel->flags affect performance at all? I'm >>>> thoroughly baffled by this one. >>>> >>>> (2) Why was this diff not applied in the first place? (Simple >>>> oversight?) >>>> >>>> (3) Why does __WINE_DBCL_INIT even exist, if its only purpose is to >>>> guard out a single assignment? >>>> >>>> --Zeb >>>> >>> >>> Probably to allow changing the selected channels dynamically, through >>> process monitor for instance. >>> >> >> I'm not sure which question this answers, but I don't think I >> understand it? winedbg and taskmgr just set the flags directly; they >> don't touch __WINE_DBCL_INIT, and I don't see why they'd need to. >> >> > > They can't change the flags in each of the translation units debug > channels. What they do is change the debug options in the process PEB. > > In order to support the runtime modification, the TU debug channels need > to keep their __WINE_DBCL_INIT bit set, so __wine_dbg_get_channel_flags > is always called, and the debug option updated from the PEB. Correction, it's actually not __WINE_DBCL_INIT but rather their default value, which contains all the bits. The logic is otherwise the same, the TU channel bits are only eventually cleared for the default options, for the reasons described here. > > Only channels which aren't explicitly specified clear their > __WINE_DBCL_INIT bit, after copying the default debug options. > > The default options (all) cannot be modified dynamically, or at least > only takes effect the first time __wine_dbg_get_channel_flags is called > for a given TU debug channel. > -- Rémi Bernon <rbernon(a)codeweavers.com>

Feb. 10, 2023

Re: Compiling issues on macOS after 7.20 on ARM

by Jason Millard

Wow! That did the trick!!! Thank you again so much!! /*** Autogenerated by WIDL 8.0 from /Users/jmillard/vpinball/standalone/inc/vpinmame/VPinMAME.idl - Do not edit ***/ #ifdef _WIN32 #ifndef __REQUIRED_RPCNDR_H_VERSION__ #define __REQUIRED_RPCNDR_H_VERSION__ 475 #endif #include <rpc.h> #include <rpcndr.h> #endif On Fri, Feb 10, 2023 at 2:15 PM Brendan Shanks <bshanks(a)codeweavers.com> wrote: > > > On Feb 10, 2023, at 11:10 AM, Jason Millard <jsm174(a)gmail.com> wrote: > > > > Hello. Thanks! > > > > `llvm-mingw` was a typo from my notes. Sorry about that. > > > > After examining paths, they looked the same, so I tried without the > > > > export LDFLAGS="-Wl,-rpath,/opt/X11/lib" > > > > and that worked and I can now make it through configure! > > > > > > Now during the build, I get: > > > > dlls/ntdll/unix/dwarf.h:915:45: warning: taking the absolute value of > unsigned type 'ULONG_PTR' (aka 'unsigned long') has no effect > [-Wabsolute-value] > > case DW_OP_abs: stack[sp] = labs(stack[sp]); break; > > ^ > > dlls/ntdll/unix/dwarf.h:915:45: note: remove the call to 'labs' since > unsigned values cannot be negative > > case DW_OP_abs: stack[sp] = labs(stack[sp]); break; > > ^~~~ > > <inline asm>:305:2: error: conditional branch requires assembler-local > label. '.L__wine_syscall_dispatcher_return' is external. > > cbnz w16, .L__wine_syscall_dispatcher_return > > ^ > > Great, I just pushed an MR for that error: > https://gitlab.winehq.org/wine/wine/-/merge_requests/2158 > > With that it should build, but otherwise ARM64 Wine completely does not > work on macOS. But if you only need widl maybe that’s ok :) > > Brendan

Feb. 10, 2023