Both the Msys2 and Cygwin runtimes make use of
FILE_DISPOSITON_POSIX_SEMANTICS in their implementations of the unlink()
system call. This enables these routines to behave similarly to POSIX where are
unlisted from the directory, if handles are still open.

https://github.com/msys2/msys2-runtime/blob/msys2-3.4.3/winsup/cygwin/syscalls.cc#L722
https://www.cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/syscalls.cc#l724Signed-off-by: Joel Holdsworth <joel@airwebreathe.org.uk>

In order to implement FILE_DISPOSITION_POSIX_SEMANTICS, it will be necessary
to add additional flags to closed_fd. In preparation for this, the unlink
member variable has been replaced with disp_flags which directly reflects the
flags defined in the FILE_DISPOSITION_INFORMATION_EX structure.
Signed-off-by: Joel Holdsworth <joel@airwebreathe.org.uk>

Signed-off-by: Joel Holdsworth <joel@airwebreathe.org.uk>

The FILE_DELETE_ON_CLOSE can be used with the FILE_DISPOSITION_ON_CLOSE flag
of FileDispositionInformationEx.
Signed-off-by: Joel Holdsworth <joel@airwebreathe.org.uk>

Signed-off-by: Joel Holdsworth <joel@airwebreathe.org.uk>

Both the Msys2 and Cygwin runtimes make use of
FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE in their implementations of the
unlink() system call. This enables these routines to delete a read-only file
without first modifying the attributes.

https://github.com/msys2/msys2-runtime/blob/msys2-3.4.3/winsup/cygwin/syscalls.cc#L724
https://www.cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/syscalls.cc#l726

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=50771Signed-off-by: Joel Holdsworth <joel@airwebreathe.org.uk>

Signed-off-by: Joel Holdsworth <joel@airwebreathe.org.uk>

This is required by Msys2 when running gpg-agent.

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54996Signed-off-by: Joel Holdsworth <joel@airwebreathe.org.uk>

Signed-off-by: Joel Holdsworth <joel@airwebreathe.org.uk>

This is far simpler than drawing with it.

The immediate motivation here is that the DXGI_FORMAT_R8G8B8A8_UINT test causes
a validation error when drawing, since the shader declares its resource as a
float4 texture, which does not match the UINT view format. This could be fixed
by using a different shader, but it seems more prudent to just simplify the test
to not draw at all.

This is far simpler than drawing with it.

The immediate motivation here is that the DXGI_FORMAT_R8G8B8A8_UINT test causes
a validation error when drawing, since the shader declares its resource as a
float4 texture, which does not match the UINT view format. This could be fixed
by using a different shader, but it seems more prudent to just simplify the test
to not draw at all.

This reverts commit a19c8712.

Fixes both a memory leak and an alloc/free mismatch, and the module heap
is the most appropriate place to hold the variable long-term.

Stops a linker error of duplicate name when using upstream vkd3d.

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55128Signed-off-by: Eric Pouech <epouech@codeweavers.com>

Only done for DS format.
Signed-off-by: Eric Pouech <epouech@codeweavers.com>

Add infrastructure to generate fake .PDB files.

Only done in DS format.

I'm not sure we care about JG anymore, DS format has been introduced
by MS in early 2000 to supersede JG, and is still mainstream today).
For the record, LLVM in its PDB handling doesn't support JG format.
Signed-off-by: Eric Pouech <epouech@codeweavers.com>

NtUserMessageCall(..., NtUserSendDriverMessage) does not ensure the
validity of the hwnd, so this check will incorrectly fail if the
last error was ERROR_INVALID_WINDOW_HANDLE by coincidence. The
notify_owner call immediately following this code will catch a
destroyed owner hwnd.

'if exists' takes a parameter which can be directory, directory/,
directory/. directory\ or directory\. for example, and should equate
to true if the directory exists. The syntax directory\ is explicitly
rejected by FindFirstFile and hence was not working - look for this
specific case, and if found append a '.'.

Follow-up commit of bc9d68bc

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55130#add_comment