- wine-devel - winehq.org

Re: ntdll: rtlstr.c: Implement checking for control characters in RtlIsTextUnicode [try 2]
by John Klehm 19 Jun '08

19 Jun '08

On Wed, Jun 18, 2008 at 7:02 PM, Zac Brown <zac(a)zacbrown.org> wrote: > Implement setting of IS_TEXT_UNICODE_CONTROLS and > IS_TEXT_UNICODE_REVERSE_CONTROLS when control characters are present > in RtlIsTextUnicode. > > Just a minor point: AFAIK the rule is to use C style /* comments */ only. --John Klehm

2 1

Re: user32:msg: Test for SetFocus
by Dmitry Timoshkov 19 Jun '08

19 Jun '08

"Anatoly Lyutin" <vostok(a)etersoft.ru> wrote: > I try to make this test (in test_ShowWindow : "/* 32 */ { SW_HIDE, TRUE, > 0, WmHide_3, TRUE }, ") passes clear and after some changes I observe > that SetFocus() is working strange for some case. > After this I wrote a test case for SetFocus(). SetFocus() have one > incorrect behavior for working of combination ( visible-invisible parent > or child). The test actually doesn't do anything useful. It doesn't check any focus windows and many vital message parameters. Besides we already have test_SetFocus() in win.c. -- Dmitry.

2 5

Re: urlmon: Fix a test that fails on all platforms [RESEND]
by Alexandre Julliard 19 Jun '08

19 Jun '08

"James Hawkins" <jhawkins(a)codeweavers.com> writes: > Anything wrong with this patch? ../../../tools/runtest -q -P wine -M urlmon.dll -T ../../.. -p urlmon_test.exe.so url.c && touch url.ok url.c:2309: Test succeeded inside todo block: bctx should not be destroyed here make: *** [url.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Development plans
by Alexandre Julliard 19 Jun '08

19 Jun '08

Eric Pouech <eric.pouech(a)orange.fr> writes: > how to you plan to handle patches that don't commit cleanly ? > do you, by design of the process, intend to drop them (id est: drop > every bug fixes that come after a functional change in the same area > of code), or do you plan to handle yourself the task of retrofit ? If a patch can't be made to apply then I'll ask the author to merge it, but for 1.0.1 that shouldn't happen, we won't be diverging that fast. And once backporting starts to become too painful then it will be time to make a new stable release. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: mapi32: stop crash under win98
by Paul Vriens 19 Jun '08

19 Jun '08

Alistair Leslie-Hughes wrote: > Hi, > I just added a check for a null pointer since we deference it. > > Changelog: > mapi32: stop crash under win98 > > Best Regards > Alistair Leslie-Hughes > > > > ------------------------------------------------------------------------ > > + if(lpResProp->Value.MVszA.lppszA) + { + ok(lpResProp->Value.MVszA.lppszA[0] == buffer + sizeof(SPropValue) + sizeof(char*), + "wrong lppszA[0] %p\n",lpResProp->Value.MVszA.lppszA[0]); + ok(!strcmp(lpResProp->Value.MVszA.lppszA[0], szTestA), + "wrong string '%s'\n", lpResProp->Value.MVszA.lppszA[0]); + } + else + { + skip("lpResProp->Value.MVszA.lppszA is NULL"); + } I'm not sure if skip() is appropriate here as we are not skipping a function call and we're not skipping subsequent function calls because of this. If Win98 is plainly wrong, and the test maybe has to be changed, here it should probably be: ok(0, "lpResProp->Value.MVszA.lppszA is NULL"); If it's perfectly valid for win98 to return that NULL value is should probably be a trace() as we still have to overcome the dereferencing. -- Cheers, Paul.

1 0

Re: gdi32: stop crash in font tests (try 3)
by Dmitry Timoshkov 19 Jun '08

19 Jun '08

"Alistair Leslie-Hughes" <leslie_alistair(a)hotmail.com> wrote: > - if (!*font_name && font_charset == DEFAULT_CHARSET) /* do it only once */ > + /* EnumFontFamilies with the NULL parameter crashes win98 */ > + if (pGetGlyphIndicesW && !*font_name && font_charset == DEFAULT_CHARSET) /* do it only once */ You are excluding NT4 again. Why don't you simply use unicode version of EnumFontFamilies in this if() block? -- Dmitry.

1 0

Re: ntdll: rtlstr.c: Implement checking for control characters in RtlIsTextUnicode
by Zac Brown 18 Jun '08

18 Jun '08

Zac Brown wrote: > Implement setting of IS_TEXT_UNICODE_CONTROLS and > IS_TEXT_UNICODE_REVERSE_CONTROLS when control characters are present > in RtlIsTextUnicode. > > > ------------------------------------------------------------------------ > > --- > dlls/ntdll/rtlstr.c | 54 ++++++++++++++++++++++++++++++++++++++++++++- > dlls/ntdll/tests/rtlstr.c | 2 - > 2 files changed, 53 insertions(+), 3 deletions(-) > > diff --git a/dlls/ntdll/rtlstr.c b/dlls/ntdll/rtlstr.c > index deec931..2191825 100644 > --- a/dlls/ntdll/rtlstr.c > +++ b/dlls/ntdll/rtlstr.c > @@ -1591,8 +1591,26 @@ NTSTATUS WINAPI RtlFindCharInUnicodeString( > */ > BOOLEAN WINAPI RtlIsTextUnicode( LPCVOID buf, INT len, INT *pf ) > { > + /* lookup table for Unicode values of control chars */ > + static const WCHAR control_chars[] = { > + '\t', > + '\r', > + '\n', > + ' ', > + 0x3000 // CJK space > + }; > + > + /* lookup table for byte-reversed Unicode values of control chars */ > + static const WCHAR reversed_control_chars[] = { > + 0x0900, // tab > + 0x0d00, // carriage return > + 0x0a00, // new line > + 0x2000, // space > + 0x0030 // CJK space > + }; > + > const WCHAR *s = buf; > - int i; > + int i, j; > unsigned int flags = ~0U, out_flags = 0; > > if (len < sizeof(WCHAR)) > @@ -1650,6 +1668,40 @@ BOOLEAN WINAPI RtlIsTextUnicode( LPCVOID buf, INT len, INT *pf ) > } > } > > + /* > + * Check for unicode control characters, both standard and byte reversed. > + * ie: (space, tab, carriage return, line feed, CJK space. > + */ > + > + for (i = 0; i < len; i++) > + { > + if ((flags & IS_TEXT_UNICODE_CONTROLS)) > + { > + if (s[i] == control_chars[0] || > + s[i] == control_chars[1] || > + s[i] == control_chars[2] || > + s[i] == control_chars[3] || > + s[i] == control_chars[4]) > + { > + out_flags |= IS_TEXT_UNICODE_CONTROLS; > + break; > + } > + } > + > + if ((flags & IS_TEXT_UNICODE_REVERSE_CONTROLS) && (out_flags & IS_TEXT_UNICODE_REVERSE_SIGNATURE)) > + { > + if (s[i] == reversed_control_chars[0] || > + s[i] == reversed_control_chars[1] || > + s[i] == reversed_control_chars[2] || > + s[i] == reversed_control_chars[3] || > + s[i] == reversed_control_chars[4]) > + { > + out_flags |= IS_TEXT_UNICODE_REVERSE_CONTROLS; > + break; > + } > + } > + } > + > if (pf) > { > out_flags &= *pf; > diff --git a/dlls/ntdll/tests/rtlstr.c b/dlls/ntdll/tests/rtlstr.c > index aa4a391..5d77f9a 100644 > --- a/dlls/ntdll/tests/rtlstr.c > +++ b/dlls/ntdll/tests/rtlstr.c > @@ -1689,7 +1689,6 @@ static void test_RtlIsTextUnicode(void) > > flags = IS_TEXT_UNICODE_UNICODE_MASK; > ok(pRtlIsTextUnicode(unicode, sizeof(unicode), &flags), "Text should not pass a Unicode\n"); > - todo_wine > ok(flags == (IS_TEXT_UNICODE_STATISTICS | IS_TEXT_UNICODE_CONTROLS), > "Expected flags 0x6, obtained %x\n", flags); > > @@ -1718,7 +1717,6 @@ static void test_RtlIsTextUnicode(void) > > flags = IS_TEXT_UNICODE_REVERSE_MASK; > ok(!pRtlIsTextUnicode(be_unicode, sizeof(unicode) + 2, &flags), "Reverse endian should be Unicode\n"); > - todo_wine > ok(flags == (IS_TEXT_UNICODE_REVERSE_CONTROLS | IS_TEXT_UNICODE_REVERSE_SIGNATURE), > "Expected flags 0xc0, obtained %x\n", flags); > HeapFree(GetProcessHeap(), 0, be_unicode); > > > ------------------------------------------------------------------------ > > Ignore this patch, aside from tabs, it needs something changed. Thanks, Zac

1 0

Re: Development plans
by Steven Edwards 18 Jun '08

18 Jun '08

On Wed, Jun 18, 2008 at 3:31 PM, Eric Pouech <eric.pouech(a)orange.fr> wrote: > how to you plan to handle patches that don't commit cleanly ? > do you, by design of the process, intend to drop them (id est: drop > every bug fixes that come after a functional change in the same area of > code), or do you plan to handle yourself the task of retrofit ? > A+ I think the person that submits the patch should take the effort to make sure the fix applies to 1.0.x if they care about it and post a patch for that to the bug also. If there is backporting work involved in getting it to apply I don't think its reasonable to expect that to be multiplied by hundreds or thousands of patches. Perhaps we could switch to something like the Linux kernel maintenance system where after a certain point, maybe when 1.1 is tagged, Alexandre turns the 1.0 branch over to someone, so that if say a third party vendor has built an application around 1.0.x, there is a public place where such patches can be maintained. Rather than maintenance of the branch just abruptly ending when 1.1 is tagged it would gradually tapper off as those vendors switch to 1.1. Assuming a larger winelib application, some vendor may want to continue to share patches for 1.0 for 3 to 5 years. I don't know if Alexandre will want to maintain 1.0.x for that long assuming 1.1 1.2 1.3 have been tagged or we've moved on to 2.0 -- 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

1 1

Re: ntdll: rtlstr.c: Implement checking for control characters in RtlIsTextUnicode
by James Hawkins 18 Jun '08

18 Jun '08

On Wed, Jun 18, 2008 at 5:10 PM, Zac Brown <zac(a)zacbrown.org> wrote: > Implement setting of IS_TEXT_UNICODE_CONTROLS and > IS_TEXT_UNICODE_REVERSE_CONTROLS when control characters are present > in RtlIsTextUnicode. > You've mixed tabs and spaces in this patch. -- James Hawkins

1 0

Re: Wine release 1.0
by Peter Bortas 18 Jun '08

18 Jun '08

Thanks for the code thus far! Wine has helped me many times throughout the years. -- Peter Bortas

1 0

Re: [31/44] richedit: Set error codes and stop parsing for some rtf syntax errors.
by Rob Shearman 18 Jun '08

18 Jun '08

Dylan Smith wrote: > + if (!inStream.editstream->dwError && parser.stackTop > 0) > + inStream.editstream->dwError = -2147024858; This should be HRESULT_FROM_WIN32(ERROR_HANDLE_EOF). -- Rob Shearman

2 1

Re: [19/44] user32: Increased area for scrolling via mouse drag outside scrollbar
by Rob Shearman 18 Jun '08

18 Jun '08

Dylan Smith wrote: > + /* Distance beside or past the ends the scrollbar for the mouse can be dragged > + * away from scrollbar and still be considered in the scrollbar. */ > +#define SCROLL_DRAG_ZONE_PADDING_BESIDE 138 > +#define SCROLL_DRAG_ZONE_PADDING_PAST_END 34 This should be a proportion of the scrollbar width/height instead of absolute values in pixels. -- Rob Shearman

2 1

Re: [PATCH 2/2] shell32: SHFileOperation can move several files into one directory
by Vitaly Perov 18 Jun '08

18 Jun '08

> The move operation can already do this. Why is this patch necessary? > The test you sent in already passes, so this 'fix' is not being tested > at all. I've checked my test again. It fails! $ wine shell32_test.exe.so shlfileop So, the result is: shlfileop.c:171: Test failed: SHGetFileInfoA(c:\nonexistent | SHGFI_ATTRIBUTES) failed shlfileop.c:178: Test failed: SHGetFileInfoA(c:\nonexistent | SHGFI_EXETYPE) returned 0 shlfileop.c:1230: Test failed: Expected ERROR_SUCCESS, got 1223 shlfileop.c:1231: Test failed: Expected one.txt to not exist shlfileop.c:1232: Test failed: Expected one2.txt to not exist shlfileop.c:1233: Test failed: Expected one.txt to exist shlfileop.c:1234: Test failed: Expected one.txt to exist shlfileop: 582 tests executed (0 marked as todo, 7 failures), 0 skipped. Could you check it again, please. -- Best wishes, Vitaly Perov Russia, Saint-Petersburg. www.etersoft.ru

2 1

Re: gdi32: Add a test for outline text metrics
by Alexandre Julliard 18 Jun '08

18 Jun '08

Dmitry Timoshkov <dmitry(a)codeweavers.com> writes: > Changelog: > gdi32: Add a test for outline text metrics. This doesn't work for me: ../../../tools/runtest -q -P wine -M gdi32.dll -T ../../.. -p gdi32_test.exe.so font.c && touch font.ok font.c:248: Test failed: expected scale_x 1, scale_y 1, got cx 0, cy 1 font.c:254: Test failed: max width 5502 != 5515 font.c:267: Test failed: cx 9878 != 9902 font.c:1459: Tests skipped: Symbol or Wingdings is not installed font.c:1475: Tests skipped: Symbol or Wingdings is not installed font.c:1583: Tests skipped: Symbol is not installed font.c:2237: Tests skipped: Arial Black or Symbol/Wingdings is not installed font.c:1793: Tests skipped: Font DejaVu Sans doesn't contain 'x', skipping the test font.c:1793: Tests skipped: Font DejaVu Sans Condensed doesn't contain 'x', skipping the test font.c:1793: Tests skipped: Font OpenSymbol doesn't contain 'x', skipping the test make[2]: *** [font.ok] Error 3 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: richedit: resend 01 [Fwd: richedit: fix misreporting of match offset for EM_FINDTEXT and EM_FINDTEXTEX]
by Alexandre Julliard 18 Jun '08

18 Jun '08

Alex Villacís Lasso <a_villacis(a)palosanto.com> writes: > -- > perl -e '$x=2.4;print sprintf("%.0f + %.0f = %.0f\n",$x,$x,$x+$x);' > > From: Alex Villacís Lasso <a_villacis(a)palosanto.com> > Subject: richedit: fix misreporting of match offset for EM_FINDTEXT and EM_FINDTEXTEX > To: wine-patches(a)winehq.org > Date: Fri, 2 May 2008 13:01:49 -0500 (ECT) > > Forward search that spans across more than one run in a single paragraph > could report with an incorrect offset, due to the use of the last examined > run rather than the start-of-search run. > > Changelog: > * Fix misreporting of match offset for EM_FINDTEXT and EM_FINDTEXTEX > * Added test that failed until bug was fixed. Could you please resend the patches from scratch instead of forwarding your previous mail to the list again? It's a pain to extract the proper data from the embedded mail. Thanks. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/2] shell32: SHFileOperation can move several files into one directory
by Vitaly Perov 18 Jun '08

18 Jun '08

> The move operation can already do this. Why is this patch necessary? > The test you sent in already passes, so this 'fix' is not being tested > at all. Really? I'm sorry! I was testing at old version of wine. Thank you very much! I'll test it again! -- Best wishes, Vitaly Perov Russia, Saint-Petersburg. www.etersoft.ru

1 0

Valgrind status: 142 errors left
by Dan Kegel 18 Jun '08

18 Jun '08

Changes since yesterday: - added suppression for one more load order memory leak - added one patch by Lei, one by Andrew Tablot, and one by me This gets us down from 205 to 142. The huge reduction was due to http://kegel.com/wine/valgrind/logs-2008-06-17-patches/dank/dsound-primary-… which exposes a problem to the dsound unit tests, and lets them fail instead of continuing with invalid data. That's the last of the huge reductions, I think. (Please join the party! We can use all the help we can get getting rid of these bugs; though many are innocuous to users, a few aren't, and they're all annoying to anyone using valgrind. It remains to be seen how many of these patches Alexandre will accept after 1.0 is out, but I'm hopeful we can get most of them up to his standards.) Report showing unique nonleak errors: http://kegel.com/wine/valgrind/logs-2008-06-17.counts.txt Logs: http://kegel.com/wine/valgrind/logs-2008-06-17.log.gz http://kegel.com/wine/valgrind/logs-2008-06-17/ Pending wine patches: http://kegel.com/wine/valgrind/logs-2008-06-17-patches/ http://kegel.com/wine/valgrind/logs-2008-06-17-patches.tgz http://kegel.com/wine/valgrind/logs-2008-06-17-patch.txt Suppression file: http://kegel.com/wine/valgrind/valgrind-suppressions

1 0

Re: gdi32: stop font tests crashing under win98 (try 2)
by Dmitry Timoshkov 18 Jun '08

18 Jun '08

"Alistair Leslie-Hughes" <leslie_alistair(a)hotmail.com> wrote: > - if (!*font_name && font_charset == DEFAULT_CHARSET) /* do it only once */ > + /* EnumFontFamilies with the NULL parameter crashes win98 */ > + if (pGetCharABCWidthsW && !*font_name && font_charset == DEFAULT_CHARSET) /* do it only once */ Have you actually tested this? GetCharABCWidthsW is exported by gdi32.dll in Win9x. -- Dmitry.

1 0

Re: gdi32: stop font tests crashing under win98 (try 2)
by Paul Vriens 18 Jun '08

18 Jun '08

Alistair Leslie-Hughes wrote: > Hi, > use a unicode mapped function to stop a test from running under win98 > > Changelog: > gdi32: stop font tests crashing under win98 > > Best Regards > Alistair Leslie-Hughes > > > ------------------------------------------------------------------------ > > + + if(!pGetGlyphIndicesA) + return; Could you add a win_skip to this? -- Cheers, Paul.

1 0

Re: msxml3: Improved checking of failed case
by Paul Vriens 18 Jun '08

18 Jun '08

Alistair Leslie-Hughes wrote: > Hi, > > Changelog: > msxml3: Improved checking of failed case > > Best Regards > Alistair Leslie-Hughes > > > ------------------------------------------------------------------------ > > - /* Win98 returns ERROR_URL_NOT_FOUND */ - ok(hr == S_OK || hr == ERROR_URL_NOT_FOUND, "Expected S_OK, got 0x%08x\n", hr); + ok(hr == S_OK, "Expected S_OK, got 0x%08x\n", hr); But this means the test will fail on Win98, is that on purpose? -- Cheers, Paul.

2 1

Re: [PATCH] shell32: SHFileOperation can move several files into one directory
by James Hawkins 18 Jun '08

18 Jun '08

2008/6/17 Vitaly Perov <vitperov(a)etersoft.ru>: > The test was sent 2 hours ago > If FOF_MULTIDESTFILES flag is set it's not olny mean that pTo contains > multiple destination files, it also can contain one folder. > > Changelog: > - shell32: SHFileOperation can move several files into one directory > --- a/dlls/shell32/shlfileop.c +++ b/dlls/shell32/shlfileop.c @@ -1426,7 +1426,8 @@ static HRESULT move_files(LPSHFILEOPSTRUCTW lpFileOp, const FILE_LIST *flFrom, c return ERROR_CANCELLED; if ((lpFileOp->fFlags & FOF_MULTIDESTFILES) && - flFrom->dwNumFiles != flTo->dwNumFiles) + flFrom->dwNumFiles != flTo->dwNumFiles && + !IsAttribDir(fileDest->attributes)) { return ERROR_CANCELLED; } There is a glaring error right here. For one, you should heed compiler warnings: wine/dlls/shell32/shlfileop.c: In function 'SHFileOperationW': wine/dlls/shell32/shlfileop.c:1428: warning: 'fileDest' is used uninitialized in this function wine/dlls/shell32/shlfileop.c:1407: note: 'fileDest' was declared here You're using fileDest when it hasn't been initialized (as the warning says). Second, the tests fail: shlfileop.c:1132: Test failed: The file is not moved - many files are specified as a target shlfileop.c:1206: Test failed: Expected d.txt to not exist make: *** [shlfileop.ok] Error 2 -- James Hawkins

2 1

Remove LATER and REMIND bug resolutions
by Lei Zhang 18 Jun '08

18 Jun '08

Hi, It's been a week and nobody has responded to Dmitry's bug report [1] yet, so I'm going to bring it up here. I am all for it, does anyone have objections? - Lei [1] http://bugs.winehq.org/show_bug.cgi?id=13794

1 0

re: Fix DirectSound's primary buffer Volume and Pan handling
by Dan Kegel 18 Jun '08

18 Jun '08

On Jul 23, 2004, Francois Gouget wrote: > The patch removes the primary buffer's 'volpan' variable and instead > uses waveOutGetVolume() on dsound->hwo to get the current volume. This seems to be failing for me here on three different machines during the primary part of test_secondary() in dsound/tests/ds3d.c. You can see evidence of this in valgrind logs, e.g. http://kegel.com/wine/valgrind/logs-2007-12-06/vg-dsound_ds3d.txt or http://kegel.com/wine/valgrind/logs-2008-06-16/vg-dsound_ds3d.txt you can see valgrind getting annoyed that waveOutGetVolume didn't actually retrieve anything: Conditional jump or move depends on uninitialised value(s) at DSOUND_AmpFactorToVolPan (mixer.c:66) by PrimaryBufferImpl_GetVolume (primary.c:646) by test_secondary (ds3d.c:864) by dsenum_callback (ds3d.c:1303) by DirectSoundEnumerateA (dsound_main.c:315) by ds3d_tests (ds3d.c:1324) by func_ds3d (ds3d.c:1344) by run_test (test.h:449) by main (test.h:498) Uninitialised value was created by a stack allocation at PrimaryBufferImpl_GetVolume (primary.c:627) The test nevertheless happens to succeed on some machines, but not others. One machine it fails on (even without valgrind) says ds3d.c:896: Test failed: The primary pan changed from 673 to 656 because, I think, it's calculating the pan based on random values on the stack. A +dsound,+alsa,+wave log (and a few extra trace statements) shows trace:dsound:PrimaryBufferImpl_GetPan (0x132258,0x32fa48) trace:wave:ALSA_wodMessage (0, WODM_GETVOLUME, 00000000, 0032F8E4, 00000000); trace:wave:wodGetVolume (0, 0x32f8e4); trace:wave:wodGetVolume wDevId 0, hctl (nil) trace:alsa:ALSA_CheckSetVolume line 470; hctl (nil) trace:wave:wodGetVolume CheckSetVolume failed; rc 8 trace:dsound:DSOUND_AmpFactorToVolPan (0x32f8c8) trace:dsound:DSOUND_AmpFactorToVolPan left=3b34, right=7e59 trace:dsound:DSOUND_AmpFactorToVolPan Vol=-611 Pan=656 ds3d.c:896: Test failed: The primary pan changed from 673 to 656 ALSA_CheckSetVolume returns right early because hctl is NULL. I threw together a small test illustrating the problem; see the attached patch and log from problem machine. (Note that sound works on this machine, and running the main ds3d tests with WINETEST_INTERACTIVE=1 yields many tones in the headphones.) Could somebody who knows this code have a look? Thanks! - Dan

2 1

Re: Wine release 1.0
by John Freed 17 Jun '08

17 Jun '08

Congratulations!!!!!!!!! On Tue, Jun 17, 2008 at 4:20 PM, Alexandre Julliard <julliard(a)winehq.org> wrote: > The Wine team is proud to announce that Wine 1.0 is now available. > This is the first stable release of Wine after 15 years of development > and beta testing. Many thanks to everybody who helped us along that > long road! > > While compatibility is not perfect yet, thousands of applications have > been reported to work very well. Check http://appdb.winehq.org to see > the details for your favorite applications. > > The source is available from the following locations: > > http://ibiblio.org/pub/linux/system/emulators/wine/wine-1.0.tar.bz2 > http://prdownloads.sourceforge.net/wine/wine-1.0.tar.bz2 > > Binary packages for various distributions will be available from: > > http://www.winehq.org/site/download > > You will find documentation on http://www.winehq.org/site/documentation > > You can also get the current source directly from the git > repository. Check http://www.winehq.org/site/git for details. > > Wine is available thanks to the work of many people. See the file > AUTHORS in the distribution for the complete list. > > ---------------------------------------------------------------- > > Bugs fixed in 1.0: > > 3838 The Punisher demo crashes after the introduction movies > 3898 Counter-Strike 1.6 performance issue > 4755 X Error of failed request: BadDrawable (X_PolyFillRectangle) when > switching to Virtual Desktop > 6315 Starlancer draws ships as white when direct3d is enabled > 7268 Oni not opening after install > 8185 can't login in Skype 3.1 on wine/kubuntu 7 > 8634 antialiasing disabled in gtasa menu > 9555 Wine crash when I click help in Stata 10 > 9589 Static / Scratchy Sound with OSS in Call of Duty > 9903 WinRAR with NXServer - black icons > 10009 QIP: window z-order is still wrong > 10268 Robot Wars: Arena of Destruction crashes while quitting (causing > resolution to stay 640 x 480) > 10322 Eve-online (video memory misaddressed?) > 10700 Dragon Naturally Speaking 9 needs gdiplus.GdipDrawArcI, > gdiplus.GdipCreatePen2, ... > 11011 Call of Duty 1.0 doesn't run after install. > 11104 Dance Praise 2: Does not respond to input > 12415 Can not leave fullscreen Warcraft 3x (Regression) > 12963 Moto Racer 2 works with wine 0.9.60 and crashes with wine 0.9.61 > 13271 The demo of the punisher fails to install > 13740 winebrowser gets wrong URL, problem with unicode > > ---------------------------------------------------------------- > > Changes since 1.0-rc5: > > Alexandre Julliard (1): > Updated the authors list. > > Francois Gouget (3): > Remove spaces before '...' in the Danish resources. > regedit: Remove spaces before '...'. > winecfg: Remove spaces before '...'. > > Jaime Rave (1): > wineconsole: Update Spanish translation. > > Matthias Kupfer (1): > wordpad: Small typo fix for German translation. > > -- > Alexandre Julliard > julliard(a)winehq.org > >

1 0

Celebrating Wine 1.0
by Jeremy White 17 Jun '08

17 Jun '08

Woohoo!!!! Alexandre just posted the Wine 1.0 commit! I eagerly did my git update and enjoyed running 'wine --version'. Ooo. I'm going to do it again... Let us all have a moment of silence to mourn the passing of the Wine 1.0 jokes <grin>. Seriously, this is a major milestone for the Wine project. It is no small undertaking to create a complex Free Software project, and to bring it to a state of general usefulness. There are literally millions - if not more - people using this software we have built. This is a great accomplishment, and we all should be deeply proud of what we've accomplished. I think it's particularly important to thank each and every one of the 1076 AUTHORS and to recognize the support and work of the many people that have contributed to Wine without having their name in that file. I also think we should particularly take a moment to recognize the incredible work of our fearless leader - Alexandre Julliard - without whom none of this would have been possible. And then we should celebrate! I realize that any real large communal celebration will have to wait until we can gather for Wineconf. But I intend to gather up a gang of folks and go out for a meal to celebrate. I will lift a glass of Wine in toast to Alexandre and the many people that have worked on Wine, and I encourage everyone else to do the same. Ideally, people will become sufficiently happy to wax maudlin and we can capture all kinds of embarrassing stories on #winehackers <grin>. Cheers, Jeremy

3 3

About code freeze...
by Alex Villacís Lasso 17 Jun '08

17 Jun '08

Wine 1.0 is out! Great! Does this mean we are now out of code freeze? I have a bunch of richedit patches I submitted previously but were held up because of the code freeze. Is it time to submit them again? -- perl -e '$x=2.4;print sprintf("%.0f + %.0f = %.0f\n",$x,$x,$x+$x);'

2 1

Re: ole32: Fix a failed call to DllGetClassObject while retrieving class object interface pointer.
by Robert Shearman 17 Jun '08

17 Jun '08

Huang, Zhangrong wrote: > See dlls/ole32/compobj.c, > > static HRESULT apartment_getclassobject(struct apartment *apt, LPCWSTR dllpath, > BOOL apartment_threaded, > REFCLSID rclsid, REFIID riid, > void **ppv) > { > ................... > if (SUCCEEDED(hr)) > { > .................. > TRACE("calling DllGetClassObject %p\n", > apartment_loaded_dll->dll->DllGetClassObject); > /* OK: get the ClassObject */ > hr = apartment_loaded_dll->dll->DllGetClassObject(rclsid, riid, ppv); > ^^^^ > if (hr != S_OK) > ERR("DllGetClassObject returned error 0x%08x\n", hr); > } > .............. > } > > Reference to http://msdn2.microsoft.com/en-us/library/ms680760.aspx, > > riid > > [in] Reference to the identifier of the interface that the caller > is to use to communicate with the class object. Usually, this is > IID_IClassFactory (defined in the OLE headers as the interface > identifier for IClassFactory). > This doesn't mean anything other than CoCreateInstance is usually used instead of CoGetClassObject (and CoCreateInstance always passes in IID_IClassFactory for the IID). > We can't pass riid to DllGetClassObject directly sometimes, causes some dlls' > DllGetClassObject (like native adsldp.dll) can only return reference-counted > pointer to class factory via IID_IClassFactory, for retrieving the > pointer to the > class object interface requested in riid, we must try another way. > Thank you for your patch, but this behaviour seems a little strange and needs a little more investigation before I am happy that it is correct. What parameters are being passed in to CoGetClassObject to cause the call to fail for you? -- Rob Shearman

5 12

Only 205 nonleak valgrind errors left!
by Dan Kegel 17 Jun '08

17 Jun '08

Changes since yesterday: - added suppression for glibc bug in if_nameindex - added two patches by Huw, one by Rob, one by Jon, one by Roy - fixed split script; broken out error files now more complete This gets us down from 218 to 205 or so. (Please join the party! We can use all the help we can get getting rid of these bugs; though many are innocuous to users, a few aren't, and they're all annoying to anyone using valgrind. It remains to be seen how many of these patches Alexandre will accept after 1.0 is out, but I'm hopeful we can get most of them up to his standards.) Report showing unique nonleak errors: http://kegel.com/wine/valgrind/logs-2008-06-16.counts.txt Logs: http://kegel.com/wine/valgrind/logs-2008-06-16.log.gz http://kegel.com/wine/valgrind/logs-2008-06-16/ Pending wine patches: http://kegel.com/wine/valgrind/logs-2008-06-16-patches/ http://kegel.com/wine/valgrind/logs-2008-06-16-patches.tgz http://kegel.com/wine/valgrind/logs-2008-06-16-patch.txt Suppression file: http://kegel.com/wine/valgrind/valgrind-suppressions

1 0

Re: Update generated packing tests using current headers.
by Paul Vriens 17 Jun '08

17 Jun '08

Rob Shearman wrote: > --- > dlls/rpcrt4/tests/generated.c | 47 ++++++++++++++++++++++++++------------- > dlls/wininet/tests/generated.c | 4 +- > 2 files changed, 33 insertions(+), 18 deletions(-) > > > ------------------------------------------------------------------------ > > Aren't these files generated (as apart from the name, the first line in those files tells us)? So does this patch miss the tools/winapi/tests.dat part? -- Cheers, Paul.

2 1

When submitting valgrind patches...
by Dan Kegel 17 Jun '08

17 Jun '08

... please include the magic phrase Fixes valgrind warnings like: in the body, followed by an example of the valgrind warnings in question, with addresses and boring parts removed. For example, see http://www.winehq.org/pipermail/wine-patches/2008-June/055658.html That will make it a lot easier to search for the patches. Thanks!

1 0

Wine compiler options benchmarks
by Ben Hodgetts (Enverex) 16 Jun '08

16 Jun '08

Just in-case anyone was ever curious about how well Wine performs with different C/XXFLAGs I did a test today with RC5 to see how much of a difference it makes with 3DMark 2001 SE, nothing major but if someone can think of a better benchmark to try, please let me know (I had hoped to try Oblivion or some such but it has no benchmark feature). Core2Quad Q9450 @ 3.4Ghz || 4GB PC8500 5-5-5-15 || GCC 4.3.1 || Linux 2.6.25 3DMark 2001 SE B300. Wine 1.0-rc5. 28576 -march=native -O3 -pipe -fomit-frame-pointer 28522 -march=native -O3 -pipe -fomit-frame-pointer -mfpmath=sse,387 28511 -march=native -O2 -pipe -fomit-frame-pointer 28427 -march=native -O3 -fomit-frame-pointer -ffast-math -funroll-loops -Wall -pipe 28426 -march=native -O2 -pipe -mfpmath=sse,387 28311 -march=native -O2 -pipe 28270 -march=native -Os -pipe -fomit-frame-pointer 28126 -O3 -pipe -fomit-frame-pointer 28072 Wine Default (-g -O2) 27984 -march=native -O3 -pipe 27646 -march=native -Os -pipe For reference I tried the same with Lame just to show how it would affect other programs: Core2Quad Q9450 @ 3.4Ghz || 4GB PC8500 5-5-5-15 || GCC 4.3.1 || Linux 2.6.25 ~30 minute stereo wave file encoded in Lame Lame-3.97 64bit. real 1m28.739s -O3 -ffast-math -funroll-loops -Wall -pipe (Lame defaults) real 1m29.168s -march=native -O3 -ffast-math -funroll-loops -Wall -pipe real 1m35.633s -march=native -O3 -pipe -ffast-math real 1m35.923s -march=native -O3 -pipe -ftracer -ffast-math real 1m36.346s -march=native -O3 -pipe -ffast-math -falign-functions=64 real 1m36.768s -march=native -O2 -pipe -ftracer -ffast-math real 1m37.242s -march=native -O3 -pipe -ftracer real 1m38.127s -march=native -O3 -pipe -fomit-frame-pointer real 1m38.235s -march=native -O3 -pipe -fvect-cost-model real 1m38.243s -march=native -O2 -pipe -mfpmath=sse,387 real 1m38.278s -march=native -O2 -pipe real 1m38.423s -march=native -O2 -pipe -falign-functions=64 real 1m38.527s -march=native -O2 -pipe -ffast-math real 1m38.573s -march=native -O2 -pipe -falign-functions=128 real 1m38.575s -march=native -O2 -pipe -mfpmath=sse real 1m39.241s -march=native -O2 -pipe -ftracer real 1m39.261s -march=native -O2 -pipe -fomit-frame-pointer real 1m40.946s -march=native -Os -pipe -ffast-math real 1m41.385s -march=native -Os -pipe real 1m41.513s -march=native -Os -pipe -fomit-frame-pointer real 1m41.602s -march=native -Os -pipe -fomit-frame-pointer -mfpmath=sse,387 real 1m46.577s -march=native -O2 -pipe -mfpmath=387 Slightly more influential there. Ben H.

3 2

Wine compiler options benchmarks
by Ben Hodgetts (Enverex) 16 Jun '08

16 Jun '08

Just in-case anyone was ever curious about how well Wine performs with different C/XXFLAGs I did a test today with RC5 to see how much of a difference it makes with 3DMark 2001 SE, nothing major but if someone can think of a better benchmark to try, please let me know (I had hoped to try Oblivion or some such but it has no benchmark feature). Core2Quad Q9450 @ 3.4Ghz || 4GB PC8500 5-5-5-15 || GCC 4.3.1 || Linux 2.6.25 3DMark 2001 SE B300. Wine 1.0-rc5. 28576 -march=native -O3 -pipe -fomit-frame-pointer 28522 -march=native -O3 -pipe -fomit-frame-pointer -mfpmath=sse,387 28511 -march=native -O2 -pipe -fomit-frame-pointer 28427 -march=native -O3 -fomit-frame-pointer -ffast-math -funroll-loops -Wall -pipe 28426 -march=native -O2 -pipe -mfpmath=sse,387 28311 -march=native -O2 -pipe 28270 -march=native -Os -pipe -fomit-frame-pointer 28126 -O3 -pipe -fomit-frame-pointer 28072 Wine Default (-g -O2) 27984 -march=native -O3 -pipe 27646 -march=native -Os -pipe For reference I tried the same with Lame just to show how it would affect other programs: Core2Quad Q9450 @ 3.4Ghz || 4GB PC8500 5-5-5-15 || GCC 4.3.1 || Linux 2.6.25 ~30 minute stereo wave file encoded in Lame Lame-3.97 64bit. real 1m28.739s -O3 -ffast-math -funroll-loops -Wall -pipe (Lame defaults) real 1m29.168s -march=native -O3 -ffast-math -funroll-loops -Wall -pipe real 1m35.633s -march=native -O3 -pipe -ffast-math real 1m35.923s -march=native -O3 -pipe -ftracer -ffast-math real 1m36.346s -march=native -O3 -pipe -ffast-math -falign-functions=64 real 1m36.768s -march=native -O2 -pipe -ftracer -ffast-math real 1m37.242s -march=native -O3 -pipe -ftracer real 1m38.127s -march=native -O3 -pipe -fomit-frame-pointer real 1m38.235s -march=native -O3 -pipe -fvect-cost-model real 1m38.243s -march=native -O2 -pipe -mfpmath=sse,387 real 1m38.278s -march=native -O2 -pipe real 1m38.423s -march=native -O2 -pipe -falign-functions=64 real 1m38.527s -march=native -O2 -pipe -ffast-math real 1m38.573s -march=native -O2 -pipe -falign-functions=128 real 1m38.575s -march=native -O2 -pipe -mfpmath=sse real 1m39.241s -march=native -O2 -pipe -ftracer real 1m39.261s -march=native -O2 -pipe -fomit-frame-pointer real 1m40.946s -march=native -Os -pipe -ffast-math real 1m41.385s -march=native -Os -pipe real 1m41.513s -march=native -Os -pipe -fomit-frame-pointer real 1m41.602s -march=native -Os -pipe -fomit-frame-pointer -mfpmath=sse,387 real 1m46.577s -march=native -O2 -pipe -mfpmath=387 Slightly more influential there. Ben H.

3 2

Re: rpcrt4/tests: Eliminate the test_simple_struct_marshal valgrind error.
by Rob Shearman 16 Jun '08

16 Jun '08

2008/6/16 Dan Hipschman <dsh(a)linux.ucla.edu>: > > Eliminates eight of these (and similar) from the ndr_marshall test: > > Conditional jump or move depends on uninitialised value(s) > at 0x4AEF05E: test_simple_struct_marshal (ndr_marshall.c:668) > by 0x4AEFD91: test_simple_struct (ndr_marshall.c:889) > by 0x4AF6B9A: func_ndr_marshall (ndr_marshall.c:1829) > by 0x4B08FF2: run_test (test.h:449) > by 0x4B09332: __wine_spec_exe_entry (exe_entry.c:36) > by 0x7B870810: start_process (process.c:904) > by 0x47EE4B6: (within /usr/local/google/work/wine/libs/wine/libwine.so.1.0) > > The warning comes from memcmp-ing a struct with padding in it that is not > initialized. http://www.winehq.org/pipermail/wine-patches/2008-June/055831.html -- Rob Shearman

2 1

The upcoming 1.0 and announcing Bordeaux for Linux
by Steven Edwards 16 Jun '08

16 Jun '08

Hello All, I mentioned the other day in the noise about the upcoming 1.0 and the short comings I felt it had. Others have commented quite a bit on the subject already and so I'll be pretty brief. I think the 1.0 process while its been slow has been a good even with its shortcomings. Like with everything its a learning process and hopefully we will be able to tweak the process further for 1.x releases. On the positive side, I think that Dan has done a great job as release manager, maintaining the bug lists, working on winetest, staying on top of all the tips and tricks needed to make Valgrind really useful and maintaining winetricks. I'm also really glad that Alexandre did a lot of refinement to the winetest infrastructure, everything he has done with the Wine infrastructure leading up to this point and frankly for everything he's done for Wine for the past 15 years has been awesome. Though I will be glad when the freeze is over so we can get back to having our patches just silently ignored when he does not like something rather than him having an excuse of the code freeze. =) One of the shortcomings I see as I stated in my email the other day, I think we really missed the target on. I think some Office versions should have been a core requirement of 1.0. Even if it was Office 97 and 2000 working in 98 mode I think we should have been able to provide a nearly perfect experience out of the box. Or nearly out of the box as it were, with a little version tweaking. Office is a core pillar of Microsoft's monopoly and not making this a priority I feel misses the point of Wine for a lot of users. Also I think the process can be refined a bit more for subsequent releases. Some of the developers I spoke with offline were unhappy about not having a public experimental branch that was blessed to continue development in. While they could privately do development and push and pull changes with git, not having a sanctioned experimental branch, I think slowed the overall processes of development down and did not really help with bug fixes enough to be warranted. Perhaps in the future we can maintain parallel lines of development before major releases. A good example is the Samba guys, they've been working on Samba 4 for ever, but the stable branch is still being constantly improved, better, newer stuff is being back ported and development continues on both tracks. Finally I am still not really happy with the results of Winetest. I think we should have had dozens of people that could pass all of the tests months or even years before 1.0 shipped rather than just Alexandre's system being the only one that could do a perfect test run. Maybe we should have just asked him to mirror his setup and provide a list of every package and configuration option he uses so we could base target systems on that. Also I think we should have done something to insure new Wine tests always passed on a fixed version of Windows a lot sooner. James has done a lot of work to make all of the tests pass on Windows 2003 but I think we should have done this back in 2003 and said "every new test has to pass on Windows 2003" as well as Alexandre's box before it gets merged. As far as 1.0 goes, its not perfect but its not horrible and I think we've learned quite a bit and Wine is better now than its ever been. I expect 1.1 or 1.2 whatever number Alexandre wants to call it, will be an exponential improvement given the experience we've gained. And lastly I'd like to announce I am starting a new Free Software company with a long term goal of providing Products and Services around Wine and ReactOS. The Bordeaux Group has today released Bordeaux for Linux which builds on the infrastructure laid out in Wine 1.0, Winetricks, IES4Linux and other tools and tries to wrap them all together in a kind of CrossOver Lite type of environment. The ultimate goal is to help refine Wine more and aide in ReactOS development to create a platform that is generic so that users wanting to migrate away from Windows will have a more broad range of choices, be it Wine on Linux and the Mac, ReactOS, or even CrossOver, PlayOnLinux,WineDoors or some other Wine package. Some of the (limited) work we've already done we hope to be able to fold back in to Winehq. If your interested check it out http://www.bordeauxgroup.com Thanks -- 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 2

[legal] eligibility for contributing code to wine for students / graduates of a course derived from the Microsoft Windows Acadamic Program
by Mark Farnell 16 Jun '08

16 Jun '08

If a student is currently taking, or has previously taken a course derived from the Microsoft Windows Academic Program http://www.microsoft.com/resources/sharedsource/windowsacademic/default.mspx which contains the curriculum resource kit, Windows Research Kernel (containing Windows XP x64 amd Server 2003 SP1 kernel sources) and Project OZ, will they become *ineligible* to contribute code to the wine project in the future? Thanks! Mark

7 9

Valgrind error status on the eve of Wine 1.0
by Dan Kegel 16 Jun '08

16 Jun '08

I've added suppressions for gecko and a few other things, added six more patches of my own and eight patches from Hans, Jon Griffiths, Roy Shea, and Zac Brown. As a result, the error count today (not counting memory leaks) is down 33% from last week; we're down to 218 unique-ish valgrind warnings when running the wine test suite! If you've submitted a patch to fix a warning reported by Valgrind, please check to make sure I've included it. If you have a spare hour or two, please grab one of the remaining errors and see if you can come up with a good fix (i.e. one that doesn't just paper over a problem without understanding it). Once we're down to near zero valgrind warnings, it'll be a lot easier for the average wine developer to check their own patches with valgrind before submission. (Why am I ignoring memory leak warnings? Because I had to focus on something first. Once I get those in shape, I'll focus on memory leaks.) Report showing unique nonleak errors: http://kegel.com/wine/valgrind/logs-2008-06-15.counts.txt Logs: http://kegel.com/wine/valgrind/logs-2008-06-15.log.gz http://kegel.com/wine/valgrind/logs-2008-06-15/ Pending wine patches: http://kegel.com/wine/valgrind/logs-2008-06-15-patches/ http://kegel.com/wine/valgrind/logs-2008-06-15-patches.tgz http://kegel.com/wine/valgrind/logs-2008-06-15-patch.txt Suppression file: http://kegel.com/wine/valgrind/valgrind-suppressions

1 0

re: Appdb has no rc5 choice
by Dan Kegel 16 Jun '08

16 Jun '08

I added the version to bugzilla just now, so the appdb should have it too.

1 0

iTunes ipod support
by Ben Engbers 16 Jun '08

16 Jun '08

Hi, A few days ago, I bought an iPod classic. When I connect it to my laptop (running FC7) the iPod shows up on the desktop. I downloaded iTunessetup.exe from the Apple site and it installed under Wine without problems. iTunes looks good, scanned my system and found all the MP3's, but it doesn't detect the iPod. (Amarok recognizes the iPod but every time I try to synchronize, the iPod database gets corrupted and I have to ask my daughter to reinitialize the iPod :-( so I cant't use that either) How I can I figure out why iTunes does not detect the iPod? Ben

2 1

Re: gdi32: stop font tests crashing under win98
by Dmitry Timoshkov 16 Jun '08

16 Jun '08

"Alistair Leslie-Hughes" <leslie_alistair(a)hotmail.com> wrote: > Changelog: > gdi32: stop font tests crashing under win98 > - if (!*font_name && font_charset == DEFAULT_CHARSET) /* do it only once */ > + /* EnumFontFamilies with the NULL parameter crashs win98 */ > + if (pGetFontUnicodeRanges && !*font_name && font_charset == DEFAULT_CHARSET) /* do it only once */ Why you are testing for pGetFontUnicodeRanges here since it has nothing to do with the test, and disables NT4 as well? There should be a better way to avoid Win9x, for instance using unicode APIs in this, and only this case. -- Dmitry.

1 0

Appdb has no rc5 choice
by Leslie Viljoen 16 Jun '08

16 Jun '08

Hi people I am testing some games with Rc5 and wish to submit results in the AppDb but there is no Rc5 choice. Les

3 2

Re: ddraw: Reset the viewport data before each test
by Paul Vriens 15 Jun '08

15 Jun '08

James Hawkins wrote: > Hi, > > Fixes bug 13643 and the ddraw:d3d tests. > > Changelog: > * Reset the viewport data before each test. > > dlls/ddraw/tests/d3d.c | 31 +++++++++++++++++++++------------ > 1 files changed, 20 insertions(+), 11 deletions(-) > > > > ------------------------------------------------------------------------ > > Can you explain why we have to do this? The fact that only Paul Millar's winetest seems to suffer from this is a bit odd, isn't it? I'm just wondering if there are more issues like this that introduces failures in the tests or even worse lets tests succeed. -- Cheers, Paul.

3 2

d3dx9_28: add version resource
by David Adam 15 Jun '08

15 Jun '08

Hello, maybe you should do this for every d3dx9_xx dll, not only the d3dx9_28 one. David

1 0

Unhandled page fault on prefix creation on osx 10.5
by Cesar Izurieta 15 Jun '08

15 Jun '08

I just deleted my .wine directory and run wineboot. The .wine directory is recreated but I get: wine: created the configuration directory '/Users/cesar/.wine' wine: Unhandled page fault on read access to 0x008cc65f at address 0xffff0eb8 (thread 000b), starting debugger... couldn't load main module (2) Unhandled exception: page fault on read access to 0x008cc65f in 32-bit code (0xffff0eb8). And a lot of dumps and backtraces. I did a regression testing and found out that 58913b439b797462a70794774b87e63283109617 commit is what is causing this problem. Reverting this commit everything works perfectly. More information about the commit (from git bisect): 58913b439b797462a70794774b87e63283109617 is first bad commit commit 58913b439b797462a70794774b87e63283109617 Author: Alexandre Julliard <julliard(a)winehq.org> Date: Fri Feb 15 12:07:56 2008 +0100 kernel32: On Mac OS, recompose the Unicode strings we get from the OS. :040000 040000 f3d03f060068424b166b0ce68169c5a3eddab96e f1a567176edfd42947239dbacff3cc8ad469a497 M dlls I'm using osx 10.5.3 in spanish on a macbook pro. Does anybody know about this?

2 3

new winetricks: new verbs comctl32.ocx, autohotkey
by Dan Kegel 14 Jun '08

14 Jun '08

Can somebody who needs comctl32.ocx or mscomctl.ocx test this? I added this at the suggestion of a comment on http://mike.kronenberg.org, but don't have an app handy to test with. Changes: Use "MS" uniformly in front of choices that are Microsoft downloads. Add comctl32.ocx Add comctl32 as alias for cc580 Added autohotkey Cosmetic changes to menu: make 1st column wider, make gui window wide enough Restore winversion on dotnet20 (Austin) As always, the latest winetricks is online at http://kegel.com/wine/winetricks and the change history is online at http://winezeug.googlecode.com/ - Dan

1 0

Re: winedbg: Add support for printing c++ bool values
by Eric Pouech 14 Jun '08

14 Jun '08

Jon Griffiths a écrit : > Hi, > > Subject says it all. > > + dbg_printf("%s", val_int ? "true" : "false"); what about the simpler: + dbg_printf(val_int ? "true" : "false"); A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

2 1

re: Bugs in Wine research
by Dan Kegel 14 Jun '08

14 Jun '08

tomecek wrote: > we are students from Department of computer science at Aalborg > university. During this semester we were working on project on static > analysis using the Coccinelle tool > (http://www.emn.fr/x-info/coccinelle/) and Flawfinder > (http://en.wikipedia.org/wiki/Flawfinder). We decided to search for > bugs in Wine source code. Great, thanks! We didn't have a wiki page about static analysis and Wine yet, so I created one, http://wiki.winehq.org/StaticAnalysis At least a couple of the memory leaks you found seem like they might be worth fixing. If you could put your full results up somewhere, and link to them from that wiki page, we'll take a look.

3 4

Re: Bugs in Wine research
by tomecek＠cs.aau.dk 14 Jun '08

14 Jun '08

> Dan Kegel wrote: >> James McKenzie <jjmckenzie51(a)sprintpcs.com> wrote: >>>>> we are students from Department of computer science at Aalborg >>>>> university. During this semester we were working on project on static >>>>> analysis using the Coccinelle tool >>>> http://wiki.winehq.org/StaticAnalysis >>> I was wondering if results from Wine 0.9.57 would continue to be valid? >>> Maybe the effort could shift to RC1? >> >> Sure, lots of the unused vars bugs in particular are probably >> already fixed. But the other issues have a pretty good >> chance of still being valid. >> > > Are there any volunteers to do this? > > My experience with Wine C code is fairly minimal, but it shouldn't be > too hard to look at one of their changes and see if it applies to > current git, and if it does just forward-port it. > > Thanks, > Scott Ritchie > > > > Hi, the complete results are available at http://www.cs.aau.dk/~dechouxb/results/complete/, the scripts used at http://www.cs.aau.dk/~dechouxb/cocci_scripts/done/. It is valid for Wine 0.9.57. Sorry for the delay, we were very busy. Unfortunately we cannot rerun the tests because we are leaving Aalborg University in 3 weeks. If you are interested I should be able to rerun these tests (with some improvements) at my home university during late August and September. Jaroslav Tomecek ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

3 2

test.winehq.org doesn't always show the download link for the executable
by Paul Vriens 14 Jun '08

14 Jun '08

Hi, I was just reading a Dutch site were somebody mentioned to help Wine and referred to: http://test.winehq.com/data/062d61a5a4ba2d7972a0011387ceda64c79dd4e3/ (with a remark about possible reboots of your system). The current page however doesn't have a link to the winetest executable. This is because the last report that is picked up by the 'gather' script fills in this executable. If the last report came from somebody running it's own winetest on Wine (instead of the Paul Millars one) there will be 'N/A' (I also saw '-') instead of a proper executable. How could we improve this? - if the last report mentions 'N/A' use a link to http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/winetest-latest.exe? The problem is however that this doesn't have to be the same winetest 'version'. - if any of the reports contains a link to Paul Millars executable, use that. - if none of the reports refer to a proper executable use that winetest-latest again. Any ideas, suggestions? -- Cheers, Paul.

1 0

ddraw: Fix Setmaterial with a test
by David Adam 14 Jun '08

14 Jun '08

>David Adam wrote: >>* The test succeded in my windows XP box. *>>* *>You have only ddraw test and no d3d test. > >Vitaliy. Giving a NULL value to SetMaterial in d3d9 or d3d8 makes Windows crashes. It is a forbidden value (see bug 13646). So, no test can be performed for d3d8 and d3d9. I sent a patch to removed these test earlier. David

3 6

Re: user32: Allow a NULL foreground window in the tests
by Dmitry Timoshkov 14 Jun '08

14 Jun '08

"James Hawkins" <jhawkins(a)codeweavers.com> wrote: > According to msdn, "The foreground window can be NULL in certain > circumstances, such as when a window is losing activation. " which is > exactly when these failures occur. > > Changelog: > * Allow a NULL foreground window in the tests. NULL foreground window is already allowed, you just need to fix the callers of check_wnd_state() to pass 0 for foreground. -- Dmitry.

2 11

Re: user32: Handle GetTextMetricsW failure in get_text_metr_size
by Dmitry Timoshkov 14 Jun '08

14 Jun '08

"Roy Shea" <royshea(a)gmail.com> wrote: > Initializes the tmHeight field of the TEXTMETRICW used by callers of > get_text_metr_size, even when calls to GetTextMetricsW fail. This fix > remedies the Valgrind errors of the form "normalize_nonclientmetrics > (sysparams.c:1043)" found throughout the advpack test suite. GetTextMetricsW should never fail. You need to find a reason of a failure. -- Dmitry.

1 0

Wine-1.0 release notes
by Vitaliy Margolen 14 Jun '08

14 Jun '08

Since all of the 1.0 blocker bugs being pushed back, wine-1.0 release notes should list all of those as major known problems. Otherwise people will get a bad impression that wine-1.0 means more then less working release. Also release notes should mention that wine-1.0 is not suitable for most games (new or old) for numerous reasons, including video driver bugs, sound and video conflicts with default system setups, unavailability of required features from X server etc. And that wine-1.0 will not work at all for majority of people using other then default input methods. In short - that after everyone's hard work and 15 years of development wine-1.0 is just a release tag nothing more. Vitaliy.

7 15

twinview and user32/tests/monitor.c
by Dan Kegel 13 Jun '08

13 Jun '08

My workstation was failing a test because it didn't have a 640x480 display mode. Turned out it was how the dual monitor support was configured, and changing a line in /etc/X11/xorg.conf from Option "MetaModes" "2560x1600,2560x1600; 1920x1200,1920x1200; 1600x1200,1600x1200; 1280x1024,1280x1024" to Option "MetaModes" "2560x1600,2560x1600; 1920x1200,1920x1200; 1600x1200,1600x1200; 1280x1024,1280x1024; 640x480,NULL" made the test happy. Probably not worth worrying about changing the test to expect crazy configurations like this...

1 1

Handy valgrind tips
by Dan Kegel 13 Jun '08

13 Jun '08

I've started collecting tips about how to track down wine bugs using valgrind; they're at the bottom of http://wiki.winehq.org/Wine_and_Valgrind There are two right now (about building wine with -O0, and about using WINEDEBUG to flush out undefined values into the open). Share and enjoy...

1 0

-O0 nearly twice as fast to build as -O2
by Dan Kegel 13 Jun '08

13 Jun '08

OK, this was confusing. I was getting repeatable five minute builds, i.e. "make clean; reboot; time make -j3" (more or less :-) was reliably showing five minutes wall clock time. Then I did "make distclean; ./configure; make depend". After that, I got repeatable nine minute builds, i.e. make clean; reboot; time make -j3 was showing nine minute wall clock time. Turns out, the difference was... I had been building without optimization. So configuring with CFLAGS="-g -O0" is almost a 2x speedup! This is with gcc-4.2.3. Might be handy to know when doing regressions.

4 5

Time to update Wine's status?
by Adam Petaccia 13 Jun '08

13 Jun '08

http://winehq.org/site/status is the website showing Wine's status on implementing various DLLs, but it hasn't been updated in almost a year! The information is not only old, but Wine has added new DLLs that aren't listed. With Wine approaching its 1.0 release, perhaps it should be decided to update or remove the page. My vote would be for updating, but I'm not sure where those stats come from, and that may take away from time better spent on bug hunting. -- Adam Petaccia <adam(a)tpetaccia.com>

4 5

Re: [AppDB] application: Only show 'submitter' column when processing queued entries
by Edwin Smulders 13 Jun '08

13 Jun '08

I'm not exactly sure where this removes the submitter column, but if this is on the test results page, please keep it as it is, I find it useful info, in multiple ways. One way is as a maintainer, being able to sort through the results, and one is as a user, being able to see which test results came from the maintainer of the app himself (i usually find these more accurate). Just a thought, and disregard this if it is not about this column but some other column :) On Fri, Jun 13, 2008 at 12:13 AM, Alexander Nicolaysen Sørnes <alex(a)thehandofagony.com> wrote: > That info is not very interesting for people browsing the database. > > > Alexander N. Sørnes > > > >

1 0

msvcrt and gcc-c++ header conflicts
by Praveenkumar Ponnusamy 13 Jun '08

13 Jun '08

Hello Wine Developers- I am trying to compile a windows project on Linux using winemaker and I'm stuck with a problem and was wondering if any of you have encountered it before or have any suggestions. In some of the compilation units in my project, I am using std::ofstream that is defined in the "fstream" header file and included as #include <fstream>. Since wine does not provide this header file, the one provided by gcc is used by the wine compiler -- which in turn includes quite a few headers of its own. A number of symbols defined in these headers conflict with the ones provided by wine and produce compiler errors such as these: In file included from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/cwchar:52, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/bits/postypes.h:47, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/iosfwd:47, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/ios:44, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/istream:45, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/fstream:45, from /home/praveen/wine-projects/myProject/tengine.h:25, from /home/praveen/wine-projects/myProject/teassembly.h:19, from teassembly.cpp:17: /usr/include/wchar.h: At global scope: /usr/include/wchar.h:62: error: conflicting declaration 'typedef unsigned int wint_t' /usr/local/include/wine/msvcrt/ctype.h:30: error: 'wint_t' has a previous declaration as 'typedef short unsigned int wint_t' In file included from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/cwchar:52, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/bits/postypes.h:47, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/iosfwd:47, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/ios:44, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/istream:45, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/fstream:45, from /home/praveen/wine-projects/myProject/tengine.h:25, from /home/praveen/wine-projects/myProject/teassembly.h:19, from teassembly.cpp:17: /usr/include/wchar.h:246: error: declaration of C function 'wchar_t* wcstok(wchar_t*, const wchar_t*, wchar_t**)' conflicts with /usr/local/include/wine/msvcrt/string.h:122: error: previous declaration 'wchar_t* wcstok(wchar_t*, const wchar_t*)' here My understanding is that Wine has implemented msvcrt and provides the associated header files but not the c++ headers. Am I right? What could be the solution here? I would greatly appreciate any help. I am using wine-1.0-rc4 on Fedora 9. Thanks in advance. -Praveen

1 0

Nice 1.0 article by Steven J. Vaughan-Nichols
by Dan Kegel 12 Jun '08

12 Jun '08

http://www.linux.com/feature/138160 It puts the release date at June 20th, but otherwise seems accurate. I was tickled by Jeremy's quote about my impact, but the real story is: Wine's lucky that a) Google happened to need Picasa on Linux, and the Picasa team was shorthanded b) I raised my hand at the right time, and said "I know a contractor that can get Picasa running on Linux..." and is even more lucky that c) Google is so open-source-friendly d) Chris DiBona works at Google e) my bosses believed me when I said a couple interns could make a big difference All in all a fortuitous coincidence. - Dan

1 0

Re: Revert "wined3d: Preload target in ActivateContext() for ORM_BACKBUFFER/ORM_PBUFFER."
by Stefan Dösinger 12 Jun '08

12 Jun '08

Am Montag, 2. Juni 2008 06:50:15 schrieb Vitaliy Margolen: > This reverts commit 2d0016c5bc872afb562727278cfd341cea182600. > Partially fixes bug 11584. I think we can revert that patch(ie, apply this patch). I haven't had time to look over the code yet, but I can't think of any problems this would cause. If it does cause problems, there's a bug elsewhere. I think this patch was needed to work around some surface management bugs before the ModifyLocation / LoadLocation methods were introduced

6 11

Nominating bugs for 1.0.1
by Dan Kegel 12 Jun '08

12 Jun '08

Since Alexandre is now planning to do a 1.0.1 release, I created a 1.0.1 target in bugzilla, and have targeted a very few high priority and/or fixed-but-not-in-time bugs to it. Many of the bugs currently targeted for 1.2 are not good candidates for targeting to 1.0.1 because the bug is not yet well understood and/or a fix is not yet known. I think the rule of thumb for further nominations should be something like "if it's already fixed in trunk, and the fix is easy to backport to 1.0, then it should be nominated for 1.0.1."

1 0

Re: advapi32: fix a test failure on NT4
by Paul Vriens 12 Jun '08

12 Jun '08

Austin English wrote: > > ------------------------------------------------------------------------ > > Hi, This patch is not correct. That last error actually came from the first of the two GetServiceDisplayNameA's just before that and wasn't reset by NT4. I'll sent a more correct one. -- Cheers, Paul.

1 1

Re: advapi32: fix a test failure on NT4
by James Hawkins 12 Jun '08

12 Jun '08

On Thu, Jun 12, 2008 at 9:29 AM, Austin English <austinenglish(a)gmail.com> wrote: > + ok(GetLastError() == ERROR_SERVICE_DOES_NOT_EXIST || + GetLastError() == ERROR_INSUFFICIENT_BUFFER /* NT 4 */, + "Expected ERROR_SERVICE_DOES_NOT_EXIST or ERROR_INSUFFICIENT_BUFFER, got %d\n", GetLastError()); You can't see it with this paste, but it looks like you used tabs instead of spaces, or at least the indentation is off. -- James Hawkins

1 0

Re: gdi32: GetCharacterPlacement should accept NULL lpResults (fixes bug 13094)
by James Hawkins 12 Jun '08

12 Jun '08

On Thu, Jun 12, 2008 at 3:39 AM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: > Changelog: > - Fixes GetCharacterPlacement with NULL lpResults argument (fix for bug 13094) > > --- > dlls/gdi32/font.c | 34 ++++++++++++++++++++++++---------- > 1 files changed, 24 insertions(+), 10 deletions(-) > > diff --git a/dlls/gdi32/font.c b/dlls/gdi32/font.c > index 1bfd97a..34aabd1 100644 > --- a/dlls/gdi32/font.c > +++ b/dlls/gdi32/font.c > @@ -2709,27 +2709,35 @@ GetCharacterPlacementA(HDC hdc, LPCSTR lpString, INT uCount, > WCHAR *lpStringW; > INT uCountW; > GCP_RESULTSW resultsW; > + GCP_RESULTSW *presults = NULL; > DWORD ret; > UINT font_cp; > > TRACE("%s, %d, %d, 0x%08x\n", > debugstr_an(lpString, uCount), uCount, nMaxExtent, dwFlags); > > - /* both structs are equal in size */ > - memcpy(&resultsW, lpResults, sizeof(resultsW)); > + if(lpResults){ > + /* both structs are equal in size */ > + memcpy(&resultsW, lpResults, sizeof(resultsW)); > + > + if(lpResults->lpOutString) > + resultsW.lpOutString = HeapAlloc(GetProcessHeap(), 0, sizeof(WCHAR)*uCountW); > + > + presults = &resultsW; > + } > > lpStringW = FONT_mbtowc(hdc, lpString, uCount, &uCountW, &font_cp); > - if(lpResults->lpOutString) > - resultsW.lpOutString = HeapAlloc(GetProcessHeap(), 0, sizeof(WCHAR)*uCountW); > > - ret = GetCharacterPlacementW(hdc, lpStringW, uCountW, nMaxExtent, &resultsW, dwFlags); > + ret = GetCharacterPlacementW(hdc, lpStringW, uCountW, nMaxExtent, presults, dwFlags); > > - lpResults->nGlyphs = resultsW.nGlyphs; > - lpResults->nMaxFit = resultsW.nMaxFit; > + if(lpResults){ > + lpResults->nGlyphs = resultsW.nGlyphs; > + lpResults->nMaxFit = resultsW.nMaxFit; > > - if(lpResults->lpOutString) { > - WideCharToMultiByte(font_cp, 0, resultsW.lpOutString, uCountW, > - lpResults->lpOutString, uCount, NULL, NULL ); > + if(lpResults->lpOutString) { > + WideCharToMultiByte(font_cp, 0, resultsW.lpOutString, uCountW, > + lpResults->lpOutString, uCount, NULL, NULL ); > + } > } > > HeapFree(GetProcessHeap(), 0, lpStringW); > @@ -2780,6 +2788,10 @@ GetCharacterPlacementW( > lpResults->lpGlyphs, lpResults->nGlyphs, lpResults->nMaxFit); > > if(dwFlags&(~GCP_REORDER)) FIXME("flags 0x%08x ignored\n", dwFlags); > + > + /* with NULL lpResults return GetTextExtentPoint32 result */ > + if(!lpResults) goto nullres; > + > if(lpResults->lpClass) FIXME("classes not implemented\n"); > if (lpResults->lpCaretPos && (dwFlags & GCP_REORDER)) > FIXME("Caret positions for complex scripts not implemented\n"); > @@ -2833,6 +2845,8 @@ GetCharacterPlacementW( > if(lpResults->lpGlyphs) > GetGlyphIndicesW(hdc, lpString, nSet, lpResults->lpGlyphs, 0); > > +nullres: > + > if (GetTextExtentPoint32W(hdc, lpString, uCount, &size)) > ret = MAKELONG(size.cx, size.cy); > You need to write a test for this behavior, especially this close to a release. -- James Hawkins

1 0

Fwd: [Wine] Wine 1.0 release date to clash with Firefox 3
by Austin English 12 Jun '08

12 Jun '08

---------- Forwarded message ---------- From: Bamm <wineforum-user(a)winehq.org> Date: Thu, Jun 12, 2008 at 6:32 AM Subject: [Wine] Wine 1.0 release date to clash with Firefox 3 To: wine-users(a)winehq.org According to http://wiki.winehq.org/WineReleasePlan the new release date for Wine 1.0 is set to June 17. However the Firefox 3.0 release date is also set to June 17. http://developer.mozilla.org/devnews/index.php/2008/06/11/coming-tuesday-ju… Their release is planned to be high profile and they even plan to set a Guinness world record for downloads in a single day! http://www.tuaw.com/2008/05/30/help-firefox-set-a-guinness-world-record/ With this, I fear that the Wine release would be drowned out in the euphoria and excitement for Firefox 3. I respectfully suggest, therefore, that we move the Wine 1.0 release date to another date besides June 17. This way we can attract more press and attention. I hope others agree with my observation. Regards, Bamm

2 1

Re: [website] wine 1.0 update
by Michael Stefaniuc 12 Jun '08

12 Jun '08

Dan Kegel wrote: > The penultimate update? > > > ------------------------------------------------------------------------ > 1.0 bugs deferred to 1.0.1 since May 27th: > +<li><a href="http://bugs.winehq.org/show_bug.cgi?id=12097">12097</a> Wine 1.0 should not ship out-of-sync resource translations This bug is fixed as soon as Alexandre commits the patch from http://www.winehq.org/pipermail/wine-patches/2008-June/055761.html . http://pf128.krakow.sdi.tpnet.pl/wine-transl/ shows an other "error" in the Japanese user32 translation but that's only an extra FONT element in DIALOG MSGBOX. I think the FONT element can be removed but i need to cross check that. Anyway, the resource/dialog is not broken at all for Japanese and thus the bug #12097 can be considered fixed after todays commit round. bye michael

1 0

Re: Add German translation for xcopy
by Rico Schüller 12 Jun '08

12 Jun '08

Michael Karcher wrote: > --- > programs/xcopy/De.rc | 79 ++++++++++++++++++++++++++++++++++++++++++++++++ > programs/xcopy/rsrc.rc | 1 + > 2 files changed, 80 insertions(+), 0 deletions(-) > create mode 100644 programs/xcopy/De.rc > > > ------------------------------------------------------------------------ > > Does this work for you? When I apply the attached patch and run wine xcopy /? I get garbled German umlauts in the output (also tried with SUBLANG_NEUTRAL) . Is it the same for you? I think you forgot something to translate: STRING_INVPARM, "Unbekannter Parameter '%s' - Use xcopy /? for help\n" should be something like STRING_INVPARM, "Unbekannter Parameter '%s' - xcopy /? zeigt Hilfe an\n" Cheers Rico

3 2

Re: Wine-1.0 release notes
by Susan Cragin 12 Jun '08

12 Jun '08

I would agree and go further. Wine has made Linux handicapped-accessible for a great number of people, including me, who have mild repetitive-motion difficulties that make typing for any length of time uncomfortable. Many of the people who use Linux are programmers and are technically proficient, and they seem to want a lot from their computer, but here I sit, comfortably churning out text at the rate of almost the spoken word. I transcribe interviews, write letters, complain to my congresspeople, and am writing this, with no effort (and sometimes, not much thought either, because you see, it's not an effort to type). Dragon NaturallySpeaking is a tremendously complex program, and it is a miracle that it has been made to run on Linux. Now, it runs in basic form. Many of its "special features" don't work. But on the other hand, if it were being sold as simply a text recognition medium, it would still sell. That's what it does well. It recognizes spoken words and writes them down, fast. In addition, I expect that soon wine and Linux will run Dragon NaturallySpeaking faster than Windows will. Windows Vista will run it better, because more of its features will be enabled, but Linux will run it faster. And faster means better, means more words PLUS more accurate recognition. As soon as some of the bugs get worked out Ubuntu and ALSA sound, and I get better accuracy scores from my microphone, I expect Dragon NaturallySpeaking to recognize text better on Linux than it does on Windows. What that means for transcription services, for court reporting, etc., is anybody's guess. But I plan to find out when I take a speed test on the last day of July. Dragon NaturallySpeaking is a unique program. Just ask those folks at IBM who worked on ViaVoice. That program was abandoned. Ask the people at Carnegie Mellon who worked on Sphinx for Linux. Ask Microsoft, which is trying to develop its own. Dragon NaturallySpeaking is the type of program that isn't going to have a rival for 10 years. Now that I've gotten that particular rant off my chest -- and don't worry about my fingers, it only took me a minute to do it -- I'd like to mention another very useful program that wine runs flawlessly. This is keynote, a note-taking program used by academic researchers. Here is another little thought to ponder. Massachusetts USA developed a state requirement for "open document format" but it has been delayed because, as one lobbyist put it, "there are no office applications with native ODF support that provide accessibility for persons who use assistive technology devices." I mean, how proud do we need to be about not running everything? Susan -----Original Message----- >From: Reece Dunn <msclrhd(a)googlemail.com> >Sent: Jun 11, 2008 8:02 PM >To: Vitaliy Margolen <wine-devel(a)kievinfo.com> >Cc: Wine Develop <wine-devel(a)winehq.org> >Subject: Re: Wine-1.0 release notes > >2008/6/11 Vitaliy Margolen <wine-devel(a)kievinfo.com>: >> In short - that after everyone's hard work and 15 years of development >> wine-1.0 is just a release tag nothing more. > >I think that this is overly harsh. It's like saying that you should >not celebrate a birthday, as that is just you aging just a day, >nothing more. > >Wine is in a strange position as it is trying to make any Windows >application (ultimately) run on any suitable posix system with a >suitable X server. Given that a new version of Windows is usually >released every 2-3 years, with new features, APIs and functionality, >the landscape is constantly changing. Couple this with each successive >release of an application supporting newer technologies and APIs - the >set of which differs from application to application, makes it harder >to support. > >Yes, regressions will happen. Yes, applications will crash/fail to >work. But think of all the applications that *do* work; given what >Wine is working against, this is an amasing achievement. Wine can and >does run Office, Photoshop, ITunes, Oblivion, Peggle and a myriad >other applications (some better than others). > >So yes, highlight the known issues in the release notes, list the >major applications (with corresponding version numbers) that are known >to work and refer the user to the AppDB for more information. However, >don't sell it short either. > >I am personally using Wine to run the Cepstral SwiftTalker >text-to-speech program, play Oberon/PopCap/casual games like Peggle, >Bejeweled 2 and Bloom on my Ubuntu laptop. I'm sure that other people >have other success stories as well, such as Susan Cragin, who uses >Dragon Naturally Speaking 9. > >Maybe what we need is a "What I use Wine for" set of documents or >mini-articles where people describe what Windows applications they are >running, what works/does not work for them. Dan's Spouse test is also >a good idea. Perhaps we can get some feedback on the Spouses >experiences of using the applications under Wine. > >NOTE: I have been testing various casual games from Oberon with the >various RC releases and have found that over 50% of those tested >(around 14 at the moment) worked out of the box when ran directly from >their install directory. While this does not seem a lot, given what >Wine is developing against, I think this is a huge success. > >NOTE: I am not saying Wine is perfect, I'm saying that the message >should be positive and realistic instead of unduly negative. > >- Reece > >

1 0

unhide .update-timestamp
by Lei Zhang 11 Jun '08

11 Jun '08

Hi, Can we rename $WINEPREFIX/.update-timestamp to $WINEPREFIX/update-timestamp? There's been times when I cleaned my $WINEPREFIX directory by going into that directory and running rm -Rf... except .update-timestamp didn't get removed. Then I run wine, but wineboot is a bit confused and does not invoke InstallHinfSectionW(), thus creating a $WINEPREFIX/drive_c with lots of missing files.

1 0

Compiling wine-1.0-rc3 (2)
by Alexandrov Anton 11 Jun '08

11 Jun '08

Hello. I solved this problem. In my case wine couldn't be compiled with "-malign-double" option. I compiled it successfully after I had removed this option in my $CFLAGS and $CXXFLAGS. -- All the best, Alexandrov Anton.

1 0

Re: [PATCH] shell32: SHFileOperation: test added
by James Hawkins 11 Jun '08

11 Jun '08

On Wed, Jun 11, 2008 at 12:01 PM, Vitaly Perov <vitperov(a)etersoft.ru> wrote: > Changelog: > - shell32: test added. It check whether SHFileOperation could correctly work > with input files mask '*.*' > + retval = SHFileOperationA(&shfo); + ok(retval == ERROR_SUCCESS, "Expected ERROR_SUCCESS, got %d\n", retval); + ok(!file_exists("testdir2\\one.txt"), "Expected one.txt to not exist\n"); Please don't add more of the weird spacing for the ok's. That is a byproduct of a huge patch that I sent to reduce the number of changes, and it just hasn't been fixed yet. -- James Hawkins

1 0

Compiling wine-1.0-rc3
by Alexandrov Anton 11 Jun '08

11 Jun '08

Good afternoon. I tried to compile wine-1.0-rc3 and got this message: ------ ../../tools/winegcc/winegcc -B../../tools/winebuild -shared ./acledit.spec main.o -o acledit.dll.so -lkernel32 ../../libs/port/libwine_port.a winebuild: Cannot read main.o winegcc: ../../tools/winebuild/winebuild failed ------ I hadn't use any special options (only "./configure", "make depend && make"). gcc version: 4.1.2 linux kernel: 2.6.24 -- All the best, Alexandrov Anton.

1 0

Re: dsound: notification order
by Vitaliy Margolen 11 Jun '08

11 Jun '08

Ulrich Hecht wrote: > Hi! > > This fixes sound in Ootake (http://www.ouma.jp/ootake/). Looks like > DSBPN_OFFSETSTOP is not always the last element. > > - /* DSBPN_OFFSETSTOP has to be the last element. So this is */ > - /* OK. [Inside DirectX, p274] */ > - /* */ > - /* This also means we can't sort the entries by offset, */ > - /* because DSBPN_OFFSETSTOP == -1 */ > + /* DSBPN_OFFSETSTOP is not necessarily the last element. */ Don't remove all the comments. They are still mostly valid. Just add that it's not always true for some broken apps. > if (offset == DSBPN_OFFSETSTOP) { > if (dsb->state == STATE_STOPPED) { > SetEvent(event->hEventNotify); > TRACE("signalled event %p (%d)\n", event->hEventNotify, i); > - return; > - } else > - return; Much better fix and easier to understand would be replacing "returns" for "continue". Then you won't need to reformat the whole block. Something like: @@ -247,9 +247,8 @@ void DSOUND_CheckEvent(const IDirectSoundBufferImpl *dsb, DWORD playpos, int len if (dsb->state == STATE_STOPPED) { SetEvent(event->hEventNotify); TRACE("signalled event %p (%d)\n", event->hEventNotify, i); - return; - } else - return; + } + continue; Vitaliy.

1 0

Wine + Fedora
by Louis Lenders 11 Jun '08

11 Jun '08

Hi, just thought dropping a note here so you'd know: the troubles reported for wine+fedora 9, now also affect fedora 8. Last saturday i did a 'yum update', and after that about all wine-applications froze my computer. Only a hard reboot helped... Solved it by reverting back to kernel 2.6.24.7-92.fc8 Just in case a new wine-1.0 release comes out, and fedora-users start whining "wine 1.0 is really crap, it freezes my computer" , hope this will be fixed soon.

3 5

RE: ddraw: modify Direct3D device name
by Stefan Dösinger 11 Jun '08

11 Jun '08

> Descent FreeSpace: The Great War and Descent FreeSpace 2 fail to detect > hardware acceleration through Direct3D when enumerating devices, they > expect the device name string to begin with "Direct3D - " > > This patch enables the Direct3D mode to be used. I am not entirely sure about this. I think there were other apps(Quicktime?) which depend on some other name. I think the best is to see which name Windows uses, make ddraw.dll read the name from WineD3D, and make WineD3D return the same name Windows does for the detected card.

2 2

Re: wininet: Make sure URL is terminated in InternetCrackUrlA.
by Alexandre Julliard 10 Jun '08

10 Jun '08

Hans Leidekker <hans(a)it.vu.nl> writes: > Fixes http://bugs.winehq.org/show_bug.cgi?id=1968 > as well as a bunch of Valgrind warnings in the url test module. > > -Hans > > Changelog > Make sure URL is terminated in InternetCrackUrlA. The bug is in InternetCrackUrlW, it shouldn't require the string to be null-terminated. -- Alexandre Julliard julliard(a)winehq.org

3 3

Trying to build rc4 for MacOS, having problems with libpng, libjpeg, etc.
by Timothy Normand Miller 10 Jun '08

10 Jun '08

Hi. I'm not subscribed. I'm trying to build rc4 for MacOS (Leopard), and I'm running into some problems, and I hope I'm not a bother to ask for some help. When I do ./configure, I get the following messages: onfigure: WARNING: libjpeg development files not found, JPEG won't be supported. configure: WARNING: libpng development files not found, PNG won't be supported. (and several other similar ones) I know for a fact that these libraries are installed under /sw (via Fink), along with the include files, but no matter what I do, I can't get get configure to find them. Here's how I'm trying to do it so far: export LDFLAGS=-L/sw/lib export LIBS="-lpng -ljpeg" ./configure --prefix=/sw --exec-prefix=/sw What am I missing? Thanks! -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project

2 3

Re: gdi32: stop gdi font test crashing under win98
by Dmitry Timoshkov 10 Jun '08

10 Jun '08

"Alistair Leslie-Hughes" <leslie_alistair(a)hotmail.com> wrote: > if (!*font_name && font_charset == DEFAULT_CHARSET) /* do it only once */ > { > + LOGFONT lf; > + memset(&lf, 0, sizeof(LOGFONT)); > + > efd.total = 0; > SetLastError(0xdeadbeef); > ret = EnumFontFamilies(hdc, NULL, arial_enum_proc, (LPARAM)&efd); > @@ -1333,7 +1336,7 @@ static void test_EnumFontFamilies(const char *font_name, INT font_charset) > > efd.total = 0; > SetLastError(0xdeadbeef); > - ret = EnumFontFamiliesEx(hdc, NULL, arial_enum_proc, (LPARAM)&efd, 0); > + ret = EnumFontFamiliesEx(hdc, &lf, arial_enum_proc, (LPARAM)&efd, 0); The test must use NULL in order to match the EnumFontFamilies results above. If it causes the crash under Win9x the test should be explicitly skipped on that platform. -- Dmitry.

1 0

Re: winex11.drv: Do not crash if UploadGlyph failed
by Alexandre Julliard 10 Jun '08

10 Jun '08

Dmitry Timoshkov <dmitry(a)codeweavers.com> writes: > this patch fixes the Firefox crashes reported in the bugs 4762 and 12307. > > Changelog: > winex11.drv: Do not crash if UploadGlyph failed. I don't think that's correct, it should still display the valid glyphs and use a replacement char for the invalid ones. -- Alexandre Julliard julliard(a)winehq.org

1 0

re: Stop shlfileop tests crashing under win98
by Dan Kegel 10 Jun '08

10 Jun '08

Alistair wrote: >- /* try an invalid list, only one null terminator */ >- init_shfo_tests(); >- shfo.pFrom = ""; >- shfo.wFunc = FO_DELETE; >- ret = SHFileOperation(&shfo); >- ok(ret == ERROR_ACCESS_DENIED, "Expected ERROR_ACCESS_DENIED, got %d\n", ret); >- ok(file_exists("test1.txt"), "Expected test1.txt to exist\n"); >+ /* This crashes under win98 */ >+ if(0) >+ { >+ /* try an invalid list, only one null terminator */ Hey Allistair, that paragraph looks like it was buggy - it should have had test1.txt followed by a single nul and then twice MAXPATH nonnulls and then a double nul, like the similar tests I fixed in http://www.winehq.org/pipermail/wine-patches/2008-May/055371.html As it is, there's no way FO_DELETE could see test1.txt to maybe delete it. James, do you agree? Perhaps you could leave it enabled if you fixed it like the ones I fixed. (Or tried to fix; sadly, Alexandre hasn't committed it yet. Why?) - Dan

3 3

Re: ddraw: Fix Setmaterial with a test
by Vitaliy Margolen 10 Jun '08

10 Jun '08

David Adam wrote: > The test succeded in my windows XP box. > You have only ddraw test and no d3d test. Vitaliy.

1 0

Re: [ole32/tests 2/2] Fix crash on NT4 and below
by Rob Shearman 10 Jun '08

10 Jun '08

2008/6/10 Paul Vriens <paul.vriens.wine(a)gmail.com>: > This 'fixes' the crash on win9x and NT4. > > @@ -1130,11 +1130,15 @@ static void test_data_cache(void) > hr = IOleCache_Uncache(pOleCache, 0xdeadbeef); > ok(hr == OLE_E_NOCONNECTION, "IOleCache_Uncache with invalid value should return OLE_E_NOCONNECTION instead of 0x%x\n", hr); > > - hr = IOleCache_Cache(pOleCache, NULL, 0, &dwConnection); > - ok(hr == E_INVALIDARG, "IOleCache_Cache with NULL fmtetc should have returned E_INVALIDARG instead of 0x%08x\n", hr); > + /* Both tests crash on NT4 and below */ > + if (0) > + { > + hr = IOleCache_Cache(pOleCache, NULL, 0, &dwConnection); > + ok(hr == E_INVALIDARG, "IOleCache_Cache with NULL fmtetc should have returned E_INVALIDARG instead of 0x%08x\n", hr); > > - hr = IOleCache_Cache(pOleCache, NULL, 0, NULL); > - ok(hr == E_INVALIDARG, "IOleCache_Cache with NULL pdwConnection should have returned E_INVALIDARG instead of 0x%08x\n", hr); > + hr = IOleCache_Cache(pOleCache, NULL, 0, NULL); > + ok(hr == E_INVALIDARG, "IOleCache_Cache with NULL pdwConnection should have returned E_INVALIDARG instead of 0x%08x\n", hr); > + } > > for (fmtetc.cfFormat = CF_TEXT; fmtetc.cfFormat < CF_MAX; fmtetc.cfFormat++) > { This test was added in response to a real application doing exactly this, so I think the test does have value when run on Win 2000+. Therefore, I think a version check would be better than "if (0)". -- Rob Shearman

2 1

Re: shell32: stop shlfolder tests crashing under win98
by Paul Vriens 10 Jun '08

10 Jun '08

Alistair Leslie-Hughes wrote: > Hi, > Moved the null pointer checker to before it's first used. > > Changelog: > shell32: stop shlfolder tests crashing under win98 > > Best Regards > Alistair Leslie-Hughes > > > ------------------------------------------------------------------------ > > While your at it, could you add a skip message? -- Cheers, Paul.

1 0

Re: gdi32: Use 0xffff as a default character as Vista does
by Reece Dunn 10 Jun '08

10 Jun '08

2008/6/10 Dmitry Timoshkov <dmitry(a)codeweavers.com>: > Hello, > > this patch fixes the problem reported in the bug 12305. In Wine Tahoma > character ':' is mapped to glyph index 0x1f, and that seems to be confusing > Firefox. > + TM.tmDefaultChar = pOS2->usDefaultChar ? pOS2->usDefaultChar : 0xffff; There is a UNICODE_NOCHAR constant for this. - Reece

2 1

Re: msxml3: tests/xmlelem.c: VT_EMPTY is not a string
by Michael Stefaniuc 09 Jun '08

09 Jun '08

Dan Kegel wrote: > Casting a VT_EMPTY to a string gets you a null string. > The test was doing that and taking the string length, then comparing to zero. > Better to simply compare to null; that's a stronger test, and > avoids generating a behind-the-scenes exception. > > Passes on Wine and XP, and makes Valgrind output a bit easier on the eyes. > > > ------------------------------------------------------------------------ > diff --git a/dlls/msxml3/tests/xmlelem.c b/dlls/msxml3/tests/xmlelem.c > index 61a2300..229de78 100644 > --- a/dlls/msxml3/tests/xmlelem.c > +++ b/dlls/msxml3/tests/xmlelem.c > @@ -78,7 +78,7 @@ static void test_xmlelem(void) > hr = IXMLElement_getAttribute(element, str, &vValue); > ok(hr == S_FALSE, "Expected S_FALSE, got %d\n", hr); > ok(V_VT(&vValue) == VT_EMPTY, "Expected VT_EMPTY, got %d\n", V_VT(&vValue)); > - ok(lstrlenW(V_BSTR(&vValue)) == 0, "Expected empty value\n"); > + ok(V_BSTR(&vValue) == (void *)0, "Expected null value\n"); Is there a problem with using NULL instead of (void *)0? bye michael

2 1

Re: notepad: updated French translation
by Laurent Vromman 09 Jun '08

09 Jun '08

Hi, I don't know if it is important since the translation is grammatically correct, but in windows (I checked on XP SP2), the exact translation is "À &propos du Bloc-notes..." and not "À &propos de Bloc-notes..." Laurent Jonathan Ernst wrote: > ------------------------------------------------------------------------ > > >

3 4

Please have a look at the current Valgrind warnings
by Dan Kegel 09 Jun '08

09 Jun '08

After a few days of cleaning up Valgrind warnings in the Wine source tree, and adding suppressions where it made sense. I've whittled the list of Valgrind warnings down to 300 or so. This list is short enough that a mortal can look upon it without dispair, and even see a number of things that might be real bugs. The histogram of frequent errors is at http://kegel.com/wine/valgrind/logs-2008-06-08.counts.txt and shows one call stack per line (only top three locations are represented for each call stack). A few groups of warnings stand out: 10 of them are invalid calls to free() or friends, 30 of them involve WideCharToMultiByte, 50 of them are in ds3d or ds3d8, and 60 of them are in Gecko. (Ooodles and oodles are caused by nvidia's libgl, libfontconfig, libexpat, and libc; most of these are suppressed, or you'd die of bordom or anger reading the logs.) As before, the log broken out by directory is at http://kegel.com/wine/valgrind/logs-2008-06-08/ The full log is at http://kegel.com/wine/valgrind/logs-2008-06-08.log.gz This is run with --track-origins=yes, so you get nifty stack tracebacks for where the undefined values got their initial, um, nonvalue. This is often quite helpful for narrowing down the cause. The diff against CVS of the tree I ran this on is at http://kegel.com/wine/valgrind/logs-2008-06-08-patch.txt and is mostly the valgrind cleanup patches I've written that have not yet been committed (plus one rough one from Juan). It's given for completeness; I'll resubmit the individual patches once 1.0 is out. Oh, and the suppressions file I use is rather bigger now. As always, it's at http://kegel.com/wine/valgrind/valgrind-suppressions If you've read this far, congratulations and thanks. Please consider triaging one of these warnings. Just pick one at random, and if you really figure it out, please submit a fix; be sure to include the valgrind warning in the description of the patch. Even if all you figure out is how to improve the test and thereby not generate Valgrind warnings, that's great, please send in your patch. Every test we make squeaky-clean improves the signal-to-noise ratio for finding real problems. (But please don't submit any change you don't really understand, or that seems risky. The goal is not to clean up Valgrind warnings; it's to improve the quality of the test suite.) - Dan

2 1

Wine Profiling
by Stephen Eilert 09 Jun '08

09 Jun '08

Hi, I'd like to know what's the procedure being used to profile Wine's code. More specifically, I want to try to track down slowdowns in some applcations, which requires profiling to identify where the bottlenecks are. Are there any specific procedures or utilities to instrument and generate profiling reports? Stephen

3 2

Re: Downgrade lack of libxslt from configure warning to notice
by Vitaliy Margolen 08 Jun '08

08 Jun '08

Gerald Pfeifer wrote: > On a test system of mine which does not feature too many packages I am > getting the following: > > configure: libsane development files not found, scanners won't be supported. > configure: libgphoto2 development files not found, digital cameras won't be supported. > configure: libldap (OpenLDAP) development files not found, LDAP won't be supported. > configure: libcapi20 development files not found, ISDN won't be supported. > configure: WARNING: libxslt development files not found, xslt won't be supported. > > Looking that libxslt only seems to be used by msxml3, I am wondering > whether this really is worth a warning? > No, if anything any missing part should stop configure and exit with error. And if you force compiling without some feature Wine should be marked "tainted". So all bug reports and calls for help can be easily filtered and ignored. In short NEVER ignore missing dependencies. You never know what windows app might use and why. Vitaliy.

1 0

Re: Downgrade lack of libxslt from configure warning to notice
by Marcus Meissner 08 Jun '08

08 Jun '08

On Sun, Jun 08, 2008 at 10:42:32PM +0200, Gerald Pfeifer wrote: > On a test system of mine which does not feature too many packages I am > getting the following: > > configure: libsane development files not found, scanners won't be supported. > configure: libgphoto2 development files not found, digital cameras won't be supported. > configure: libldap (OpenLDAP) development files not found, LDAP won't be supported. > configure: libcapi20 development files not found, ISDN won't be supported. > configure: WARNING: libxslt development files not found, xslt won't be supported. > > Looking that libxslt only seems to be used by msxml3, I am wondering > whether this really is worth a warning? > > How about the patch below? It probably should be an error, since otherwise msxml3 is only partial functional aka "broken". Ciao, Marcus

1 0

hey, small wine job on a rent-a-coder site
by Dan Kegel 08 Jun '08

08 Jun '08

Anyone want to do a Picasa-like packaging of a commercial app? I just saw http://www.getacoder.com/projects/create_prm_deb_package_80623.html The offered fee is about 10x too small, but perhaps somebody would be interested in the challenge anyway.

1 0

RE: Some feedfack for string {\style} on msi
by Ge van Geldorp 08 Jun '08

08 Jun '08

> I am trying to fix the bug 13408 related with ActiveSync, but > i need some information of how and when appear the string > {\style} on msi. > I need some specification or url for begin. Try http://msdn.microsoft.com/en-us/library/aa367524(VS.85).aspx (or search for "Adding Controls and Text").

2 1

re: Valgrind and COD4
by Dan Kegel 08 Jun '08

08 Jun '08

Rico schrieb: > I'd like to run valgrind + wine + cod4. > [But when I run valgrind on my game], I got the preloader problem. That's a known problem, but it's not a serious one. [Still, John Reiser is working on a fix for it.] The real problem in your log is this: Memcheck: mc_main.c:817 (get_sec_vbits8): Assertion 'n' failed. Memcheck: get_sec_vbits8: no node for address 0x6032050 (0x6032054) You're using an old version of Valgrind, and wine is blowing its little mind. Please switch to building Valgrind out of svn; see http://wiki.winehq.org/Wine_and_Valgrind Good luck, and let me know how it goes! - Dan

2 3

Bugzilla bugs.winehq.org and it's git out of sync
by Jan Zerebecki 08 Jun '08

08 Jun '08

The git repository contains version 3.0.4 but bugs.winehq.org still shows 3.0.2 . Can anyone who has access to it look after that? Thanks. Jan

2 1

Re: [2/2] gdi32/dib: Fix palette of 1bpp DIB in GetDIBits
by Eric Pouech 08 Jun '08

08 Jun '08

Michael Karcher a écrit : > Windows always generates a black/white palette for 1 bit DIBs > generated from DDBs. Copying from the current palette only takes > place for color DDBs (not explicitly mentioned in MSDN), and only > if depth equal (MSDN states it, explicitly). > --- > As mentioned in [1/2], this series is intended to fix #6519, but a > third patch is needed additionally to these two patches. The patch > by Eric in the buglog does that job, but I think there is an "more > obviously correct" solution to it. I let Eric submit a patch if he > wants, as he tracked down the problem. If he tells me to go on, I > will submit my version myself instead. > I didn't retest after your two patches, but basically what my patch does is: - ensure we convert non black pixels (from DIB) into white pixels (in monochrome bitmap) in all cases - zero out the end of lines (after last pixel up to next dword aligned bit) this bug (and the mentionned 3 patches) are IMO good candidates for 1.0 the last item of this patch is not mandatory here, and can be dropped before inclusion to 1.0 (if needed) regarding this last patch and Michael comment: I'm only concerned with having the best fix in wine (who ever wrote it) so what's your idea about the fix ? A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

2 1

AutoCad and wine
by Louis Lenders 08 Jun '08

08 Jun '08

This seems to be a must have for many people. Would be nice if we could have this running in near futurfe. I found that you can download a few old trialversions from http://www.brothersoft.com/autocad-download-78215.html (this is autocad2006l on the right side you can see the downloadlinks for 2004/2007/2008 as well) I'm currently testing AutoCAD 2004 and with a bit workarounds/tweaking it seems to run but the main issues seem to be with the installer; I'll add some info to the appdb; i'll test other versions lateron; if someone wants to join testing feel welcom ;)

1 0

kernel/debugger tests and win9x/winme
by Paul Vriens 08 Jun '08

08 Jun '08

Hi, I (once more) had a look at the registry on my win95 box and found : HKLM\Software\Microsoft\Windows NT\CurrentVersion This is because we create that key ourselves if it doesn't exist. "Windows NT" is of course not present on a (normal) win98/winme box so I was wondering how we could change this test. It appears that win9x uses win.ini for the same purpose. Should we change the test to: 1. check if "HKLM\Software\Microsoft\Windows NT" exist 2. if it exist do our normal thing 3. if it doesn't use win.ini ? Or should we check for the "HKLM\Software\Microsoft\Windows NT" key and if doesn't exist skip all tests ? (We do have these keys lingering around after our winetest though). -- Cheers, Paul.

1 0

Some feedfack for string {\style} on msi
by Ángel Guzmán Maeso 07 Jun '08

07 Jun '08

I am trying to fix the bug 13408 related with ActiveSync, but i need some information of how and when appear the string {\style} on msi. I need some specification or url for begin. Cheers. -- Shakaran

1 0

Re: kernel: updated French translation
by Laurent Vromman 07 Jun '08

07 Jun '08

There are a few mistakes in your translations : The right translation for "Overflow" is "Dépassement", not "Dépacement" You often use the word "Mauvais" as a translation for "Bad". Sometimes, it could be better not to translate literally. For example, I think "Niveau de pilote incorrect" is a better translation for "Bad driver level" than "Mauvais niveau de pilote". You should try to avoid "Mauvais" anytime you can. Last thing : I'm not sure "Sémaphore" is a female word in french : http://fr.wikipedia.org/wiki/S%C3%A9maphore_(informatique) Laurent Jonathan Ernst wrote: > ------------------------------------------------------------------------ > > >

4 3

Valgrind and COD4
by Rico 07 Jun '08

07 Jun '08

Hi, I'd like to run valgrind + wine + cod4. But there is a problem: The preloader problem. When I run valgrind --trace-children=yes ~/Desktop/wine/native/wine iw3sp.exe, I got the preloader problem. When I run ~/Desktop/wine/native/wine iw3sp.exe there is no preloader problem. Any hints on this? (The same applies for valgrind+wine+notepad.) Attached is the output from the valgrind run. Cheers Rico

1 0

Regression in winebrowser found and identified
by Pavel Troller 07 Jun '08

07 Jun '08

Hi! Today we've found that winebrowser gets invalid URL consisting of many question marks instead of correct URL, in at least two cases: 1) Attempt to buy a game in Steam (yes, we are regularly doing that) 2) Trying to buy a program called CPT-Master from 3am systems, free demo which shows the problem when "Buy now" button is pressed in its welcome screen, can be downloaded at http://www.3amsystems.com/products/CPT-Master.exe The following commit has been identified as making the regression: e547cf7043e36fecfe5e23d1d6f93a9c5ba89c46 is first bad commit commit e547cf7043e36fecfe5e23d1d6f93a9c5ba89c46 Author: Hans Leidekker <hans(a)it.vu.nl> Date: Sun Apr 6 14:44:31 2008 +0200 winebrowser: Convert to Unicode. :040000 040000 4f3a034b18392677fc0dfd1ed6df7fefe843a10e 0ab8603a13e836a0b91dd2f146df8da59f7e79e4 M programs It really looks related to the problem which I'm reporting :-). BTW, my system is NOT running in Unicode. Maybe is it related ? I hope it is not yet mandatory. I'm using iso-8859-2 encoding, which works much better in my normal working environment. Please do your best to fix it before 1.0, I feel it really bad and I think that many programs may be affected by it. Should I submit a bug too ? With regards, Pavel Troller

2 2

Re: kernel: updated French translation
by Laurent Vromman 07 Jun '08

07 Jun '08

Hi, There is a mistake here : "L'acquéreur de le sémaphore est mort" The right translation is : "L'acquéreur du sémaphore est mort" The translation of "broken pipe" is not good too, but I can't find anything better on the internet. You should maybe try something like "Tube indisponible (broken pipe)", if you think it is better. Laurent Jonathan Ernst wrote: > ------------------------------------------------------------------------ > > >

2 1

French translation only partial?
by Frans Kool 07 Jun '08

07 Jun '08

Hi, I just had a look at the French translation of the dlls/kernel32/nls/winerr_fra.mc file. I noticed only the first 54 messages have been translated, whereas the other 1876 are still the English originals. Was this on purpose? Or was this a partial translation which needs to be finalized (the remaining 97.2%)? I'm all for translating Wine in as many languages as possible, but I doubt this is the way to get there. Is there some way to detect if the 'translation' of a message is identical to the original (English) one and have it show up as 'partially translated' in the translation overview [1]? As a side note, is there any review on translations or is the policy "any translation is better than no translation"? When Wine 1.0 is going to be released, how can we be sure that the application is actually completely translated. For example, if I really wanted to harm translations, I could make a copy of all English resource files, just change the 'LANGUAGE LANG_ENGLISH, SUBLANG_DEFAULT' to whatever language I would like to 'translate' and submit them. As far as I know, there is no way of detecting this. Anyone got ideas? Frans. [1] http://pf128.krakow.sdi.tpnet.pl/wine-transl/index.php

2 1

Re: [PATCH] GetUrlCacheEntryInfo*: Handle null dest pointer when length is given
by Rob Shearman 07 Jun '08

07 Jun '08

2008/6/6 Jon Griffiths <jon_p_griffiths(a)yahoo.com>: > - if (dwRequiredSize > *lpdwBufferSize) > - { > - *lpdwBufferSize = dwRequiredSize; > + ret = dwRequiredSize > *lpdwBufferSize? FALSE : TRUE; > + *lpdwBufferSize = dwRequiredSize; > + > + if (!ret) > SetLastError(ERROR_INSUFFICIENT_BUFFER); > - return FALSE; > + else if (!lpCacheEntryInfo) > + { > + SetLastError(ERROR_INVALID_PARAMETER); > + ret = FALSE; > } > - *lpdwBufferSize = dwRequiredSize; > - return TRUE; > + return ret; > } Internal functions should return an error code instead of calling SetLastError. This avoids situations like this: > @@ -1531,6 +1539,9 @@ BOOL WINAPI GetUrlCacheEntryInfoA( > FALSE /* ANSI */)) > { > URLCacheContainer_UnlockIndex(pContainer, pHeader); > + /* This case is inconsistent w.r.t RetrieveUrlCacheEntryFile */ > + if (!lpCacheEntryInfo && GetLastError() == ERROR_INVALID_PARAMETER) > + SetLastError(ERROR_INSUFFICIENT_BUFFER); > return FALSE; > } > TRACE("Local File Name: %s\n", debugstr_a(lpCacheEntryInfo->lpszLocalFileName)); -- Rob Shearman

2 2

Re: mshtml: Added FIXME about QUERY_USES_HISTORYFOLDER in about protocol.
by Paul Vriens 07 Jun '08

07 Jun '08

Jacek Caban wrote: > --- > dlls/mshtml/protocol.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > > ------------------------------------------------------------------------ > > Hi Jacek, return E_NOTIMPL; + case QUERY_USES_HISTORYFOLDER: + FIXME("Unsupported option QUERY_USES_HISTORYFOLDER\n"); default: return E_FAIL; } shouldn't there be a "return E_NOTIMPL" after the FIXME as we do with the others? -- Cheers, Paul.

3 2

RE: d3d8: Fix the null condition in ApplyStateBlock
by Stefan Dösinger 06 Jun '08

06 Jun '08

What would be interesting to know is which effect this has on the states, but not in this patch I'd say, and not before the 1.0 release. In the long run it might be an idea to port the d3d9:stateblock test to d3d8 and see how d3d8 behaves

1 0

Re: urlmon: Fix a few failing tests in win2k3
by Jacek Caban 06 Jun '08

06 Jun '08

James Hawkins wrote: > Hi, > > Changelog: > * Fix a few failing tests in win2k3. You've fixed tests on IE7, not only win2k3. It would be better to change Wine to behave like IE7. Also your patch lefts some variables in wrong state. I will send patches to fix it. Jacek

2 4

Re: [urlmon/tests 2/2] Fix test on IE7 (Resend)
by Jacek Caban 06 Jun '08

06 Jun '08

Hi Paul, Paul Vriens wrote: > Hi, > > This (together with number 1 of course) fixes the tests on IE7 boxes. > > Not sure if a patch for urlmon/protocol.c is needed as well. Let me > know and > I'll sent one. > > Changelog > Fix test on IE7 While fixing such tests it's good to add FIXME in code so info about it won't be lost. It's not documented anywhere which protocol handles which options. I will send a patch. Jacek

1 0

Re: Remove unused variable in dlls/mlang/tests/mlang.c
by James Hawkins 06 Jun '08

06 Jun '08

2008/6/5 Gerald Pfeifer <gerald(a)pfeifer.com>: > > ChangeLog: > Remove unused variable in test_EnumScripts(). > > Index: dlls/mlang/tests/mlang.c > =================================================================== > RCS file: /home/wine/wine/dlls/mlang/tests/mlang.c,v > retrieving revision 1.24 > diff -u -3 -p -r1.24 mlang.c > --- dlls/mlang/tests/mlang.c 4 Jun 2008 11:37:37 -0000 1.24 > +++ dlls/mlang/tests/mlang.c 5 Jun 2008 15:17:51 -0000 > @@ -594,7 +594,6 @@ static void test_EnumScripts(IMultiLangu > > for (i = 0; pGetCPInfoExA && i < n; i++) > { > - CPINFOEXA cpinfoex; > #ifdef DUMP_SCRIPT_INFO > trace("SCRIPTINFO #%u:\n" > "ScriptId %08x\n" > > > http://winehq.org/pipermail/wine-cvs/2008-June/044013.html -- James Hawkins

2 1

Compile wine on Red Hat 9
by Wen Huang 06 Jun '08

06 Jun '08

Hi everybody, I was trying to compile a winehq on Red Hat 9 and I downloaded the source 0.9.60 from sourceforge. When I tried to compile by ./configure make depend make during the make step, it gave an error ..... gcc -c -I. -I. -I../../include -I../../include -I/usr/include/ libxml2 -I/usr/include/libxml2 -D__WINESRC__ -DCOM_NO_WINDOWS_H - D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after- statement -Wwrite-strings -Wpointer-arith -g -O2 -o cdata.o cdata.c cdata.c: In function `domcdata_appendData': cdata.c:601: void value not ignored as it ought to be make[2]: *** [cdata.o] Error 1 make[2]: Leaving directory `/home/tus/wine-0.9.60/dlls/msxml3' make[1]: *** [msxml3] Error 2 make[1]: Leaving directory `/home/tus/wine-0.9.60/dlls' make: *** [dlls] Error 2 Can anybody kindly offer some help? By the way, is there rpm package for wine I can use on Red Hat 9, I tried to use the script on Wine Red Hat wiki to generate a rpm, but it failed at the same step... Thanks, Wen

2 3

Wine in the news
by Dan Kegel 06 Jun '08

06 Jun '08

http://www.australianit.news.com.au/story/0,24897,23797416-24169,00.html The new president of Red Hat, when asked about desktop linux, said: "My simple answer is until Apple's iTunes runs on consumer Linux desktops, it's not going to take off. I know you can run Wine, which runs Windows applications on Linux, so techies will beat me up on that, but fundamentally there are some major device driver issues with products that people like to use and this limits adoption. It's going to be slow until these issues are solved." http://news.zdnet.co.uk/software/0,1000000121,39429910,00.htm http://economyaustria.at/Text/?id=3363378 Vienna migrates some Linux workstations to Vista because a single app, Schlaumäuse, crashes under Wine. Looks like they send the software out upon request to teachers; see http://www.schlaumaeuse.de/ (Can somebody send me a copy?)

4 5

Bad free error involving shdocvw and COM?
by Dan Kegel 06 Jun '08

06 Jun '08

In shdocvw/tests/webbrowser.c, at the end of test_WebBrowser, the call IUnknown_Release(unk) results in the following Valgrind error: Invalid free() / delete / delete[] at notify_free (heap.c:199) by RtlFreeHeap (heap.c:1284) by SysFreeString (oleaut.c:196) by DocHost_Release (dochost.c:550) by WebBrowser_Release (webbrowser.c:153) by test_WebBrowser (webbrowser.c:2028) by func_webbrowser (webbrowser.c:2070) by run_test (test.h:421) by main (test.h:470) Address 0x7f01dc14 is 8 bytes after a block of size 28 alloc'd at notify_alloc (heap.c:191) by RtlAllocateHeap (heap.c:1231) by COMPOBJ_DllList_Add (compobj.c:910) by apartment_getclassobject (compobj.c:794) by get_inproc_class_object (compobj.c:2138) by CoGetClassObject (compobj.c:2238) by get_protocol_cf (session.c:111) by get_protocol_info (session.c:219) by parse_canonicalize_url (internet.c:63) by CoInternetParseUrl (internet.c:184) by URLMonikerImpl_Construct (umon.c:1039) by CreateURLMonikerEx (umon.c:1097) by CreateURLMoniker (umon.c:1123) by create_moniker (navigate.c:564) by bind_to_object (navigate.c:600) by navigate_bsc (navigate.c:657) by navigate_bsc_proc (navigate.c:679) by process_dochost_task (dochost.c:43) by shell_embedding_proc (oleobject.c:65) by ??? (library.h:163) Seems like an important bug to fix, since it could conceivably lead to heap corruption. This is all our code, no gecko involved, so we ought to be able to sort it, but it's beyond my ken.

1 0

[website] Fix typo in Spanish translation of home.template
by Ángel Guzmán Maeso 06 Jun '08

06 Jun '08

Fix several typos -- Shakaran

1 1

Double free error involving dsound and winealsa.drv
by Dan Kegel 06 Jun '08

06 Jun '08

Hmm, freeing a buffer that's already been freed is bad, is it showstopper bad? http://bugs.winehq.org/show_bug.cgi?id=13723

2 1

Re: user32: EnumDisplaySettingsExA: fill in all of lpDevmode->dmDeviceName
by Dmitry Timoshkov 06 Jun '08

06 Jun '08

"Dan Kegel" <dank(a)kegel.com> wrote: > 'Cause if we don't, code that expects it to be defined > is mildly surprised to find that bytes after the string's > terminating nul are undefined. > Fixes 16 Valgrind warnings of the form: > > Use of uninitialised value of size 4 > at mbstowcs_sbcs (mbtowc.c:78) > by wine_cp_mbstowcs (mbtowc.c:266) > by MultiByteToWideChar (locale.c:1846) > by GdiConvertToDevmodeW (driver.c:434) > by ChangeDisplaySettingsExA (sysparams.c:3011) > by ChangeDisplaySettingsA (sysparams.c:2980) > by test_ChangeDisplaySettingsEx (monitor.c:161) > Uninitialised value was created by a stack allocation > at test_ChangeDisplaySettingsEx (monitor.c:141) GdiConvertToDevmodeW should be fixed instead. -- Dmitry.

1 0

Re: kernel32: tests/path.c: Improve test for GetLongPathNameA
by James Hawkins 05 Jun '08

05 Jun '08

On Wed, Jun 4, 2008 at 8:38 PM, Zac Brown <zac(a)zacbrown.org> wrote: > Add test to check for GetLongPathNameA on GetModuleFileNameA's returned > string. > > Found via errors existing in shell32/tests/shelllink.c. Checked against > Windows XP and Windows 2000. > + pGetModuleFileNameA = + (void*)GetProcAddress( GetModuleHandleA("kernel32.dll"), "GetModuleFileNameA" ); GetModuleFileNameA is available on all platforms, and besides, you use it without checking if it's NULL. +/* Try getting the long path of your module name */ + if(pGetLongPathNameA) { + ok(pGetModuleFileNameA(NULL,tmpstr,sizeof(tmpstr)),"GetModuleFileNameA failed %s\n", + tmpstr); + todo_wine ok(pGetLongPathNameA(tmpstr,tmpstr1,MAX_PATH),"GetLongPathNameA failed %s\n", + tmpstr); + } What is this testing? Just that GetLongPathName doesn't fail in this case (I'm not even sure what 'this case' is specifically)? You should be checking the return value and the value of the out variable. -- James Hawkins

1 0

Re: gdi32/tests: Take into account several Win9x bugs in GetObject(). (take 3)
by Paul Vriens 05 Jun '08

05 Jun '08

Francois Gouget wrote: > --- > > This time without the bug that caused tests to fail in Wine and on > Windows XP. > > > + SetLastError(0xdeadbeef); > ret = GetBitmapBits(hbm, 0, NULL); > - ok(ret == bm.bmWidthBytes * bm.bmHeight, "%d != %d\n", ret, bm.bmWidthBytes * bm.bmHeight); > + gle=GetLastError(); > + ok(ret == bm.bmWidthBytes * bm.bmHeight || (ret == 0 && gle == ERROR_INVALID_PARAMETER /* Win9x */), "%d != %d\n", ret, bm.bmWidthBytes * bm.bmHeight); Any reason this one isn't put into a broken() for win9x (as you did with all the others). -- Cheers, Paul.

2 1

re: [PATCH] oleaut32: Fix valgrind warnings in vatype.c test
by Dan Kegel 05 Jun '08

05 Jun '08

Hi Jon, I guess http://www.winehq.org/pipermail/wine-patches/2008-May/055352.html must have been too scary to commit. I independently sent in a fix for the easy part, and it was committed as http://winehq.org/pipermail/wine-cvs/2008-June/043999.html The last part of your patch, having to do with SysAllocStringByteLen(), seems correct to me, offhand. Maybe if you clean up the comment a bit more, sprinkle sugar on it, and resend, it'll make it in this time. It's so gross, though, that it really should serve as a reminder to us to switch to IMalloc... - Dan

2 1

Re: [AppDB] Allow admins to remove their admin rights
by Alexander Nicolaysen Sørnes 04 Jun '08

04 Jun '08

På Onsdag 04 juni 2008 , 01:24:07 skrev Chris Morgan: > What new policy on dissidents? ;-) > > How does this patch enable admins to remove themselves? I'm afraid I > can't see how this change lets an admin remove their own admin status. > > Chris > > Yea, that particular piece of code isn't very clear on what it's doing. I found out that $aClean['iUserId'] would only be set when modifying another user, and it previously compared it to $oUser->iUserId before allowing the admin removal. Now we only check for admin rights, and the oUser->iUserId == aClean['iUserId'] check is performed later to see if we should redirect back to the user admin page. > > On Tue, Jun 3, 2008 at 6:34 AM, Alexander Nicolaysen Sørnes > > <alex(a)thehandofagony.com> wrote: > > This is in accordance with the AppDB's new policy on dissidents. :) > > > > > > Alexander N. Sørnes

2 3

Fixing crashes in Tests (OS version check)
by Alistair Leslie-Hughes 04 Jun '08

04 Jun '08

Hi, I've being investigating crashes that occur on Win98 when the tests run. I have fixed a couple already which where trivial. When I attempted to fix the snmpapi tests, I have found that i will end up removing alot of tests (~ 17). If I add a check for the windows version, I can skip the tests that will crash, also there is already tests with if(0) around them. What is the policy about checking the version of the OS before running certain tests? Best Regards Alistair Leslie-Hughes

8 11

Time to revert bad commits?
by Vitaliy Margolen 04 Jun '08

04 Jun '08

I'm afraid we are out of time to fix bugs that introduces major d3d regressions. I've yet to see a single patch that addressed those issues. It's time to start reverting bad commits and testing the results. The bugs I'm talking about: Bug 10580 Bug 11584 Bug 12794 Bug 13101 Vitaliy.

6 9

Re: mmio: Do not zero current file position whenever mmioSetBuffer is called
by Christoph Frick 04 Jun '08

04 Jun '08

On Tue, Jun 03, 2008 at 07:57:00PM -0700, Matthew D'Asaro wrote: > Instead I set wm->info.lBufOffset to wm->info.lDiskOffset because the > buffer is flushed at the beginning of a call to mmioSetBuffer so > wm->info.lDiskOffset is synchronized with wm->info.lBufOffset and so > wm->info.lDiskOffset contains the correct current file position. The > test for mmio still passes with this patch. wouldn't that indicate, that the current patch does not cover that case? can you add a test for it? -- cu

1 0

Re: urlmon: Fix a test that fails on all platforms
by Dmitry Timoshkov 04 Jun '08

04 Jun '08

"James Hawkins" <jhawkins(a)codeweavers.com> wrote: > - ok(IBindCtx_Release(bctx) == 0, "bctx should be destroyed here\n"); > + > + if(bindf & BINDF_ASYNCHRONOUS) { > + ok(IBindCtx_Release(bctx) == 1, "bctx should not be destroyed here\n"); > + IBindCtx_Release(bctx); /* actually destroy it */ > + } > + else > + ok(IBindCtx_Release(bctx) == 0, "bctx should be destroyed here\n"); Wouldn't it be better to change it this way: if(bindf & BINDF_ASYNCHRONOUS) ok(IBindCtx_Release(bctx) == 1, "bctx should not be destroyed here\n"); ok(IBindCtx_Release(bctx) == 0, "bctx should be destroyed here\n"); -- Dmitry.

2 1

Re: advpack: fix a test failure on 9x
by James Hawkins 04 Jun '08

04 Jun '08

On Tue, Jun 3, 2008 at 7:17 PM, Austin English <austinenglish(a)gmail.com> wrote: > This isn't the right fix. The RegisterOCX command doesn't work in win9x, so it needs to be changed to another command. -- James Hawkins

1 0

Re: kernel32: avoid thread-unsafe function gmtime()
by Dmitry Timoshkov 04 Jun '08

04 Jun '08

"Dan Kegel" <dank(a)kegel.com> wrote: > Using gmtime() in a multithreaded program could > result in invalid results. So use the safer alternative > gmtime_r() if it's available. Most likely gmtime_r() should be used without #ifdefs and a replacement put in libs/port. -- Dmitry.

1 0

Re: [programs/winetest] Put up a warning message before running
by James Hawkins 04 Jun '08

04 Jun '08

On Tue, Jun 3, 2008 at 8:27 AM, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > Hi, > > Due to the fact that we have several ordinary users trying out winetest I > think > it makes sense to put up this message. > > The message will not be shown in quiet mode and not in expert mode (new one > '-x'). > > Changelog > Put up a warning message before running > No this is a bad idea, mostly because winetest is not particularly intended to be run by 'ordinary users', and anyone that does run winetest should be well aware of the supposed 'dangers' of running it. On top of this, running winetest should not be dangerous in the first place, and more effort should be put into fixing tests that crash the tests or the system. -- James Hawkins

3 3

Valgrind note
by Dan Kegel 03 Jun '08

03 Jun '08

For those of you using valgrind with --track-origins, make sure you're using a tree with vex rev >= 1854; Julian Seward says there was a problem that could cause segfaults. If in doubt, grab a fresh valgrind tree from svn.

1 0

Re: msi:MsiSourceListEnumMediaDisksW: free original string, not substring
by Steven Edwards 03 Jun '08

03 Jun '08

On Tue, Jun 3, 2008 at 9:29 AM, Dan Kegel <dank(a)kegel.com> wrote: > Found via valgrind: > > Invalid free() / delete / delete[] > by msi_free (msipriv.h:965) > by MsiSourceListEnumMediaDisksW (source.c:324) > Address 0x7f01b2ac is 12 bytes inside a block of size 54 alloc'd > by msi_alloc (msipriv.h:945) > by MsiSourceListEnumMediaDisksW (source.c:273) > > 'data' is freed later, so don't touch it. I think I know of one application that might be affected by this. With the Project 2003 installer it reports an error I believe in this function. -- 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

1 0

userenv: tests/userenv.c: fix buffer overrun
by Dan Kegel 03 Jun '08

03 Jun '08

Found via valgrind. Fixes Use of uninitialised value of size 4 at wine_cp_mbstowcs (mbtowc.c:79) by MultiByteToWideChar (locale.c:1846) by CompareStringA (locale.c:2722) by get_env (userenv.c:140) by func_userenv (userenv.c:218) Uninitialised value was created by a stack allocation at get_env (userenv.c:128)

1 0

Trip & Conference Report Linux Tag 2008
by Marcus Meissner 03 Jun '08

03 Jun '08

Hi, I was at LinuxTag 2008, which is the largest Linux User fair in Germany. The fair was from Wednesday to Saturday, however I was only there Saturday. Saturday was openSUSE day and we (openSUSE) had a conference track over the whole day. One of those talks in this track was my talk on "Wine - applications and games on Linux". My talk was well received, the lecture hall was about 80% full with around 180-200 people. My german slides are at: http://files.opensuse.org/opensuse/en/0/08/Lt2008-wine.pdf http://files.opensuse.org/opensuse/en/6/66/Lt2008-wine.odp 2 smaller german online journals commented on it, mostly regarding the 1.0 release part: http://www.golem.de/0806/60100.html http://www.oszine.de/node/9141 (There might even be a Video recording later on.) I received totally unexpected applause on announcing that after 15 years we finally come to 1.0 release (after over 200 alphas, and 60 betas). After the talk I had 10 people around me asking questions, and one specific problem with Adobe InDesign FileOpen Dialog on a laptop brought to the openSUSE booth. Interesting Wine related points: - Kai Tietz of mingw64 told me that they have a GCC patch ready for gcc 4.4 which will support the Win64 calling convention attribute just like __attribute__(stdcall). Was committed to GCC TRUNK: http://gcc.gnu.org/viewcvs?view=rev&sortby=date&revision=136311 __attribute__(ms_abi) If we have more GCC requirements for Win64, he is willing to help. In general he would like to have Wine as a testbed for mingw64 development (and we could use it as testbed the other way round). http://mingw-w64.sf.net/ - Avira (Antivirus vendor) They use Wine in house to at least get some info on Windows DLLs, using version.dll.GetFileVersionInformation. While this works for Win32 DLLs, it stopped working/currently does not work for Win64 DLLs. - scan.coverity.com Talked to Coverity folks, and also to David Maxell. The application will receive an update from Coverity 2.9 to 3.2 in the next days/weeks. Not sure if it brings new features. Also process issue: We have a large backlog of UNINSPECTED features. They suggested that in those cases we could just say "lets not look at this old cruft" and mark them somehow "PENDING" or similar. Not sure it helps us, but at least we could use "PENDING" for partially inspected issues. - Booth or no Booth (We had no booth this year.) Since the question will likelay appear again, I thought about whether to have a Wine booth itself next year... Well, if we dont have at least 2 people there over the whole 4 days it does not make sense and finding those 2+ people likely is difficult. I might be able to spare the time, but this year it was not possible due to overlapping schedule. Perhaps its also easier to have a demo-point on another larger booth (could ask openSUSE if they would have Wine there). At least the Saturday visitors got their knowledge on Wine increased by my talk at least. I got the feeling that people are still quite unsure what works and what not and expect clear and definitive statements from us. I pointed to the AppDB several times in those cases and tried not to make overly positive statements. People are expectant on 1.0 and I think they are willing to be suprised. Ciao, Marcus

2 1

Re: ddraw: Don't release ddraw if a surface is still using it.
by Jens Albretsen 03 Jun '08

03 Jun '08

> Am Samstag, 31. Mai 2008 17:03:13 schrieb Michael Karcher: >> > Anyway it makes wine stop crashing when programs tries to do something >> > crazy like this. Stefan DÃ¶singer asked me to put a HeapAlloc all >> memory >> > between the two Release's to check if the memory of ddraw object would >> be >> > corrupt in Windows. It really doesn't matter if programs live by >> chance >> > in windows, if we can implement it so it's not by chance anymore. >> >> I agree on that point. > Actually, that is dangerous. There may be situations in which this > make-something-work has an unintended side effect, e.g. failure to restore > the display mode because the ddraw object isn't destroyed(although it > maybe > should be - it's the test's job to find that out). You're right, if we expect every program to behave. I guess we need a hook for wined3d (if we not already have it) to restore the state back at process termination, if there is stuff not freed, changed video modes and such. I believe d3d does this natively, if you change video and there is a abnormal program termination it will restore the video mode and if you're running with debug libraries it will tell you what you forgot to free, at least in Windows XP. I actually ran wine without virtual desktop at one point where program crashed, had to hard reset because video wasn't restored, CTRL+ALT+BACKSPACE didn't work, so now i'm running everything in a virtual desktop, so I guess there isn't any hook and we expect all programs to behave. The hook could probably be put wined3d_main.c/DllMain() fdwReason == DLL_PROCESS_DETACH so it closes wined3d correctly, in the event of abnormal program execution. > Another possibility are apps that intend to cause an exception, like copy > protection systems. Anyway still need to know if the test fails or passes in Windows.

2 1

Failing tests: now what?
by Juan Lang 03 Jun '08

03 Jun '08

Following through with Francois's suggestion, I extracted the user32 tests. They still fail for me: 81 failures in menu.c, all having to do with the expected width of menu items [1], which is precisely what I wanted to address. So I'm stymied how I'm going to convince Alexandre that my little menu patch [2] is correct. Vim is clearly broken without the patch, and looks correct with it. The user32 tests pass for me (in Wine) with and without the patch. None of the apps I've tried appear changed by the patch, though there's always the possibility. I can't verify it's correct in the usual way, by writing a test, because the existing tests fail for me in Windows. (Alexandre's never said he wants a test, but then again he hasn't said anything yet, either.) If anyone has any suggestions how I can get this accepted, I'm all ears. Thanks, --Juan [1] Typical failure: menu.c:432: Test failed: menu width wrong, got 109 expected 102 [2] http://www.winehq.org/pipermail/wine-patches/2008-May/055101.html

1 0

Re: Keep swapchain while its backbuffer is in use.
by Michael Karcher 02 Jun '08

02 Jun '08

Am Montag, den 02.06.2008, 22:51 +0200 schrieb Michael Karcher: > This fixes the warn+heap errors/crashes of d3d9:stateblock, and should > close the bug about differences with warn+heap enabled. Thats #12246, one of the 1.0 targeted bugs. I was offline while writing the patch email, so I could not look up the number. Regards, Michael Karcher

1 0

Re: winedbg: Fix 'winedbg --auto' so it does just one backtrace.
by Alexandre Julliard 02 Jun '08

02 Jun '08

Francois Gouget <fgouget(a)codeweavers.com> writes: > 'winedbg --auto' already prints a backtrace before the modules list. So > there is no need to print another one after everything else. Actually there are cases where it doesn't, which is why I added this. It's better to have two backtraces than none. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [2/2] wined3d: Set the surface location to SFLAG_INSYSMEM for depth stencils on Reset
by Stefan Dösinger 02 Jun '08

02 Jun '08

Am Montag, 2. Juni 2008 21:12:54 schrieb H. Verbeet: > This fixes a rather major regression when using FBOs for offscreen > rendering. Since we destroy the GL texture associated with the > surface, and INDRAWABLE and INTEXTURE are the same for offscreen > targets when using FBO ORM, the texture would never get recreated for > the depth stencil. Depth stencils are special in this regard since > they can switch between being onscreen and offscreen, for the other > implicit surfaces this isn't an issue. This should also fix bug 12794. > (This bug does expose issues with the surface management code, but I > don't think those are fixable before 1.0) updateSurfaceDesc releases the allocated system memory, so setting INSYSMEM is dangerous as well since allocatedMemory = NULL. depth stencils are't lockable, so we may get away with that, but it is still dangerous I think

2 1

Re: [2/2] Wineshader: Hardcode local constants with glUniform4fvARB
by Stefan Dösinger 02 Jun '08

02 Jun '08

Am Montag, 2. Juni 2008 21:45:07 schrieb Stefan Dösinger: Erm, the proper library is wined3d, not wineshader. "wineshader" is my current in-development HLSL compiler lib...

1 0

Invalid '...' in resources
by Francois Gouget 02 Jun '08

02 Jun '08

The files below contain ' . . .' instead of '...'. This is invalid typographically in at least English, French and Russian. Could someone check if it is valid for the relevant languages: Danish Dutch Hungarian Korean Norwegian Turkish ./programs/winefile/No.rc ./programs/oleview/No.rc ./programs/clock/No.rc ./programs/cmd/Da.rc ./programs/cmd/No.rc ./programs/taskmgr/No.rc ./programs/notepad/No.rc ./programs/winhlp32/No.rc ./programs/progman/No.rc ./programs/cmdlgtst/No.rc ./programs/wordpad/Ko.rc ./programs/wordpad/No.rc ./programs/wordpad/Tr.rc ./programs/wordpad/Nl.rc ./programs/wordpad/Hu.rc ./programs/winecfg/No.rc ./programs/regedit/Ko.rc ./programs/regedit/Da.rc ./programs/regedit/No.rc ./programs/regedit/Nl.rc ./dlls/setupapi/No.rc ./dlls/mshtml/No.rc ./dlls/gphoto2.ds/gphoto2_No.rc ./dlls/shell32/shell32_No.rc ./dlls/sane.ds/sane_No.rc ./dlls/msvfw32/msvfw32_No.rc ./dlls/msvfw32/msvfw32_Da.rc ./dlls/oledlg/oledlg_No.rc ./dlls/msacm32/msacm_Da.rc ./dlls/msacm32/msacm_No.rc ./dlls/comdlg32/cdlg_No.rc ./dlls/browseui/rsrc_No.rc ./dlls/shdoclc/Da.rc ./dlls/shdoclc/No.rc ./dlls/user32/resources/user32_No.rc -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ La terre est une bêta...

3 2

How to handle lack of internet connection in conformance tests
by Austin English 02 Jun '08

02 Jun '08

For curiousity's sake, I tested my work XP box today, first as usual, then after a reboot and disabling the network connection: http://test.winehq.org/data/b4bf3553c4071a2a6979f1df08ae75aadde94b4b/#group… http://test.winehq.org/data/b4bf3553c4071a2a6979f1df08ae75aadde94b4b/xp_aen… http://test.winehq.org/data/b4bf3553c4071a2a6979f1df08ae75aadde94b4b/xp_aen… Most of the tests came out the same, with some spurious failures in MSI/dinput/user32/etc. The interesting ones would be the urlmon/wininet. Some of these tests timeout (urlmon: protocol/url, wininet:http) , some failed (msxml3:domdoc), and some still passed(!) (wininet:ftp, wininet:generated, wininet:internet, wininet:url, wininet:urlcache, ws2_32:protocol, urlmon:misc). I haven't tested wine yet, as I can't bring down the network connection on any of the boxes I can currently test on, but I'll do so when I next get a chance. Either way, seems some of this behavior could be made more consistent (if network connection is down, either skip or timeout, but don't fail). I may try later with leaving the network connection up but removing the internet connection at the router... -Austin

1 0

Crash in test d3d9:stateblock with warn+heap is a wine bug
by Michael Karcher 02 Jun '08

02 Jun '08

Hello developers (mostly direct3d hackers), the infamous crash in d3d9:stateblock [1] is caused by a call sequence that is forbidden according to the DirectX SDK documentation. The switch_rendertarget test makes a new swap chain, and sets its backbuffer as new rendering target, and then releases the swap chain. The backbuffer is obtained by GetBackBuffer on the new swapchain. The SDK tells states explicitly that you have to release all surfaces obtained by GetBackBuffer before you release the swapchain itself. [2] In Windows, this buggy behaviour seems to work nicely (no crash in the d3d9:stateblock test and no errors with maximum debugging settings in the debugging d3d9 runtime), whereas on wine, at releasing the backbuffer finally, some access to the state is made which has already been released with the swapchain. So, we have two options: - Consider using backbuffer of released chains buggy: Fix the test to not release the swapchain Upgrade the FIXMEs in dlls/wined3d/swapchain.c, lines 95 and 104 to ERR - Implement behaviour seemingly compatible to Windows: Have a hidden reference counter to the swap chain or for the contexts to prevent them from getting freed too early. Does anyone knows whether the test has this been written buggy on purpose (some app does this), or it is by accident? Regards, Michael Karcher [1]: Bugs 9916, 12246 [2]: http://msdn.microsoft.com/en-us/library/bb205902(VS.85).aspx

3 4

Winetest grrr...
by Juan Lang 02 Jun '08

02 Jun '08

Since my tiny little menu patch didn't go in, I figured Alexandre wanted a test. So I tried to compile and run the existing one on Windows XP. It failed for me: lots of menu size tests failed. I checked the test.winehq.org data, and I don't see lots of failures on XP, so... I thought I'd run winetest.exe from Paul Millar's site, just in case the compilation environment had something to do with it. That locks up my laptop somewhere in the d3d/ddraw tests. I know some video drivers are so broken we don't want to run on them. I have an ATI Radeon Mobility 250. I thought this was a fairly common card. Is locking up the machine really acceptable here? How the ^$*@ am I supposed to produce a test when the existing ones fail/crash/burn for me? Grrr... --Juan

5 9

Re: winex11.drv: Add support for AlphaBlend with non-opaque SourceConstantAlpha values.
by Peter Urbanec 02 Jun '08

02 Jun '08

Ángel Guzmán Maeso wrote: > A small change: > > +int x,y; > +for (x = 0; x < widthSrc; x++, tmpBits += 4) > + for(y=0;y<4;y++) > + tmpBits[y] = tmpBits[y] * blendfn.SourceConstantAlpha / 255; I'm not fussed one way or the other, but I can see at least two advantages in keeping the original code: 1) It's slightly more obvious that the data we are dealing with is four bytes of R, G, B and A - although a comment to that effect would be a better solution. 2) Compiler optimisers may do a slightly better job on the already unrolled loop. I'll leave it to Alexandre and co. to pick and choose which version makes it in.

1 0

Re: snmpapi: Stop tests from crashing on win98
by Paul Vriens 02 Jun '08

02 Jun '08

Alistair Leslie-Hughes wrote: > Hi, > > Changelog: > snmpapi: Stop tests from crashing on win98 > > Best Regards > Alistair Leslie-Hughes > > > > > ------------------------------------------------------------------------ > > I still don't think they should be removed but that's my opinion. If not running is preferable shouldn't we just if(0) them and add some comments? -- Cheers, Paul.

2 1

Re: user32: Fix input tests failing on WinXP+ (resend)
by Vitaliy 02 Jun '08

02 Jun '08

Vitaliy Margolen wrote: > --- > dlls/user32/tests/input.c | 29 +++++++++++++++++------------ > 1 files changed, 17 insertions(+), 12 deletions(-) >

1 0

Re: [PATCH] winealsa: Raise ALSA minimum period size to sane value
by John Klehm 02 Jun '08

02 Jun '08

On Sun, Jun 1, 2008 at 6:58 PM, Zephiris <zephiris(a)gmail.com> wrote: > The ALSA period size can be set to rather odd values, and querying the > minimum period size isn't always guaranteed to be sane. Use a safety net > value. This fixes bug 13458. > > --- > > dlls/winealsa.drv/dsoutput.c | 5 +++++ > 1 files changed, 5 insertions(+), 0 deletions(-) > Please use your real name, Wine doesn't accept anonymous patches. --John

1 0

iexplore/gecko problems with recent builds
by Steven Edwards 02 Jun '08

02 Jun '08

Hi, I did not find anything about this in bugzilla. Is anyone else having problems using builtin IE with gecko? I keep getting this error with the tip err:mshtml:before_async_open GetWineURL returned NULL -- 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

1 1

Re: Revert "wined3d: Put implicit surfaces into drawable on unload."
by H. Verbeet 02 Jun '08

02 Jun '08

2008/6/2 Vitaliy Margolen <wine-patches(a)kievinfo.com>: > This reverts commit 0de167db9e2ef6c62ba48b050bc3d0ba2638467f. > Fixes bug 12794 and probably others related to the black screen with enabled > FBO. > --- > dlls/wined3d/surface.c | 11 ++--------- > 1 files changed, 2 insertions(+), 9 deletions(-) > I've actually got a more correct fix for this, which I'll send in later today.

1 0

Re: [try 4] user32: Use correct buffer header for cursor inCURSORICON_LoadFromFile
by Dmitry Timoshkov 02 Jun '08

02 Jun '08

"Sergey Khodych" <khodych(a)gmail.com> wrote: > CreateIconFromResourceEx expects POINT16 at beginning of input buffer( > for cursors ). > Fixes bug #5031. Please follow the indentation/braces style of the file you are changing. -- Dmitry.

1 0

Re: [1/3] ddraw/tests: Detach surface if attaching worked by surprise (or refrast)
by James Hawkins 02 Jun '08

02 Jun '08

On Sun, Jun 1, 2008 at 5:47 PM, Michael Karcher <wine(a)mkarcher.dialup.fu-berlin.de> wrote: > --- > dlls/ddraw/tests/dsurface.c | 3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > Patch already sent: http://winehq.org/pipermail/wine-patches/2008-May/055424.html -- James Hawkins

2 1

Re: [2/3] ddraw/tests: Add another refrast exception
by James Hawkins 02 Jun '08

02 Jun '08

On Sun, Jun 1, 2008 at 5:48 PM, Michael Karcher <wine(a)mkarcher.dialup.fu-berlin.de> wrote: > --- > dlls/ddraw/tests/dsurface.c | 5 ++++- > 1 files changed, 4 insertions(+), 1 deletions(-) > I've gone through all the latest test results, and this failure isn't happening anywhere that I've seen. Please link to where you're seeing this. -- James Hawkins

2 1

Re: advapi32: RegEnumKeyEx() should return "ERROR_INVALID_PARAMETER" if name_len is NULL
by James Hawkins 01 Jun '08

01 Jun '08

On Sun, Jun 1, 2008 at 11:28 AM, Andrew Talbot <andrew.talbot(a)talbotville.com> wrote: > Like native. > > -- Andy. > --- > Changelog: > advapi32: RegEnumKeyEx() should return "ERROR_INVALID_PARAMETER" if name_len is NULL. > > diff --git a/dlls/advapi32/registry.c b/dlls/advapi32/registry.c > index 9ce3da0..41ef3bf 100644 > --- a/dlls/advapi32/registry.c > +++ b/dlls/advapi32/registry.c > @@ -473,7 +473,7 @@ LSTATUS WINAPI RegEnumKeyExW( HKEY hkey, DWORD index, LPWSTR name, LPDWORD name_ > TRACE( "(%p,%d,%p,%p(%d),%p,%p,%p,%p)\n", hkey, index, name, name_len, > name_len ? *name_len : -1, reserved, class, class_len, ft ); > > - if (reserved) return ERROR_INVALID_PARAMETER; > + if (!name_len || reserved) return ERROR_INVALID_PARAMETER; > if (!(hkey = get_special_root_hkey( hkey ))) return ERROR_INVALID_HANDLE; > > status = NtEnumerateKey( hkey, index, KeyNodeInformation, > @@ -537,7 +537,7 @@ LSTATUS WINAPI RegEnumKeyExA( HKEY hkey, DWORD index, LPSTR name, LPDWORD name_l > TRACE( "(%p,%d,%p,%p(%d),%p,%p,%p,%p)\n", hkey, index, name, name_len, > name_len ? *name_len : -1, reserved, class, class_len, ft ); > > - if (reserved) return ERROR_INVALID_PARAMETER; > + if (!name_len || reserved) return ERROR_INVALID_PARAMETER; > if (!(hkey = get_special_root_hkey( hkey ))) return ERROR_INVALID_HANDLE; > > status = NtEnumerateKey( hkey, index, KeyNodeInformation, > Please add a test. -- James Hawkins

1 0

Re: [2/2] ddraw: Rename IDirectDraw functions (try 2)
by Christian Costa 01 Jun '08

01 Jun '08

Hi Michael, I think it would be better to fix function names in IDirectDraw7. Christian Michael Karcher a écrit : > The functions implementing IDirectDraw are called IDirectDrawImpl_Foo, > the ones implementing IDirectDraw7 are called alike. As they are > static functions in different files, the compiler has no problems > distinguishing them, but it confuses the reader of TRACE messages. > --- > dlls/ddraw/ddraw_thunks.c | 92 ++++++++++++++++++++++---------------------- > 1 files changed, 46 insertions(+), 46 deletions(-) > > ------------------------------------------------------------------------ > >

3 3

Two quick press mentions about Microsoft and Wine (the other one)
by Dan Kegel 01 Jun '08

01 Jun '08

Microsoft Wine (Sept '07): http://www.sommelierindia.com/blog/2007/10/changing_the_world_with_a_micr.h… Microsoft bans searches for Wine in France (today): http://www.sbpost.ie/post/pages/p/story.aspx-qqqt=MEDIA+AND+MARKETING-qqqs=… Not sinister, just funny. And somewhat inconvenient...

1 0

Re: try 2: shell32: fix SHFileOperation copying to an empty file list
by James Hawkins 01 Jun '08

01 Jun '08

On Sun, Jun 1, 2008 at 1:35 AM, Vincent Povirk <madewokherd+d41d(a)gmail.com> wrote: > This partially fixex bug 13394. > > Apparently there are two separate issues involved in that bug, one > with empty destination lists (which Windows seems to treat as a list > containing one 0-length string), and one involving long filenames. > This patch only addresses the empty lists. > This fix is wrong. We already handle empty file lists in parse_file list. If the list is empty, dwNumFiles is 0. Why did you add another variable for that? Also, you need to add a test case for multiple source files and an empty dest list for the FO_MOVE operation. You will not get ERROR_ACCESS_DENIED (the test will fail with your change). -- James Hawkins

1 0

Acid test: migrating the spouse
by Dan Kegel 01 Jun '08

01 Jun '08

Been looking forward to trying this for a long time. What with Wine 1.0 nearly here, and a brand new computer to populate, I thought I'd try actually migrating my spouse to Linux / Wine, or at least see why it isn't yet practical. I'll record the process here: http://kegel.com/wine/migrating-user-1.html So far it's not quite clear it'll work, but it should be educational, and I'll at least get a bunch of good bug reports out of it. - Dan

2 1

Fwd: shell32: fix SHFileOperation copying to an empty file list
by Vincent Povirk 01 Jun '08

01 Jun '08

Grr, forgot to copy list. ---------- Forwarded message ---------- From: Vincent Povirk <madewokherd+d41d(a)gmail.com> Date: Sat, May 31, 2008 at 9:46 PM Subject: Re: shell32: fix SHFileOperation copying to an empty file list To: James Hawkins <truiken(a)gmail.com> On Sat, May 31, 2008 at 9:42 PM, James Hawkins <truiken(a)gmail.com> wrote: > I'm not either. There's a very simple way to implement this. Also, > you need to add tests for the FO_MOVE action as well. Do tell, sir. None of the other operations actually succeed when the destination is an empty list (except delete of course). I can add tests for them to ensure they don't crash, but it seems unnecessary. > @@ -131,6 +132,7 @@ static void clean_after_shfo_tests(void) > DeleteFileA("test3.txt"); > DeleteFileA("test_5.txt"); > DeleteFileA("one.txt"); > + DeleteFileA("filename.tex"); > DeleteFileA("test4.txt\\test1.txt"); > DeleteFileA("test4.txt\\test2.txt"); > DeleteFileA("test4.txt\\test3.txt"); > > typo, and why didn't you stick with the convention used for all the > other test files (.txt, not .text)? This was intentional. It was to show that extensions are trimmed to three characters in this case. -- Vincent Povirk -- Vincent Povirk

2 3

Re: shell32: fix SHFileOperation copying to an empty file list
by James Hawkins 01 Jun '08

01 Jun '08

On Sat, May 31, 2008 at 8:10 PM, Vincent Povirk <madewokherd+d41d(a)gmail.com> wrote: > On Windows, copying files to an empty file list copies each file to > the working directory, truncating each filename to 8.3 format. See bug > 13394. > > I'm not very happy about the way I implemented this (a special loop > just for the weird case), but it doesn't seem possible to use the > current copy_files loop. This is too different from what the function > does in every other possible situation. > I'm not either. There's a very simple way to implement this. Also, you need to add tests for the FO_MOVE action as well. @@ -131,6 +132,7 @@ static void clean_after_shfo_tests(void) DeleteFileA("test3.txt"); DeleteFileA("test_5.txt"); DeleteFileA("one.txt"); + DeleteFileA("filename.tex"); DeleteFileA("test4.txt\\test1.txt"); DeleteFileA("test4.txt\\test2.txt"); DeleteFileA("test4.txt\\test3.txt"); typo, and why didn't you stick with the convention used for all the other test files (.txt, not .text)? -- James Hawkins

1 0

Re: ddraw: Don't release ddraw if a surface is still using it.
by Michael Karcher 31 May '08

31 May '08

Am Samstag, den 31.05.2008, 12:08 +0200 schrieb Jens Albretsen: The patch looks like it would work as advertised, but the following snippet in the testcase smells fishy: > +static unsigned long getRefcount(IUnknown *iface) > +{ > + IUnknown_AddRef(iface); > + return IUnknown_Release(iface); > +} [...] > + IDirectDraw_Release(lpDD); > + > + ref = getRefcount(lpDD); > + ok(ref == 0, "Got refcount %ld, expected 0\n", ref); > + > + IUnknown_Release(surface); The IDirectDraw_Release seems to be dropping the reference count of the DirectDraw object to zero. This is OK, of course, as you might well drop the last reference. But this might put the DirectDraw object into a state where AddRef crashes, as parts of the object might get destroyed when the reference count drops down to zero. On wine, there is obviously no problem, as wine keeps the DirectDraw object itself alive for longer. On Windows, it is not clear to me that the DirectDraw object is not destroyed at the IDirectDraw_Release, the only thing we know is, that Direct Draw still is working (perhaps implemented by a subobject of the DirectDraw object which keeps living). I suggest to alternatively write the second part as + ref = IDirectDraw_Release(lpDD); + ok(ref == 0, "Got refcount %ld, expected 0\n", ref); + + IUnknown_Release(surface); Regards, Michael Karcher

3 3

MinGW RPM packages - discontinued
by Hans Leidekker 31 May '08

31 May '08

Hi all, This is a message for those who used or contributed to the cross compiler packages available from this URL: http://mirzam.it.vu.nl/mingw/ Quoting myself from that page: I have decided to stop maintaining these packages. The original incentive to create these packages was to be able to build Wine's test suite as PE executables on Fedora. Wine recently changed its build system to use Wine's own headers and import libraries when cross compiling the test suite, which means that the mingw-w32api package (where most of the action was) is no longer needed. Another reason is that I'm moving towards Ubuntu as my main development platform. -Hans

3 3

Re: #1 wininet: Make resolving hostnames thread-safe. try2
by Rob Shearman 31 May '08

31 May '08

2008/5/31 Hans Leidekker <hans(a)it.vu.nl>: > Make resolving hostnames thread-safe. > > +/* critical section to protect non-reentrant gethostbyname() */ > +CRITICAL_SECTION cs_gethostbyname; > +static CRITICAL_SECTION_DEBUG critsect_debug = > +{ > + 0, 0, &cs_gethostbyname, > + { &critsect_debug.ProcessLocksList, &critsect_debug.ProcessLocksList }, > + 0, 0, { (DWORD_PTR)(__FILE__ ": cs_gethostbyname") } > +}; > +CRITICAL_SECTION cs_gethostbyname = { &critsect_debug, -1, 0, 0, 0, 0 }; cs_gethostbyname should be static. -- Rob Shearman

1 0

Re: Fix debug log incosistencies and function naming
by Vitaliy Margolen 31 May '08

31 May '08

Michael Karcher wrote: > Debugging DirectDraw reference counting is confusing, > as the IDirectDraw{,2,3,4}_AddRef methods dump to ddraw_thunk, > whereas the matching Release methods dump to ddraw. This > patch changes to consistently use the ddraw channel. > > Furthermore, as the methods from IDirectDraw7 are named > like "IDirectDrawImpl_Foo", the functions from IDirectDraw > (Direct Draw 1) get renamed to "IDirectDraw1Impl_Foo" to > avoid non-unique function names in trace logs. > --- Please make it two patches. One to change debug channel. Second to rename IDirectDrawImpl into IDirectDraw1Impl. Vitaliy.

1 0

Re: winex11.drv: Place tablet cursors in slots based on type
by James Hawkins 31 May '08

31 May '08

On Sat, May 31, 2008 at 12:19 PM, John Klehm <xixsimplicityxix(a)gmail.com> wrote: > This patch looks bigger than it really is. A more detailed changelog is this: > No, it's as big as it seems. > - I've added a lot of comments describing how cursor slotting works. > - added code to slot the cursor appropriately from the get go > - use local memory to temporarily store cursor info before slotting it > (this change results in a lot of inserts deletes of '->' to '.' ) > - iterate through cursors with CURSORMAX and ACTIVE instead of gNumCursors > - cursors will always have a type now: PEN, ERASER, or OTHER > - removed cursor slot fixup code. no longer needed > - removed counters used to place the cursor in slot. no longer needed > Each one of those items should be a separate patch. -- James Hawkins

1 0

Re: dxdiagn: PhysicalMemory parameter is a string not long long
by Vitaliy Margolen 31 May '08

31 May '08

Vitaliy Margolen wrote: > --- > dlls/dxdiagn/provider.c | 7 ++++--- > 1 files changed, 4 insertions(+), 3 deletions(-) > Was anything wrong with this patch? I've used a simple utility DxDiagOutput.exe from DXSDK to find and test this. Vitaliy.

2 4

Re: [PATCH] WM_IME_SETCONTEXT is sent when a window is activated
by Vitaliy Margolen 31 May '08

31 May '08

Christopher GAUTIER wrote: > Changelog: > * dll/user32/defwnd.c: > WM_IME_SETCONTEXT is sent when a window is activated > > Description: > The WM_IME_SETCONTEXT message should be sent when a window is (de)activated > (source: http://msdn.microsoft.com/en-us/library/ms776117(VS.85).aspx) > The value for lParam was obtained by spying on the messages when > activating and deactivating the window. > Please add a test for this to user32/test/msg.c test Vitaliy.

1 0

wine site: Translate sendind_patches to Spanish in web.site.git
by Ángel Guzmán Maeso 30 May '08

30 May '08

My patch needs commit. Changelog: Add translation Spanish to sending_patches in Wine site http://www.winehq.org/pipermail/wine-patches/2008-May/055157.html <http://www.apogeus.es>

4 14

Wine 1.0-rc3 build fails
by John Voltz 30 May '08

30 May '08

Hi, I just tried building rc3 on Fedora 9, and it fails with this: make[2]: Entering directory `/home/john.voltz/workspace/wine/dlls/user32/tests' gcc -c -I. -I. -I../../../include -I../../../include -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wtype-limits -Wpointer-arith -g -O2 -o broadcast.o broadcast.c gcc -c -I. -I. -I../../../include -I../../../include -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wtype-limits -Wpointer-arith -g -O2 -o class.o class.c gcc -c -I. -I. -I../../../include -I../../../include -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wtype-limits -Wpointer-arith -g -O2 -o clipboard.o clipboard.c gcc -c -I. -I. -I../../../include -I../../../include -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wtype-limits -Wpointer-arith -g -O2 -o combo.o combo.c gcc -c -I. -I. -I../../../include -I../../../include -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wtype-limits -Wpointer-arith -g -O2 -o cursoricon.o cursoricon.c gcc -c -I. -I. -I../../../include -I../../../include -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wtype-limits -Wpointer-arith -g -O2 -o dce.o dce.c gcc -c -I. -I. -I../../../include -I../../../include -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wtype-limits -Wpointer-arith -g -O2 -o dde.o dde.c gcc -c -I. -I. -I../../../include -I../../../include -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wtype-limits -Wpointer-arith -g -O2 -o dialog.o dialog.c gcc -c -I. -I. -I../../../include -I../../../include -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wtype-limits -Wpointer-arith -g -O2 -o edit.o edit.c gcc -c -I. -I. -I../../../include -I../../../include -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wtype-limits -Wpointer-arith -g -O2 -o generated.o generated.c gcc -c -I. -I. -I../../../include -I../../../include -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wtype-limits -Wpointer-arith -g -O2 -o input.o input.c gcc -c -I. -I. -I../../../include -I../../../include -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wtype-limits -Wpointer-arith -g -O2 -o listbox.o listbox.c gcc -c -I. -I. -I../../../include -I../../../include -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wtype-limits -Wpointer-arith -g -O2 -o menu.o menu.c {standard input}: Assembler messages: {standard input}:7412: Warning: end of file not at end of a line; newline inserted {standard input}:7745: Error: unknown pseudo-op: `.l' gcc: Internal error: Segmentation fault (program cc1) Please submit a full bug report. See <http://bugzilla.redhat.com/bugzilla> for instructions. make[2]: *** [menu.o] Error 1 make[2]: Leaving directory `/home/john.voltz/workspace/wine/dlls/user32/tests' make[1]: *** [user32/tests] Error 2 make[1]: Leaving directory `/home/john.voltz/workspace/wine/dlls' make: *** [dlls] Error 2

2 1

Ubuntu Popularity Contest - 37% Wine install base, 10% who use, and 7% who use regularly
by Scott Ritchie 30 May '08

30 May '08

The Ubuntu "popcon" package is installed when a user opts to share anonymous usage data during the install process (or within the synaptic package manager). Analyzing the data (http://popcon.ubuntu.com/), we can see the following for Wine: wine 215262 installed 41731 use regularly 156710 don't use compare this with dpkg, which every Ubuntu system has: dpkg 576989 installed 151098 use regularly 411213 don't use Doing some division, this means that a rather high 37% of Ubuntu users have Wine installed, and 10% of all Ubuntu users actually make use of Wine. 7% use Wine "frequently", however popcon defines that. Combine this with other estimates of Ubuntu's user base (about 8 million last I heard), and you have approximately 800,000 Wine users. This data is slightly biased - it doesn't include most Wubi users who installed Ubuntu from within Windows, since they aren't given any installation questions. I believe, though can't prove, that this means we are under-representing Wine users, as it seems reasonable that Wubi installs would be more likely to have Windows applications to run and thus need Wine. Thanks, Scott Ritchie

3 3

README: Few more updates
by Austin English 30 May '08

30 May '08

Anything wrong with this patch? http://www.winehq.org/pipermail/wine-patches/2008-May/055215.html

2 2

Double free in direct sound capture
by Michael Karcher 30 May '08

30 May '08

Hello developers I was running the testcases with warn+heap, and noted some warnings from dsound:capture. They are caused by double free calls, and only happen with winealsa.drv, not with wineoss.drv. The following patch happens to makes the messages disappear. Could somebody with some knowledge about wine's DirectSound implementation please look into this issue and find a proper fix? Regards, Michael Karcher

2 2

Re: mscms/tests: The presence of an ICM file in the color directory has nothing to do with the presence of a registered RGB profile.
by Paul Vriens 30 May '08

30 May '08

Francois Gouget wrote: > --- > > The tests were failing on my Windows systems because they have ICM files > in the color directory but they are not registered, i.e. they don't > even have the HKLM\Software\Microsoft\Windows > NT\CurrentVersion\ICM\RegisteredProfiles key. > > What matters for GetStandardColorSpaceProfile() is that that the > relevant value is set in HKLM\Software\Microsoft\Windows > NT\CurrentVersion\ICM\RegisteredProfiles. It may also check the presence > of the file but the presence of an 'srgb*.icm' file in the color > directory is by no means sufficient. > > > dlls/mscms/tests/profile.c | 33 ++++++++++++++++++++++----------- > 1 files changed, 22 insertions(+), 11 deletions(-) > > > ------------------------------------------------------------------------ > > This addition to the tests checks for a registry entry: + if (strcmp(szName, "RGB") == 0) + *has_space_rgb = TRUE; I see several systems (test.winehq.org) including some of mine that have "RGB " (extra space at the end). It seems that the logic that was added for has_space_rgb is also valid for "RGB ". Any idea? -- Cheers, Paul.

1 0

Re: msxml3: Fix crashes on win98
by Paul Vriens 30 May '08

30 May '08

Alistair Leslie-Hughes wrote: > Hi, > > Changelog: > msxml3: Fix crashes on win98 > > Best Regards > Alistair Leslie-Hughes > > > ------------------------------------------------------------------------ > > Just a question. Why not use a goto to a cleanup session instead of having these huge indented blocks? Or is goto a bad thing by default? (I have the same 'issue' with the setupapi/devinst tests. All the tests in there have these big sets of indented code. In this setupapi case a simple return on failure would have been enough probably) -- Cheers, Paul.

2 1

Search for leftovers after running winetest
by Paul Vriens 30 May '08

30 May '08

Hi, (Sorry, first one went to the wrong list) I just had a look at some of the stuff that's still around after running winetest a few months now on my W2K3 box (some of the regkeys are linked of course): Registry ======== HKEY_CLASSES_ROOT\Applications\shell32_test.exe HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Applications\shell32_test.exe HKEY_CLASSES_ROOT\TypeLib\{D96D8A3E-78B6-4C8D-8F27-059DB959BE8A} HKEY_LOCAL_MACHINE\SOFTWARE\Classes\TypeLib\{D96D8A3E-78B6-4C8D-8F27-059DB959BE8A} (includes a reference to oleaut32_test.exe) HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.shlexec\OpenWithList (reference to shell32_test.exe) HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug (contains 'Debugger' which points to kernel32_test.exe) HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\StillImage\Debug\mscms_test.exe HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\BOGUS HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum\USB\BOGUS HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Enum\USB\BOGUS HKEY_CURRENT_USER\Software\Wine HKEY_LOCAL_MACHINE\SOFTWARE\Wine\msitest Filesystem ========== C:\Config.Msi C:\Documents and Settings\testuser (basically a testuser for each winetest run on xp+ systems) (Any maybe more) I'm wondering how this effects tests? Any ideas? Do other see the same leftovers? I also think we should remove all leftovers after the tests if possible. Nice janitorial task or important enough to be tackled quicker? -- Cheers, Paul.

2 3

Recent change causes registry creation to fail
by Benjamin M. Schwartz 30 May '08

30 May '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am trying to write a scripted wine installation in a nonstandard directory. As part of this procedure, I set $WINEPREFIX and then run wineprefixcreate. This worked perfectly in 0.9.59, but in 0.9.60+ it fails with wineserver: chdir to config dir : Not a directory wine: for some mysterious reason, the wine server failed to run "regedit" fails with the same error. Wine does run, but its registry appears to be screwy. For example, the DOS environment variables like %PROGRAMFILES% and %PATH% are not set at all. I have traced the error to a change made by Alexandre Julliard to registry.c in mid-April [1]. Why might that change have this effect? What should I do to avoid this problem? Thank you, Ben Schwartz OLPC volunteer [1] http://source.winehq.org/git/wine.git/?a=blobdiff;f=server/registry.c;h=d2c… -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkg/g8wACgkQUJT6e6HFtqTgdwCeM7S/HVIS8LU82qVQ5R3cs0Yt HGAAn3cQhdG4VR5H/2jbIbU7SS/uDRX4 =5Bd7 -----END PGP SIGNATURE-----

1 0

Re: advpack: don't close a handle if it wasn't opened
by James Hawkins 30 May '08

30 May '08

On Thu, May 29, 2008 at 10:34 PM, Dan Kegel <dank(a)kegel.com> wrote: > Avoids referencing an undefined variable. > The right way to fix this is to set subkey to NULL in the beginning. -- James Hawkins

1 0

Currently Git doesn't build on Linux x86_64
by Erik de Castro Lopo 29 May '08

29 May '08

Hi all, I've just pulled from git and the latest change I have is this one: commit 4c928d39ad82e576113a34bfa4d27dd0b3eaba17 Author: James Hawkins <jhawkins(a)codeweavers.com> Date: Wed May 28 19:15:15 2008 -0500 oleaut32: Disable olefont tests that fail on all platforms. When I ./configure it I get: checking for freetype-config... freetype-config checking for -lfreetype... not found configure: error: FreeType development files not found. Fonts will not be built. Dialog text may be invisible or unaligned. Use the --without-freetype option if you really want this. This is an Ubuntu Hardy system and I do have freetype installed: > dpkg -L libfreetype6-dev | grep libfreetype.so /usr/lib/libfreetype.so Is anyone else seeing this? Cheers, Erik -- ----------------------------------------------------------------- Erik de Castro Lopo ----------------------------------------------------------------- "Men who use terrorism as a means to power, rule by terror once they are in power." -- Helen Macinnes

3 2

Re: implemented first testcase for dxdiagn
by Vitaliy Margolen 29 May '08

29 May '08

Markus wrote: > > ------------------------------------------------------------------------ > > > + hr = IDxDiagContainer_GetNumberOfProps(pAdapterContainer, &dwPropCount); > + ok(dwPropCount == 72, "Incorrect number of properties in display adapter container. " > + "Found (%d) should be (%d).\n", dwPropCount, 72); I don't think you can relay on that being true all the time. Besides what's the point in testing the number of properties? As a general note - if you add a test that currently fails on Wine it needs todo_wine at front of it. Vitaliy.

1 0

Re: ntdll: Strengthen current tests and add new tests for asynchronous I/O.
by Zac Brown 29 May '08

29 May '08

Woops, ignore this patch. Its got a couple things wrong with it. I'll send a fix later on. -Zac Zac Brown wrote: > Strengthen current tests and add new tests for asynchronous I/O. Missing > test for empty messages as well as thoroughly testing input and output > of read/write commands. > > -Zac Brown > > > ------------------------------------------------------------------------ > > From d2a3cbaf6d71c3b0bcfa39afcf854de7e5daa5bb Mon Sep 17 00:00:00 2001 > From: Zac Brown <zac(a)zacbrown.org> > Date: Thu, 29 May 2008 13:34:50 -0700 > Subject: [PATCH] Strengthen current tests and add new tests for asynchronous I/O. > > --- > dlls/ntdll/tests/file.c | 103 ++++++++++++++++++++++++++++++++++++----------- > 1 files changed, 79 insertions(+), 24 deletions(-) > > diff --git a/dlls/ntdll/tests/file.c b/dlls/ntdll/tests/file.c > index d824530..e3cbf77 100644 > --- a/dlls/ntdll/tests/file.c > +++ b/dlls/ntdll/tests/file.c > @@ -2,6 +2,7 @@ > * > * Copyright 2007 Jeff Latimer > * Copyright 2007 Andrey Turkin > + * Copyright 2008 Google (Zac Brown) > * > * This library is free software; you can redistribute it and/or > * modify it under the terms of the GNU Lesser General Public > @@ -65,6 +66,7 @@ static inline BOOL is_signaled( HANDLE obj ) > } > > #define PIPENAME "\\\\.\\pipe\\ntdll_tests_file.c" > +#define TEST_BUF_LEN 10 > > static BOOL create_pipe( HANDLE *read, HANDLE *write, ULONG flags, ULONG size ) > { > @@ -114,7 +116,10 @@ static BOOL get_msg(HANDLE h) > { > LARGE_INTEGER timeout = {{-10000000*3}}; > DWORD res = pNtRemoveIoCompletion( h, &completionKey, &completionValue, &ioSb, &timeout); > - ok( res == STATUS_SUCCESS, "NtRemoveIoCompletion failed: %x\n", res ); > + if (res == STATUS_TIMEOUT) > + ok( res == STATUS_TIMEOUT, "NtRemoveIoCompletion should have timed out, got: %x\n", res ); > + else > + ok( res == STATUS_SUCCESS, "NtRemoveIoCompletion failed: %x\n", res ); > if (res != STATUS_SUCCESS) > { > completionKey = completionValue = 0; > @@ -507,6 +512,7 @@ static void test_iocp_fileio(HANDLE h) > FILE_COMPLETION_INFORMATION fci = {h, CKEY_SECOND}; > HANDLE hPipeSrv, hPipeClt; > NTSTATUS res; > + BOOL rw_res; > > hPipeSrv = CreateNamedPipeA( pipe_name, PIPE_ACCESS_INBOUND, PIPE_TYPE_MESSAGE | PIPE_READMODE_MESSAGE | PIPE_WAIT, 4, 1024, 1024, 1000, NULL ); > ok( hPipeSrv != INVALID_HANDLE_VALUE, "Cannot create named pipe\n" ); > @@ -533,49 +539,97 @@ static void test_iocp_fileio(HANDLE h) > if (hPipeClt != INVALID_HANDLE_VALUE) > { > OVERLAPPED o = {0,}; > - BYTE buf[3]; > + BYTE buf_send[TEST_BUF_LEN]; > + BYTE buf_rcv[TEST_BUF_LEN]; > DWORD read; > long count; > + unsigned int i; > > NTSTATUS res = pNtSetInformationFile( hPipeSrv, &iosb, &fci, sizeof(fci), FileCompletionInformation ); > ok( res == STATUS_SUCCESS, "NtSetInformationFile failed: %x\n", res ); > ok( U(iosb).Status == STATUS_SUCCESS, "iosb.Status invalid: %x\n", U(iosb).Status ); > > - count = get_pending_msgs(h); > - ok( !count, "Unexpected msg count: %ld\n", count ); > - ReadFile( hPipeSrv, buf, 3, &read, &o); > - count = get_pending_msgs(h); > - ok( !count, "Unexpected msg count: %ld\n", count ); > - WriteFile( hPipeClt, buf, 3, &read, NULL ); > - > - if (get_msg(h)) > + /* Try messages of differing lengths and values, checking that they match. */ > + for( i = 1; i < 10; i++ ) > { > - ok( completionKey == CKEY_SECOND, "Invalid completion key: %lx\n", completionKey ); > - ok( ioSb.Information == 3, "Invalid ioSb.Information: %ld\n", ioSb.Information ); > - ok( U(ioSb).Status == STATUS_SUCCESS, "Invalid ioSb.Status: %x\n", U(ioSb).Status); > - ok( completionValue == (ULONG_PTR)&o, "Invalid completion value: %lx\n", completionValue ); > + memset( buf_send, 0, TEST_BUF_LEN ); > + memset( buf_rcv, 0, TEST_BUF_LEN ); > + memset( buf_send, i, i ); > + > + /* Try reading before writing */ > + count = get_pending_msgs(h); > + ok( !count, "Unexpected msg count: %ld\n", count ); > + rw_res = ReadFile( hPipeSrv, buf_rcv, i, &read, &o ); > + ok( rw_res == FALSE, "Unexpected success of ReadFile\n" ); > + ok( GetLastError() == ERROR_IO_PENDING, "Expected error of ERROR_IO_PENDING, got %d\n", GetLastError() ); > + count = get_pending_msgs(h); > + ok( !count, "Unexpected msg count: %ld\n", count ); > + rw_res = WriteFile( hPipeClt, buf_send, i, &read, NULL ); > + ok( rw_res == TRUE, "Unexpected fail of WriteFile\n" ); > + if (get_msg(h)) > + { > + ok( completionKey == CKEY_SECOND, "Invalid completion key: %lx\n", completionKey ); > + ok( ioSb.Information == i, "Invalid ioSb.Information: %ld\n", ioSb.Information ); > + ok( U(ioSb).Status == STATUS_SUCCESS, "Invalid ioSb.Status: %x\n", U(ioSb).Status); > + ok( completionValue == (ULONG_PTR)&o, "Invalid completion value: %lx\n", completionValue ); > + ok( !memcmp( buf_send, buf_rcv, TEST_BUF_LEN ), "Receive buffer (%x %x %x) did not match send buffer (%x %x %x)\n", > + buf_rcv[0], buf_rcv[1], buf_rcv[2], buf_send[0], buf_send[1], buf_send[2] ); > + } > + count = get_pending_msgs(h); > + ok( !count, "Unexpected msg count: %ld\n", count ); > + > + /* Try writing before reading */ > + rw_res = WriteFile( hPipeClt, buf_send, i, &read, NULL ); > + ok( rw_res == TRUE, "Unexpected fail of WriteFile\n" ); > + count = get_pending_msgs(h); > + ok( !count, "Unexpected msg count: %ld\n", count ); > + rw_res = ReadFile( hPipeSrv, buf_rcv, i, &read, &o ); > + ok( rw_res == TRUE, "Unexpected fail of ReadFile\n" ); > + if (get_msg(h)) > + { > + ok( completionKey == CKEY_SECOND, "Invalid completion key: %lx\n", completionKey ); > + ok( ioSb.Information == i, "Invalid ioSb.Information: %ld\n", ioSb.Information ); > + ok( U(ioSb).Status == STATUS_SUCCESS, "Invalid ioSb.Status: %x\n", U(ioSb).Status); > + ok( completionValue == (ULONG_PTR)&o, "Invalid completion value: %lx\n", completionValue ); > + ok( !memcmp( buf_send, buf_rcv, TEST_BUF_LEN ), "Receive buffer (%x %x %x) did not match send buffer (%x %x %x)\n", > + buf_rcv[0], buf_rcv[1], buf_rcv[2], buf_send[0], buf_send[1], buf_send[2] ); > + } > + count = get_pending_msgs(h); > + ok( !count, "Unexpected msg count: %ld\n", count ); > } > - count = get_pending_msgs(h); > - ok( !count, "Unexpected msg count: %ld\n", count ); > > - WriteFile( hPipeClt, buf, 2, &read, NULL ); > + /* Try sending a message of length zero. */ > count = get_pending_msgs(h); > ok( !count, "Unexpected msg count: %ld\n", count ); > - ReadFile( hPipeSrv, buf, 2, &read, &o); > + rw_res = WriteFile( hPipeClt, buf_send, 0, &read, NULL ); > + ok( rw_res == TRUE, "Unexpected fail of WriteFile\n" ); > count = get_pending_msgs(h); > - ok( count == 1, "Unexpected msg count: %ld\n", count ); > + ok( !count, "Unexpected msg count: %ld\n", count ); > + rw_res = ReadFile( hPipeSrv, buf_rcv, TEST_BUF_LEN, &read, &o ); > + /* This passes on XP but not in wine. */ > + todo_wine ok( rw_res == TRUE, "Unexpected fail of ReadFile\n" ); > if (get_msg(h)) > { > ok( completionKey == CKEY_SECOND, "Invalid completion key: %lx\n", completionKey ); > - ok( ioSb.Information == 2, "Invalid ioSb.Information: %ld\n", ioSb.Information ); > + ok( ioSb.Information == 0, "Invalid ioSb.Information: %ld\n", ioSb.Information ); > ok( U(ioSb).Status == STATUS_SUCCESS, "Invalid ioSb.Status: %x\n", U(ioSb).Status); > ok( completionValue == (ULONG_PTR)&o, "Invalid completion value: %lx\n", completionValue ); > } > + count = get_pending_msgs(h); > + ok( !count, "Unexpected msg count: %ld\n", count ); > > - ReadFile( hPipeSrv, buf, sizeof(buf), &read, &o); > - CloseHandle( hPipeSrv ); > + rw_res = ReadFile( hPipeSrv, buf_rcv, TEST_BUF_LEN, &read, &o); > + ok( rw_res == FALSE, "Unexpected success of ReadFile\n" ); > + ok( GetLastError() == ERROR_IO_PENDING, "Expected error of ERROR_IO_PENDING, got %d\n", GetLastError() ); > + rw_res = CloseHandle( hPipeSrv ); > + ok( rw_res == TRUE, "Unexpected fail of CloseHandle\n" ); > count = get_pending_msgs(h); > - ok( count == 1, "Unexpected msg count: %ld\n", count ); > + /* > + * Wine reports 1 extra message. This is probably due to the server > + * reporting that a message is in the queue from sending an empty message above. > + * The offending code is suspected to be in ntdll/file.c in the NtReadFile function. > + */ > + todo_wine ok( count == 1, "Unexpected msg count: %ld\n", count ); > if (get_msg(h)) > { > ok( completionKey == CKEY_SECOND, "Invalid completion key: %lx\n", completionKey ); > @@ -586,7 +640,8 @@ static void test_iocp_fileio(HANDLE h) > } > } > > - CloseHandle( hPipeClt ); > + rw_res = CloseHandle( hPipeClt ); > + ok( rw_res == TRUE, "Unexpected fail of CloseHandle\n" ); > } > > static void test_iocompletion(void) > > > ------------------------------------------------------------------------ > >

1 0

uninformed musings on ddraw + bugs 2082 and 1347 + dib engine
by Vincent Povirk 29 May '08

29 May '08

I apologize if what I'm about to say is wrong and useless. I feel the need to say it just in case it is not as wrong and useless as I fear. Background: We have two very difficult (possibly unfixable) ddraw bugs: http://bugs.winehq.org/show_bug.cgi?id=2082 - DirectDraw games only showing black screen http://bugs.winehq.org/show_bug.cgi?id=1347 - Screen is wiped/blanked on usage of DirectDraw Both of these bugs are the result of the fact that Windows (probably even Windows Vista when Aero is disabled, which I believe happens temporarily when an exclusive move ddraw app is active) ddraw can give apps direct access to the screen and X cannot. Instead of drawing to the screen, Wine draws to the application's window, which it determines based on an argument the application passed to SetCooperativeLevel. In the case of 2082, this window is obscured and no drawing happens even though it would on windows. There is a hack for ddraw that uses hwnd 0 instead (so drawing operations do go to the screen), but it can also break things in situations where an application uses both ddraw and gdi. 1347 is the result of non-fullscreen applications passing hwnd 0 to SetCooperativeLevel and (so I'm told) going through this series of steps: 1. Lock the primary surface, thus mapping the image on the screen to memory. 2. Write to your window. 3. Unlock the primary surface. On Windows, as long as Aero isn't running, this works out fine. But on Wine, mapping the image on the screen to memory is impossible. Instead, Wine simply gives the app an empty buffer, which the app writes to (but only its own window). It is impossible to determine afterwards which parts of the that buffer were written. When the primary surface is unlocked, Wine draws the image in the buffer to the application's SCL window, which is often (but not always) what the application happened to be drawing. Stefan mentions the idea of grabbing a screenshot when the surface is locked and writing it back when the surface is unlocked (which he says in one case would cause framerate to drop to less than 1 fps, which I believe). He thinks 1347 is unfixable. I think that if so, 2082 is also unfixable because even in fullscreen mode we can have problems caused by interactions with ddraw and gdi (using hwnd 0 is not always the right thing even for a fullscreen app). Now, here's where we get to the crazy uninformed ideas: What if, instead of picking one hwnd to draw to, ddraw drew to every window owned by an application? I'm making some assumptions here: it has to be possible to find the space occupied by "every window owned by an application" and draw to it at a reasonable speed. I'm also assuming that no app we want to support will want to draw to windows owned by other programs, especially X programs, even though there's nothing in ddraw that would prevent it. Well, we'd still theoretically have some problems. What if a program locked/unlocked the primary surface multiple times, once for each of various widgets that it wants to draw? The widgets would flicker. And what if a program has its own window that it wants to draw to with gdi? Its gdi parts would be painted black. Alright then, what if we had a single clientside buffer per app, the size and depth (as far as the app is concerned) of the screen, that was not synced with the actual contents of the screen but was preserved between locks/unlocks? Any operation in ddraw or gdi that resulted in a draw to the screen would have to first go through this buffer. The lock/unlock sequence would overdraw all the application's windows with the last thing the application drew there. Ignoring opengl (opengl and ddraw working simultaneously in one process should be extremely rare; maybe some swing apps do it), that should work pretty much perfectly. Sadly I can't even pretend to know enough to say how this affects opengl. It would require clientside buffers, and it would probably be difficult for current gdi to support. It seems like the sort of thing that would be more reasonable if we had a dib engine. (!) Also, giving every process a clientside buffer the size of the screen would be wasteful of memory (and optimizing for a rare case; most programs won't even have a primary surface, let along be locking/unlocking it). It may be more reasonable to have one per visible window or even one per X window, which would be manipulated as needed for lock/unlock (not sure about the X window thing because they'd have to be shared between processes.. but perhaps we need that capability anyway? it would also effectively mean we CAN give apps direct access to the screen for virtual desktops and CAN allow ddraw drawing to other Wine processes' windows). -- Vincent Povirk

6 8

winetest issue on w2k and below
by Paul Vriens 29 May '08

29 May '08

Hi, Lately I've been seeing an issue with winetest on Windows whereby the kernel32_test.exe file can't be deleted after the test. On NT4 I've also seen popups during the test with some remark about not being able to initialize user32.dll. This is when the process test is run for kernel32. Anyone else seeing this? Or better yet, anyone know the cause? -- Cheers, Paul.

2 2

Re: advpack: Fix buffer sizes for possibly quoted strings (try 2, including testcase)
by James Hawkins 29 May '08

29 May '08

On Thu, May 29, 2008 at 9:20 AM, Michael Karcher <wine(a)mkarcher.dialup.fu-berlin.de> wrote: > Increase buffer size to make quoted strings fit. This fixes the problem > Dan described in > http://www.winehq.org/pipermail/wine-devel/2008-May/065954.html which > is caused by quoted 'HKLM' not fitting into prefix. This patch does, on > request, *not* fix the bigger picture issue that made it possible for > this bug to slip for such a long time, which is missing error checking > on SetupGetStringFieldW calls in get_dest_dir. Valid .inf files should, > of course, not exercise the missing error check, so on valid .inf > files, this patch is sufficient for correct behaviour. > > In the testcase with quoted 'HKLM', SetupGetStringFieldW fails because > of unsufficient buffer size, which is *ignore* by the current code. As > from the previous destination parsed in the patch the local automatic > variable still contains the unquoted HKLM and by luck does not get > overwritten between invocations of get_dest_dir, the testcase passes > nevertheless except if compiled by gutsy's gcc 4.1 without optimization > which puts the local variable to a stack location that does not survive > between different invocations of get_dest_dir. > > The attached change to the testcase "pollutes" the local variable prefix > with HKCU, so the bug is always exposed and not just by bad luck. > --- > dlls/advpack/advpack.c | 10 +++++----- > 1 files changed, 5 insertions(+), 5 deletions(-) > You must've attached the wrong patch because there is no test case. Also, don't make a change to the existing tests. Please write a completely new test that exposes just the one bug you're trying to fix. They're called 'unit' tests for a reason. -- James Hawkins

1 0

Re: advpack: Fix buffer sizes for possibly quoted strings
by James Hawkins 29 May '08

29 May '08

On Thu, May 29, 2008 at 8:58 AM, Michael Karcher <wine(a)mkarcher.dialup.fu-berlin.de> wrote: > Increase buffer size to make quoted strings fit. This fixes the problem > Dan described in > http://www.winehq.org/pipermail/wine-devel/2008-May/065954.html which > is caused by quoted 'HKLM' not fitting into prefix. This patch does, on > request, *not* fix the bigger picture issue that made it possible for > this bug to slip for such a long time, which is missing error checking > on SetupGetStringFieldW calls in get_dest_dir. Valid .inf files should, > of course, not exercise the missing error check, so on valid .inf > files, this patch is sufficient for correct behaviour. > > In the testcase with quoted 'HKLM', SetupGetStringFieldW fails because > of unsufficient buffer size, which is *ignore* by the current code. As > from the previous destination parsed in the patch the local automatic > variable still contains the unquoted HKLM and by luck does not get > overwritten between invocations of get_dest_dir, the testcase passes > nevertheless except if compiled by gutsy's gcc 4.1 without optimization > which puts the local variable to a stack location that does not survive > between different invocations of get_dest_dir. > --- > dlls/advpack/advpack.c | 10 +++++----- > 1 files changed, 5 insertions(+), 5 deletions(-) > Add a test case please. -- James Hawkins

1 0

AppDB: More information about the test environment needed
by Groeschel, Volker 29 May '08

29 May '08

I just found two conflicting reports for Age of empires: http://appdb.winehq.org/objectManager.php?sClass=version&iId=10326 Both are on Ubuntu 8.04 and 1.0-rc1. One is Silver, one is Garbage. But it is just one example. My suggestion is to ask for more information about the test environment. To specify it I think it would be helpfull to know the grafics chip/card and the used driver. With the new free drivers around the block it could be even more helpfull to have this information. The same ATI card e.g. could use Radeon, RadeonHD or the Catalyst driver. The same is true for Nvidia with nvidia, nv and Nouveau driver. I often read that Wine developers recommend nvidia, but I actually have good experience with radeon. It is quite hard to get real informaltion on this topic.

2 1

Re: [1/2] tests: Add functions to make it possible to handle Windows misbehaviors that we don't want to reproduce in Wine.
by Alexandre Julliard 29 May '08

29 May '08

Francois Gouget <fgouget(a)free.fr> writes: > This patch introduces the buggy(), deprecated() and strict_wine > functions I mentioned in: > http://www.winehq.org/pipermail/wine-devel/2008-April/065322.html I like the idea, but I don't think this should copy the todo mechanism, as it doesn't scale well. For todo that's OK because the number of todos is supposed to remain small, and get smaller as Wine improves; but strict checking is something we'll want more and more of, so ultimately we'll have them all over the place. It gets even worse if we want to be strict for other platforms too. So I would suggest to not add a strict(platform), but make buggy() and deprecated() always do strict checking except when platform is "windows". If we need to have a buggy() check succeed on Wine for some reason it can always be wrapped in a todo_wine. -- Alexandre Julliard julliard(a)winehq.org

1 0

2k is the default version?
by Austin English 28 May '08

28 May '08

I was testing installing Virtualbox today and got an error that Windows XP is the minimum requirement. Funny I thought...we're emulating XP, it must want SP 2 or something strange. Fired up winecfg, and lo and behold, Windows 2000 is the default OS again. Thought I might be going crazy or botched my local tree, but checking out on a fresh tree shows the same thing. When/why did this happen? -Austin

4 7

wine video codec demo
by Dan Kegel 28 May '08

28 May '08

I put together a little script demonstrating how to install and use various video codecs and use them in a test application (media player classic). To try it out, do wget http://kegel.com/wine/winetricks wget http://kegel.com/wine/codecdemo sh codecdemo (after of course reading both scripts to make sure they don't do something evil.) To make this demo script easier to write, I added quicktime72 and mpc verbs to winetricks. (I also added a vlc verb, but that wasn't so useful as a system codec test, since vlc has its own embedded codecs, and doesn't use the system's.) The demo shows that Quicktime works more or less, but .wmv doesn't work (even with the codecs); it probably needs either native quartz.dll or Maarten's VMR9 implementation (which he is busily finishing up now; it seems to be good at finding video card driver bugs). Next step: Dirac.

1 1

Re: [ws2_32/tests] Fix crash on win98
by Kai Blin 28 May '08

28 May '08

On Wednesday 28 May 2008 10:08:49 Paul Vriens wrote: > Hi, > > As pi_size was uninitialized the value turned out to be the cause of this > crash. > > I don't know where that limit ( 2*sizeof(WSAPROTOCOL_INFOA) ) comes from > but tests show it has to be less then that on win98. Whoops, thanks for the catch. I had that initialized to 0 at one point in my test program, but it seems like I dropped it while reworking the tests. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

1 0

advpack.c must be compiled with optimization?
by Dan Kegel 28 May '08

28 May '08

Oddly, if I compile the wine tree without -O2, the following test fails: ../../../wine advpack_test.exe.so advpack.c advpack.c:441: Test failed: Expected C:\Program Files, got C:\ advpack.c:443: Test failed: Expected size 17, got 4 make: *** [advpack.ok] Error 2 Compiling advpack/advpack.c with at least -O makes the problem go away.

3 3

Why I think it's worth fixing Valgrind warnings
by Dan Kegel 28 May '08

28 May '08

If you're wondering whether it's worth fixing Valgrind warnings (after all, they are just warnings, right?): First, some of the valgrind errors that show up when running the test suite might be real bugs. That might be enough reason right there. Second, clearing out the valgrind errors that show up in the test suite make it a lot easier to find Wine bugs when running real apps on wine on valgrind. (The lower the background noise level, the easier it is to see the real problem.) Third, if valgrind works well on wine, windows developers might start coming to Wine just to run Valgrind on their apps to find app bugs. (Don't laugh! It could happen!) This is why I hired John Reiser to improve Valgrind/Wine support, why I've been fixing a few valgrind warnings lately, and why I think it's important for other people to start doing it, too. That said, it's important when fixing Valgrind errors to really understand the code you're changing, lest you paper over a bug with another bug, or make things worse. (Here would be a good place for me to thank James for his code reviews :-) - Dan

4 5

Coaxing appdb maintainers into testing their apps with rc1?
by Dan Kegel 28 May '08

28 May '08

It doesn't look like many people are paying attention to http://wiki.winehq.org/PlatinumRegressionHunt Think it would be useful to email all the app maintainers and ask them to pretty please test their apps with rc1?

4 6

Ooodles of sexy new valgrind warnings
by Dan Kegel 28 May '08

28 May '08

I updated to the latest valgrind from svn, and it gives lots of nifty new warnings. e.g. it warns if you are using the wrong free for a particular memory block, and it tells you where uninitialized blocks came from. http://kegel.com/wine/valgrind/logs-2008-05-25-summary.txt is a roadmap of where the sexy new stuff is; the details are in http://kegel.com/wine/valgrind/logs-2008-05-25/ For instance, it says diff -u logs-2008-05-20/vg-winmm_capture.txt logs-2008-05-25/vg-winmm_capture.txt + Uninitialised value was created by a client request + Mismatched free() / delete / delete [] Pulling up just that diff, http://kegel.com/wine/valgrind/logs-2008-05-25/vg-winmm_capture-diff.txt shows the latter error is + Mismatched free() / delete / delete [] + at RtlFreeHeap (heap.c:1287) + by wave_in_test_device (capture.c:397) + by func_capture (capture.c:716) + by run_test (test.h:414) + by main (test.h:463) + Address 0x440cc90 is 0 bytes inside a block of size 14 alloc'd + at malloc (vg_replace_malloc.c:207) + by wave_in_test_device (capture.c:388) + by func_capture (capture.c:716) + by run_test (test.h:414) + by main (test.h:463) Sure enough, memory is allocate with strdup() and freed with HeapFree(), tsk. Anyway, there's plenty here for everybody. Pile on! Tomorrow I'll start running these without -O2; Zac Brown reminded me that gives better stack tracebacks (i.e. it inhibits inlining, which often causes small static functions to disappear from the stack dumps in valgrind's error messages). - Dan

2 3

Re: mscoree: add implementation of GetCORSystemDirectory
by Vitaliy Margolen 28 May '08

28 May '08

Vitaly Perov wrote: > Changeleg: > - mscoree: add implementation of GetCORSystemDirectory > What bug # does this patch fixes? Please leave all the new implementations to after the wine-1.0 Vitaliy.

1 0

Re: implemented further properties for DXDiagDisplayContainer in dxdiagn dll
by Vitaliy Margolen 28 May '08

28 May '08

Markus wrote: > > ------------------------------------------------------------------------ > > Subject: implemented further properties for DXDiagDisplayContainer in dxdiagn dll Please do not send implementation of new things, especially as dangerous as this. Wine at the code freeze. You should be going over bugs in bugzilla and fixing them. Vitaliy.

1 0

re: shell32: Test against the long form of the path.
by Dan Kegel 27 May '08

27 May '08

This change http://source.winehq.org/git/wine.git/?a=commit;h=f2aa3259b913d75a273296f28… seems to causes a test failure on my wine box, but more importantly, on several windows boxes as well: http://test.winehq.org/data/200805221320/2000_aenglish-2k/shell32:shelllink… http://test.winehq.org/data/200805221320/2003_jh-win2k3-vm/shell32:shelllin… http://test.winehq.org/data/200805221320/xp_om/shell32:shelllink.txt It passes on some systems, go figure: http://test.winehq.org/data/200805221320/xp_maarten-xp/shell32:shelllink.txt James, want to revert this one for now?

3 3

Winetest broken on Win98
by Francois Gouget 27 May '08

27 May '08

So if anyone has been wondering why I don't run the tests on Win98 anymore... I still do! The problem is that since 2008/05/08 something prevents winetest from submitting the results. The 200805062030 winetest build works fine so that leaves a two/three days window where things went wrong. Unfortunately I have been unable to pinpoint a specific test that causes the problem. Here's a log I generated with the 200805211000 build: http://fgouget.free.fr/tmp/winetest.log I let winetest run for 90 minutes (normally it's over in about 15), then Windows was frozen, not responding to Ctrl-Alt-Del, using all the CPU and I had to hit VMware's reset button. The last test that was run is setupapi:parser, but according to the log it completed fine, and I can run it by hand just fine. Still according to the log the next test did not even start. Unfortunately the list of potential suspects is quite long. It would help if I could at least cross-build winetest but I always get errors (e.g. due to d3dx9_36). What happened to the resolution to get rid of the dependency on MinGW libraries? Alternatively, where's the lastest version of w32api with d3dx9_36? commit 382ed33b7a770d532bcf4b7dc392ee929c987c7a Author: Vitaliy Margolen <wine-patches(a)kievinfo.com> Date: Thu May 8 08:11:19 2008 -0600 dinput: Default value for unassigned POVs should be -1. commit b92d1c7fbef30114b3aa7f3197a5df3556c98b12 Author: Paul Vriens <paul.vriens.wine(a)gmail.com> Date: Thu May 8 15:06:53 2008 +0200 crypt32/tests: Cleanup registry after tests. commit 5714c4deee6f3c0cc30098d056fa4ce39a333878 Author: Alexandre Julliard <julliard(a)winehq.org> Date: Thu May 8 11:12:03 2008 +0200 user32: The client rectangle is in screen coordinates for the initial WM_NCCALCSIZE. commit 09cb415109447c4be086f1c756f8a168628457f7 Author: Guy Albertelli <galberte(a)neo.rr.com> Date: Thu May 8 00:46:38 2008 -0400 listview: Return correct value from WM_NOTIFYFORMAT with test. commit 864e24d2e586b796c2069576ca6d8fe4e7b8cef7 Author: Maarten Lankhorst <m.b.lankhorst(a)gmail.com> Date: Wed May 7 16:31:02 2008 -0700 kernel32: Fix temporary path test. commit db8e63af27b75d098db6f9a61a6fb0ab7d70d83f Author: Maarten Lankhorst <m.b.lankhorst(a)gmail.com> Date: Wed May 7 15:44:48 2008 -0700 kernel32: Fix process tests to pass in Windows. commit fd7b277d8ac23706b1c819d2ed1fd0ee9833fd06 Author: Maarten Lankhorst <m.b.lankhorst(a)gmail.com> Date: Tue May 6 15:06:17 2008 -0700 rpcrt4: Fix ndr_marshall test failures. Created with help from Robert Shearman. commit 51c28a1493c844eff4f4625d3398da5ee5d707fd Author: Dmitry Timoshkov <dmitry(a)codeweavers.com> Date: Wed May 7 20:34:36 2008 +0900 gdi32: More carefully compare EMF records in tests. commit 3da466a9f75076f618a5440805cd211a98c7b628 Author: Kai Blin <kai.blin(a)gmail.com> Date: Wed May 7 12:35:06 2008 +0200 secur32: Fix ntlm tests on Vista. commit 02c66c2312d9bf98d0fc0d5d4ce56b8564718026 Author: Rob Shearman <rob(a)codeweavers.com> Date: Wed May 7 11:11:09 2008 +0100 rpcrt4: Add better traces for the server test. Handle failure to use one or more protocol sequences more gracefully, as ncacn_np servers aren't support on Win9x and ncacn_ip_tcp fails on some machines. commit 473717fefd06650e1e8d80c8dc0e16ab583cc673 Author: Detlef Riekenberg <wine.dev(a)web.de> Date: Tue May 6 20:26:05 2008 +0200 winspool: Set PrinterPorts for win3.x/win9.x compatibility. commit 7c051f13941b15bd0a399431e36cae16b8fe092e Author: Maarten Lankhorst <m.b.lankhorst(a)gmail.com> Date: Tue May 6 14:14:56 2008 -0700 winetest: Fix CreateProcess so that debugger tests run without timing out. commit deee97d9eaa7dfe28a9e39f288c3c7ed39f6e7c8 Author: Paul Vriens <paul.vriens.wine(a)gmail.com> Date: Tue May 6 18:08:09 2008 +0200 advapi32/tests: Add another test. commit 6477a1c1bfd7966ff75b6847156a765ec088b0b3 Author: Alexandre Julliard <julliard(a)winehq.org> Date: Tue May 6 15:54:07 2008 +0200 kernel32: Set the USERPROFILE and ALLUSERSPROFILE environment variables based on the ProfileList registry keys. commit c4d75213abe21dcd7697d2f9151a186ebb3f8c8d Author: Alexander Dorofeyev <alexd4(a)inbox.lv> Date: Tue May 6 00:49:34 2008 +0300 ddraw/tests: Add tests for IDirect3DDevice7_Load. I'm ignoring wininet and ntdll changes because they don't run due to missing imports. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ tcA thgirypoC muinelliM latigiD eht detaloiv tsuj evah uoY

6 7

urlmon:protocol test timeouts
by James Hawkins 27 May '08

27 May '08

Hi Jacek, The following patch causes timeouts for all platforms, can you have a look at it? commit 210854edf2e841af675d541d29f2b90cd2625d02 Author: Jacek Caban <jacek(a)codeweavers.com> Date: Thu Jan 31 18:18:49 2008 +0100 urlmon: Added more protocol tests. http://test.winehq.org/data/156dad05c08cd921288aedf1b281ff23844a1692/ Thanks, James Hawkins

1 0

inkscape font rendering: is this bug #4386?
by Marcel Partap 27 May '08

27 May '08

Hi all, as a poppler upgrade just broke my native inkscape and the 1.0 bug hunt is on, i thought i'd quickly try inkscape win32 (latest nightly build) and see if it works.. well stuff seems to look fine - except all glyphs (except from the file dialogs of course) are shown as black filled .. blurps (http://hfopi.org/files/temp/inkscape-font-rendering.png), kinda ;) now looking at the appdb it really surprised my inkscape is not yet in there.. also i am not sure if this font problem is probably something on my side (my x font server is behaving strangly atm: thunderbird has everything typeset with some gothic script?!) or if it corresponds to either bug #6519 or #4386 ? If someone can confirm this I'll add a bug report later today.. regards -- <div id="signature"> "Obstacles are those frightful things you see when you take your eyes off your goal." -- Henry Ford (1863-1947) Change the world! Vote revolution: http://hfopi.org/vote-future </div>

2 1

re: runtest: Add an option to run the tests with valgrind
by Dan Kegel 27 May '08

27 May '08

Maarten wrote: > Usage: make test RUNTEST="$WINE_GIT/tools/runtest -V" VALGRIND_OPTS="..." That seems clumsier offhand than how I've been doing it, RUNTEST_USE_VALGRIND=1 make test

2 1

WOW! Look at test.winehq.org now!
by Dan Kegel 27 May '08

27 May '08

Alexandre did an awesome job of improving the index page. It's very polished and useful now. http://test.winehq.org/data/

6 5

Re: wined3d: Use higher precision to convert floats into text.
by Chris Robinson 27 May '08

27 May '08

On Monday 26 May 2008 12:37:04 pm Vitaliy Margolen wrote: > - shader_addline(buffer, "PARAM srgb_mul_low = {%f, %f, %f, > 1.0};\n", > + shader_addline(buffer, "PARAM srgb_mul_low = {%.12f, > %.12f, %.12f, 1.0};\n", I don't know if ARB shaders would except the notation (GLSL does), but would %.8e or somesuch work better than %.12f at maintaining accuracy?

4 6

listview maintainer review, please...
by Dan Kegel 27 May '08

27 May '08

The curious Valgrind error + Conditional jump or move depends on uninitialised value(s) + at SetWindowPos (winpos.c:2034) + by LISTVIEW_UpdateSize (listview.c:9380) + by LISTVIEW_Size (listview.c:9320) + by LISTVIEW_WindowProc (listview.c:9949) + by (within /home/dank/wine-git/dlls/user32/user32.dll.so) + by call_window_proc (winproc.c:457) + by WINPROC_CallProcAtoW (winproc.c:901) + by CallWindowProcA (winproc.c:2282) + by listview_subclass_proc (listview.c:231) + by (within /home/dank/wine-git/dlls/user32/user32.dll.so) + by call_window_proc (winproc.c:457) + by WINPROC_CallProcWtoA (winproc.c:1267) + by WINPROC_call_window (winproc.c:2200) + by call_window_proc (message.c:1610) + by send_message (message.c:2434) + by SendMessageW (message.c:2557) + by DEFWND_DefWinProc (defwnd.c:746) + by DefWindowProcW (defwnd.c:1037) + by LISTVIEW_WindowProc (listview.c:9994) + by (within /home/dank/wine-git/dlls/user32/user32.dll.so) + Uninitialised value was created by a stack allocation + at LISTVIEW_UpdateSize (listview.c:9351) started happening recently. Looking at LISTVIEW_UpdateSize, it seems clear that if SendMessageW( infoPtr->hwndHeader, HDM_LAYOUT, 0, (LPARAM)&hl ); fails for whatever reason, hl will be undefined, and that's what Valgrind is complaining about. Here's a patch that skips the rest of the function if that line fails; it makes Valgrind happy, and doesn't seem to hurt the conformance tests. Can somebody familiar with the code have a look at that function and explain what's going on here? Thanks! - Dan

2 1

Re: [PATCH] Add Ex critical section initialisers for msvcrt
by Rob Shearman 27 May '08

27 May '08

2008/5/26 Jon Griffiths <jon_p_griffiths(a)yahoo.com>: > The latest msvcrt needs InitializeCriticalSectionEx to load (e.g. > http://forum.utorrent.com/viewtopic.php?id=37243). I don't believe we should be adding new functions during code freeze, especially not totally implemented ones with no corresponding tests. However, I would encourage you to create a bug and to submit the patch when we start thawing. -- 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