August 2021 - Wine-Devel - list.winehq.org

[PATCH 2/2] wininet: Prefere recent windows resutls in InternetErrorDlg tests.

by Jacek Caban

Based on patch by Dmitry Timoshkov. Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> --- dlls/wininet/tests/internet.c | 66 +++++++++++++++++------------------ 1 file changed, 33 insertions(+), 33 deletions(-)

Aug. 31, 2021

[PATCH 1/2] wininet: Return ERROR_CANCELLED for unsupported errors in InternetErrorDlg.

by Jacek Caban

Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> --- dlls/wininet/dialogs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

Aug. 31, 2021

Re: [RFC PATCH 0/5] XAudio PE conversion.

by Zebediah Figura (she/her)

I know I'm representing the minority opinion here, but I'd like to offer my objections anyway :-) I think the solution I originally proposed doesn't make a lot of sense in retrospect. However, I don't like this one either. I've tried to rethink my position to be more reasonable, and I'd like whatever solution we come up with to satisfy three things: (1) I really don't want to have to build any libraries that aren't part of Wine. More importantly, I don't want anyone who's not a regular Wine developer to ever have to build any libraries that aren't part of Wine. Also, if I do need to build (say) libvkd3d-shader, I want to *only* have to build libvkd3d-shader and not all of the Wine dependencies at once. This is quite likely the only thing that holds me back from contributing to wine-mono (not that this is entirely Esme's fault; the problem affects mono upstream, although wine-mono has doubled down on it) (2) I would like bisecting dependencies to not be a pain. As someone who will be working on vkd3d a lot, this is quite important to me. Ideally this means that the dependencies should exist in shared libraries, not static ones. I would also like to be able to develop in a separate tree, since git submodules are terrible for doing active development on a component. Rémi's proposed solution does not really allow for that as far as I can tell. As an aside, I still think there is something to be gained in using shared libraries to reduce disk space. Almost all of our PE dependencies are not only shared across multiple DLLs, but will often be loaded multiple times in the same process (vkd3d, faudio, gnutls, libpng, zlib, freetype, mpg123 all come immediately to mind. To some degree we can try to abstract that out with our own shared-to-static shims, but that takes some work which I think is rather unnecessary.) (3) Most importantly, I would like to coöperate with distributions. As I understand, they already don't like the way we distribute wine-mono and wine-gecko, and I don't think we should annoy them any further by going behind their back and distributing more pre-built libraries. I know people here think that they won't want to distribute PE libraries, but I'm inclined to think that at least some distributions won't be happy with our proposed solution either. See [1] [2] [3] [4] for popular distributions trying to discourage source imports and static libraries. I get that we're a special case, and maybe distributions will think so too, but I really want to again argue that we shouldn't be making that decision for them. ἔρρωσθε, Zebediah [1] https://wiki.debian.org/EmbeddedCopies [2] https://fedoraproject.org/wiki/Bundled_Libraries [3] https://docs.fedoraproject.org/en-US/packaging-guidelines/#packaging-static… [4] https://wiki.gentoo.org/wiki/Why_not_bundle_dependencies

Aug. 31, 2021

Re: [PATCH v2] conhost: Set keyboard focus to correct radio button in save dialog

by Jacek Caban

Signed-off-by: Jacek Caban <jacek(a)codeweavers.com>

Aug. 31, 2021

Re: [PATCH] ntdll: Truncate and ellipsize debug output if it's too long.

by Alexandre Julliard

"Esme Povirk (she/they)" <esme(a)codeweavers.com> writes: > On Tue, Aug 31, 2021 at 5:03 AM Alexandre Julliard <julliard(a)winehq.org> wrote: >> > I would still like to figure this out for the occasions when Mono >> > produces really long trace outputs. >> >> The best is to send them through debugstr_a/w, but you can also truncate >> or wrap them manually as seems appropriate. You don't need to know the >> exact buffer length, you can use say 600 chars (two debugstr's worth). > > The trouble is that Mono likes to send debug output in pieces, > especially the trace functionality where each argument is a single > call to mono_print_handler_fn. To illustrate, I tried modifying it to > print just one line with debugstr_a and got call traces like this: > > 00fc:fixme:mscoree:mono_print_handler_fn "ENTER:c (wrapper > managed-to-native) System.IO.MonoIO:Write > (intptr,byte[],int,int,System.IO.MonoIOError&)(" > 00fc:fixme:mscoree:mono_print_handler_fn "0000000000000014" > 00fc:fixme:mscoree:mono_print_handler_fn ", " > 00fc:fixme:mscoree:mono_print_handler_fn > "[System.Byte[]:[1024]0000000001457a40]" > 00fc:fixme:mscoree:mono_print_handler_fn ", " > 00fc:fixme:mscoree:mono_print_handler_fn "0" > 00fc:fixme:mscoree:mono_print_handler_fn ", " > 00fc:fixme:mscoree:mono_print_handler_fn "15" > 00fc:fixme:mscoree:mono_print_handler_fn ", " > 00fc:fixme:mscoree:mono_print_handler_fn "[BYREF:000000000011f140]" > 00fc:fixme:mscoree:mono_print_handler_fn ")\n" > > We could keep track of the total line length in some sort of TLS, but > it feels like it'd be better to do that in the common debug code where > we already have a TLS structure than in mscoree. There's also a > possibility that the length stored by mscoree will be off if other > Wine traces occur in the same thread between these calls (which would, > of course, garble the output, so maybe that's an argument for having a > string buffer in mscoree, but it doesn't feel very clean to me as we'd > have to hard-code the maximum length). It sounds very much like you want a buffer for mono_print_handler_fn separate from the other debug functions. I don't see any issue with hard-coding a maximum length. -- Alexandre Julliard julliard(a)winehq.org

Aug. 31, 2021

Re: [PATCH] ntdll: Truncate and ellipsize debug output if it's too long.

by Esme Povirk (she/they)

On Tue, Aug 31, 2021 at 5:03 AM Alexandre Julliard <julliard(a)winehq.org> wrote: > > I would still like to figure this out for the occasions when Mono > > produces really long trace outputs. > > The best is to send them through debugstr_a/w, but you can also truncate > or wrap them manually as seems appropriate. You don't need to know the > exact buffer length, you can use say 600 chars (two debugstr's worth). The trouble is that Mono likes to send debug output in pieces, especially the trace functionality where each argument is a single call to mono_print_handler_fn. To illustrate, I tried modifying it to print just one line with debugstr_a and got call traces like this: 00fc:fixme:mscoree:mono_print_handler_fn "ENTER:c (wrapper managed-to-native) System.IO.MonoIO:Write (intptr,byte[],int,int,System.IO.MonoIOError&)(" 00fc:fixme:mscoree:mono_print_handler_fn "0000000000000014" 00fc:fixme:mscoree:mono_print_handler_fn ", " 00fc:fixme:mscoree:mono_print_handler_fn "[System.Byte[]:[1024]0000000001457a40]" 00fc:fixme:mscoree:mono_print_handler_fn ", " 00fc:fixme:mscoree:mono_print_handler_fn "0" 00fc:fixme:mscoree:mono_print_handler_fn ", " 00fc:fixme:mscoree:mono_print_handler_fn "15" 00fc:fixme:mscoree:mono_print_handler_fn ", " 00fc:fixme:mscoree:mono_print_handler_fn "[BYREF:000000000011f140]" 00fc:fixme:mscoree:mono_print_handler_fn ")\n" We could keep track of the total line length in some sort of TLS, but it feels like it'd be better to do that in the common debug code where we already have a TLS structure than in mscoree. There's also a possibility that the length stored by mscoree will be off if other Wine traces occur in the same thread between these calls (which would, of course, garble the output, so maybe that's an argument for having a string buffer in mscoree, but it doesn't feel very clean to me as we'd have to hard-code the maximum length). On the Mono side, that line is printed by a single method, mono_trace_enter_method (https://github.com/madewokherd/mono/blob/develop/mono/mini/trace.c#L147) but I'd rather not modify Mono code any more than I have to because it makes merges more difficult, and it's not obvious to me how to improve it anyway. At the moment, Mono doesn't have access to debugstr_a, but I guess I could throw in another copy of debug.c. I've had one case where a single method name and its argument types was enough to overflow the buffer on its own.

Aug. 31, 2021

Re: [PATCH vkd3d 2/5] tests: Test the shape of the sum of two numeric values.

by Zebediah Figura (she/her)

On 8/31/21 9:40 AM, Giovanni Mascellani wrote: > diff --git a/tests/hlsl-shape.shader_test b/tests/hlsl-shape.shader_test > new file mode 100644 > index 00000000..0d488da4 > --- /dev/null > +++ b/tests/hlsl-shape.shader_test I'm not a huge fan of this name; it's not immediately clear to me what it means :-( Maybe "hlsl-expression-dimensions"? > @@ -0,0 +1,121 @@ > +[pixel shader] > +float4 main(float4 pos : sv_position) : sv_target > +{ > + /* Scalar and scalar */ > + float x = 1.0; > + float y = 2.0; > + if (pos.x == 0.5) > + return float4(x + y, 0.0, 0.0, 0.0); > + > + /* Vector and vector */ > + float1 v1 = float1(1.0); > + float2 v2 = float2(2.0, 3.0); > + float4 v4 = float4(4.0, 5.0, 6.0, 7.0); > + if (pos.x == 10.5) > + return float4(v1 + v2, 0.0, 0.0); > + if (pos.x == 11.5) > + return float4(v1 + v4); > + if (pos.x == 12.5) > + return float4(v2 + v4, 0.0, 0.0); > + > + /* Scalar and vector */ > + if (pos.x == 20.5) > + return float4(x + v1, v1 + x, 0.0, 0.0); > + if (pos.x == 21.5) > + return float4(v4 + x); > + if (pos.x == 22.5) > + return float4(x + v4); > + > + /* Matrix and matrix */ > + float1x4 m14 = float1x4(1.0, 2.0, 3.0, 4.0); > + float4x1 m41 = float4x1(5.0, 6.0, 7.0, 8.0); > + float2x2 m22 = float2x2(9.0, 10.0, 11.0, 12.0); > + float2x3 m23 = float2x3(13.0, 14.0, 15.0, > + 16.0, 17.0, 18.0); > + float4x4 m44 = float4x4(35.0, 36.0, 37.0, 38.0, > + 39.0, 40.0, 41.0, 42.0, > + 43.0, 44.0, 45.0, 46.0, > + 47.0, 48.0, 49.0, 50.0); > + if (pos.x == 30.5) > + return float4(m22 + m23); > + if (pos.x == 31.5) > + return float4(m23 + m22); > + if (pos.x == 32.5) > + return float4(m14 + m44); > + if (pos.x == 33.5) > + return float4(m44 + m14); > + if (pos.x == 34.5) > + return float4(m41 + m44); > + if (pos.x == 35.5) > + return float4(m44 + m41); > + if (pos.x == 36.5) > + return float4((m44 + m23)[0], 0.0); > + if (pos.x == 37.5) > + return float4((m44 + m23)[1], 0.0); > + > + /* Matrix and vector */ > + if (pos.x == 50.5) > + return v4 + m14; > + if (pos.x == 51.5) > + return m14 + v4; > + if (pos.x == 52.5) > + return v4 + m41; > + if (pos.x == 53.5) > + return m41 + v4; > + if (pos.x == 54.5) > + return v4 + m22; > + if (pos.x == 55.5) > + return m22 + v4; > + if (pos.x == 56.5) > + return float4(v1 + m14); > + if (pos.x == 57.5) > + return float4(m14 + v1); > + if (pos.x == 58.5) > + return float4(v2 + m41, 0.0, 0.0); > + if (pos.x == 59.5) > + return float4(m41 + v2, 0.0, 0.0); > + > + /* Matrix and scalar */ > + if (pos.x == 70.5) > + return (x + m44)[0]; > + if (pos.x == 71.5) > + return (m44 + x)[1]; > + > + return float4(0.0, 0.0, 0.0, 0.0); > +} This doesn't compile with native for ps_2_0 either (see my comment on 5/5). Part of this is because it uses SV_Position, which is kind of my fault too as I've been using that. We should probably find a way to change that to texcoords instead. With that hacked out of the way, it breaks because of the following error: Z:\home\hazel\test.hlsl(83,38): error X5608: Compiled shader code uses too many arithmetic instruction slots (83). Max. allowed by the target (ps_2_0) is 64. Consider increasing optimization level to reduce instruction count. (Increasing optimization level does nothing, of course.)

Aug. 31, 2021

Re: [PATCH vkd3d 5/5] tests: Test a number of simple HLSL operations.

by Zebediah Figura (she/her)

On 8/31/21 9:40 AM, Giovanni Mascellani wrote: > diff --git a/tests/hlsl-operations.shader_test b/tests/hlsl-operations.shader_test > new file mode 100644 > index 00000000..3c8036b5 > --- /dev/null > +++ b/tests/hlsl-operations.shader_test > @@ -0,0 +1,86 @@ > +[pixel shader] > +float4 main(uniform float zero, uniform float one, uniform float x, uniform float y, > + float4 pos : SV_POSITION) : SV_TARGET > +{ > + int izero = zero; > + int ione = one; > + int ix = x; > + int iy = y; > + uint uzero = zero; > + uint uone = one; > + uint ux = x; > + uint uy = y; > + > + if (pos.x == 0.5) > + return float4(x + y, x - y, x * y, x / y); > + if (pos.x == 1.5) > + return float4(ix + iy, ix - iy, ix * iy, ix / iy); > + if (pos.x == 2.5) > + return float4(ux + uy, ux - uy, ux * uy, ux / uy); > + if (pos.x == 3.5) > + return float4(x % y, +x, -x, y / x); > + if (pos.x == 4.5) > + return float4(ix % iy, +ix, -ix, iy / ix); > + if (pos.x == 5.5) > + return float4(ux % uy, +ux, -ux, uy / ux); > + if (pos.x == 6.5) > + return float4(x == y, x != y, x < y, x <= y); > + if (pos.x == 7.5) > + return float4(x > y, x >= y, !x, !zero); > + if (pos.x == 8.5) > + return float4(ix == iy, ix != iy, ix < iy, ix <= iy); > + if (pos.x == 9.5) > + return float4(ix > iy, ix >= iy, !ix, !izero); > + if (pos.x == 10.5) > + return float4(ix & iy, ix | iy, ix ^ iy, ~ix); > + if (pos.x == 11.5) > + return float4(ix >> 2, ix << 2, iy >> 2, iy << 2); > + if (pos.x == 12.5) > + return float4(ux == uy, ux != uy, ux < uy, ux <= uy); > + if (pos.x == 13.5) > + return float4(ux > uy, ux >= uy, !ux, !uzero); > + if (pos.x == 14.5) > + return float4(ux & uy, ux | uy, ux ^ uy, ~ux); > + if (pos.x == 15.5) > + return float4(ux >> 2, ux << 2, uy >> 2, uy << 2); > + if (pos.x == 16.5) > + return float4(zero && zero, zero && one, one && zero, one && one); > + if (pos.x == 17.5) > + return float4(zero || zero, zero || one, one || zero, one || one); > + if (pos.x == 18.5) > + return float4(izero && izero, izero && ione, ione && izero, ione && ione); > + if (pos.x == 19.5) > + return float4(izero || izero, izero || ione, ione || izero, ione || ione); > + if (pos.x == 20.5) > + return float4(uzero && uzero, uzero && uone, uone && uzero, uone && uone); > + if (pos.x == 21.5) > + return float4(uzero || uzero, uzero || uone, uone || uzero, uone || uone); > + > + return float4(0.0, 0.0, 0.0, 0.0); > +} > + > +[test] > +uniform 0 float4 0.0 1.0 5.0 15.0 > +draw quad > +probe rgba (0, 0) (20.0, -10.0, 75.0, 0.33333333) 1 > +probe rgba (1, 0) (20.0, -10.0, 75.0, 0.0) > +probe rgba (2, 0) (20.0, 4294967300.0, 75.0, 0.0) > +probe rgba (3, 0) (5.0, 5.0, -5.0, 3.0) 1 > +probe rgba (4, 0) (5.0, 5.0, -5.0, 3.0) > +probe rgba (5, 0) (5.0, 5.0, 4294967300.0, 3.0) > +probe rgba (6, 0) (0.0, 1.0, 1.0, 1.0) > +probe rgba (7, 0) (0.0, 0.0, 0.0, 1.0) > +probe rgba (8, 0) (0.0, 1.0, 1.0, 1.0) > +probe rgba (9, 0) (0.0, 0.0, 0.0, 1.0) > +probe rgba (10, 0) (5.0, 15.0, 10.0, -6.0) > +probe rgba (11, 0) (1.0, 20.0, 3.0, 60.0) > +probe rgba (12, 0) (0.0, 1.0, 1.0, 1.0) > +probe rgba (13, 0) (0.0, 0.0, 0.0, 1.0) > +probe rgba (14, 0) (5.0, 15.0, 10.0, 4294967300.0) > +probe rgba (15, 0) (1.0, 20.0, 3.0, 60.0) > +probe rgba (16, 0) (0.0, 0.0, 0.0, 1.0) > +probe rgba (17, 0) (0.0, 1.0, 1.0, 1.0) > +probe rgba (18, 0) (0.0, 0.0, 0.0, 1.0) > +probe rgba (19, 0) (0.0, 1.0, 1.0, 1.0) > +probe rgba (20, 0) (0.0, 0.0, 0.0, 1.0) > +probe rgba (21, 0) (0.0, 1.0, 1.0, 1.0) > Some of these operations work with SM2-3, but not all of them. We don't currently have tests for anything other than 4.0, but ideally we'd like to compile all tests on all targets possible. Not to mention that this is kind of a lot, and I'm not convinced that we won't want more tests for any given operation. If nothing else it'd be nice to split these into arithmetic, shift, logical, and bitwise tests.

Aug. 31, 2021

Re: RFC: Reparse Point/NT Symlink Support [3]

by Zebediah Figura (she/her)

On 8/31/21 12:00 PM, Erich E. Hoover wrote: > On Tue, Aug 31, 2021 at 10:52 AM Zebediah Figura (she/her) > <zfigura(a)codeweavers.com> wrote: >> ... >> Is there a problem with collapse_path(), or is it just a matter of >> asking for the parent of the current directory? If the latter, wouldn't >> it just be a matter of storing the unresolved path in the TEB? > > That's necessary but not sufficient, you also need to change the path > resolution. It's completely valid (and common) to pass a relative > path that does something "stupid". An extension of the Linux example: > === > ~/tmplnk$ cd link/.. > ~/tmplnk$ ls > link test > ~/tmplnk$ ls link/.. > target > === Doesn't this end up being a problem regardless of how we store symlinks internally, though? As far as I can tell, all of this logic should happen on the PE side.

Aug. 31, 2021

Re: [PATCH] avicap32: Partially implement capCreateCaptureWindowW.

by Zebediah Figura (she/her)

On 8/31/21 8:59 AM, Gijs Vermeulen wrote: > Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=38011 > Signed-off-by: Gijs Vermeulen <gijsvrm(a)gmail.com> > --- > dlls/avicap32/Makefile.in | 1 + > dlls/avicap32/avicap32_main.c | 72 ++++++++++++++++++++++++++--------- > 2 files changed, 56 insertions(+), 17 deletions(-) > > diff --git a/dlls/avicap32/Makefile.in b/dlls/avicap32/Makefile.in > index 8f5a1089d5c..f320a58f04b 100644 > --- a/dlls/avicap32/Makefile.in > +++ b/dlls/avicap32/Makefile.in > @@ -1,4 +1,5 @@ > MODULE = avicap32.dll > IMPORTLIB = avicap32 > +IMPORTS = user32 > > C_SRCS = avicap32_main.c > diff --git a/dlls/avicap32/avicap32_main.c b/dlls/avicap32/avicap32_main.c > index 9e2a99d4c7c..6ed8db1d552 100644 > --- a/dlls/avicap32/avicap32_main.c > +++ b/dlls/avicap32/avicap32_main.c > @@ -56,36 +56,74 @@ > > WINE_DEFAULT_DEBUG_CHANNEL(avicap); > > +static ATOM registered_class = 0; > +static WCHAR class_nameW[] = {'W','i','n','e','A','v','i','C','a','p','C','l','a','s','s',0}; > + > +static LRESULT CALLBACK avicap_wndproc(HWND hwnd, UINT msg, WPARAM wparam, LPARAM lparam) > +{ > + switch(msg) > + { > + /* FIXME: handle WM_CAP_* messages */ Could we maybe have a FIXME for these? > + default: > + return DefWindowProcW(hwnd, msg, wparam, lparam); > + } > +} > + > +static ATOM register_class(void) > +{ > + WNDCLASSEXW class; > + > + class.cbSize = sizeof(WNDCLASSEXW); > + class.style = 0; > + class.lpfnWndProc = avicap_wndproc; > + class.cbClsExtra = 0; > + class.cbWndExtra = 0; > + class.hInstance = GetModuleHandleW(NULL); > + class.hIcon = NULL; > + class.hCursor = LoadCursorW(NULL, (LPWSTR)IDC_ARROW); > + class.hbrBackground = (HBRUSH)(COLOR_BTNFACE+1); > + class.lpszMenuName = NULL; > + class.lpszClassName = class_nameW; > + class.hIconSm = NULL; > + > + return RegisterClassExW(&class); > +} > > /*********************************************************************** > * capCreateCaptureWindowW (AVICAP32.@) > */ > -HWND VFWAPI capCreateCaptureWindowW(LPCWSTR lpszWindowName, DWORD dwStyle, INT x, > - INT y, INT nWidth, INT nHeight, HWND hWnd, > - INT nID) > +HWND VFWAPI capCreateCaptureWindowW(const WCHAR *window_name, DWORD style, INT x, > + INT y, INT width, INT height, HWND hWnd, INT id) > { > - FIXME("(%s, %08x, %08x, %08x, %08x, %08x, %p, %08x): stub\n", > - debugstr_w(lpszWindowName), dwStyle, x, y, nWidth, nHeight, hWnd, nID); > - return 0; > + FIXME("(%s, %08x, %08x, %08x, %08x, %08x, %p, %08x): semi-stub\n", > + debugstr_w(window_name), style, x, y, width, height, hWnd, id); > + > + if (!registered_class && !(registered_class = register_class())) > + { > + ERR("Failed to register class!\n"); > + return NULL; > + } > + > + return CreateWindowExW(style, class_nameW, window_name, style, x, y, width, height, > + hWnd, NULL, GetModuleHandleW(NULL), NULL); > } > This is thread-safe, but it really doesn't look like it. I'm honestly inclined to advocate for just not caching "registered_class" at all. Also, can you please unregister the window class on DLL unload?

Aug. 31, 2021