September 2008 - Wine-devel

re: Fixing the conformance tests
by Dan Kegel 07 Sep '08

07 Sep '08

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

07 Sep '08

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

07 Sep '08

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

07 Sep '08

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 06 Sep '08

06 Sep '08

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

Re: modified: dlls/wininet/http.c
by Hans Leidekker 06 Sep '08

06 Sep '08

On Wednesday 03 September 2008 20:33:25 Nerv wrote: > -It seems Windows XP only increments lpdwIndex if the Function returns > true, so it is fixed if you just look on bSuccess This patch is likely correct but please do add a test case to prove your finding. -Hans

1 0

Re: wined3d: Be more careful when deleting FBOs
by Henri Verbeet 06 Sep '08

06 Sep '08

Ignore these, I sent them a few days ago without being subscribed to the list.

1 0

Re: oleaut32: Add support for loading typelibs from NE files.
by Rob Shearman 05 Sep '08

05 Sep '08

2008/9/2 Huw Davies <huw(a)codeweavers.com>: > --- a/dlls/oleaut32/typelib.c > +++ b/dlls/oleaut32/typelib.c > @@ -64,6 +64,7 @@ > #include "winnls.h" > #include "winreg.h" > #include "winuser.h" > +#include "wine/winbase16.h" > > #include "wine/unicode.h" > #include "objbase.h" I don't think we should be including a 16-bit header file and using 16-bit functions in a 32-bit source file if we can avoid it. In this case, we can avoid it. -- Rob Shearman

2 2

Re: msi: Reduce destination file name used in the MoveFiles action to the long file name.
by James Hawkins 05 Sep '08

05 Sep '08

On Fri, Sep 5, 2008 at 4:18 PM, Rob Shearman <robertshearman(a)gmail.com> wrote: > --- > dlls/msi/action.c | 22 ++++++++++++++++------ > 1 files changed, 16 insertions(+), 6 deletions(-) > > There doesn't appear to be any documentation on MSDN suggesting this > behaviour but it fixes the following snippet of a log from a > customised Office 2003 installer: > > 0065:trace:msi:msi_move_file copying > L"C:\\windows\\temp\\~OCW0023.TMP" -> L"C:\\Program Files\\Microsoft > Office\\sfn|custom11.prf" > 0065:Call KERNEL32.CopyFileW(0105f4d0 > L"C:\\windows\\temp\\~OCW0023.TMP",0105f1f8 L"C:\\Program > Files\\Microsoft Office\\sfn|custom11.prf",00000000) ret=7eded205 > 0065:Ret KERNEL32.CopyFileW() retval=00000000 ret=7eded205 > 0065:warn:msi:msi_move_file CopyFile failed: 123 > Can you please add a test case? The test_movefiles already exists, and adding this case shouldn't take more than 5 minutes. -- James Hawkins

2 1

re: Can we import MSConfig from ReactOS?
by Dan Kegel 05 Sep '08

05 Sep '08

Jason Spiro wrote: > Could the Wine team make up a whitelist of trusted ReactOS > developers who won't reverse engineer any Windows code? There is already a whitelist of sorts; look at whom Alexandre accepts patches from. > Or a whitelist of trusted portions of ReactOS...? IMHO it's not worth the effort. - Dan

1 0