wine-bugs February 2020

wine-bugs@winehq.org

1 participants
7232 discussions

[Bug 34217] New: MS XPSEP GUI installer crashes if dotnet20 installed
by wine-bugs＠winehq.org 08 Jan '21

08 Jan '21

http://bugs.winehq.org/show_bug.cgi?id=34217 Bug #: 34217 Summary: MS XPSEP GUI installer crashes if dotnet20 installed Product: Wine Version: 1.7.0 Platform: x86-64 URL: http://download.microsoft.com/download/2/5/2/2526f55d- 32bc-410f-be18-164ba67ae07d/XPSEP%20XP%20and%20Server% 202003%2032%20bit.msi OS/Version: Linux Status: NEW Keywords: download, Installer Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: kennybobs(a)o2.co.uk Blocks: 32164, 32166, 32167, 32168 Classification: Unclassified Created attachment 45524 --> http://bugs.winehq.org/attachment.cgi?id=45524 Wine 1.7.0 console output The Microsoft XML Paper Specification Essentials Pack (XPSEP) GUI installer fails 100% of the time when dotnet20 is first installed in a clean WINEPREFIX. err:msi:ITERATE_Actions Execution halted, action L"EPUpdateInstallAction" returned 1627 err:msi:custom_get_thread_return Invalid Return Code 3 Affects Winetricks in multiple verbs. Run: 1. winetricks dotnet20 2. Install. -- 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 15

[Bug 19624] New: winspool.drv needs to properly handle local printer server config data queries (XPSEPSC update/installer)
by wine-bugs＠winehq.org 08 Jan '21

08 Jan '21

http://bugs.winehq.org/show_bug.cgi?id=19624 Summary: winspool.drv needs to properly handle local printer server config data queries (XPSEPSC update/installer) Product: Wine Version: 1.1.27 Platform: PC URL: http://go.microsoft.com/fwlink/?LinkId=96332 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: spooler AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, that component is a needed prerequisite for .NET 3.0 Framework SP1, 3.5, 3.5 SP1 Fortunately can be reproduced without all the .NET installer mess: clean WINEPREFIX, run the installer from link. Local printer server has no name associated with it (NULL), leading to later problem when querying for registry data. --- snip --- 0032:Call KERNEL32.CreateProcessA(00000000,0015a5e8 "C:\\windows\\system32\\spool\\prtprocs\\w32x86\\printfilterpipelinesvc.exe /RegServer C:\\3b6becc6d220eb7bdd60153c\\update\\",00000000,00000000,00000000,00000000,00000000,00000000,0033ba98,0033badc) ... 003b:Call winspool.drv.OpenPrinterW(00000000,0033f8a0,00000000) ret=0102ed15 003b:trace:winspool:OpenPrinterW ((null), 0x33f8a0, (nil)) ... 003b:trace:winspool:OpenPrinterW returning 1 with 0 and 0x1 003b:Ret winspool.drv.OpenPrinterW() retval=00000001 ret=0102ed15 003b:Call winspool.drv.GetPrinterDataW(00000001,01004ad8 L"DefaultSpoolDirectory",00000000,00000000,00000000,0033f8a8) ret=0102ed82 003b:trace:winspool:GetPrinterDataExW (0x1, L"PrinterDriverData", L"DefaultSpoolDirectory" (nil), (nil), 00000000, 0x33f8a8) 003b:Ret winspool.drv.GetPrinterDataW() retval=00000006 ret=0102ed82 ... 003b:Call KERNEL32.GetLastError() ret=01021138 003b:Ret KERNEL32.GetLastError() retval=00000000 ret=01021138 ... 003b:Call KERNEL32.MultiByteToWideChar(00000000,00000008,0033f718 "Unexpected return value.",00000100,0033f518,00000100) ret=0105ec7c 003b:Ret KERNEL32.MultiByteToWideChar() retval=00000100 ret=0105ec7c ... 003b:Call KERNEL32.RaiseException(e06d7363,00000001,00000003,0033f810) ret=0101e688 003b:trace:seh:raise_exception code=e06d7363 flags=1 addr=0x7b84303a ip=7b84303a tid=003b 003b:trace:seh:raise_exception info[0]=19930520 003b:trace:seh:raise_exception info[1]=0033f83c 003b:trace:seh:raise_exception info[2]=01086754 003b:trace:seh:raise_exception eax=7b82cb69 ebx=7b8d091c ecx=00000000 edx=0033f7fc esi=0033f7fc edi=0033f770 003b:trace:seh:raise_exception ebp=0033f758 esp=0033f6f4 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00000246 ... 003b:Call KERNEL32.OutputDebugStringA(01002aec "Invalid parameter passed to C runtime function.\n") ret=01022579 003b:Ret KERNEL32.OutputDebugStringA() retval=ffffffff ret=01022579 --- snip --- Regards -- 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 14

[Bug 48354] New: Some patches may require forcing a wineprefix update
by WineHQ Bugzilla 08 Jan '21

08 Jan '21

https://bugs.winehq.org/show_bug.cgi?id=48354 Bug ID: 48354 Summary: Some patches may require forcing a wineprefix update Product: Wine-Testbot Version: unspecified Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: unknown Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- The TestBot updates the wineprefixes when it updates its base Wine source from the daily Wine commits. The rest of the time it lets Wine deal with updating the wineprefix is necessary. Furthermore Wine only updates the wineprefix when wine.inf changes, which is the case for every Wine release. The problem is that the wineprefix should also be updated when a patchset adds a WINE_REGISTRY resource to an existing dll. Failing to do so may cause the patchset tests to fail because the wineprefix is out of date. See: https://www.winehq.org/pipermail/wine-devel/2019-December/156914.html Wineprefix updates are relatively slow compared to the execution time of most tests (about 30s vs. < 1s) so it would be good not to have to do that for every task. An alternative would be to force a wineprefix update when a task has failures and gets rerun as a result (pass an option to the relevant VM-side scripts). -- 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 45117] New: paf5.exe not working with wine 2.0 or 3.0 but works ok with wine 1.9
by wine-bugs＠winehq.org 07 Jan '21

07 Jan '21

https://bugs.winehq.org/show_bug.cgi?id=45117 Bug ID: 45117 Summary: paf5.exe not working with wine 2.0 or 3.0 but works ok with wine 1.9 Product: Wine Version: 3.0-rc1 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: hollywood188(a)live.com Distribution: --- paf5.exe works with wine 1.9 but with 2.0 and 3.0 rectangular boxes are shown instead of charactors I am using Knoppix 8.1 linux which had wine 2.0 and I upgraded to wine 3.0 but same problem. it worked fine with Knoppix 7.7.1 and wine 1.9?? -- 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 16227] New: Tooltips on mouse hover in EMS SQL Manager block the mouse click
by wine-bugs＠winehq.org 05 Jan '21

05 Jan '21

http://bugs.winehq.org/show_bug.cgi?id=16227 Summary: Tooltips on mouse hover in EMS SQL Manager block the mouse click Product: Wine Version: 1.1.9 Platform: PC-x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: P1 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: ksfreitas(a)gmail.com Created an attachment (id=17473) --> (http://bugs.winehq.org/attachment.cgi?id=17473) Screenshot of a tooltip bloocking the mouse click In EMS SQL Manager (Free and Full), the tooltips block the mouse click, having to resize to see all item without tooltip for click. The link for freeware software download: http://www.sqlmanager.net/en/products/postgresql/manager/download -- 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 13

[Bug 38966] New: force close after hitting install usb drivers on lg mobile support tool and when enter cell carrier
by wine-bugs＠winehq.org 04 Jan '21

04 Jan '21

https://bugs.winehq.org/show_bug.cgi?id=38966 Bug ID: 38966 Summary: force close after hitting install usb drivers on lg mobile support tool and when enter cell carrier Product: Wine Version: 1.7.37 Hardware: x86 OS: Mac OS X Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: catsetname(a)yahoo.com Created attachment 51910 --> https://bugs.winehq.org/attachment.cgi?id=51910 backtrace.txt after loading lg mobile support tool i hit install usb drivers, list of cell carriers pop to select once selected box comes up stating program needs to close and options to close or show details -- 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 4

[Bug 27502] New: app freezes when WM_KILLFOCUS creates modal dialog
by wine-bugs＠winehq.org 03 Jan '21

03 Jan '21

http://bugs.winehq.org/show_bug.cgi?id=27502 Summary: app freezes when WM_KILLFOCUS creates modal dialog Product: Wine Version: unspecified Platform: All OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: user32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: efrias(a)syncad.com Created an attachment (id=35159) --> (http://bugs.winehq.org/attachment.cgi?id=35159) simple example which produces the error When a program brings up a modal dialog box in response to a WM_KILLFOCUS message, the program will freeze. I've attached a simple test case, all boilerplate except for: case WM_KILLFOCUS: MessageBox(hWnd, _T("Killing Focus"), _T("Note"), MB_OK); in the main event loop. If you run the program and then give focus to another application, the messagebox will pop up and then the program will become unresponsive. What is happening is: - x11drv gets a FocusOut event and calls the event handler, which ends up SendMessage-ing a WM_KILLFOCUS to the program. - The programs's code creates a modal dialog like the MessageBox above, and enters the dialog's event loop, which winds up calling GetMessage which calls MsgWaitForMultipleObjectsEx to get more X11 events. - X11DRV_MsgWaitForMultipleObjectsEx executes this: if (data->current_event) mask = 0; /* don't process nested events */ where data->current_event is true since we're still handling the FocusOut event. Since we're not processing nested events, we'll never be able to process the usual events like keys or mouse events which could exit this nested event loop. This type of error occurs in a few places in our application, where a WM_KILLFOCUS message to an edit box triggers some input validation and displays an error on failure. This works correctly in the normal case, where the user tabs out or clicks on another control in the dialog box containing the edit control -- since everything stays in the same top-level window, there is no FocusOut event from X11 and the WM_KILLFOCUS is generated internally by wine in response to, say, a KeyEvent. I think these key or mouse events are just posted to the windows message queue, and the X11 event handler has already exited by the time the application gets around to processing the ensuing WM_KILLFOCUS. But in the case where focus is lost by clicking outside the dialog containing the edit control, the WM_KILLFOCUS is generated by the FocusOut handler which is still executing, and we lock up. I suspect this is related to bug 11595 "Notepad++ freezes if native application changes a file it has open (dogfood)". My guess is in that case, a FocusIn event triggers something like a WM_ACTIVATE, in which notepad++ notices a file is changed and displays a messagebox asking if you want to reload. Since wine is still processing the FocusIn event, the modal message loop's call to MsgWaitForMultipleObjectsEx will never process any useful events because it's a nested event. Our application's built-in text editor has this same problem. I don't understand the event handling code well enough to propose a solution. As a test, I allowed nested event processing and it solved the problem without introducing any obvious errors, but I'm sure that check was in there for a reason. It's probably better to keep the application code from being executed from inside the event handler, if that's possible. Note: this bug was also posted as a message to wine-devel here: http://www.winehq.org/pipermail/wine-devel/2011-June/090652.html -- 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 14

[Bug 32058] New: Guild Wars 2 launcher freezes/hangs (unable to launch game)
by wine-bugs＠winehq.org 03 Jan '21

03 Jan '21

http://bugs.winehq.org/show_bug.cgi?id=32058 Bug #: 32058 Summary: Guild Wars 2 launcher freezes/hangs (unable to launch game) Product: Wine Version: 1.5.15 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: x.egam.wodahs.x(a)gmail.com CC: julliard(a)winehq.org Classification: Unclassified Once I updated wine to version 1.5.15, the Guild Wars 2 launcher can no longer launch the game because it just freezes/hangs. This was not an issue in 1.5.14, and in order to run the game for now I'm using wine 1.5.14 compiled from source. In wine 1.5.14, the launcher is black (can't see UI at all, but it's still functional) unless using the -dx9single flag. Using -dx9single, the background is black instead of transparent but the UI inside is properly rendered. This information is important because, before submitting this bug report, I performed two separate git bisects between 1.5.14 and 1.5.15: one without any command-line parameters, and one using -dx9single. Technical details follow: ======================================================================= 1) git bisect for running the game without any parameters: In the last good commit (8dcbeff760115834656f3f1fc85922e3a9af14d0), the launcher is still black but it still works. You cannot see the UI but by blindly logging in, the game does launch. In the first bad commit (f12c1c6630f0bf842dde9af10da4ab188ff16e94), the behavior is different from the wine 1.5.15 release and the other commits tested: here, instead of locking up, the window just disappears. It's still there, but I guess it's fully transparent. Because this leaves us even more "blind", I considered this "bad" in the git bisect, yielding the following result: --- f12c1c6630f0bf842dde9af10da4ab188ff16e94 is the first bad commit commit f12c1c6630f0bf842dde9af10da4ab188ff16e94 Author: Alexandre Julliard <julliard(a)winehq.org> Date: Wed Sep 26 13:12:17 2012 +0200 winex11: Switch to an ARGB visual for layered windows with per-pixel alpha. :040000 040000 e9933c28f3e50c52d2cee37a43b06a2f5cb5a497 3870099a31a68a69cd7c022857794700c2343aa9 M dlls --- If, however, we consider f12c1c6630f0bf842dde9af10da4ab188ff16e94 "good" in the git bisect, we get: --- d8247efd5ecb8c4604624eb2bbf47e194ce59e7e is the first bad commit commit d8247efd5ecb8c4604624eb2bbf47e194ce59e7e Author: Alexandre Julliard <julliard(a)winehq.org> Date: Thu Sep 27 20:47:08 2012 +0200 winex11: Take the alpha channel into account to compute the region of layered windows. :040000 040000 3870099a31a68a69cd7c022857794700c2343aa9 d9ec62b63405f910db90b095145a7910cc124eef M dlls --- In this case, the launcher does indeed lock up in the first bad commit (d8247efd5ecb8c4604624eb2bbf47e194ce59e7e). 2) git bisect for running the game using -dx9single: Using the -dx9single flag, we seem to be able to get to a later commit before it stops working (but does not work in the 1.5.15 release). In the last good commit (dbff4f422c943a837f0098e921f831eb4a94ac11), everything seems to be fine (when using the -dx9single flag) and even the transparency seems to be working. However, in the first bad commit (6f3b097a203d9ca248732cb45eed462599ca3af1), things start to lock up. This yields the following git bisect result: --- 6f3b097a203d9ca248732cb45eed462599ca3af1 is the first bad commit commit 6f3b097a203d9ca248732cb45eed462599ca3af1 Author: Alexandre Julliard <julliard(a)winehq.org> Date: Wed Oct 3 00:09:01 2012 +0200 winex11: Fix a typo in the surface region computation with an alpha channel. :040000 040000 fa11ac3c80763b81911ba999d8302029d2c6d147 566c9c06b11f8785c870a1e09ec53d42e13d1524 M dlls --- -- 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 19

[Bug 38166] New: Heroes of Might and Magic 5 slowly on some maps.
by wine-bugs＠winehq.org 02 Jan '21

02 Jan '21

https://bugs.winehq.org/show_bug.cgi?id=38166 Bug ID: 38166 Summary: Heroes of Might and Magic 5 slowly on some maps. Product: Wine Version: 1.7.37 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: galdralag(a)bk.ru Distribution: --- On some maps especially when many green trees game works very slowly. This happens on all versions of nvidia driver AFTER 331.89. 331.89 it is last version when game works on maximum video settings. May be this is bug of nvidia driver (not wine) but I can't test this. I tested 2 videocards nvidia 760M and 650 ti. This can be reproduced on ArchLinux, Fedora, OpenSuse and Kubuntu. If you have problems with reproducing I can attach some maps where it can be reprocuced -- 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 48

[Bug 44243] New: Spire and Serum paints very slowly
by wine-bugs＠winehq.org 02 Jan '21

02 Jan '21

https://bugs.winehq.org/show_bug.cgi?id=44243 Bug ID: 44243 Summary: Spire and Serum paints very slowly Product: Wine Version: 3.0-rc3 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: bique.alexandre(a)gmail.com Distribution: --- Hi, The following programs take a lot of time to render the UI: https://www.reveal-sound.com/ https://www.xferrecords.com/products/serum A few versions before the UI was just black, and recently it started to paint correctly, so it must be that you have add new painting/rendering api recently. Yet the painting performance is really slow, so it would be great if you guys could have a look and optimize it a bit? Maybe it is an easy thing to do? Many thanks for your work guys! To reproduce it you can install a plugin host like reaper: https://www.reaper.fm/ and then install the vst plugins and try them with reaper. Regards, Alexandre -- 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 14

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 2020