September 2012 - Wine-bugs - list.winehq.org

[Bug 24555] New: Fugawi - Maps do not draw properly, blank spaces (black) and colours incorrect
by wine-bugs＠winehq.org 03 Mar '13

03 Mar '13

http://bugs.winehq.org/show_bug.cgi?id=24555 Summary: Fugawi - Maps do not draw properly, blank spaces (black) and colours incorrect Product: Wine Version: 1.1.42 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: slush(a)vodus.fsnet.co.uk Created an attachment (id=30994) --> (http://bugs.winehq.org/attachment.cgi?id=30994) Screen shot of Fugawi OS maps in Wine See screen shot, maps do not draw properly, blank areas (black), some areas appear with incorrect colours, some bits drawn correctly. I have tried a number of different configurations, Win 98, win 2000, win XP, emulating a virtual desktop or not, vertex shader and pixel shader on or off. Nothing makes any difference. -- 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.

1 7

[Bug 15797] New: Install exe not working
by wine-bugs＠winehq.org 03 Mar '13

03 Mar '13

http://bugs.winehq.org/show_bug.cgi?id=15797 Summary: Install exe not working Product: WineHQ Apps Database Version: unspecified Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P3 Component: appdb-unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: asudak_tantill(a)hotmail.com After successfully downloading a game and it's installer through wine I then have a problem using the install.exe. If I double click, right click open with wine, or open it through Ubuntu's terminal all that happens is a bit of a pause, the blank wine desktop pops up and then quickly fades away. Their isn't any error message or anything similar that pops up just the virtual desktop comes up blank, then goes away in less then a couple seconds. -- 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.

1 13

[Bug 28093] New: GetCurrentPadding must slowly decrease (MacOS)
by wine-bugs＠winehq.org 02 Mar '13

02 Mar '13

http://bugs.winehq.org/show_bug.cgi?id=28093 Summary: GetCurrentPadding must slowly decrease (MacOS) Product: Wine Version: 1.3.25 Platform: x86 OS/Version: Mac OS X Status: UNCONFIRMED Severity: normal Priority: P2 Component: mmdevapi AssignedTo: wine-bugs(a)winehq.org ReportedBy: hoehle(a)users.sourceforge.net This issue lends itself to an interesting case in a (hypothetical) article about how to fully satisfy the static requirements of an API by the letter yet lose on the dynamic (or timing) aspects of it. Unsurprisingly, the dynamics are not well covered in MSDN. It struck me when analysing the log of my render test (attachment #35968 to bug #28047) that it plays ping pong with mmdevapi using two buffers: 20671/22050 and 1379/22050, then waits for almost half a second while GetCurrentPadding yields "buffer full" at 22050 = GetBufferSize = 500ms. 100ms later, it suddenly says "buffer almost empty". Follows another round of ping pong. Now imagine what happens after Start when an app prefills the buffer with a single GetBuffer(GetBufferSize): winecoreaudio will let it starve with "buffer full" until after that one buffer is returned from MacOS' audio queue, e.g. 500ms later. IOW an underrun and pause is guaranteed every half second. Perhaps that explains the 0.5s pauses in bug #28027. Native does not at all behave like this. I've mentioned its 10ms steps a few times. Even a much reduced rate, e.g. buffer duration / 3 would prevent the underruns in Wine. Unfortunately, fixing this requires a significant rewrite of the mmdevapi->CoreAudio bridge. Note that this 10ms talk applies only to shared mode. In exclusive mode, Initialize presumably sets the period the user asks for. Only EXCLUSIVE + EVENTCALLBACK is documented to play ping pong with exactly 2 buffers of GetBufferSize. -- 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.

1 9

[Bug 24669] New: Civilization V crashes on startup
by wine-bugs＠winehq.org 01 Mar '13

01 Mar '13

http://bugs.winehq.org/show_bug.cgi?id=24669 Summary: Civilization V crashes on startup Product: Wine Version: 1.3.4 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: shimi.chen(a)gmail.com Created an attachment (id=31185) --> (http://bugs.winehq.org/attachment.cgi?id=31185) Terminal output Game does not start. Crashes on startup. Ubuntu Lucid x64 ATI 4570hd mobility -- 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.

1 41

[Bug 26261] New: Start menu items are not displayed
by wine-bugs＠winehq.org 01 Mar '13

01 Mar '13

http://bugs.winehq.org/show_bug.cgi?id=26261 Summary: Start menu items are not displayed Product: Wine Version: 1.3.14 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: torgeriedel(a)gmx.de Created an attachment (id=33469) --> (http://bugs.winehq.org/attachment.cgi?id=33469) Screenshot showing the installation structure When installing Commandos - Behind Enemy Lines, I do not see any start menu entries in my Ubuntu (gnome) menu of wine. Checking the installation I see, that - in contrast to Axis & Allies - the start menu entries of Commandos - BEL were created in the users menu folder, not in the public one. See attached screenshot. I'm sure on windows both folders are merged and displayed together. In the screenshot there are four red squares: The first two are marking the "Public" folder (I think it is the common folder every user has access to), from which I see start menu entries in my Ubuntu (gnome) menu. The other two are marking the users own folder and the start menu folder of Commandos - BHL which I do not see -- 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.

1 7

[Bug 22227] New: Wrong grayed picture for disabled vb6 controls
by wine-bugs＠winehq.org 01 Mar '13

01 Mar '13

http://bugs.winehq.org/show_bug.cgi?id=22227 Summary: Wrong grayed picture for disabled vb6 controls Product: Wine Version: 1.1.41 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: trivial Priority: P2 Component: oleaut32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: gabmoa(a)yahoo.it The vb6 command button, option and radio controls have a "graphical mode" in which they can display also a picture. When the state of the control is disabled a wrong grayed picture is displayed (I think the problem may be in oleaut32). In the attached example two disabled command buttons have an icon and a bitmap picture respectively and the problem seems the same. -- 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.

1 12

[Bug 22551] New: unsupported TIFF with an alpha channel.
by wine-bugs＠winehq.org 01 Mar '13

01 Mar '13

http://bugs.winehq.org/show_bug.cgi?id=22551 Summary: unsupported TIFF with an alpha channel. Product: Wine Version: unspecified Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: windowscodecs AssignedTo: wine-bugs(a)winehq.org ReportedBy: jibanes(a)gmail.com Folks, I am trying to run Phase One's Capture One under wine 1.1.43 on x86-64, but TIFF with an alpha channel is currently unsupported in the windowscodecs component; as shown below: $ wine CaptureOne.exe fixme:wincodecs:tiff_get_decode_info unhandled RGB sample count 4 Thank you, Jerome -- 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.

1 16

[Bug 21856] New: VB6 modal form appears BEHIND parent (borderless) form when focus is on certain controls, making parent form unusable.
by wine-bugs＠winehq.org 01 Mar '13

01 Mar '13

http://bugs.winehq.org/show_bug.cgi?id=21856 Summary: VB6 modal form appears BEHIND parent (borderless) form when focus is on certain controls, making parent form unusable. Product: Wine Version: 1.1.38 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: razorwings18(a)hotmail.com Created an attachment (id=26460) --> (http://bugs.winehq.org/attachment.cgi?id=26460) VB6 project + binary to reproduce bug -- requires Microsoft Windows Common Controls 6.0 to run and compile In Visual Basic 6, calling FORMNAME.show 1 (open modal form) from a borderless form, will make the new MODAL form pop UNDER the parent form when the SHOW method is called while focus is on certain controls, but will correctly pop OVER the parent form when focus is on other controls. I.E.: In my BORDERLESS parent form (FORM1), I have a ListView and a CommandButton. If I give focus to the ListView and call FORM2.SHOW 1, FORM2 pops up OVER FORM1, which is correct. If I give focus to the CommandButton and call FORM2.SHOW 1, FORM2 pops UNDER FORM1. This will make FORM1 unusable until you move/minimize FORM1 to find FORM2 and close it. This problem is particularly annoying when FORM1 is an MDI Child, since FORM2 will not show in the task bar, and it will be difficult to find FORM2 to close it. My findings: - Seems to be related to Microsoft Windows Common Controls, or maybe even the presence of ListViews on the form in particular. - Setting FORM2's StartUpPosition property to something other than 0 (Manual) seems to fix it (need more testing though). - Forms with borders seem to work fine (did not test it enough) - Which focused control will trigger the bug and which won't varies. I've had the bug appear when focused over textboxes, commandbuttons, listviews, checkboxes, etc. See attached VB6 project (binary and instructions to reproduce bug included - requires Microsoft Windows Common Controls 6.0 to run and compile). -- 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.

1 10

[Bug 31769] New: windowsx.h macro HANDLE_WM_DISPLAYCHANGE is incorrect
by wine-bugs＠winehq.org 01 Mar '13

01 Mar '13

http://bugs.winehq.org/show_bug.cgi?id=31769 Bug #: 31769 Summary: windowsx.h macro HANDLE_WM_DISPLAYCHANGE is incorrect Product: Wine Version: 1.4.1 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: jc.gervais(a)videotron.ca Classification: Unclassified windowsx.h macro HANDLE_WM_DISPLAYCHANGE is erroneous: The CY parameter is not cracked correctly for the function pointer argument. This is because of a simple typo - the macro is defined thus: #define HANDLE_WM_DISPLAYCHANGE(hwnd, wParam, lParam, fn) ((fn)((hwnd), (UINT)(wParam), (UINT)LOWORD(lParam), (UINT)HIWORD(wParam)), 0L) but should be defined this way: #define HANDLE_WM_DISPLAYCHANGE(hwnd, wParam, lParam, fn) ((fn)((hwnd), (UINT)(wParam), (UINT)LOWORD(lParam), (UINT)HIWORD(lParam)), 0L) HIWORD( wParam ) is incorrectly used for the CY value when in fact it is encoded in HIWORD( lParam ) That is all. Thank you for your hard work, great persistence and attention to detail. -- 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.

1 7

[Bug 27941] New: Very slow rendering in sPlan7
by wine-bugs＠winehq.org 01 Mar '13

01 Mar '13

http://bugs.winehq.org/show_bug.cgi?id=27941 Summary: Very slow rendering in sPlan7 Product: Wine Version: 1.3.25 Platform: x86 URL: http://www.abacom-online.de/demos/splan70(demo).exe OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: b7.10110111(a)gmail.com Steps to reproduce: 1. Start sPlan 2. In the top-left combobox select TTL 3. See the elements cells being drawn for several seconds In Windows they are drawn instantly. The same is for main image widget. -- 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.

1 8