October 2022 - Wine-GitLab - list.winehq.org

Re: [PATCH v6 0/2] MR979: d3d9: Implement d3dx_effect_SetRawValue
by Matteo Bruni (＠Mystral) Oct. 26, 2022

Oct. 26, 2022

On Wed Oct 19 09:55:18 2022 +0000, Patrick Hibbs wrote: > The same issue with strings occurs with Texture and shader types. > I.e. Paramater is rendered irretrievable. Calling it's relevant GetXXX() > function causes a crash if it's a scalar. Calling GetParamaterByName() > will return an invalid handle. Oh, interesting. GetParameterByName() failing afterwards is probably an indication that the SetRawValue() call overwrote parts of some internal data structure and broke the effect object to some degree. BTW, you're supposed to set texture parameters to a IDirect3DBaseTexture9 / IUnknown pointer (and similarly the value for a string parameter should probably be a string pointer rather than the string contents). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/979#note_12212

1 0

Re: [PATCH v6 0/2] MR979: d3d9: Implement d3dx_effect_SetRawValue
by Matteo Bruni (＠Mystral) Oct. 26, 2022

Oct. 26, 2022

On Wed Oct 19 09:48:02 2022 +0000, Patrick Hibbs wrote: > Actually it seems that the strings are rendered irretrievable by the > call to SetRawValue(). > Calling GetString() on a scalar string after the destruction causes a > crash in win10. While calling it with a string vector doesn't crash, but > returns D3DERR_INVALIDCALL instead. > I've updated the tests in v3 of the patch to check for this. Ah, that explains it I guess. Weird, but not too surprising. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/979#note_12211

1 0

Re: [PATCH v6 0/2] MR979: d3d9: Implement d3dx_effect_SetRawValue
by Matteo Bruni (＠Mystral) Oct. 26, 2022

Oct. 26, 2022

On Wed Oct 19 11:23:25 2022 +0000, Patrick Hibbs wrote: > Sorry about the unexpected push, I'll be more careful next time. > With regards to the bool fixups, are we sure we want to just write the > raw data given to us? I ask because I've also noticed that SetRawValue() > has a tendency to promote datatypes when given a single value and a > vector / matrix paramater. I.e. float and int become a float4 and int4 > respectively for both vectors and matrices. (MSDN calls this behavior a > "cast.") This results in the next 3 values in the paramater's buffer > being set to zero. > Assuming SetRawValue() shouldn't fix the bool values itself, should it > also avoid fixing the ints and floats? If so, how should we indicate the > need for a fixup to other functions? There doesn't seem to be any > infrastructure to support that in wine currently. (We could abuse the > paramater block support for that, but see the speculation below.) > The float and int promotions were the reason I didn't clear the > paramater after each test. As doing so would cause us to miss the writes > to the next 3 values in the paramater. As they would already be set to > zero before the call. Should I still go ahead and clear the paramaters > after each test anyway? > As a dirty hack, I added a call to zero out the paramaters after each > test with a 4x4 matrix of zero ints in v3 of the test. That call is > commented out in the push, but if you enable it it will succeed for most > of the tests under win10. (I disabled it before I fixed the string test > crashes. So it may work fine now, I haven't checked.) I haven't tried > checking the paramaters after the current one for alterations. I was > going to put that in it's own set of tests. > This part is speculation but, if it is a valid use of SetRawValue() to > set adjacent paramaters regardless of type with one call, then the > entire set of paramaters for a given effect needs to be in the same > memory block. (Which seems to be not the case in wine, as there are > plenty of calls to heap_alloc() / heap_realloc() using the param->data > pointer in effect.c.) That would also imply that there is a specific > ordering of paramaters in memory as well. Which would need to be tested > for. If this behavior is combined with the bool assumption above, then > we'd also need to test for order of operations too. > Assuming all of that needs to be done, how do we split this up? Because > I have a feeling that this patchset is going to be rather large in > scope. (If all of the assumptions and speculation are true that is.) Unfortunately I keep being unable to reply promptly. Anyway... > With regards to the bool fixups, are we sure we want to just write the raw data given to us? I ask because I've also noticed that SetRawValue() has a tendency to promote datatypes when given a single value and a vector / matrix paramater. I.e. float and int become a float4 and int4 respectively for both vectors and matrices. (MSDN calls this behavior a "cast.") This results in the next 3 values in the paramater's buffer being set to zero. Is that what happens or is just the rest of the parameter being set to 0? > Assuming SetRawValue() shouldn't fix the bool values itself, should it also avoid fixing the ints and floats? How should they be fixed? I'm still assuming that SetRawValue() more or less does what it says i.e. it just sets the value of parameters by mere byte-for-byte copy, without any kind of conversion or fixup. Do we have evidence that's not the case? > The float and int promotions were the reason I didn't clear the paramater after each test. As doing so would cause us to miss the writes to the next 3 values in the paramater. As they would already be set to zero before the call. Should I still go ahead and clear the paramaters after each test anyway? It might make sense to clear them to a non-zero value (e.g. some variation of the usual 0xdeadbeef marker) to make those results more evident. > This part is speculation but, if it is a valid use of SetRawValue() to set adjacent paramaters regardless of type with one call, then the entire set of paramaters for a given effect needs to be in the same memory block. (Which seems to be not the case in wine, as there are plenty of calls to heap_alloc() / heap_realloc() using the param->data pointer in effect.c.) That would also imply that there is a specific ordering of paramaters in memory as well. Which would need to be tested for. If this behavior is combined with the bool assumption above, then we'd also need to test for order of operations too. Yes, that wouldn't quite work right away. It's fine to just add a FIXME() for straddling parameters for the time being, if it turns out that native actually supports that. Similarly for the test. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/979#note_12210

1 0

[PATCH 0/2] MR12: vkd3d: Add Windows implementation of vkd3d_set_thread_name().
by Brendan Shanks (＠bshanks) Oct. 26, 2022

Oct. 26, 2022

-- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/12

4 7

[PATCH 0/1] MR1168: wbemprox: WQL string comparisons are case insensitive.
by Hans Leidekker (＠hans) Oct. 26, 2022

Oct. 26, 2022

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53832 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1168

2 1

[PATCH v9 0/10] MR1148: ntdll: Mark created files beginning with a dot as not hidden.
by Torge Matthies (＠tmatthies) Oct. 26, 2022

Oct. 26, 2022

Also unifies hidden file handling. Fixes bug [53826](https://bugs.winehq.org/show_bug.cgi?id=53826). -- v9: ntdll: Try to avoid requesting the file name for a handle. ntdll: Ensure that attributes are kept the same when renaming or hard-linking a file. https://gitlab.winehq.org/wine/wine/-/merge_requests/1148

3 11

[PATCH 0/2] MR1156: Allow a loaded registry key to be loaded multiple times.
by Santino Mazza (＠tati1454) Oct. 26, 2022

Oct. 26, 2022

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/1156

4 4

[PATCH v8 0/10] MR1148: ntdll: Mark created files beginning with a dot as not hidden.
by Torge Matthies (＠tmatthies) Oct. 26, 2022

Oct. 26, 2022

Also unifies hidden file handling. Fixes bug [53826](https://bugs.winehq.org/show_bug.cgi?id=53826). -- v8: ntdll: Try to avoid requesting the file name for a handle. https://gitlab.winehq.org/wine/wine/-/merge_requests/1148

3 12

[PATCH v7 0/10] MR1148: ntdll: Mark created files beginning with a dot as not hidden.
by Torge Matthies (＠tmatthies) Oct. 26, 2022

Oct. 26, 2022

Also unifies hidden file handling. Fixes bug [53826](https://bugs.winehq.org/show_bug.cgi?id=53826). -- v7: ntdll: Try to avoid requesting the file name for a handle. ntdll: Ensure that attributes are kept the same when renaming a file. ntdll: Set xattr in NtCreateFile if inferred and requested attributes don't match. ntdll: Only infer hidden attribute from file name if xattr is not present. ntdll: Handle hidden file names in fd_get_file_info. ntdll: Pass file path into fd_get_file_info if available. ntdll: Do not compute file attributes for info classes that don't need them. ntdll: Handle hidden file names inside get_file_info instead of after it. ntdll: Do not open-code hidden file handling in get_dir_data_entry. ntdll/tests: Add test for file attributes of files with names beginning with a dot. https://gitlab.winehq.org/wine/wine/-/merge_requests/1148

3 11

[PATCH v7 0/3] MR1164: Draft: gdiplus: add initial CompoundLine support to fix application crash
by Bartosz Kosiorek (＠gang65) Oct. 26, 2022

Oct. 26, 2022

Wine-bug: https://bugs.winehq.org/show_bug.cgi?id=52196 -- v7: gdiplus: add GdipGetPenCompoundArray implementation gdiplus: add GdipGetPenCompoundCount implementation gdiplus: add GdipSetPenCompoundArray implementation https://gitlab.winehq.org/wine/wine/-/merge_requests/1164

3 4