Signed-off-by: Eric Pouech <epouech@codeweavers.com>

Signed-off-by: Eric Pouech <epouech@codeweavers.com>

Signed-off-by: Eric Pouech <epouech@codeweavers.com>

This will help separate debug info files lookup from their actual
loading once found and correctly matched.
Signed-off-by: Eric Pouech <epouech@codeweavers.com>

- SymLoadModules flags (SLMFLAG_VIRTUAL and SLMFLAG_NO_SYMBOLS),
- handling of load details (SymType, ImageName vs LoadedImageName,
  various instances of module name).
Signed-off-by: Eric Pouech <epouech@codeweavers.com>

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

Fixes a regression introduced by
efd3d310.

Signed-off-by: Eric Pouech <epouech@codeweavers.com>

Signed-off-by: Eric Pouech <epouech@codeweavers.com>

Signed-off-by: Eric Pouech <epouech@codeweavers.com>

Signed-off-by: Eric Pouech <epouech@codeweavers.com>

Signed-off-by: Eric Pouech <epouech@codeweavers.com>

Fix Warlords Battlecry III (433280) crashes at launch.

Signed-off-by: Connor McAdams <cmcadams@codeweavers.com>

Signed-off-by: Nikolay Sivov <nsivov@codeweavers.com>

Based on a patch by Michael Müller.

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

Don't convert the source to PIDLs just to convert it back to paths.

Make the logic in do_paste() a bit more idiomatic.

And simplify the control flow a bit while we're at it.

Dragon Naturally Speaking 12.5 manually validates that the custom action server
is elevated.

One might imagine that the right approach here is to add a manifest to msiexec;
however, msiexec does not always trigger a UAC prompt on Windows.

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

This signifies that UAC is active.

Foobar2000 checks this value, and won't even try to elevate itself otherwise.

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

Like all other verbs, the actual command line template is specified in the
registry. The elevation seems to be hardcoded into shell32 for this specific
verb.

The Foobar2000 installer requires administrator privileges, and elevates itself
in this way.

Based on a patch by Michael Müller.

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

Signed-off-by: Philip Rebohle <philip.rebohle@tu-dortmund.de>

Consider a thread A running waiting_item_cancelable_callback() and a thread B running queue_cancel_item(),
which is the scenario from canceling a work item right after it gets submitted by RtwqPutWaitingWorkItem().
When the invoke_async_callback() call in queue_cancel_item() for item key with WAIT_ITEM_KEY_MASK in
thread B runs before the queue_release_pending_item() in waiting_item_cancelable_callback() in thread
A, the async callback is called the first time in queue_cancel_item() with RTWQ_E_OPERATION_CANCELLED,
then a second time in waiting_item_cancelable_callback(). We should check in queue_release_pending_item()
whether an item is already removed by queue_cancel_item() before calling async callbacks.

A different scenario could happen for scheduled_item_cancelable_callback() with the function ends
up calling its async callback even after it has been canceled by queue_cancel_item().