September 2008 - Wine-Devel

Debugging applications running on wine
by Kevin K Sept. 9, 2008

Sept. 9, 2008

Is winedbg the only method of debugging applications being developed for Windows on Wine? For instance, assume a program developed with Visual Studio in C or C++, and I needed to debug it on Linux? Thanks, Kevin

1 0

Re: Patchwatcher security improvements
by Ambroz Bizjak Sept. 9, 2008

Sept. 9, 2008

> Also, it's possible some of your changes won't be needed > after the refactoring... I plan to run wine-slave as a different > user anyway... That doesn't solve much; although in may look clean, it is not secure. The user should have a limited amount of resources to work with. Your way, for example, it can write the whole master Wine tree. With my patches, the master tree is read-only for the user, and it only has its own copy to work with which is never used again. I plan to further improve things. In particular, killing stall processes is not implemented securely now. As I have already mentioned, additional access control is needed to produce a fully solid system. For example, disk access should be limited (think about world-writable folders and stuff like ~/.bashrc), and memory usage should be limited as well (could patchwatcher get killed when the patch starts consuming memory?). Considering the refactoring, I see you are just some moving stuff into its own file; I can easily adjust my code.

1 0

re: Patchwatcher security improvements
by Ambroz Bizjak Sept. 8, 2008

Sept. 8, 2008

> Interesting. One of my goals is to support Solaris and BSD; > have you tried your stuff there? Not yet, but that stuff is pretty generic, so it shouldn't be hard to get it to work. > I'm surprised you had to give up on the chroot... > I was planning on trying to run just wine-slave.sh in > a chroot jail, since it's the only part that would > actually try to run any part of the wine build system. Creating the chroot itself is really hard and has to be done for each platform separately. The basic system and also all development tools and Wine dependencies have to be copied properly. And there are the tests with their own bunch of requirements. In the end you would end up with a chroot that is not much different from the base system itself. And it doesn't really bring many security benefits. Many potentially insecure interfaces have to be exposed anyway (/proc, X server with OpenGL, sound hardware). If a clean and dedicated system is used and permissions are properly configured, running stuff on the base system shouldn't really be a problem. Furthermore, using some advanced access control system (like SELinux) would probably be easier to configure and more efficient.

1 0

re: [1/5] secur32: Require gnutls for schannel
by Dan Kegel Sept. 8, 2008

Sept. 8, 2008

> If its easier with gnutls, please use it. +1 I also agree that nss is likely to replace openssl as the toolkit of choice. But if depending on gnutls is the easiest path to a working schannel, that's the right thing to do. We can always change later if a compelling reason arises. - Dan

1 0

Re: user32.dll: Add stub for LockWorkStation
by Rob Shearman Sept. 8, 2008

Sept. 8, 2008

2008/9/8 Paul Chitescu <paulc(a)voip.null.ro>: > /*********************************************************************** >+ * LockWorkStation (USER32.@) >+ */ >+BOOL WINAPI LockWorkStation() This is the right place to put it be the above should be "LockWorkStation(void)" not "LockWorkStation()". -- Rob Shearman

1 0

Re: wininet: InternetQueryOption return size when buffer too small
by James Hawkins Sept. 8, 2008

Sept. 8, 2008

On Mon, Sep 8, 2008 at 5:01 PM, Rotem Zach <rotemz(a)gmail.com> wrote: > > + > + internetQWCheckOption(NULL,INTERNET_OPTION_MAX_CONNS_PER_SERVER,(WCHAR*)"Open: INTERNET_OPTION_MAX_CONNS_PER_SERVER Got wrong length %d instead of %d\n",sizeof(ULONG)); > + internetQWCheckErr(ERROR_INSUFFICIENT_BUFFER,(WCHAR*)"Open: INTERNET_OPTION_MAX_CONNS_PER_SERVER Wrong Error %d Expecting %d\n"); > + > + internetQWCheckOption(NULL,INTERNET_OPTION_MAX_CONNS_PER_1_0_SERVER,(WCHAR*)"Open: INTERNET_OPTION_MAX_CONNS_PER_1_0_SERVER Got wrong length %d instead of %d\n",sizeof(ULONG)); > + internetQWCheckErr(ERROR_INSUFFICIENT_BUFFER,(WCHAR*)"Open: INTERNET_OPTION_MAX_CONNS_PER_1_0_SERVER Wrong Error %d Expecting %d\n"); > + All of these lines are way too long. Please stick close to an 80-col line limit. -- James Hawkins

1 0

winhttp test failures
by James Hawkins Sept. 8, 2008

Sept. 8, 2008

Hi Hans, Tests you added to the file dlls/winhttp/tests/notification.c are causing several test failures across all platforms. Can you please have a look at this? Thanks, James Hawkins

1 0

Re: [1/5] secur32: Require gnutls for schannel
by Marcus Meissner Sept. 8, 2008

Sept. 8, 2008

On Mon, Sep 08, 2008 at 11:10:11PM +0200, Henri Verbeet wrote: > > From cb10664e7d7526951d97f6d9ba2f7429d20b69d4 Mon Sep 17 00:00:00 2001 > From: Henri Verbeet <hverbeet(a)gmail.com> > Date: Mon, 8 Sep 2008 22:39:11 +0200 > Subject: secur32: Require gnutls for schannel > +AC_ARG_WITH(gnutls, AS_HELP_STRING([--without-gnutls],[do not use GnuTLS (schannel support)])) Hmm, I really do not think gnutls will have a long feature, NSS seems to be the future choice of crypto frameworks :/ Ciao, Marcus

3 4

Re: wined3d: Add support for updating part of a compressed surface.
by Henri Verbeet Sept. 8, 2008

Sept. 8, 2008

2008/9/5 Christof Sigel <christof.sigel(a)intenode.on.net>: > + /* since DXT compressed formats are specified in 4x4 pixel blocks devide pitch by 4 */ > + int srcPitch=srcLockedRect.Pitch>>2; > + int destPitch=destLockedRect.Pitch>>2; That will break with DXT1 surfaces. All the DXT formats are specified in 4x4 blocks, but for DXT1 a 4x4 block is 8 bytes, while for the other DXT formats a block is 16 bytes. This also has implications for how you should handle copying row by row, since each row is 4 pixels high. Strictly speaking you should also verify that the pitch exactly corresponds to the surface width before using the "single memcpy" path, since theory the surface layout in memory could look like this: |<----width--->| |<-----------pitch------------>| xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |--------------|xxxxxxxxxxxxxxxx | |xxxxxxxxxxxxxxxx | |xxxxxxxxxxxxxxxx | surface |xxxxxxxxxxxxxxxx | |xxxxxxxxxxxxxxxx | |xxxxxxxxxxxxxxxx | |xxxxxxxxxxxxxxxx |--------------|xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx In other words, for a DXT1 surface with height h, width w and pitch p, you should copy h/4 rows of w*2 bytes, where each row starts at pBits+p*row. For DXT2/3/4/5 you'd copy w*4 bytes for each row. A test for this code would be appreciated.

2 2

Peb->BeingDebugged and a debugger messing up
by Markus Hitter Sept. 8, 2008

Sept. 8, 2008

Hello all, after wrestling severals days with Wine's debugging capabilities I think I need some advice. First, regardless wether my app (Catia) is launched with wine or winedbg, Peb->BeingDebugged is always False. To the best of my efforts I can't find the code snippet which sets this variable or does some sort of probing for the correct value. Oddly enough, the app breaks into the debugger after creation of a new process, anyways. As the app uses a launcher, I have the chance to set BeingDebugged explicitely to True. Some time later, after the app created a few threads, it's back to False. Are there applications out there setting this flag to what they think is best? Any other possible reasons for going BeingDebugged back to False while running in winedbg? None of the functions Wine provides and handles this variable appears to be called by the application. Third thing is, Wine's attempt to auto-launch the debugger messes up. Not only if BeingDebugged is reported wrongly, it obviously runs in conflicts if launched due to a exception stack overflow. Is it really wise to launch it by triggering an interrupt in DbgBreakPoint()? Short of better suggestions, I'd try to make debugger launching independent from Peb->BeingDebugged (server/kernel should know better), try to get rid of the interrupt in DbgBreakPoint() and/or make debugger autolaunching optional (at compile time). What do you think? Thanks, MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/

1 0

Re: imm32: Improve ImmGetCompositionString.
by Paul Vriens Sept. 8, 2008

Sept. 8, 2008

Aric Stewart wrote: > > It should return number of copied bytes. But it always returns required > buffer size to receive all information. > (originally by Kusanagi Kouichi (slash(a)ma.neweb.ne.jp) ) > --- > dlls/imm32/imm.c | 207 > ++++++++++++++++++++++++++++++++++-------------------- > 1 files changed, 130 insertions(+), 77 deletions(-) > > > > ------------------------------------------------------------------------ > > Shouldn't patches like these be accompanied by tests? It changes the behavior after all. -- Cheers, Paul.

2 1

Re: dsound: fix a few failing tests and a crash on 2008
by Paul Vriens Sept. 8, 2008

Sept. 8, 2008

Jeff Zaroyko wrote: > > ------------------------------------------------------------------------ > > I found more or less the same thing for Vista a few days ago. Doing a IDirectSoundBuffer_Release sets the reference counter to zero but doesn't clear secondary. Is this something worthwhile to add a comment for (or a test)? It does seem important as it's a change of behavior starting with Vista? -- Cheers, Paul.

2 1

Re: winemenubuilder: eliminate wineshelllink
by Francois Gouget Sept. 8, 2008

Sept. 8, 2008

On Thu, 4 Sep 2008, Damjan Jovanovic wrote: > Changelog: > * moved the functionality of wineshelllink into winemenubuilder, and > eliminated wineshelllink What is the rational for eliminating wineshelllink? It seems to me that by eliminating it we are losing a lot of flexibility for handling special setups (and there are a lot of these in menuing systems). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Research is the transformation of money to knowledge. Innovation is the transformation of knowledge to money. -- Dr. Hans Meixner

4 4

Re: crypt32: fixed the testGetCertChain tests on Vista.
by James Hawkins Sept. 8, 2008

Sept. 8, 2008

On Sun, Sep 7, 2008 at 5:59 AM, Reece Dunn <msclrhd(a)googlemail.com> wrote: > This fixes these crypt32:chain testGetCertChain tests on Vista and Windows 2008. > - ok(!ret && GetLastError() == ERROR_INVALID_DATA, - "Expected ERROR_INVALID_DATA, got %d\n", GetLastError()); + ok(!ret, "Expected CertGetCertificateChain to fail\n"); + ok(GetLastError() == ERROR_INVALID_DATA || + GetLastError() == CRYPT_E_ASN1_BADTAG /* Vista/win2k8 */, I'm not NACK'ing this patch, but for future reference, please put comments *after* the comma or logical OR marker, and each system condition should be on its own line. I've seen this in several patches recently. While it's syntactically OK, it looks wrong and there's no need for everyone to have to play Find The Comma. Yes there are other places in the code where this happens, but that doesn't make it correct or preferable. For example, the following is significantly easier to read: ok(result == ERROR_BUFFER_TOO_SMALL || result == ERROR_INVALID_USER_BUFFER || /* win98 */ result == ERROR_INVALID_DATA, /* Vista */ "Expected ERROR_BUFFER_TOO_SMALL, got %08d\n", result); than ok(result == ERROR_BUFFER_TOO_SMALL || result == ERROR_INVALID_USER_BUFFER /* win98 */ || result == ERROR_INVALID_DATA /* Vista */, "Expected ERROR_BUFFER_TOO_SMALL, got %08d\n", result); -- James Hawkins

2 3

Re: user32: Resend Check for NULL pData in DdeClientTransAction expectingto be passed a handle
by Dmitry Timoshkov Sept. 8, 2008

Sept. 8, 2008

"Jeff Latimer" <lats(a)yless4u.com.au> wrote: > diff --git a/dlls/user32/dde_client.c b/dlls/user32/dde_client.c > index 99e2d1c..cbbf99a 100644 > --- a/dlls/user32/dde_client.c > +++ b/dlls/user32/dde_client.c > @@ -632,6 +632,15 @@ static WDML_XACT* WDML_ClientQueueExecute(WDML_CONV* pConv, LPVOID pData, DWORD > > TRACE("XTYP_EXECUTE transaction\n"); > > + if (pData == NULL) > + { > + if (cbData == (DWORD)-1) > + pConv->instance->lastError = DMLERR_INVALIDPARAMETER; > + else > + pConv->instance->lastError = DMLERR_MEMORY_ERROR; > + return NULL; > + } Alexandre suggested to use the existing 'if (cbData == (DWORD)-1)' block, not introduce a new one. > @@ -1154,13 +1163,10 @@ HDDEDATA WINAPI DdeClientTransaction(LPBYTE pData, DWORD cbData, HCONV hConv, HS > switch (wType) > { > case XTYP_EXECUTE: > - /* Windows simply ignores hszItem and wFmt in this case */ > - if (pData == NULL) > - { > - pConv->instance->lastError = DMLERR_INVALIDPARAMETER; > - return 0; > - } > + /* Windows simply ignores hszItem and wFmt in this case */ > pXAct = WDML_ClientQueueExecute(pConv, pData, cbData); > + if (pXAct == NULL) > + return 0; > break; The formatting of the above block is strange. Set the tab size in your editor to 8 and you will see the mess. -- Dmitry.

2 2

Fixing the conformance tests
by Paul Vriens Sept. 8, 2008

Sept. 8, 2008

Hi, As we are slowly progressing towards a more green test.winehq.org there are still some conformance tests that fail either on all platforms or with a specific configuration (like IE7). This email is merely to list those and see if the SME's can have a look in these tests. (I didn't put to much effort in stuff below XP and left out user32) Tests with timeouts =================== - dplayx:dplayx fails with a timeout on all windows servers - msi:install fails with a timeout on a lot of windows servers Tests that fail with IE7 installed ================================== - hlink:hlink has a consistent 8 failures on servers with IE7 - mshtml:htmldoc has 8 failures on servers with IE7 (and more, but also on others) - shdocvw:webbrowser has 3 failures on servers with IE7. Tests that fail starting with a specific OS (or level) ====================================================== - msi:package has 16 failures on XP-SP3+ and 16 extra on W2K3-SP2+ - ole32:storage32 has 24 failures on XP-SP3+ and 24 extra on W2K3-SP2+ (both the above have to do with access rights on files) Tests that fail on Windows and succeed on Wine ============================================== - ws2_32:sock has 1 consistent failure on all Windows boxes but not on Wine Tests with failures on all Windows boxes ======================================== - riched20:editor has failures on all boxes - urlmon:protocol either has timeouts or failures on all boxes - urlmon:url fails with 6 consistent failures on all boxes The above is a subset of all the failures and are not the easy ones. There are still loads of tests that fail on only 1 OS or even on 1 server. -- Cheers, Paul.

4 4

Re: itircl: add a stub for DllUnregisterServer
by Austin English Sept. 7, 2008

Sept. 7, 2008

Please ignore this patch. It's not ready, and not sure why it was sent yet... -Austin On Sun, Sep 7, 2008 at 2:08 PM, Austin English <austinenglish(a)gmail.com> wrote: > >

1 0

Re: [PATCH] buffer overflow checking for string functions
by Francois Gouget Sept. 7, 2008

Sept. 7, 2008

On Thu, 4 Sep 2008, Marcus Meissner wrote: [...] > +#if defined(__GNUC__) && (__GNUC__ < 4) > +# define __builtin_object_size(x,y) -1 > +#endif Shouldn't this be: #if !defined(__GNUC__) || (__GNUC__ < 4) To preserve compatibility with non-GNU compilers. > +static inline INT > +WINAPI MultiByteToWideChar_ichk( > + UINT cp,DWORD flags, > + LPCSTR src,INT srclen,INT srcbuflen, > + LPWSTR dst,INT dstlen,INT dstbuflen > +) { > + if ((srclen != -1) && (srcbuflen != -1) && (srcbuflen < srclen)) > + RaiseException(0xC0000409,0x01,0,NULL); It would be nice to issue a trace clarifying the cause of the exception before raising it. Maybe something like this: TRACE("used %d as the size when >= %d is needed for the builtin object\n", ...); Sending it to the seh channel would be best. [...] > +#define MultiByteToWideChar(cp,flags,src,srclen,dst,dstlen) \ > + MultiByteToWideChar_ichk(cp,flags, \ > + src,srclen,__builtin_object_size(src,0), \ > + dst,dstlen,__builtin_object_size(dst,0) \ > + ) I have a few other concerns here: * Why do we need a macro here? I thought it was so that __builtin_object_size() could do its work, but the strcpy() functions above in the patch have no associated macro and they call __builtin_object_size() on their parameter which would seem to be poinless. So I must be misunderstanding something here. * It's customary to add some extra parenthesing in such macros: (src),(srclen),__builtin_object_size((src),0), * The macro itself can cause trouble in some cases. In Winelib code it can cause naming collisions with user functions (especially with class methods, though it may not be very likely here), which would especially be an issue with strcpy*(). Maybe it should be protected by something like a WINE_NO_OVERFLOW_CHECK macro? * The macro can also cause trouble in case its parameters have side-effects, like x++ or similar (though the __builtin_object_size() mentions returning -1 in case or side-effects). This could impact Wine too. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Computers are like airconditioners They stop working properly if you open WINDOWS

3 2

Changing configure.ac script
by Nikolay Sivov Sept. 7, 2008

Sept. 7, 2008

Is there any way not to include a regenerated 'configure' script into a patch but be able to 'git fetch' it when it's changed remotely in repo? As I see there is no need to patch a 'configure' file in repository since it's always regenerated when 'configure.ac' changed. Thanks in advance.

2 4

1st resend: Can we import MSConfig from ReactOS? (was: autorun perhaps dangerous)
by Jason Spiro Sept. 7, 2008

Sept. 7, 2008

(Hi Alexandre. I sent the below email 2 weeks ago and didn't get a response yet. I know you are busy, but please do try to find the time to reply, even if it's to say "I'm not sure". Cheers, --Jason) cc: wine-devel(a)winehq.org Hi Alexandre, In January 2008, Steven Edwards wondered[1] if you would let Wine import "msconfig" (the System Configuration Utility) from ROS. Would you allow it? Thanks, --Jason Spiro (not a Wine developer) ^ [1]. http://news.gmane.org/find-root.php?message_id=%3c19e31a080801122302u52d513… -- Jason Spiro: software/web developer, trainer, IT consultant. I support Linux, UNIX, Windows, and more. Contact me to discuss your needs and get a free estimate. +1 (613) 668-6096 / info(a)jspiro.com

4 5

re: Fixing the conformance tests
by Dan Kegel Sept. 7, 2008

Sept. 7, 2008

Paul V. wrote: > As we are slowly progressing towards a more green > test.winehq.org there are still some conformance tests > that fail either on all platforms or with a specific configuration (like IE7). Here's some data. On my new box (CPU: Core 2 Duo e8400, graphics: nVidia Corporation GeForce 8500 GT (rev a1) window manager: metacity 2.25.0 built from source) distro: 32 bit Hardy), out of 212 full runs of 'make -k test', here's a count of failures by test name: 6 d3d9 device 6 comdlg32 printdlg 8 wininet http 14 kernel32 thread 19 comctl32 tooltips 24 ddraw visual 32 riched20 editor 46 user32 win 137 user32 input 215 user32 msg 216 dsound ds3d 216 winmm wave 216 urlmon protocol 216 dsound ds3d8 In my perfect world, those tests would all pass, every time, even if you ran them 100 times. That would make patchwatcher a lot more useful, since then it wouldn't have to blacklist these tests. Here's a little script to tickle just the flaky tests I found: #!/bin/sh try() { cd dlls/$1/tests rm $2.ok make $2.ok cd ../../.. } set -e set -x while true do try comctl32 tooltips try comdlg32 printdlg try d3d9 device try ddraw visual try dsound ds3d8 try kernel32 thread try riched20 editor try user32 input try user32 win try wininet http done This aborts for me in just five seconds. Can *anyone* run it for an hour without failure? If so, how can I duplicate your setup? - Dan

4 5

Re: wineboot: Basic RunOnceEx support v2 (with patch)
by Dmitry Timoshkov Sept. 7, 2008

Sept. 7, 2008

"Johan Dahlin" <jdahlin(a)gmail.com> wrote: > +typedef HRESULT WINAPI (*DLLREGISTER) (void); > +typedef HRESULT WINAPI (*DLLINSTALL) (BOOL,LPCWSTR); This is still not right, have a look at other places that use pointers to the exported win32 APIs. > +typedef enum { > + ROEF_DISABLED = 0x00000000, > + ROEF_SHELLSTATUS = 0x00000004, > + ROEF_NOERRORDIALOGS = 0x00000008, > + ROEF_ERRORLOG = 0x00000010, > + ROEF_EXECUTELOG = 0x00000020, > + ROEF_NOEXCTRAP = 0x00000040, > + ROEF_NOSTATUSDIALOG = 0x00000080 > +} RunOnceExFlags; Please use 4 spaces as an indentation like existing code does, here and everywhere else. > +static VOID *LoadProc(WCHAR* strDllW, const char* procName, HMODULE* DllHandle) > +{ > + VOID* (*proc)(void); Why not use just 'void *' as a type for proc, since that's what you are casting it to and returning to the caller anyway? Also using 'VOID' instead of 'void' is not justified. -- Dmitry.

1 0

Re: Patchwatcher: failed regression tests: [6/10 AcceptEx] Implements sock_close_handle
by Scott Lindeneau Sept. 7, 2008

Sept. 7, 2008

I don't understand, this patch doesn't cause any regressions on my machine using the latest git (none of them do). The patch[6/10] is (nearly) identical to the patch I submitted earlier (which did not cause regressions). The only difference is in the hash. The next patch[7/10] changes zero functionality because the function that is implemented in [7/10] is unused at this point in time and patch [7/10] passes the conformance tests. scott(a)SocialSycotic:~/programming/wine/wine/patch$ diff 9.7.2/0006-Implements-sock_close_handle.txt 9-4.7/0006-Implements-sock_close_handle.txt 1c1 < From 40ae4098b66df1cb30dc77368ccfc1c495bb0b68 Mon Sep 17 00:00:00 2001 --- > From d1e0353beb8490bbd9b8818523c6d79daae510ff Mon Sep 17 00:00:00 2001 scott(a)SocialSycotic:~/programming/wine/wine/patch$ Using only patches [1/10 - 6/10] (The patches applied by patchwatcher when it displays the failure): ../../../tools/runtest -q -P wine -M urlmon.dll -T ../../.. -p urlmon_test.exe.so protocol.c && touch protocol.ok fixme:wininet:InternetLockRequestFile STUB fixme:wininet:InternetLockRequestFile STUB fixme:wininet:InternetLockRequestFile STUB fixme:wininet:InternetLockRequestFile STUB ../../../tools/runtest -q -P wine -M urlmon.dll -T ../../.. -p urlmon_test.exe.so stream.c && touch stream.ok As for the conformance test. I will look into how I have to change the sock.c test loop. ~Scott On Sun, Sep 7, 2008 at 9:14 AM, Dan Kegel <dank(a)kegel.com> wrote: > This is interesting. It does seem like that patch changed > an error code and added a new failure to urlmon:protocol.c. > Was this just a case of "I should have combined two of the > patches in the series"? > > BTW, if you end up resending the patch series again, > you might send the test case first (with todo_wine's), > and then after the errors are fixed, remove the todo_wine's. > > > On Sat, Sep 6, 2008 at 4:42 PM, Patchwatcher <patchwatcher(a)kegel.com> wrote: >> Hi! This is the experimental automated wine patchwatcher thingy. >> The latest git sources were built and tested with your patch >> "[6/10 AcceptEx] Implements sock_close_handle" >> Result: the patch failed regression tests. >> >> You can retrieve the full build results at >> http://kegel.com/wine/patchwatcher/results/1162.log >> and see the patch as parsed at >> http://kegel.com/wine/patchwatcher/results/1162.txt >> See >> http://kegel.com/wine/patchwatcher/results >> for more info. >> >> >

2 2

Re: [1/2] hlink/tests: display the expected data, as well as the actual data.
by James Hawkins Sept. 7, 2008

Sept. 7, 2008

On Sun, Sep 7, 2008 at 4:56 AM, Reece Dunn <msclrhd(a)googlemail.com> wrote: > This improves the error reporting for the hlink tests. > I think you need to think this one over. Why would we care to display the expected data, when the expected data is in the tests? For simple tests, e.g. last errors or simple integer results, displaying the expected data makes it easier to understand the returned value. On the other hand, for the hlink tests, the expected binary data adds no value to the output. -- James Hawkins

2 1

re: [3/10 AcceptEx] Modifies accept_socket, allows it to take sock structures instead of handles
by Dan Kegel Sept. 6, 2008

Sept. 6, 2008

This patch seemed to cause wineserver to crash. See http://kegel.com/wine/patchwatcher/results http://kegel.com/wine/patchwatcher/results/1033.log http://kegel.com/wine/patchwatcher/results/1034.log

2 2