On Sat Feb 22 21:16:23 2025 +0000, eric pouech wrote:
> yes `dir /p` needs to be fixed, and what you propose does work for the
> regular use (cmd in interactive mode...)
> did some testing on windows which confirm that ENABLE_PROCESSED_INPUT
> should be kept in wait operation
> * piping ctrl-c character in input stream doesn't stop the `dir /p` command
> * while hitting ctrl-c from keyboard (from the same pipe command) does
> * this means that the console is always kept in processed mode, and the
> ctrl-c is always returned through the ctrl-c handler and not as a
> character in input stream
> actually, I'd prefer to have a dedicated helper to only wait for user
> input (it doesn't prevent to have another helper which does {print
> message(); wait for input(); print \\r\\n}); and we tend to place
> generic helpers in wcmdmain.c
> there are some functional points to consider:
> * may be setting console mode to ENABLE_PROCESSED_INPUT only is too
> aggressive; it looks like only clearing ENABLE_LINE_INPUT could be
> sufficient (you may want to keep ENABLE_ECHO_INPUT to have character printed)
> * console mode isn't reset on error path
> * the most annoying bit is that the ctrl-c isn't handled
> * this may end up a bit complicated as you need to wait on two
> objects; WCMD_choice could help for some waitable reads, but not all the
> input handles are opened in overlapped mode \<g\>
> * and also, it must ensure that the callers to that helper correctly
> support the STATUS_CONTROL_C_EXIT (`pause` seems to ignore it, `dir` now
> has support for ctrl-c return code)
> note: builtin cmd doesn't properly implement pipes between commands, so
> don't try test it
OK, thank you. Note that it appears that you make two conflicting statements above:
"did some testing on windows which confirm that ENABLE_PROCESSED_INPUT should be kept in wait operation"
and
"may be setting console mode to ENABLE_PROCESSED_INPUT only is too aggressive; it looks like only clearing ENABLE_LINE_INPUT could be sufficient"
The problem here is that ENABLE_PROCESSED_INPUT is not enabled by default. If I just clear ENABLE_LINE_INPUT then I don't believe that ENABLE_PROCESSED_INPUT is enabled.
I will rework the code per your suggestions and I will figure out what works here.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7400#note_95667
This MR intends to add support for the case FileAllocationInformation in function SetFileInformationByHandle of library kernelbase.dll.
The code is based on my understanding of [MS documentation](https://learn.microsoft.com/en-us/windows-hardware/drivers/d…
No test was added, because other cases that could have helped doing so (FileEndOfFileInformation) do not have neither.
--
v7: removed probably useless FALLOC_FL_ZERO_RANGE flag
Switched back to fallocate, with FALLOC_FL_KEEP_SIZE
Used posix_fallocate in place of ftruncate + added related test
Added support of sub function FileAllocationInformation in SetFileInformationByHandle
https://gitlab.winehq.org/wine/wine/-/merge_requests/7115
Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com>
--
v2: windowscodecs/decoder: Implement metadata readers enumerator for the common decoder.
windowscodecs/decoder: Reuse metadata readers instances.
windowscodecs: Use common decoder for GIF format.
windowscodecs/decoder: Add support for IWICBitmapDecoder::CopyPalette() in common decoder.
windowscodecs/decoder: Add support for metadata block reader at decoder level.
windowscodecs/decoder: Separate metadata block reader to a reusable structure.
windowscodecs/metadata: Add an option to initialize reader from a memory block.
windowscodecs/gif: Store Image descriptor offset when reading GIF data.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7376