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().

Consider a thread A running scheduled_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 RtwqScheduleWorkItem().
When the CloseThreadpoolTimer() call in queue_cancel_item() in thread B runs before the queue_release_pending_item()
in scheduled_item_cancelable_callback() in thread A, scheduled_item_cancelable_callback() ends up
calling work_item_Release() and CloseThreadpoolTimer() is called again for the same timer object. So
the thread pool timer object end up getting released while the scheduled_item_cancelable_callback()
is running, triggering the '!object->num_running_callbacks' assertion in tp_object_release(). This
is actually a double free but the assertion happens before the second free could happen. The same
thing could happen for thread pool wait objects as well.

Fix mf and mfmediaengine tests sometimes trigger the '!object->num_running_callbacks' assertion.

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

An extension of 3985b7c5. Opening the device for the Touch Bar on
older MacBooks also triggers a permission prompt, so for now it makes
sense to restrict the devices we open.

The main motivation here is to avoid overflow, and multiplying in one place seems simpler.

This avoids overflow when component costs exceed 4 GB.

Fixes missed key up events on older macOS versions, which could
result in out-of-order input.

Fix via Rémi Bernon <rbernon@codeweavers.com>.

Fixes weird keyboard behavior on MacBooks with the Touch Bar.