May 2023 - wine-gitlab

Re: [PATCH v4 0/1] MR2795: d3dx9_36: Stub D3DXComputeTangent
by Zebediah Figura (＠zfigura) 12 May '23

12 May '23

Does this actually make the program work? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2795#note_32669

1 0

Re: [PATCH v4 0/1] MR2795: d3dx9_36: Stub D3DXComputeTangent
by Matteo Bruni (＠Mystral) 12 May '23

12 May '23

Matteo Bruni (@Mystral) commented about dlls/d3dx9_36/mesh.c: > return hr; > } > > +/************************************************************************* > + * D3DXComputeTangent (D3DX9_36.@) > + */ Your choice, but I would just get rid of this comment header. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2795#note_32668

1 0

Re: [PATCH v4 0/1] MR2795: d3dx9_36: Stub D3DXComputeTangent
by Matteo Bruni (＠Mystral) 12 May '23

12 May '23

Matteo Bruni (@Mystral) commented about dlls/d3dx9_36/mesh.c: > return hr; > } > > +/************************************************************************* > + * D3DXComputeTangent (D3DX9_36.@) > + */ > +HRESULT WINAPI D3DXComputeTangent(ID3DXMesh *mesh, const DWORD stage_idx, DWORD tangent_idx, > + DWORD binorm_idx, DWORD wrap, const DWORD *adjacency) > +{ > + FIXME("mesh %p, stage_idx %lu, tangent_idx %lu, binorm_idx %lu, wrap %lu, adjacency %p.\n", We usually end FIXME messages for stubs with "stub!\n". -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2795#note_32667

1 0

Re: [PATCH v4 0/1] MR2795: d3dx9_36: Stub D3DXComputeTangent
by Matteo Bruni (＠Mystral) 12 May '23

12 May '23

Matteo Bruni (@Mystral) commented about dlls/d3dx9_36/mesh.c: > return hr; > } > > +/************************************************************************* > + * D3DXComputeTangent (D3DX9_36.@) > + */ > +HRESULT WINAPI D3DXComputeTangent(ID3DXMesh *mesh, const DWORD stage_idx, DWORD tangent_idx, That "const" shouldn't be there. I guess it doesn't matter in practice but it does look quite weird. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2795#note_32666

1 0

[PATCH 0/5] MR2805: winemac: High-res/retina mode fixes
by Brendan Shanks (＠bshanks) 12 May '23

12 May '23

This fixes two issues: - since WineContentView became layer-backed in Wine 6.17, windows do not display correctly on a non-retina monitor when high-res/retina mode is enabled. (The needed downscaling was not being done). - additionally on macOS 10.13 and earlier, the desired minification/downscaling filter was being ignored, causing poor image quality. Enabling rasterization for the layer seems to work around this and uses the correct filter. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2805

2 5

[PATCH v2 0/4] MR2800: ntdll/heap: Reduce memory footprint by better matching Windows subheap sizes
by Paul Gofman (＠gofman) 12 May '23

12 May '23

Turns out Windows is more conservative both in initial allocation when creating new heap and also in growing the heap. Comments: - Without patch 1 the related test in test_block_layout fails on x64 for me ("unexpected padding") after the last patch. I don't think the last patches really changes much in this regard, looks like the test just depends on the uninitialized data; - Without patch 2 test_HeapCreate fails (line 601 where it checks the last block pointer). I think it is also only triggered by my patch, I think that last block detection only works correctly now when commit size is smaller than the subheap size (which happens to be not the case in the test after the last patch); - The last patch extends a bit a todo in test_block_layout(). The actual reason for (extended) todo is that we are probably not handling pending free blocks quite like on Windows. I watched the pointers on Windows in the same test and they are always withing the same subheap allocation which suggests that Windows might be reusing pending free block once it can't find normal free block and before extending the heap. So the last patch changes subheap sizes and that triggers different subheaps for the allocated pointers in Wine. So it looks like not an actual issue with my patch. Reusing pending free pointers is apparently possible to implement but it seems to me that it doesn't worth the trouble until anything depends on that (since those pending free blocks are only there when heap debug flags are enabled which is rarely the case outside of debugging). -- v2: ntdll: Better match Windows subheap sizes. kernel32/tests: Add tests for subheap sizes. ntdll: Fix last block detection in heap_walk_blocks(). ntdll: Fix tail padding in mark_block_tail(). https://gitlab.winehq.org/wine/wine/-/merge_requests/2800

2 5

[PATCH 0/4] MR2800: ntdll/heap: Reduce memory footprint by better matching Windows subheap sizes
by Paul Gofman (＠gofman) 12 May '23

12 May '23

Turns out Windows is more conservative both in initial allocation when creating new heap and also in growing the heap. Comments: - Without patch 1 the related test in test_block_layout fails on x64 for me ("unexpected padding") after the last patch. I don't think the last patches really changes much in this regard, looks like the test just depends on the uninitialized data; - Without patch 2 test_HeapCreate fails (line 601 where it checks the last block pointer). I think it is also only triggered by my patch, I think that last block detection only works correctly now when commit size is smaller than the subheap size (which happens to be not the case in the test after the last patch); - The last patch extends a bit a todo in test_block_layout(). The actual reason for (extended) todo is that we are probably not handling pending free blocks quite like on Windows. I watched the pointers on Windows in the same test and they are always withing the same subheap allocation which suggests that Windows might be reusing pending free block once it can't find normal free block and before extending the heap. So the last patch changes subheap sizes and that triggers different subheaps for the allocated pointers in Wine. So it looks like not an actual issue with my patch. Reusing pending free pointers is apparently possible to implement but it seems to me that it doesn't worth the trouble until anything depends on that (since those pending free blocks are only there when heap debug flags are enabled which is rarely the case outside of debugging). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2800

3 10

[PATCH 0/4] MR2002: Draft: RFC: Extend winetest with multi-arch capabilities.
by eric pouech (＠epo) 12 May '23

12 May '23

Rationale: - currently, winetest is built either as a 32bit exec or a 64bit exec, containaing a bunch of tests of same bitness. - there's no simple support for having parent process in one bitness, and child process in a different bitness. - lots of cases are not covered in ntdll, kernel32 and kernelbase tests. - there are here and there a couple of tweaks to workaround this, but nothing a bit solid. Attached is a proposal to extend winetest to support better these use cases: - the idea is to add an extra-option to winetest.exe (64bit) passing the path to the corresponding winetest.exe (32bit). - when running test X (64bit), the path to corresponding test X (32bit) will be passed to test X (64 bit), allowing it to trigger test with test X (32bit). - nothing more is provided: it's up to the test designer to decide whether to use the 32bit child (and to adapt potentially the test) to cope with the difference in bitness between parent and child. - this can be used either in current wow64 setup, and also in multi-arch wow64 setup (just need to change the patch to 32bit winetest.exe) There's an example of such test at the end of the serie. Comments, ideas welcomed. And especially if it's something worth continuing. Note: - this is first shot at it, it should be improved (especially in ensuring that the 32bit/64bit pair is correct). A+ -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2002

2 5

[PATCH 0/3] MR2497: Modules list handling in dbghelp.
by eric pouech (＠epo) 12 May '23

12 May '23

The aim of this series is to re-implement dbghelp.EnumerateLoadedModules* in order to match Windows' behavior (especially in wow64 environments). The serie includes: - a bunch of tests to compare 3 different sets of loaded modules: + the load DLL debug events (generated by kernel) + the output of dbghelp.EnumerateLoadedModules(), which is a wrapper around kernel32.EnumProcesModulesEx (yet modifying some information) + the actual list of loaded modules in dbghelp (SymEnumerateModules). => the later list can be populated automatically from the second if requested to dbghelp (this is what is tested). => for the record, winedbg uses the first set to populate the third set. We just test the content of first set, not the population to the third. - the reimplementation of EnumerateLoadedModules to match Window's behavior (especially regarding paths information) Despite the three sets look similar, they have quite a few differences to be taken care of (especially in wow64 setup). Note: having the correct paths (esp. in wow64) is important as dbghelp sometimes tries some wild guesses based on the path (like bitness <g>) or (in some other places) don't rely on path information and retries things on its own. The long target is to simplify the module lookup by relying on more solid information. @julliard: the paths for wow64 modules returned from kernel32 don't match windows behavior: wine returns 32bit system modules from c:\windows\syswow64 whereas windows returns them from c:\windows\system32 (except a couple of exceptions: 32bit ntdll and exe main module). Implementation in dbghelp includes the correction of this. (I opted not to change ntdll at once: testing on windows show that kernel32.EnumProcesModulesEx returns exactly the ldr_data list, and I didn't feel like adding this burden to this patch ;-). Let me know if you want ntdll to be fixed before this patch. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2497

3 7

[PATCH v3 0/2] MR2578: Fixing module paths in LdrPath (corner case).
by eric pouech (＠epo) 12 May '23

12 May '23

The serie intent is to fix unexpected paths in module's list: This happens: - when running under old / (new) wow64 - when main module is located under the syswow64 directory - the 32 bit modules are stored in LdrData (and then exposed through a couple of ways) under syswow64 (they are normally stored under system32, letting the redirection come into play when needed) This triggers a couple of errors in winetest (as we're using c:\windows\syswow64\msinfo32.exe in many tests to trigger a wow64 process from a winetest program). This is the fix awaited in MR!2497. @julliard: I'm not 100% happy with the fix itself by reintroducting ref to the redirected DLLs in ntdll/PE but couldn't find a better idea. -- v3: ntdll,wow64: Unredirect DLLs filename before storing them into LdrData. kernel32: Harden some wow64 module tests. https://gitlab.winehq.org/wine/wine/-/merge_requests/2578

2 4

2025

2024

2023

2022

wine-gitlab May 2023