wine-bugs February 2008

wine-bugs@winehq.org

1 participants
2919 discussions

[Bug 11523] New: wine error after switching to 0.9.55
by wine-bugs＠winehq.org 09 Feb '08

09 Feb '08

http://bugs.winehq.org/show_bug.cgi?id=11523 Summary: wine error after switching to 0.9.55 Product: Wine Version: 0.9.55. Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: emkay(a)gmx.de Created an attachment (id=10689) --> (http://bugs.winehq.org/attachment.cgi?id=10689) console error output When i try to start chemdraw 8/9 with wine 0.9.55 i get the attched errormsg. the weird thing is that alomst everything worked with 0.9.54. When i reinstalled 0.9.54 Chemdraw also refuses to load. How can i get the program to work again? Other apps like the games WoW and DoW:Dc are running fine with both versions. cu -- 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 6

[Bug 11528] New: Ubuntu 7.10 crash
by wine-bugs＠winehq.org 09 Feb '08

09 Feb '08

http://bugs.winehq.org/show_bug.cgi?id=11528 Summary: Ubuntu 7.10 crash Product: Wine Version: unspecified Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: critical Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: bobheaps(a)mountaincable.net I recently upgraded from ubuntu 7.04 to ubuntu 7.10. I used wine with several (irfanview, A9CAD, etc)windows prtograms quite sucessfully with 7.04. Under the upgrade 7.10 the whole system locks up and i have to completely restart. I have tried removing and re-installing wine as well as the effected windows programs to no avail. What can I try next? -- 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 11524] New: Winecfg dialog is too large
by wine-bugs＠winehq.org 09 Feb '08

09 Feb '08

http://bugs.winehq.org/show_bug.cgi?id=11524 Summary: Winecfg dialog is too large Product: Wine Version: 0.9.54. Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: tools AssignedTo: wine-bugs(a)winehq.org ReportedBy: decocq(a)live.com All Windows dialogs should by design fit on a 640x480 VGA screen. When you configure Wine to emulate a virtual desktop, the size is 640x480 by default and this cuts off the dialog so you can't Ok/Cancel and reach all the settings. Also on Mobile devices/UMPC's this is a problem. I realize even MS is not following this rule strictly anymore (Internet Explorer settings dialog is also a bit to big) but Wine should set a good example. -- 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 3

[Bug 4056] winecfg is unusable with the default virtual desktop size
by wine-bugs＠winehq.org 09 Feb '08

09 Feb '08

http://bugs.winehq.org/show_bug.cgi?id=4056 Vitaliy Margolen <vitaliy(a)kievinfo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |decocq(a)live.com --- Comment #2 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2008-02-09 12:07:56 --- *** Bug 11524 has been marked as a duplicate of this bug. *** -- 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 0

[Bug 6033] Fallout 2 : In game mouse pointer is unusable
by wine-bugs＠winehq.org 09 Feb '08

09 Feb '08

http://bugs.winehq.org/show_bug.cgi?id=6033 jargonautti(a)hotmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jargonautti(a)hotmail.com --- Comment #29 from jargonautti(a)hotmail.com 2008-02-09 11:50:09 --- I too have this problem, however: it only occurs in truecolor (24 bpp) mode. If I change the X-server configuration to 16 bpp ("DefaultDepth 16" in the "Screen" section of XF86Config), the game runs just fine. I couldn't test 8 bpp because Gnome wouldn't start then :(. Correlating this with the fact that Wine spits out error messages about being unable to switch to 8 bpp mode when the game is started, it seems likely that this is a problem with paletted and non-paletted color modes colliding. Pity that changing X-server's color depth at runtime is impossible, or so all the docs I've found claim; otherwise this would be a simple thing to fix :(. Oh, and my Wine is version 0.9.54. -- 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 0

[Bug 7229] WoW locks up
by wine-bugs＠winehq.org 09 Feb '08

09 Feb '08

http://bugs.winehq.org/show_bug.cgi?id=7229 Peter Kovacs <legine(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |legine(a)gmx.net --- Comment #31 from Peter Kovacs <legine(a)gmx.net> 2008-02-09 09:26:04 --- Hello, I have the problem for month now. Read all postings. I checked the Schedtool and saw that you can swap the sheduler in the Kernel for better results: > SCHED_ISO [ patch needed ] SCHED_ISO was designed to give users a > SCHED_RR-similar class. To quote Con Kolivas: "This is a non-expiring scheduler > policy designed to guarantee a timeslice within a reasonable latency while > preventing starvation. Good for gaming, video at the limits of hardware, video > capture etc." Maybe this can solve the Problem we face within the game. I did not test it because the default kernel need to be patched and ck Kernel are atm discontinued because of differences between Linus Torvalis / Ingo Molnar and Con Kolivas. (Which is imho a shame for all of us) I will see to it if I find the time maybe someone else wants to test this Idea if it solves the issue. Cheers Peter Patch can be found at: http://members.optusnet.com.au/ckolivas/kernel/ Schedtool manpage for more Info on how to use: http://linux.die.net/man/8/schedtool -- 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 0

[Bug 3498] Civilization 3: Fonts missplaced
by wine-bugs＠winehq.org 09 Feb '08

09 Feb '08

http://bugs.winehq.org/show_bug.cgi?id=3498 David <cymerio(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cymerio(a)gmail.com --- Comment #6 from David <cymerio(a)gmail.com> 2008-02-09 09:06:33 --- Some other apps are affected by "CreateScalableFontResourceA", like translation apps or music apps, like Cakewalk Pro Audio 9 (they need the fonts to display the staff symbols). These apps are useless without their fonts. The solution would be to properly implement CreateScalableFontResourceA. As I'm new to bugzilla, I don't know if it's possible to vote for implementing a stub. Also, there are more bugs related to CreateScalableFontResourceA. Somebody should mark them as duplicates. -- 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 0

[Bug 8357] EverQuest models not shown
by wine-bugs＠winehq.org 09 Feb '08

09 Feb '08

http://bugs.winehq.org/show_bug.cgi?id=8357 --- Comment #9 from Julio Fernandez <ucldb(a)wanadoo.es> 2008-02-09 08:49:14 --- FIX FOR THE BUG I finally managed to get the models show properly (tested at 0.9.54) I will try to send the info to the devs when I find out how to get this information to them: ===================== These are my findings: The main executable is eqgame.exe it typically accesses D3D through a custom dll eqgraphicsdx9 which interacts with D3D itself or through d3dx9_30.dll Using channels and adding some extra messages into certain source files I got to track a possible reason: The game was declaring vertex lists with a vertex of type '0xfe' and +189 offset Sadly, I could not get any extra information tracking just from source code, so I had to run the game under Windows on a computer and using windbg to debug it, while running the same time on another computer the game under Debian etch using winedbg to debug, and so tracing both programs in assambler (I burnt my eyelashes there!), the fact that I could have d3d dll symbols availables on the windows box was the key here, I really missed winedbg to be able to read pdb files :( After many hours I was able to track down the reason, and to my surprise it seems its not wine's fault (for the most of it) The 'troublesome' vertex are apparently Blended ones on a Mesh setup. When d3dx9_30 calls ConvertToIndexedBlendedMesh, it calls GetDeviceInfo to get the device capabilites, in the end wine returns the capabilites through IWineD3DImpl_GetDeviceCaps in wine/dlls/wined3d/directx.c Here comes the fun thing, the attribute MaxVertexBlendMatrices in D3DCAPS9, from (MSDN): "Maximum number of matrices that this device can apply when performing multimatrix vertex blending. For a given physical device, this capability may vary across Direct3D devices depending on the parameters supplied to IDirect3D9::CreateDevice." At the moment is set in wine as *pCaps->MaxVertexBlendMatrices = GL_LIMITS(blends) which results in a value of 0 (at least in my Linux computer/build), while under Windows (XPSP2 DX9c) results in a value of 4 d3dx9_30 has a check right after capabilites are returned comparing that value with 2, resulting in different code paths for the remaining of MaxVertexBlendMatrices function, when the value was 0 both Linux and Windows (hacking the returned value to be 0) make those odd '0xfe' vertexes to be inserted (in Linux that makes the models to not be shown, in Windows it makes eqgame.exe to crash) I proceeded then to try to 'hack' wine to return a value of 4, adding the line pCaps->MaxVertexBlendMatrices=0x4; Before returning from function IDirect3DDevice9Impl_GetDeviceCaps(LPDIRECT3DDEVICE9 iface, D3DCAPS9* pCaps) at wine/dlls/d3d9/directx.c The result: MaxVertexBlendMatrices runs the same path as Windows does, the odd '0xfe' vertexes are not generated and the models work are now shown as expected My apologies for the long post, but I thought it would be handy to tell the full story to justify calling your atention on this - d3dx9_30 ConvertToIndexedBlendedMesh shows an 'odd' behavior when MaxVertexBlendMatrices capabilites in D3DCAPS9 is 0 - Is wine reporting the right value for MaxVertexBlendMatrices ??? As it seems the game works flawlesly in wine when it's hacked to be 4 (I don't know if this 'hack' would affect other programs in any other way ===================== So while we wait for a dev answer about this the 'fix' that replaces the prior 'HOWTO' is as follows: Add this line: pCaps->MaxVertexBlendMatrices=0x4; In file: (your wine source directory)/dlls/d3d9/directx.c At function: IDirect3DDevice9Impl_GetDeviceCaps(LPDIRECT3DDEVICE9 iface, D3DCAPS9* pCaps) Before returning (return hrc;), line 176 (as of 0.9.55) Build wine as usual and happy Everquesting (Side note, for me it works flawlesly with all graphic settings BUT 'shadows' (crashes the game), I've seen some very minor artifacts when 'advanced lighing' is on too. I haven't played for too long, I wanted to post this as soon as possible ;) will see next days now that Everquest should be FULL playable. -- 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 0

[Bug 881] Mouse cursor not blanked
by wine-bugs＠winehq.org 09 Feb '08

09 Feb '08

http://bugs.winehq.org/show_bug.cgi?id=881 Dan Kegel <dank(a)kegel.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |1.0.0 --- Comment #53 from Dan Kegel <dank(a)kegel.com> 2008-02-09 08:16:35 --- Affects several popular apps, nice analysis, candidate patch -> nominating for 1.0 -- 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 0

[Bug 881] Mouse cursor not blanked
by wine-bugs＠winehq.org 09 Feb '08

09 Feb '08

http://bugs.winehq.org/show_bug.cgi?id=881 --- Comment #52 from Eli <sharparrow1(a)yahoo.com> 2008-02-09 07:29:25 --- Okay, so I actually tried looking at this closely, and it's actually a pretty tricky issue (although probably easy to solve for anyone who has touched the relevant code before). The issue is that whatever the initial cursor happens to be, that initial cursor needs to be communicated to the driver. The x11 driver's initial cursor is a cursor which does not correspond to *any* of the builtin cursors in wine's user32. Therefore, no matter what the default is, winex11 needs to be told sometime after initialization what the currect cursor is. Currently, winex11 doesn't get any information until some application sets its cursor; since 99% of applications do set their cursor to something non-null soon after window creation, the issue isn't normally visible. Therefore, to get this correct in general, either every thread needs to tell the driver its default cursor on creation, or both user32 and the driver need to have the same default cursor. I'm having a bit of trouble figuring out what would be the best approach, though. gbrammer's patch works around this issue by forcing SetCursor(NULL) to always communicate with x11drv, so despite the fact that wine thinks that there is no cursor, the SetCursor call still does the right thing. Side notes: IDC_WAIT would be the Windows-compatible default cursor; if we're going to go to the trouble of fixing this, we should probably match the Windows default. The default winex11 arrow cursor on my computer is the gnome arrow cursor; it's a bit different from the wine arrow cursor in that it has a shadow and the stem is a bit shorter. It would be nice if Wine used the same arrow, but that's a separate issue. -- 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 0

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 2008