January 2022 - Wine-Devel - list.winehq.org

Re: [PATCH v10 2/2] ntdll: Properly track refcount with forwarded exports.

by Marvin

Hi, While running your changed tests, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at: https://testbot.winehq.org/JobDetails.pl?Key=105950 Your paranoid android. === w10pro64 (32 bit report) === kernel32: loader.c:3010: Test failed: attached thread count should be 2 === w10pro64_ar (64 bit report) === kernel32: loader.c:720: Test failed: 1219: wrong status c000011b/c0000130 loader.c:720: Test failed: 1224: wrong status c000011b/c000007b loader.c:720: Test failed: 1229: wrong status c000011b/c000007b loader.c:720: Test failed: 1234: wrong status c000011b/c000007b loader.c:720: Test failed: 1239: wrong status c000011b/c000007b loader.c:720: Test failed: 1244: wrong status c000011b/c000007b loader.c:720: Test failed: 1260: wrong status c000011b/0 loader.c:720: Test failed: 1264: wrong status c000011b/0 loader.c:720: Test failed: 1269: wrong status c000011b/0 loader.c:720: Test failed: 1273: wrong status c000011b/0 loader.c:720: Test failed: 1277: wrong status c000011b/0 loader.c:720: Test failed: 1431: wrong status c000011b/c000007b loader.c:720: Test failed: 1439: wrong status c000011b/c000007b loader.c:720: Test failed: 1444: wrong status c000011b/0 loader.c:724: Test failed: 1444: failed with c000011b expected fallback loader.c:720: Test failed: 1450: wrong status c000011b/0 loader.c:724: Test failed: 1450: failed with c000011b expected fallback loader.c:720: Test failed: 1456: wrong status c000011b/0 loader.c:724: Test failed: 1456: failed with c000011b expected fallback loader.c:720: Test failed: 1463: wrong status c000011b/0 loader.c:724: Test failed: 1463: failed with c000011b expected fallback loader.c:720: Test failed: 1469: wrong status c000011b/0 loader.c:720: Test failed: 1478: wrong status c000011b/0 loader.c:720: Test failed: 1482: wrong status c000011b/0 loader.c:720: Test failed: 1486: wrong status c000011b/0 loader.c:720: Test failed: 1490: wrong status c000011b/0 loader.c:720: Test failed: 1494: wrong status c000011b/0

Jan. 25, 2022

Re: [PATCH 3/5] widl: Fix nested parameterized types C / short name output.

by Rémi Bernon

On 1/25/22 18:53, Bernhard Kölbl wrote: > Am Di., 25. Jan. 2022 um 10:13 Uhr schrieb Rémi Bernon > <rbernon(a)codeweavers.com>: >> @@ -1218,8 +1229,9 @@ type_t *type_parameterized_type_specialize_declare(type_t *type, typeref_list_t >> new_type->namespace = type->namespace; >> new_type->name = format_parameterized_type_name(type, params); >> reg_type(new_type, new_type->name, new_type->namespace, 0); >> - new_type->c_name = format_parameterized_type_c_name(type, params, ""); >> + new_type->c_name = format_parameterized_type_c_name(type, params, "", "_C"); >> new_type->short_name = format_parameterized_type_short_name(type, params, ""); >> + new_type->param_name = format_parameterized_type_c_name(type, params, "", "__C"); >> >> if (new_type->type_type == TYPE_DELEGATE) >> { > > The patch works great, but declared types from imported IDLs aren't > found. (E.g. IVectorView<HSTRING > from windows.foundation.idl) > To fix this add > new_type->signature = format_parameterized_type_signature(type, params); > here. > > Bernhard Thanks, I think this is actually a separate issue, and it will need a bit more investigation as this change doesn't seem to work with some of the classes already in the IDLs. Cheers, -- Rémi Bernon <rbernon(a)codeweavers.com>

Jan. 25, 2022

Re: [v2 PATCH vkd3d 2/4] vkd3d-shader/hlsl: Cast round() input to float.

by Zebediah Figura (she/her)

On 1/21/22 05:04, Giovanni Mascellani wrote: > Hi, > > Il 20/01/22 19:20, Matteo Bruni ha scritto: >>>>>> I wonder if that's what it should do in the first place? >>>>> Yes, witness the following shader: >>>>> >>>>> --- >>>>> >>>>> uint func(float x) { return 1; } >>>>> uint func(half x) { return 2; } >>>>> >>>>> float4 main(void) : sv_target >>>>> { >>>>> return float4(func(float(0)), func(half(0)), func(int(0)), >>>>> func(uint(0))); >>>>> } >>>>> >>>>> --- >>>>> >>>>> Native reduces this to (1, 2, 1, 1). >>>> Fun... But at least it means we can fix add_implicit_conversion() and >>>> avoid that kind of workarounds, if I understand correctly. >>> I... guess, but it seems janky. The main point of >>> add_implicit_conversion() is for stuff like assignment RHS or return >>> values. If we had add_implicit_conversion() pass through half it'd >>> generate IR like >>> >>> 2: half | 1.0 >>> 3: | x = @2 >>> 4: float | x >>> >>> >>> (i.e. "x" is a float variable). Which... works, I guess? Maybe it's not >>> that bad, since we already do a somewhat similar thing for scalar vs >>> vec1. >> I think that's an improvement to the current state of things, right >> now we're effectively losing information from the get-go. We can >> always add a half-to-float lowering pass to simplify the IR. > > I don't really understand what Zeb's proposed fragment of code have to > do with implicit conversions (that seems mostly a test about overload > resolution), and I don't understand why and how implicit conversions > should treat half in a special way. Overload resolution and implicit conversion are essentially two strategies for dealing with what that code fragment demonstrates. > > Also, I don't think we should mix types in the IR without casts. If > we're doing the same for vec1 vs scalar, I think we should rather fix > that than introduce other mistypings. I don't think this is a desirable invariant to keep. It makes a lot of transformations harder for no reason (e.g. you can't "just" peephole two subsequent instructions anymore; you now have to deal with a possible identity conversion between them). By the time we get out of the parser we really shouldn't be doing type validation anyway.

Jan. 25, 2022

Re: [PATCH] widl: Add support for the [overload] attribute.

by Rémi Bernon

Signed-off-by: Rémi Bernon <rbernon(a)codeweavers.com>

Jan. 25, 2022

Re: [PATCH vkd3d v2 1/3] vkd3d-shader/hlsl: Handle branches in copy propagation.

by Zebediah Figura (she/her)

On 1/21/22 03:15, Giovanni Mascellani wrote: > Hi, > > Il 21/01/22 03:19, Zebediah Figura (she/her) ha scritto: >>> - if (entry) >>> - return RB_ENTRY_VALUE(entry, struct >>> copy_propagation_var_def, entry); >>> - else >>> - return NULL; >>> + if (var_def->values[component].state != >>> VALUE_STATE_NOT_WRITTEN) >> >> Why not just check for VALUE_STATE_STATICALLY_WRITTEN? > > It's not the same thing. If the value has been dynamically written I > have to stop searching, it's the answer the caller needs to get. > Otherwise I risk returning an outer statically written value enabling an > invalid optimization. Ah, right, I can't read... I would suggest folding the subsequent check for VALUE_STATE_STATICALLY_WRITTEN into this function, though. > >>> + for (i = 0; i < 4; ++i) >>> + { >>> + if (writemask & (1u << i)) >>> + { >>> + memset(&var_def->values[offset + i], 0, >>> sizeof(var_def->values[offset + i])); >> >> This memset() doesn't seem necessary anymore. > > I agree it is not, given that when the value is not statically written, > node and component should not even be checked. I thought it would be > cleaner to reset them to zero anyway (e.g., it might help debugging in > the future), but if it bothers you I can remove it. I don't feel strongly about it, but we don't tend to bother zeroing invalidated pointers as a rule. >>> static void copy_propagation_invalidate_whole_variable(struct >>> copy_propagation_var_def *var_def) >>> { >>> + unsigned i; >>> + >>> TRACE("Invalidate variable %s.\n", var_def->var->name); >>> + >>> memset(var_def->values, 0, sizeof(*var_def->values) * >>> var_def->var->data_type->reg_size); >> >> Note that you don't need this memset() anymore either. > > Same as above. > >> As an alternative, you could iterate over the whole state, marking the >> parent as "dynamically written" wherever the child state is written. > > That's what I did in my first implementation, and from some point of > view it would be nicer, but it doesn't play well with loops, because > there you have to know what you are going to invalidate before iterating > into the loop itself. Having two different ways to invalidate the outer > state looks like a useless amount of code to maintain, so I think it is > better to just do this way (copy_propagation_invalidate_from_block()). Ah, right. I probably knew that already but forgot. In that case can you please add a comment so I don't forget again?

Jan. 25, 2022

Re: [PATCH 3/5] widl: Fix nested parameterized types C / short name output.

by Bernhard Kölbl

Am Di., 25. Jan. 2022 um 10:13 Uhr schrieb Rémi Bernon <rbernon(a)codeweavers.com>: > @@ -1218,8 +1229,9 @@ type_t *type_parameterized_type_specialize_declare(type_t *type, typeref_list_t > new_type->namespace = type->namespace; > new_type->name = format_parameterized_type_name(type, params); > reg_type(new_type, new_type->name, new_type->namespace, 0); > - new_type->c_name = format_parameterized_type_c_name(type, params, ""); > + new_type->c_name = format_parameterized_type_c_name(type, params, "", "_C"); > new_type->short_name = format_parameterized_type_short_name(type, params, ""); > + new_type->param_name = format_parameterized_type_c_name(type, params, "", "__C"); > > if (new_type->type_type == TYPE_DELEGATE) > { The patch works great, but declared types from imported IDLs aren't found. (E.g. IVectorView<HSTRING > from windows.foundation.idl) To fix this add new_type->signature = format_parameterized_type_signature(type, params); here. Bernhard

Jan. 25, 2022

[PATCH v2 2/2] msxml3: Make utf-8 the default encoding.

by Daniel Lehman

Jan. 25, 2022

[PATCH v2 1/2] msxml3/tests: Add test saving XML with non-english characters.

by Daniel Lehman

v2: added some Releases

Jan. 25, 2022

Re: [PATCH v10 1/2] kernel32/tests: Test module refcounting with forwarded exports.

by Marvin

Hi, While running your changed tests, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at: https://testbot.winehq.org/JobDetails.pl?Key=105949 Your paranoid android. === w7u_adm (32 bit report) === kernel32: comm.c:859: Test failed: WaitCommEvent failed with a timeout comm.c:880: Test failed: WaitCommEvent error 0 comm.c:881: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:886: Test failed: WaitCommEvent used 1513 ms for waiting === w7u_2qxl (32 bit report) === kernel32: debugger.c:1027: Test failed: ole32.dll was not reported === w7u_adm (32 bit report) === kernel32: debugger.c:1027: Test failed: ole32.dll was not reported === w7u_el (32 bit report) === kernel32: debugger.c:1027: Test failed: ole32.dll was not reported === w8 (32 bit report) === kernel32: debugger.c:1217: Test failed: dwDebugEventCode = 4 debugger.c:1223: Test failed: dwDebugEventCode = 4 debugger.c:1225: Test failed: ExceptionCode = 0 debugger.c:1244: Test failed: dwDebugEventCode = 1 debugger.c:161: Test failed: wrong size for 'C:\Users\winetest\AppData\Local\Temp\wt44DE.tmp': read=0 debugger.c:415: Test failed: unexpected event pid === w1064_tsign (32 bit report) === kernel32: debugger.c:155: Test failed: unable to open 'C:\Users\winetest\AppData\Local\Temp\wt5B8D.tmp' debugger.c:155: Test failed: failed to open: C:\Users\winetest\AppData\Local\Temp\wt5B8D.tmp debugger.c:676: Test failed: the child and debugged pids don't match: 6052 != 3528 === w1064_tsign (64 bit report) === kernel32: debugger.c:155: Test failed: unable to open 'C:\Users\winetest\AppData\Local\Temp\wt59D8.tmp' debugger.c:155: Test failed: failed to open: C:\Users\winetest\AppData\Local\Temp\wt59D8.tmp debugger.c:676: Test failed: the child and debugged pids don't match: 5540 != 2988 === w10pro64 (testbot log) === WineRunTask.pl:error: The previous 1 run(s) terminated abnormally === w1064_tsign (64 bit report) === kernel32: loader.c:720: Test failed: 1197: wrong status c0000131/c000011b loader.c:720: Test failed: 1197: wrong status c0000131/c000011b loader.c:720: Test failed: 1197: wrong status c0000131/c0000130 loader.c:720: Test failed: 1197: wrong status c0000131/c000011b loader.c:720: Test failed: 1197: wrong status c0000131/c000011b loader.c:720: Test failed: 1197: wrong status c0000131/c000011b loader.c:720: Test failed: 1197: wrong status c0000131/c000011b loader.c:720: Test failed: 1197: wrong status c0000131/c000011b loader.c:720: Test failed: 1197: wrong status c0000131/c000011b loader.c:720: Test failed: 1197: wrong status c0000131/c000011b loader.c:720: Test failed: 1197: wrong status c0000131/c000011b loader.c:720: Test failed: 1197: wrong status c0000131/c000011b loader.c:720: Test failed: 1197: wrong status c0000131/c000011b loader.c:720: Test failed: 1214: wrong status c0000131/c0000130 loader.c:720: Test failed: 1219: wrong status c0000131/c0000130 loader.c:720: Test failed: 1224: wrong status c0000131/c000007b loader.c:720: Test failed: 1229: wrong status c0000131/c000007b loader.c:720: Test failed: 1234: wrong status c0000131/c000007b loader.c:720: Test failed: 1239: wrong status c0000131/c000007b loader.c:720: Test failed: 1244: wrong status c0000131/c000007b loader.c:720: Test failed: 1260: wrong status c0000131/0 loader.c:720: Test failed: 1264: wrong status c0000131/0 loader.c:720: Test failed: 1269: wrong status c0000131/0 === w10pro64_ja (64 bit report) === kernel32: loader.c:720: Test failed: 1219: wrong status c000011b/c0000130 loader.c:720: Test failed: 1224: wrong status c000011b/c000007b loader.c:720: Test failed: 1229: wrong status c000011b/c000007b loader.c:720: Test failed: 1234: wrong status c000011b/c000007b loader.c:720: Test failed: 1239: wrong status c000011b/c000007b loader.c:720: Test failed: 1244: wrong status c000011b/c000007b loader.c:720: Test failed: 1260: wrong status c000011b/0 loader.c:720: Test failed: 1264: wrong status c000011b/0 loader.c:720: Test failed: 1269: wrong status c000011b/0 loader.c:720: Test failed: 1273: wrong status c000011b/0 loader.c:720: Test failed: 1277: wrong status c000011b/0 loader.c:720: Test failed: 1431: wrong status c000011b/c000007b loader.c:720: Test failed: 1439: wrong status c000011b/c000007b === w10pro64_zh_CN (64 bit report) === kernel32: loader.c:720: Test failed: 1219: wrong status c000011b/c0000130 loader.c:720: Test failed: 1224: wrong status c000011b/c000007b loader.c:720: Test failed: 1229: wrong status c000011b/c000007b loader.c:720: Test failed: 1234: wrong status c000011b/c000007b loader.c:720: Test failed: 1239: wrong status c000011b/c000007b loader.c:720: Test failed: 1244: wrong status c000011b/c000007b loader.c:720: Test failed: 1260: wrong status c000011b/0 loader.c:720: Test failed: 1264: wrong status c000011b/0 loader.c:720: Test failed: 1269: wrong status c000011b/0 loader.c:720: Test failed: 1273: wrong status c000011b/0 loader.c:720: Test failed: 1277: wrong status c000011b/0 loader.c:720: Test failed: 1431: wrong status c000011b/c000007b loader.c:720: Test failed: 1439: wrong status c000011b/c000007b loader.c:720: Test failed: 1444: wrong status c000011b/0 loader.c:724: Test failed: 1444: failed with c000011b expected fallback loader.c:720: Test failed: 1450: wrong status c000011b/0 loader.c:724: Test failed: 1450: failed with c000011b expected fallback loader.c:720: Test failed: 1456: wrong status c000011b/0 loader.c:724: Test failed: 1456: failed with c000011b expected fallback loader.c:720: Test failed: 1463: wrong status c000011b/0 loader.c:724: Test failed: 1463: failed with c000011b expected fallback loader.c:720: Test failed: 1469: wrong status c000011b/0 loader.c:720: Test failed: 1478: wrong status c000011b/0 loader.c:720: Test failed: 1482: wrong status c000011b/0 loader.c:720: Test failed: 1486: wrong status c000011b/0 loader.c:720: Test failed: 1490: wrong status c000011b/0 === debian11 (32 bit Chinese:China report) === kernel32: change.c:309: Test failed: should be ready change.c:339: Test failed: should be ready

Jan. 25, 2022

Re: Arbitrary DOS device name

by Daniel Kucera

On 2022-01-24 12:26, Stefan Dösinger wrote: > Am Montag, 24. Jänner 2022, 13:13:23 EAT schrieb Daniel Kucera: > >> I am reversing the driver and I'll create a Linux char device to >> handle >> those ioctl calls and talk to the USB device using libusb. > > If I understand you right you want to create a > $WINEPREFIX/dosdevices/d6CDE-0 > link to whatever char device your Linux driver creates, and that > doesn't work > because Wine will only do that for COM ports and other drives? I can create the link but wine refuses to open the device because it doesn't match any of the defined device prefixes: https://github.com/wine-mirror/wine/blob/e909986e6ea5ecd49b2b847f321ad89b2a… > From Wine's point of view the proper solution is to load the original > Windows > device driver, have it talk to the USB hardware via libusb and the > Windows > software via the device it creates. Wine nowadays should have > infrastructure > to support that. I haven't used it myself though. I was researching this option but I haven't even found a way to load a driver. Besides, if the original driver doesn't work out-of-the-box (which I presume it won't), I am not really able to write/compile wine/Windows driver. > > Beyond opening the device name, how would the ioctl forward work? Is it > some > standard serial port ioctl that pass throuh Wine to your driver fine? > Or would > you need to teach Wine to forward them as well? So what works for me now is, that when I create the link COM81 -> /dev/hantek and create the device using cuse (https://libfuse.github.io/doxygen/cuse_8c.html) , the software is able to open the device: FUSE library version: 3.10.3 unique: 2, opcode: CUSE_INIT (4096), nodeid: 0, insize: 56, pid: 1568849 CUSE_INIT: 7.34 flags=0x00000001 CUSE_INIT: 7.31 flags=0x00000001 max_read=0x00020000 max_write=0x00100000 dev_major=0 dev_minor=0 dev_info: DEVNAME=hantek unique: 2, success, outsize: 103 unique: 4, opcode: OPEN (14), nodeid: 0, insize: 48, pid: 1568962 unique: 4, success, outsize: 32 unique: 6, opcode: IOCTL (39), nodeid: 0, insize: 72, pid: 1568962 unknown ioctld 21505 unique: 6, error: -22 (Invalid argument), outsize: 16 unique: 8, opcode: RELEASE (18), nodeid: 0, insize: 64, pid: 0 unique: 8, success, outsize: 16 The software is calling DeviceIoControl() which results in ioctl calls in wine server and ends here: https://github.com/wine-mirror/wine/blob/master/server/fd.c#L2408 To forward the call to device, I would need to modify this function, something in this sense: diff --git a/server/fd.c b/server/fd.c index 5d80e218b97..627b44fc195 100644 --- a/server/fd.c +++ b/server/fd.c @@ -2261,7 +2261,8 @@ int default_fd_ioctl( struct fd *fd, ioctl_code_t code, struct async *async ) unmount_device( fd ); return 1; default: - set_error( STATUS_NOT_SUPPORTED ); + ioctl(fd->unix_fd, code, ioctl_data); // how the get the call data here? + //set_error( STATUS_NOT_SUPPORTED ); return 0; } }

Jan. 25, 2022