February 2025 - Wine-GitLab

Re: [PATCH v14 0/2] MR741: ntdll: Implement NtFlushProcessWriteBuffers. - approved
by Alexandre Julliard (＠julliard) Feb. 14, 2025

Feb. 14, 2025

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/741

1 0

Re: [PATCH v2 0/1] MR7315: winedbg: Make crash dialog topmost. - approved
by Alexandre Julliard (＠julliard) Feb. 14, 2025

Feb. 14, 2025

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7315

1 0

Re: [PATCH v2 0/1] MR7337: ntdll/tests: Skip leap secondInformation test with older Windows versions. - approved
by Alexandre Julliard (＠julliard) Feb. 14, 2025

Feb. 14, 2025

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7337

1 0

Re: [PATCH v2 0/1] MR7333: winedmo: Explicitly set 'Data1' value for VP9 GUID. - approved
by Alexandre Julliard (＠julliard) Feb. 14, 2025

Feb. 14, 2025

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7333

1 0

Re: [PATCH v3 0/1] MR7331: winex11.drv: Go though WithdrawnState when transitioning from IconicState to NormalState. - approved
by Alexandre Julliard (＠julliard) Feb. 14, 2025

Feb. 14, 2025

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7331

1 0

Re: [PATCH v3 0/2] MR7335: wldap32: Build libldap with debugging facilities turned on, enable tracing with +libldap channel. - approved
by Alexandre Julliard (＠julliard) Feb. 14, 2025

Feb. 14, 2025

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7335

1 0

Re: [PATCH v4 0/2] MR7204: Fix running arm+arm64 in old wow64 mode - approved
by Alexandre Julliard (＠julliard) Feb. 14, 2025

Feb. 14, 2025

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7204

1 0

Re: [PATCH v4 0/4] MR7308: windows.storage: Add error handling in IRandomAccessStreamReferenceStatics::CreateFromStream(). - approved
by Alexandre Julliard (＠julliard) Feb. 14, 2025

Feb. 14, 2025

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7308

1 0

Re: [PATCH v2 0/1] MR7330: msi: Avoid invalid access when handling format strings. - approved
by Alexandre Julliard (＠julliard) Feb. 14, 2025

Feb. 14, 2025

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7330

1 0

Re: [PATCH v5 0/1] MR7322: programs/cmd: Implement ability to abort lengthy directory operations via Ctrl-C.
by Joe Souza (＠JoeS209) Feb. 14, 2025

Feb. 14, 2025

On Fri Feb 14 18:29:59 2025 +0000, eric pouech wrote: > thanks for the update... > that's better however, that's not exactly what should be done > some background first: > - cmd.exe for its builtin commands use a RETURN_CODE; this return code > gets the status of the command execution (NO_ERROR success, error codes, > but also propagating an 'EXIT /B' return value...) > - each command eventually sets the ERRORLEVEL based on the RETURN_CODE > (some builtin commands always do, some only do it in case of != 0 return > code - and leave ERRORLEVEL untouched in case of success -, and some > even have a different behavior if run from a .BAT or a .CMD command file) > - the return code is used as a basis in command chaining (esp. && and || > with success/failure of LHS to decide or not to execute RHS) > note: this some evolution in code base that has been started last year > and the target is that all builtin implementation follow that scheme. > not all of them have been fully migrated > from what's tested DIR seem to always set the ERRORLEVEL to the > return_code value (file not found...) > but in case of ctrl-c, the return code shall be STATUS_CTRL_C_EXIT and > errorlevel 1 (we'll need the return_code to be STATUS_CTRL_C_EXIT so > that upper functions can decide to implement the 'Terminate batch job > (Y/N)' at some point) > so we globally need to invert the logic: in WCMD_dir and its helpers, > always set the return_code, and set the errorlevel at WCMD_dir exit > based on return_code value > in this case, you should: > - have a local var `RETURN_CODE return_code; `in WCMD_list_directory > - use `return_code == NO_ERROR` to continue looping (and only this > pattern as we could in later patches have more return codes stored in return_code) > - and return the return_code from the helper into the WCMD_dir (which > shall then break the loop, free all directory structures and finally set > error level based on return code) > simple test (by hand, should be harder to integrate in test suite): > `dir /s \*.* || echo foobar` > interrupt with ctrl-c, shall print `foobar` at the end Looking through the existing code, especially WCMD_directory, there seems to be no distinction between errorlevel and the RETURN_CODE that the function returns. In most cases I see the code set errorlevel to some value and then the function returns errorlevel. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7322#note_94635

1 0