February 2008 - Wine-Devel - list.winehq.org

Re: Is wine reporting the right value for MaxVertexBlendMatrices ?

by Vitaliy Margolen

Julio Fernandez wrote: > Hi, I don't know if this is the right place to post this, but sorry if > not, and I'd like to be pointed to the right one Please one message is enough! And please do not cross post! The bugzilla and/or wine-devel is enough. What you failed to specify is your video card and driver version you are using. Otherwise thanks for analysis this indeed should let someone who knows the area fix it or have a better explanation to what is going on. Vitaliy

Feb. 9, 2008

Re: No win95 tests after commit "tests: Add a helper routine to wait for a child process and propagate its result correctly."

by Steven Edwards

On Feb 9, 2008 9:24 AM, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > Hi, > > This commit: 05c7174909e975fc7d0ebf9a59bb07160c09d66d introduces a new helper > script but uses InterlockedExchangeAdd that is not available on win95. > > This means that none of the tests run on win95 anymore. Can we just implement our own version inline? -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

Feb. 9, 2008

gecko download not robust?

by Dan Kegel

Hmm. gecko download hung for me once. I saw fixme:urlmon:ProtocolStream_Read Read failed: 800c0008 in the log, which makes me wonder if our download code doesn't handle transient network errors well. Time to get rid of the download, and just bundle gecko outright, I say...

Feb. 9, 2008

Is wine reporting the right value for MaxVertexBlendMatrices ?

by Julio Fernandez

Hi, I don't know if this is the right place to post this, but sorry if not, and I'd like to be pointed to the right one I have been working last weeks on making the game Everquest to work under wine, since 0.9.49 it was working flawlesly, but most models were not shown properly. This corresponds with bug http://bugs.winehq.org/show_bug.cgi?id=8357 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

Feb. 9, 2008

Re: msvcrt: Fix EOF behavior on read from pipe

by Damjan Jovanovic

On Feb 9, 2008 5:27 PM, Dan Kegel <dank(a)kegel.com> wrote: > On Feb 9, 2008 2:15 AM, Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: > > > Try my patch, it should help that case. > > > > It only helps if I change > > + if (type != FILE_TYPE_PIPE) { > > to > > + if (type != FILE_TYPE_PIPE && type != FILE_TYPE_CHAR) { > > That makes me as uneasy as I bet it does you; switching to > detecting EOF by noticing zero byte reads as you suggested sounds safer. > Try the attached patch and let me know what you think. It works with jdb, and all msvcrt tests still pass. I was trying the same thing a while back, but some tests always kept failing, so well done! > > Well, if the MSDN is correct about ReadFile() returning only when the > > requested number of bytes is read unless an error occurs (it's a big > > if :-), then it would be an NTDLL NtReadFile() issue where pread() > > returns too soon due to a signal. But I haven't been able to get a > > signal to interrupt pread() in my tests, maybe wine handles signals. > > Wine's ReadFile already tries to handle interrupted reads, but it looks > offhand like it only handles the case where the read is interrupted > before getting any bytes. > Wine uses signals internally, maybe a stress test that tickled > that part of wine heavily while doing lots of extremely large ReadFile() calls > would cause a partial read. But it's possible that no apps would care, > especially if we get rid of the "short read = EOF" bug you pointed out > in msvcrt. > - Dan > Thank you Damjan

Feb. 9, 2008

Re: No win95 tests after commit "tests: Add a helper routine to wait for a child process and propagate its result correctly."

by Paul Vriens

Paul Vriens wrote: > Hi, > > This commit: 05c7174909e975fc7d0ebf9a59bb07160c09d66d introduces a new > helper script but uses InterlockedExchangeAdd that is not available on > win95. > > This means that none of the tests run on win95 anymore. > Hi, Another side effect of that change is that the kernel32/toolhelp tests shows a high number of failures for win98 (139): http://test.winehq.org/data/200802091000/98_W98SE/kernel32:toolhelp.txt compared to before (12): http://test.winehq.org/data/200802062039/98_W98SE/kernel32:toolhelp.txt -- Cheers, Paul.

Feb. 9, 2008

Is wine reporting the right value for MaxVertexBlendMatrices ?

by Julio Fernandez

Hi, I don't know if this is the right place to post this, but sorry if not, and I'd like to be pointed to the right one I have been working last weeks on making the game Everquest to work under wine, since 0.9.49 it was working flawlesly, but most models were not shown properly. This corresponds with bug http://bugs.winehq.org/show_bug.cgi?id=8357. 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 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 at the same time on another computer the game under Debian etch using winedbg to debug, and so tracing both programs in assembler (I've 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 was able to read pdb files :( After many hours I was able to track down the reason, and to my surprise it seems it's 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, for 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 not to 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 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

Feb. 9, 2008

Re: msvcrt: Fix EOF behavior on read from pipe

by Dan Kegel

On Feb 9, 2008 2:15 AM, Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: > > Try my patch, it should help that case. > > It only helps if I change > + if (type != FILE_TYPE_PIPE) { > to > + if (type != FILE_TYPE_PIPE && type != FILE_TYPE_CHAR) { That makes me as uneasy as I bet it does you; switching to detecting EOF by noticing zero byte reads as you suggested sounds safer. Try the attached patch and let me know what you think. > Well, if the MSDN is correct about ReadFile() returning only when the > requested number of bytes is read unless an error occurs (it's a big > if :-), then it would be an NTDLL NtReadFile() issue where pread() > returns too soon due to a signal. But I haven't been able to get a > signal to interrupt pread() in my tests, maybe wine handles signals. Wine's ReadFile already tries to handle interrupted reads, but it looks offhand like it only handles the case where the read is interrupted before getting any bytes. Wine uses signals internally, maybe a stress test that tickled that part of wine heavily while doing lots of extremely large ReadFile() calls would cause a partial read. But it's possible that no apps would care, especially if we get rid of the "short read = EOF" bug you pointed out in msvcrt. - Dan

Feb. 9, 2008

Re: wine keyboard fix

by Stefan Dösinger

Am Samstag, 9. Februar 2008 04:52:23 schrieb dhliu: > Some input methods can send a much longer string. The original size is > too small. Please consider enlarging it. > Thanks. You should send a patch generated via git to wine-patches. If you do not know how to do this, plese consider filing a bugreport about this issue, together with an example for "Some input methods" which can trigger the issue.

Feb. 9, 2008

Is wine reporting the right value for MaxVertexBlendMatrices ?

by Julio Fernandez

Hi, I don't know if this is the right place to post this, but sorry if not, and I'd like to be pointed to the right one I have been working last weeks on making the game Everquest to work under wine, since 0.9.49 it was working flawlesly, but most models were not shown properly. This corresponds with bug http://bugs.winehq.org/show_bug.cgi?id=8357. 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

Feb. 9, 2008