July 2022 - Wine-bugs - list.winehq.org

[Bug 52494] New: shell32 progman_dde tests crash if run immediately after prefix creation
by WineHQ Bugzilla 08 Nov '22

08 Nov '22

https://bugs.winehq.org/show_bug.cgi?id=52494 Bug ID: 52494 Summary: shell32 progman_dde tests crash if run immediately after prefix creation Product: Wine Version: 7.1 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: alexhenrie24(a)gmail.com Distribution: --- Created attachment 71789 --> https://bugs.winehq.org/attachment.cgi?id=71789 Backtrace Steps to reproduce: 1. Delete ~/.wine or move it to another location 2. Compile Wine and run `./wine dlls/shell32/tests/shell32_test.exe progman_dde` An example backtrace is attached. -- 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 7

[Bug 52667] New: DTS Master Audio Suite Encoder - can not select a save to file location so will not encode
by WineHQ Bugzilla 08 Nov '22

08 Nov '22

https://bugs.winehq.org/show_bug.cgi?id=52667 Bug ID: 52667 Summary: DTS Master Audio Suite Encoder - can not select a save to file location so will not encode Product: Wine Version: 7.4 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: --- This is a change from 7.3. At the bottom right of the GUI there is an area to enter the location of the file you are about to create, normally you click the "Save To" button to enter the location of the file you wish to save (name is stored by the program), alternatively I think you can type the location directly into the space next to the button. With the release of 7.4 it is no longer possible to either click the "Save To" button or enter the address into the space provided. As a result it is not possible to create a file. -- 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 41

[Bug 52704] New: Open File dialog doesn't work on FreeHand 9 demo
by WineHQ Bugzilla 08 Nov '22

08 Nov '22

https://bugs.winehq.org/show_bug.cgi?id=52704 Bug ID: 52704 Summary: Open File dialog doesn't work on FreeHand 9 demo Product: Wine Version: 7.4 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: bugs.drew(a)yahoo.com Distribution: --- Created attachment 72061 --> https://bugs.winehq.org/attachment.cgi?id=72061 FreeHand9 log After installing the demo, when you click on the "Open" icon on the "Welcome to FreeHand 9" wizard window, nothing happens visually but the err:module:DelayLoadFailureHook message appears in the log. This bug looks very similar to bug 45938 which AF analyzed. I'm not sure what was meant by "try GetModuleHandleExA() first before LoadLibraryA()" so I wasn't able to verify that it resolves this bug. -- 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 10

[Bug 52679] New: Anno 1602 / 1602 A.D. graphics too dark / black
by WineHQ Bugzilla 08 Nov '22

08 Nov '22

https://bugs.winehq.org/show_bug.cgi?id=52679 Bug ID: 52679 Summary: Anno 1602 / 1602 A.D. graphics too dark / black Product: Wine Version: 6.11 Hardware: x86-64 URL: https://archive.org/details/1602ADdemo OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: marc.pluhar+winehq(a)gmail.com Distribution: ArchLinux Created attachment 72012 --> https://bugs.winehq.org/attachment.cgi?id=72012 Screenshot of the game with black graphics When starting the game "Anno 1602" an intro video plays fine, but when arriving at the menu, everything is very dark (see 1602_ad_wine_6.11.png). I remember playing this game a while ago, so I tried different versions and it starts failing like this in version 6.11. When compiling the current master (8a52d3e93f5690fd0833c228d54a996a784afad7) directly from source, the problem also persists. Version 6.10 works fine. The demo of the game exhibits the same behaviour, so I added a download link for it. I also attached the console log, but I don't see anything different between the two starts. -- 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 17

[Bug 50433] New: 'MsiBreak' custom action debugging aid should use custom action's name from 'CustomAction' table (currently uses 'Target' field)
by WineHQ Bugzilla 08 Nov '22

08 Nov '22

https://bugs.winehq.org/show_bug.cgi?id=50433 Bug ID: 50433 Summary: 'MsiBreak' custom action debugging aid should use custom action's name from 'CustomAction' table (currently uses 'Target' field) Product: Wine Version: 6.0-rc4 Hardware: x86-64 OS: Linux Status: NEW Severity: trivial Priority: P2 Component: msi Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Distribution: --- Hello folks, I always have to remember that Wine uses 'Target' field/name from the 'CustomAction' table instead of the custom action's name when debugging custom actions. Fooled me quite a number of times in these 13 years. I'm aware that very few people might be concerned/affected with this inconsistency but still. https://docs.microsoft.com/en-us/windows/win32/msi/debugging-custom-actions I requested the installer debugging aid in 2007 in bug 8243 ("Feature: Add MsiBreak to aid debugging custom actions"): https://source.winehq.org/git/wine.git/commitdiff/60e95ee6e8ea4a4f43a6c170c… ("msi: Add handling for MsiBreak.") My follow-up comment https://bugs.winehq.org/show_bug.cgi?id=8243#c7 was ignored. Maybe because I didn't bother to create a follow-up bug and/or didn't complain loud enough ;-) --- quote --- Please fix the evaluation to use "action" msi_custom_action_info member instead of "target" to make it feature compatible with Windows MSI server. --- quote --- Some example (from bug 21987): --- snip --- ... 01b0:trace:msi:ACTION_CustomAction Handling custom action L"CreateAdobePDFPrinter" (c41 L"AdobeIsf" L"SetupAdobePDFPrinter") ... 01b0:trace:msi:HANDLE_CustomType1 Calling function L"SetupAdobePDFPrinter" from L"C:\\users\\focht\\Temp\\msi48b7.tmp" ... 02f8:Ret PE DLL (proc=0160618A,module=01600000 L"msi48b7.tmp",reason=PROCESS_ATTACH,res=00000000) retval=1 ... 02f8:Ret KERNEL32.LoadLibraryW() retval=01600000 ret=100210f6 02f8:Call KERNEL32.GetProcAddress(01600000,0016df28 "SetupAdobePDFPrinter") ret=1002110a 02f8:Ret KERNEL32.GetProcAddress() retval=01602bea ret=1002110a ... --- snip --- To have this work for Wine 'MsiBreak=SetupAdobePDFPrinter' is needed but 'MsiBreak=CreateAdobePDFPrinter' would be correct. $ wine --version wine-6.0-rc4 Regards -- 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

[Bug 52434] New: Light Blue theme has rendering errors in tree views
by WineHQ Bugzilla 08 Nov '22

08 Nov '22

https://bugs.winehq.org/show_bug.cgi?id=52434 Bug ID: 52434 Summary: Light Blue theme has rendering errors in tree views Product: Wine Version: 7.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: comctl32 Assignee: wine-bugs(a)winehq.org Reporter: nyanpasu64(a)tuta.io Distribution: --- Created attachment 71705 --> https://bugs.winehq.org/attachment.cgi?id=71705 Screenshot of foobar2000 in Light Blue color scheme When I enable the new Light Blue theme in Wine 7.0, tree views (eg. OpenMPT and foobar2000) render incorrectly. The background is light gray #F5F5F5 (and changes if you change Controls Background in winecfg and apply, then restart foobar2000), but every line of text has a white #FFFFFF background. I think this is a rendering bug. Additionally in foobar2000, if you add a Selection Properties element, the Metadata/Location text is light gray on a white background. The text color changes if you change Hot Tracked Element in winecfg and apply, then restart foobar2000. This may be a poor choice of colors. I forgot Wine's old default color for Hot Tracked Element, but the new default when I switch to (No Theme) is #0000C8, which makes foobar2000 look more saturated than I remember. On Windows 7+, foobar2000 renders text in light blue-cyan rather than saturated dark blue (see https://www.foobar2000.org/images/img/main.png) and I'm not sure if this matches Hot Tracked Element or not (you can't list/change colors manually in Windows 10 like you can in XP/7 and winecfg, and I don't have a test app to check Windows's color scheme on Windows 10). As a more subjective comment, I don't like how checked toggle buttons are bright blue #2979FF (eg. download and run Dn-FamiTracker, and look at "Follow-mode" in the toolbar). This doesn't match any color in winecfg I can find, and the closest winecfg color is #3296FA which is less saturated and more greenish. As another subjective comment, I dislike how clicking a dropdown list (eg. winecfg's Theme: dropdown) makes the [v] button turn blue until the mouse is released, but clicking a second time doesn't make it turn blue while the mouse is held. But this matches the (No Theme) behavior, so it may be working as intended. -- 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 5

[Bug 52476] New: QuickLOAD: wine 7 causes VB5 application to change input value by factor 10
by WineHQ Bugzilla 08 Nov '22

08 Nov '22

https://bugs.winehq.org/show_bug.cgi?id=52476 Bug ID: 52476 Summary: QuickLOAD: wine 7 causes VB5 application to change input value by factor 10 Product: Wine Version: 7.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: andreasnagel(a)gmx.net Distribution: --- Created attachment 71764 --> https://bugs.winehq.org/attachment.cgi?id=71764 Terminal output and partial screenshot QuickLOAD is a ballistics software. After entering all data and clicking the button to calculate results, an error message appears: "Warning: Input of effective cross section area of bore is essentially larger than caliber!" This bug renders the application unusable. As user 'jkfloris' from WineHQ forum confirms, Wine 6.14 was the last working version for QuickLOAD. https://forum.winehq.org/viewtopic.php?f=8&t=36143#p135918 OS: Linux Mint Cinnamon 20.3 (64-bit) Tested with latest winehq-devel 7.0.0~focal-2 from official WineHQ repo. A demo version can be downloaded here: https://quickload.software.informer.com/download/ Installation: - install winehq-devel + winetricks + ttf-mscorefonts-installer - install vb5run via winetricks - install demo software: wine qldemo.exe - during setup wizard provide install path without spaces (e.g. c:\quickload) - during installation, cancel search for QuickDESIGN ini-file - after setup finishes, run 'wine QLOADDEMO.EXE' from install path - dismiss security/welcome dialogs to reach main application window - select bullet/cartridge from combo boxes; see values of 'Cross sectional bore area' - click both 'Apply&Calc' buttons => error message as stated above - dismiss error message and compare values of 'Cross sectional bore area' => factor 10 now. -- 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 13

[Bug 50869] New: Regressions caused by new start.exe behaviour in Wine 6.5 (stdout redirect, killing inferior, wine start /unix)
by WineHQ Bugzilla 08 Nov '22

08 Nov '22

https://bugs.winehq.org/show_bug.cgi?id=50869 Bug ID: 50869 Summary: Regressions caused by new start.exe behaviour in Wine 6.5 (stdout redirect, killing inferior, wine start /unix) Product: Wine Version: 6.5 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: programs Assignee: wine-bugs(a)winehq.org Reporter: mail(a)robbertvanderhelm.nl Distribution: --- I noticed a few regressions and new weird behaviours after updating to Wine 6.5 with regards to launching applications now that everything gets launched through start.exe: 1. When launching Winelib applications all STDOUT output gets lost. I tested this with a simple C++ file compiled with wineg++ that tries to print some text using both `printf()` and `std::cout`. Printing to STDERR using `std::cerr` still works fine. 2. When spawning a Wine child process from another application, you can no longer kill that child process by raising SIGINT or SIGKILL for the pid of the child. In Wine 6.5 this now kills the start.exe process, but it leaves the inferior process running in the background. To reproduce this, run `wine notepad&` in `fish` (bash seems to kill the child process by itself), use `ps -aux | grep notepad` or `jobs` to find the pid of the process just named `notepad`, and then run `kill -SIGKINT <pid>` (or with SIGKILL). Even though the process launched using `wine notepad&` has exited, Notepad is still running in the background. 3. (duplicate of bug 50867, but I still wanted to mention it here for completeness' sake) Launching binaries with Wine from the GUI by clicking on them (using the bundled wine.desktop) no longer works. This uses `wine start /unix`, which was already reported to no longer work as of Wine 6.5 in the other issue because `ShellExecuteEx` cannot find the file. 4. And lastly, as discovered by @stefand, `wine https://google.com` now launches the regular system browser. This is probably not really a bug as much as a consequence of the start.exe change, but I just wanted to mention it. Please let me know if I should split this up into separate tickets. -- 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 16

[Bug 44202] New: undname.c fails to parse symbols with rvalue-reference semantics '&&'
by wine-bugs＠winehq.org 08 Nov '22

08 Nov '22

https://bugs.winehq.org/show_bug.cgi?id=44202 Bug ID: 44202 Summary: undname.c fails to parse symbols with rvalue-reference semantics '&&' Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: shulgaaa(a)gmail.com Distribution: --- For example, the symbol ??4QDnsDomainNameRecord@@QAEAAV0@$$QAV0@@Z should be de-mangled as: public: class QDnsDomainNameRecord & __thiscall QDnsDomainNameRecord::operator=(class QDnsDomainNameRecord &&) undname returns NULL -- 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 17

[Bug 50352] New: Maximum sockets per process is set very low
by WineHQ Bugzilla 08 Nov '22

08 Nov '22

https://bugs.winehq.org/show_bug.cgi?id=50352 Bug ID: 50352 Summary: Maximum sockets per process is set very low Product: Wine Version: 5.22 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winsock Assignee: wine-bugs(a)winehq.org Reporter: skreech(a)skree.ch Distribution: --- Created attachment 68942 --> https://bugs.winehq.org/attachment.cgi?id=68942 TWGS warning at startup Within wine-5.22/dlls/ws2_32/socket.c, the maximum number of sockets per process is set and used like so: > #define WS_MAX_SOCKETS_PER_PROCESS 128 /* reasonable guess */ and: > lpWSAData->iMaxSockets = WS_MAX_SOCKETS_PER_PROCESS; This became relevant when I ran the TradeWars 2002 game server (TWGS) under a maximum license allowing 100 simultaneous players. On startup, it logs a message warning that the OS's number of sockets per process is limited to 128, therefore no more than 63 players will be able to connect. This makes sense, since two sockets are required per player connection, and one SysOp connection is reserved. Changing WS_MAX_SOCKETS_PER_PROCESS to 1024 and recompiling WINE results in TWGS not experiencing this limit and not giving the warning. Also, I tested TWGS under ReactOS and did not experience limit nor warning. Peeking into their socket.c, I notice that their limit is set to 32767, or 0, depending: https://github.com/reactos/reactos/search?q=iMaxSockets It seems likely that WS_MAX_SOCKETS_PER_PROCESS should be set to 32767 here if any value is being set, given that the underlying OS should be the one imposing its own limits or lack of limit. -- 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