The || and && operators to chain commands rely on the LHS command
to be successful (or unsucessful) to decide upon launching the RHS
command.

Unfortunately, success/failure is not always when errorlevel is
0 (non zero).

Some exmaples:
- if a redirection fails (eg. appending to a non existing file),
  the command (builtin/external) is always unsuccessful (and the
  error level is untouched,
- external command (when redirection is ok) is succesful when
  program exit code is zero,
- ditto for a call to a label inside the batch file, with
  the 'exit /b' parameter,
- it's way more complicated for builtins. Eg 'type' is unsuccessful
  on a non existing file, while 'dir' (on the same unexisting file)
  succeeds.

So start adding some tests about success / failure of some commands.
Signed-off-by: Eric Pouech <epouech@codeweavers.com>

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

Based on a patch by Alex Henrie.
Signed-off-by: Eric Pouech <epouech@codeweavers.com>

Based on a patch by Dimitry Sokolov.
Signed-off-by: Eric Pouech <epouech@codeweavers.com>

Based on a test case from Dimitry Sokolov.
Signed-off-by: Eric Pouech <epouech@codeweavers.com>

This is needed for hybrid patchable guest exit thunks generated by the compiler.

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

To demonstrate the difference in behavior, we need a special MPEG
program stream that is at least 32kB over in size.

When no display cache update is needed.

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

Fixes: 010008f6
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56615

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

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

This improves performance for the game "Grounded", on a AMD Radeon RX 6700 XT,
with radv from Mesa 22.3.6. Testing was done with the "cb_access_map_w" option
enabled, which also improves performance with the game by itself.

Grounded generally makes about 4000 draw calls per frame, which seems not
atypical. This change makes it submit at most an extra 8 times per frame, but in
practice due to WINED3D_PERIODIC_SUBMIT_MAX_BUFFERS it submits less (usually
only 2-3).

The most demanding game I've seen made about 20,000 draw calls per frame, at
which point the overhead of adapter_vk_draw_primitive() itself becomes a serious
bottleneck. For such a game we would submit 40 more times per frame with these
settings, although WINED3D_PERIODIC_SUBMIT_MAX_BUFFERS means we would likely
submit less than that. In any case if submission itself becomes a bottleneck, we
should offload it to a separate thread.

Credit goes to Philip Rebohle and his work on DXVK for helping me to notice that
periodic submission might make a difference.

Part of beginning a render pass involves executing an RTV barrier, which itself
needs to call wined3d_context_vk_get_command_buffer(). However, that function
may decide to submit the command buffer, in order to prevent resource buildup,
or [in the future] because it has been some length of time since the last
submission.

Therefore we cannot retrieve and store a VkCommandBuffer pointer before
executing an RTV barrier and then use it later.

This fixes the following C++ compiler error

mfmediaengine.h:1216:18: error: expected ',' or '...' before 'protected'
 1216 |            BOOL *protected) = 0;
      |                  ^~~~~~~~~

After commit 898ab8da wine would no longer
build on musl.

Issue is that apparently TCSETS2 isn't defined when including sys/ioctl.h.

A little digging shows that glibc goes ahead and includes asm/ioctls.h in
sys/ioctl.h, providing said macro.  Musl on the other hand doesn't and relies
on bits/ioctl.h, which lacks said macro.
Signed-off-by: Fotios Valasiadis <fvalasiad@gmail.com>

NtUserCreateWindowEx will call apply_window_pos and drivers
WindowPosChanging callback, which already creates window data.

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