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

[Bug 49950] d3d10:reflection tests crash

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=49950 --- Comment #1 from Gijs Vermeulen <gijsvrm(a)gmail.com> --- I can seem to reproduce this with wine-5.19. I am running a GTX 750 Ti, prop driver 455.28. -- 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. 10, 2020

[Bug 49974] New: termite-3.4 can't connect to com5 -> /dev/ttyACM0

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=49974 Bug ID: 49974 Summary: termite-3.4 can't connect to com5 -> /dev/ttyACM0 Product: Wine Version: 5.18 Hardware: x86-64 URL: https://www.compuphase.com/software_termite.htm OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: cedric.dewijs(a)eclipso.eu Distribution: ArchLinux Created attachment 68375 --> https://bugs.winehq.org/attachment.cgi?id=68375 console messages Summary termite-3.4 can't connect to com5 -> /dev/ttyACM0 Prepare wine: $ rm -rf ~/.wine/ $ wineserver -k $ wineboot Download location https://www.compuphase.com/software_termite.htm https://www.compuphase.com/software/termite-3.4.exe $ sha256sum termite-3.4.exe ca440b6c7f6eaa812ba5f8bf42aed86e02022ca50a1c72585168c9b671d0fe19 termite-3.4.exe Steps to reproduce: 1) Install the program: $ wine termite-3.4.exe Accept the defaults. Now termite starts. 2) Press settings. The dropdown box only shows COM1. Choose baud rate 9600 and press OK. Now termite reports "Failed to initialize the port. Please verify the COM port settings." 3) Press "Connect". Now that termite reports "Waiting for port" 4) Press close. Now termite closes. As a sanity test, I open moserial, choose /dev/ttyACM0 9600,8N1, press connect, and I see the messages my MCP2221 serial to USB converter is sending to me. /dev/ttyACM0 is detected by wine: $ ls -l ~/.wine/dosdevices/ total 0 lrwxrwxrwx 1 cedric cedric 10 Oct 10 19:25 c: -> ../drive_c lrwxrwxrwx 1 cedric cedric 10 Oct 10 19:35 com1 -> /dev/ttyS0 lrwxrwxrwx 1 cedric cedric 12 Oct 10 19:35 com5 -> /dev/ttyACM0 lrwxrwxrwx 1 cedric cedric 8 Oct 10 19:26 d:: -> /dev/sr0 lrwxrwxrwx 1 cedric cedric 1 Oct 10 19:25 z: -> / My versions $ wine --version wine-5.18 (Staging) $ pacman -Q wine wine-staging 5.18-1 uname -a Linux cedric-p4 5.8.14-arch1-1 #1 SMP PREEMPT Wed, 07 Oct 2020 23:59:46 +0000 x86_64 GNU/Linux -- 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. 10, 2020

[Bug 49529] 5.12 regression: Wine segfaults if the +heap debug channel is enabled

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=49529 subgraph93(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from subgraph93(a)gmail.com --- I don't think this ever happened again after 5.13, so I'll assume this is fixed and mark is as such. Thank you for your work, Wine developers. -- 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. 10, 2020

[Bug 49973] New: 64-bit Cheat Engine does not properly handle 32-bit processes

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=49973 Bug ID: 49973 Summary: 64-bit Cheat Engine does not properly handle 32-bit processes Product: Wine Version: 5.4 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: subgraph93(a)gmail.com Distribution: --- Created attachment 68374 --> https://bugs.winehq.org/attachment.cgi?id=68374 cheatengine-x86_64.exe attaching to Tutorial-i386.exe Distribution: Ubuntu 20.04 Program download: Cheat Engine 7.1, available from https://cheatengine.org/downloads.php (the actual link appears to change on every page refresh) Program source code: available at https://github.com/cheat-engine/cheat-engine/ On Windows 7, 64-bit Cheat Engine (cheatengine-x86_64.exe) works fine for 32-bit processes as well as 64-bit processes. However, when using Wine, 64-bit CE cannot properly attach to 32-bit processes. 32-bit CE works fine for 32-bit processes. Explaining in some more detail below. To attach CE to a program, start CE and the program (in any order), then when CE opens, click the "Open process" icon (it looks like a desktop monitor with a magnifying glass; it's below the "File" menu button) and select the target process from the list. CE comes with its own tutorial programs (32-bit and 64-bit), so installing another, unrelated program shouldn't be needed for testing. A simple way to identify whether the issue exists is to add an address using the executable name. To do this, click the "Add Address Manually" button in CE, enter ["programname.exe"] (with the square brackets; e. g. ["Tutorial-i386.exe"]) in the "Address" box, then click OK. Note the new entry in the address list below and check the value in the "Address" column for that entry. When using 32-bit CE on a 32-bit program, the address column shows the actual address (e. g. 00905A4D) and may show a value, but when using 64-bit CE on a 32-bit program (something that works on Windows), the address column shows the text with the program name – something like (["Tutorial-i386.exe"]), with the parentheses, – and the value is just question marks. The most obvious impact of the issue is that cheat tables and assembly scripts cannot work unless the base address (is this the right term?) of the .exe is hardcoded. Other problems with using 64-bit CE on 32-bit programs are that the code finder does not work (so you can't complete Step 5 of the tutorial, which requires you to overwrite an instruction that changes a value; you can't find that instruction), and that pointer scans do not work. (I'll file other tickets if these turn out to be their own issues; but both features work fine if 32-bit CE is used on a 32-bit process.) I set the version as 5.4 because it's the first version I noticed this issue in. This issue was also present in every newer version up to 5.19 (both devel and staging channels). I don't think it's a regression. I didn't use Cheat Engine with Wine versions before 5.4. Attached the terminal output for the 5.19-staging test with 64-bit CE and the 32-bit tutorial. -- 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. 10, 2020

[Bug 49972] New: Termie 1.0 crashes after selecting a serial port.

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=49972 Bug ID: 49972 Summary: Termie 1.0 crashes after selecting a serial port. Product: Wine Version: 5.18 Hardware: x86-64 URL: http://termie.sourceforge.net/#downloads OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: cedric.dewijs(a)eclipso.eu Distribution: ArchLinux Created attachment 68373 --> https://bugs.winehq.org/attachment.cgi?id=68373 Console messages Summary Termie 1.0 crashes after selecting a serial port. Download location http://termie.sourceforge.net/#downloads http://termie.sourceforge.net/Termie-1.0-Binary.zip $ sha256sum Termie-1.0-Binary.zip 53469ffdb38058b985482cbfac3f4c0575eeafa4e1b766b5f0c2af43acb7cba6 Termie-1.0-Binary.zip $ unzip Termie-1.0-Binary.zip Steps to reproduce: 1)Start the program: $ wine Termie.exe After a long time (+- 20 seconds) the program opens. 2) Select one of the comm port. Now the program crashes. 3) Press ctrl-c in the console to kill wine. 4) restart Termie. $ wine Termie.exe Now wine gives this error. "[ERROR] FATAL UNHANDLED EXCEPTION: System.IO.IOException: Broken pipe." Every time Termie is restarted via step 3, it crashes the same way. My versions $ wine --version wine-5.18 (Staging) $ pacman -Q wine wine-staging 5.18-1 uname -a Linux cedric-p4 5.8.14-arch1-1 #1 SMP PREEMPT Wed, 07 Oct 2020 23:59:46 +0000 x86_64 GNU/Linux -- 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. 10, 2020

[Bug 49942] Games on Battle.net refuse to launch using either wine-5.18 or wine-staging-5.18

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=49942 --- Comment #5 from nvaert1986 <nvaert1986(a)hotmail.com> --- UPDATE: I'm not sure whether mingw is being using, when I check the ebuild it states that when using multilib. I'm assuming they mean both 32-bit and 64-bit support, but if multilib means something different then it's not the case. If they define it as 32-bit and 64-bit support, then mingw is definitely turned off. multilib_src_configure() { local myconf=( --without-mingw # linux LDFLAGS leak in mingw32: bug #685172 ) -- 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. 10, 2020

[Bug 49942] Games on Battle.net refuse to launch using either wine-5.18 or wine-staging-5.18

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=49942 nvaert1986 <nvaert1986(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Distribution|--- |Gentoo -- 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. 10, 2020

[Bug 49942] Games on Battle.net refuse to launch using either wine-5.18 or wine-staging-5.18

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=49942 --- Comment #4 from nvaert1986 <nvaert1986(a)hotmail.com> --- (In reply to Sveinar Søpler from comment #3) > Since you mentiones "ebuilds", does that indicate Gentoo? If so.. Are you > compiling wine --with-mingw ? (Loads of PE dll work has been done as of > late, that may break some games if NOT compiled with mingw-w64) > > In the case of you actually using mingw-w64, wine-staging-5.0 is somewhat > "old", so upgrading the wineprefix -> wine-staging-5.18++ might break stuff. > > I think i had some problems needing me to redo my prefix when coming from > wine-staging-4.x -> wine-staging-5.x due to some leftover crud on my > wineprefix i run battle.net games from. > > I am not sure what you mean by "clean install", but if that only means > reinstalling the game from the Battle.net app itself, it probably will not > do much if it is "old prefix crud" messing stuff up. > > Battle.net works fairly well re-using your old game install if you just > create a new wineprefix and moving the game folders over to the new > wineprefix, and let the Battle.net client search for games. With re-installing battle.net I mean removing my wine prefix using rm -rf .wine in my /home/username directory (which is the default prefix). There I completely re-installed everything twice. The installation of Battle.net and starting Battle.net works fine, but starting any of the games does not. Whenever I switch back to wine-staging.5.0 and start any of the games, they work flawlessly using the prefix created with wine-staging-5.18. I'm using Gentoo indeed. I'm not compiling with mingw or mingw-w64. I'm using GCC 9.3.0 using -O2 and --march=znver1 those ore the only flags set. I just started a compilation to double confirm if mingw is being called, but when watching the compilation, mingw is not being called at all. The only difference as of recent is unwind support, which I disabled, which is set through a USE flag, but which I don't need. -- 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. 10, 2020

[Bug 48529] Avencast: Rise of the Mage fails to launch

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=48529 Gijs Vermeulen <gijsvrm(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1|d5edadf35a40cb7238c2068db28 |1dcc3ab292151cd91ea4202b921 |b6c6abc7da800 |07c3a91527c7a --- Comment #4 from Gijs Vermeulen <gijsvrm(a)gmail.com> --- Just for posterity, Comment #2 is wrong, this was fixed by <https://source.winehq.org/git/wine.git/commit/1dcc3ab292151cd91ea4202b92107…> -- 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. 10, 2020

[Bug 49970] No sound in Supreme Commander FA - regression in 5.18

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=49970 --- Comment #6 from Gijs Vermeulen <gijsvrm(a)gmail.com> --- Created attachment 68372 --> https://bugs.winehq.org/attachment.cgi?id=68372 +xact3 So this is still present in wine-staging 5.19 with FAudio 20.10. Attached is a +xact3 log. This seems concerning: 0024:trace:xact3:IXACTEngineImpl_Initialize (0x2e23b38)->(0x3a6d2d4) 0024:warn:xact3:IXACTEngineImpl_Initialize FACTAudioEngine_Initialize returned -2 -- 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. 10, 2020