October 2007 - Wine-Devel - list.winehq.org

Lots of 'make test' failures on Windows

by Francois Gouget

Looking at yesterday's test results is depressing: http://test.winehq.org/data/200710241000/ Just looking at the pretty colors may not make this very obvious, but the state of the tests is APPALLING. Successes | Failures | Failure rate | Not Run WinXP-1 | 260 | 53 | 17% | 0 WinXP-2 | 252 | 62 | 20% | 0 Win2003-1 | 264 | 49 | 16% | 0 Win2003-2 | 241 | 72 | 23% | 0 Win98 | 113 | 115 | 50% | 45 So depending on the test run and the platform we have a failure rate that is between 16% and over 50%, really 53% as the gdi32 tests should really run on Win98. This is important because if you try to fix Wine to make these tests pass you may actually end up breaking Wine. So until these tests are fixed and pass on Windows they are of no use to us. So yeah, we don't have an http://test.winehq.org/ home page, and http://test.winehq.org/data/ should be made nicer too, but even so I'm hoping a few motivated developers will find their way to the test results and start a push to make things better. Btw, shouldn't it be a Wine 1.0 goal to have our conformance test suite pass cleanly on Windows? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ The software said it requires Win95 or better, so I installed Linux.

Oct. 25, 2007

Re: Start: Convert start to Unicode.

by Anatoly Lyutin

Michael Stefaniuc wrote: > Anatoly Lyutin wrote: > >> Dmitry Timoshkov wrote: >> >>> "Anatoly Lyutin" <vostok(a)etersoft.ru> wrote: >>> >>> >>> The whole Wine tree uses 8 spaces for a tab. >>> >>> >>> >> Hm. I thought that some modules use 4 space symbols instead of 1 tab >> symbol. Sorry if I am wrong. >> > I think you are confusing indentation level with the amount of space a > tab is. > - Indentation level in Wine can be 4 (preferred), 8, 2 or even something > odd like 3. > - A tab is always 8 spaces. > > Yes, Thanks a lot. It is clear for me now. >>> A proper error handling IMO is to return an error to the caller instead >>> of terminating the app. >>> >>> >>> >> Can you give an example? The Start utility already uses ExitProcess() >> if you means this... >> >> > > bye > michael > -- Best regards Anatoly Lyutin.

Oct. 25, 2007

Re: Start: Convert start to Unicode.

by Michael Stefaniuc

Anatoly Lyutin wrote: > Dmitry Timoshkov wrote: >> "Anatoly Lyutin" <vostok(a)etersoft.ru> wrote: >> >> >> The whole Wine tree uses 8 spaces for a tab. >> >> > Hm. I thought that some modules use 4 space symbols instead of 1 tab > symbol. Sorry if I am wrong. I think you are confusing indentation level with the amount of space a tab is. - Indentation level in Wine can be 4 (preferred), 8, 2 or even something odd like 3. - A tab is always 8 spaces. >> A proper error handling IMO is to return an error to the caller instead >> of terminating the app. >> >> > Can you give an example? The Start utility already uses ExitProcess() > if you means this... > bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 -------------------------------------------------------------------- Reg. Adresse: Red Hat GmbH, Hauptstätter Strasse 58, 70178 Stuttgart Handelsregister: Amtsgericht Stuttgart HRB 153243 Geschäftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Werner Knoblich

Oct. 25, 2007

Re: Start: Convert start to Unicode.

by Anatoly Lyutin

Dmitry Timoshkov wrote: > "Anatoly Lyutin" <vostok(a)etersoft.ru> wrote: > > > The whole Wine tree uses 8 spaces for a tab. > > Hm. I thought that some modules use 4 space symbols instead of 1 tab symbol. Sorry if I am wrong. > > A proper error handling IMO is to return an error to the caller instead > of terminating the app. > > Can you give an example? The Start utility already uses ExitProcess() if you means this... -- Best regards Anatoly Lyutin.

Oct. 25, 2007

Re: Start: Convert start to Unicode.

by Dmitry Timoshkov

"Anatoly Lyutin" <vostok(a)etersoft.ru> wrote: >> Once you change your editor settings to use natural 8 spaces for a tab >> you will >> see how ugly the formatting in your new code is. >> > I am sorry. I forgot that in the start.c uses natural 8 spaces for a > tab. Fixed. The whole Wine tree uses 8 spaces for a tab. >>> -static void fatal_error(const char *msg, DWORD error_code) >>> +static void fatal_error(const WCHAR *msg, DWORD error_code) >> >> fatal_error() is not called with strings outside of ASCII charset, so >> there is no much point in converting it to unicode. It only makes your >> patch full of controversial changes. IMHO fatal_error() should be removed >> altogether, and replaced by proper error handling instead. >> > I think that it is the question of time. For example In the future these > messages will be probably deduced in the Korean (or Japanese or etc) > language. > But what proper error handling do you mean?Should I use a FIXME, ERR and > so on? A proper error handling IMO is to return an error to the caller instead of terminating the app. -- Dmitry.

Oct. 25, 2007

Re: Start: Convert start to Unicode.

by Anatoly Lyutin

Dmitry Timoshkov wrote: > "Anatoly Lyutin" <vostok(a)etersoft.ru> wrote: > >> -/** >> +WINE_DEFAULT_DEBUG_CHANNEL(start); >> + >> +/* > > All these changes /** -> /* make the diff larger, and are not really > necessary. I have considered it in the new version. > > >> Output given message to stdout without formatting. >> */ >> -static void output(const char *message) >> +static void output(const WCHAR *message) >> { >> DWORD count; >> - WriteFile(GetStdHandle(STD_OUTPUT_HANDLE), message, >> strlen(message), &count, NULL); >> + DWORD res; >> + int wlen = strlenW(message); > > Once you change your editor settings to use natural 8 spaces for a tab > you will > see how ugly the formatting in your new code is. > I am sorry. I forgot that in the start.c uses natural 8 spaces for a tab. Fixed. >> -static void fatal_error(const char *msg, DWORD error_code) >> +static void fatal_error(const WCHAR *msg, DWORD error_code) > > fatal_error() is not called with strings outside of ASCII charset, so > there is no much point in converting it to unicode. It only makes your > patch full of controversial changes. IMHO fatal_error() should be removed > altogether, and replaced by proper error handling instead. > I think that it is the question of time. For example In the future these messages will be probably deduced in the Korean (or Japanese or etc) language. But what proper error handling do you mean?Should I use a FIXME, ERR and so on? I will resend my patch. -- Best regards Anatoly Lyutin.

Oct. 25, 2007

Re: winmm: fix uninitialized variable that caused near-infinite loop

by Alexandre Julliard

"Dan Kegel" <dank(a)kegel.com> writes: > Without this patch, winmm/tests/mixer.c appears to hang on one of my machines. > > I think the problem was capsA was uninitialized in: > for (d=0;d<capsA.cDestinations;d++) { That's just hiding the bug. If mixerGetDevCapsA failed we shouldn't go on to use the data that it hasn't returned, we should abort the test. -- Alexandre Julliard julliard(a)winehq.org

Oct. 25, 2007

Re: Start: Convert start to Unicode.

by Dmitry Timoshkov

"Anatoly Lyutin" <vostok(a)etersoft.ru> wrote: > -/** > +WINE_DEFAULT_DEBUG_CHANNEL(start); > + > +/* All these changes /** -> /* make the diff larger, and are not really necessary. > Output given message to stdout without formatting. > */ > -static void output(const char *message) > +static void output(const WCHAR *message) > { > DWORD count; > - WriteFile(GetStdHandle(STD_OUTPUT_HANDLE), message, strlen(message), &count, NULL); > + DWORD res; > + int wlen = strlenW(message); Once you change your editor settings to use natural 8 spaces for a tab you will see how ugly the formatting in your new code is. > -static void fatal_error(const char *msg, DWORD error_code) > +static void fatal_error(const WCHAR *msg, DWORD error_code) fatal_error() is not called with strings outside of ASCII charset, so there is no much point in converting it to unicode. It only makes your patch full of controversial changes. IMHO fatal_error() should be removed altogether, and replaced by proper error handling instead. -- Dmitry.

Oct. 25, 2007

Re: shlwapi: Update exported API entries according to theinfopublished by Geoff Chappell

by Alexandre Julliard

"Dmitry Timoshkov" <dmitry(a)codeweavers.com> writes: > That means that if/once apps start to import shlwapi APIs by name they > will not work in Wine. Also, do you mean that APIs for which entries > -noname has been already removed need to be fixed to have -noname again? With -noname the name should still be available in the export table, but not be used for importing. And yes, if -noname has been removed from functions that are exported by ordinal in some versions that's wrong. -- Alexandre Julliard julliard(a)winehq.org

Oct. 25, 2007

Re: shlwapi: Update exported API entries according to the infopublished by Geoff Chappell

by Dmitry Timoshkov

"Robert Shearman" <rob(a)codeweavers.com> wrote: [skipped] > These are all exported by ordinal only up to Windows 2003 SP1 (w/ IE 6.0). Probably. But they are exported by name in Vista, and in some other versions of Windows (have a look at the referenced web page). The point is that once/if applications start to import shlwapi APIs by name they won't work under Wine. > +196 stub -noname SHVerbExistsNA #stdcall @(ptr ptr ptr ptr) dnsapi.DnsRecordSetCompare > > > You need to fix the name of the function in the comment here. I intentionally left a not matching name in the comment in order to force anyone who decides to implement this API to carefully examine both points. -- Dmitry.

Oct. 25, 2007