December 2013 - Wine-Bugs - list.winehq.org

[Bug 19320] New: space in-between of two different links gets removed in "description" field if it not part of any link
by wine-bugs＠winehq.org Dec. 26, 2013

Dec. 26, 2013

http://bugs.winehq.org/show_bug.cgi?id=19320 Summary: space in-between of two different links gets removed in "description" field if it not part of any link Product: WineHQ Apps Database Version: unspecified Platform: PC URL: http://appdb.winehq.org/objectManager.php?sClass=appli cation OS/Version: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: appdb-unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: virtuousfox(a)gmail.com i was trying to edit application's "description" field and then i have commited changes space in-between of two separate links got removed see http://appdb.winehq.org/objectManager.php?sClass=application&iId=4640 -- 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 34282] New: AppDB App for Wine
by wine-bugs＠winehq.org Dec. 26, 2013

Dec. 26, 2013

http://bugs.winehq.org/show_bug.cgi?id=34282 Bug #: 34282 Summary: AppDB App for Wine Product: WineHQ Apps Database Version: unspecified Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: appdb-unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: shatteredlites(a)gmail.com Classification: Unclassified Ok It just came to mind that there should be a app for wine that keeps track of the AppDB and its games and this is my Idea and what it could do... When wine is running you will be asked whether or not to send info as in- game logs and debug info and system info without compromising privacy that is. and while this app runs it would do a search in AppDB on what game you're using and what settings are recommended for it as well as patches for it and so on. The info that is being sent while ingame can be monitored by the game maintainer in Appdb to check for bugs or regressions. what do yall think and how would I go about asking for an enhancement like this? EXTRA INFO Requirements To Work -AppDB Game Needs A Maintainer -AppDB Games Need Constant Watch To Keep Track Of Regressions & Bugs Pros & Cons Pro- Games Will Automatically Apply Fixes When Needed Pro- Bugs Could Automatically Be Sent To Bugzilla With Info Already In Report Pro- Less Hassle For Devs & Users Con- More Dedicated Devs Needed To Keep DB In Order Con- A New Project That Will Take Time Con- WineHQ Will Go Through Changes In Order To Work With Program -- 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 2

[Bug 34382] New: Nerf Arena Blast Demo link doesn't work
by wine-bugs＠winehq.org Dec. 26, 2013

Dec. 26, 2013

http://bugs.winehq.org/show_bug.cgi?id=34382 Bug #: 34382 Summary: Nerf Arena Blast Demo link doesn't work Product: WineHQ Apps Database Version: unspecified Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: appdb-unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: maikwagner(a)yahoo.com Classification: Unclassified AppDB entry at: http://appdb.winehq.org/objectManager.php?sClass=version&iId=15654 contains an invalid link to download the demo. This is amore recent one: http://www.fileplanet.com/29188/download/Nerf-Arena-v1.1-Demo -- 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 2

[Bug 6941] Dune 2000 freezes when pressing LAN button
by wine-bugs＠winehq.org Dec. 26, 2013

Dec. 26, 2013

http://bugs.winehq.org/show_bug.cgi?id=6941 --- Comment #14 from Bruno Jesus <00cpxxx(a)gmail.com> --- Still in wine 1.7.9. It blocks in a recv call in an IPX socket, I'll try to find out what is happening when I have 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 0

[Bug 23940] New: SetWindowPos does not work for other wine processes
by wine-bugs＠winehq.org Dec. 25, 2013

Dec. 25, 2013

http://bugs.winehq.org/show_bug.cgi?id=23940 Summary: SetWindowPos does not work for other wine processes Product: Wine Version: unspecified Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: user32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: jUrner(a)arcor.de resizing windows belonging to other (wine) processes does not work. user32.dll SetWindowPos() always returns 0. somewhere down in winpos.c set_window_pos() returns FALSE wine 1.2 -- 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 19

[Bug 5402] Canon PhotoStitch 3.1.13 crashes on startup
by wine-bugs＠winehq.org Dec. 25, 2013

Dec. 25, 2013

http://bugs.winehq.org/show_bug.cgi?id=5402 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|patch | URL|http://www.wolflair.com/rig |http://www.minisiteg.narod. |htframe.php?context=army_bu |ru/Canon/PhotoStitch311332. |ilder&page=downloads |rar Summary|Multiple apps crash (e.g. |Canon PhotoStitch 3.1.13 |PhotoStitch 3.1, Army |crashes on startup |Builder, Web Builder....) | --- Comment #37 from Anastasius Focht <focht(a)gmx.net> --- Hello folks, still present. --- snip --- ... 0009:Ret user32.CreateWindowExA() retval=00010076 ret=5f40c211 0009:Call user32.GetActiveWindow() ret=5f4013c8 0009:Ret user32.GetActiveWindow() retval=00000000 ret=5f4013c8 0009:trace:seh:raise_exception code=c0000005 flags=0 addr=0x42e81e ip=0042e81e tid=0009 0009:trace:seh:raise_exception info[0]=00000000 0009:trace:seh:raise_exception info[1]=00000138 0009:trace:seh:raise_exception eax=00000000 ebx=0033e24c ecx=0033e20c edx=00000386 esi=0019e6d0 edi=0019e3f8 0009:trace:seh:raise_exception ebp=00000000 esp=0033e1f4 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010246 --- snip --- ArmyBuilder 3.1 (http://www.wolflair.com/download/ab/ab31c_install.exe) also referenced in this bug works fine which indicates it suffered from bug 19052 'WYSIWYG Web Builder 5.5.x' (http://3dwebdesign.org/download/webbuilder5.zip) also works fine indicating it suffered from bug 19052 Refining summary and replacing download with old version of PhotoStitch 3.1.13 $ sha1sum PhotoStitch311332.rar 02856a422d6d57eb2c6694463f422852a7c653e5 PhotoStitch311332.rar $ du -sh PhotoStitch311332.rar 4.0M PhotoStitch311332.rar $ wine --version wine-1.7.9-158-g33fa552 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 0

[Bug 2082] DirectDraw games only showing black screen
by wine-bugs＠winehq.org Dec. 24, 2013

Dec. 24, 2013

http://bugs.winehq.org/show_bug.cgi?id=2082 --- Comment #128 from Vincent Povirk <madewokherd(a)gmail.com> --- > The ultimate result is that dialog D obscures window A. I haven't > investigated why dialog D is all black as opposed to looking like a typical > user32 dialog window with controls. This is because (on Windows, at least before compositing was introduced and before Windows 8), although ddraw will ignore clipping and draw over other windows, it does not prevent those other windows from also drawing. To prevent ddraw from fighting user32 and causing flicker, WA intentionally prevents the dialog from drawing (on older versions that prevention was flawed and you'd sometimes get flicker anyway, but they may have fixed that). It happens that WA does not need to do any gdi drawing at all, but other programs use clipping to mix ddraw with gdi, and there may be a few that do not use clipping but instead manually synchronize ddraw and gdi drawing (diablo maybe?). -- 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 0

[Bug 2082] DirectDraw games only showing black screen
by wine-bugs＠winehq.org Dec. 24, 2013

Dec. 24, 2013

http://bugs.winehq.org/show_bug.cgi?id=2082 Stefan Dösinger <stefan(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |stefan(a)codeweavers.com --- Comment #127 from Stefan Dösinger <stefan(a)codeweavers.com> --- d3d8/9 drawing to the desktop window is not valid, unless D3DDEVTYPE_NULLREF is used. Which is what some applications do, and we don't implement NULLREF and just treat it as HAL. I believe we have tests that demonstrate that opengl rendering on the desktop window is not valid on Windows. I might be mistaken though, I haven't checked the code. I'm not entirely sure about the ddraw behavior. This needs some additional tests for clippers. Specifically we'll have to check what clippers do in fullscreen mode, and if clippers affect primary surface locks (and not just blits). The current behavior is to render to the clipper window if a clipper is assigned to the primary, and it has a clip window and not a clip list. What may be the correct behavior: *) Always render to the device window, which is NULL by default unless the application explicitly sets it with SetCoopLevel(DDSCL_SETDEVICEWINDOW) or asks ddraw to create one with SetCoopLevel(DDSCL_CREATEDEVICEWINDOW). I think SetCoopLevel(window, FULLSCREEN | EXCLUSIVE) just sets the focus window, not the device window. *) Never render to the clipper window. *) Use the clipper window only in surface::blt to limit the written area. -- 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 0

[Bug 2082] DirectDraw games only showing black screen
by wine-bugs＠winehq.org Dec. 23, 2013

Dec. 23, 2013

http://bugs.winehq.org/show_bug.cgi?id=2082 --- Comment #126 from Ken Thomases <ken(a)codeweavers.com> --- Created attachment 46977 --> http://bugs.winehq.org/attachment.cgi?id=46977 Use desktop window for fullscreen ddraw, with support in Mac driver This is a hack that a) makes ddraw target the desktop window when DDSCL_FULLSCREEN is specified and doesn't treat it differently from other windows; and b) adds support in the Mac driver for doing OpenGL on the desktop window. This allows Worms Armageddon to work with the Mac driver without its Wine-specific tweaks. It's sort of a proof of concept of the plan I mentioned in my last reply. NOTE: This will not work with the X11 driver because it doesn't have support for doing OpenGL on the desktop window. (The X11 driver actually has code specifically to reject attempts to do so, as did the Mac driver before this hack.) The ddraw hacks will actually break the ability of the X11 driver to run WA when its tweaks are active. I also don't expect this to work with DirectDrawRenderer=gdi. -- 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 0

[Bug 2082] DirectDraw games only showing black screen
by wine-bugs＠winehq.org Dec. 23, 2013

Dec. 23, 2013

http://bugs.winehq.org/show_bug.cgi?id=2082 Ken Thomases <ken(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ken(a)codeweavers.com --- Comment #125 from Ken Thomases <ken(a)codeweavers.com> --- I've been looking into this bug as it affects Worms Armageddon. That game has built-in Wine-specific tweaks to work around the problem, but they don't work with the Mac driver because the Mac driver doesn't support a virtual desktop window. For testing purposes, I'm using the X11 driver with WA's tweaks disabled. I'm going to summarize what I have found (which has also been demonstrated by some of the test cases): * WA creates window A. * WA creates a dialog window D, which is owned by window A. This has sometimes been described as a child window but it's not. It's a top-level window. Being owned by window A means that it is kept in front of window A. * The dialog D has various controls, including buttons, etc. * WA calls IDirectDraw::SetCooperativeLevel(window A, DDSCL_EXCLUSIVE | DDSCL_FULLSCREEN). The presence of DDSCL_FULLSCREEN should mean that it draws directly to the screen, bypassing all normal (GDI) drawing of other windows. So, even though dialog D is in front of window A, the drawing to window A should appear on screen. * Wine's ddraw calls wined3d_device_setup_fullscreen_window() to set window A up as a full-screen window. This attempts to order window A to the front of all windows by calling SetWindowPos(window A, HWND_TOPMOST, ...). However, because dialog D is owned by window A, user32 keeps D in front. The ultimate result is that dialog D obscures window A. I haven't investigated why dialog D is all black as opposed to looking like a typical user32 dialog window with controls. I have confirmed this with a gross hack. In dlls/user32/dialog.c:DIALOG_CreateIndirect(), I have modified the two calls to CreateWindowEx[AW]() to pass NULL for the owner. This means that dialog D is not owned by window A and window A can be moved in front of it. The result is that you can see the rendering. However, clicks on the window are ignored. That's because window A isn't prepared to respond to the clicks. The dialog D is supposed to receive those clicks. I think that Stefan was on the right path. I think that, when ddraw/wined3d goes to set up window A for full-screen, it should not attempt to change the Win32 window. I think it needs to work with the user driver to set up a full-screen OpenGL surface that's outside of the Win32 window hierarchy. This surface would have to avoid interfering with mouse events. Those should still be delivered to whatever Win32 window is under the cursor. It may be that targeting the desktop window is the most appropriate way for ddraw/wined3d to communicate the need to draw to the full screen to the user driver, although Stefan mentioned that that has its own problems. Given that ddraw (and d3d?) has a need to bypass the normal windowing and graphics, I think it makes sense for it to communicate directly with the user driver. -- 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 0