wine-devel February 2008

wine-devel@winehq.org

141 participants
325 discussions

Is wine reporting the right value for MaxVertexBlendMatrices ?
by Julio Fernandez 09 Feb '08

09 Feb '08

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

3 3

No win95 tests after commit "tests: Add a helper routine to wait for a child process and propagate its result correctly."
by Paul Vriens 09 Feb '08

09 Feb '08

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. -- Cheers, Paul.

2 2

Is wine reporting the right value for MaxVertexBlendMatrices ?
by Julio Fernandez 09 Feb '08

09 Feb '08

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

1 0

re: msvcrt: Fix EOF behavior on read from pipe
by Dan Kegel 09 Feb '08

09 Feb '08

Damjan wrote > The problem is more general: consoles *also* break on short reads > (Java 1.4.1's gdb takes 1 command then quits because it thinks it's > the end of file) Try my patch, it should help that case. > I'm sure short read != end of file for ordinary > files either, especially in *nix where read() can easily be > interrupted by a signal. If you can come up with an example of a real app or even a test case that is currently broken, I'll gladly try to fix it. - Dan

2 3

Is wine reporting the right value for MaxVertexBlendMatrices ?
by Julio Fernandez 09 Feb '08

09 Feb '08

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

1 0

Re: wine keyboard fix
by Stefan Dösinger 09 Feb '08

09 Feb '08

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.

1 0

Is wine reporting the right value for MaxVertexBlendMatrices?
by Julio Fernandez 09 Feb '08

09 Feb '08

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' vertexes are apparently blended ones in mesh declarations. 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 the 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

1 0

Code quality (was Re: comctl32: Fix invalid syntax)
by Bang Jun-young 09 Feb '08

09 Feb '08

On 2/7/08, Michael Stefaniuc <mstefani(a)redhat.com> wrote: > Bang Jun-young wrote: > > On 2/7/08, Alexandre Julliard <julliard(a)winehq.org> wrote: > >> "Bang Jun-young" <junyoung(a)mogua.com> writes: > >> > >>> 18 hours passed, and it looks like Alexandre decided to ignore this...why? > >>> > >>> This fix is required for Wine to be built with VC2005/2008 (although > >>> Alexandre doesn't seem to care about it). > >> There's no need to count the hours, or to ask every day, especially not > >> with a mail to wine-patches. I have lots of pending patches from my > >> vacation, I'll get to it eventually, and if I don't you should resubmit > >> it after a week has passed. > > > > That's because you wanted yourself to be the only committer in the > > project. Why don't you give commit privilege to other Wine > > contributors as well? > Huh? Why would you need that? Because I'm concerned with the code quality of Wine. When Alexandre commits what he doesn't understand, it's a red sign to the project. Months ago I posted a patch similar to this one to wine-patches, and he committed it: typedef struct _OLEOBJECTVTBL { - void CALLBACK *(*QueryProtocol)(_LPOLEOBJECT,LPCOLESTR16); + void * (CALLBACK *QueryProtocol)(_LPOLEOBJECT,LPCOLESTR16); How did he know what the patch does from the same message "Fix invalid syntax?" IIRC, he didn't tell anything about what he doesn't understand. In fact, this is a well known mistake many newbie Win32 developers make (and fix in minutes). It shouldn't have been in the tree in the first place if he actually have read the patch. There are a lot of easily catchable bugs in the tree, for example, potential security holes like buffer overrun, meaningless comparison of unsigned < 0 (or > 0), misuse of BOOL vs. HRESULT, misuse of functions such as strcasecmp(), use of non-portable syntax, etc. Most of them (if not all) could be filtered out if he have read the patches carefully. That's the main reason why Wine keeps crashing every time I give it a try with my Windows apps. Since 1993, Wine has never gotten to the point where everybody could rely on it for his daily work. It has as awfully many bugs as Win95. I see something fundamentally wrong with development process. > Wine uses git, a distributed SCM. You are > free to publish your own Wine tree without waiting for Alexandre. 99% of the world won't benefit from what I have done in my own local repository. People usually don't have a much time to keep track of repositories of hundreds of developers around the world. That's why every open source project has the main repository even if developers usually maintain their own repostories at home. > People prefer to follow Alexandre's tree but nobody forces them to use it. If winehq.org is Alexandre's own property, this is something fundametally wrong again.

6 5

Bugzilla: Remove obsolete components
by Austin English 09 Feb '08

09 Feb '08

Howdy, I just finished moving over the last of the obsolete components. _obsolete_binary, _obsolete_directx, and _obsolete_gui can all be removed now. -Austin

3 2

Re: user32: Implement GetWindowModuleFileName with tests
by Dmitry Timoshkov 09 Feb '08

09 Feb '08

"Maarten Lankhorst" <m.b.lankhorst(a)gmail.com> wrote: > UINT WINAPI GetWindowModuleFileNameA( HWND hwnd, LPSTR lpszFileName, UINT cchFileNameMax) > { > - FIXME("GetWindowModuleFileNameA(hwnd %p, lpszFileName %p, cchFileNameMax %u) stub!\n", > - hwnd, lpszFileName, cchFileNameMax); > - return 0; > + LPWSTR filenameW = NULL; > + UINT retval; > + > + if (cchFileNameMax) > + { > + filenameW = HeapAlloc(GetProcessHeap(), 0, cchFileNameMax); > + if (!filenameW) > + { > + SetLastError(ERROR_NOT_ENOUGH_MEMORY); > + return 0; > + } > + } Probably GetWindowModuleFileNameA should simply allocate a buffer of size MAX_PATH on the stack and fail with ERROR_FILENAME_EXCED_RANGE if unicode counterpart returns a string longer than MAX_PATH. kernel32 APIs behave that way. > + retval = GetWindowModuleFileNameW(hwnd, filenameW, cchFileNameMax); > + if (retval) > + { > + DWORD lasterror = GetLastError(); > + WideCharToMultiByte(CP_ACP, 0, filenameW, -1, lpszFileName, cchFileNameMax, NULL, NULL); > + SetLastError(lasterror); What's the point of saving/restoring last error value? If WideCharToMultiByte fails you need to return an error in that case, not silently continue. Also GetWindowModuleFileNameA also should be fixed to return correct value, and not assume that the buffer is '\0' terminated. > UINT WINAPI GetWindowModuleFileNameW( HWND hwnd, LPWSTR lpszFileName, UINT cchFileNameMax) > { > - FIXME("GetWindowModuleFileNameW(hwnd %p, lpszFileName %p, cchFileNameMax %u) stub!\n", > - hwnd, lpszFileName, cchFileNameMax); > - return 0; > + PROCESS_BASIC_INFORMATION pbi; > + DWORD pid, retval; > + HANDLE hproc; > + DWORD lasterror = GetLastError(); > + UNICODE_STRING *pathname; > + TRACE("GetWindowModuleFileNameW(hwnd %p, lpszFileName %p, cchFileNameMax %u)\n", hwnd, lpszFileName, > cchFileNameMax); TRACE/WARN/ERR/etc already print the caller's name, there is no need to duplicate it. > + if (!GetWindowThreadProcessId(hwnd, &pid)) > + { > + SetLastError(ERROR_INVALID_WINDOW_HANDLE); > + return 0; > + } GetWindowThreadProcessId already sets the error to the correct value, there is no need to guess why it failed. > + if (!cchFileNameMax) > + { /* Fail silently without setting filename */ > + SetLastError(lasterror); > + return 0; > + } Saving/restoring last error value doesn't look correct at all. > + hproc = OpenProcess(PROCESS_QUERY_INFORMATION, 0, pid); > + if (!hproc) > + { > + FIXME("Is this correct?"); > + SetLastError(ERROR_INVALID_WINDOW_HANDLE); > + return 0; > + } There is no need to guess why OpenProcess failed. > + retval = NtQueryInformationProcess(hproc, ProcessBasicInformation, &pbi, sizeof(pbi), NULL); > + pathname = &pbi.PebBaseAddress->ProcessParameters->ImagePathName; > + if (pathname->Length / sizeof(WCHAR) < cchFileNameMax) > + { > + memcpy(lpszFileName, pathname->Buffer, pathname->Length); > + lpszFileName[pathname->Length / sizeof(WCHAR)] = 0; > + retval = pathname->Length / sizeof(WCHAR) + 1; > + } > + else > + { > + memcpy(lpszFileName, pathname->Buffer, cchFileNameMax * sizeof(WCHAR)); > + retval = cchFileNameMax; > + } Both branches above should be merged, that will simplify the code. Just '\0' terminate the result if there is enough space in the provided buffer. > + CloseHandle(hproc); > + SetLastError(lasterror); > + FIXME("--> %u %s\n", retval, debugstr_w(lpszFileName)); Left-over from debugging? -- Dmitry.

3 7

← Newer
1
...
23
24
25
26
27
28
29
...
33
Older →

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-devel February 2008