April 2023 - Wine-gitlab - list.winehq.org

Re: [PATCH v2 0/4] MR174: Consolidate the TPF and d3dbc handling code.
by Zebediah Figura (＠zfigura) 21 Apr '23

21 Apr '23

> > I don't want to be insensitive to the concern, particularly since both Giovanni and you raised it, but I just don't get it? Navigating within a file seems at least as easy as navigating between files, and files on the order of \~2k lines in case of d3dbc.c and \~5k lines in case of tpf.c don't seem particularly unusual in either vkd3d or Wine. (I had been thinking we might as well merge hlsl.c, hlsl_codegen.c and hlsl_constant_ops.c, but I guess not then...) > > I suppose it depends a lot on one's own thought processes and habits, so I don't claim that what's better for me is intrinsecally better for everybody. Also, as you say, Wine's standards are much worse than what we're discussing here, so, while I don't think they are good standards, I had to come to terms with them. > > I agree with Zeb that having smaller files helps segregation of code, and if code is segregated properly with reasonable interfaces between the segregated parts it is easier (for me at least) to understand and change, because I can study each of the segregated parts somewhat independently. In theory it is not the number of lines or functions that counts, but in practice, with some exceptions, once a file has grown past a few thousands lines of code it's hard for me not to think that it would make good use of some splitting. Something like this. I find it hard to give an objective rationalization of *why* I want to split things up, but I think to a degree it comes down to the same reasons that large functions should be split up. It communicates to the reader that a piece of code is self-contained and should make sense by itself. On the other hand, when I see a large file, much like a large function, I can't help but think "can this be split up into a coherent set of pieces?" To a degree I guess it also is an intuitive judgement, and that can be poor. The cost of compiling large files shouldn't be discarded either, I don't think. E.g. our d3d12.c test file (or d3d11.c, and so on) doesn't really need to be split from an architectural standpoint—yes, the tests *can* stand alone, but there's no common thread segregating any one group of tests from another, and splitting *every* test into its own file seems excessive. No, if something makes me want to split up that file, it's that it takes multiple seconds to compile (depending on machine). I don't think there's any concern regarding navigation, at least on my part. That said, it's also something that feels like a waste of time to argue a lot about. I didn't feel like hlsl_constant_ops.c was particularly necessary, and would probably have just kept it in hlsl_codegen.c if it was just me, but it also doesn't feel like it's worth bikeshedding at all. Nor do I really intend to argue about splitting up the backend readers and writers here, just make a vague comment about code organization and move on. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/174#note_30876

1 0

[PATCH 0/1] MR2685: msvcrt: Fix crash when rethrowing after a non-C++ exception on x86_64.
by Brendan Shanks (＠bshanks) 21 Apr '23

21 Apr '23

This fixes a crash seen with the .NET Framework 3.5 SP1 installer in a 64-bit prefix where `ServiceModelReg.exe` throws a C++ exception, it's rethrown again, then a CLR exception (`0xe0434f4d`) exception is thrown, and finally there's another C++ rethrow. At the last rethrow, `cxx_frame_handler()` detects the rethrow and sets `*rec` to the previous exception record, which is the CLR exception, not the C++ exception. If `+seh` is enabled, it then assumes `*rec` is a C++ exception and tries to TRACE info about it, which crashes. Move the rethrow detection before the exception type check, so the TRACEs are not done. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2685

3 2

[PATCH v3 0/4] MR2688: tasklist: Add basic functionality.
by Zhiyi Zhang (＠zhiyi) 21 Apr '23

21 Apr '23

Company of Heroes: Battle of Crete needs a functioning tasklist.exe to exit properly. -- v3: tasklist: Partially support '/fi' option. tasklist: Support '/fo' option. tasklist: Support '/nh' option. https://gitlab.winehq.org/wine/wine/-/merge_requests/2688

4 9

[PATCH 0/11] MR2691: mshtml: More ref leak fixes.
by Gabriel Ivăncescu 21 Apr '23

21 Apr '23

This should finally fix the ref leaks that keep all gecko nsDocuments alive even on the most basic docs. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2691

2 14

[PATCH v26 0/4] MR1148: ntdll: Mark created files beginning with a dot as not hidden.
by Torge Matthies (＠tmatthies) 21 Apr '23

21 Apr '23

Fixes bug [53826](https://bugs.winehq.org/show_bug.cgi?id=53826). -- v26: 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 inside get_file_info instead of after it. ntdll/tests: Add test for file attributes of files with names beginning with a dot. https://gitlab.winehq.org/wine/wine/-/merge_requests/1148

2 6

[PATCH 0/1] MR175: vkd3d-shader/tpf: Return unsigned int from hlsl_sm4_register_from_semantic().
by Zebediah Figura (＠zfigura) 21 Apr '23

21 Apr '23

Fix a compile warning: ../vkd3d/libs/vkd3d-shader/hlsl_codegen.c: In function 'allocate_semantic_register': ../vkd3d/libs/vkd3d-shader/hlsl_codegen.c:2947:85: error: passing argument 4 of 'hlsl_sm4_register_from_semantic' from incompatible pointer type [-Werror=incompatible-pointer-types] 2947 | if ((builtin = hlsl_sm4_register_from_semantic(ctx, &var->semantic, output, &type, NULL, &has_idx))) | ^~~~~ | | | unsigned int * In file included from ../vkd3d/libs/vkd3d-shader/hlsl_codegen.c:21: ../vkd3d/libs/vkd3d-shader/hlsl.h:1171:52: note: expected 'enum vkd3d_sm4_register_type *' but argument is of type 'unsigned int *' 1171 | bool output, enum vkd3d_sm4_register_type *type, enum vkd3d_sm4_swizzle_type *swizzle_type, bool *has_idx); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~ -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/175

4 3

[PATCH v10 0/1] MR150: vkd3d-shader/hlsl: Ignore "unroll" attribute for loops.
by Nikolay Sivov (＠nsivov) 21 Apr '23

21 Apr '23

-- v10: vkd3d-shader/hlsl: Ignore "unroll" attribute for loops. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/150

3 3

[PATCH v4 0/2] MR172: vkd3d-shader/hlsl: Implement SampleBias().
by Nikolay Sivov (＠nsivov) 21 Apr '23

21 Apr '23

-- v4: vkd3d-shader/hlsl: Implement SampleBias() method. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/172

2 2

[PATCH v3 0/2] MR172: vkd3d-shader/hlsl: Implement SampleBias().
by Nikolay Sivov (＠nsivov) 21 Apr '23

21 Apr '23

-- v3: vkd3d-shader/hlsl: Implement SampleBias() method. vkd3d-shader/hlsl: Add separate helpers to generate object methods. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/172

3 5

Re: [PATCH v2 0/4] MR174: Consolidate the TPF and d3dbc handling code.
by Giovanni Mascellani (＠giomasce) 21 Apr '23

21 Apr '23

> I don't want to be insensitive to the concern, particularly since both Giovanni and you raised it, but I just don't get it? Navigating within a file seems at least as easy as navigating between files, and files on the order of \~2k lines in case of d3dbc.c and \~5k lines in case of tpf.c don't seem particularly unusual in either vkd3d or Wine. (I had been thinking we might as well merge hlsl.c, hlsl_codegen.c and hlsl_constant_ops.c, but I guess not then...) I suppose it depends a lot on one's own thought processes and habits, so I don't claim that what's better for me is intrinsecally better for everybody. Also, as you say, Wine's standards are much worse than what we're discussing here, so, while I don't think they are good standards, I had to come to terms with them. I agree with Zeb that having smaller files helps segregation of code, and if code is segregated properly with reasonable interfaces between the segregated parts it is easier (for me at least) to understand and change, because I can study each of the segregated parts somewhat independently. In theory it is not the number of lines or functions that counts, but in practice, with some exceptions, once a file has grown past a few thousands lines of code it's hard for me not to think that it would make good use of some splitting. For example, I would find ideal to have `hlsl_codegen.c` splitted in a few pieces. The prepend/append copies and copy propagation sections could be easily moved to an independent file each one, keeping basically everything `static` except a handful of functions that are called by `hlsl_emit_bytecode()`. You have a small interface, but everything else you have to do in copy propagation doesn't need to interact with all the rest of `hlsl_codegen.c`, and splitting the file ensures that. If somebody wants to learn how copy propagation works, they can read `hlsl_copy_propagation.c` instead of having to potentially have to go through the whole of `hlsl_codegen.c`. This luckily already happened for `hlsl_constant_ops.c`. I wouldn't move each other pass in its own file because that would be too small, though. There is some sweet spot, which of course can change from person to person. As for `tpf.c`, the parser and writer parts are basically completely independent. They don't even share the internal representation. When I am working on the parser it's unlikely that I care about the writer at all. So having them in the same place is just confusing for me. Since they need to share some code (mostly the definitions) it makes sense to move that in a shader header, as it was before. If, say, I want to refactor how an hypothetical field `type` is used, then I'm likely to search through the file for that identifier. And if unrelated code sits in the same file, I'll have a lot more false positives. As I said above, that's probably a very personal thing, and having bigger files is not a blocker for me. Just wanted to share my point of view. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/174#note_30845

1 0