Fixes a regression from 9d537999, which removed closing the file.
This causes Windows widl build to be to remove the temporary file on exit.

RE:D Cherish! (Trial ver) depends on this behavior.

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

On recent Windows, at least Windows 7, a multithread apartment (MTA) is
initialized within IDirectSound::Initialize().

Fixes: a4ef56e1

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>

Either from command line option, or as a command.
Mostly handy for scripting.
Signed-off-by: Eric Pouech <epouech@codeweavers.com>

Signed-off-by: Dmitry Timoshkov <dmitry@baikal.ru>

This does two things:

1. ShellExecute no longer searches in the directory where the current executable is in.
2. We always CreateProcess with a fully qualified path, so we CreateProcess won't do its own path
   resolution.

Serendipitously this also fixes some existing todos in tests.

It should look in the currect working directory, instead of the directory where the current
executable is in.

Setting dwWhich to 0xff forces extensions to be appended, even when the file name already includes
an extension. This causes PathResolve to fail in some cases where the file does exist.

Previously looking for file that does exist in current directory will fail because of the early
`!PathFileExists(path)` check, even when the current directory is specified in `dirs`.

Unless it's explicitly specified.

FindExecutable should look in the current working directory, not relative to the current executable
image (which is what SearchPathW(NULL, ...) does).