October 2020 - Wine-Bugs - list.winehq.org

[Bug 50035] Bugs in ntdll-Junction_Points staging patchset

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=50035 --- Comment #4 from Martin Storsjö <martin(a)martin.st> --- (In reply to Erich E. Hoover from comment #3) > (In reply to Martin Storsjö from comment #0) > > Created attachment 68475 [details] > > First patch > > This used to be part of: > ntdll-Junction_Points/0019-kernel32-Implement-CreateSymbolicLink-A-W-with- > ntdll.patch Yeah, it seems to have been lost here: https://github.com/wine-staging/wine-staging/commit/4ffe305c90f9e15141f2c1b… > Must have gotten lost in a rebase. You are missing a free: > HeapFree( GetProcessHeap(), 0, linkW ); > that should occur both at the end and if linkW gets allocated and targetW > fails. No, I'm taking a shortcut, by passing FALSE to the alloc parameter to the FILE_name_AtoW function - just like CopyFileA does: https://source.winehq.org/git/wine.git/blob/f6a5a3d03c1eb914444af96352ca54e… The comment above FILE_name_AtoW says: https://source.winehq.org/git/wine.git/blob/f6a5a3d03c1eb914444af96352ca54e… * If alloc is FALSE uses the TEB static buffer, so it can only be used when * there is no possibility for the function to do that twice, taking into * account any called function. AFAIK that should be ok here? > > Attaching two patches that can be squashed into the existing patches in > > ntdll-Junction_Points. The bugs are that FindNextFileW doesn't properly set > > the dwReserved0 field (containing the ReparseTag value) if iterating over > > files in a directory other than the current one, and that > > CreateSymbolicLinkA is unimplemented. > > That is a good find, I only tested this in wcmd - so I never noticed. > Please use sizeof(WCHAR)*2 instead of 4. Sure > Also, is there a reason you are avoiding lstrcpyW and lstrcatW? No, I just wasn't aware of them. But I actually need lstrcpynW, because info->path points to the full string ending with "dirname\*", while we just want the dirname. But the intermediate extra backslash isn't needed as it's included in info->path.Length. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Oct. 22, 2020

[Bug 48336] Applications using MS ADO require Recordset Connect to be implemented (Enterprise Architect, Brickcom CMS client)

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=48336 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|NEW |RESOLVED Fixed by SHA1| |57e30f27cb3f4d3d494660b0974 | |6b67b152efcc7 --- Comment #23 from Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> --- Fixed by https://source.winehq.org/git/wine.git/?a=commit;h=57e30f27cb3f4d3d494660b0… -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Oct. 22, 2020

[Bug 50036] Remaining issues in Bugs in ntdll-Junction_Points in staging

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=50036 --- Comment #2 from Martin Storsjö <martin(a)martin.st> --- (In reply to Erich E. Hoover from comment #1) > If I may ask, what are you using symlinks for? (I want them to eventually > reduce the space consumed by the prefix, but getting them upstream has been > a challenge) My usecase, admittedly probably pretty nontypical, is that I'm working on getting the libc++ testsuite for the C++17 std::filesystem module to work with MSVC's STL, as a preparatory step for trying to implement std::filesystem in libc++ for windows targets. (Previously, both libc++'s implementation and tests of this part were very much unix-only.) I'm not much of a windows user myself and mostly cross compile, so being able to do most of the testing with wine makes the work much more convenient. So far, mostly everything exercised by the testsuite works the same in wine, but there's a bunch of tests for symlinks (some entirely disabled, and some that work on native windows but not on wine). I'm not sure if there's other issues on the wine side still, but these two issues are the ones that I've so far pinpointed on the wine side. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Oct. 22, 2020

[Bug 49849] system("CLS") don't work

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=49849 Jeff Smith <whydoubt(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |whydoubt(a)gmail.com --- Comment #1 from Jeff Smith <whydoubt(a)gmail.com> --- This is now fixed. I believe several patches affected this, but the final one that seems to have fixed this issue was: 54e117018cd4cc58c258da92686bfad13946bde2 Author: Jacek Caban <jacek(a)codeweavers.com> Date: Mon Sep 21 17:07:29 2020 +0200 kernelbase: Use conhost to handle Unix consoles. This was included in wine 5.18. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Oct. 22, 2020

[Bug 50037] wineconsole and mingw64 gdb.exe and keyboard input

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=50037 --- Comment #1 from Vladimir Koković <vladimir.kokovic(a)gmail.com> --- "mingw64 gdb.exe(9.2) which works fine in wine17" -> "mingw64 gdb.exe(9.2) which works fine in wine 5.18" -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Oct. 22, 2020

[Bug 50037] wineconsole and mingw64 gdb.exe and keyboard input

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=50037 Vladimir Koković <vladimir.kokovic(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|5.18 |unspecified -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Oct. 22, 2020

[Bug 49915] can not register COM server

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=49915 Jeff Smith <whydoubt(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |whydoubt(a)gmail.com --- Comment #1 from Jeff Smith <whydoubt(a)gmail.com> --- It appears that the commands you used were WINARCH=win32 WINEPREFIX=~/wine32 WINEDEBUG=warn+all winecfg WINARCH=win32 WINEPREFIX=~/wine32 WINEDEBUG=warn+all wine start TradeStationSetup.exe The first thing I notice is that you should be using WINEARCH, not WINARCH. I would suggest removing the ~/wine32 wineprefix and try again using WINEARCH, to see if you get better results. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Oct. 22, 2020

[Bug 50037] wineconsole and mingw64 gdb.exe and keyboard input

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=50037 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |627d31fcd9fa1e4657c781ca07f | |f25e437101820 Keywords| |regression CC| |jacek(a)codeweavers.com Version|unspecified |5.18 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Oct. 22, 2020

[Bug 50036] Remaining issues in Bugs in ntdll-Junction_Points in staging

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=50036 --- Comment #1 from Erich E. Hoover <erich.e.hoover(a)gmail.com> --- I had this working at one point where FILE_FLAG_OPEN_REPARSE_POINT gets translated into O_SYMLINK (O_NOFOLLOW | O_PATH), I'll have to see what went wrong. If I may ask, what are you using symlinks for? (I want them to eventually reduce the space consumed by the prefix, but getting them upstream has been a challenge) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Oct. 21, 2020

[Bug 50035] Bugs in ntdll-Junction_Points staging patchset

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=50035 --- Comment #3 from Erich E. Hoover <erich.e.hoover(a)gmail.com> --- (In reply to Martin Storsjö from comment #0) > Created attachment 68475 [details] > First patch This used to be part of: ntdll-Junction_Points/0019-kernel32-Implement-CreateSymbolicLink-A-W-with-ntdll.patch Must have gotten lost in a rebase. You are missing a free: HeapFree( GetProcessHeap(), 0, linkW ); that should occur both at the end and if linkW gets allocated and targetW fails. > Attaching two patches that can be squashed into the existing patches in > ntdll-Junction_Points. The bugs are that FindNextFileW doesn't properly set > the dwReserved0 field (containing the ReparseTag value) if iterating over > files in a directory other than the current one, and that > CreateSymbolicLinkA is unimplemented. That is a good find, I only tested this in wcmd - so I never noticed. Please use sizeof(WCHAR)*2 instead of 4. Also, is there a reason you are avoiding lstrcpyW and lstrcatW? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Oct. 21, 2020