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.
--
v9: Added tests for class FILE_INFORMATION_ALLOCATION in setFileInformationByHandle
Added support for class FILE_INFORMATION_ALLOCATION in setFileInformationByHandle
https://gitlab.winehq.org/wine/wine/-/merge_requests/7115
The current YUV to RGB conversion provides values in studio-range [16-235], but full-range is required [0-255]. As a result, we currently write the value of 16 to represent black, and so we get gray instead.
This MR changes the coefficients used in the conversion so that the resultant output is in full-range. It actually uses two sets of coefficients as these differ between SD and HD.
Also included is a number of Direct Draw 7 tests.
The coefficients used are documented here:
https://learn.microsoft.com/en-us/windows/win32/medfound/recommended-8-bit-…
--
v5: wined3d: Use Microsoft provided coefficients for YUV to RGB conversion.
ddraw/tests: Test yuv to rgb blt in ddraw7.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7324
On Sat Feb 22 21:18:30 2025 +0000, Joe Souza wrote:
> Note also that PAUSE clears *all* flags and sets them to 0.
And according to MS docs, ENABLE_ECHO_INPUT works only if ENABLE_LINE_INPUT is also enabled.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7400#note_95669
On Sat Feb 22 21:16:22 2025 +0000, Joe Souza wrote:
> 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.
Note also that PAUSE clears *all* flags and sets them to 0.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7400#note_95668
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