- 04 Dec, 2023 28 commits
-
-
Rémi Bernon authored
We often use "native" to talk about Windows "native" code, which is confusing here.
-
Paul Gofman authored
-
Zhiyi Zhang authored
-
Zhiyi Zhang authored
-
Zhiyi Zhang authored
pEntry could be freed after cache_container_unlock_index(pContainer, pHeader).
-
Zhiyi Zhang authored
process_entry->szExeFile has length of MAX_PATH but info->image_name only has 32.
-
Zhiyi Zhang authored
*pszTmpFileName will be freed with free() but it's allocated with HeapAlloc().
-
Zebediah Figura authored
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55591
-
Zebediah Figura authored
-
Zebediah Figura authored
Fixes: 370b8299
-
Zebediah Figura authored
-
Zebediah Figura authored
As with the previous commit, this is clearer and avoids a state ordering assumption.
-
Zebediah Figura authored
wined3d: Use context->stream_info.position_transformed instead of context->last_was_rhw in state handlers. Use of last_was_rhw in these state handlers is, firstly, confusing to read. The variable is actually supposed to be set for *this* draw, not the last one, and state handlers indeed expect that, but that fact isn't obvious. Reading from context->stream_info instead is clearer. Secondly, since last_was_rhw is set by the STATE_VDECL handler, any other state depending on it (including some, though not all, of the sites changed here) thus has an implicit state handler ordering assumption. This is, needless to say, fragile. context->stream_info is computed before state handlers, so that dependency is a bit less fragile.
-
Zebediah Figura authored
The comment was originally added in 4b831a5d. At that point, it referred only to non-FFP shader constants. Subsequently 38934fe7 moved bumpenv constant loading to the misc pipeline, apparently out of concerns that bumpenv constants might interact badly with shader constants. It's not clear whether those concerns were ever justified, and normal shader constants are now sufficiently untangled from each other anyway. However, bumpenv constants, like e.g. color keys, affect both FFP and non-FFP pipelines, so it makes the most sense for them to remain in the misc state table anyway.
-
Etaash Mathamsetty authored
-
Alex Henrie authored
-
Daniel Lehman authored
-
Nikolay Sivov authored
Signed-off-by: Nikolay Sivov <nsivov@codeweavers.com>
-
Nikolay Sivov authored
Signed-off-by: Nikolay Sivov <nsivov@codeweavers.com>
-
Nikolay Sivov authored
Signed-off-by: Nikolay Sivov <nsivov@codeweavers.com>
-
Nikolay Sivov authored
Signed-off-by: Nikolay Sivov <nsivov@codeweavers.com>
-
Piotr Caban authored
-
Piotr Caban authored
-
Zhiyi Zhang authored
push_dc_driver() places drivers based on their priorities, so the newly created driver is not necessarily on top. Thus in windrv_CreateDC(), find_dc_driver() should be used to find the DIB driver instead of assuming the DIB driver is the top driver, which could be the path driver because it has a higher priority. The exact wrong code path was: 1. A path driver with priority 400 is created for a DC. 2. windrv_CreateDC() is called to create a window driver for the DC. 3. Then in dibdrv_CreateDC(), push_dc_driver() is called with 'dev' pointing to the top driver, which is the path driver. 4. push_dc_driver() updates 'dev' to point to the address of the next driver because DIB driver has a lower 300 priority. 5. The DIB driver is assigned to 'dev', which is not the original parameter passed into push_dc_driver(). 6. In windrv_CreateDC(), get_dibdrv_pdev(*dev) is called, assuming the top driver is the DIB driver. But actually the top driver that '*dev' points to is still the path driver. The added tests can demonstrate the memory corruption before this fix is applied.
-
Alexandre Julliard authored
-
Alexandre Julliard authored
-
Alexandre Julliard authored
-
Alexandre Julliard authored
-
- 03 Dec, 2023 5 commits
-
-
Alexandre Julliard authored
-
Alexandre Julliard authored
-
Alexandre Julliard authored
-
Alexandre Julliard authored
-
Alexandre Julliard authored
-
- 01 Dec, 2023 7 commits
-
-
Robert Wilhelm authored
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55185
-
Nikolay Sivov authored
Signed-off-by: Nikolay Sivov <nsivov@codeweavers.com>
-
Brendan Shanks authored
LLVM no longer allows non-private labels to appear between .cfi_startproc/endproc when targeting Mach-O. Based on a patch by Jacek Caban. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55863
-
Rémi Bernon authored
-
Rémi Bernon authored
-
Rémi Bernon authored
-
Rémi Bernon authored
-