- wine-gitlab - winehq.org

Re: [PATCH v21 0/1] MR7843: cmd: Implement tab completion for command line entry.
by eric pouech (＠epo) 26 Apr '25

26 Apr '25

thanks a couple of high level comments: * I don't think having a separate source file just for \~400 LoC is worth it * WCMD_ReadConsole is way too big as a function and need to be split in smaller pieces. * you should also be using the command line parsing functions instead of rewriting them (eg WCMD_parameter to loop against the various parameters) from quick testing: * when looping around files sometimes filename is inserted in quotes, while it shouldn't. Native seems to insert quotes only when filename contains specific characters (spaces...), but to also remove them if next file doesn't contain any... * using "cd c:\\Program Files"\<tab\>\<backspace\>\\\<tab\> doesn't behave as native... native circles in the directory content, current MR only adds a double quote * got a crash when playing with MR (perhaps one of the buffer overflow stated above, perhaps not) * when the width of the console is smaller than the full line input (eg spread at least on two lines), circling gives some strange result (cursor and display when from bottom of screen buffer back to top, will previous content not shifted) likely the current appoach of just having a handle to findfirst/findnext will not fit all the (long term) goals. at some point, we want to support shift-tab which circles backwards in the matching files. and I fail to see what using FindFirstFileEx brings as value, as you filter against directory when needed (I'm not asking for supporting shift-tab right now, but rather to put in place a structure were it wil fit simply when we implement it) support for cd/rmdir/ and friends should be added in a second patch I didn't go further in the review given the amount a remarks and problems stated above. I'll restart when they are solved (will look in // to the ESC issue raised) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7843#note_101926

1 0

[PATCH v3 0/2] MR7908: Fix macOS winetest timeout in kernel32:virtual
by Jinoh Kang (＠iamahuman) 26 Apr '25

26 Apr '25

Work around slow runtime of current FlushProcessWriteBuffers() implementation on macOS. The total iteration count becomes: ``` - positive half: 32768 * 1 (old) = 8192 * 4 (new) - negative half: 32768 * 1 (old) > 8192 * 1 (new) ``` -- v3: kernel32/tests: Shorten time for negative half of litmus test for FlushProcessWriteBuffers(). kernel32/tests: Run store_buffer_litmus_test() in a single-iteration loop. https://gitlab.winehq.org/wine/wine/-/merge_requests/7908

2 2

[PATCH v2 0/2] MR7908: Fix macOS winetest timeout in kernel32:virtual
by Jinoh Kang (＠iamahuman) 26 Apr '25

26 Apr '25

Work around slow runtime of current FlushProcessWriteBuffers() implementation on macOS. The total iteration count becomes: ``` - positive half: 32768 * 1 (old) = 8192 * 4 (new) - negative half: 32768 * 1 (old) > 8192 * 1 (new) ``` -- v2: kernel32/tests: Shorten time for negative half of litmus test for FlushProcessWriteBuffers(). https://gitlab.winehq.org/wine/wine/-/merge_requests/7908

2 2

[PATCH v2 0/2] MR7895: Revert "kernel32/tests: Don't use _ReadWriteBarrier on ARM platforms."
by Jinoh Kang (＠iamahuman) 26 Apr '25

26 Apr '25

This reverts commit 504a305a60849704f2d83b55e9aabb26d89edf11. The choice of weak barrier was by design. The stronger barrier broke the positive half of the litmus test for FlushProcessWriteBuffers(): > virtual.c:4568: Test failed: expected write-read reordering with compiler barrier > only (got 0 reorderings) FlushProcessWriteBuffers() is used in tandem with a compiler-only barrier to implement fast synchronization, where only one side is executed frequently and the other side only occassionally (e.g., garbage collection). Prominent applications include .NET and HotSpot JVM. Although _ReadWriteBarrier() is "marked deprecated," it is in fact used by Microsoft's own STL library (with explicit suppression of warning) to implement a compiler-only memory barrier[^1]. The deprecation notice suggests C++11 atomics as the (only?) alternative. [^1]: https://github.com/microsoft/STL/blob/b5df16a98934319e2e6864d6036cbe9cd9c74… -- v2: kernel32/tests: Don't use _ReadWriteBarrier() on clang. https://gitlab.winehq.org/wine/wine/-/merge_requests/7895

2 3

[PATCH 0/1] MR7895: Revert "kernel32/tests: Don't use _ReadWriteBarrier on ARM platforms."
by Jinoh Kang (＠iamahuman) 26 Apr '25

26 Apr '25

This reverts commit 504a305a60849704f2d83b55e9aabb26d89edf11. The choice of weak barrier was by design. The stronger barrier broke the positive half of the litmus test for FlushProcessWriteBuffers(): > virtual.c:4568: Test failed: expected write-read reordering with compiler barrier > only (got 0 reorderings) FlushProcessWriteBuffers() is used in tandem with a compiler-only barrier to implement fast synchronization, where only one side is executed frequently and the other side only occassionally (e.g., garbage collection). Prominent applications include .NET and HotSpot JVM. Although _ReadWriteBarrier() is "marked deprecated," it is in fact used by Microsoft's own STL library (with explicit suppression of warning) to implement a compiler-only memory barrier[^1]. The deprecation notice suggests C++11 atomics as the (only?) alternative. [^1]: https://github.com/microsoft/STL/blob/b5df16a98934319e2e6864d6036cbe9cd9c74… -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7895

4 4

[PATCH 0/3] MR7907: vwin32.vxd: Fix support for vwin32 IOCTLs
by Pali Rohár (＠pali) 26 Apr '25

26 Apr '25

* Remove cases for vwin32 IOCTLs 0x10 and 0x29 numbers as they are unsupported by Windows 9x * Fix functions accepted by IOCTLs VWIN32_DIOC_DOS_IOCTL and VWIN32_DIOC_DOS_DRIVEINFO * Add missing IOCTL VWIN32_DIOC_DOS_INT13 case for TRACE log -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7907

2 3

[PATCH 0/6] MR7861: krnl386: Fixes for DPMI functions
by Pali Rohár (＠pali) 26 Apr '25

26 Apr '25

* Set carry flag for every failed DPMI call * Fix return value for DPMI calls 0102h, 0202h and 0900h-0902h * Fix comments and FIXME -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7861

5 14

[PATCH v4 0/4] MR6885: Draft: cmd: Use the console output codepage to read batch files.
by Akihiro Sagawa (＠sgwaki) 26 Apr '25

26 Apr '25

To prevent performance degradation, we will cache the result of GetConsoleOutputCP() after executing every external command. -- v4: cmd: Use the console output code page to read batch files. programs/cmd: Factor out code_page when searching for a label. cmd/tests: Add updated code page test in batch file. cmd: Use the OEM code page if GetConsoleOutputCP fails. https://gitlab.winehq.org/wine/wine/-/merge_requests/6885

4 7

[PATCH 0/1] MR7904: krnl386: Fix return value for DPMI 0900h-0902h calls (Virtual Interrupt State)
by Pali Rohár (＠pali) 26 Apr '25

26 Apr '25

According to the DPMI specification, DPMI functions 0900h-0902h related to Virtual Interrupt State has to always return state in AL register. As wine does not support disabling virtual interrupt flag, report that interrupts are always enabled (AL=1). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7904

2 1

[PATCH 0/1] MR7903: krnl386: Fix comments for DPMI 0202h/0203h calls (Processor Exception Handler Vector)
by Pali Rohár (＠pali) 26 Apr '25

26 Apr '25

DPMI functions 0202h and 0203h related to Processor Exception Handler Vector are not supported by wine. So update FIXME comments about this fact. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7903

2 1

2025

2024

2023

2022

wine-gitlab