Introduce relevant structures in include/wine/msvcpdb.h.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>

GCC12.2 emits a warning here.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>

This usually doesn't go through the normal presentation paths.

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52954

This reverts commit 27f417eb.
It breaks the tests.

This reverts commit 28e0d8ff.
It breaks the tests.

Change strategy for resetting local scope when unloading a module.
Old strategy was keeping the local scoped symbol alive on some code path when
unloading a module.
This caused some bad behavior as we kept a pointer to a deleted object.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>

This happens because the llvmpipe virtual GPU is not in the RandR provider list
when there is a hardware GPU driving the screen. So LUID for the llvmpipe is
not generated in such cases.

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52931Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>

Some Wine tests are multi-threaded or start child processes which can
result in traces and failure messages being garbled which prevents them
from being recognized by continuous integration tools.
So printing the test messages is now serialized. Note that if a process
crashes while holding the mutex, that mutex will be abandoned and not
cause a deadlock.

MSDN states, a NULL InfoValue parameter will return as the length.
unixODBC which we currently use, handles this scenario.

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53714Signed-off-by: Alistair Leslie-Hughes <leslie_alistair@hotmail.com>

VariantCopyInd allows pvargDest == pvargSrc in order to dereference in place
To avoid confusing the source values and a partially-written destination,
wine's implementation makes a shallow copy and uses that as pSrc.

However, the call to VARIANT_CopyIRecordInfo did not use this,
leading to it copying from the zeroed-out memory it just allocated.

In many cases (in particular when VariantCopy has been used),
multiple VARIANT structs which contain the same type of record
will share the same instance of IRecordInfo, just adding refcounts.

RecordClear should not be aware of where the data it's clearing came from,
and certainly should not be modifying someone else's VARIANT::brecVal.
This seems to have been intended as a way to make tests more sensitive to
use-after-free, by overwriting the source pointer with NULL after
clearing the pointed-to record.

To preserve that sensitivity (if it was indeed the goal), replace the
hardcoded "0xdeadbeef is valid" check with a "validsrc" address that
get_test_recordinfo initially agrees to pretend points to a valid record,
but will stop accepting after a call to RecordClear.

OpenTextFile(...,ForWriting,True) should either create a new file,
or open and truncate an existing one

OpenTextFile(...,ForAppending,?,True) should write a BOM
if appending to an existing-but-empty file