- wine-devel - winehq.org

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

AppDB Issues
by Jeremy Newman 08 Feb '08

08 Feb '08

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 08 Feb '08

08 Feb '08

"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 08 Feb '08

08 Feb '08

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 08 Feb '08

08 Feb '08

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 08 Feb '08

08 Feb '08

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 08 Feb '08

08 Feb '08

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 08 Feb '08

08 Feb '08

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 08 Feb '08

08 Feb '08

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 08 Feb '08

08 Feb '08

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 07 Feb '08

07 Feb '08

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 07 Feb '08

07 Feb '08

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 07 Feb '08

07 Feb '08

"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 07 Feb '08

07 Feb '08

"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 07 Feb '08

07 Feb '08

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 07 Feb '08

07 Feb '08

"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

Re: 2/2 start.exe: Handle the process title argument (try3)
by Alexandre Julliard 07 Feb '08

07 Feb '08

Alexander Nicolaysen Sørnes <alex(a)thehandofagony.com> writes: > + vi.dwOSVersionInfoSize = sizeof(vi); > + GetVersionExW(&vi); > + > + /* On Windows 9x start does not have the process title argument. > + It works such that if the first parameter begins with a double quote ("), > + it is taken as the process title. Thus 'start "notepad" a' will work on > + Windows 9x but not NT variants */ > + if(argc > 1 && (vi.dwMajorVersion >= 5 || (vi.dwMajorVersion == 4 && vi.dwPlatformId == 2))) The right way to check for Win9x is GetVersion() & 0x80000000. > + { > + int cmdcount; > + WCHAR* cmdline = GetCommandLineW(); > + WCHAR** cmdargs = CommandLineToArgvW(cmdline, &cmdcount); > + WCHAR* pos = cmdline; > + > + pos += lstrlenW(cmdargs[0]); This won't work if the program name is quoted. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: systray[3/4]: Better validate icon owner
by Robert Shearman 07 Feb '08

07 Feb '08

Kirill K. Smirnov wrote: > @@ -131,15 +130,18 @@ static LRESULT WINAPI adaptor_wndproc(HW > case WM_LBUTTONDBLCLK: > case WM_RBUTTONDBLCLK: > case WM_MBUTTONDBLCLK: > - /* notify the owner hwnd of the message */ > - WINE_TRACE("relaying 0x%x\n", msg); > - ret = PostMessage(icon->owner, icon->callback_message, (WPARAM) icon->id, (LPARAM) msg); > - if (!ret && (GetLastError() == ERROR_INVALID_HANDLE)) > + if (!IsWindow(icon->owner)) > { > WINE_WARN("application window was destroyed without removing " > "notification icon, removing automatically\n"); > delete_icon_directly(icon); > } > + else > + { > + /* notify the owner hwnd of the message */ > + WINE_TRACE("relaying 0x%x\n", msg); > + PostMessage(icon->owner, icon->callback_message, (WPARAM) icon->id, (LPARAM) msg); > + } > break; > > case WM_NCDESTROY: I don't get why you need this change. PostMessage should correctly handle the case where icon->owner has been destroyed and adding a call to IsWindow just introduces a race condition. -- Rob Shearman

2 2

Re: systray[3/4]: Better validate icon owner
by Kirill K. Smirnov 07 Feb '08

07 Feb '08

> I don't get why you need this change. PostMessage should correctly > handle the case where icon->owner has been destroyed and adding a call > to IsWindow just introduces a race condition. Just a testcase: 1) run any wine app (to be sure that explorer is running), e.g winecfg 2) run taskmgr 3) select taskmgr process in tasklist and kill it. taskmgr window will dissapear but tray icon not. 4) move mouse cursor over taskmgr tray icon. Before this patch it will not dissapear, but should. The reason is that ERROR_INVALID_HANDLE is not the only value which indicates the absence of owner window (ERROR_INVALID_WINDOW_HANDLE too). I think that using robust and straightforward IsWindow() function is better than verify last error. Is it acceptable to check return value of PostMessage only and do not check last error? And what race condition introduces IsWindow() here? -- Kirill

2 1

Re: [PATCH] dinput: Skip old mouse movement evenets.
by Alexandre Julliard 07 Feb '08

07 Feb '08

Vitaliy Margolen <wine-patches(a)kievinfo.com> writes: > @@ -280,6 +281,9 @@ static void dinput_mouse_hook( LPDIRECTINPUTDEVICE8A iface, WPARAM wparam, LPARA > { > POINT pt, pt1; > > + /* Skip old movement events */ > + if (This->last_event_time > hook->time) break; That's not an appropriate way to compare timestamps. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: x11drv: implement X11DRV_AlphaRender for non bitmap sources
by Alexandre Julliard 07 Feb '08

07 Feb '08

Aric Stewart <aric(a)codeweavers.com> writes: > @@ -1569,12 +1570,14 @@ BOOL X11DRV_AlphaBlend(X11DRV_PDEVICE *devDst, INT xDst, INT yDst, INT widthDst, > > if (!devSrc->bitmap || GetObjectW( devSrc->bitmap->hbitmap, sizeof(dib), &dib ) != sizeof(dib)) > { > - FIXME("not a dibsection\n"); > - return FALSE; > + TRACE("not a dibsection\n"); > + bitmap = FALSE; It can be an invalid handle too, you can't assume that it's a valid bitmap just because it isn't a DIB. Also naming the boolean 'bitmap' for the DIB section case is very confusing, both are bitmaps. > > - if (xSrc < 0 || ySrc < 0 || widthSrc < 0 || heightSrc < 0 || xSrc + widthSrc > dib.dsBmih.biWidth > - || ySrc + heightSrc > abs(dib.dsBmih.biHeight)) > + if (xSrc < 0 || ySrc < 0 || widthSrc < 0 || heightSrc < 0 || (bitmap && xSrc + widthSrc > dib.dsBmih.biWidth) > + || (bitmap && ySrc + heightSrc > abs(dib.dsBmih.biHeight))) Testing the flag all over the place is ugly, you should separate the code completely, have one block for DIBs and one block for DDBs, with a single if at the top. -- Alexandre Julliard julliard(a)winehq.org

1 0

regression in worms2
by luis.busquets＠ilidium.com 07 Feb '08

07 Feb '08

The same bug happens in Patrician3.exe If you apply the attached patch if should be ok. Please let me know, if that worked also for you.

3 2

Re: systray[2/4]: correctly handle icon addition/deletion
by Kirill K. Smirnov 07 Feb '08

07 Feb '08

В сообщении от Thursday 07 February 2008 02:58:42 вы написали: > Kirill K. Smirnov wrote: > > @@ -71,6 +71,12 @@ struct icon > > static struct tray tray; > > static BOOL hide_systray; > > > > +static BOOL add_icon(NOTIFYICONDATAW *nid); > > +static BOOL modify_icon(NOTIFYICONDATAW *nid); > > +static BOOL delete_icon(const NOTIFYICONDATAW *nid); > > +static BOOL delete_icon_directly(struct icon *icon); > > +static BOOL display_icon(struct icon *icon, BOOL hide); > > + > > /* adaptor code */ > > > > #define ICON_SIZE GetSystemMetrics(SM_CXSMICON) > > I don't see any reason why you need to add forward declarations for all > of these functions. Hmmmm..... It may be an artifact from my development when I need to call them from places before they defined.... Anyway, is it really bad to have them declared here? If so I'll remove it. -- Kirill

2 1

Re: systray[2/4]: correctly handle icon addition/deletion
by Robert Shearman 06 Feb '08

06 Feb '08

Kirill K. Smirnov wrote: > @@ -71,6 +71,12 @@ struct icon > static struct tray tray; > static BOOL hide_systray; > > +static BOOL add_icon(NOTIFYICONDATAW *nid); > +static BOOL modify_icon(NOTIFYICONDATAW *nid); > +static BOOL delete_icon(const NOTIFYICONDATAW *nid); > +static BOOL delete_icon_directly(struct icon *icon); > +static BOOL display_icon(struct icon *icon, BOOL hide); > + > /* adaptor code */ > > #define ICON_SIZE GetSystemMetrics(SM_CXSMICON) > I don't see any reason why you need to add forward declarations for all of these functions. -- Rob Shearman

1 0

Re: systray[1/4]: rewrite tooltips support
by Kirill K. Smirnov 06 Feb '08

06 Feb '08

> Please explain better what you are doing, "rewrite tooltips support" > doesn't say what is changing or why the change is needed (and "rewrite" > is an exaggeration, you are mostly just moving code around). The main issue this patch fixes is an "attempt to set/modify a tooltip to a nonexistent window". This may happen when application modifies tip text while icon is hidden (e.g. when adding initially disabled icon with tooltip). [verbose] The change I did: 1) Store tip text in the icon structure. 2) Move tooltip creation code to the separate function. 3) Immediately bind tooltip to icon window at creation. We can bind empty tooltip text with icon window and further just update text when needed. 4) set_tooltip function was renamed to update_tooltip_text and simplified. Since tooltip support code is relatively small, this was enough for me to exaggeratedly proclaim tooltip support be rewritten ;-) [/verbose] So this ChangeLog is better: Avoid modifying non-existent tooltip windows of non-existent icon windows when application updates tip of hidden icon. -- Kirill

1 0

Re: systray[1/4]: rewrite tooltips support
by Alexandre Julliard 06 Feb '08

06 Feb '08

"Kirill K. Smirnov" <lich(a)math.spbu.ru> writes: > diff --git a/programs/explorer/systray.c b/programs/explorer/systray.c Please explain better what you are doing, "rewrite tooltips support" doesn't say what is changing or why the change is needed (and "rewrite" is an exaggeration, you are mostly just moving code around). -- Alexandre Julliard julliard(a)winehq.org

1 0

Building tests with Visual Studio 2005 Express
by Dan Kegel 06 Feb '08

06 Feb '08

After giving up for the moment on building with Visual C 6, I tried Visual Studio 2005. First hitch: Boy, does it spew out lots of warnings about deprecated functions! http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=87401&SiteID=1 talks about this a bit; defining _CRT_SECURE_NO_DEPRECATE and _CRT_NONSTDC_NO_DEPRECATE suppresses the warnings. Fix: You can't set them via corewin_express.vsprops because our project is converted from an older visual studio version, so you have to add those two defines to all the .dsp files, e.g. perl -p -i -e 's,/D "WIN32",/D "WIN32" /D "_CRT_NONSTDC_NO_DEPRECATE" /D "_CRT_SECURE_NO_DEPRECATE",' `find . -iname '*.dsp'` Second hitch: For some reason, the imported projects lose their list of .lib files to link against. Fix: As suggested at http://msdn2.microsoft.com/en-us/express/aa700755.aspx add user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib to the "Additional Dependencies" setting in the file corewin_express.vsprops. Third hitch: error C2065: 'PFORM_INFO_2A': undeclared identifier See http://msdn2.microsoft.com/en-us/library/aa383745(VS.85).aspx and http://blogs.msdn.com/oldnewthing/archive/2007/04/11/2079137.aspx winspool.h only defines the new symbol if NTDDI_VERSION is NTDDI_LONGHORN or higher. NTDDI_LONGHORN is 0x06000000. Fix: add /D _WIN32_WINNT=0x0600 to that list of changes to all the .dsp files in hitch #1 above. Fourth hitch: urlmon_test.exe refers to CLSID_IdentityUnmarshal, but that symbol is not defined. ?? Fifth hitch: generated.c refers to CS_STUB_INFO, which is not defined in Microsoft's rpcndr.h. ?? Sixth hitch: it can't find server.h Seventh hitch: can't find tmarshal.h Fix: Not sure, but maybe these files need to be generated by midl, and msvcmaker doesn't know about that yet? See http://www.mail-archive.com/wine-devel@winehq.org/msg37442.html Eighth hitch: riched20/tests/editor.c fails to compile because in GETTEXTEX, the field is named lpUsedDefChar, not lpUsedDefaultChar Fix: fix our richedit.h? ... Seventy-seventh hitch: gdiplus/tests/brush.c includes Microsoft's gdiplus.h, but that's not safe to include from C, so you get an error on the namespace. Golly. I guess I won't be building the tests with any flavor of microsoft C any time soon! - Dan

5 6

Re: added wgl_bind_to_texture_depth_nv to ConvertAttribWGLtoGLX
by Chris Robinson 06 Feb '08

06 Feb '08

On Wednesday 06 February 2008 11:44:58 am you wrote: > Chris Robinson wrote: > > I don't think it's correct to add this since it's not supported (the > > extension string isn't exported and it can't be easilly emulated). If an > > app is trying to set that attribute without the extension being > > advertised, I'd say the app is broken. If you're intending on adding > > support, you may want to familiarize yourself with how wine emulates > > render_to_texture and look over the extension: > > http://opengl.org/registry/specs/NV/render_depth_texture.txt > > "I don't think it's correct to add this since it's not supported" > The > > case WGL_BIND_TO_TEXTURE_RGB_ARB: > case WGL_BIND_TO_TEXTURE_RGBA_ARB: > case WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_R_NV: > are not supported either. The WGL_BIND_TO_TEXTURE_DEPTH_NV came up as a > fixme since it isn't in the switch. The formats are supported in X11DRV_wglGetPixelFormatAttribivARB, X11DRV_wglCreatePbufferARB and the other render-to-texture functions, and the render-to-texture extension is advertised.. There's just nothing to do in that function for them since the hint will always be accepted. But I don't see the point in supporting a pbuffer creation hint that an app shouldn't be using without the extension being advertised (actually, I think pbuffer creation is supposed to fail if an unsupported attribute is specified). Which app is trying to use it? > Again, just trying to learn, not annoy > people with tiny fixes. No annoyance to me, just explaining why I don't think it's something to handle. :)

1 0

Stupid new winetricks: added a trivial GUI
by Dan Kegel 06 Feb '08

06 Feb '08

Some users freak at the thought of a commandline, so I threw together a trivial GUI using whatever gui-from-shell tool is appropriate for the current desktop. Unfortunately, that means the default action is to put up a gui, not show help. You have to say winetricks -h or the like to get help. It's ugly, so shoot me :-) As always, it's available at http://kegel.com/wine/winetricks and the svn repository is http://code.google.com/p/winezeug/

2 2

Re: RegOverridePredefKey stub - Take 2
by Dmitry Timoshkov 06 Feb '08

06 Feb '08

"Jens Nestler" <nessi(a)nessi-online.de> wrote: > Stub implementation for RegOverridePredefKey. > The added prototype in the winreg.h is now in alphabetical order. Please review yuor patches before sending, this one contains not related changes. -- Dmitry.

1 0

Re: [5/8] WineD3D: Add infrastructure for faking driver versions
by Alexandre Julliard 06 Feb '08

06 Feb '08

Stefan Dösinger <stefan(a)codeweavers.com> writes: > +/* Certain applications(Steam) complain if we report an outdated driver version. In general, > + * reporting a driver version is moot because we are not the Windows driver, and we have different > + * bugs, features, etc. > + * > + * Some drivers(ATI, Nvidia Linux drivers) have a shared codebase with the Windows driver, so we're > + * reading the Linux driver version and report it to the app. Some drivers(Apple drivers, Mesa) don't > + * have the version match, so we overwrite the OpenGL driver version with a hardcoded one. Obviously > + * the hardcoded driver version is outdated once a new Windows driver is released, so we'll have to > + * keep them in sync manually. > + * > + * If a card is not found in this table, the gl driver version is reported > + */ > +struct driver_version_information { > + WORD vendor; /* reported PCI card vendor ID */ > + WORD card; /* reported PCI card device ID */ > + BOOL loword_matches_apple; /* Are Mac and Win driver versions matching? */ > + BOOL loword_matches_linux; /* Are Lin and Win driver versions matching? */ The world is not limited to Mac and Linux, this sort of thing can't scale. -- Alexandre Julliard julliard(a)winehq.org

3 6

Re: uxtheme: fix the system tests so they pass on Vista. [try 2] [RESEND]
by Alexandre Julliard 06 Feb '08

06 Feb '08

"Reece Dunn" <msclrhd(a)googlemail.com> writes: > The Vista return code is what wine is returning, so remove the todo > block as well. Not for me: ../../../tools/runtest -q -P wine -M uxtheme.dll -T ../../.. -p uxtheme_test.exe.so system.c && touch system.ok system.c:420: Test failed: Expected E_POINTER or S_OK, got 0x80070490 make: *** [system.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

winedbg - using pdb from Visual Studio 2005
by Michel Jacques 06 Feb '08

06 Feb '08

Hello, I am using PDBs generated with 2005 with wine version 0.9.54. I get errors related to my PDBs and I am wondering if I need to change the pdb format? Anything special to do when using 2005? Here are the errors I get, each time one of my pdb gets loaded: 0009:trace:dbghelp:SymFindFileInPathW (hProcess = 0x30, searchPath = (null), full_path = L"C:\\master\\x86\\debug\\bin\\mydll.pdb", id = 0x34c160, two = 0x00000002, three = 0x00000000, flags = 0x00000008, buffer = 0x34b718, cb = 0x6020fb50, user = 0x34bd30) 0009:err:dbghelp_msc:pdb_process_types -Unknown type info version 20040203 0009:err:dbghelp_msc:pe_load_debug_directory Got a page fault while loading symbols 0009:trace:dbghelp:pcs_callback 0x111998 2 0x34c378 0009:trace:dbghelp:pcs_callback 0x111998 1 0x34c378 0009:trace:dbghelp:pe_load_stabs failed to load the STABS debug info Thanks, Michel Jacques Découvrez les styles qui font sensation sur Yahoo! Québec Avatars. http://cf.avatars.yahoo.com/

4 5

Re: [winetest] Add a new utility to simply running + submitting tests via winetest when run from the Wine tree.
by Alexandre Julliard 06 Feb '08

06 Feb '08

Jeremy White <jwhite(a)winehq.org> writes: > +date +%Y%m%d >build.id > +gcc --version >build.nfo > +uname -a >>build.nfo > +/lib/libc.so.6 >>build.nfo > +echo N/A >tests.url > +make dist > +make > +export WINEPREFIX=`mktemp -d` > +wineprefixcreate > + > +type winetricks >/dev/null 2>&1 > +if [ $? -eq 0 ] ; then > + winetricks gecko > +fi > + > +./winetest-dist -c -t "$1" None of that should be necessary. The make dist stuff is supposed to be for people who want to distribute a winetest binary. If what you want is simply run the tests then you should just have to run winetest; if some things don't work in that mode they should be fixed. -- Alexandre Julliard julliard(a)winehq.org

1 0

Bug in patch winex11.drv: Don't create a win_data structure for the desktop window, except in the process that owns it.
by "Luis C. Busquets Pérez" 06 Feb '08

06 Feb '08

There is a bug in the patch: c19af910ebafa9b1928b0f67bee68f6b0b237e8e is first bad commit commit c19af910ebafa9b1928b0f67bee68f6b0b237e8e Author: Alexandre Julliard <julliard(a)winehq.org> Date: Thu Jan 17 19:53:59 2008 +0100 winex11.drv: Don't create a win_data structure for the desktop window, except in the process that owns it. Handle desktop size changes by sending a message to the desktop owner. :040000 040000 b7c030353fe92121bb999481724a3689429b2e8a 80fd2c5f4ace2707abb01648bd61663a6c9d7626 M dlls It affects to Patrician3.exe. When initiating, it hangs and does not allow to play the movie. Actually, the programm changes the screen resolution and hangs. I understand that the problem is that it does not send the appropiate message for binkplayer.exe to play the movie.

5 4

New winetricks: msxml6, riched30
by Dan Kegel 06 Feb '08

06 Feb '08

Johan Dahlin sent in a patch to add msxml6, and said "It's enough to make msi2xml.exe to at least start-up (before failing in msi later)." Tom Wickline some time ago sent in a suggestion for adding riched30. I didn't know any apps it helped, but apparantly Novell thinks it helps Groupwise a bit. So it's in now. Caution, it doesn't update riched32, no idea what happens if apps try to use it after this... As always, it's available at http://kegel.com/wine/winetricks and the svn repository is http://code.google.com/p/winezeug/

1 0

regression in worms2
by Olaf Leidinger 06 Feb '08

06 Feb '08

Hello! I noticed that the game "worms 2" broke between wine-0.9.53 and wine-0.9.54. A git-bisect revealed the guilty patches. The game includes a frontend.exe which starts game.exe and controls the settings of the game (the map and teams etc.). Running game.exe directly works but you can't alter the settings. When running game.exe via frontend the game doesn't show up but hangs after changing resolution. Before the following commit the game starts and is playable: 2921f5c156b368b4ce6e615eb61dad5c5f423bf8 is first bad commit commit 2921f5c156b368b4ce6e615eb61dad5c5f423bf8 Author: Alexandre Julliard <julliard(a)winehq.org> Date: Tue Jan 22 20:06:35 2008 +0100 server: Invalidate the correct region when custom valid rects are specified. :040000 040000 1385d5899b5b6affd5da84328e1bc15985406976 5c8756013a67c0402f3bb5fb9f3ee7b4a50e124a M server And this one makes worms2 hang after exiting the game: c19af910ebafa9b1928b0f67bee68f6b0b237e8e is first bad commit commit c19af910ebafa9b1928b0f67bee68f6b0b237e8e Author: Alexandre Julliard <julliard(a)winehq.org> Date: Thu Jan 17 19:53:59 2008 +0100 winex11.drv: Don't create a win_data structure for the desktop window, except in the process that owns it. Handle desktop size changes by sending a message to the desktop owner. :040000 040000 b7c030353fe92121bb999481724a3689429b2e8a 80fd2c5f4ace2707abb01648bd61663a6c9d7626 M dlls Thanks for your attention! Ciao, Olaf

3 7

Re: RegOverridePredefKey stub
by Dmitry Timoshkov 06 Feb '08

06 Feb '08

"Jens Nestler" <nessi(a)nessi-online.de> wrote: > diff -urN wine-0.9.54_org/include/winreg.h wine-0.9.54/include/winreg.h > --- wine-0.9.54_org/include/winreg.h 2008-01-25 17:05:38.000000000 +0100 > +++ wine-0.9.54/include/winreg.h 2008-01-28 22:07:55.000000000 +0100 > @@ -131,6 +131,7 @@ > WINADVAPI LSTATUS WINAPI RegLoadKeyA(HKEY,LPCSTR,LPCSTR); > WINADVAPI LSTATUS WINAPI RegLoadKeyW(HKEY,LPCWSTR,LPCWSTR); > #define RegLoadKey WINELIB_NAME_AW(RegLoadKey) > +WINADVAPI LSTATUS WINAPI RegOverridePredefKey(HKEY,HKEY); > WINADVAPI LSTATUS WINAPI RegLoadMUIStringA(HKEY,LPCSTR,LPSTR,DWORD,LPDWORD,DWORD,LPCSTR); > WINADVAPI LSTATUS WINAPI RegLoadMUIStringW(HKEY,LPCWSTR,LPWSTR,DWORD,LPDWORD,DWORD,LPCWSTR); > #define RegLoadMUIString WINELIB_NAME_AW(RegLoadMUIString) Isn't there something that suggests that the entries are alphabetically sorted? -- Dmitry.

2 4

Building tests with MSVC 6 broken?
by Dan Kegel 06 Feb '08

06 Feb '08

Call me an oldtimer, but I decided to try building winetest with MSVC 6 today. I installed cygwin's git and perl, grabbed wine from git, and used msvcmaker as described at http://winehq.org/site/docs/winedev-guide/testing-windows I downloaded and installed the Platform SDK from the first google hit, the Windows Server 2003 SP1 Platform SDK, http://www.microsoft.com/downloads/details.aspx?FamilyId=A55B6B43-E24F-4EA3… (although the latest is Windows Server 2003 R2 Platform SDK, I thought the slightly older one would be ok). Oddly, Microsoft's Platform SDK page lists the SP1 SDK as the latest. Pffft. I then used Tools/ Options / Directories to tell msdev about include and lib in both msvc6 and the platform SDK. Then I tried building wineruntests. First hitch: error C2065: 'RRF_RT_REG_DWORD' : undeclared identifier Fix: Move Platform SDK higher in the priority list in Tools / Options / Directories. msdev will then use the newer headers, which have that symbol. Second hitch: Linking... uuid.lib(cguid_i.obj) : fatal error LNK1103: debugging information corrupt; recompile module Error executing link.exe. Fix: From http://blogs.msdn.com/stephen_griffin/archive/2006/08/03/building-mfcmapi-w… In the platform SDK's lib directory, rename uuid.lib to uuid.lib.bad. msdev will then use the older library. (Microsoft intentionally removed VC6 support from the newer one, whoops.) Third hitch: http://www.winehq.org/pipermail/wine-patches/2007-September/043988.html introduced a type LSTATUS into winreg.h. This isn't present in the 2003 SP1 platform sdk, nor in the newer 2003 R2 platform SDK, but as long as only our winreg.h uses it, that's fine. Sadly, that patch uses it elsewhere, so compilation breaks. A google search for LSTATUS at microsoft.com finds nothing. Fix: change the LSTATUS in comctl32/tests/mru.c to LONG (gee, maybe we should move the definition of LSTATUS from winreg.h to advapi32/registry.c, too). (But see below.) Fourth hitch: comdlg32\tests\printdlg.c: error C2064: 'LPPRINTDLGEXW' : undeclared identifier Turns out commdlg.h in the platform sdk only defines LPPRINTDLGEXW if STDMETHOD is declared. STDMETHOD is declared in basetyps.h, but including that file makes commdlg.h not even compile. Bleah. Fix: replace the #include "windef.h" ... "winuser.h" with #include "windows.h" in comdlg32/tests/printdlg.h. Fifth hitch: crypt32/tests/cert.c: error C2081: 'HCRYPTPROV_OR_NCRYPT_KEY_HANDLE': name in formal parameter list illegal Turns out that identifier was introduced in Vista, and added to Wine here: http://www.winehq.org/pipermail/wine-patches/2007-August/042250.html Fix: Uninstall the platform SDK and install the Windows SDK! http://www.microsoft.com/downloads/details.aspx?familyid=c2b1e300-f358-4523… Sixth hitch: c:\program files\microsoft sdks\windows\v6.0\include\specstrings.h: fatal error C1083: cannot open include file 'sal.h' I think sal.h comes with Visual Studio 8 and higher. Crap. Thus it looks like you can't build wine's tests with Visual C 6 and the Microsoft headers anymore. So I tried building with the Wine headers. That blows up with "can't find stdio.h". So I'm stuck. What's the recommended way to build the wine test suite with Visual C 6, if any? - Dan

3 5

re: [Patch for Bug 8551] MoveFileWithProgressW unconditional fails for directories with flag MOVEFILE_REPLACE_EXISTING
by Dan Kegel 05 Feb '08

05 Feb '08

James McKenzie wrote: > Please submit a git diff not a UNIX diff. Now, hang on there. Jens submitted a perfectly good unified diff patch taken from the right directory. There is no reason to turn up our noses at it. It will apply using patch in exactly the same way as a diff generated by git. Jens, you're fine, I wouldn't bother rediffing. You might however resend your patch next week when Alexandre the maintainer is back from vacation! - Dan

2 1

Re: added wgl_bind_to_texture_depth_nv to ConvertAttribWGLtoGLX
by Chris Robinson 05 Feb '08

05 Feb '08

On Tuesday 05 February 2008 02:09:09 pm Christopher Harvey wrote: > @@ -758,6 +758,7 @@ static int ConvertAttribWGLtoGLX(const int* iWGLAttr, > int* oGLXAttr, Wine_GLPBuf nvfloatattrib = iWGLAttr[++cur]; > TRACE("pAttr[%d] = WGL_FLOAT_COMPONENTS_NV: %x\n", cur, > nvfloatattrib); break ; > + case WGL_BIND_TO_TEXTURE_DEPTH_NV: > case WGL_BIND_TO_TEXTURE_RGB_ARB: > case WGL_BIND_TO_TEXTURE_RGBA_ARB: > case WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_R_NV: I don't think it's correct to add this since it's not supported (the extension string isn't exported and it can't be easilly emulated). If an app is trying to set that attribute without the extension being advertised, I'd say the app is broken. If you're intending on adding support, you may want to familiarize yourself with how wine emulates render_to_texture and look over the extension: http://opengl.org/registry/specs/NV/render_depth_texture.txt

1 0

Re: added wgl_bind_to_texture_depth_nv to ConvertAttribWGLtoGLX
by Roderick Colenbrander 05 Feb '08

05 Feb '08

> This patch doesn't implement the format, simply says that is can't be > converted. This is my first patch, sorry if the format is wrong. Ok not converting the format is fine but you are also changing the return value of wglMakeCurrent. Resubmit the patch without that unneeded change. Roderick -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

1 0

OUTB() and friends on Win32 and .sys files
by Uwe Bonnes 05 Feb '08

05 Feb '08

Hallo, some programm with source uses giveio.sys to access the parallel port. You can find the source for giveio.sys e.g. in the avrdude package. We have code in dlls/winedos/ppdev.c to emulate the directed access on the parallel port to accesses to /dev/ppdev. However this code is not called for WIN32 code. So after starting giveio with loaddrv.exe supplied with giveio > wine loaddrv.exe start giveio starting giveio... ok. > wine javr.exe crashes when the outb access happens: javr [<filename>] [-p<port>] [-f<fusefilename>] [-e<eepromfilename>] [-L] [-V] Allocated flash buffer of 128K Using giveio.sys to gain port access to 0x378 trace:seh:raise_exception code=c0000096 flags=0 addr=0x4014b6 trace:seh:raise_exception eax=00000000 ebx=00000000 ecx=00000378 edx=00000378 esi=00000378 edi=00110388 trace:seh:raise_exception ebp=0072fe50 esp=0072fe50 cs=0073 ds=007b es=007b fs=0033 gs=003b flags=00010246 trace:seh:call_stack_handlers calling handler at 0x7eddc5bc code=c0000096 flags=0 trace:seh:MSVCRT_signal (4, (nil)) wine: Unhandled privileged instruction at address 0x4014b6 (thread 0011), starting debugger... trace:seh:start_debugger Starting debugger "winedbg --auto 16 56" trace:seh:call_stack_handlers handler at 0x7eddc5bc returned 1 Unhandled exception: privileged instruction in 32-bit code (0x004014b6). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:004014b6 ESP:0072fe50 EBP:0072fe50 EFLAGS:00010246( - 00 -RIZP1) EAX:00000000 EBX:00000000 ECX:00000378 EDX:00000378 ESI:00000378 EDI:00110388 Stack dump: 0x0072fe50: 0072fe58 0040151a 0072fe88 00406ccf 0x0072fe60: 00000378 00000000 00000000 00403411 0x0072fe70: 00000001 00110388 0072fe88 0040a3ef 0x0072fe80: 0040a3ef 00000001 0072fec8 004025e4 0x0072fe90: 00000378 00000378 00110048 0040255c 0x0072fea0: 7ed5ff48 7ffdf000 0072fec8 7ed30f5c Backtrace: =>1 0x004014b6 outb+0x6(value=0x0, port=0x378) [/spare/bon/jtagprog/win/javr-2.8/ppiwin.c:311] in javr (0x0072fe50) MS msvcrt.dll also supplies outb(). What is the policy to handle outb() and friends? Thanks -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Call for winetest ing
by Jeremy White 05 Feb '08

05 Feb '08

Okay, so I got winetest to do something rational, and now I'd like to see if it will work for someone else. It's easy! Just apply this patch to a current Wine tree: http://www.winehq.org/pipermail/wine-patches/2008-February/049675.html Then configure and make Wine as you normally would. Then, cd programs/winetest ./runtests <your-tag-here> (The tag I used was jwhite-etch64; I think you should identify who you are, and then if you have multiple systems, your system within that). If you have winetricks in your path, it should be completely unattended. (If you don't, you'll need to hang around to click 'go' to the Gecko install dialog). After about 5 minutes, your test results should be run and sent up to test.winehq.org. The cron job runs every 5 minutes, so sometime after that, a reload of: firefox http://test.winehq.org/data/`date +%Y%m%d`/ Should show you your results! Easy as Pi! There is still quite a bit to do. First, I'm waiting for a 'real' winetest expert to wack me with a clue bat. But I'll stumble along until the hammer falls... Second, I want to do a stupidity check and make sure that winetest essentially correlates to a make -k test run. If they are not really identical, then we need to fix that problem... Next, I think we should probably shift the build-id from being the date to being the HEAD sha1, but that's a radical enough change that I felt I needed to start simpler and within the current conventions. But I'd really appreciate it if folks could try this and see if we can gather some data quickly. In theory, we should be able to quickly see the common points of failure and know where to attack first. Cheers, Jeremy

5 7

Blocked conformance tests
by Francois Gouget 05 Feb '08

05 Feb '08

When I run winetest on Windows XP I get some dialog boxes asking me: Do you want to keep blocking this program? According to the title bar, the impacted tests are: dplayx rpcrt4 'Microsoft DirectPlay Helper' ??? ws2_32 My understanding is that it should only prevent the test from receiving network connections which I guess is not common. Does anyone know if this could cause any test failure currently? How does XP determine whether to block the test or not? Is the 'authorisation' based on the executable hash? If so there's no way to pre-authorise the tests for nightly tests. Should the winetest mark the executable so it is not hampered by this check? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Linux, WinNT, MS-DOS - also known as the Good, the Bad and the Ugly.

2 1

Re: kernel32: Implement ReplaceFileW. [RESEND]
by Alexandre Julliard 05 Feb '08

05 Feb '08

Robert Shearman <rob(a)codeweavers.com> writes: > + /* > + * Open the replacement file for reading, writing, and deleting > + * (writing and deleting are needed when finished) > + */ > + if ((hReplacement = CreateFileW(lpReplacementFileName, > + GENERIC_READ | GENERIC_WRITE, > + FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE, > + NULL, OPEN_EXISTING, 0, 0)) == INVALID_HANDLE_VALUE) > + { > + error = GetLastError(); /* Use error returned by CreateFileW */ > + goto fail; > + } Files should be opened with NtOpenFile the same way MoveFile does, to avoid having to convert path names twice. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [10/20] WineD3D: Make Clear aware of the depth stencil sharing
by H. Verbeet 05 Feb '08

05 Feb '08

On 05/02/2008, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Stefan already knows this, but just for what it's worth, I've got a more complete fix in my tree for depth stencil sharing. Unfortunately that patch causes a couple of regressions, so it needs more work.

2 2

Re: [7/20] WineD3D: De-Statify depth blit opengl resources
by H. Verbeet 05 Feb '08

05 Feb '08

On 05/02/2008, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > I was aware of this issue, but technically these resources should be stored in the shader backend, not the device.

2 2

running "make test" results in an error
by Christopher 05 Feb '08

05 Feb '08

I tried running "make test" under Ubuntu 7.10, and I just updated to the latest cvs this morning so it's not too old. However, after only running a couple of tests it exited with an error. Is this normal, and if so how do I run the rest of the tests? I attached a log showing which test fails. Christopher make[1]: Entering directory `/home/christopher/wine-git/tools' make[1]: `makedep' is up to date. make[1]: Leaving directory `/home/christopher/wine-git/tools' make[1]: Entering directory `/home/christopher/wine-git/dlls' make[2]: Entering directory `/home/christopher/wine-git/dlls/advapi32/tests' make[2]: Nothing to be done for `test'. make[2]: Leaving directory `/home/christopher/wine-git/dlls/advapi32/tests' make[2]: Entering directory `/home/christopher/wine-git/dlls/advpack/tests' make[2]: Nothing to be done for `test'. make[2]: Leaving directory `/home/christopher/wine-git/dlls/advpack/tests' make[2]: Entering directory `/home/christopher/wine-git/dlls/browseui/tests' make[2]: Nothing to be done for `test'. make[2]: Leaving directory `/home/christopher/wine-git/dlls/browseui/tests' make[2]: Entering directory `/home/christopher/wine-git/dlls/cabinet/tests' make[2]: Nothing to be done for `test'. make[2]: Leaving directory `/home/christopher/wine-git/dlls/cabinet/tests' make[2]: Entering directory `/home/christopher/wine-git/dlls/comcat/tests' make[2]: Nothing to be done for `test'. make[2]: Leaving directory `/home/christopher/wine-git/dlls/comcat/tests' make[2]: Entering directory `/home/christopher/wine-git/dlls/comctl32/tests' make[2]: Nothing to be done for `test'. make[2]: Leaving directory `/home/christopher/wine-git/dlls/comctl32/tests' make[2]: Entering directory `/home/christopher/wine-git/dlls/comdlg32/tests' make[2]: Nothing to be done for `test'. make[2]: Leaving directory `/home/christopher/wine-git/dlls/comdlg32/tests' make[2]: Entering directory `/home/christopher/wine-git/dlls/credui/tests' make[2]: Nothing to be done for `test'. make[2]: Leaving directory `/home/christopher/wine-git/dlls/credui/tests' make[2]: Entering directory `/home/christopher/wine-git/dlls/crypt32/tests' make[2]: Nothing to be done for `test'. make[2]: Leaving directory `/home/christopher/wine-git/dlls/crypt32/tests' make[2]: Entering directory `/home/christopher/wine-git/dlls/cryptnet/tests' make[2]: Nothing to be done for `test'. make[2]: Leaving directory `/home/christopher/wine-git/dlls/cryptnet/tests' make[2]: Entering directory `/home/christopher/wine-git/dlls/d3d8/tests' make[2]: Nothing to be done for `test'. make[2]: Leaving directory `/home/christopher/wine-git/dlls/d3d8/tests' make[2]: Entering directory `/home/christopher/wine-git/dlls/d3d9/tests' ../../../tools/runtest -q -P wine -M d3d9.dll -T ../../.. -p d3d9_test.exe.so device.c && touch device.ok fixme:win:EnumDisplayDevicesW ((null),0,0x34f8c0,0x00000000), stub! fixme:d3d:IWineD3DDeviceImpl_CreateAdditionalSwapChain The app requests more than one back buffer, this can't be supported properly. Please configure the application to use double buffering(=1 back buffer) if possible err:xrandr:X11DRV_XRandR_SetCurrentMode Resolution change not successful -- perhaps display has changed? device.c:753: Test failed: Screen width is 1680 device.c:754: Test failed: Screen height is 1050 err:xrandr:X11DRV_XRandR_SetCurrentMode Resolution change not successful -- perhaps display has changed? device.c:798: Test failed: Screen width is 1680 device.c:799: Test failed: Screen height is 1050 err:d3d:IWineD3DDeviceImpl_DrawIndexedPrimitive (0x144548) : Called without a valid index buffer set, returning WINED3DERR_INVALIDCALL fixme:d3d:SetupForBlit >>>>>>>>>>>>>>>>> GL_INVALID_VALUE (0x501) from glOrtho @ context.c / 622 fixme:d3d_surface:flush_to_framebuffer_drawpixels >>>>>>>>>>>>>>>>> GL_INVALID_VALUE (0x501) from glDrawPixels @ surface.c / 1061 fixme:d3d:transform_projection >>>>>>>>>>>>>>>>> GL_INVALID_VALUE (0x501) from glOrtho @ state.c / 2802 fixme:d3d_surface:flush_to_framebuffer_drawpixels >>>>>>>>>>>>>>>>> GL_INVALID_VALUE (0x501) from glDrawPixels @ surface.c / 1061 fixme:d3d:IWineD3DDeviceImpl_SetLightEnable Too many concurrently active lights make[2]: *** [device.ok] Error 4 make[2]: Leaving directory `/home/christopher/wine-git/dlls/d3d9/tests' make[1]: *** [d3d9/tests/__test__] Error 2 make[1]: Leaving directory `/home/christopher/wine-git/dlls' make: *** [dlls/__test__] Error 2

4 3

Re: kernel32: Add tests for LoadLibraryEx
by Alexandre Julliard 05 Feb '08

05 Feb '08

"James Hawkins" <truiken(a)gmail.com> writes: > I'm not sure how you feel this should be fixed. Is there a reason we > don't have tests for ntdll/loader.c? If not, I'd like add some tests > for LdrLoadDll. We don't have tests for it because apps don't use LdrLoadDll, so testing LoadLibraryEx should be enough. Of course if you have an app that depends on a specific behavior of LdrLoadDll then this should be tested. The todo in your test is because builtin dlls are supposed to get loaded even if the corresponding native file doesn't exist, that's a feature. -- Alexandre Julliard julliard(a)winehq.org

1 0

comctl32 failures on Win95, Win98, NT4 asnd Win2K
by Reece Dunn 05 Feb '08

05 Feb '08

These tests are all failing consistently with identical failures on these platforms: combobox - 21 failures; all identical across the platforms. datetime - 2 failures; all identical across the platforms. The rebar tests have 146 failures on some (Win95 and NT4) and 545 failures on others (Win98 and Win2K). This looks like it is due to a different comctl32 version as a result of a different IE version. Several of the others have failures on Win95 and Win98 only. Is anyone going to look at these? - Reece

3 2

Re: d3dx9_36: Implementation of D3DXCheckVersion try 2
by tony.wasserka＠freenet.de 05 Feb '08

05 Feb '08

Oh well, I forgot one point: if you take my example code again, but don't build it under winelib but under windows (i.e. it's a real win application) but later run it with wine it may also fail because all dlls forward to the D3DXCheckVersion of d3dx9_36. I know that you would have implemented another D3DXCheckVersion for each dll, but this again would've ended in the case I mentioned in the first e-mail. Unbegrenzter Speicher, Top-Spamschutz, 120 SMS und eigene E-MailDomain inkl. http://office.freenet.de/dienste/emailoffice/produktuebersicht/power/mail/i…

1 0

Re: d3dx9_36: Implementation of D3DXCheckVersion try 2
by tony.wasserka＠freenet.de 05 Feb '08

05 Feb '08

I probably should've gone into a bit more detail about this function: It's just for developer purpose. If you have a very big project and are trying to upgrade e.g. from d3dx9_27 to d3dx9_36 some files may need to be rebuild, some files may not. This function is just there to ensure the developer that all files are built with the right dll. Now THIS means, that we won't ever see an ENDUSER application fail because of a d3dx9 version mismatch. Also, we come to a problem when a user wants to built an application with Winelib, where we can only use one definition of D3DX_SDK_VERSION which only applies to ONE dll. Now just watch following code sample: > #include "d3dx9.h" > > int check_version() { > if( D3DXCheckVersion( D3D_SDK_VERSION, D3DX_SDK_VERSION ) == FALSE ) { > MessageBox( NULL, "D3DX9 Versions don't match!", "Error!", MB_OK ); > exit( 1 ); > } > } Now, if a Winelib user compiles this, D3DX_SDK_VERSION is 9 (as its specified in our current d3dx9core.h). But if the program requires to be built with d3dx9_36 (and thus uses our implementation of D3DXCheckVersion) it will report an error as D3DX_SDK_VERSION was expected to be 36. So, the only thing we can test in this function is if D3DX_SDK_VERSION is between 24 and 36, which are all compatible versions (also, no enduser application will need the accurate implementation as stated above). I have made a mistake though, when I defined D3DX_SDK_VERSION to be 9, which was caused by my somewhat old installation of the DX SDK, which is incompatible with d3dx9_24 to d3dx9_36. (it was statically linked at that time), You don't need correct this in your patch, as this will be addressed in one of my future patches, I am just waiting for Julliard to (hopefully) accept my d3dx9_24 patch. In conclusion, all you have to do is replace the line > return ((D3DSdkVersion==D3D_SDK_VERSION) && (D3DXSdkVersion==D3DX_SDK_VERSION)); with > return ((D3DSdkVersion==D3D_SDK_VERSION) && (D3DXSdkVersion>=24 && D3DXSdkVersion <=36)); (Could also be => and =<, ain't that familiar with it) Best regards, Tony

1 0

winetest experience
by Jeremy White 05 Feb '08

05 Feb '08

Okay, so I boldly tried to use winetest with what documentation I could find, and had an...um...interesting time. I created these files: [jertop] cat build.id fcccd9fca605d1d4c462df5c33f4bacf03bdda5f [jertop] cat build.nfo A Large Shovel [jertop] cat tests.url http://www.IDontKnowWhatURLToPutHere.com/ [jertop] did a make dist, and then did: ./winetest -c -t "jw-etch32" It ran, did it's thing, and had one interactive thing (Gecko fussed at me; that's not a Winetest bug afaik). Then when it was all done, it transferred my nearly 1 MB file, and then errored out with: "Unknown build id" So then I looked at the output file, and sure enough, it had a - for build info, not my fancy git id. So I hacked that, put in jwtip, and then ran winetest -s to send my output file through. And then I have a lovely result here: http://test.winehq.org/data/jwtip/ So that's *something* at least. Although I suspect someone will now have to go clean up my mess :-/. So...what's the convention for build.id etc? And why didn't they get set? Cheers, Jeremy

2 2

[Fwd: d3dx8: Implement D3DXCreateTextureFromFile]
by "Luis C. Busquets Pérez" 04 Feb '08

04 Feb '08

I have created a /dlls/d3dx8/texture.c file where to put all functions related to textures and d3dx8. I have included D3DXIMAGE_FILEFORMAT in the patch because it is referred by D3DXIMAGE_FILEFORMAT which is referred in the function. If not included, it would not compile. They both are now in /include/d3dx8.h whci I think is the appropiate file. Do you propose to put them elsewhere? Do you think I am missing anything or is it ok?

2 2

re: running "make test" results in an error
by Dan Kegel 04 Feb '08

04 Feb '08

Christopher raccoonone at procyongames.com wrote: >I tried running "make test" under Ubuntu 7.10, and I just updated to the >latest cvs this morning so it's not too old. However, after only running >a couple of tests it exited with an error. Is this normal Sadly, yes. See http://bugs.winehq.org/show_bug.cgi?id=9916 Believe it or not, the situation was much worse five months ago. At the last Wineconf, Jeremy White got everybody to spend a whole day just fixing test failures. We could use something like that again. > and if so how do I run the rest of the tests? Elementary, my dear Watson. "make -k test". - Dan

2 1

winedbg pdb issue - n00b
by Michel Jacques 04 Feb '08

04 Feb '08

Hi. I've have setup my debug build (with pdbs) and MSVCRT debug dlls. When stopping on a breakpoint with winedbg, I get a stack of calls in winedbg which does not contains any function info from my dlls or app. I only get hex offset of call within my dll. But I do see the information for wine sources though, function name + line number. What do I need to do so that winedbg can extract info from my pdb? Thanks, Michel Découvrez les styles qui font sensation sur Yahoo! Québec Avatars. http://cf.avatars.yahoo.com/

2 1

attempt to install Wine from source
by Mike Harrison 04 Feb '08

04 Feb '08

Dear Sir; This below is the config.log I got from trying to install Wine (a source archive from a British Linux mag) on to my AMD64 m/c under Debian 4.0. 64 bit OS. A similar message was obtained from an attempt to install Wine on my AMD64 laptop under Ubuntu 7.04. (not 64 bit). From the report log I can't identify just what went wrong. My aim is to use Wine to run Windows XP applications on both machines, and if possible Windows Vista applic'ns on the laptop - both machines running 32 bit applic'ns. My first priority for this is MS Excel XP pro. From a brief visit to WineHQ today (the connection died for some unknown reason) I believe it may not be as straightforward a project as I had hoped. Please tell me either what I must do to load/install my Wine source package, or where I have to go for help to go a little further. I prefer to load the sources I already have, plus supplementary programs, if that's possible. Any advice you can give would be appreciated. Thanks; Mike Harrison This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by Wine configure 20050830, which was generated by GNU Autoconf 2.59. Invocation command line was $ ./configure -C --prefix=/usr/local ## --------- ## ## Platform. ## ## --------- ## hostname = ultima uname -m = x86_64 uname -r = 2.6.18-4-amd64 uname -s = Linux uname -v = #1 SMP Mon Mar 26 11:36:53 CEST 2007 /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = x86_64 /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /usr/local/bin PATH: /usr/bin PATH: /bin PATH: /usr/bin/X11 PATH: /usr/games ## ----------- ## ## Core tests. ## ## ----------- ## configure:1249: creating cache config.cache configure:1424: checking build system type configure:1442: result: x86_64-unknown-linux-gnu configure:1450: checking host system type configure:1464: result: x86_64-unknown-linux-gnu configure:1504: checking whether make sets $(MAKE) configure:1524: result: yes configure:1579: checking for gcc configure:1605: result: gcc -m32 configure:1849: checking for C compiler version configure:1852: gcc -m32 --version </dev/null >&5 ./configure: line 1853: gcc: command not found configure:1855: $? = 127 configure:1857: gcc -m32 -v </dev/null >&5 ./configure: line 1858: gcc: command not found configure:1860: $? = 127 configure:1862: gcc -m32 -V </dev/null >&5 ./configure: line 1863: gcc: command not found configure:1865: $? = 127 configure:1888: checking for C compiler default output file name configure:1891: gcc -m32 conftest.c >&5 ./configure: line 1892: gcc: command not found configure:1894: $? = 127 configure: failed program was: | /* confdefs.h. */ | | #define PACKAGE_NAME "Wine" | #define PACKAGE_TARNAME "wine" | #define PACKAGE_VERSION "20050830" | #define PACKAGE_STRING "Wine 20050830" | #define PACKAGE_BUGREPORT "wine-devel(a)winehq.org" | /* end confdefs.h. */ | | int | main () | { | | ; | return 0; | } configure:1933: error: C compiler cannot create executables See `config.log' for more details. ## ---------------- ## ## Cache variables. ## ## ---------------- ## ac_cv_build=x86_64-unknown-linux-gnu ac_cv_build_alias=x86_64-unknown-linux-gnu ac_cv_env_CC_set= ac_cv_env_CC_value= ac_cv_env_CFLAGS_set= ac_cv_env_CFLAGS_value= ac_cv_env_CPPFLAGS_set= ac_cv_env_CPPFLAGS_value= ac_cv_env_CPP_set= ac_cv_env_CPP_value= ac_cv_env_CXXFLAGS_set= ac_cv_env_CXXFLAGS_value= ac_cv_env_CXX_set= ac_cv_env_CXX_value= ac_cv_env_LDFLAGS_set= ac_cv_env_LDFLAGS_value= ac_cv_env_build_alias_set= ac_cv_env_build_alias_value= ac_cv_env_host_alias_set= ac_cv_env_host_alias_value= ac_cv_env_target_alias_set= ac_cv_env_target_alias_value= ac_cv_host=x86_64-unknown-linux-gnu ac_cv_host_alias=x86_64-unknown-linux-gnu ac_cv_prog_ac_ct_CC='gcc -m32' ac_cv_prog_make_make_set=yes ## ----------------- ## ## Output variables. ## ## ----------------- ## ALSALIBS='' AR='' ARTSCCONFIG='' ARTSINCL='' ARTSLIBS='' AS='as --32' AUDIOIOLIBS='' BISON='' BUILTINFLAG='' CC='gcc -m32' CFLAGS='' COREFOUNDATIONLIB='' CPP='' CPPBIN='' CPPFLAGS='' CROSSCC='' CROSSTEST='' CROSSWINDRES='' CRTLIBS='' CURSESLIBS='' CXX='' CXXFLAGS='' DEFS='' DLLDEFS='' DLLEXT='' DLLFLAGS='' DLLIBS='' DLLTOOL='' DLLWRAP='' ECHO_C='' ECHO_N='-n' ECHO_T='' EGREP='' ESDCONFIG='' ESDINCL='' ESDLIBS='' EXEEXT='' EXTRACFLAGS='' FONTFORGE='' FONTSSUBDIRS='' FREETYPEINCL='' FREETYPELIBS='' GLU32FILES='' GLUT32FILES='' GLUT_LIBS='' ICULIBS='' IMPLIBEXT='' INSTALL_DATA='' INSTALL_PROGRAM='' INSTALL_SCRIPT='' IOKITLIB='' LCMSLIBS='' LD='ld -m elf_i386' LDAPLIBS='' LDCONFIG='' LDD='' LDDLLFLAGS='' LDEXECFLAGS='' LDFLAGS='' LDLIBWINEFLAGS='' LDPATH='' LDSHARED='' LEX='' LEXLIB='' LEX_OUTPUT_ROOT='' LIBEXT='' LIBOBJS='' LIBPTHREAD='' LIBS='' LINT='' LINTFLAGS='' LN='' LN_S='' LTLIBOBJS='' MAIN_BINARY='' NASLIBS='' OBJEXT='' OPENGLFILES='' OPENGL_LIBS='' PACKAGE_BUGREPORT='wine-devel(a)winehq.org' PACKAGE_NAME='Wine' PACKAGE_STRING='Wine 20050830' PACKAGE_TARNAME='wine' PACKAGE_VERSION='20050830' PATH_SEPARATOR=':' PKG_CONFIG='' PRELINK='' RANLIB='' SANEINCL='' SANELIBS='' SET_MAKE='' SHELL='/bin/sh' SOCKETLIBS='' STRIP='' TOOLSDIR='' WIN16_FILES='$(WIN16_FILES)' WIN16_INSTALL='$(WIN16_INSTALL)' WINDRES='' WINE_BINARIES='' XFILES='' XLEX='' XLIB='' XML2INCL='' XML2LIBS='' X_CFLAGS='' X_EXTRA_LIBS='' X_LIBS='' X_PRE_LIBS='' ac_ct_AR='' ac_ct_AS='' ac_ct_CC='gcc -m32' ac_ct_CPPBIN='' ac_ct_CXX='' ac_ct_DLLTOOL='' ac_ct_DLLWRAP='' ac_ct_LD='' ac_ct_RANLIB='' ac_ct_STRIP='' ac_ct_WINDRES='' bindir='${exec_prefix}/bin' build='x86_64-unknown-linux-gnu' build_alias='' build_cpu='x86_64' build_os='linux-gnu' build_vendor='unknown' datadir='${prefix}/share' exec_prefix='NONE' ft_devel2='' ft_devel='' host='x86_64-unknown-linux-gnu' host_alias='' host_cpu='i386' host_os='linux-gnu' host_vendor='unknown' includedir='${prefix}/include' infodir='${prefix}/info' libdir='${exec_prefix}/lib' libexecdir='${exec_prefix}/libexec' localstatedir='${prefix}/var' mandir='${prefix}/man' oldincludedir='/usr/include' prefix='/usr/local' program_transform_name='s,x,x,' sane_devel='' sbindir='${exec_prefix}/sbin' sharedstatedir='${prefix}/com' sysconfdir='${prefix}/etc' target_alias='' ## ------------- ## ## Output files. ## ## ------------- ## MAKE_DLL_RULES='' MAKE_IMPLIB_RULES='' MAKE_LIB_RULES='' MAKE_PROG_RULES='' MAKE_RULES='' MAKE_TEST_RULES='' ## ----------- ## ## confdefs.h. ## ## ----------- ## #define PACKAGE_BUGREPORT "wine-devel(a)winehq.org" #define PACKAGE_NAME "Wine" #define PACKAGE_STRING "Wine 20050830" #define PACKAGE_TARNAME "wine" #define PACKAGE_VERSION "20050830" configure: exit 77

4 3

winehq.org down?
by James Hawkins 04 Feb '08

04 Feb '08

Hey guys, I'm having problems connecting to the winehq.org server. Is this a known issue? -- James Hawkins

6 6

cabinet: Include wine/port.h for strcasecmp().
by Kirill K. Smirnov 03 Feb '08

03 Feb '08

>The rules are as follows: > * For case insensitive comparisons of 'windows strings', a Windows > function must be used (stricmp() or similar). and >In this case, KERNEL32 lstrcmpiA() would be more appropriate. In >general, using stricmp() in Win32 code should be discouraged since it >may cause unnecessary dependency on MSVCRT. Wine lstrcmpi is broken (bug #10767). There are cases GLIBC strcasecmp and Windows lstrcmpi handle correctly but wine not. Should we fix this first? -- Kirill

2 1

Re: winex11.drv: Use bitwise NOT not logical NOT
by Marcus Meissner 02 Feb '08

02 Feb '08

On Sat, Feb 02, 2008 at 05:43:27PM +0000, Andrew Talbot wrote: > Changelog: > winex11.drv: Use bitwise NOT not logical NOT. > > diff --git a/dlls/winex11.drv/settings.c b/dlls/winex11.drv/settings.c > index d68b674..2cd36c7 100644 > --- a/dlls/winex11.drv/settings.c > +++ b/dlls/winex11.drv/settings.c > @@ -369,10 +369,10 @@ LONG X11DRV_ChangeDisplaySettingsEx( LPCWSTR devname, LPDEVMODEW devmode, > devmode->dmBitsPerPel,devmode->dmDisplayFrequency, handler_name); > > dwBpp = devmode->dmBitsPerPel; > - if (devmode->dmFields & DM_BITSPERPEL) def_mode &= !dwBpp; > - if (devmode->dmFields & DM_PELSWIDTH) def_mode &= !devmode->dmPelsWidth; > - if (devmode->dmFields & DM_PELSHEIGHT) def_mode &= !devmode->dmPelsHeight; > - if (devmode->dmFields & DM_DISPLAYFREQUENCY) def_mode &= !devmode->dmDisplayFrequency; > + if (devmode->dmFields & DM_BITSPERPEL) def_mode &= ~dwBpp; > + if (devmode->dmFields & DM_PELSWIDTH) def_mode &= ~devmode->dmPelsWidth; > + if (devmode->dmFields & DM_PELSHEIGHT) def_mode &= ~devmode->dmPelsHeight; > + if (devmode->dmFields & DM_DISPLAYFREQUENCY) def_mode &= ~devmode->dmDisplayFrequency; I do not think this is right, def_mode is a boolean and we actually check for not-0-being of various struct members. Ciao, Marcus

3 3

Re: cabinet: Include wine/port.h for strcasecmp().
by Dmitry Timoshkov 01 Feb '08

01 Feb '08

"Bang Jun-young" <junyoung(a)mogua.com> wrote: >> > cabinet: Include wine/port.h for strcasecmp(). >> >> If a Wine DLL uses strcasecmp() then it's a bug. It should >> use an appropriate kernel32 API instead. > > I know, but it's too late. The tree is already contaminated with such > functions and quite a number of other unnecessary Wine-specific APIs > which shouldn't have been in the first place. It doesn't mean that instead of replacing them you can simply make an impression that it's OK to just hide the bug. -- Dmitry.

3 2

What's needed to make gdb work again?
by Maarten Lankhorst 01 Feb '08

01 Feb '08

Hi folks, I've been trying some debugging with kdbg (Graphical kde debugger), but it fails on wine because it can't attach to a process. While it is of course possible to use WINEDEBUG flags, I want to be able to use a full debugger, and not just deduce from logs what happened, but rather be able to see the corresponding lines of source as well. so would it be possible to make gdb work with winedbg again, and perhaps make it understand threads this time? Cheers, Maarten.

2 1

test.winehq.org
by Stefan Leichter 01 Feb '08

01 Feb '08

Hello, i just noticed that the test results for advapi32:service tests are not available for the last build (http://test.winehq.org/data/200801301937/). It looks like the parser did not create the files. Can someone familar with this stuff have a look? Thanks Stefan

4 4

Review comparing Wine and Vista for running games
by Dan Kegel 01 Feb '08

01 Feb '08

http://wastingtimewithmikeandari.wordpress.com/2008/01/31/linux-has-better-… It'd be nice if we ran those games properly, but still, at least we didn't lock the system.

3 2

Re: cabinet: Include wine/port.h for strcasecmp().
by Dmitry Timoshkov 01 Feb '08

01 Feb '08

"Bang Jun-young" <junyoung(a)mogua.com> wrote > cabinet: Include wine/port.h for strcasecmp(). If a Wine DLL uses strcasecmp() then it's a bug. It should use an appropriate kernel32 API instead. -- Dmitry.

1 0

Re: qmgr: Implement DLL server registration.
by Roderick Colenbrander 31 Jan '08

31 Jan '08

If possible you should do the registration in the same way as windows as we try to be like windows in every way. Depending on the dll the settings are either hardcoded in a dll (that's what most dlls do) or when it are default windows dlls the keys are stored in wine.inf. In case of your dll I guess it should be hardcoded. Shipping extra files puts an extra burden on packagers and it likely isn't what windows is doing. Regards, Roderick > I like the way Roy used a .INF file for the DLL server registration. > Looking > at some of the other DLL's code, this seems comparably like a very clean > idea. > > ChangeLog: > > Add the server registration code to qmgr. > > From: Roy Shea <roy at cs.hmc.edu> > Date: Thu Dec 20 18:38:31 CST 2007 > > --- > dlls/qmgr/Makefile.in | 4 ++- > dlls/qmgr/qmgr.h | 11 ++++++ > dlls/qmgr/qmgr.inf | 31 ++++++++++++++++ > dlls/qmgr/qmgr.spec | 4 +- > dlls/qmgr/qmgr_main.c | 92 > +++++++++++++++++++++++++++++++++++++++++++++++-- > dlls/qmgr/rsrc.rc | 20 +++++++++++ > 6 files changed, 156 insertions(+), 6 deletions(-) > create mode 100644 dlls/qmgr/qmgr.inf > create mode 100644 dlls/qmgr/rsrc.rc > > diff --git a/dlls/qmgr/Makefile.in b/dlls/qmgr/Makefile.in > index a19eea6..7159607 100644 > --- a/dlls/qmgr/Makefile.in > +++ b/dlls/qmgr/Makefile.in > @@ -3,7 +3,7 @@ TOPOBJDIR = ../.. > SRCDIR = @srcdir@ > VPATH = @srcdir@ > MODULE = qmgr.dll > -IMPORTS = kernel32 > +IMPORTS = advpack kernel32 > EXTRALIBS = -luuid > > C_SRCS = \ > @@ -11,6 +11,8 @@ C_SRCS = \ > qmgr.c \ > qmgr_main.c > > +RC_SRCS = rsrc.rc > + > IDL_I_SRCS = qmgr_local.idl > > @MAKE_DLL_RULES@ > diff --git a/dlls/qmgr/qmgr.h b/dlls/qmgr/qmgr.h > index 9b708c8..3ad314d 100644 > --- a/dlls/qmgr/qmgr.h > +++ b/dlls/qmgr/qmgr.h > @@ -27,6 +27,8 @@ > #define COBJMACROS > #include "bits.h" > > +#include <string.h> > + > /* Background copy manager vtbl and related data */ > typedef struct > { > @@ -43,4 +45,13 @@ extern ClassFactoryImpl BITS_ClassFactory; > > HRESULT BackgroundCopyManagerConstructor(IUnknown *pUnkOuter, LPVOID > *ppObj); > > +/* Little helper functions */ > +static inline char * > +qmgr_strdup(const char *s) > +{ > + size_t n = strlen(s) + 1; > + char *d = HeapAlloc(GetProcessHeap(), 0, n); > + return d ? memcpy(d, s, n) : NULL; > +} > + > #endif /* __QMGR_H__ */ > diff --git a/dlls/qmgr/qmgr.inf b/dlls/qmgr/qmgr.inf > new file mode 100644 > index 0000000..0550f01 > --- /dev/null > +++ b/dlls/qmgr/qmgr.inf > @@ -0,0 +1,31 @@ > +[version] > +Signature="$CHICAGO$" > + > + > +[Strings] > +Services="System\CurrentControlSet\Services" > + > + > +[RegisterDll] > +AddReg = Qmgr.Reg > + > + > +[UnregisterDll] > +DelReg = Qmgr.Reg > + > + > +[Qmgr.Reg] > + > +HKCR,"AppID\BITS","AppID",,"%CLSID_BackgroundCopyQMgr%" > +HKCR,"AppID\%CLSID_BackgroundCopyQMgr%","LocalService",,"BITS" > +HKCR,"CLSID\%CLSID_BackgroundCopyManager%","AppID",,"%CLSID_BackgroundCopyQMgr%" > + > +HKLM,"Software\Microsoft\Windows > NT\CurrentVersion\SvcHost","netsvcs",0x00010000,"BITS" > + > +HKLM,"%Services%\BITS","Type",0x00010001,00000110 > +HKLM,"%Services%\BITS","Start",0x00010001,00000003 > +HKLM,"%Services%\BITS","ErrorControl",0x00010001,00000001 > +HKLM,"%Services%\BITS","Description",,"BITS Service" > +HKLM,"%Services%\BITS","DispalyName",,"BITS" > +HKLM,"%Services%\BITS","ImagePath",0x00020000,"svchost.exe -k netsvcs" > +HKLM,"%Services%\BITS\Parameters","ServiceDll",0x00020000,"qmgr.dll" > diff --git a/dlls/qmgr/qmgr.spec b/dlls/qmgr/qmgr.spec > index 1a63b32..0f9b073 100644 > --- a/dlls/qmgr/qmgr.spec > +++ b/dlls/qmgr/qmgr.spec > @@ -1,2 +1,2 @@ > -@ stub DllRegisterServer > -@ stub DllUnregisterServer > +@ stdcall -private DllRegisterServer() > +@ stdcall -private DllUnregisterServer() > diff --git a/dlls/qmgr/qmgr_main.c b/dlls/qmgr/qmgr_main.c > index d00ac2d..2bb5258 100644 > --- a/dlls/qmgr/qmgr_main.c > +++ b/dlls/qmgr/qmgr_main.c > @@ -21,15 +21,27 @@ > * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, > USA > */ > > -#include <stdarg.h> > +#include <stdio.h> > > -#include "windef.h" > -#include "winbase.h" > +#include "objbase.h" > +#include "winuser.h" > +#include "winreg.h" > +#include "advpub.h" > + > +#include "bits.h" > +#include "qmgr.h" > +#include "initguid.h" > > #include "wine/debug.h" > > WINE_DEFAULT_DEBUG_CHANNEL(qmgr); > > +/* Handle to the base address of this DLL */ > +static HINSTANCE hInst; > + > +/* Other GUIDs used by this module */ > +DEFINE_GUID(CLSID_BackgroundCopyQMgr, 0x69AD4AEE, 0x51BE, 0x439b, > 0xA9,0x2C, 0x86,0xAE,0x49,0x0E,0x8B,0x30); > + > /* Entry point for DLL */ > BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID > lpvReserved) > { > @@ -41,6 +53,7 @@ BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, > LPVOID lpvReserved) > return FALSE; /* prefer native version */ > case DLL_PROCESS_ATTACH: > DisableThreadLibraryCalls(hinstDLL); > + hInst = hinstDLL; > break; > case DLL_PROCESS_DETACH: > break; > @@ -48,3 +61,76 @@ BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD > fdwReason, LPVOID lpvReserved) > > return TRUE; > } > + > +static HRESULT init_register_strtable(STRTABLEA *strtable) > +{ > + #define CLSID_EXPANSION_ENTRY(id) { "CLSID_" #id, &CLSID_ ## id } > + static const struct { > + const char *name; > + const CLSID *clsid; > + } expns[] = { > + CLSID_EXPANSION_ENTRY(BackgroundCopyQMgr), > + CLSID_EXPANSION_ENTRY(BackgroundCopyManager) > + }; > + #undef CLSID_EXPANSION_ENTRY > + static STRENTRYA pse[sizeof expns / sizeof expns[0]]; > + int i; > + > + strtable->cEntries = sizeof pse / sizeof pse[0]; > + strtable->pse = pse; > + for (i = 0; i < strtable->cEntries; i++) { > + static const char dummy_sample[] = > "{12345678-1234-1234-1234-123456789012}"; > + const CLSID *clsid = expns[i].clsid; > + pse[i].pszName = qmgr_strdup(expns[i].name); > + pse[i].pszValue = HeapAlloc(GetProcessHeap(), 0, sizeof > dummy_sample); > + if (!pse[i].pszName || !pse[i].pszValue) > + return E_OUTOFMEMORY; > + sprintf(pse[i].pszValue, > "{%08X-%04X-%04X-%02X%02X-%02X%02X%02X%02X%02X%02X}", > + clsid->Data1, clsid->Data2, clsid->Data3, > clsid->Data4[0], > + clsid->Data4[1], clsid->Data4[2], clsid->Data4[3], > clsid->Data4[4], > + clsid->Data4[5], clsid->Data4[6], clsid->Data4[7]); > + } > + > + return S_OK; > +} > + > +static void cleanup_register_strtable(STRTABLEA *strtable) > +{ > + int i; > + for (i = 0; i < strtable->cEntries; i++) { > + HeapFree(GetProcessHeap(), 0, strtable->pse[i].pszName); > + HeapFree(GetProcessHeap(), 0, strtable->pse[i].pszValue); > + if (!strtable->pse[i].pszName || !strtable->pse[i].pszValue) > + return; > + } > +} > + > +/* Use an INF file to register or unregister the DLL */ > +static HRESULT register_server(BOOL do_register) > +{ > + HRESULT hr; > + STRTABLEA strtable; > + > + TRACE("(%x)\n", do_register); > + > + hr = init_register_strtable(&strtable); > + if (SUCCEEDED(hr)) > + hr = RegInstallA(hInst, do_register ? "RegisterDll" : > "UnregisterDll", > + &strtable); > + cleanup_register_strtable(&strtable); > + > + if (FAILED(hr)) > + ERR("failed: %08x\n", hr); > + > + return hr; > +} > + > +HRESULT WINAPI DllRegisterServer() > +{ > + return register_server(TRUE); > +} > + > +HRESULT WINAPI DllUnregisterServer() > +{ > + return register_server(FALSE); > +} > diff --git a/dlls/qmgr/rsrc.rc b/dlls/qmgr/rsrc.rc > new file mode 100644 > index 0000000..dfc64d0 > --- /dev/null > +++ b/dlls/qmgr/rsrc.rc > @@ -0,0 +1,20 @@ > +/* > + * Copyright 2007 Google (Roy Shea) > + * > + * This library is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. > + * > + * This library is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this library; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, > USA > + */ > + > +/* @makedep: qmgr.inf */ > +REGINST REGINST qmgr.inf > -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

2 1

Is http://test.winehq.org down?
by Reece Dunn 31 Jan '08

31 Jan '08

Hi, I an getting a network timeout whern connecting to http://test.winehq.org. - Reece

1 1

No new winetest?
by Francois Gouget 31 Jan '08

31 Jan '08

There's been no new winetest for about a week. Does anyone know what's up? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Linux: Because rebooting is for adding new hardware

3 4

Wiki Down?
by Austin English 31 Jan '08

31 Jan '08

What happened to the wiki? AppDB/WineHQ/Bugzilla are all fine, but wiki.winehq.org seems to be down. -Austin

4 4

windows xp x64
by EA Durbin 31 Jan '08

31 Jan '08

I'm trying to install a game (Zoo Tycoon2) for my little sisters on my Dad's PC, it's running Windows XP pro x64 edition, which gets recognized as Windows Server 2003. The install is complaining about needing Windows XP to install the game and VMWare only has 16mb of video card emulated. Can I run it in wine on Windows, or is there a cool way to spoof my Windows version under Windows? _________________________________________________________________ Helping your favorite cause is as easy as instant messaging. You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join

1 1

[Fwd: [PATCH] This is an update to riched20 to incorporate EM_FONTRANGE based upon 0.9.54.]
by James McKenzie 31 Jan '08

31 Jan '08

Please delete this patch. It is incomplete and I will submit a new one. -------- Original Message -------- Subject: [PATCH] This is an update to riched20 to incorporate EM_FONTRANGE based upon 0.9.54. Date: Mon, 28 Jan 2008 22:17:39 -0700 From: James McKenzie <jjmckenzie51(a)earthlink.net> To: wine-patches(a)winehq.org --- dlls/riched20/context.c | 16 ++ dlls/riched20/editor.c | 9 + dlls/riched20/editor.h | 12 ++ dlls/riched20/list.c | 153 +++++++++++++++++++++ dlls/riched20/paint.c | 312 +++++++++++++++++++++++++++++++++++++++++- dlls/riched20/run.c | 33 ++++ dlls/riched20/style.c | 113 +++++++++++---- dlls/riched20/tests/editor.c | 16 +- dlls/riched20/wrap.c | 23 +++ 9 files changed, 627 insertions(+), 60 deletions(-) This is based upon Lei Zhang's November patch.

1 0

Re: commdlg: PrintDlg16: Handle print quality combobox (try2)
by Detlef Riekenberg 31 Jan '08

31 Jan '08

On Mi, 2008-01-30 at 13:48 +0100, Alexander Nicolaysen Sørnes wrote: > + printf("CCC %d\n", lpdm->u1.s1.dmPrintQuality); This looks like debug code -- By by ... Detlef

2 1

Re: 2/2 start.exe: Handle the process title argument (try3)
by Dmitry Timoshkov 30 Jan '08

30 Jan '08

"Alexander Nicolaysen Sørnes" <alex(a)thehandofagony.com> wrote: > try 2 (thanks to Dmitry & Detlef) > > - Use GlobalFree instead of LocalFree > - Fix indentation > - Remove part of a comment > > try 3 > - Use LocalFree, fixing CommandLineToargvW first The following question from my original review still has not been answered: wmain() already has arc/argv pair of parameters, why do you need to parse command line again? -- Dmitry.

2 1

Re: d3dx9: Implement D3DXGetShaderVersion
by Stefan Dösinger 30 Jan '08

30 Jan '08

Am Dienstag, 29. Januar 2008 20:32:52 schrieb Luis C. Busquets Pérez: > --- > dlls/d3dx9_36/Makefile.in | 3 ++- > dlls/d3dx9_36/d3dx9_36.spec | 2 +- > dlls/d3dx9_36/shader.c | 31 +++++++++++++++++++++++++++++++ > 3 files changed, 34 insertions(+), 2 deletions(-) > create mode 100644 dlls/d3dx9_36/shader.c I think you should write a TRACE to allow better debugging

1 0

Re: Add GdipSetStringFormatFlags stub
by Dmitry Timoshkov 30 Jan '08

30 Jan '08

"Alistair Leslie-Hughes" <leslie_alistair(a)hotmail.com> wrote: > +GpStatus WINGDIPAPI GdipSetStringFormatFlags(GDIPCONST GpStringFormat *format, INT flags) > +{ > + FIXME("format (%d) flags (%d)\n", (int)(format), flags); Please try to avoid the casts in traces, especially casting a pointer to an int, use appropriate format specifier instead. This applies also to your "gdiplus: Add GdipSetPenMode stub" patch. -- Dmitry.

1 0

Re: start.exe: Handle the process title argument (try2)
by Dmitry Timoshkov 29 Jan '08

29 Jan '08

"Alexander Nicolaysen Sørnes" <alex(a)thehandofagony.com> wrote: > - Use GlobalFree instead of LocalFree According to MSDN LocalFree is the correct one, as I asked before you need to fix Wine implementation of CommandLineToArgvW. -- Dmitry.

2 1

RE: d3dx: A few last questions...
by tony.wasserka＠freenet.de 29 Jan '08

29 Jan '08

> The function D3DXCheckVersion must not be forwarded from each d3dx9_xx file to the 36 because D3DX_SDK_VERSION changes for each file. Thanks for your comment, though I don't know if this is needed: Comment from the d3dx9core.h of the DX SDK: > /////////////////////////////////////////////////////////////////////////// > // D3DX_SDK_VERSION: > // ----------------- > // This identifier is passed to D3DXCheckVersion in order to ensure that an > // application was built against the correct header files and lib files. > // This number is incremented whenever a header (or other) change would > // require applications to be rebuilt. If the version doesn't match, > // D3DXCheckVersion will return FALSE. (The number itself has no meaning.) > /////////////////////////////////////////////////////////////////////////// So this function is only needed to ensure that no header file changed between the last build of an application. As this won't be the case in our wine implementation we can let all dlls use the same function. Also, the D3DX_SDK_VERSION is declared in d3dx9core.h, which means we can only have one definition of it at a time which even prevents us from caring about this function. By the way, I think this function is just a leftover from the times, when microsoft released updates of their D3DX library without renaming the dlls, were using a more actual dll could really lead to conflicts. Unbegrenzter Speicher, Top-Spamschutz, 120 SMS und eigene E-MailDomain inkl. http://office.freenet.de/dienste/emailoffice/produktuebersicht/power/mail/i…

2 1

ddraw: ddrawmodes test failures (all platforms)
by Reece Dunn 29 Jan '08

29 Jan '08

Hi, Looking at the ddrawmode test failures, they are because the test is checking that if the DDSD_REFRESHRATE flag is set, then dwRefreshRate is not 0. However, on many of the test platforms at http://test.winehq.org/data/200801161000, they are reporting a refresh rate of 0. Are these bogus - due to them running on VM - or is this a valid case? I don't currently have the ability to build those tests locally, so I cannot verify those failures. - Reece

4 6

shell32:shlfileop - interactive dialogs on Windows Vista
by Reece Dunn 29 Jan '08

29 Jan '08

Hi, One of the new features of Windows Vista is to bring up dialogs whenever you are copying files, moving files, etc. to ask the user what behaviour they want (e.g. move and replace; don't move; move, but keep both files). This makes it more user friendly, but for the Wine tests, it means that: - on XP the shlfileop tests run and pass eithout any user interaction; - on Vista, the shlfileop tests bring up several of those dialog prompts. I haven't yet looked at the tests to see what they are doing, or at the MSDN documentation to see if this would break things (i.e. if the program selected copy & replace, but the user said don't copy). Does anyone have any ideas how to get these working without user interaction (or if that is at all possible)? - Reece

1 1

Wine Wiki spam users
by Vitaliy Margolen 29 Jan '08

29 Jan '08

Does anyone have a power to block / remove those users that spam Wine wiki? It seems just 2-3 users keep creating more and more spam. Can't we just remove them and permanently block an IP range? Vitaliy.

2 1

user32: understanding the HiliteMenuItem failures (all platforms)... call for help
by Reece Dunn 29 Jan '08

29 Jan '08

Hi, I am currently looking at the user32: menu (HiliteMenuItem) test failures: menu.c:1884: Test failed: HiliteMenuItem: Item 1 is not hilited menu.c:1891: Test failed: HiliteMenuItem: Item 3 is not hilited 1. These are failing consistently on all platforms (see http://test.winehq.org/data/200801161000 - you may need to search for HiliteMenuItem to find the failures!). 2. It appears (backed up with tests in the attached patch) that the API fails when the HWND parameter is NULL. 3. The tests are not comprehensive enough. The patch I have attached here is still a work in progress: 1. I have not tested it on Wine - it is likely that this will require todo_wine markers to make it run successfully. 2. The tests are still failing on Windows (both XP and Vista). Here is where I get stuck. According to the MDSN documentation (which is likely to be wrong) this appears to be correct. Does anyone know how to get HiliteMenuItem to work?! - Reece

1 1

Mail flood from the uncoordinated bugzilla cleanup
by Detlef Riekenberg 29 Jan '08

29 Jan '08

Grrr. Please remember, that some Free Mail accounts have a limit in the numbers of Mails. The flood was to fast to stop Mail-delivery in wine-bugs. After i stopped Mail-delivery in wine-bugs, the sending queue was still so full, that my Mailbox got flood again and the bounce rate reached the limit and mailman disabled Mail-delivery for all wine groups. Not nice. -- By by ... Detlef

2 1

RE: d3dx: A few last questions...
by "Luis C. Busquets Pérez" 29 Jan '08

29 Jan '08

The function D3DXCheckVersion must not be forwarded from each d3dx9_xx file to the 36 because D3DX_SDK_VERSION changes for each file.

1 0

RE: [Patch for Bug 8551] MoveFileWithProgressW unconditional fails fordirectories with flag MOVEFILE_REPLACE_EXISTING
by Rolf Kalbermatter 29 Jan '08

29 Jan '08

Jens Nestler wrote: > [Patch for Bug 8551] MoveFileWithProgressW > unconditional fails fordirectories with flag MOVEFILE_REPLACE_EXISTING > > http://bugs.winehq.org/show_bug.cgi?id=8551 > > Hello, > > please find attached the patch for the bug mentioned above. Hi Jens, Please diff your patches from the top level wine directory itself, as it is it's not helpful since the patch utility couldn't even know which of the many path.c files in the source tree needs to be patched, and the maintainer has a lot more things to do than to search where a patch could apply to. Rolf Kalbermatter

3 2

Wine BOF at Scale 6X in Los Angeles, Feb 8th
by Dan Kegel 29 Jan '08

29 Jan '08

Anyone going to Scale in Los Angeles? I've scheduled a Wine BOF at 7pm on Friday, Feb 8th; see http://www.socallinuxexpo.org/scale6x/conference-info/social-events/birds-o… For those who don't know, SCALE is the brightest spot in Los Angeles' open source / free software scene. They've been going for eight years now. It's where I first saw a Samba developer running Windows in a VM and immediately going from Ethereal traces to implementing new code :-) See you there, I hope! (The BOF is a combined BOF with Zumastor, but don't worry, that just means I'll be talking with two people instead of one :-) - Dan

1 0

Re: [Patch for Bug 8551] MoveFileWithProgressW unconditional fails for directories with flag MOVEFILE_REPLACE_EXISTING
by James Hawkins 29 Jan '08

29 Jan '08

On Jan 28, 2008 4:05 PM, Jens Nestler <nessi(a)nessi-online.de> wrote: > http://bugs.winehq.org/show_bug.cgi?id=8551 > > Hello, > > please find attached the patch for the bug mentioned above. > Please submit a test case for this change as well. -- James Hawkins

1 0

Re: [PATCH 1/1] winecoreaudio: Make sure Port_SendToMessageThread is non-NULL in CoreAudio_WaveRelease.
by Ken Thomases 29 Jan '08

29 Jan '08

On Jan 28, 2008, at 8:06 AM, Misha Koshelev wrote: > I have started playing with wine on MacOS in VMWare. > wineprefixcreate page faults on my > MacOS "system" and I tracked it to Port_SendToMessageThread staying > NULL because of: > err:wave:CoreAudio_WaveInit AudioHardwareGetProperty: > CoreAudio_DefaultDevice.outputDeviceID == kAudioDeviceUnknown > Clearly wineprefixcreate shouldn't be page faulting under any > condition. It seems to me that the driver ought to just fail to load in this case. If you back out your patch and apply the attached patch, does that fix the page fault? -Ken

1 0

Re: start.exe: Handle the process title argument
by Detlef Riekenberg 28 Jan '08

28 Jan '08

On So, 2008-01-27 at 21:18 +0100, Alexander Nicolaysen Sørnes wrote: > SHELLEXECUTEINFOW sei; > + OSVERSIONINFOW vi; > WCHAR *args = NULL; > - int i; > + int i = 1; > The idention show a mismatch between SPACE and TAB -- By by ... Detlef

1 0

Re: your winhttp work
by Hans Leidekker 28 Jan '08

28 Jan '08

On Sunday 27 January 2008 06:42:45 EA Durbin wrote: [ I decided to CC wine-devel since you're the second person to ask ] > You had completed some work on winhttp and provided a snapshot in bug 9200. > Has this been sent to wine-patches yet? I was going to tinker with it a bit > to see if I could get an app working and wondered if you had anything more > up to date or if this had been merged into git yet? If you've already got > a solution I don't want to reinvent the wheel. Here's a rediffed version of my unfinished winhttp patch. I wrote it primarily to explore the option of implementing winhttp on top of wininet. Basically we are faced with a choice between this option, which requires a Wine-only extension to wininet to implement winhttp style callbacks, and duplicating wininet code. I think layering can be done in a relatively clean way by making wininet handle the superset of wininet and winhttp callbacks and adding callback filtering as required by winhttp. Old wininet behavior can then be obtained by an implicit filter on the wininet subset of callbacks. If time permits I'll write a comprehensive test suite for winhttp which should help us make an informed decision. -Hans

1 2

Re: start.exe: Handle the process title argument
by Dmitry Timoshkov 28 Jan '08

28 Jan '08

"Alexander Nicolaysen Sørnes" <alex(a)thehandofagony.com> wrote: > + NOTE: This will only work when run from Wine's cmd, but that's ok as start is a builtin > + shell command on NT */ What's the purpose of the comment above? > + if(argc > 1 && (vi.dwMajorVersion >= 5 || (vi.dwMajorVersion == 4 && vi.dwPlatformId == 2))) Unless there is an app which would break because of the title set there is no need to check the version. > + { > + int cmdcount; > + WCHAR* cmdline = GetCommandLineW(); > + WCHAR** cmdargs = CommandLineToArgvW(cmdline, &cmdcount); > + WCHAR* pos = cmdline; wmain() already has arc/argv pair of parameters, why do you need to parse command line again? > + > + pos += lstrlenW(cmdargs[0]); > + > + while(*pos == ' ') > + pos++; > + > + if(*pos == '"') > + { > + /* FIXME: Set the process title */ > + i++; > + } > + LocalFree(cmdargs); > + } I assume that you've added LocalFree as MSDN suggests, but CommandLineToArgvW in Wine uses GlobalAlloc, perhaps you could fix that? -- Dmitry.

2 1

Sorry about the extraordinary amount of wine-bugs spam
by Dan Kegel 28 Jan '08

28 Jan '08

I've been as annoyed as anybody at the huge churn on wine-bugs lately, it makes it hard to actually read, and the mailing list archive can't really cope. But there seems to be no way around it, so I decided to get a bunch more out of the way in one fell (and I do mean fell) swoop. In particular, I closed over a thousand old RESOLVED FIXED, RESOLVED ABANDONED, RESOLVED WORKSFORME, and RESOLVED INVALID bugs tonight. You can see the effect here: http://bugs.winehq.org/reports.cgi?product=Wine&datasets=RESOLVED%3A&datase… The only real benefit of this is fixed bugs will show up with strikethrough now when referenced in bugzilla, which is actually kind of nice. I'd like to get all the wine-bugs churn out of the way during January, if possible. For reference, the rule of thumb for closing RESOLVED bugs is: FIXED and WORKSFORME: can be closed after two weeks (i.e. after release) ABANDONED: can be closed after three months INVALID: can be closed immediately, but if it's less than a couple months old, check to make sure somebody wasn't just being cranky - Dan

1 0

question for dumps
by Juan Carlos Montes 28 Jan '08

28 Jan '08

Hi all, I need dump the data using the debug log. trace:winsock:WSASendTo socket 00f8, wsabuf 0x34e1e0, nbufs 1, flags 0, to (nil), tolen 0, ovl (nil), func (nil) if have this one, can i dump the data in 0x34e1e0 with another option in debug, or i need change the source? thanks a lot, -- _______________________________________________________________________________ Juan Carlos Montes Senra INTECO-CERT Instituto Nacional de TecnologÃas de la ComunicaciÃ³n email: juancarlos.montes(a)inteco.es | jcmontes(a)cert.inteco.es Tlf. 0034 987 877 189 - ext. 532 _______________________________________________________________________________

4 8

Re: gitignore: ignore files generated by the Visual C++ compiler.
by Dmitry Timoshkov 28 Jan '08

28 Jan '08

"Reece Dunn" <msclrhd(a)googlemail.com> wrote: > This patch ignores any files generated by the Visual C++ compiler to > make it easier to generate patches when using the VCExpress family of > compilers on Windows. There is no point in that, patches should be generated after testing in Wine under a supported platform. -- Dmitry.

6 6

Vacation
by Alexandre Julliard 27 Jan '08

27 Jan '08

Hi folks, Once again you'll have to live without commits for a while, I'm off skiing for a week... -- Alexandre Julliard julliard(a)winehq.org

3 2

d3dx8: Implement D3DXCreateTextureFromFile functions in relation to the extended version - 3rd try
by "Luis C. Busquets Pérez" 27 Jan '08

27 Jan '08

d3dx8tex.h with the mentioned name. I should be done now. Please send comments if not. --- dlls/d3dx8/Makefile.in | 1 + dlls/d3dx8/d3dx8.spec | 8 ++-- dlls/d3dx8/texture.c | 86 ++++++++++++++++++++++++++++++++++++++++++++++++ include/d3dx8.h | 1 + include/d3dx8tex.h | 43 ++++++++++++++++++++++++ 5 files changed, 135 insertions(+), 4 deletions(-) create mode 100644 dlls/d3dx8/texture.c create mode 100644 include/d3dx8tex.h

1 0

d3dx8: Implement D3DXCreateTextureFromFile functions in relation to the extended version - 3rd try
by "Luis C. Busquets Pérez" 27 Jan '08

27 Jan '08

d3dx8tex.h with the mentioned name. I should be done now. Please send comments if not. --- dlls/d3dx8/Makefile.in | 1 + dlls/d3dx8/d3dx8.spec | 8 ++-- dlls/d3dx8/texture.c | 86 ++++++++++++++++++++++++++++++++++++++++++++++++ include/d3dx8.h | 1 + include/d3dx8tex.h | 43 ++++++++++++++++++++++++ 5 files changed, 135 insertions(+), 4 deletions(-) create mode 100644 dlls/d3dx8/texture.c create mode 100644 include/d3dx8tex.h

1 0

Re: Implement D3DXCreateTextureFromFile
by Dmitry Timoshkov 27 Jan '08

27 Jan '08

"Luis C. Busquets Pérez" <luis.busquets(a)ilidium.com> wrote: > diff --git a/dlls/d3dx8/d3dx8_main.c b/dlls/d3dx8/d3dx8_main.c > index c24aedc..931e6c1 100644 > --- a/dlls/d3dx8/d3dx8_main.c > +++ b/dlls/d3dx8/d3dx8_main.c > @@ -32,6 +32,30 @@ > #include "wine/unicode.h" > #include "d3dx8_private.h" > > +typedef enum D3DXIMAGE_FILEFORMAT > +{ > + D3DXIFF_BMP = 0, > + D3DXIFF_JPG = 1, > + D3DXIFF_TGA = 2, > + D3DXIFF_PNG = 3, > + D3DXIFF_DDS = 4, > + D3DXIFF_PPM = 5, > + D3DXIFF_DIB = 6, > + D3DXIFF_HDR = 7, > + D3DXIFF_PFM = 8, > + D3DXIFF_FORCE_DWORD = 0x7fffffff, > +} D3DXIMAGE_FILEFORMAT, *LPD3DXIMAGE_FILEFORMAT; D3DXIMAGE_FILEFORMAT s inot used in your patch, so it either should be a separate patch, or removed. > +typedef struct _D3DXIMAGE_INFO { > + UINT Width; > + UINT Height; > + UINT Depth; > + UINT MipLevels; > + D3DFORMAT Format; > + D3DRESOURCETYPE ResourceType; > + D3DXIMAGE_FILEFORMAT ImageFileFormat; > +} D3DXIMAGE_INFO; If D3DXIMAGE_INFO is used in public API definitions it should be placed in an appropriate SDK header. -- Dmitry.

2 1

RegOverridePredefKey stub
by Jens Nestler 27 Jan '08

27 Jan '08

Hello all, I'm a Windows software developer and I'm trying to execute an application under the wine environment. Now I have a problem introduced with wine 0.9.49. I use the function RegOverridePredefKey from the advapi32.dll. In wine 0.9.49 a stub entry for this function was created, but the implementation is missing. To hold my code running, I need any implememtation for this function. Please apply the attached patch for a stub implementation. Thank you Jens

4 4

d3dx: A few last questions...
by tony.wasserka＠freenet.de 27 Jan '08

27 Jan '08

Hi, So far I have pretty much completed the d3dx9_24 dll. However, while writing the spec files I faced a few problems which I'd like to have solved befor submitting the patch: 1. With the d3dx9_31 dll, microsoft removed three functions from the SDK. I'm curious what to do with them. Should I stub them at the first or last dll they're used in? Also, How should I handle the forwarding thing then? I'm importing d3dx9_36 in each dll, but need to import the dll containing the three functions, too (I'm just asking to make sure there won't be any collisions or conflicts or something). By the way, the three functions are D3DXCpuOptimizations, GetTargetDescByName and GetTargetDescByVersion. 2. Another problem is, that many functions changed in there argument list from one version to the next one. For example http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/directx9_c… Says, that D3DXCreateFont changed the type of the D3DXFONT_DESC member Height from UINT to INT. I think (but don't know, so I ask) that this could lead to a misbehavior in some programs, as a UINT has a significant difference in the bit structure to INT. Also, the Angle parameter in D3DXSHRotateZ was changed from const FLOAT to FLOAT, which COULD also lead to problems. 3. Also, the MSDN seems to lack the info about D3DXGetTargetDescByName and D3DXGetTargetDescByVersion. I'd be really gradeful if someone who has an old version of the DXSDK installed could take a look into the headers and tell me the argument list. 4. And just to make sure, I attached the d3dx9_24 specfile. Everything but the argument types should be okay I think, but please tell me if you find any other problems with it, like typos in function names or something about the forwarding. Also, the two D3DXGetTargetDescByName/Version functions don't have argument lists yet as I couldn't find resources about them. That's it at the moment, I'll reply later to this topic if there appear new problems. Thanks for any answers, best regards Tony Unbegrenzter Speicher, Top-Spamschutz, 120 SMS und eigene E-MailDomain inkl. http://office.freenet.de/dienste/emailoffice/produktuebersicht/power/mail/i…

1 0

Wine Test Shell - timeouts during test runs too short?
by Reece Dunn 27 Jan '08

27 Jan '08

Hi, When running the Wine Test Shell to run the tests as part of http://test.winehq.org/, there are several timeouts in different places. These may be valid timeouts, but on my Vista test machine ddraw:d3d and msi:install generate the timeout message box part way through the test run, even though they continue and complete. Those tests are just slow. The others (such as kernel32:debugger) may be the same - especially when you get mixed results from different runs. Because of this, the timeout length should be increased (I would say at least doubled, to allow the long-running tests to run through). Another thing... I find it breaks the idea of an automated test run to have to watch it to OK the timeout messages. I know that UAC and the shfileop tests bring up interactive dialogs, but these are from within Windows itself, and will be dealt with by the timeout/test killer part of the Wine Test Shell. This would help make it easier for people to run the tests more often. - Reece

2 3

Re: d3dx8: Implement D3DXCreateTextureFromFile
by Chris Robinson 27 Jan '08

27 Jan '08

On Sunday 27 January 2008 12:39:18 am Luis C. Busquets Pérez wrote: > +{ > + FIXME("(void): stub\n"); > + return D3D_OK; > +} You probably shouldn't return okay if you're not implementing the function. It's normal to return D3DERR_NOTIMPLEMENTED (or whatever it is). At the very least you don't want to leave the output parameters untouched.

1 0

MinGW cross compiler rpms available
by Hans Leidekker 26 Jan '08

26 Jan '08

Updated cross compiler rpms are available here: http://mirzam.it.vu.nl/mingw/ I can build the full test suite from Wine 0.9.54 with these. -Hans

1 0

Re: d3dx8, d3dx9_xx and d3dx10_xx
by tony.wasserka＠freenet.de 26 Jan '08

26 Jan '08

> Find attached some data on d3dx8, d3dx9_xx and d3dx10_xx implementations: > dll files by d3dx extension: > d3dx8 1 dll files > d3dx9_xx 13 dll files > d3dx10_xx 4 dll files > [...] > Nice work, how did you get the data? Did you run Dependency Walker on each dll or is there a more practical way? I'm creating stub dlls at the moment and need to get the parameters for each function on MSDN which is very time consuming and am looking for a faster way. However, to add a little more data, my list of the differences between the d3dx9 dlls: from d3dx9_24 to d3dx9_25: + D3DXUVAtlasCreate + D3DXUVAtlasPack + D3DXUVAtlasPartition from d3dx9_25 to d3dx9_26: + D3DXComputeIMTFromPerTexelSignal + D3DXComputeIMTFromPerVertexSignal + D3DXComputeIMTFromSignal + D3DXComputeIMTFromTexture from d3dx9_26 to d3dx9_27: (no changes) from d3dx9_27 to d3dx9_28: + D3DXPreprocessShader + D3DXPreprocessShaderFromFileA + D3DXPreprocessShaderFromFileW + D3DXPreprocessShaderFromResourceA + D3DXPreprocessShaderFromResourceW from d3dx9_28 to d3dx9_30: (no changes) from d3dx9_30 to d3dx9_31: - D3DXCpuOptimizations - D3DXGetTargetDescByName - D3DXGetTargetDescByVersion from d3dx9_31 to d3dx9_32: + D3DXSHMultiply2 + D3DXSHMultiply3 + D3DXSHMultiply4 + D3DXSHMultiply5 + D3DXSHMultiply6 from d3dx9_32 to d3dx9_35: (no changes) from d3dx9_35 to d3dx9_36: + D3DXCreateFragmentLinkerEx + D3DXGetShaderConstantTableEx They of course match to your reported number of function, great job. PS: My d3dx9_24 patch is on its way, just need to prove that everything is correct

2 1

d3dx8, d3dx9_xx and d3dx10_xx
by "Luis C. Busquets Pérez" 26 Jan '08

26 Jan '08

Find attached some data on d3dx8, d3dx9_xx and d3dx10_xx implementations: dll files by d3dx extension: d3dx8 1 dll files d3dx9_xx 13 dll files d3dx10_xx 4 dll files Functions included in each d3dx: DLL Number of functions d3dx8 153 d3dx9_24 320 d3dx9_25 323 d3dx9_26 327 d3dx9_27 327 d3dx9_28 332 d3dx9_29 332 d3dx9_30 332 d3dx9_31 329 d3dx9_32 334 d3dx9_33 334 d3dx9_34 334 d3dx9_35 334 d3dx9_36 336 d3dx10_33 177 d3dx10_34 177 d3dx10_35 180 d3dx10_36 180 Total functions for all d3dx implementations: 5162 functions. Total functions for all d3dx implementations taking into account repetitions: 425 functions From these 425 functions: Functions specific to d3dx8: 15 Functions specific to d3dx9: 165 Functions specific to d3dx10: 71 Functions shared between d3dx8 and d3dx9: 65 Functions shared between d3dx9 and d3dx10: 35 Functions shared between the three implementations: 74 On the other hand, considering individual dlls, 17 functions are only mentioned in one dll 3 functions are mentioned in 2 dlls 68 functions are mentioned in 4 dlls 2 functions are mentioned in 7 dlls 10 functions are mentioned in 9 dlls 5 functions are mentioned in 11 dlls 3 functions are mentioned in 12 dlls 149 functions are mentioned in 13 dlls 65 functions are mentioned in 14 dlls 29 functions are mentioned in 17 dlls 74 functions are mentioned in 18 dlls

1 0

gdiplus: bezier test question
by Reece Dunn 26 Jan '08

26 Jan '08

The patch that I have just submitted ("gdiplus: fix the bezier arc path test (on all platforms).") is a simple fix for the failing test in graphicspath.c. The failure highlights gdiplus behaviour that is not directly obvious: If you have a bezier arc: static path_test_t arc_path[] = { {600.0, 450.0, PathPointTypeStart, 0, 0}, /*0*/ {600.0, 643.3, PathPointTypeBezier, 0, 0}, /*1*/ {488.1, 800.0, PathPointTypeBezier, 0, 0}, /*2*/ }; the gdiplus code will make the last entry PathPointTypeBezier | PathPointTypeCloseSubpath. For the nature of the existing test, I believe the fix is correct (it is testing the basic arc path functionality). However, there should be another test to document the above behaviour. - Reece

2 2

Re: [PATCH] D3DXGetFVFVertexSize implementation
by Stefan Dösinger 25 Jan '08

25 Jan '08

Am Freitag, 25. Januar 2008 19:41:52 schrieb Victor: > This is a DX8 implementation of D3DXGetFVFVertexSize (i.e. D3DFVF_XYZW is > commented out).I must note that I've encountered a bug in original/natvie > D3DXGetFVFVertexSize - it returned wrong vertex size(one float less than > needed(?)) when it was used with D3DFVF_XYZB4.It was more than a year ago, > and I'm not sure if this bug still exists in native D3DX. > Anyway this bug isn't reproduced here. A few comments: Regarding the possible bug in d3dx8 I recommend to add a test for this, like you're testing other flags already in dlls/d3dx8/tests/math.c . This will shed more light on the issue. If you do not have a Windows box to test on I can run the test for you. If the bug still exists Wine should clone it as well. (I don't think this function belongs to math.c by the way, probably create a new file called vertex.c or fvf.c or something like that) Your code contains some C++ comments ("//"), please do not use them as Wine is plain C code. I think you can just remove the D3DFVF_XYZW block if this enumeration doesn't exist in d3d8. Also please watch out with the whitespaces: The code is mixing tabs and spaces. Preferably stick to the style that is used in the rest of the file.

1 0

system tray icon regression
by Lei Zhang 25 Jan '08

25 Jan '08

Hi, With today's wine-git, tray icons no longer work. There's a spot in the system tray where the icon should be, but nothing is displayed there and I can't interact with it. This occurred on both KDE and Gnome. I found this with Picasa, but you can also see the problem with this sample program: http://bugs.winehq.org/attachment.cgi?id=9725 - Lei

1 1

Re: dlls/d3d9/tests/visual.c -- address five compiler warnings (RESEND)
by Alexandre Julliard 25 Jan '08

25 Jan '08

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > @@ -4348,12 +4349,12 @@ static void vshader_version_varying_test > "vs_3_0 returned color 0x%08x, expected 0x00203366\n", color); > color = getPixelColor(device, 160, 360); > ok((color & 0x00ff0000) >= 0x003c0000 && (color & 0x00ff0000) <= 0x004e0000 && > - (color & 0x0000ff00) >= 0x00000000 && (color & 0x0000ff00) <= 0x00000000 && > + (color & 0x0000ff00) <= 0x00000000 && > (color & 0x000000ff) >= 0x00000066 && (color & 0x000000ff) <= 0x00210068, > "vs_1_1 returned color 0x%08x, expected 0x00808080\n", color); > color = getPixelColor(device, 480, 360); > ok((color & 0x00ff0000) >= 0x003c0000 && (color & 0x00ff0000) <= 0x004e0000 && > - (color & 0x0000ff00) >= 0x00000000 && (color & 0x0000ff00) <= 0x00000000 && > + (color & 0x0000ff00) <= 0x00000000 && > (color & 0x000000ff) >= 0x00000066 && (color & 0x000000ff) <= 0x00210068, > "vs_2_0 returned color 0x%08x, expected 0x00000000\n", color); These tests don't make much sense, with or without your fix, plus the error messages don't match the tests. This needs more work. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: winex11.drv: Remove an incorrect FIXME
by Alexandre Julliard 25 Jan '08

25 Jan '08

Dmitry Timoshkov <dmitry(a)codeweavers.com> writes: > diff --git a/dlls/winex11.drv/x11drv_main.c b/dlls/winex11.drv/x11drv_main.c > index f2bf12c..948c58c 100644 > --- a/dlls/winex11.drv/x11drv_main.c > +++ b/dlls/winex11.drv/x11drv_main.c > @@ -498,10 +498,7 @@ static BOOL process_attach(void) > break; > > case 15: > - /* Out tests suggest that windows does not support 15 bpp color depth. > - * X11 does, what should we do with these situations? > - */ > - FIXME("The X server is running at 15 bpp color depth\n"); > + /* It's the same thing as 16 bpp but with different bit fields */ > screen_bpp = 15; Shouldn't screen_bpp be set to 16 then? -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: msxml3: Implement IXMLDOMDocument IDispatch interface
by Alistair Leslie-Hughes 25 Jan '08

25 Jan '08

"Alistair Leslie-Hughes" <leslie_alistair(a)hotmail.com> wrote in message news:fnchqv$a5r$1@ger.gmane.org... > Hi, > > Fixes bug http://bugs.winehq.org/show_bug.cgi?id=11257 > Correction Fixes http://bugs.winehq.org/show_bug.cgi?id=8152 Best Regards Alistair Leslie-Hughes

1 0

Re: comctl32: Vista sends an unidentified message when destroyingdatetime and monthcal windows.
by Dmitry Timoshkov 25 Jan '08

25 Jan '08

"Reece Dunn" <msclrhd(a)googlemail.com> wrote: > When destroying datetime and monthcal controls, Vista sends a message > with the value 0x0090. This messasge is not in winuser.h of the Vista > SDK. > +#define WM_UNKNOWN_VISTA1 0x0090 IMO just adding { 0x0090, sent|optional }, /* Vista */ is clear enough, WM_UNKNOWN_VISTA1 clutters the code. -- Dmitry.

2 1

re: system tray icon regression
by Dan Kegel 25 Jan '08

25 Jan '08

Lei wrote: > With today's wine-git, tray icons no longer work ... > http://bugs.winehq.org/attachment.cgi?id=9725 What bug number is that associated with, btw?

2 1

Re: user32: make the edit tests pass on Vista.
by Reece Dunn 24 Jan '08

24 Jan '08

On 24/01/2008, Reece Dunn <msclrhd(a)googlemail.com> wrote: > This adds a return code value returned by Vista in one of the test > cases to fix the uxtheme tests. > > - Reece Ignore this (sent the wrong patch). - Reece

1 0

re: Assorted spelling fixes
by Dan Kegel 24 Jan '08

24 Jan '08

Austin wrote: >- /* centred vertically and in the right side of the password edit control */ >+ /* centered vertically and in the right side of the password edit control */ I never thought about it before, but "centred" is perfectly fine English, at least in England. Guess I need to add that to stop.txt.

4 4

Re: [PATCH] fixed potential double free
by Alexandre Julliard 24 Jan '08

24 Jan '08

Marcus Meissner <marcus(a)jet.franken.de> writes: > Coverity spotted that set_window_pos() could call > free_region() on the same pointer twice. > > (CID 671 and 672) > > Check that they are different before freeing them twice. This can't happen, Coverity is confused. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [dbghelp 4/10] Rewrite much of the symbol lookup method to work with Optimized PDB files as well
by Jason Green 24 Jan '08

24 Jan '08

On Jan 22, 2008 4:00 PM, Eric Pouech <eric.pouech(a)orange.fr> wrote: > Jason Green a écrit : > > Re-responses from Eric van Beurden: > > > > > >> hmm I still don't get how, in a generic way symbols could overlap > >> the only think I could come up with if when static functions get > >> automatically inlined by the compiler, but that's rather a different > >> story (as I'd suspect the inlined function to be a single memory range > >> within a container => and in that case returning the shortest matching > >> symbol should be fine is there an existing exe/pdb file available for > >> further testings > >> > > > > > > in testing with one of our projects, i was seeing symbols lookups fail > > 85-90% of the time with the initial versions of dbghelp. The PDB > > files that were being used were generated along with the release build > > of the project (it was a C++ project as well). On further > > investigation i found that the lookups were failing because many > > symbol addresses and ranges were overlapping. This seemed to occur on > > even unrelated objects and symbols. I would suspect it was the result > > of the optimizations the compiler performed. > > > > I was able to generate PDBs that exhibited this behaviour with every > > test app i built under Visual Studio (v7.1 and 8.0Express); even apps > > that were only 25 lines long. Since it was very repeatable and the > > project in question would always be using PDBs generated from > > optimized release builds i decided to change the symbol lookup method > > to take the range into account and to be able to store a sublist of > > all symbols whose addresses fall into the same range (15-25% of the > > lookups still failed with just the range addition). > > > I'm still not convinced that the fix proposed is the correct one. Do you > have one of those examples handy so that I can have a look on it (src > file + .exe + .pdb) ? that would be great > TIA Re-re-responses from Eric van Beurden. I'll send the sample app to you off-list (and anyone else who wants a copy, just email me directly).: I tracked down one of my sample apps that showed the overlapping symbols issue in its PDB file. Many of the symbols in it are either coincident or overlapping. In some cases the overlap occurs between a C++ decorated name and its undecorated counterpart, but in several cases the overlapping symbols are unrelated. For some symbols it could be possible that their sizes are being read incorrectly from the PDB. The original symbol lookup method used a binary search on a symbol list that was sorted by starting address. The issue was that during the search it was skipping over the correct symbol because its starting address was the same as a previous symbol's address. This sent the search in the wrong direction after that and the lookup would fail. There was no fallback for handling the case of the symbol being coincident with another or the symbol being within the address space of another symbol. The attached archive contains 4 files: - 'emptyTest.exe': the optimized release build executable linked to 'emptyTest.pdb'. This should crash. - 'emptyTest.pdb': the PDB file - 'main.cpp': the source file for the test app. Some of the code is unused as the app has morphed over time. - 'emptyTest.vcproj': the VC++7.1 project file for the test app

3 5

What is the commit status of my test fixes?
by Reece Dunn 24 Jan '08

24 Jan '08

Hi, what is the status of my recent patches sent to the wine-patches list: ‎user32: make the class tests pass on Vista. [0001-user32-make-the-class-tests-pass-on-Vista.patch] 23 Jan user32: make the clipboard tests pass on Vista. [0001-user32-make-the-clipboard-tests-pass-on-Vista.patch] 23 Jan ‎user32: make the listbox tests pass in directories other than dlls/user32/tests. [0001-user32-make-the-listbox-tests-pass-in-directories-o.patch] 00:54 ‎gdi32: Vista returns UNICODE_NOCHAR if a character does not exist. [0001-gdi32-Vista-returns-UNICODE_NOCHAR-if-a-character-d.patch] 09:01 These have not been applied, although the others beyond them have (all the changes are independant of each other, except for the gitignore changes where the devenum.h one should be ignored). wine-dev ‎gitignore: ignore files generated by the Visual C++ compiler. [0001-gitignore-ignore-files-generated-by-the-Visual-C.patch] 09:08 I know that this is causing a bit of discussion at the moment. wine-dev ‎user32: make the edit tests pass on Vista. [0001-user32-make-the-edit-tests-pass-on-Vista.patch] 00:03 This one needs updating, so I'll repost it later today with the update. wine-dev ‎gitignore: added the missing include/devenum.h generated file. [0001-gitignore-added-the-missing-include-devenum.h-gener.patch] 23 Jan This one I have said is wrong, so this one can be ignored. - Reece

1 0

wpkg.org, taskkill, reg
by Dan Kegel 24 Jan '08

24 Jan '08

I just noticed http://wpkg.org, which has a big library of silent install scripts for many windows apps. Groovy! But the first one I looked at, http://wpkg.org/Picasa, requires the taskkill and reg utilities (part of Windows XP Professional), e.g. taskkill /F /IM "Picasa2.exe" reg delete "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" /v "Picasa Media Detector" /f' It ought to be easy to whip those up. Any takers? - Dan

1 0

Basis to accept someone as a maintainer
by Vitaliy Margolen 24 Jan '08

24 Jan '08

Recently I've noticed number of random people being accepted as maintainers of few apps I'm being a super-maintainer for. First, can the appDB send notifications that some one became a maintainer? Second, what are the basis that appDB admins accept some one as one? I've tried to search for a single message, test results, anything from the people in question and found none. Should we just make everyone a maintainer? If not, then could anyone spellout why we have some random people there? Vitaliy.

3 2

Re: user32: make the edit tests pass on Vista.
by Paul Vriens 24 Jan '08

24 Jan '08

Reece Dunn wrote: > The EM_CHARFROMPOS calls return different results on Vista. This patch > adds the values returned by Vista as expected results. > > - Reece > > > ------------------------------------------------------------------------ > > If you change the test for multiple correct answers, the corresponding text should reflect that as well (it now only say 'expected 0'). -- Cheers, Paul.

1 0

Re: shell32: Support getting the shell folder path for users other than the current user and the default user [resend]
by Alexandre Julliard 24 Jan '08

24 Jan '08

"Ge van Geldorp" <ge(a)thinstall.com> writes: > +static PSID _GetUserFromToken(HANDLE Token) > +{ > + char InfoBuffer[64]; > + PTOKEN_USER UserInfo; > + DWORD InfoSize; > + PSID Sid; > + DWORD SidSize; > + > + UserInfo = (PTOKEN_USER) InfoBuffer; > + if (! GetTokenInformation(Token, TokenUser, InfoBuffer, sizeof(InfoBuffer), > + &InfoSize)) > + { > + if (GetLastError() != ERROR_INSUFFICIENT_BUFFER) > + return NULL; > + UserInfo = HeapAlloc(GetProcessHeap(), 0, InfoSize); > + if (UserInfo == NULL) > + return NULL; > + if (! GetTokenInformation(Token, TokenUser, UserInfo, InfoSize, > + &InfoSize)) > + { > + HeapFree(GetProcessHeap(), 0, UserInfo); > + return NULL; > + } > + } > + > + SidSize = GetLengthSid(UserInfo->User.Sid); > + Sid = HeapAlloc(GetProcessHeap(), 0, SidSize); > + if (Sid == NULL) > + { > + if (UserInfo != (PTOKEN_USER) InfoBuffer) > + HeapFree(GetProcessHeap(), 0, UserInfo); > + return NULL; > + } > + > + if (! CopySid(SidSize, Sid, UserInfo->User.Sid)) > + { > + HeapFree(GetProcessHeap(), 0, Sid); > + Sid = NULL; > + } You should return a string directly, there's no reason to make a copy of the SID. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: PATCH - makedep, open in binary mode, move the end of file marker
by Alexandre Julliard 24 Jan '08

24 Jan '08

"Steven Edwards" <winehacker(a)gmail.com> writes: > As Julliard did not comment on this, I am assuming either it hit is > garbage filter because it was bad or because it was diffed from cvs. > Resending to hit the garbage filter for bad hacks...As discussed on > wine-devel, if its still not accepted then when I have some time I'll > look to seeing what needs to be done to teach MSYS about using windows > style line endings when doing checkouts with msys and cvs. Makefiles are text files, so they should be opened in text mode. If the mixed endings are confusing MSYS you could change makedep to rewrite the whole file instead of just appending. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: winex11.drv: try work around a crash
by Marcus Meissner 24 Jan '08

24 Jan '08

On Thu, Jan 24, 2008 at 09:00:32AM +0000, Louis. Lenders wrote: > > Hi, basically this is a resend of a patch i sent very long time ago ( http://www.winehq.org/pipermail/wine-patches/2007-April/037733.html ) > > It's a fix for bug http://bugs.winehq.org/show_bug.cgi?id=7380#c29 > > As explained in comment http://bugs.winehq.org/show_bug.cgi?id=7380#c29 > the cause of these crashes is some buggy mfc-function > , and as windows is able to work around this, wine should do the same. > > I've put the exception handler only around X11DRV_DIB_SetImageBits_24 , as that's where all the applications crash; if we want to mimic windows behaviour it should be put around all cases i guess, but i'm not sure we want to that and maybe hide other bugs. > > If this patch is rejected could you please comment why, to help fix the bug in a better way Remembering a different bug with the same issue I think you should not wrap DIB_SetImageBits_24 but just check descr->bits in X11DRV_DIB_SetImageBits() Something along the lines of: unsigned long off; unsigned char volatile x; __TRY { for (off=0;off<descr->sizeImage;off+=PAGE_SIZE) { x += ((unsigned char*)descr->bits)[off] } } ... Ciao, Marcus

1 1

Re: user32: Test destroying the cursor of a parent process.
by Dmitry Timoshkov 24 Jan '08

24 Jan '08

"Andrew Riedi" <andrewriedi(a)gmail.com> wrote: >I made some changes from the last time I talked to AJ - mainly exit code > stuff. > > changelog: user32: Test destroying the cursor of a parent process. Also there was a complaint that ok() call ersults in the child process are not included in the final statistics. There were no changes in that area in the patch. -- Dmitry.

1 0

Re: gitignore: added the missing include/devenum.h generated file.
by Reece Dunn 24 Jan '08

24 Jan '08

On 23/01/2008, Reece Dunn <msclrhd(a)googlemail.com> wrote: > The include/devenum.idl file does not have an entry in .gitignore to > prevent the generated file include/devenum.h from being included. This > patch fixes this issue. Please ignore this patch. - Reece

1 0

Re: credui: Full russian translation
by Kirill K. Smirnov 24 Jan '08

24 Jan '08

Hi, > + IDS_INCORRECTPASSWORDTITLE "Вход успешно произведён" The translation has opposite meaning than original. >+ IDS_INCORRECTPASSWORD "Убедитесь, что имя пользоватея\nи пароль верны." Typo in word "пользоватея" -- Kirill

1 0

Re: msxml3: Implement ownerDocument
by Alistair Leslie-Hughes 24 Jan '08

24 Jan '08

Dont apply this patch. "Alistair Leslie-Hughes" <leslie_alistair(a)hotmail.com> wrote in message news:fn6308$1gf$1@ger.gmane.org... > Hi, > > Changelog: > msxml3: Implement ownerDocument > > Best Regards > Alistair Leslie-Hughes > -------------------------------------------------------------------------------- > From 422440f49888d555c6031e3e40cafda0523c6ad8 Mon Sep 17 00:00:00 2001 > From: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > Date: Wed, 23 Jan 2008 11:07:59 +1100 > Subject: [PATCH] Implement ownerDocument > To: wine-patches <wine-patches(a)winehq.org> > > --- > dlls/msxml3/node.c | 22 ++++++++++++++++++++-- > dlls/msxml3/tests/domdoc.c | 23 +++++++++++++++++++++-- > 2 files changed, 41 insertions(+), 4 deletions(-) > > diff --git a/dlls/msxml3/node.c b/dlls/msxml3/node.c > index 9d43c09..bc7a2a0 100644 > --- a/dlls/msxml3/node.c > +++ b/dlls/msxml3/node.c > @@ -602,8 +602,26 @@ static HRESULT WINAPI xmlnode_get_ownerDocument( > IXMLDOMNode *iface, > IXMLDOMDocument** DOMDocument) > { > - FIXME("\n"); > - return E_NOTIMPL; > + HRESULT hr = S_OK; > + xmlnode *This = impl_from_IXMLDOMNode( iface ); > + TRACE("\n"); > + > + if(!DOMDocument) > + return E_INVALIDARG; > + > + *DOMDocument = NULL; > + > + switch( This->node->type ) > + { > + case XML_DOCUMENT_NODE: > + hr = S_FALSE; > + break; > + default: > + *DOMDocument = (IXMLDOMDocument*)create_basic_node( > (xmlNodePtr)This->node->doc, NULL ); > > + break; > + } > + > + return hr; > } > > static HRESULT WINAPI xmlnode_cloneNode( > diff --git a/dlls/msxml3/tests/domdoc.c b/dlls/msxml3/tests/domdoc.c > index 4507d08..8802053 100644 > --- a/dlls/msxml3/tests/domdoc.c > +++ b/dlls/msxml3/tests/domdoc.c > @@ -687,10 +687,9 @@ static void test_domnode( void ) > { > owner = NULL; > r = IXMLDOMNode_get_ownerDocument( element, &owner ); > - todo_wine { > ok( r == S_OK, "get_ownerDocument return code\n"); > - } > ok( owner != doc, "get_ownerDocument return\n"); > + IXMLDOMDocument_Release(owner); > > type = NODE_INVALID; > r = IXMLDOMNode_get_nodeType( element, &type); > @@ -1869,6 +1868,7 @@ static void test_cloneNode(void ) > static void test_xmlTypes(void) > { > IXMLDOMDocument *doc = NULL; > + IXMLDOMDocument *docOwner = NULL; > IXMLDOMElement *pRoot; > HRESULT hr; > IXMLDOMComment *pComment; > @@ -1923,6 +1923,25 @@ static void test_xmlTypes(void) > ok(hr == S_OK, "ret %08x\n", hr ); > ok( !lstrcmpW( str, _bstr_("document") ), "incorrect nodeTypeString > string\n"); > SysFreeString(str); > + > + /* test ownerDocument */ > + hr = IXMLDOMDocument_get_ownerDocument(doc, NULL); > + ok(hr == E_INVALIDARG, "ret %08x\n", hr ); > + > + hr = IXMLDOMDocument_get_ownerDocument(doc, &docOwner); > + ok(hr == S_FALSE, "ret %08x\n", hr ); > + ok(docOwner == NULL, "ownerDocument return a value\n"); > + if(docOwner != NULL) > + { > + str = NULL; > + hr = IXMLDOMDocument_get_nodeName( docOwner, &str ); > + ok ( hr == S_OK, "get_nodeName wrong code\n"); > + ok ( str != NULL, "str is null\n"); > + ok( !lstrcmpW( str, szDocument ), "incorrect nodeName\n"); > + SysFreeString( str ); > + > + IXMLDOMDocument_Release(docOwner); > + } > > /* test implementation */ > hr = IXMLDOMDocument_get_implementation(doc, NULL); > -- > 1.5.3.7 > > -------------------------------------------------------------------------------- > >

1 0

help with typelib support
by Alistair Leslie-Hughes 24 Jan '08

24 Jan '08

Hi, This msxml bug requires the TYPELIB resource to be added. http://bugs.winehq.org/show_bug.cgi?id=11257 I modified the followng file as follows. Makefile.in IDL_TLB_SRCS = msxml3_v1.idl msxml3_v1.idl (new File, with a single line) #include "msxml2.idl" version.rc 1 TYPELIB LOADONCALL DISCARDABLE msxml3_v1.tlb The issue I am seing is the msxml3_v1.tlb is not being created. Output. ../../tools/widl/widl -I. -I. -I../../include -I../../include -I/usr/include/libxml2 -I/usr/include/libxml2 -D__WINESRC__ -DCOM_NO_WINDOWS_H -t -T msxml3_v1.tlb msxml3_v1.idl ../../tools/wrc/wrc --nostdinc -I. -I. -I../../include -I../../include -I/usr/include/libxml2 -I/usr/include/libxml2 -D__WINESRC__ -DCOM_NO_WINDOWS_H -foversion.res version.rc version.rc:26:47: Error: Cannot open file msxml3_v1.tlb Any ideas on what is wrong? Best Regards Alistair Leslie-Hughes

3 4

user32: listbox failures
by Reece Dunn 24 Jan '08

24 Jan '08

Running the listbox tests from dlls/user32/tests, I don't get any test failures on Vista. Can anyone else confirm this? Also, the LB_DIR failures on http://test.winehq.org/ are due to it looking for files in dlls/user32/tests as part of its test run. Since these are not available when running it as part of the test suite that generates those test results - or if you are running it as as standalone in another directory (e.g. building it on one machine, then running it on another) - the tests are failing. My thoughts on this is to create some dummy data used by the tests, then cleaning this up after the tests are run. This will all be self-contained in listbox.c. Does anyone have a better idea? If not, I'll look into this and provide a patch. - Reece

1 0

[msi/tests] Install tests on win9x and NT4
by Paul Vriens 23 Jan '08

23 Jan '08

Hi, Currently the install test fail/crash on at least win95 and NT4. The main reason I found was that pMsiQueryComponentStateA and pMsiSourceListGetInfoA are not guarded. Does it makes sense to guard every instance of these calls and just continue: if (pMsiSourceListGetInfoA) { call test outcome } or should we skip the whole subtest when the function is not available. Guarding each single item requires 28 of these if-statements or is there an other alternative? (like creating a function/macro to deal with this) Just guarding the functions makes the tests not crash but they still fail (that is another issue of course). -- Cheers, Paul.

3 3

appdb test results queue count wrong?
by Dan Kegel 23 Jan '08

23 Jan '08

When an app maintainer is logged in to the appdb, and there are test results queued for approval, the test results queue length is wrongly reported as zero at the moment...

3 3

Re: Alexandre Julliard : winex11.drv: Fix handling of strange window sizes in CreateWindow, with tests.
by Lei Zhang 23 Jan '08

23 Jan '08

On Jan 22, 2008 4:01 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: > Module: wine > Branch: master > Commit: 390ae9cc2845fe002bc2e68c14d104d927af68b1 > URL: http://source.winehq.org/git/wine.git/?a=commit;h=390ae9cc2845fe002bc2e68c1… > > Author: Alexandre Julliard <julliard(a)winehq.org> > Date: Tue Jan 22 10:16:19 2008 +0100 > > winex11.drv: Fix handling of strange window sizes in CreateWindow, with tests. > > --- > > dlls/user32/tests/win.c | 79 +++++++++++++++++++++++++++++++++++++++++++++ > dlls/winex11.drv/window.c | 42 +++++------------------- > 2 files changed, 88 insertions(+), 33 deletions(-) > > diff --git a/dlls/user32/tests/win.c b/dlls/user32/tests/win.c > index 49fe766..d0a9673 100644 > --- a/dlls/user32/tests/win.c > +++ b/dlls/user32/tests/win.c > @@ -3733,6 +3733,43 @@ static LRESULT CALLBACK minmax_wnd_proc(HWND hwnd, UINT msg, WPARAM wp, LPARAM l > return 1; > } > > +static int expected_cx, expected_cy; > +static RECT expected_rect; > + > +static LRESULT CALLBACK winsizes_wnd_proc(HWND hwnd, UINT msg, WPARAM wp, LPARAM lp) > +{ > + switch(msg) > + { > + case WM_GETMINMAXINFO: > + { > + RECT rect; > + GetWindowRect( hwnd, &rect ); > + ok( !rect.left && !rect.top && !rect.right && !rect.bottom, > + "wrong rect %d,%d-%d,%d\n", rect.left, rect.top, rect.right, rect.bottom ); > + return DefWindowProc(hwnd, msg, wp, lp); > + } > + case WM_NCCREATE: > + case WM_CREATE: > + { > + CREATESTRUCTA *cs = (CREATESTRUCTA *)lp; > + RECT rect; > + GetWindowRect( hwnd, &rect ); > + trace( "hwnd %p msg %x size %dx%d rect %d,%d-%d,%d\n", > + hwnd, msg, cs->cx, cs->cy, rect.left, rect.top, rect.right, rect.bottom ); > + ok( cs->cx == expected_cx, "wrong x size %d/%d\n", cs->cx, expected_cx ); > + ok( cs->cy == expected_cy, "wrong y size %d/%d\n", cs->cy, expected_cy ); > + ok( rect.right - rect.left == expected_rect.right - expected_rect.left && > + rect.bottom - rect.top == expected_rect.bottom - expected_rect.top, > + "wrong rect %d,%d-%d,%d / %d,%d-%d,%d\n", > + rect.left, rect.top, rect.right, rect.bottom, > + expected_rect.left, expected_rect.top, expected_rect.right, expected_rect.bottom ); > + return DefWindowProc(hwnd, msg, wp, lp); > + } > + default: > + return DefWindowProc(hwnd, msg, wp, lp); > + } > +} > + > static void test_CreateWindow(void) > { > WNDCLASS cls; > @@ -3986,11 +4023,53 @@ static void test_CreateWindow(void) > ok(EqualRect(&rc, &rc_minmax), "rects don't match: (%d,%d-%d,%d) and (%d,%d-%d,%d)\n", > rc.left, rc.top, rc.right, rc.bottom, > rc_minmax.left, rc_minmax.top, rc_minmax.right, rc_minmax.bottom); > + DestroyWindow(hwnd); > + > + cls.lpfnWndProc = winsizes_wnd_proc; > + cls.lpszClassName = "Sizes_WndClass"; > + RegisterClass(&cls); > + > + expected_cx = expected_cy = 200000; > + SetRect( &expected_rect, 0, 0, 200000, 200000 ); > + hwnd = CreateWindowExA(0, "Sizes_WndClass", NULL, WS_CHILD, 300000, 300000, 200000, 200000, parent, 0, 0, NULL); > + ok( hwnd != 0, "creation failed err %u\n", GetLastError()); > + GetClientRect( hwnd, &rc ); > + ok( rc.right == 200000, "invalid rect right %u\n", rc.right ); > + ok( rc.bottom == 200000, "invalid rect bottom %u\n", rc.bottom ); > + DestroyWindow(hwnd); > + > + expected_cx = expected_cy = -10; > + SetRect( &expected_rect, 0, 0, 0, 0 ); > + hwnd = CreateWindowExA(0, "Sizes_WndClass", NULL, WS_CHILD, -20, -20, -10, -10, parent, 0, 0, NULL); > + ok( hwnd != 0, "creation failed err %u\n", GetLastError()); > + GetClientRect( hwnd, &rc ); > + ok( rc.right == 0, "invalid rect right %u\n", rc.right ); > + ok( rc.bottom == 0, "invalid rect bottom %u\n", rc.bottom ); > + DestroyWindow(hwnd); > > + expected_cx = expected_cy = -200000; > + SetRect( &expected_rect, 0, 0, 0, 0 ); > + hwnd = CreateWindowExA(0, "Sizes_WndClass", NULL, WS_CHILD, -300000, -300000, -200000, -200000, parent, 0, 0, NULL); > + ok( hwnd != 0, "creation failed err %u\n", GetLastError()); > + GetClientRect( hwnd, &rc ); > + ok( rc.right == 0, "invalid rect right %u\n", rc.right ); > + ok( rc.bottom == 0, "invalid rect bottom %u\n", rc.bottom ); > DestroyWindow(hwnd); > + > + /* top level window */ > + expected_cx = expected_cy = 200000; > + SetRect( &expected_rect, 0, 0, GetSystemMetrics(SM_CXMAXTRACK), GetSystemMetrics(SM_CYMAXTRACK) ); > + hwnd = CreateWindowExA(0, "Sizes_WndClass", NULL, WS_OVERLAPPEDWINDOW, 300000, 300000, 200000, 200000, 0, 0, 0, NULL); > + ok( hwnd != 0, "creation failed err %u\n", GetLastError()); > + GetClientRect( hwnd, &rc ); > + ok( rc.right <= expected_cx, "invalid rect right %u\n", rc.right ); > + ok( rc.bottom <= expected_cy, "invalid rect bottom %u\n", rc.bottom ); > + DestroyWindow(hwnd); > + > DestroyWindow(parent); > > UnregisterClass("MinMax_WndClass", GetModuleHandle(0)); > + UnregisterClass("Sizes_WndClass", GetModuleHandle(0)); > > #undef expect_menu > #undef expect_style > diff --git a/dlls/winex11.drv/window.c b/dlls/winex11.drv/window.c > index 84209b7..3f65602 100644 > --- a/dlls/winex11.drv/window.c > +++ b/dlls/winex11.drv/window.c > @@ -1296,37 +1296,13 @@ BOOL X11DRV_CreateWindow( HWND hwnd, CREATESTRUCTA *cs, BOOL unicode ) > CBT_CREATEWNDA cbtc; > CREATESTRUCTA cbcs; > BOOL ret = FALSE; > + INT cx = cs->cx, cy = cs->cy; > > if (!(data = alloc_win_data( display, hwnd ))) return FALSE; > > - if (cs->cx > 65535) > - { > - ERR( "invalid window width %d\n", cs->cx ); > - cs->cx = 65535; > - } > - if (cs->cy > 65535) > - { > - ERR( "invalid window height %d\n", cs->cy ); > - cs->cy = 65535; > - } > - if (cs->cx < 0) > - { > - ERR( "invalid window width %d\n", cs->cx ); > - cs->cx = 0; > - } > - if (cs->cy < 0) > - { > - ERR( "invalid window height %d\n", cs->cy ); > - cs->cy = 0; > - } > - > if (hwnd == GetDesktopWindow()) get_desktop_xwin( display, data ); > else > { > - /* initialize the dimensions before sending WM_GETMINMAXINFO */ > - SetRect( &rect, cs->x, cs->y, cs->x + cs->cx, cs->y + cs->cy ); > - X11DRV_SetWindowPos( hwnd, 0, &rect, &rect, SWP_NOZORDER | SWP_NOACTIVATE, NULL ); > - > /* create an X window if it's a top level window */ > if (GetAncestor( hwnd, GA_PARENT ) == GetDesktopWindow()) > { > @@ -1360,16 +1336,16 @@ BOOL X11DRV_CreateWindow( HWND hwnd, CREATESTRUCTA *cs, BOOL unicode ) > POINT maxSize, maxPos, minTrack, maxTrack; > > WINPOS_GetMinMaxInfo( hwnd, &maxSize, &maxPos, &minTrack, &maxTrack); > - if (maxTrack.x < cs->cx) cs->cx = maxTrack.x; > - if (maxTrack.y < cs->cy) cs->cy = maxTrack.y; > - if (cs->cx < 0) cs->cx = 0; > - if (cs->cy < 0) cs->cy = 0; > - > - SetRect( &rect, cs->x, cs->y, cs->x + cs->cx, cs->y + cs->cy ); > - if (!X11DRV_SetWindowPos( hwnd, 0, &rect, &rect, SWP_NOZORDER | SWP_NOACTIVATE, NULL )) > - return FALSE; > + if (maxTrack.x < cx) cx = maxTrack.x; > + if (maxTrack.y < cy) cy = maxTrack.y; > } > > + if (cx < 0) cx = 0; > + if (cy < 0) cy = 0; > + SetRect( &rect, cs->x, cs->y, cs->x + cx, cs->y + cy ); > + if (!X11DRV_SetWindowPos( hwnd, 0, &rect, &rect, SWP_NOZORDER | SWP_NOACTIVATE, NULL )) > + return FALSE; > + > /* send WM_NCCREATE */ > TRACE( "hwnd %p cs %d,%d %dx%d\n", hwnd, cs->x, cs->y, cs->cx, cs->cy ); > if (unicode) > > > > I've having trouble on my dual screen (twinview) setup with this patch. With a fresh ~/.wine directory, I ran notepad or regedit. The app starts on the left monitor. When I move the window to the right monitor, the window is no longer being redrawn.

3 2

Re: gdi32: Fix spec file to export the right symbols for GetGlyphOutline
by Dmitry Timoshkov 23 Jan '08

23 Jan '08

"Kai Blin" <kai.blin(a)gmail.com> wrote: > --- a/dlls/gdi32/gdi32.spec > +++ b/dlls/gdi32/gdi32.spec > @@ -282,7 +282,6 @@ > @ stdcall GetFontUnicodeRanges(ptr ptr) > @ stdcall GetGlyphIndicesA(long ptr long ptr long) > @ stdcall GetGlyphIndicesW(long ptr long ptr long) > -@ stub GetGlyphOutline > @ stdcall GetGlyphOutlineA(long long long ptr long ptr ptr) > @ stdcall GetGlyphOutlineW(long long long ptr long ptr ptr) > @ stub GetGlyphOutlineWow This patch is not correct. gdi32 does export GetGlyphOutline at least in XP. It just points to GetGlyphOutlineA. -- Dmitry.

2 1

Problem with winelib
by Nagarjuna Bandi 23 Jan '08

23 Jan '08

Dear Wine Developers Team, I am using the wine for porting windows applications under linux. This is a very powerful tool for doing this job thank you very much for providing us a such tool. Here i am getting problem with winelib when i trying to build the notepad application with the given guidelines in winelib user guide i had made the changes to Makefile you are specifying but i got another error msg like [nagarjunab@ibi212 notepad2]$ vim Makefile [nagarjunab@ibi212 notepad2]$ make wrc -I. -forsrc.res rsrc.rc winegcc -mwindows -mno-cygwin -o notepad2.exe.so dialog.o main.o rsrc.res -lodbc32 -lole32 -loleaut32 -lwinspool -luuid dialog.o(.text+0x1a5): In function `DIALOG_StringMsgBox': : undefined reference to `wnsprintfW' collect2: ld returned 1 exit status winegcc: gcc failed. make: *** [notepad2.exe.so] Error 2 This is the error i am getting so please let me know what is the problem and what i have to do for avoiding this problem. I am expecting a fast response from you. Thanks in advance. --------------------------------- Regards, Nagarjuna Bandi , Infobrain Technologies Pvt. Ltd. | My Home Sarovar Plaza | Hyderabad | India. --------------------------------- Explore your hobbies and interests. Click here to begin.

4 4

Re: [dbghelp 4/10] Rewrite much of the symbol lookup method to work with Optimized PDB files as well
by Eric Pouech 22 Jan '08

22 Jan '08

Jason Green a écrit : > ------------------------------------------------------------------------ > > From 14d91ebd5974c8fc02f8b83d53e8eff0df7ad76d Mon Sep 17 00:00:00 2001 > From: Jason Green <jason(a)jave01.(none)> > Date: Thu, 17 Jan 2008 16:41:11 -0500 > Subject: [PATCH] Rewrite much of the symbol lookup method to work with Optimized PDB files as well. > Also, improves a number of TRACEs, and wraps strings in the debugstr() functions. > what's the rationale of optimized pdb ? the patch is already big enough not to mix code evolution with stuffing new trace:s all over the place A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

2 3

Suggestion to the list maintainer
by kubrick＠fgv6.net 22 Jan '08

22 Jan '08

Hello. I have many subscriptions to different mailing list with my email-address and I'd appreciate a lot to be able to identify a message from this mailing list quickly by reading it's subject. Could you please add a subject prefix like [WINE-DEVEL] in the mailman preferences ? It's very easy to do, so maybe there is a good reason why you haven't done it yet... Thanks. François.

8 15

Re: [WineHQ][WWN] WWN 340
by Dmitry Timoshkov 22 Jan '08

22 Jan '08

"Zachary Goldberg" <zgs(a)seas.upenn.edu> wrote: > +<section > + title="Theming WINE" > + subject="WINE" Could you please use a commonly accepted capitalization of the project name - Wine? -- Dmitry.

1 0

Re: WineD3D: don't use texture_rectangle for paletted textures
by Stefan Dösinger 22 Jan '08

22 Jan '08

Am Montag, 21. Januar 2008 22:33:17 schrieb Roderick Colenbrander: > Hi, > > Don't use ARB_texture_rectangle in combination with EXT_paletted_texture. > This should get StarCraft running again on Geforce1-FX cards in case of > DirectDrawRenderer opengl with RenderTargetLockMode readtex. (bug 10697) You'll have to modify IWineD3DDeviceImpl_CreateTexture as well

1 0

Re: Fix detection error in configure.ac
by Alexandre Julliard 22 Jan '08

22 Jan '08

Thomas Zimmermann <kuhundbaer(a)web.de> writes: > this patch fixes a detection error in configure.ac. > > 'Xrandr' and 'Xinerama' detection fails if GCC is set to Ansi mode. > The reason is the use of 'typeof' in the test. GCC does not support > this keyword when it is in Ansi mode. The patch solves that problem by > using __typeof__ instead. I tested the patch on my machine. Since the corresponding code won't build either, it's actually a feature that the configure check fails. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: gdi32: Make GetICMProfile behave more like native. Rewrite ansi version as a wrapper and move color management functions to their own file.
by Detlef Riekenberg 22 Jan '08

22 Jan '08

On Mo, 2008-01-21 at 16:33 +0100, Hans Leidekker wrote: - gdi32: Make GetICMProfile behave more like native. Rewrite ansi version as a wrapper and move color management functions to their own file. The large subject is an indicator, that the Patch can be splitted. IMHO, moving the stubs to a different file can be a seperate patch. > +BOOL WINAPI GetICMProfileA(HDC hdc, LPDWORD size, LPSTR filename) > + if (!hdc || !size || !filename) return FALSE; This is not the same as documented in MSDN, and > +BOOL WINAPI GetICMProfileW(HDC hdc, LPDWORD size, LPWSTR filename) > + > + if (!hdc || !size) return FALSE; ANSI and UNICODE are different. Are you really sure? (Please insert a big warning in the comment then) Returning FALSE without a SetLastError() looks not correct, compared to SetLastError(ERROR_INSUFFICIENT_BUFFER) below. Sorry, i'm unable to test your code now. I try to do it tomorrow. -- By by ... Detlef

3 2

Re: Fix for LoadStringW
by Dmitry Timoshkov 22 Jan '08

22 Jan '08

"Christopher" <raccoonone(a)procyongames.com> wrote: > @@ -363,10 +363,14 @@ INT WINAPI LoadStringW( HINSTANCE instance, UINT resource_id, > WCHAR *p; > int string_num; > int i; > + int strlen; strlen is not the best variable name. > TRACE("instance = %p, id = %04x, buffer = %p, length = %d\n", > instance, resource_id, buffer, buflen); > > + if (buffer == NULL) > + return 0; Please add a check whether last error value should be set as well. Also this fix breaks other places in Wine which rely on previous behaviour (I repeat it the 3rd time already). > + /* Copy the resource since it is not '\0' terminated, and add '\0' to the end */ > + if(resourcepointer != NULL) > + { > + memcpy(copiedstring, resourcepointer, strlen * sizeof(WCHAR)); > + copiedstring[strlen] = '\0'; > + } Again, if () above is not needed. But ok(resourcepointer != NULL) is (right after appropriate LoadStringW call). -- Dmitry.

1 0

Re: gdi32: Add tests for GetICMProfile and SetICMMode.
by Detlef Riekenberg 22 Jan '08

22 Jan '08

On Mo, 2008-01-21 at 16:33 +0100, Hans Leidekker wrote: > > +static void test_GetICMProfileA( HDC dc ) Please check GetLastError() as much as possible (Add comments, when GetLastError() does not return something usable > + size = MAX_PATH; > + ret = GetICMProfileA( dc, &size, NULL ); > + ok( !ret, "GetICMProfileA succeeded\n" ); This is different from GetICMProfileW and MSDN. Please add a comment. > + size = 0; > + SetLastError(0xdeadbeef); > + ret = GetICMProfileA( dc, &size, filename ); > + error = GetLastError(); > + ok( !ret, "GetICMProfileA succeeded\n" ); > + ok( size, "expected size > 0\n" ); > + ok( error == ERROR_INSUFFICIENT_BUFFER, "got %d, expected > ERROR_INSUFFICIENT_BUFFER\n", error ); what are the advantages compared to one test for all? ok ( !ret && (GetLastError() == ERROR_INSUFFICIENT_BUFFER) && (size > 0), "got %u with %u and size %d (expected '0' with " "ERROR_INSUFFICIENT_BUFFER and '> 0'\n", ret, GetLastError(), size); > + size = MAX_PATH; > + ret = GetICMProfileA( dc, &size, filename ); > + ok( ret, "GetICMProfileA failed %d\n", GetLastError() ); Does the size include the terminating '\0'? what about tests with: size == needed_size -1 size == needed_size size == needed_size +1 I'm unable to test your Patch now. will try to do it tomorrow. -- By by ... Detlef

2 1

Testing on Windows for conformance
by Darragh Bailey 21 Jan '08

21 Jan '08

Wondering what flavour of Windows XP people would recommend for testing on? Is there any benefit to getting Professional over the Home edition? Or does Home have everything that is needed to be capable of developing and testing conformance tests? -- Darragh "Nothing is foolproof to a sufficiently talented fool."

2 1

Shared IDL Imports
by Robert Shearman 21 Jan '08

21 Jan '08

Hi all, I've got a patch pending in my tree that adds another IDL file in include/wine/ but it has a dependency on another new IDL file in the same directory. The trouble is that the patch in the import statement gets lost in the generated IDL file. The attached diff shows an example of this, which gives the following error: ~/Documents/wine/dlls/ole32 rob$ make ../../tools/widl/widl -I. -I. -I../../include -I../../include -D__WINESRC__ -D_OLE32_ -DCOM_NO_WINDOWS_H -h -H irot.h irot.idl gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_OLE32_ -DCOM_NO_WINDOWS_H -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o moniker.o moniker.c In file included from moniker.c:48: irot.h:11:18: error: test.h: No such file or directory I see an number of options for fixing this, but they all have problems: Solution 1: Fix the generation of include statements in header files generated from the IDL to include the path. This has the issue that it is not compatible with MIDL, so testing our IDL files with it becomes difficult (MIDL appears to only search in the current directory when it encounters an import statement with a path). Solution 2: Include the dependent IDL file instead of importing it. This has the issue that the include needs to be guarded so that the definitions don't get declared if the dependent IDL file's header is imported before or after the first IDL file's header. This also has the trouble that it isn't compatible with MIDL as the guards are different between MIDL and widl. Solution 3: Put the IDL files in another directory (e.g. include/idl) and add that to the -I statement in CFLAGS and not using a path in the import statment in the first IDL file. This has the issue of having to change the name of the IDL file in the DLL or program directory to avoid an infinite recursion of includes. Which of these is the best solution or is there another solution? Thanks, -- Rob Shearman diff --git a/include/wine/irot.idl b/include/wine/irot.idl index 54d8653..927ee13 100644 --- a/include/wine/irot.idl +++ b/include/wine/irot.idl @@ -16,6 +16,7 @@ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA */ +import "wine/test.idl"; import "wtypes.idl"; cpp_quote("#define IROT_PROTSEQ {'n','c','a','l','r','p','c',0}") diff --git a/include/wine/test.idl b/include/wine/test.idl new file mode 100644 index 0000000..e69de29

2 1

Re: mscoree: Stub for LoadStringRCEx and LoadStringRC
by Dmitry Timoshkov 21 Jan '08

21 Jan '08

"Paul Chitescu" <paulc(a)voip.null.ro> wrote: > +HRESULT WINAPI LoadStringRCEx(LCID culture, UINT resId, LPWSTR pBuffer, int iBufLen, int bQuiet, int* pBufLen) > +{ > + HRESULT res = S_OK; > + if ((iBufLen <= 0) || !pBuffer) > + return E_INVALIDARG; > + pBuffer[0] = 0; > + if (resId) { > + WARN("(%d, %x, %p, %d, %d, %p): semi-stub\n", culture, resId, pBuffer, iBufLen, bQuiet, pBufLen); This should be a FIXME not a WARN. > + res = ERROR_CALL_NOT_IMPLEMENTED; > + } > + else > + res = E_FAIL; You are mixing OLE error codes with ERROR_xxx ones, this doesn't look right. -- Dmitry.

1 0

Re: Fix makedep to work on windows again
by Dmitry Timoshkov 21 Jan '08

21 Jan '08

"Steven Edwards" <winehacker(a)gmail.com> wrote: > Make on mingw does not like mixed line endings. Don't do it, ever. > diffed from a cvs checkout > as MSYS git is slower than molasses flowing uphill on a Minnesota winter day. > > Changelog: open makedep in binary mode when writing or appending, move > the EOF marker I guess that you just use the sources fetched in Linux? Don't do that, get the source via cvs under Windows instead, in that case you don't get mixed line endings. Or alternatively convert LF to CRLF before building. -- Dmitry.

2 5

gdiplus: DEFINE_GUID
by Adam Rimon 20 Jan '08

20 Jan '08

Hi there, I wanted to implement some gdiplus functions, but for this I need the GUIDs of some properties. I took the GUIDs from http://www.reactos.org/generated/doxygen/db/de2/gdiplusimaging_8h-source.ht…, but when I tried to compile gdiplus with the new gdiplusimaging.h with many DEFINE_GUID's, the compiler kept complaining that "hidden symbol `FrameDimensionPage' isn't defined". What did I do wrong? -Adam

5 6

Re: [PATCH] Wine's ChangeDisplaySettingsEx is too strict
by Dmitry Timoshkov 20 Jan '08

20 Jan '08

"Szombathelyi György" <gyurco(a)freemail.hu> wrote: > The game changes display resolution with ChangeDisplaySettingsEx, but doesn't > specify DM_PELSWIDTH and DM_PELSHEIGHT at devmode->dmFields, so it quits > early with an error message. Of course, it works on windows. So I attached a > patch which make wine WinXP compatible...Hope you accept it. Please add a test case for this to dlls/user32/tests/monitor.c. -- Dmitry.

2 1

WWN license issue
by Ian Macfarlane 20 Jan '08

20 Jan '08

At the bottom of each WWN issue (for example, the latest http://www.winehq.org/?issue=339) is the text: "All Kernel Cousin issues and summaries are copyright their original authors, and distributed under the terms of the GNU General Public License, version 2.0. " However, it links to http://www.gnu.org/licenses/gpl.txt which of course is now the GPLv3 license text. Perhaps the text should change to say version 3 (or perhaps version 2+), or to the old archived GPLv2 license (IMO the former two options are preferable).

9 12

Re: [PATCH] Wine's ChangeDisplaySettingsEx is too strict
by Jeff Latimer 20 Jan '08

20 Jan '08

Szombathelyi György wrote: > if ((devmode->dmFields & (DM_PELSWIDTH | DM_PELSHEIGHT)) != (DM_PELSWIDTH | DM_PELSHEIGHT)) > { > WARN("devmode doesn't specify the resolution: %04x\n", devmode->dmFields); > - return DISP_CHANGE_BADMODE; > } Is this warning still valid if this is valid Windows behaviour? Jeff

2 1

Need help getting alt key remapping tips right for Photoshop users
by Dan Kegel 19 Jan '08

19 Jan '08

As of a few days ago, Photoshop CS2 activation works! IMHO the announcement for wine-0.9.54 should mention this prominently, and ask Photoshop users to test it and report bugs. In preparation for this, I'm gathering tips for users at http://wiki.winehq.org/AdobePhotoshop and will copy them into the appdb page for each version of Photoshop once I've got them together. The tough part is getting the instructions for alt key remapping right (so the window manager doesn't steal the key combinations normally used by photoshop's clone tool). I have instructions for a couple distributions there (ubuntu and suse with KDE). I'm looking for volunteers to check those instructions and correct them if they're incorrect or incomplete. Any takers? Thanks, Dan

1 0

Re: d3dx9_24: first implementation
by tony.wasserka＠freenet.de 19 Jan '08

19 Jan '08

> You need to forward all the functions of d3dx9_24 to these ones of d3dx9_36; > not only these ones that are already implemented in d3dx9_36. > > Moreover, when you create a new dll, you need to change plenty of files: > configure > configure.ac > Makefile.in > in the folder ~/wine-git/ > > You can take as example your d3dx9_36 implementation at this following > link: > http://source.winehq.org/git/wine.git/?a=commitdiff;h=87fefc7ef4eabef2b5869d > 75c7 > > David Hm, seems like I acted a little bit too hectic again... I will send a fix within the next two days. However, the configure.ac, Makefile.in etc, are autogenerated files from tools/make_makefiles, aren't they? That automatically changes these files and so I don't need to patch these manually as far as I understood. Anyways, thanks for pointing to my mistake.

1 0

Re: shdocvw: Remove unneeded cast
by Andrew Talbot 19 Jan '08

19 Jan '08

By coincidence, I've edited the same line as Jacek Caban in his patch "shdocvw: Store URL in BindStatusCallback" but in a different way. So if the two clash, please drop my patch: I shall revise it and try again after you have considered his. Thanks, -- Andy.

1 0

Re: Fix for LoadStringW
by James Hawkins 19 Jan '08

19 Jan '08

On Jan 17, 2008 1:31 AM, Christopher <raccoonone(a)procyongames.com> wrote: > This patch fixes LoadStringW when 0 is passed for buflen. LoadStringW > should now behave as described on MSDN: > http://msdn2.microsoft.com/en-us/library/ms647486.aspx > > This patch also fixes bug #10932 > > Christopher Berner > > From dfe1719df7e8cd12cc5819c647049d9f39978841 Mon Sep 17 00:00:00 2001 > From: Christopher Berner <raccoonone(a)procyongames.com> > Date: Wed, 16 Jan 2008 23:21:23 -0800 > Subject: [PATCH] Patch to fix LoadStringW when buflen is 0 > > --- > dlls/user32/resource.c | 11 +++++++++++ > 1 files changed, 11 insertions(+), 0 deletions(-) > > diff --git a/dlls/user32/resource.c b/dlls/user32/resource.c > index b9a51ae..148e9d1 100644 > --- a/dlls/user32/resource.c > +++ b/dlls/user32/resource.c > @@ -363,6 +363,7 @@ INT WINAPI LoadStringW( HINSTANCE instance, UINT resource_id, > WCHAR *p; > int string_num; > int i; > + int strlen; > > TRACE("instance = %p, id = %04x, buffer = %p, length = %d\n", > instance, resource_id, buffer, buflen); > @@ -379,9 +380,19 @@ INT WINAPI LoadStringW( HINSTANCE instance, UINT resource_id, > for (i = 0; i < string_num; i++) > p += *p + 1; > > + strlen = (int)*p; > TRACE("strlen = %d\n", (int)*p ); > > if (buffer == NULL) return *p; > + > + //if buflen == 0, then return a read-only pointer to the resource itself in buffer > + //it is assumed that buffer is actually a LPWSTR * > + if(buflen == 0) > + { > + *((LPWSTR *)buffer) = p + 1; > + return strlen; > + } > + > i = min(buflen - 1, *p); > if (i > 0) { > memcpy(buffer, p + 1, i * sizeof (WCHAR)); No c++ comments allowed. Also, you need to add a test case for this change. -- James Hawkins

5 6

Wine font license
by Brian Vincent 19 Jan '08

19 Jan '08

Right now on our fonts we say they're LGPL. (Look for the LangName attribute in the .sfd file.) We might want to make a modification to that. Here's what the FSF has to say about it: http://www.fsf.org/licensing/licenses/gpl-faq.html#FontException Or, to just copy and paste that info: -----------------------8<----------------- "How does the GPL apply to fonts?" Font licensing is a complex issue which needs serious consideration. The following license exception is experimental but approved for general use. We welcome suggestions on this subject—please see this this explanatory essay and write to licensing(a)gnu.org. To use this exception, add this text to the license notice of each file in the package (to the extent possible), at the end of the text that says the file is distributed under the GNU GPL: As a special exception, if you create a document which uses this font, and embed this font or unaltered portions of this font into the document, this font does not by itself cause the resulting document to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the document might be covered by the GNU General Public License. If you modify this font, you may extend this exception to your version of the font, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version. -Brian

1 0

GOM player
by Dan Kegel 18 Jan '08

18 Jan '08

http://www.guardian.co.uk/technology/2008/jan/17/linux.korea says everyone in Korea uses the GOM player instead of Windows Media Player. It installs ok, but blew up when I tried to load the Sony music stream from its playlist. Free download http://www.gomplayer.com/ supposedly comes with lots of codecs. - Dan

4 4

Re: [dbghelp 10/10] Clamp minidump memory blocks to 928KB
by Eric Pouech 18 Jan '08

18 Jan '08

Jason Green a écrit : > ------------------------------------------------------------------------ > > From 1127317807ec264541e2e03e6a633cefee8f697b Mon Sep 17 00:00:00 2001 > From: Jason Green <jason(a)jave01.(none)> > Date: Thu, 17 Jan 2008 17:43:41 -0500 > Subject: [PATCH] Clamp minidump memory blocks to 928KB and improve TRACEs > WinDbg can't read minidumps with memory blocks larger than this. > From: Eric van Beurden (ericvb(a)transgaming.com) > --- > dlls/dbghelp/minidump.c | 35 +++++++++++++++++++++++++++++++++-- > 1 files changed, 33 insertions(+), 2 deletions(-) > > diff --git a/dlls/dbghelp/minidump.c b/dlls/dbghelp/minidump.c > index 564d824..f113728 100644 > --- a/dlls/dbghelp/minidump.c > +++ b/dlls/dbghelp/minidump.c > @@ -32,6 +32,13 @@ > > WINE_DEFAULT_DEBUG_CHANNEL(dbghelp); > > + > +/* windbg isn't able to open minidump files if they contain a single memory block larger > + than 928KB. If a larger block is found, it simply reports that all following streams > + could not be loaded. This is as of WinDbg version 6.7.0005.1. */ > +#define MINIDUMP_MEMORY_BLOCK_MAX (928 * 1024) > + > + > struct dump_memory > { > ULONG base; > @@ -640,8 +647,32 @@ static void dump_threads(struct dump_context* dc, > } > if (mdThd.Stack.Memory.DataSize && (flags_out & ThreadWriteStack)) > { > - add_memory_block(dc, mdThd.Stack.StartOfMemoryRange, > - mdThd.Stack.Memory.DataSize, > + ULONG size; > + ULONG64 base; > + > + > + /* windbg only supports memory blocks up to 928KB in size. Not sure where that > + specific amount comes from, but in testing it will completely fail to load > + all minidump streams that follow a memory block that is larger than 928KB. > + Because of this, we'll clamp all of the memory blocks that we add to the > + file. */ > + if (mdThd.Stack.Memory.DataSize > MINIDUMP_MEMORY_BLOCK_MAX){ > + size = MINIDUMP_MEMORY_BLOCK_MAX; > + > + /* since this is the thread stack we'll want to save this block top-down > + instead of just clamping the buffer size */ > + base = mdThd.Stack.StartOfMemoryRange + (mdThd.Stack.Memory.DataSize - MINIDUMP_MEMORY_BLOCK_MAX); > + > + TRACE(" clamping the stack block starting at 0x%08llx {oldSize = %u bytes, newSize = %u bytes, newBase = 0x%08llx}\n", > + mdThd.Stack.StartOfMemoryRange, mdThd.Stack.Memory.DataSize, size, base); > + } > + > + else{ > + size = mdThd.Stack.Memory.DataSize; > + base = mdThd.Stack.StartOfMemoryRange; > + } > + > + add_memory_block(dc, base, size, > rva_base + sizeof(mdThdList.NumberOfThreads) + > mdThdList.NumberOfThreads * sizeof(mdThd) + > FIELD_OFFSET(MINIDUMP_THREAD, Stack.Memory.Rva)); > > ------------------------------------------------------------------------ > > > if that's really the case (and I'm even not sure we want to support this backward compatibility), a good fix would be to add several streams each up to 928k instead of clamping A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

1 0

Re: [dbghelp 7/10] Fix file searching to search only listed directories instead of the whole HD
by Eric Pouech 18 Jan '08

18 Jan '08

Jason Green a écrit : > ------------------------------------------------------------------------ > > From ad95ee9cad0df8b4e8ca35d2d5a280d755c7bf7f Mon Sep 17 00:00:00 2001 > From: Jason Green <jason(a)jave01.(none)> > Date: Thu, 17 Jan 2008 17:21:00 -0500 > Subject: [PATCH] Fix file searching to search only listed directories instead of the whole HD. > And, wrap some TRACE parameters in debugstr. > From: Eric van Beurden (ericvb(a)transgaming.com) > --- > dlls/dbghelp/path.c | 14 +++++++------- > 1 files changed, 7 insertions(+), 7 deletions(-) > > diff --git a/dlls/dbghelp/path.c b/dlls/dbghelp/path.c > index 2e191af..fac9dc0 100644 > --- a/dlls/dbghelp/path.c > +++ b/dlls/dbghelp/path.c > @@ -57,7 +57,7 @@ HANDLE WINAPI FindDebugInfoFile(PCSTR FileName, PCSTR SymbolPath, PSTR DebugFile > { > HANDLE h; > > - h = CreateFileA(DebugFilePath, GENERIC_READ, FILE_SHARE_READ, NULL, > + h = CreateFileA(FileName, GENERIC_READ, FILE_SHARE_READ, NULL, > OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); > you failed to set DebugFilePath to the desired value again the rest of the patch has nothing to do with the first part of the patch A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

1 0

problem with widl.
by Ivan Sinitsin 18 Jan '08

18 Jan '08

I have a question about widl. tools\widl\header.c function "write_method_macro" fprintf(header, "#define %s_", name); write_name(header,def); fprintf(header, "(p"); for (c=0; c<argc; c++) fprintf(header, ",%c", c+'a'); fprintf(header, ") "); fprintf(header, "(p)->lpVtbl->"); write_name(header, def); fprintf(header, "(p"); for (c=0; c<argc; c++) fprintf(header, ",%c", c+'a'); fprintf(header, ")\n"); This code wrong, because if my function have more then 16 parameters I receive something like this: #define Imyinterface_Open(p,a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q (p)->lpVtbl->Open(p,a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q) and the compiler gives out a mistake library.h:1296:63: duplicate macro parameter "p" I think that this code should be like this: Variant 1. int p=0; for (c=0; c<argc; c++) { if (p==15) p++; fprintf(header, ",%c", p+'a'); p++; } fprintf(header, ") "); fprintf(header, "(p)->lpVtbl->"); write_name(header, def); fprintf(header, "(p"); p=0; for (c=0; c<argc; c++) { if (p==15) p++; fprintf(header, ",%c", p+'a'); p++; } fprintf(header, ")\n"); or Variant 2. (Without cycles) char str[] = {'p',',','a',',','b',',','c',',','d',',','e',',','f',',','g',',','h',',','i',',','j',',','k',',','l',',','m',',','o',',','q',',','r',',','s',',','t',',','u',',','v',',','w',',','x',',','y',',','z',',',0}; str[2*argc+1] = 0; fprintf(header, "#define %s_", name); write_name(header,def); fprintf(header,"("); fprintf(header,"%s",str); fprintf(header, ") "); fprintf(header, "(p)->lpVtbl->"); write_name(header, def); fprintf(header,"("); fprintf(header,"%s",str); fprintf(header, ")\n"); What do you think about that? ---------------- Sinitsin Ivan

2 1

Debugger unhappiness blocking valgrind runs
by Dan Kegel 18 Jan '08

18 Jan '08

I just tried to do another daily valgrind run, but it got blocked because it started up an infinite number of copies of winedbg. It seems that a crash in the imagelist test in GetDibBits triggered winedbg, and winedbg crashed trying to generate a backtrace, which of course fired up winedbg, which... was bad. Some of the logs are at http://bugs.winehq.org/show_bug.cgi?id=11211 This seems to be very recent breakage, either today or yesterday. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

3 3

Re: [dbghelp 4/10] Rewrite much of the symbol lookup method to work with Optimized PDB files as well
by Alexandre Julliard 18 Jan '08

18 Jan '08

"Jason Green" <jave27(a)gmail.com> writes: > + > +#ifdef TRACE_SYMBOL_LIST > + TRACE("\n\n***** sorting the table {count = %d}\n\n", module->num_sorttab); > +#endif > + > + qsort(module->addr_sorttab, module->num_sorttab, sizeof(struct symbol_entry), symt_cmp_addr_and_size); > + > + generateSymbolChains(module); > + > + > +#ifdef TRACE_SYMBOL_LIST > + if (0){ > + ULONG64 prevAddr = 0; Please don't add ifdef'ed out code, it should either be compiled always, or removed completely. > + sizeof(SYMBOL_INFO), Symbol->SizeOfStruct, > + (intptr_t)&Symbol->SizeOfStruct - (intptr_t)Symbol, > + (intptr_t)&Symbol->TypeIndex - (intptr_t)Symbol, > + (intptr_t)&Symbol->Reserved[0] - (intptr_t)Symbol, Don't use stdint.h types, there are Win32 types for that. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: qmgr [1/3]: Implement IClassFactory methods.
by Alexandre Julliard 18 Jan '08

18 Jan '08

Dan Hipschman <dsh(a)linux.ucla.edu> writes: > I split the last patch into three. This is essentially the same as the last > one Roy sent, but cleaned up a bit. This adds the IClassFactory methods for > BITS. When sending a patch written by someone else, please include a From: line with the proper attribution in your message. -- Alexandre Julliard julliard(a)winehq.org

1 0

appdb hosed
by Dan Kegel 18 Jan '08

18 Jan '08

The left nav bars are broken, can't approve any new test data.

2 3

re: add HKLM/System/MountedDevices to be added by default
by Dan Kegel 18 Jan '08

18 Jan '08

c.f. wrote: > this is suggested on quite some places in appdb to make seucrom based games come a litle further Discussed at http://bugs.winehq.org/show_bug.cgi?id=7065#c58 Looks like something of this sort is already in, you must have blinked :-)

1 0

add HKLM/System/MountedDevices to be added by default
by Christoph Frick 17 Jan '08

17 Jan '08

this is suggested on quite some places in appdb to make seucrom based games come a litle further --- tools/wine.inf | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/tools/wine.inf b/tools/wine.inf index c3cb89c..f63fb23 100644 --- a/tools/wine.inf +++ b/tools/wine.inf @@ -362,6 +362,8 @@ HKLM,SOFTWARE\Microsoft\Active Setup\Installed Components\{de5aed00-a4bf-11d1-99 HKLM,SOFTWARE\Microsoft\Active Setup\Installed Components\{de5aed00-a4bf-11d1-9948-00c04f98bbc9},"IsInstalled",2,1 HKLM,SOFTWARE\Microsoft\Active Setup\Installed Components\{de5aed00-a4bf-11d1-9948-00c04f98bbc9},"Locale",2,"*" HKLM,SOFTWARE\Microsoft\Active Setup\Installed Components\{de5aed00-a4bf-11d1-9948-00c04f98bbc9},"Version",2,"4,74,9273,0" +; SecuROM needs this key +HKLM,System\MountedDevices,,,"" [Nls] HKLM,System\CurrentControlSet\Control\Nls\Codepage,"37",,"" -- 1.5.3.7

2 2

Re: [PATCH] support for synchronous and non-buffered I/O
by Dave Hansen 17 Jan '08

17 Jan '08

On Tue, 2008-01-15 at 23:10 -0800, Dave Hansen wrote: > I have a little Eye-Fi card (http://www.eye.fi). The software to > control it is a windows application that writes to control files which > appear in a DOS filesystem on the SD card. (you can read more > information here: http://dave-hansen.blogspot.com/) > > However, the application does not quite work under wine. The > application writes to the card, but doesn't get the results it expects. > It loops doing read()s of the files looking for results until it times > out. Do me a favor and don't apply this quite yet. I'll repost when it's ready. -- Dave

1 0

Valgrinding large win32 app worked!
by Dan Kegel 17 Jan '08

17 Jan '08

This script, http://kegel.com/wine/valgrind/valgrind-330-build.sh builds a copy of valgrind-3.3.0 with John Reiser's forward port of the Wine support patch. With that, I can run Picasa for Windows under Wine under Valgrind. It takes 40 seconds to start up on my 1.3GHz Athlon 64, which is right in line with Valgrind's legendary ~10x overhead. It seemed to find lots of little problems, but since there were lots of numeric addresses without symbolic info in the valgrind log, it wasn't directly useful to the Picasa developers. The next step, I suppose, is to find a way to make the valgrind log contain symbolic identifiers for the functions in the Windows app. I looked at that for a few minutes; here are some notes that might provide a starting point. http://www.debuginfo.com/articles/gendebuginfo.html is the best overview I've seen so far on how to tell Visual C++ to generate debugging info; for most apps, the preferred debug info format will be .pdb. http://www.debuginfo.com/articles/dbghelptypeinfo.html has an example win32 app that will dump all public symbols from a win32 app. It runs fine on Windows XP, and can dump symbols for Picasa (generating a 9MB text file). (I happen to have the .pdb file for Picasa handy since I are an honorary Picasa developer.) Sadly, that symbol dumper crashes on Wine, see http://bugs.winehq.org/show_bug.cgi?id=11211 Also, the unresolved error addresses in the valgrind trace were mostly in the 0x400000 - 0x420000 range, whereas the symbols dumped by that dumper app were all in the range 0x1000000 - 0x1080000... maybe the base load address is different between the two OS's. I haven't tried valgrinding a toy app yet, but that's probably the easiest way to figure out how to match the symbols up. - Dan

4 6

bugzilla component and keyword cleanup
by Jan Zerebecki 17 Jan '08

17 Jan '08

I'm done with one step of the changes. See the following URLs for how things currently look: http://bugs.winehq.org/describekeywords.cgi http://bugs.winehq.org/describecomponents.cgi?product=Wine Improvement suggestions are welcome. Does anyone know how the CVS/GIT version is marked so that it gets selected on the new bug page and if that is also possible for the component? Now for further improvements: Changes which IMHO should not be done: wine-help -> hhctrl - Help viewer implementation help is currently not for the various help APIs but for user that want help. We should obsolete this component. We can create a new component for the help APIs if there is demand. (new) -> vdm - Wine 16-bit compatibility layer (new) -> win16 - Wine 16-bit compatibility layer vdm is part of the component dos, right? A win16 keyword is probably useful as win16 support is intertwined in quite some other DLLs and thus components. Components that are marked as obsolete now, but where it's not sure how to replace them: multimedia Should we really replace this? Replace it with what? An mci and winmm component? console I didn't really made my mind up about this one yet... files ipc ports winelib Possibly replace each with a keyword, see below. Changes to the keywords: conformance (delete) Delete this keyword, because it fits probably most wine bugs. testcase (new) Bugs that have a testcase attached, in source form but not necessarily integrated into the Wine test suite. win16 (new) Bugs in the win16 parts of Wine. dotnet (new) Bugs that appear in applications using dotNet and that are related to this dotNet useage. winelib (new) Bugs during winelib useage but not during useage through windows native executables. ports (new) Bugs regarding porting to specific platforms or OSs. FIXME needs clarification tasklet needs clarification tasklist needs clarification Abandoned? -> needmoreinfo This is currently discussed in another thread. filesystem (new) Do we want such a component? Is it maybe related with console? What exactly should it cover? Only things that possibly can destroy data? console (new) I didn't really made my mind up about this one yet... Jan

3 4

Re: kernel32: Intialise 16-bit stack to zero.
by Alexandre Julliard 17 Jan '08

17 Jan '08

Robert Shearman <rob(a)codeweavers.com> writes: > --- > dlls/kernel32/kernel_main.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > Otherwise dbghelp could sometimes get confused and think it should > switch to 16-bit mode. > This results in messages such as the following when warn or tracing > for the heap channel is turned on: > fixme:dbghelp:Failed to linearize address ????:55555555 ... Initializing the first frame should be enough. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: ntdll: Do not perform base relocation if an image is not a DLL. Take 2
by Paul Chitescu 17 Jan '08

17 Jan '08

Dmitry, IMHO it doesn't worth to the to relocate EXEs since virtually none are providing relocation records. Any operating system that can't allocate memory at low virtual addresses won't be able to run any Windows application newer than about 13 years (that is, all of interess). EXEs were relocated only in Win32s where all applications were sharing a single address space. Since Visual C 4 the linker default is to not generate relocations for EXE files. Paul Chitescu On Thu, 17 Jan 2008, Dmitry Timoshkov wrote: > Hello, > > this patch fixes the problem reported in the bug 11170. It appears that > LoadLibrary in Windows doesn't attempt to relocate .exe files. > > Alexandre noticed that previous version of the patch may break relocation of > the main exe. This version addresses that. However, this appears to be not > compatible with what Windows (does not) do: in order to force a relocation > of main under XP I set its base address to match the ntdll.dll (0x7c900000), > and XP just refused to load the exe with an error message "The system cannot > execute the specified program." But we may need to relocate main exe due to > environment limitations (some native .so file may be mapped at that address). > > Changelog: > [...]

1 0

Time to create a stub wmvcore.dll?
by Dan Kegel 17 Jan '08

17 Jan '08

There seem to be a large number of apps that don't start unless a wmvcore.dll is present: TVersity Phatnoise Lost Planet The Bard's Tale WMA Workshop MixMeister ... So, how 'bout it? Should we create a stub for wmvcore.dll and friends? - Dan

2 1

Easy usage of native DLLs in Linux programs
by Radovan Skolnik 17 Jan '08

17 Jan '08

Hello! I have found this old thread dealing exactly with what I need: http://www.winehq.org/pipermail/wine-devel/2006-April/046779.html It basically proposes a work to be done to allow loading native Windows DLLs into Linux binaries (for example loading WinAmp plugins into xine/mplayer/gst/...). I am in the need to use a small DLL (no GUI, just few APIs that are all already implemented) which I have no source code to. Has this initiative progressed to something? If not can anybody advise on how I shoudl proceed wrapping native DLL into .so? I have looked over the mplayer code to load Windows codecs but I couldn't really grasp the idea - the are no comments with the code :-( Thank you and best regards Radovan Skolnik

2 1

Getting Mozy to work
by Christopher 17 Jan '08

17 Jan '08

3 3

Re: Request for patch removal
by Dmitry Timoshkov 17 Jan '08

17 Jan '08

"Federico Vecchiarelli" <fedev(a)gmx.net> wrote: > Ok, to the point. The patch mentioned below prohibits wine from running > any application which is inside someone else's folder, even if you have > access to it. In my case, I wanted to make one unique installation > available to several users. Because of this patch, there is no > workaround that could be implemented, forcing me to either run a script > changing the owner of the folders for every user as they want to use the > application or I have to make several copies of the software which will > put me in a difficult legal situation. All the details about this problem you can find here: http://bugs.winehq.org/show_bug.cgi?id=11112 -- Dmitry.

6 6

valgrind and +heap not getting along?
by Dan Kegel 17 Jan '08

17 Jan '08

I'm seeing fun traces like ==17177== Invalid write of size 1 ==17177== at 0x4022D5A: memset (mc_replace_strmem.c:492) ==17177== by 0x46E914A: mark_block_free (heap.c:148) ==17177== by 0x46E6950: HEAP_CreateFreeBlock (heap.c:493) ==17177== by 0x46E6B78: HEAP_ShrinkBlock (heap.c:575) ==17177== by 0x46E7F47: RtlAllocateHeap (heap.c:1228) ==17177== by 0x46EC10A: get_builtin_fullname (winnt.h:1989) ==17177== by 0x46EC2B8: load_builtin_callback (loader.c:1320) ==17177== by 0x402C3BF: wine_dll_set_callback (loader.c:480) ==17177== by 0x46EF3A7: __wine_process_init (loader.c:2529) ==17177== by 0x402C7D5: wine_init (loader.c:645) ==17177== by 0x7BF01263: main (main.c:111) ==17177== Address 0x7f000140 is not stack'd, malloc'd or (recently) free'd when running with +heap under valgrind. Is something off by one somewhere? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

Shader compiler GL error
by Markus 16 Jan '08

16 Jan '08

Hi, while trying to fix the bug I posted a few days ago, the game's developer pointed out on request that the ingame shader issues are not related to the graphics card detection but more likely to a failing shader compilation. They are using d3d9_33.dll for development and recommended to try with this version. I've thus removed all other versions of the library and also deleted the game's cached shaders. The game now crashes on startup with the following error: fixme:d3d_surface:flush_to_framebuffer_drawpixels >>>>>>>>>>>>>>>>> GL_INVALID_VALUE (0x501) from glDrawPixels @ surface.c / 1061 If I use d3d9_31.dll instead, the shaders are compiled and the game starts but the water is again looking like a low-end fallback. Any ideas on this? Regards, -- Markus

2 4

autorun perhaps dangerous (Was: Wine release 0.9.53)
by Marcus Meissner 16 Jan '08

16 Jan '08

On Fri, Jan 11, 2008 at 05:36:04PM +0100, Alexandre Julliard wrote: > This is release 0.9.53 of Wine, a free implementation of Windows on Unix. > > What's new in this release: > - RunOnce and Run entries now executed on startup. This will probably give some fallout ;) I wanted to write earlier, but did forget about it over the last days. For my grown Wine installation this now starts: - 2 instances of a Windows Worm - Google Talk (not working) - Skype (crashing) - pccam.exe from some digital camera disk - the annoying Steam.exe auto-update and ask-for-subscription dialog - perhaps more and this even on "make check" :( We probably need some tool to edit Run and RunOnce entries now. Ciao, Marcus

16 25

Status of d3d in a child window?
by Mark Hatsell 16 Jan '08

16 Jan '08

Hello All I was just wondering what the status was of D3D in a child window. Looking back at the release info it seems that the OpenGL in a child window has been sorted and that D3D has been converted to use WGL. Is this not enough to get D3D in a child window going? I have tried the mfctex sample but it draws the D3D child window in slightly the wrong place and doesn't render anything at all. I have also tried a couple of other apps which also exhibit similar behaviour. Just wondered what else needed fixing before this would work? Thanks Mark

3 3

re: Request for patch removal
by Dan Kegel 16 Jan '08

16 Jan '08

"Federico Vecchiarelli" <fedev at gmx.net> wrote: > ... I wanted to make one unique installation > available to several users. Because of this patch, there is no > workaround that could be implemented, forcing me to either run a script > changing the owner of the folders for every user as they want to use the > application or I have to make several copies of the software which will > put me in a difficult legal situation. Since it seems from your description that the users don't need to share a copy of the registry, the solution is probably to do what Picasa for Linux does, and just put symlinks to the installed files into each user's .wine directory. You will need to write a little script that starts the app after creating these links. You can see how to do this by installing Picasa and looking at /opt/picasa/bin/wrapper, it does exactly this. - Dan

1 0

Towards Zero Test Suite Failures
by Dan Kegel 16 Jan '08

16 Jan '08

On my machine, we've been hovering between five and ten test suite failures for some time (see http://bugs.winehq.org/show_bug.cgi?id=9916 ) IMHO one of the hallmarks of 1.0 should be reliably getting zero test suite failures. That would make regressions stand out like sore thumbs instead of requiring developers to diff results before and after their changes, and might result in fewer regressions getting committed. How 'bout folks spend some time tracking the current six odd failures down and cleaning them up? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

8 11

Re: ntdll: Do not perform base relocation if an image is not a DLL
by Alexandre Julliard 16 Jan '08

16 Jan '08

Dmitry Timoshkov <dmitry(a)codeweavers.com> writes: > Hello, > > this patch fixes the problem reported in the bug 11170. It appears that > LoadLibrary in Windows doesn't attempt to relocate .exe files. > > Changelog: > ntdll: Do not perform base relocation if an image is not a DLL. This will break the relocation of the main exe. -- Alexandre Julliard julliard(a)winehq.org

1 0

GDI32.dll.NamedEscape
by "Luis C. Busquets Pérez" 16 Jan '08

16 Jan '08

I am having problems with a bunch of three games that came together in the same pack. They all abort qhen asking for installation with the following line wine: Call from 0x73ba1895 to unimplemented function GDI32.dll.NamedEscape, aborting Does anybody know what GDI32.dll.NamedEscape does? Does anybody intend to implement it in the near future?

5 4

Re: advpack: Skip some tests if not in interactive mode because they pop up dialogs.
by Saulius Krasuckas 15 Jan '08

15 Jan '08

* On Tue, 13 Nov 2007, Francois Gouget wrote: > > This was causing the advpack:install test to time out on my Win98, WinXP > and Win2003 VMs. Would it be nice to create some closer-thread for closing poped up dialogs in places of code known for that behaviour? (Probably, for non interactive mode only)

2 1

SVN usage for Wine
by James McKenzie 15 Jan '08

15 Jan '08

Because git is unstable on the Mac platform, I've been utilizing a little time investigating the use of either SVN or CVS to download .git updates. This appears to not be working per the Wiki pages for SVN. Is CVS or SVN still being supported for Wine or is git the only supported download (I don't expect to do any patching for now) method for .git updates? Thank you. James McKenzie

5 4

re: Tools: Spelling fixes
by Dan Kegel 15 Jan '08

15 Jan '08

Austin wrote: > only used for optimization, so just check for a very small set of >- criteria that guarantee the types are equivalent; assume every thing >+ criteria that guarantees the types are equivalent; assume everything The original was correct, please don't change that. Firstly, it's not a spelling problem; secondly, in England, it's correct to consider a set of something plural. The rest of the changes in this patch seem ok. - Dan

1 0

d3dx9: Start implementation of d3dx9_36
by tony.wasserka＠freenet.de 15 Jan '08

15 Jan '08

What's wrong with it this time? Thought that it was okay this time :D

1 0

Good source for msvcr71?
by Dan Kegel 15 Jan '08

15 Jan '08

I finally ran into an app that wanted msvcr71 but didn't bundle it (supercopyright). After a few minutes of looking, I couldn't find it anywhere on microsoft.com. The best source I could find was the installer for spambayes 1.1, but that's inconvenient. Anyone know a better source, preferably at microsoft.com? I'd like to add it to winetricks. Thanks, Dan

3 4

Re: [advapi32] QueryServiceConfig2 (2nd try)
by Alexandre Julliard 15 Jan '08

15 Jan '08

Stefan Leichter <Stefan.Leichter(a)camline.com> writes: > + * Note > + * observed unter win2k: > + * 1. when the function is called to get the required buffer size, the value of > + * the returned parameter needed is big enough to hold the strings as WCHARs(!) It's not WCHARs, it's two A chars per W char to leave enough room for the conversion. I don't see you doing that in the code. > + case SERVICE_CONFIG_DESCRIPTION: > + { LPSERVICE_DESCRIPTIONA configA = (LPSERVICE_DESCRIPTIONA) buffer; > + LPSERVICE_DESCRIPTIONW configW = (LPSERVICE_DESCRIPTIONW) bufferW; > + *needed = sizeof(SERVICE_DESCRIPTIONA); > + if (configW->lpDescription) { > + DWORD sz; > + configA->lpDescription = (LPSTR)(configA + 1); > + sz = WideCharToMultiByte( CP_ACP, 0, configW->lpDescription, -1, > + configA->lpDescription, size - sizeof(SERVICE_DESCRIPTIONA), NULL, NULL ); > + if (!sz) { > + FIXME("WideCharToMultiByte failed for configW->lpDescription\n"); > + ret = FALSE; > + configA->lpDescription = NULL; > + goto cleanup; You need to update the needed size on buffer overflow. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [take 2] shell32: Check if token references the current user
by Alexandre Julliard 15 Jan '08

15 Jan '08

ge(a)gse.nl writes: > Incorporates feedback by Juan Lang > > Changelog: > Ge van Geldorp <ge(a)thinstall.com> Please either put your full name in the mail headers, or include the full git headers in the body of your message, so that my commit script can grab your name and email automatically. > @@ -1382,14 +1476,15 @@ static HRESULT _SHGetUserProfilePath(HANDLE hToken, DWORD dwFlags, BYTE folder, > return E_INVALIDARG; > > /* Only the current user and the default user are supported right now > - * I'm afraid. > + * I'm afraid. We do handle the case where the token references the > + * current user. > * FIXME: should be able to call GetTokenInformation on the token, > * then call ConvertSidToStringSidW on it to get the user prefix. > * But Wine's registry doesn't store user info by sid, it stores it > * by user name (and I don't know how to convert from a token to a > * user name). This comment is obsolete, we store the registry by sid now, so this is what you should use to open the user's key. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: gdi32: Do not allow to create too large device dependent bitmaps like Windows does
by Robert Shearman 15 Jan '08

15 Jan '08

Dmitry Timoshkov wrote: > + SetLastError(0xdeadbeef); > + hbmp = CreateBitmap(0x7ffffff, 9, 1, 1, NULL); > + ok(!hbmp, "CreateBitmap should fail\n"); > + ok(GetLastError() == ERROR_NOT_ENOUGH_MEMORY, > + "expected ERROR_INVALID_PARAMETER, got %u\n", GetLastError()); > The string here doesn't match the test. -- Rob Shearman

1 0

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