wine-bugs February 2022

wine-bugs@winehq.org

1 participants
3932 discussions

[Bug 49884] New: When transitioning from Useful Registry Keys to Wine Man Page - 404 Page Not Found Error
by WineHQ Bugzilla 23 Mar '22

23 Mar '22

https://bugs.winehq.org/show_bug.cgi?id=49884 Bug ID: 49884 Summary: When transitioning from Useful Registry Keys to Wine Man Page - 404 Page Not Found Error Product: WineHQ.org Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: www-unknown Assignee: wine-bugs(a)winehq.org Reporter: commissaris.mike(a)gmail.com Distribution: --- Clicked on Wine Man Page at bottom of Useful Registry Keys page and the result was page not found. Broken link? -- 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.

1 2

[Bug 49754] New: Invalid write of size 4 - while clearing thread stack
by WineHQ Bugzilla 23 Mar '22

23 Mar '22

https://bugs.winehq.org/show_bug.cgi?id=49754 Bug ID: 49754 Summary: Invalid write of size 4 - while clearing thread stack Product: Wine Version: 5.16 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: jeffersoncarpenter2(a)gmail.com Distribution: --- Created attachment 68058 --> https://bugs.winehq.org/attachment.cgi?id=68058 Valgrind output Occurs as of 5bb27d1edb2. Steps to reproduce: * Build 'int main() { return 0; }' using i686-w64-mingw32-gcc. * Run wine under valgrind (valgrind output attached). Valgrind output snippet: ==9636== Invalid write of size 4 ==9636== at 0x7BC7AA17: ??? (signal_i386.c:470) ==9636== Address 0x61bab0 is on thread 1's stack -- 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.

1 3

[Bug 52237] New: Lots of errors running under valgrind
by WineHQ Bugzilla 23 Mar '22

23 Mar '22

https://bugs.winehq.org/show_bug.cgi?id=52237 Bug ID: 52237 Summary: Lots of errors running under valgrind Product: Wine Version: 7.0-rc2 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: dark.shadow4(a)web.de Distribution: --- Created attachment 71345 --> https://bugs.winehq.org/attachment.cgi?id=71345 valgrind lock using wine-7.0-rc2 (no mingw build) I tried running wine under valgrind, but it generates over 1000 errors or makes valgrind fail with an assertion. Using a wine-7.0-rc2 debug build. Compile parameters: CC="ccache gcc" CFLAGS="-g -O0 -fcommon" CROSSCFLAGS="-g -O0 -fcommon" ../wine-git/configure --without-cups --enable-win64 --disable-tests --enable-silent-rules --without-mingw -- 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.

1 3

[Bug 49914] New: Windows CLI has error with text highlighting
by WineHQ Bugzilla 22 Mar '22

22 Mar '22

https://bugs.winehq.org/show_bug.cgi?id=49914 Bug ID: 49914 Summary: Windows CLI has error with text highlighting Product: Wine Version: 5.18 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: shagooserver(a)gmail.com Distribution: --- Created attachment 68285 --> https://bugs.winehq.org/attachment.cgi?id=68285 example The latest version of wine extends the highlight colour of a windows terminal command to far. In the attached example the green highlight should only cover the word "Done" or that line only. What happens though is that the highlight extends through to the following command prompt. Although not shown in the example but also occurring is the intervening blank line between "Done" and the following command prompt is also green highlighted. -- 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.

1 3

[Bug 11112] New: Does the fatal error if the config directory isn' t owned by the user make sense?
by wine-bugs＠winehq.org 21 Mar '22

21 Mar '22

http://bugs.winehq.org/show_bug.cgi?id=11112 Summary: Does the fatal error if the config directory isn't owned by the user make sense? Product: Wine Version: CVS/GIT Platform: All OS/Version: All Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: bero(a)arklinux.org Created an attachment (id=10147) --> (http://bugs.winehq.org/attachment.cgi?id=10147) Proposed fix Recent wine versions abort on startup if the config directory isn't owned by the user running wine. This breaks setups where several users share a common wine prefix (e.g. to make applications that make heavy use of the registry available to several users without installing them several times) and they have the right access to the configs through group permissions. Unless I'm overlooking a better way to do this, it would make more sense to check proper permissions than to check ownership. I'm attaching a patch that does that. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 50

[Bug 52110] New: Can't open the Restoro app
by WineHQ Bugzilla 20 Mar '22

20 Mar '22

https://bugs.winehq.org/show_bug.cgi?id=52110 Bug ID: 52110 Summary: Can't open the Restoro app Product: WineHQ Apps Database Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: appdb-unknown Assignee: wine-bugs(a)winehq.org Reporter: juwaeny21(a)gmail.com Distribution: --- Created attachment 71134 --> https://bugs.winehq.org/attachment.cgi?id=71134 Log Bug when opening the Restoro application, but after this it displays a Program Error, the message "thi can be caused by a problem in the program or a deficiency in wine. you may to check the Application Database for tips about running this application" -- 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.

1 4

[Bug 52151] New: Powershell Core 7.2.0 (64-bit) crashes at start
by WineHQ Bugzilla 20 Mar '22

20 Mar '22

https://bugs.winehq.org/show_bug.cgi?id=52151 Bug ID: 52151 Summary: Powershell Core 7.2.0 (64-bit) crashes at start Product: Wine Version: 6.22 Hardware: x86-64 URL: https://github.com/PowerShell/PowerShell/releases/down load/v7.2.0/PowerShell-7.2.0-win-x64.msi OS: Linux Status: NEW Keywords: download Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: xerox.xerox2000x(a)gmail.com Distribution: Debian The new 7.2.0 64-bit version crashes instantly: wine pwsh.exe: 00c4:fixme:ntdll:EtwEventActivityIdControl 0x1, 000000000019E928: stub Fatal error. Internal CLR error. (0x80131506) at System.Management.Automation.Security.NativeMethods.SaferIdentifyLevel(UIn t32, System.Management.Automation.Security.SAFER_CODE_PROPERTIES ByRef, IntPtr B yRef, System.String) at System.Management.Automation.Internal.SecuritySupport.GetSaferPolicy(Syste m.String, System.Runtime.InteropServices.SafeHandle) at System.Management.Automation.Security.SystemPolicy.TestSaferPolicy(System. String, System.String) The 32-bit version (https://github.com/PowerShell/PowerShell/releases/download/v7.2.0/PowerShel…) starts fine, so I guess it`s not about unimplemented stuff/incomplete stubs but rather something in wine`s 64<->32 handling?? (Note: in traces there was something about some missing wldp.dll, but it should start also without that dll; couldn`t further really find out where this crash would come from) -- 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.

1 3

[Bug 25773] New: Majesty 2: certain keyboard keys are not recognized
by wine-bugs＠winehq.org 19 Mar '22

19 Mar '22

http://bugs.winehq.org/show_bug.cgi?id=25773 Summary: Majesty 2: certain keyboard keys are not recognized Product: Wine Version: 1.3.11 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: gyebro69(a)gmail.com Created an attachment (id=32841) --> (http://bugs.winehq.org/attachment.cgi?id=32841) terminal output I noticed the problem when trying to start a multiplayer game. Logging in to Gamespy requires an email address but the period '.' sign used in the address was not accepted in the input field. It turned out that several other keys are not recognized by the game, e.g.: ~,[]/;'\=-+. By default '~' is used to bring up the chat window. The issue can be tested by creating a new profile in the game: the input field, containing the name, should accept all of the above mentioned characters but they're not recognized (only the letters and numbers work and some of the special characters by using <Shift>: @!$%). Installing native dinput8.dll (via winetricks) doesn't help in Majesty 2. Fedora 14 / Gnome 2.32.0 / xorg-x11-server 1.9.3-3.fc14 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.

2 8

[Bug 50710] New: relative paths in WINEDLLPATH (as created from $0) no longer work in wine-5.11+
by WineHQ Bugzilla 17 Mar '22

17 Mar '22

https://bugs.winehq.org/show_bug.cgi?id=50710 Bug ID: 50710 Summary: relative paths in WINEDLLPATH (as created from $0) no longer work in wine-5.11+ Product: Wine Version: 6.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: loader Assignee: wine-bugs(a)winehq.org Reporter: PuetzKevinA(a)JohnDeere.com Distribution: --- Winegcc's app_loader_template deriveds $appdir from $0, and then adds this directory into WINEDLLPATH: https://source.winehq.org/git/wine.git/blob/wine-6.0:/tools/winegcc/winegcc… appdir=`dirname \"$0\"` WINEDLLPATH=\"$appdir:$WINEDLLPATH\" Presumably the intent here is to match LOAD_LIBRARY_SEARCH_APPLICATION_DIR; windows also searches for dlls immediately beside the main executable. However, it is not unusual in interactive use for $0 to be a relative path, e.g. if an executable is invoked as ./hello.exe, and dirname preserves this. This results in WINEDLLPATH containing relative-path entries; this seems a bit inadvisable, but it worked through wine-5.10. Since then it does not. 0024:err:module:import_dll Loading library test_shared.dll (which is needed by L"Z:\\home\\test\\\bin\\test_executable_shared.exe") failed (error c000003b). Bisecting first pointed at df5e4764870e8ad1d8b206cb3475a073bc034e48, but this is just https://bugs.winehq.org/show_bug.cgi?id=49545; after the unix cwd is lost, a relative-path entry no longer resolves to the right place. cherry-picking that fix from cdaa72c728df3c80499c8a4f59e731f353347db0 restores functionality, but then it breaks again (for the reason that is actually breaking it in 6.0) at 9ec262ebcc7f14d7373841d4ca082b855ed8090f https://source.winehq.org/git/wine.git/blobdiff/a2e77268f2007f2819c2e3e8bd7… Previously ntdll/unix/loader.c:open_builtin_file used unix_to_nt_file_name, which looks like it would have just flipped the slashes to translate a a relative unix path to a relative NT path, which would then use NT's cwd (hence susceptibility to https://bugs.winehq.org/show_bug.cgi?id=49545), But now it uses open_unix_file, which calls SERVER_START_REQ( create_file ), which just refuses relative paths STATUS_OBJECT_PATH_SYNTAX_BAD https://source.winehq.org/git/wine.git/blob/wine-6.0:/server/file.c#l214 This is an error other than STATUS_OBJECT_{PATH,NAME}_NOT_FOUND, so it stops https://source.winehq.org/git/wine.git/blob/wine-6.0:/dlls/ntdll/unix/loade… I'm not sure what the best fix here really is... relative paths in WINEDLLPATH seem like a pretty bad idea (since the cwd may change as the process runs, environment variables leak down into child processe, etc), but the launcher script's been like this for a long time. -- 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.

1 2

[Bug 52565] New: CD/DVD Druckerei v6.0 - can't detect original DVD media because of ProtectDisc
by WineHQ Bugzilla 14 Mar '22

14 Mar '22

https://bugs.winehq.org/show_bug.cgi?id=52565 Bug ID: 52565 Summary: CD/DVD Druckerei v6.0 - can't detect original DVD media because of ProtectDisc Product: Wine Version: 7.2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: vaxxabait(a)gmail.com Distribution: --- CD/DVD Druckerei is a disc labeling software primarily for German-speaking market. It installs fine on Wine, but after starting it checks and ask to insert original DVD media in the drive although it is in the drive. The path to DVD is added as D: drive of CDROM type in Winecfg. It is the same D: drive software has been installed from. I set up Windows 2000 in Winecfg because software seems to be roughly from this age. I've checked the main executable with Protection_ID v0.6.8.5, which detects: [!] ProtectDISC v6.6 [Build 0xC744 / 51012] [!] protection level: Basic So seems like it prevents software to start. According to https://wiki.winehq.org/Copy_Protection, ProtectDISC is not supported yet. Since original issue (https://bugs.winehq.org/show_bug.cgi?id=9484) is closed as abandoned now, I would like to raise the topic again. -- 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.

1 6

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-bugs February 2022