This goes through a buffer in advapi32, so it's not obviously visible to the application; however, it means that a call to getrandom() will return EFAULT and won't actually fill the buffer.
This was implemented upstream in e.g. 52e09e823e2a2b65f1f993145c0a65ab1d84713d and 926dd780697852b375ec0a193c762e7723a3f5e6, albeit in ntdll instead of mscoree.
This patch concerns the case where we successfully create a read-only directory
with FILE_DELETE_ON_CLOSE. Currently we return STATUS_CANNOT_DELETE (having
cleared O_CREAT). This patch would change that to return success.
However, tests show that this is incorrect. Actually FILE_DELETE_ON_CLOSE should
always fail on a read-only file, including when that file is created by the same
call.
These were committed without any explanation, but they do seem to fix Cygwin
unlink(), and it's been observed that many patches in Wine-Staging, whether
labeled or not, were specifically for Cygwin.
The relevant functionality was fixed a different way upstream, namely:
91e442b060
There is no record at all of what this was for.
However, it's not hard to make a good guess. The effect of the patch is to skip
walking the TEB chain if the faulting %esp is *above* the first element in the
TEB chain.
The most obvious thing this protects against is the case where the application
switched stacks and the new stack happened to be at a higher address. Without
this patch, we would walk through the whole TEB chain, since all of its entries
would be below the target frame we are unwinding to. But they wouldn't actually
be "inner to" it, and so we'd incorrectly hit Wine try/catch blocks.
The most notable such try/catch block is the unhandled exception filter itself,
and it would necessarily have been triggered by any such exception if no other
blocks were.
One can further speculate that this patch, like many others in Wine-Staging, was
written for Cygwin, which is known to switch stacks.
Besides Wine commits c22aa54e9977785eafcd7cc3811116e5f4dd2da8, and other more
targeted workarounds to specific functions, the workaround introduced by this
patch was obviated by a similar, but more complete and holistic, workaround
upstream, namely 8fe95d29d32533e8fa28383c0211555eb71ea6c1.
Thus this patch has been, in almost the simplest sense, upstreamed. Remove it.
This seems to be another one of those cases where Sebastian added a patch for an
application [1], then never submitted the patch upstream, and then someone else
submitted a different patch upstream [2], but Sebastian didn't bother checking
if his version was actually still necessary, and instead assumed it was (or just
decided it was better) and rebased the patch [3], and of course still never
submitted it upstream.
In this case the patch is for Terragen 4. That application does not, according
to my testing, actually depend on success from SetThreadIdealProcessorEx().
The patch does not add a correct implementation, is trivial to recreate, and is
easy to re-debug (the function still prints a FIXME), so it's not adding any
value. Remove it.
[1] a12dca03ce
[2] 980754bff7
[3] 0c46d1e8a2
