September 2010 - Wine-devel

Re: [PATCH 1/5] gameux: Add implementation of IGameStatistics::SetCategoryTitle
by Nikolay Sivov 26 Sep '10

26 Sep '10

On 9/26/2010 16:59, Mariusz Pluciński wrote: > --- > dlls/gameux/gamestatistics.c | 50 > ++++++++++++++++++++++++++++++++++- > dlls/gameux/tests/gamestatistics.c | 14 +++++----- > 2 files changed, 55 insertions(+), 9 deletions(-) > @@ -177,8 +201,30 @@ static HRESULT WINAPI GameStatisticsImpl_SetCategoryTitle( > WORD categoryIndex, > LPCWSTR title) > { > - FIXME("stub\n"); > - return E_NOTIMPL; > + HRESULT hr = S_OK; > + DWORD dwLength; > + GameStatisticsImpl *This = impl_from_IGameStatistics(iface); > + > + TRACE("(%p, %d, %s)\n", This, categoryIndex, debugstr_w(title)); > + > + if(!title || categoryIndex>= MAX_CATEGORIES) > + hr = E_INVALIDARG; Just return here and be done with it, this will save you hr initialization and unnecessary if (SUCCEEDED(hr)) after that. > + > + if(SUCCEEDED(hr)) > + { > + dwLength = lstrlenW(title); > + > + if(dwLength> MAX_CATEGORY_LENGTH) > + { > + hr = S_FALSE; > + dwLength = MAX_CATEGORY_LENGTH; > + } Does it really copy with hr == S_FALSE ? > + > + lstrcpynW(This->stats.categories[categoryIndex].sName, > + title, dwLength+1); > + } > + > + return hr; > } >

2 1

RFC [PATCH] ddraw: Prevent refcount underflow
by Vincent Pelletier 26 Sep '10

26 Sep '10

Hi. Attached patch fixes a problem with Beetle Crazy Cup's VideoSetup.exe, which hangs at exit because some code tries to free ddraw surface on which a refcount underflow happened earlier in the execution. Executing it with winedbg shows that the first call causing the underflow is triggered from game's binary: Stopped on breakpoint 3 at 0x7ed494fc ddraw1_Release+0x2c [/home/vincent/git/wine/dlls/ddraw/ddraw.c:476] in ddraw 476 ULONG ref = InterlockedDecrement(&ddraw->ref1); Wine-dbg>print ddraw->ref1 0 Wine-dbg>bt Backtrace: =>0 0x7ed494fc ddraw1_Release+0x2c(iface=0x129e10) [/home/vincent/git/wine/dlls/ddraw/ddraw.c:476] in ddraw (0x0033fd24) 1 0x00401d2c in videosetup (+0x1d2b) (0x0033fd5c) 2 0x0040342b in videosetup (+0x342a) (0x0033fd84) 3 0x004034f5 in videosetup (+0x34f4) (0x0033fda0) 4 0x00402f65 in videosetup (+0x2f64) (0x0033fe04) 5 0x00404a4e in videosetup (+0x4a4d) (0x0033fe90) 6 0x7b8565bc call_process_entry+0xb() in kernel32 (0x0033fea8) 7 0x7b8565bc call_process_entry+0xb() in kernel32 (0x0033fee8) 8 0x7b858a9b start_process+0x5a(peb=0x536430) [/home/vincent/git/wine/dlls/kernel32/process.c:994] in kernel32 (0x0033fef8) 9 0x7bc715f0 call_thread_func+0xb() in ntdll (0x0033ffc8) 10 0x7bc717c0 call_thread_entry_point+0x6f(entry=0x7b858a40, arg=0x7ffdf000) [/home/vincent/git/wine/dlls/ntdll/signal_i386.c:2473] in ntdll (0x0033ffe8) 11 0x7bc4cefa start_process+0x29(kernel_start=0x7b858a40) [/home/vincent/git/wine/dlls/ntdll/loader.c:2610] in ntdll (0x00000000) Points on which I would like opinions: - getting rid of the magic number - need to check after InterlockedDecrement (in doubt I did, but the code is much less readable this way) - couldn't it actually hide a refcount problem in wine ? - if not, then would it be good to extend to other refcounts aswell or include in [a local wrapper for] InterlockedDecrement ? Regards, --- dlls/ddraw/ddraw.c | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-)

2 1

Re: comctl32/treeview: Erase background when painting over supplied hdc
by testbot＠testbot.winehq.org 26 Sep '10

26 Sep '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=5489 Your paranoid android. === W98SE (32 bit treeview) === treeview.c:1293: Test failed: got 0x0

1 0

RFC: Revised patchset to fix Bug 7929 (C&C 3 network does not work)
by Erich Hoover 25 Sep '10

25 Sep '10

I realize it's been some time since I've submitted something for the networking problems with the C&C games, but I believe I've come up with something that resolves the major show-stopping issue that was discussed previously. Here is the original thread, for reference: http://www.winehq.org/pipermail/wine-devel/2009-October/079099.html Specifically, this set of patches is revised to address the problem of throwing away packets destined for the incorrect interface in a multi-threaded/multi-process environment. The approach used here is to create a global (named) POSIX.1-2001 semaphore for each socket with the form wine-ifacelock-FD , where "FD" is the Unix file descriptor corresponding to the socket at hand. These semaphores are only created for UDP sockets bound to a specific interface and are locked/unlocked by both the Wine user-space and the Wine server. These patches are against wine-1.3.3 and are split apart according to function. The most revised portions since the original set are 2/6 (server-side creation of semaphore), 3/6 (locking and unlocking), and 6/6 (server-side locking and unlocking). If I could get some feedback on these patches then I would greatly appreciate it, it'd be really nice to finally get this issue resolved. Thanks in advance! [1/6] ws2_32/tests: Add UDP broadcast tests: http://www.compholio.com/wine-kane/patches/2010-09-18/0001-ws2_32-tests-Add… [2/6] server: Add mechanism for storing an interface ID with a socket: http://www.compholio.com/wine-kane/patches/2010-09-18/0002-server-Add-mecha… [3/6] ws2_32: Patch to selectively bind to interfaces while still allowing broadcast packets: http://www.compholio.com/wine-kane/patches/2010-09-18/0003-ws2_32-Patch-to-… [4/6] ws2_32: Ensure select does not wake up on packets with an interface mismatch: http://www.compholio.com/wine-kane/patches/2010-09-18/0004-ws2_32-Ensure-se… [5/6] ws2_32: Ensure Async WSARecv does not wake up on packets with an interface mismatch: http://www.compholio.com/wine-kane/patches/2010-09-18/0005-ws2_32-Ensure-As… [6/6] server: Ensure Async ReadFile does not wake up on packets with an interface mismatch: http://www.compholio.com/wine-kane/patches/2010-09-18/0006-server-Ensure-As… Erich Hoover ehoover(a)mines.edu

3 6

Request for Assistance/Advice for Richedit EM_SETMARGINS test
by James McKenzie 25 Sep '10

25 Sep '10

All: I've been trying to get the attached patch to pass on both the testbot and a copy of WindowsXP that I possess. It appears that the statement in MSDN that the USEFONTINFO information is either incorrect or I'm doing something wrong. The MSDN page for this information is: http://msdn.microsoft.com/en-us/library/bb761649%28VS.85%29.aspx I remember that WindowsXP does have Richedit 3.0 Thank you. James McKenzie

1 0

Re: [5/5] msxml3/httprequest: Implement ::get_status()
by testbot＠testbot.winehq.org 25 Sep '10

25 Sep '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=5483 Your paranoid android. === W98SE (32 bit domdoc) === domdoc.c:2914: Test failed: got 0x8000ffff domdoc.c:2922: Test failed: got 0x8000ffff domdoc.c:2939: Test failed: got 0x8000ffff domdoc.c:2945: Test failed: got 0x8000ffff domdoc.c:2961: Test failed: got 0x8000ffff domdoc.c:2979: Test failed: got 0x00000000 domdoc.c:3003: Test failed: got 0x8000ffff === W2KPROSP4 (32 bit domdoc) === domdoc.c:2914: Test failed: got 0x8000ffff domdoc.c:2922: Test failed: got 0x8000ffff domdoc.c:2939: Test failed: got 0x8000ffff domdoc.c:2945: Test failed: got 0x8000ffff domdoc.c:2961: Test failed: got 0x8000ffff domdoc.c:2979: Test failed: got 0x00000000 domdoc.c:3003: Test failed: got 0x8000ffff === WXPPROSP3 (32 bit domdoc) === domdoc.c:2979: Test failed: got 0x00000000 === W2K3R2SESP2 (32 bit domdoc) === domdoc.c:2979: Test failed: got 0x00000000 === WVISTAADM (32 bit domdoc) === domdoc.c:2979: Test failed: got 0x00000000 === W2K8SE (32 bit domdoc) === domdoc.c:2979: Test failed: got 0x00000000 === W7PRO (32 bit domdoc) === domdoc.c:2979: Test failed: got 0x00000000 === W7PROX64 (32 bit domdoc) === domdoc.c:2979: Test failed: got 0x00000000 === W7PROX64 (64 bit domdoc) === domdoc.c:2979: Test failed: got 0x00000000

1 0

Re: [3/5] msxml3/httprequest: Add basic bind callback for moniker binding
by testbot＠testbot.winehq.org 25 Sep '10

25 Sep '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=5482 Your paranoid android. === W98SE (32 bit domdoc) === domdoc.c:2914: Test failed: got 0x8000ffff domdoc.c:2930: Test failed: got 0x8000ffff domdoc.c:2936: Test failed: got 0x8000ffff domdoc.c:2964: Test failed: got 0x00000000 domdoc.c:2979: Test failed: got 0x8000ffff === W2KPROSP4 (32 bit domdoc) === domdoc.c:2914: Test failed: got 0x8000ffff domdoc.c:2930: Test failed: got 0x8000ffff domdoc.c:2936: Test failed: got 0x8000ffff domdoc.c:2964: Test failed: got 0x00000000 domdoc.c:2979: Test failed: got 0x8000ffff === WXPPROSP3 (32 bit domdoc) === domdoc.c:2964: Test failed: got 0x00000000 === W2K3R2SESP2 (32 bit domdoc) === domdoc.c:2964: Test failed: got 0x00000000 === WVISTAADM (32 bit domdoc) === domdoc.c:2964: Test failed: got 0x00000000 === W2K8SE (32 bit domdoc) === domdoc.c:2964: Test failed: got 0x00000000 === W7PRO (32 bit domdoc) === domdoc.c:2964: Test failed: got 0x00000000 === W7PROX64 (32 bit domdoc) === domdoc.c:2964: Test failed: got 0x00000000 === W7PROX64 (64 bit domdoc) === domdoc.c:2964: Test failed: got 0x00000000

1 0

Memory Management
by Luis Carlos Busquets Pérez 25 Sep '10

25 Sep '10

Concerning the e-mail http://www.winehq.org/pipermail/wine-devel/2010-April/082900.html it seems that it is broken because in wine there is no way to ensure that the string will be in the lower 2GB. Actually, according to the Windows Memory Management model: http://www.intellectualheaven.com/Articles/WinMM.pdf only the 2 lower Gb are able to be used in user mode in Windows. So actually in Windows OS you have a way to ensure that all user things will be in the lower 2Gb. Is there something similar in WINE, If not, would it not be logical to replicate also that behaviour, so that then d3dxhandle can rely in the MSB? What is more, if there is not that way to ensure that, and I guess that the d3dxx_xx.dll might rely on that to distinguish between strings and d3dxhandle, there might be cases even using the original d3dx, programmes would crash in wine when the wine implementation allocates strings in memory positions where then MSB = 1.

3 2

Re: [2/5] msxml3/httprequest: Implement IXMLHttpRequest::setRequestHeader()
by testbot＠testbot.winehq.org 25 Sep '10

25 Sep '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=5481 Your paranoid android. === W98SE (32 bit domdoc) === domdoc.c:2926: Test failed: got 0x8000ffff domdoc.c:2932: Test failed: got 0x8000ffff domdoc.c:2960: Test failed: got 0x00000000 === W2KPROSP4 (32 bit domdoc) === domdoc.c:2926: Test failed: got 0x8000ffff domdoc.c:2932: Test failed: got 0x8000ffff domdoc.c:2960: Test failed: got 0x00000000 === WXPPROSP3 (32 bit domdoc) === domdoc.c:2960: Test failed: got 0x00000000 === W2K3R2SESP2 (32 bit domdoc) === domdoc.c:2960: Test failed: got 0x00000000 === WVISTAADM (32 bit domdoc) === domdoc.c:2960: Test failed: got 0x00000000 === W2K8SE (32 bit domdoc) === domdoc.c:2960: Test failed: got 0x00000000 === W7PRO (32 bit domdoc) === domdoc.c:2960: Test failed: got 0x00000000 === W7PROX64 (32 bit domdoc) === domdoc.c:2960: Test failed: got 0x00000000 === W7PROX64 (64 bit domdoc) === domdoc.c:2960: Test failed: got 0x00000000

1 0

WineAPI wiki status update
by Max TenEyck Woodbury 25 Sep '10

25 Sep '10

The wiki is at http://sourceforge.net/apps/mediawiki/wineapi/index.php and this address should *not* require a Sourceforge login. At least one person has complained that this project is too Wine specific. They want it to be more generic. I do *not* plan to remove the Wine specific content, but I have labeled it with the prefix 'Wine/' so there will be space for content specific to other projects. I have to admit that the format is pretty UGLY with too much information crammed into too little space. I have received some suggestions on how this can be improved. I intend to act on those suggestions, but not right now. I need to put the content in and assure that it is correct before I get into aesthetics. If someone wants to help with this, let me know. There are now links to every directory and file in the repository and a mechanism is in place to assure that this will continue to be the case. Significant repository entries have their own wiki pages with at least one place where editable content can be added that will not be over-written by the automatic update process. There are also the usual wiki discussion pages. Most of the file related pages are simply place holders at this time, with the exception of '.spec' file pages. Please see the section below on plans before complaining about this. Statistics (very approximate) 400 Directories 3000 Files 55000 APIs identified Plans and problems. The current maintenance process is based on bash scripts with different scripts doing different parts of the analysis. Scheduling is based on a list of work items. The scripts add work items as they are discovered and remove work items as they are finished. If someone wants to try their hand at them, let me know and I'll post them to the wiki. I expect that re-writes in other languages are in order, but I do bash scripts well. My other strong languages are C and C++. I am very interested in learning Python, Perl and others. Some of the pages are HUGE and cause problems when some wiki operations are tried. In particular there are at least two '.spec' files with more than 8000 entries. The scripts need to be taught how to split these monsters into managable pieces. Some of the APIs are class-object based and their names have been mangled in the usual C++ manner. They are currently displayed in their raw form. De-mangling is needed and a separate hierarchy should be established for indexing them. A section in each standard directory has been set aside to hold API descriptions for each executable but are currently empty (and invisible as a result). Once the names have been de-mangled, I plan to fill in these sections. Header and code analysis are on queue after that, as is improving the page format. There are a bunch of old pages without the 'Wine/' prefix. They are being removed. Advice on wiki-bots would be helpful. - Max

1 0