This is the fourth part in cmd.exe's engine rewrite.
It concerns:
- start of decoupling parsing from execution by introducing
ad hoc structure to hold parsing result to be passed for
execution (done here for redirection, and if conditions),
- refactor execution code with putting into helpers:
+ change of input/output streams
+ save / restore of input/output streams before / after
execution
Note:
- the handling of fd > 2 is clearly wrong, but it just
mimics the current implementation. More work will be
required afterwards (likely using directly CRT low level
I/O),
- I kept a few specific debug channels in place. They will
be removed (or simplified at some point), but they
could be useful to debug remaining issues.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5641
This should achieve the same thing as https://github.com/ValveSoftware/wine/commit/e8801e96fedf67b88e6f3f5d9f9e2d…
--
v3: win32u: Enumerate offscreen vulkan devices as GPU devices.
win32u: Query GPU memory from vulkan physical device.
win32u: Match driver GPUs with vulkan GPUS from their ids, or index.
win32u: Keep a list of vulkan GPUS in the device manager context.
win32u: Load the graphics driver vulkan functions lazily.
win32u: Fix default_update_display_devices return type to NTSTATUS.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5616
On Tue May 21 09:53:24 2024 +0000, eric pouech wrote:
> using strtol would be better and save you the str_is_number helper
I can switch to strtol, but how does it save the `str_is_number` helper? It returns 0, which is a valid (if useless) timeout value for the native program.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5691#note_71016
On Tue May 21 12:09:30 2024 +0000, eric pouech wrote:
> I'd rather see this outside the do/while loop (and moreover, the second
> count down shall be printed after this message)
Yes, but it only overrides the "Waiting for %s seconds" part, which mostly matches Windows' behavior (from the cursor position). The only difference is that Windows will end at "Waiting for N". While it's possible to replicate this, I believe it may cause issues with translations.
I can move it outside the do/while loop though.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5691#note_71014
On Tue May 21 10:23:40 2024 +0000, eric pouech wrote:
> why do you need float operations here? (int)(ticks_remaining / 1000)
> should do
It needs to be rounded because otherwise it will start with printing "Waiting for N-1 seconds" due to one or more ticks having elapsed (at least on my machine). But yes, I could do an int roundup instead (`(ticks_remaining + 500) / 1000`).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5691#note_71013
eric pouech (@epo) commented about programs/timeout/timeout_main.c:
> +
> +#include <stdio.h>
> +#include <stdlib.h>
> +#include <string.h>
> +#include <conio.h>
> +#include <math.h>
> +
> +#include <windows.h>
> +
> +#include "resources.h"
> +
> +#include <wine/debug.h>
> +
> +WINE_DEFAULT_DEBUG_CHANNEL(timeout);
> +
> +static char* get_string(int which)
a couple of remarks here (about the helpers for printing):
- returning ASCII strings could lose some bits in conversion, so you'd be safer keeping unicode string
- also usage of (w)printf can lack flexibility in translations (it assumes all parameters have the same order whatever the translation). FormatMessage brings more flexibility as you can change the order of parameters in output.
- and likely RPRINTF_VA could be rewritten as a function and not a macro
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5691#note_71012
On Tue May 21 09:53:24 2024 +0000, eric pouech wrote:
> to be pedantic, native only allows one timeout value and prints error
> when two are given
using strtol would be better and save you the str_is_number helper
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5691#note_71008
--
v3: quartz: Hold the streaming lock while calling ICDecompressEnd.
quartz: Use the correct stride when calculating image size in AVIDec.
quartz: Get output format from source, not sink in AVIDec.
quartz/tests: Use unaligned width in AVIDec tests to expose incorrect stride calculation.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5674
On Mon May 20 21:34:08 2024 +0000, eric pouech wrote:
> agreed (except perhaps for the padding of the N seconds... not that it
> would make sense to replicate the padding, but I'm not sure the printf
> has a trailing whitespace so that it erases the last visible char when
> the width of N is reduced)
I've added the padding, and replicated the behavior of the native program by only updating the "Waiting for N seconds" text.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5691#note_70991
--
v2: quartz: Hold the streaming lock while calling ICDecompressEnd.
quartz: Use the correct stride when calculating image size in AVIDec.
quartz: Get output format from source, not sink in AVIDec.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5674
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=44863
The bug has been fixed already by moving ddraw4 vertex buffers into
system memory. Changing this value makes the game create a smaller
buffer, which makes the game fast on video memory buffers. I think we
should stay close to what Windows drivers report even though we
mitigated the original issue in a different way.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5687
This MR improves the handling of numpad keys for drivers using KBDTABLES (only the Wayland driver at this point). It achieves this by:
1. Allowing drivers to send only the scancode in keyboard events, with win32u performing the scan->vkey mapping internally. A nice side effect of this change is that it fixes a few user32 input test TODOs.
2. Enhancing wineserver to read extended KBD vkey attributes and perform numpad key mapping depending on modifier state.
3. Providing default VK_NUMPAD* -> WCHAR mappings in win32u.
--
v7: winewayland.drv: Populate vkey to wchar entry for VK_DECIMAL.
user32/tests: Add tests for SendInput with numpad scancodes.
server: Send numpad virtual keys if NumLock is active.
win32u: Store the full KBD vkey information in kbd_tables_init_vsc2vk.
win32u: Allow drivers to send only the scan code for keyboard events.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5601
This MR improves the handling of numpad keys for drivers using KBDTABLES (only the Wayland driver at this point). It achieves this by:
1. Allowing drivers to send only the scancode in keyboard events, with win32u performing the scan->vkey mapping internally. A nice side effect of this change is that it fixes a few user32 input test TODOs.
2. Enhancing wineserver to read extended KBD vkey attributes and perform numpad key mapping depending on modifier state.
3. Providing default VK_NUMPAD* -> WCHAR mappings in win32u.
--
v6: winewayland.drv: Populate vkey to wchar entry for VK_DECIMAL.
user32/tests: Add tests for SendInput with numpad scancodes.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5601
In update_external_font_keys(), remove the fonts from the registry
immediately after we mark them for deletion, and then proceed to add or
update values in the registry.
This prevents a font from being marked as deleted, then being updated in
the registry, and then removed from the registry regardless. When this
happened, the registry would not contain the value for this font that we
intended to update it with. This function would need to run again for
this value to be added to the registry, but since this function runs
during initialization, this means that a subsequent launch of wine was
necessary. By removing the old value from the registry first, and then
adding the new one, the initialization process becomes idempotent
starting from the first run.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5684
On Sat May 18 08:22:49 2024 +0000, Piotr Caban wrote:
> Did you consider changing `get_args` prototype to something like:
> `static char* get_args(struct parsed_symbol* sym, BOOL func)`? I think
> that `z_term` argument name is not very descriptive. `open_char` and
> `close_char` seems to be redundant.
yes I thought about it (with same reasoning as yours). Didn't do it at once because I wondered where to put the open/closing argument (keep it inside get_args() as it is today or move it to caller site) and I wanted to cover the throw clauses that we don't handle yet first (to check the impacts -if any- in handling of end of parameters' type list marker).
will include in next round if it fits well.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5675#note_70879