April 2025 - Wine-gitlab - list.winehq.org

[PATCH 0/2] MR7884: odbc32: Fix some NULL pointer issues
by Stefan Dösinger 26 Apr '25

26 Apr '25

I ran into this trying to use the Mac-Native MS SQL Server ODBC driver -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7884

2 3

[PATCH 0/1] MR7912: appwiz.cpl: Report addon download failures.
by Esme Povirk (＠madewokherd) 26 Apr '25

26 Apr '25

This relates to https://bugs.winehq.org/show_bug.cgi?id=58160 but doesn't fix it, just reports the error instead of stalling. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7912

2 1

[PATCH 0/1] MR7911: odbc32: Fix replicating unixODBC data sources.
by Hans Leidekker (＠hans) 26 Apr '25

26 Apr '25

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58140 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7911

2 1

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

26 Apr '25

eric pouech (@epo) commented about programs/cmd/lineedit.c: > + } > + oldCurPos = curPos; > + curPos = 0; > + while (curPos < len && > + inputBuffer[curPos] != L'\t' && > + inputBuffer[curPos] != L'\x1B' > + ) { > + > + curPos++; > + } > + /* curPos is often numRead - 1, but not always, as in the case where history is retrieved > + * and then user backspaces to somewhere mid-string and then hits Tab. > + */ > + TRACE("numRead: %lu, curPos: %u\n", *numRead, curPos); > + > + switch (inputBuffer[curPos]) { looks to be that curPos can be \> \*numRead, hence reading garbage in that case -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7843#note_101933

1 0

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

26 Apr '25

eric pouech (@epo) commented about programs/cmd/lineedit.c: > + > + FindInsertPos(inputBuffer, curPos, &sc); > + } > + > + /* Copy search results to input buffer. */ > + UpdateInputBuffer(inputBuffer, inputBufferLength, &sc); > + > + /* Update cursor position to end of buffer. */ > + curPos = lstrlenW(inputBuffer); > + if (curPos > maxLen) { > + maxLen = curPos; > + } > + } > + break; > + > + case L'\x1B': /* ESC */ looks at that question, and you're right... ReadConsole needs to handle ESC. I'll send a patch later on, so can drop ESC handling from your patch -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7843#note_101934

1 0

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

26 Apr '25

eric pouech (@epo) commented about programs/cmd/lineedit.c: > + int lastStartQuote; > + int searchPos; > + int insertPos; > +} SEARCH_CONTEXT, *PSEARCH_CONTEXT; > + > + > +static BOOL IsDirectoryOperation(const WCHAR *inputBuffer, const ULONG inputBufferLength) > +{ > + int cc = 0; > + BOOL ret = FALSE; > + > + while (cc < inputBufferLength && (inputBuffer[cc] == L' ' || inputBuffer[cc] == L'\t')) { > + cc++; > + } > + > + if ((cc + 2 < inputBufferLength && (inputBuffer[cc + 2] == L' ' || inputBuffer[cc + 2] == L'\t')) && questionning about finding the end of first word algorithm native behavior is very inconsistent `>cd\windows` (note that there's no space between "cd" and "\\"). is supported as command, but tab-completion on "windows" doesn't work **but** `>cd"\windows"` (idem no space, but with quotes). isn't supported as a command, but tab-completion does work since this relates to corner cases of user interaction, I'm not sure we want to mimic all these broken behaviors for consistency I'd rather suggest that you use `WCMD_parameter` to split the edit line into separate words you can then work upon this at least will provide consistency across all the code -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7843#note_101935

1 0

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

26 Apr '25

eric pouech (@epo) commented about programs/cmd/lineedit.c: > + } else { > + cc = len; > + while (cc > 0 && inputBuffer[cc] != L' ' && inputBuffer[cc] != L'\t') { > + cc--; > + } > + } > + } > + > + if (cc != sc->searchPos || inputBuffer[sc->searchPos] == L'\\') { > + cc++; > + } > + > + sc->insertPos = cc; > +} > + > +static void FindNextMatchingDirectoryEntry(const WCHAR *searchstr, PSEARCH_CONTEXT sc) a couple of comments here: * actually, this is not exactly how native (Win10) behaves: native captures the list of matching files at first tab usage, and doesn't update that list if eg. a file matching the pattern is added * the way done here is a bit more dynamic (as it would capture file creation/deletion), and I don't think it matters much from a user perspective the main thing I'm concerned about is that code to handle backwards shift-tab will be a bit more painful, and also the restart case (when the matched file is deleted) I think code would be simpler and more readable when storing the list of files, but I won't block on that. I let you pick up your favorite one. if you keep current logic, it seems to me that: * \-\>hadOneMatch is only used locally, and should rather be a local variable * \-\>hasSearchResult would make more sense be return value from this function -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7843#note_101936

1 0

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

26 Apr '25

eric pouech (@epo) commented about programs/cmd/lineedit.c: > + } > + lstrcatW(searchstr, L"*"); > + TRACE("New search: [%s]\n", wine_dbgstr_w(searchstr)); > + > + sc.isDirSearch = IsDirectoryOperation(inputBuffer, inputBufferLength); > + } > + > + FindNextMatchingDirectoryEntry(searchstr, &sc); > + > + if (sc.haveSearchResult) { > + /* If this is our first time through here for this search, we need to find the insert position > + * for the results. Note that this is very likely not the same location as the search position. > + */ > + if (!sc.insertPos) { > + /* If user entered a backslash after quotes, remove the quotes. */ > + if (curPos > 2 && inputBuffer[curPos-2] == L'\"' && inputBuffer[curPos-1] == L'\\') { I think quote handling is not done as it should from what I see on native: quotes are added when generated word does contain characters that would need to be escaped (eg ' ', but didn't check all the others) need quote is an attribute of current filename (ie they are removed when the new (partial) matching file no longer needs them) ; so quotes shouldn't be part of the SEARCH_CONTEXT, but only used for display (basically: go to beg of word; if needs quotes, print quote; print (partial) word; print ending quotes (if needed) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7843#note_101937

1 0

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

26 Apr '25

didn't play a lot with resulting code, mostly reviewed it note: dir "c:\\Programs Files\\"\<tab\> should circle among the subdirectories... current code doesn't also dir c\<tab\> (with a first file displayed), then reduce size of console window to be shorter than input line, will display input on line after the prompt -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7843#note_101938

1 0

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