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

Is wine reporting the right value for MaxVertexBlendMatrices ?
by Julio Fernandez Feb. 9, 2008

Feb. 9, 2008

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 Feb. 9, 2008

Feb. 9, 2008

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 Feb. 9, 2008

Feb. 9, 2008

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 Feb. 9, 2008

Feb. 9, 2008

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 Feb. 9, 2008

Feb. 9, 2008

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 Feb. 9, 2008

Feb. 9, 2008

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 Feb. 9, 2008

Feb. 9, 2008

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 Feb. 9, 2008

Feb. 9, 2008

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 Feb. 9, 2008

Feb. 9, 2008

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 Feb. 8, 2008

Feb. 8, 2008

"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

AppDB Issues
by Jeremy Newman Feb. 8, 2008

Feb. 8, 2008

As many of you have noticed we've been having a bit of server trauma this past month. The issue boils down to a bug somewhere in mysqld. We are still trying to find the exact cause of the bug. We do have some leads. I just wanted to do a brain dump on wine-devel here before I go on Vacation for a week. The problem: mysqld will randomly eat up all resources on the system until the server is completely unresponsive to anything but pings. My band-aids thus far: 1. mysql is now running at a nice of 1. This should allow us to at least ssh in and kill it if it gets out of control again. 2. I've removed InnoDB table support to save on memory. Not many tables where using it anyway, and nothing is using transaction support at this time. 3. I've patched the appdb to use memcached for session management. This will reduce some load on the DB as the session table was busiest and slowest table of the appdb. These fixes should give longer uptime, but they are not solving the core issue. While I'm gone, if the server goes offline again, please contact Alexandre or Jeremy White. They can kick proverbial butt of the server to get it going again. Lastly, sorry for the issues. -Newman "We do what we must because we can" - GLaDOS

1 0

Re: More correctly handle the presence of the default ime inputwindow on Ime open and close
by Dmitry Timoshkov Feb. 8, 2008

Feb. 8, 2008

"Aric Stewart" <aric(a)codeweavers.com> wrote: > diff --git a/dlls/imm32/imm.c b/dlls/imm32/imm.c > index 4acbde3..f3ed6f9 100644 > --- a/dlls/imm32/imm.c > +++ b/dlls/imm32/imm.c > @@ -190,19 +190,17 @@ static LRESULT ImmInternalSendIMENotify(WPARAM notify, LPARAM lParam) > > static void ImmInternalSetOpenStatus(BOOL fOpen) > { > - TRACE("Setting internal state to %s\n",(fOpen)?"OPEN":"CLOSED"); > + TRACE("Setting internal state to %s\n",(fOpen)?"OPEN":"CLOSED"); Wouldn't it be better to change indentation to commonly used 4 spaces instead of a strange mix of 3 and 4 spaces? -- Dmitry.

2 1

Fixing make test - progress update
by Jeremy White Feb. 8, 2008

Feb. 8, 2008

I believe that we have an easy way to find out the 'state of the art' wrt to make test. That is, my patch + request of a few days ago: http://www.winehq.org/pipermail/wine-devel/2008-February/062303.html resulted in a very nice, easy to digest report http://test.winehq.org/data/20080205/ That data has five test runs and shows clear across the board failures in msi:install, shell32:shellink, user32:listbox, and user32:msg. So, we can quickly and easily collate and visually see the make test failures. And, heck, I'm sure that fixing those failures is now a trivial exercise. Now we just need the will. :-/. Not sure how to arrange that, but I think having make test succeed on all systems should be a mandatory requirement for Wine 1.0, so I think we have to work on solving it sooner rather than later. The todo's as I see them are as follows: 1. Revise winetest to not require the 'make dist' step, so that the function of my patch can be implemented more cleanly. 2. Persuade people to run a script on a regular basis so we always have this data. It's trickier than the average bear because the tests require the 'real' console, so you can't just stick it in a headless cron job. Maybe some xauth magic... :-/ 3. (The hard one) Focus in and fix the issues. I'll work on #1 and #2 (although not for a week or two), if everyone else agrees to do #3 <evil grin>. Cheers, Jeremy

3 3

Re: user32:scroll.c: Compulsory enabling/disabling scrollbars after setting scrollbar`s flags.
by Anatoly Lyutin Feb. 8, 2008

Feb. 8, 2008

Oh, Sorry! It crashes some another scrollbars. :( -- Best regards Anatoly Lyutin.

1 0

Re: msvcrt: Fix EOF behavior on read from pipe
by Damjan Jovanovic Feb. 8, 2008

Feb. 8, 2008

On Feb 8, 2008 4:31 PM, Dan Kegel <dank(a)kegel.com> wrote: > Nguyễn Thái Ngọc Duy's patch was almost right, he > forgot a test case, and he neglected to move where > EOF is detected for pipes instead of just removing it. > > Should fix http://bugs.winehq.org/show_bug.cgi?id=11187 > > > > 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) and I'm sure short read != end of file for ordinary files either, especially in *nix where read() can easily be interrupted by a signal. Damjan

1 0

re: [PATCH] msvcrt: Fix early pipe closing
by Dan Kegel Feb. 8, 2008

Feb. 8, 2008

On Sat Feb 2, Nguyễn Thái Ngọc Duy wrote: > Pipes are not like other normal files. If we do not read enough > bytes, it does not mean it reaches EOF > ... fixes broken pipe on git-fetch-pack (MinGW port) This is the same problem as http://bugs.winehq.org/show_bug.cgi?id=11187 so it's my fault. Thanks for the information about git-fetch-pack failing, and for the proposed fix. Before we can commit a fix like yours, we need a test case, so I improved msvcrt/tests/file.c to test EOF on pipes more thoroughly. It shows your patch was almost right. I've fixed up your patch and will send it in. - Dan

1 0

kernel32: Implement ReplaceFileW
by luis.busquets＠ilidium.com Feb. 8, 2008

Feb. 8, 2008

I have read this patch sent in several times and have realised that every time it contains a large number of "goto"'s. I certainly do not like "goto" in structured code. My question to the forum is if it is allowed to use "goto" in wine or if you prefer not to use it. Even when this will make the code larger but it may give a little nore readability,

2 1

Patch tracking system - again...
by Steven Edwards Feb. 8, 2008

Feb. 8, 2008

Hi, I'm not sure if this would even really be of use with most of the development being done on git anyway, but after re-reading the governance thread when the point of patch tracking was brought up, It got me thinking. last time around it got shelved as normal due to not wanting to disrupt Alexandre's work flow. Thinking about it a bit more I think I've come up with a solution to the problem that should not disrupt Alexandre's flow if I understand git properly. Let me preface this with saying that I don't. At first I thought we might be able to use the sha1 hashes that are the patch names themselves to track if a commit had be accepted or not, but then I guess that would only work if we were pushing and pulling directly in to each others tree's as I see the commit hash differs from the patch hash in the patches I've reviewed. I can only assume this is because of the way git views looks at the entire repo as one chunk of data rather than dealing with single patches. Then as I dug in to it a bit more I noticed the index's did match provided Alexandre did not make any changes before he committed. I was thinking this could be a use for a tracking system. Lets imagine there is this patch daemon that sits out there and reads wine-patches, storing the diff and parsing the index in to a database. This deamon could do a git fetch every 30 mins or so to compare and see if a patch has been merged in based on the index. It seems like we already have most of the tools we need to do it now if someone really wants the tracking system. We know about the patches and we know if its been merged or not, defining rules for accepted or rejected seem pretty trivial to me as we already have the rule, if its not merged in a week then resend. So here is what it would look like as far as work flow goes, someone submits a patch, it goes to this database and up to a website with a listview showing all the patches. Anything not merged yet still in the two week window would show up in the list as white meaning still pending. The further up the list we would have patches that were merged and accepted as is, like the following (showing up in green) http://www.winehq.org/pipermail/wine-patches/2008-February/049719.html http://source.winehq.org/git/wine.git/?a=commit;h=ac61b90f87a2062b99f6f7068… The following patch would show up in yellow as the index differs for the Makefile part of the patch as Julliard made local changes http://www.winehq.org/pipermail/wine-patches/2008-February/049720.html http://source.winehq.org/git/wine.git/?a=commit;h=5bad12c6bc3072a2676f0d9ed… Any other patches that don't get merged would show up in the list as red after the one week window went by. The tracker would assume they were rejected. The cool thing about this is that we could directly link it in to bugzilla so that when a patch is applied the bug could get automatically updated. Now this all hinges on being able to use the diff index to do the tracking. I imagine there might be conflicts if your trying to use that as the only data point as its not as long as a real hash, but assuming your only doing a compare over as period of a few weeks or a month I think it would work. Am I wack? Is there even still the desire to have a graphical patch tracking system? -- 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

2 1

re: Code quality (was Re: comctl32: Fix invalid syntax)
by Dan Kegel Feb. 7, 2008

Feb. 7, 2008

Bang Jun-young wrote: >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. I don't think so. In my experience, it's either a missing feature or something more subtle. Outright bugs of the kind you describe are the minority. I think. > 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. Nah, Alexandre usually does a good job of screening patches. We're lucky to have such a good maintainer, IMHO. (I say this knowing full well that newbies are put off by how difficult it is to get feedback because I have seen much, much worse maintainers. Imagine if, say, that guy who always yells at the newbies to not paste logs in bug reports was the maintainer. We'd probably lose all our developers in a month.) So you're peeved you don't have commit access. That's understandable, but it's time to get over it. IMHO the single-committer system works pretty well once you get into the swing of it. It actually forces at least one code review on every patch! - Dan

1 0

War on conformance test suite failures!
by Dan Kegel Feb. 7, 2008

Feb. 7, 2008

Great progress was made at Wineconf last year on getting our test suite closer to always passing on wine, but http://test.winehq.org/data/200801301937/#Wine shows that, according to the results collected from people who run programs/winetest on Wine, twelve DLLs' tests are currently failing. (Let alone the test failures on Windows!) http://bugs.winehq.org/show_bug.cgi?id=9916 also talks about the fact that "make test" shows failures. This situation greatly confuses new developers, who assume that any test failure is somehow their fault. And that's a reasonable assumption, let's make it so! It would make validating a new Wine development environment easy -- it'd be great to be able to say If it doesn't pass "make test" with no errors, something's wrong with the build environment. What's the best way to encourage people to fix these problems? Should we designate some upcoming day, week, or month as a conformance test bug squishing party? Should we offer prizes (or at least notoriety) for the person who does the best job fixing conformance test suite bugs (as judged by Alexandre or his designate)? Or is a simple call to arms enough?

5 8

Re: comctl32: Fix invalid syntax.
by Bang Jun-young Feb. 7, 2008

Feb. 7, 2008

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). On 2/6/08, Bang Jun-young <junyoung(a)mogua.com> wrote: > Any reason why this hasn't been committed? >

3 3

Re: gdi32: correct the test message in font.c that was out of sync with the test. [RESEND]
by Alexandre Julliard Feb. 7, 2008

Feb. 7, 2008

"Reece Dunn" <msclrhd(a)googlemail.com> writes: > diff --git a/dlls/gdi32/tests/font.c b/dlls/gdi32/tests/font.c > index 7e560d2..bfdb0af 100644 > --- a/dlls/gdi32/tests/font.c > +++ b/dlls/gdi32/tests/font.c > @@ -604,7 +604,7 @@ static void test_GetGlyphIndices(void) > flags |= GGI_MARK_NONEXISTING_GLYPHS; > charcount = pGetGlyphIndicesW(hdc, testtext, (sizeof(testtext)/2)-1, glyphs, flags); > ok(charcount == 5, "GetGlyphIndices count of glyphs should = 5 not %d\n", charcount); > - ok((glyphs[4] == 0x001f || glyphs[4] == UNICODE_NOCHAR /* Vista */), "GetGlyphIndices should have returned a nonexistent char not %04x\n", glyphs[4]); > + ok((glyphs[4] == 0x001f || glyphs[4] == UNICODE_NOCHAR /* Vista */), "GetGlyphIndices should have returned a nonexistent char or UNICODE_NOCHAR, not %04x\n", glyphs[4]); UNICODE_NOCHAR is a nonexistent char too. And if someone really cares about the exact details they can always look at the test, we don't need to duplicate all of it in the error message. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: user32: make the listbox tests pass in directories other than dlls/user32/tests. [RESEND]
by Alexandre Julliard Feb. 7, 2008

Feb. 7, 2008

"Reece Dunn" <msclrhd(a)googlemail.com> writes: > diff --git a/dlls/user32/tests/listbox.c b/dlls/user32/tests/listbox.c > index 3645190..f1a7b2b 100644 > --- a/dlls/user32/tests/listbox.c > +++ b/dlls/user32/tests/listbox.c > @@ -560,6 +560,8 @@ static void test_listbox_LB_DIR() > char * p; > char driveletter; > > + fclose( fopen( "wtest1.tmp.c", "w" ) ); Using stdio is not really appropriate here, CreateFile() would be a better choice. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: shell32: Fix security issue in SHELL_execute.
by Alexandre Julliard Feb. 7, 2008

Feb. 7, 2008

Robert Shearman <rob(a)codeweavers.com> writes: > execfunc should not be called on files which aren't supposed to be > executable. This doesn't work: ../../../tools/runtest -q -P wine -M shell32.dll -T ../../.. -p shell32_test.exe.so shlexec.c && touch shlexec.ok shlexec.c:971: Test failed: ShellExecuteEx(null, "C:\windows\temp\\test_shortcut_exe.lnk", null, null) failed: rc=31 err=2 shlexec.c:974: Test failed: argvA3 expected 'Lnk', got '(null)' shlexec.c:1010: Test failed: ShellExecuteEx(null, "C:\windows\temp\\test_shortcut_exe.lnk", ""C:\windows\temp\\nonexistent.shlexec"", null) failed: rc=31 err=2 shlexec.c:1010: Test failed: ShellExecuteEx(null, "C:\windows\temp\\test_shortcut_exe.lnk", ""C:\windows\temp\\nonexistent.noassoc"", null) failed: rc=31 err=2 shlexec.c:1010: Test failed: ShellExecuteEx(null, "C:\windows\temp\\test_shortcut_exe.lnk", ""C:\windows\temp\\test file.shlexec"", null) failed: rc=31 err=2 shlexec.c:1010: Test failed: ShellExecuteEx(null, "C:\windows\temp\\test_shortcut_exe.lnk", ""C:\windows\temp\/%nasty% $file.shlexec"", null) failed: rc=31 err=2 shlexec.c:1010: Test failed: ShellExecuteEx(null, "C:\windows\temp\\test_shortcut_exe.lnk", ""C:\windows\temp\\test file.noassoc"", null) failed: rc=31 err=2 shlexec.c:1062: Test failed: ShellExecuteEx(null, "Z:\home\julliard\wine\wine\dlls\shell32\tests\shell32_test.exe.so", "shlexec "C:\windows\temp\wt51f.tmp" Exec", null) returned 31 shlexec.c:1064: Test failed: argvA3 expected 'Exec', got '(null)' shlexec.c:1071: Test succeeded inside todo block: ShellExecute(null, "C:\windows\temp\\test file.noassoc", "shlexec "C:\windows\temp\wt51f.tmp" Exec", null) succeeded: rc=31 shlexec.c:1093: Test failed: ShellExecuteEx(null, "Z:\home\julliard\wine\wine\dlls\shell32\tests\shell32_test.exe.so", "shlexec "C:\windows\temp\wt51f.tmp" abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxy", null) returned 31 shlexec.c:1095: Test failed: argvA3 expected 'abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxy', got '(null)' shlexec.c:1102: Test succeeded inside todo block: ShellExecute(null, "C:\windows\temp\\test file.noassoc", "shlexec "C:\windows\temp\wt51f.tmp" abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxy", null) succeeded: rc=31 make: *** [shlexec.ok] Error 13 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: msi 2: Handle carriage returns in MsiDatabaseImport
by Alexandre Julliard Feb. 7, 2008

Feb. 7, 2008

"James Hawkins" <truiken(a)gmail.com> writes: > Hi, > > Fixes bug 11479. http://bugs.winehq.org/show_bug.cgi?id=11479 This doesn't work: ../../../tools/runtest -q -P wine -M msi.dll -T ../../.. -p msi_test.exe.so automation.c && touch automation.ok automation.c:276: Test failed: Expected ERROR_SUCCESS, got 1627 wine: Unhandled page fault on read access to 0x00000018 at address 0x6002a3da (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x00000018 in 32-bit code (0x6002a3da). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:6002a3da ESP:0033f400 EBP:0033f578 EFLAGS:00010206( - 00 - RIP1) EAX:00000018 EBX:60121844 ECX:00000018 EDX:0033f5b8 ESI:602adce0 EDI:0033f52d Stack dump: 0x0033f400: 00000000 4d430002 00132fac 00000004 0x0033f410: 600425f6 0033f44c 6065e20e 602adce0 0x0033f420: 0033f5b8 0033f5b8 00000001 7bc417fa 0x0033f430: 00000000 4d430002 00133004 00000004 0x0033f440: 00000010 0033f47c 0033f464 00000030 0x0033f450: 00134180 00110014 00000020 00000000 Backtrace: =>1 0x6002a3da vsnprintfW+0x3ca(str=0x33f67a, len=0x7fffffff, format=0x6065e20a, valist=0x33f5b8) [/home/julliard/wine/wine/libs/wine/string.c:376] in libwine.so.1 (0x0033f578) 2 0x6002a596 sprintfW+0x36(str=0x33f678, format=0x6065e20a) [/home/julliard/wine/wine/libs/wine/string.c:458] in libwine.so.1 (0x0033f5a8) 3 0x60610808 MSI_DatabaseImport+0x13e8(db=0x130ef8, folder=<is not available>, file=0x1329ca) [/home/julliard/wine/wine/dlls/msi/database.c:603] in msi (0x0033f7f8) 4 0x60610b29 MsiDatabaseImportW+0x129(handle=<register EDI not in topmost frame>, szFolder=0x12fcd0, szFilename=0x1329b0) [/home/julliard/wine/wine/dlls/msi/database.c:777] in msi (0x0033f828) 5 0x60610cce MsiDatabaseImportA+0x18e(handle=0x1, szFolder=0x605b43c0, szFilename=0x605a3db7) [/home/julliard/wine/wine/dlls/msi/database.c:803] in msi (0x0033f868) 6 0x60527631 test_Installer+0x571() [/home/julliard/wine/wine/dlls/msi/tests/automation.c:275] in msi_test (0x0033fbd8) 7 0x6052983b func_automation+0xebb() [/home/julliard/wine/wine/dlls/msi/tests/automation.c:2428] in msi_test (0x0033fe68) 8 0x60592cea run_test+0x14a(name=0x1103ec) [/home/julliard/wine/wine/dlls/msi/tests/../../../include/wine/test.h:389] in msi_test (0x0033fea8) 9 0x60593332 main+0x142(argc=<register ECX not in topmost frame>, argv=0x1103d0) [/home/julliard/wine/wine/dlls/msi/tests/../../../include/wine/test.h:437] in msi_test (0x0033fed8) 10 0x6059340b __wine_spec_exe_entry+0x5b(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in msi_test (0x0033ff08) 11 0x7b8744ee start_process+0xee(arg=0x0) [/home/julliard/wine/wine/dlls/kernel32/process.c:883] in kernel32 (0x0033ffe8) 12 0x600288d7 wine_switch_to_stack+0x17() in libwine.so.1 (0x00000000) 0x6002a3da vsnprintfW+0x3ca [/home/julliard/wine/wine/libs/wine/string.c:376] in libwine.so.1: movzwl 0x0(%ecx),%edx 376 while (*striter) -- Alexandre Julliard julliard(a)winehq.org

1 0