mingw-w64 defines __forceinline (and therefore FORCEINLINE) as
"extern __inline__ __attribute__((__always_inline__,__gnu_inline__)). This means
that COM inline wrappers specify multiple storage classes and hence cannot be
compiled.
Wine defines FORCEINLINE simply as "inline" (and uses "static" everywhere), so
this is a non-issue for Wine. However, since Wine and mingw-w64 share the source
code of widl and of most IDL headers, this patch changes the definition for both
projects.
There's no reason to force inlining here, especially since the wrappers need to
be manually enabled, and we don't need to match PSDK semantics where these
wrappers don't even exist.
In practice, use "__inline__" instead of "inline" for GNU C targets, to preserve
compatibility with C89 in mingw-w64 headers.
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=52931
Signed-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=53714
Signed-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
Fix invisible disabled menu item text in Subtitle Workshop Classic 6.1.4. The application happens to
use 0xF0F0F0 as the menu background and the inactive caption color to draw disabled menu item text.
In Light theme, the inactive caption color is very close to 0xF0F0F0, thus causing the invisible
text. So use a darker color for inactive captions to avoid this issue. The inactive caption text
color is also adjusted accordingly.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53575
It occurred to me to wonder whether it was really Description, Source,
or both that results in skipping the map_vbs_exception logic.
It turns out we had it right (it's just description, and it's
null-pointer and not empty string that makes the difference).
But the fact that it's not obvious still makes it a good testcase
