Re: Wine and multiarch on Debian Testing
2012/11/12 Francois Gouget > On Wed, 17 Oct 2012, Erich E. Hoover wrote: > > > I just upgraded to 12.04, until they fix the "32-bit headers problem" > > you'll have to manually create the symbolic links for the "-dev" > > package behavior: > > I ran into pretty much the same set of problems with Wine on Debian > Testing. However some development packages are already > multiarch-compatible so I installed them and created a bit fewer > symbolic links than you. In particular I was able to install the > following i386 development packages: > >libasound2-dev:i386 >libcapi20-dev:i386 >libjpeg8-dev:i386 >liblcms1-dev:i386 >libldap2-dev:i386 >libmpg123-dev:i386 >libopenal-dev:i386 >libtinfo-dev:i386 (needed for ncurses) >libv4l-dev:i386 >libx11-dev:i386 >libxau-dev:i386 >libxcb1-dev:i386 >libxinerama-dev:i386 >libxml2-dev:i386 >libxrender-dev:i386 >zlib1g-dev:i386 > > > I also made a list of the packages that need to be fixed in order for > work on Wine to be possible without so much complication, and made sure > we have bugs to track the status of each of them. I am sure the > maintainers would appreciate some help so here are the multiarch fixes > needed for Wine development: > > * These all seem to be fixable trivially. Double-check and submit a >patch? The Debian freeze might block your efforts though :-( >libfontconfig1-dev - #677885 >libgl1-mesa-dev - #678040, #689088 >libglu1-mesa-dev - #678040, #689089 >libgnutls-dev - #678070 >libosmesa6-dev - #678040 >libxcomposite-dev - #689082 >libxfixes-dev - #677657 >libxrandr-dev - #678895 >libxvmc1 - #640499 (well the work seems to have been done in any case) >libxxf86vm-dev - #678898 > Hi François, #677885, #678040, #678070, #678895 and #678898 already contains trivial patches, I did check packages on every offered architectures to see if file differs, I can recheck if necessary. I can also check #677657 to see if things has changed since bug report and provide a patch if needed. libgl1-nvidia-glx doesn't depend on libxvmc1 so it should be a problem anymore (at least if you use nvidia packages from unstable). Unfortunately I didn't have much time to spend on not so trivial packages and Debian freeze doesn't really help accepting patches, even if multiarch is a release goal ... -- Nicolas Le Cam
Re: include: fix mingw64 build
2012/7/17 Jacek Caban : > On 07/15/12 14:21, Nicolas Le Cam wrote: >> Hi Jacek, >> >> Could it be backported into stable 2.x ? This will allow distros to >> package it with the next stable release of mingw-w64. > > I've just committed it to 2.x branch. It's up to distros now to update > packages. > > Jacek Thanks a lot Jacek ! -- Nicolas Le Cam
Re: include: fix mingw64 build
2012/7/4 Jacek Caban : > On 07/03/12 20:10, Jacek Caban wrote: >> On 06/29/12 03:35, Austin English wrote: >>> On Thu, Jun 28, 2012 at 6:30 PM, Nicolas Le Cam >>> wrote: >>>> 2012/6/29 Austin English : >>>>> Fixes http://bugs.winehq.org/show_bug.cgi?id=30980 >>>>> >>>>> -- >>>>> -Austin >>>>> >>>>> >>>>> >>>> Hi Austin, >>>> >>>> I already tried to fix it on Wine side, see [1], >>>> but Alexandre told me on IRC that the bug needs to be fixed in mingw-w64, >>>> as it shouldn't include crtdefs.h by default. >>>> >>>> BTW, won't that break mingw32 build ? >>>> >>>> [1] http://source.winehq.org/patches/data/84070 >>>> >>>> -- >>>> Nicolas Le Cam >>> Thanks for the info. Have you or anyone else discussed this with >>> mingw64? I did a quick search on their bugtracker, but don't see >>> anything.. >>> http://sourceforge.net/search/?group_artifact_id=983354&type_of_search=artifact&group_id=202880&words=crtdefs >> FWIW, here is my proposed patch to mingw-w64: >> >> http://repo.or.cz/w/mingw-w64/jacek.git/commitdiff/5db96424c7b9ac4aa5a66bd0e9724740624bf96f >> >> We will see if they like it. > > The (extended) fix is in mingw-w64 SVN now. > > Jacek > > > > Hi Jacek, Could it be backported into stable 2.x ? This will allow distros to package it with the next stable release of mingw-w64. -- Nicolas Le Cam
Re: include: fix mingw64 build
2012/7/3 Jacek Caban : > On 06/29/12 03:35, Austin English wrote: >> On Thu, Jun 28, 2012 at 6:30 PM, Nicolas Le Cam wrote: >>> 2012/6/29 Austin English : >>>> Fixes http://bugs.winehq.org/show_bug.cgi?id=30980 >>>> >>>> -- >>>> -Austin >>>> >>>> >>>> >>> Hi Austin, >>> >>> I already tried to fix it on Wine side, see [1], >>> but Alexandre told me on IRC that the bug needs to be fixed in mingw-w64, >>> as it shouldn't include crtdefs.h by default. >>> >>> BTW, won't that break mingw32 build ? >>> >>> [1] http://source.winehq.org/patches/data/84070 >>> >>> -- >>> Nicolas Le Cam >> Thanks for the info. Have you or anyone else discussed this with >> mingw64? I did a quick search on their bugtracker, but don't see >> anything.. >> http://sourceforge.net/search/?group_artifact_id=983354&type_of_search=artifact&group_id=202880&words=crtdefs > > FWIW, here is my proposed patch to mingw-w64: > > http://repo.or.cz/w/mingw-w64/jacek.git/commitdiff/5db96424c7b9ac4aa5a66bd0e9724740624bf96f > > We will see if they like it. > > Jacek Thanks a lot Jacek ! -- Nicolas Le Cam
Re: include: fix mingw64 build
2012/6/29 Austin English : > On Thu, Jun 28, 2012 at 6:30 PM, Nicolas Le Cam wrote: >> 2012/6/29 Austin English : >>> Fixes http://bugs.winehq.org/show_bug.cgi?id=30980 >>> >>> -- >>> -Austin >>> >>> >>> >> Hi Austin, >> >> I already tried to fix it on Wine side, see [1], >> but Alexandre told me on IRC that the bug needs to be fixed in mingw-w64, >> as it shouldn't include crtdefs.h by default. >> >> BTW, won't that break mingw32 build ? >> >> [1] http://source.winehq.org/patches/data/84070 >> >> -- >> Nicolas Le Cam > > Thanks for the info. Have you or anyone else discussed this with > mingw64? I did a quick search on their bugtracker, but don't see > anything.. > http://sourceforge.net/search/?group_artifact_id=983354&type_of_search=artifact&group_id=202880&words=crtdefs > > -- > -Austin No I didn't take the time to report the issue. I cloned their repo and wanted to send a patch, unfortunately I didn't have the time to work on that actually. -- Nicolas Le Cam
Re: include: fix mingw64 build
2012/6/29 Austin English : > Fixes http://bugs.winehq.org/show_bug.cgi?id=30980 > > -- > -Austin > > > Hi Austin, I already tried to fix it on Wine side, see [1], but Alexandre told me on IRC that the bug needs to be fixed in mingw-w64, as it shouldn't include crtdefs.h by default. BTW, won't that break mingw32 build ? [1] http://source.winehq.org/patches/data/84070 -- Nicolas Le Cam
Re: po: English (neutral / Great Britain) spelling fixes.
2012/5/3 Frédéric Delanoy : > On Thu, May 3, 2012 at 7:07 AM, Nicolas Le Cam wrote: >> Le 3 mai 2012 02:45, "Francois Gouget" a écrit : >> >> >>> @@ -9429,9 +9429,9 @@ msgstr "" >>> "start [options] document_filename\n" >>> "\n" >>> "Options:\n" >>> -"/M[inimized] Start the program minimized.\n" >>> -"/MAX[imized] Start the program maximized.\n" >>> -"/R[estored] Start the program normally (neither minimized nor >>> maximized).\n" >>> +"/M[inimized] Start the program minimised.\n" >>> +"/MAX[imized] Start the program maximised.\n" >>> +"/R[estored] Start the program normally (neither minimised nor >>> maximised).\n" >>> "/W[ait] Wait for started program to finish, then exit with its exit >>> " >>> "code.\n" >>> "/Unix Use a Unix filename and start the file like windows >>> explorer.\n" >> Hi Francois, >> Shouldn't the end of words between brackets be translated too ? > > IMO they shouldn't be translated, since they indicate the long version > of options. > > Frédéric You're right ! (Even if code seems to only check if the second letter is a 'a' or anything else .. and windows only advertise /MIN and /MAX as valid parameters) -- Nicolas Le Cam
Re: po: English (neutral / Great Britain) spelling fixes.
Le 3 mai 2012 02:45, "Francois Gouget" a écrit : > @@ -9429,9 +9429,9 @@ msgstr "" > "start [options] document_filename\n" > "\n" > "Options:\n" > -"/M[inimized] Start the program minimized.\n" > -"/MAX[imized] Start the program maximized.\n" > -"/R[estored] Start the program normally (neither minimized nor maximized).\n" > +"/M[inimized] Start the program minimised.\n" > +"/MAX[imized] Start the program maximised.\n" > +"/R[estored] Start the program normally (neither minimised nor maximised).\n" > "/W[ait] Wait for started program to finish, then exit with its exit " > "code.\n" > "/UnixUse a Unix filename and start the file like windows explorer.\n" Hi Francois, Shouldn't the end of words between brackets be translated too ? -- Nicolas Le Cam
Re: [PATCH] mscoree: Print the correct values in a TRACE.
Le 23 mars 2012 22:21, Charles Davis a écrit :
>
> On Mar 23, 2012, at 3:09 PM, Nicolas Le Cam wrote:
>
>> Le 23 mars 2012 21:41, Lauri Kenttä a écrit :
>>> ---
>>> dlls/mscoree/mscoree_main.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/dlls/mscoree/mscoree_main.c b/dlls/mscoree/mscoree_main.c
>>> index 1aa120f..0ebc813 100644
>>> --- a/dlls/mscoree/mscoree_main.c
>>> +++ b/dlls/mscoree/mscoree_main.c
>>> @@ -359,7 +359,7 @@ HRESULT WINAPI GetRequestedRuntimeInfo(LPCWSTR pExe,
>>> LPCWSTR pwszVersion, LPCWST
>>>
>>> HRESULT WINAPI GetRequestedRuntimeVersion(LPWSTR pExe, LPWSTR pVersion,
>>> DWORD cchBuffer, DWORD *dwlength)
>>> {
>>> - TRACE("(%s, %p, %d, %p)\n", debugstr_w(pExe), debugstr_w(pExe),
>>> cchBuffer, dwlength);
>>> + TRACE("(%s, %p, %d, %p)\n", debugstr_w(pExe), pVersion, cchBuffer,
>>> dwlength);
>>>
>>> if(!dwlength)
>>> return E_POINTER;
>>> --
>>> 1.7.9.4
>>>
>>>
>>>
>> Hi Lauri,
>>
>> Should be %s debugstr_w(pVersion) IMHO.
> No, that's an out parameter. (It's hard to tell, because the in parameter
> pExe is of type LPWSTR instead of LPCWSTR.)
>
> Chip
>
My bad, thanks for the explanation !
--
Nicolas Le Cam
Re: [PATCH] mscoree: Print the correct values in a TRACE.
Le 23 mars 2012 21:41, Lauri Kenttä a écrit :
> ---
> dlls/mscoree/mscoree_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/dlls/mscoree/mscoree_main.c b/dlls/mscoree/mscoree_main.c
> index 1aa120f..0ebc813 100644
> --- a/dlls/mscoree/mscoree_main.c
> +++ b/dlls/mscoree/mscoree_main.c
> @@ -359,7 +359,7 @@ HRESULT WINAPI GetRequestedRuntimeInfo(LPCWSTR pExe,
> LPCWSTR pwszVersion, LPCWST
>
> HRESULT WINAPI GetRequestedRuntimeVersion(LPWSTR pExe, LPWSTR pVersion,
> DWORD cchBuffer, DWORD *dwlength)
> {
> - TRACE("(%s, %p, %d, %p)\n", debugstr_w(pExe), debugstr_w(pExe),
> cchBuffer, dwlength);
> + TRACE("(%s, %p, %d, %p)\n", debugstr_w(pExe), pVersion, cchBuffer,
> dwlength);
>
> if(!dwlength)
> return E_POINTER;
> --
> 1.7.9.4
>
>
>
Hi Lauri,
Should be %s debugstr_w(pVersion) IMHO.
--
Nicolas Le Cam
Re: Web based translation tool
Le 15 mars 2012 16:12, Aric Stewart a écrit : > Hi Yaron, > > Thanks for continuing to push this forward. I have been a bit swamped > recently. The thing is that there are several projects who are all JUST on > the edge of being able to do what we need but none that are there yet. > > I got an e-mail from a pootle developer saying that they are doing work to > do just this sort of thing for the Mozilla project however it is not ready > yet, the wikimedia foundation is in the same boat. > > I do not know if Weblate will work or not. > > Basically we have 3 big requirements that have been sticking points for > various solutions. > > 1) Real Names and e-mails for all contributors > > 2) Individual attribution for all translations. So we know exactly who > changed what string. > > 3) Generate incremental diffs/patches/change sets divided based on > translator. > > Generally it is #2 that has been the hardest for projects to cope with. > > -aric > > Hi Aric, I don't know weblate but as it is based on git (its home page says 'Tight git integration - every change is represented by Git commit') I think #2 and #3 should be handled easily. -- Nicolas Le Cam
Re: msvcp90/tests: Don't redefine __thiscall (resend).
Le 13 mars 2012 16:28, Alexandre Julliard a écrit : > Nicolas Le Cam writes: > >> @@ -60,11 +60,13 @@ static char* (__cdecl *p_Copy_s)(char*, size_t, const >> char*, size_t); >> static unsigned short (__cdecl *p_wctype)(const char*); >> static MSVCP__Ctypevec (__cdecl *p__Getctype)(void); >> >> +#ifndef __thiscall >> #ifdef __i386__ >> #define __thiscall __stdcall >> #else >> #define __thiscall __cdecl >> #endif >> +#endif > > That seems dangerous, we don't know what it has been defined to. > > -- > Alexandre Julliard > julli...@winehq.org You're right. I'll undefine it then. Thanks. -- Nicolas Le Cam
Re: [PATCH 6/6] d3dxof: Do not allow separator to terminate the string. Only the double quote can do that.
Le 10 mars 2012 17:56, Christian Costa a écrit : > Le 09/03/2012 16:11, Nicolas Le Cam a écrit : >> >> Le 9 mars 2012 14:22, Christian Costa a écrit : >>> >>> Le 09/03/2012 14:08, Nicolas Le Cam a écrit : >>>> >>>> Le 9 mars 2012 13:39, Christian Costa a écrit >>>> : >>>>> >>>>> Le 08/03/2012 21:23, Alexandre Julliard a écrit : >>>>>> >>>>>> Christian Costa writes: >>>>>> >>>>>>> This should fix the d3dxof problem of bug 12694. >>>>>> >>>>>> It's broken on 64-bit: >>>>>> >>>>>> ../../../../wine/tools/runtest -q -P wine -M d3dxof.dll -T ../../.. -p >>>>>> d3dxof_test.exe.so ../../../../wine/dlls/d3dxof/tests/d3dxof.c&& >>>>>> touch >>>>>> d3dxof.ok >>>>>> d3dxof.c:578: Test failed: Got size 8, expected 4 >>>>>> d3dxof.c:597: Test failed: Got size 8, expected 4 >>>>>> make[1]: *** [d3dxof.ok] Error 2 >>>>>> >>>>> I updated my tests and just remember sizeof must no be used in traces. >>>>> BTW >>>>> what should it be avoided ? >>>>> >>>>> Christian >>>>> >>>>> >>>> Because there's no C89/C90 portable way of printf'ing a size_t. >>>> >>> Ok. Thanks. But that could be done using a variable, right ? >> >> Not really, %llu format specifier is avoided too as it's not much >> portable. >> > I meant using an unsigned long variable and %lu. Somethig like that. Using unsigned long can cause value truncation in some implementations like win64. -- Nicolas Le Cam
Re: [PATCH 6/6] d3dxof: Do not allow separator to terminate the string. Only the double quote can do that.
Le 9 mars 2012 14:22, Christian Costa a écrit : > Le 09/03/2012 14:08, Nicolas Le Cam a écrit : >> >> Le 9 mars 2012 13:39, Christian Costa a écrit : >>> >>> Le 08/03/2012 21:23, Alexandre Julliard a écrit : >>>> >>>> Christian Costa writes: >>>> >>>>> This should fix the d3dxof problem of bug 12694. >>>> >>>> It's broken on 64-bit: >>>> >>>> ../../../../wine/tools/runtest -q -P wine -M d3dxof.dll -T ../../.. -p >>>> d3dxof_test.exe.so ../../../../wine/dlls/d3dxof/tests/d3dxof.c&& >>>> touch >>>> d3dxof.ok >>>> d3dxof.c:578: Test failed: Got size 8, expected 4 >>>> d3dxof.c:597: Test failed: Got size 8, expected 4 >>>> make[1]: *** [d3dxof.ok] Error 2 >>>> >>> I updated my tests and just remember sizeof must no be used in traces. >>> BTW >>> what should it be avoided ? >>> >>> Christian >>> >>> >> Because there's no C89/C90 portable way of printf'ing a size_t. >> > Ok. Thanks. But that could be done using a variable, right ? Not really, %llu format specifier is avoided too as it's not much portable. -- Nicolas Le Cam
Re: [PATCH 6/6] d3dxof: Do not allow separator to terminate the string. Only the double quote can do that.
Le 9 mars 2012 13:39, Christian Costa a écrit : > Le 08/03/2012 21:23, Alexandre Julliard a écrit : >> >> Christian Costa writes: >> >>> This should fix the d3dxof problem of bug 12694. >> >> It's broken on 64-bit: >> >> ../../../../wine/tools/runtest -q -P wine -M d3dxof.dll -T ../../.. -p >> d3dxof_test.exe.so ../../../../wine/dlls/d3dxof/tests/d3dxof.c&& touch >> d3dxof.ok >> d3dxof.c:578: Test failed: Got size 8, expected 4 >> d3dxof.c:597: Test failed: Got size 8, expected 4 >> make[1]: *** [d3dxof.ok] Error 2 >> > I updated my tests and just remember sizeof must no be used in traces. BTW > what should it be avoided ? > > Christian > > Because there's no C89/C90 portable way of printf'ing a size_t. -- Nicolas Le Cam
Re: Web based translation tool
Hi Aric, Latest entry on Planet Debian is about http://weblate.org/ which could be a good candidate according to its about page : Weblate is web based translation tool with tight Git integration. It features simple and clean user interface, propagation of translations across subprojects or automatic linking to source files. List of features includes: Easy web based translation Propagation of translations across sub-projects (for different branches) Tight git integration Usage of Django's admin interface Upload and automatic merging of po files Links to source files for context -- Nicolas Le Cam
Re: [PATCH] wined3d: Reduce console flood with an Ogre3D Game
2012/1/25 Nicolas Le Cam :
> 2012/1/25 Francois Gouget :
>> On Wed, 25 Jan 2012, Detlef Riekenberg wrote:
>>
>>> On Sun, 2012-01-22 at 19:53 +0100, Henri Verbeet wrote:
>>> > On 22 January 2012 19:44, Detlef Riekenberg wrote:
>>> > > - if (usage & ~handled)
>>> > > + static DWORD reported_once;
>>> > > +
>>> > > + if (usage & ~(handled | reported_once))
>>> > > + {
>>> > > + reported_once |= (usage & ~handled);
>>> > > FIXME("Unhandled usage flags %#x.\n", usage & ~handled);
>>> > > + }
>>> > I don't think so.
>>>
>>> Sorry, I have no Idea, what objections do you have.
>>
>> I don't pretend to know what Henry meant but reported_once is not
>> initialized. It's probably put into a zero-initialized section by the
>> compiler but it looks worrying to me (I believe something like this has
>> been debated on the Linux kernel mailing list).
>>
>> I did not try to check the bit manipulations.
>>
>> --
>> Francois Gouget http://fgouget.free.fr/
>> If you think the whole world revolves around you,
>> quit staring at the GPS display while driving.
>>
>>
>
> static variables are zero-initialized by default I don't think that's
> the problem. Perhaps it's because with such a patch, only the first
> unhandled flag will be reported and not others (wich can be of a
> different value), so using a bit mask to only report once every
> unhandled flags will be better ?
>
> --
> Nicolas Le Cam
I really shouldn't send mail until I get my third coffee ... sorry for
the useless noise.
--
Nicolas Le Cam
Re: [PATCH] wined3d: Reduce console flood with an Ogre3D Game
2012/1/25 Francois Gouget :
> On Wed, 25 Jan 2012, Detlef Riekenberg wrote:
>
>> On Sun, 2012-01-22 at 19:53 +0100, Henri Verbeet wrote:
>> > On 22 January 2012 19:44, Detlef Riekenberg wrote:
>> > > - if (usage & ~handled)
>> > > + static DWORD reported_once;
>> > > +
>> > > + if (usage & ~(handled | reported_once))
>> > > + {
>> > > + reported_once |= (usage & ~handled);
>> > > FIXME("Unhandled usage flags %#x.\n", usage & ~handled);
>> > > + }
>> > I don't think so.
>>
>> Sorry, I have no Idea, what objections do you have.
>
> I don't pretend to know what Henry meant but reported_once is not
> initialized. It's probably put into a zero-initialized section by the
> compiler but it looks worrying to me (I believe something like this has
> been debated on the Linux kernel mailing list).
>
> I did not try to check the bit manipulations.
>
> --
> Francois Gouget http://fgouget.free.fr/
> If you think the whole world revolves around you,
> quit staring at the GPS display while driving.
>
>
static variables are zero-initialized by default I don't think that's
the problem. Perhaps it's because with such a patch, only the first
unhandled flag will be reported and not others (wich can be of a
different value), so using a bit mask to only report once every
unhandled flags will be better ?
--
Nicolas Le Cam
Re: [PATCH] kernel32: Output message to stderr in UTF-8
2011/10/25 Alex Henrie : > Hello, > > Last week I submitted a patch to make kernel32 output an error message > in UTF-8 rather than the current codepage. This fixed a bug in which > the command "wine /." would produce a garbled error message in > languages other than English. However, thinking about this some more, > I'm not sure that my patch fixes the bug correctly. I made > WideCharToMultiByte use CP_UTF8 instead of CP_ACP, but reading more > about the codepage setting, I think I should have used either > CP_UNIXCP or CP_OEMCP. Could anyone help clarify which should be used? > > -Alex > See Dmitry response to your patch : http://article.gmane.org/gmane.comp.emulators.wine.devel/87295 -- Nicolas Le Cam
Re: WineHQ database compromise
2011/10/11 Jerome Leclanche : > Thank you so much for letting the users know so early on. > > Bugzilla/forum passwords should probably be reset as well for appdb > users, there's no doubt most people share passwords with the appdb. > > On Tue, Oct 11, 2011 at 8:13 PM, Jeremy White wrote: >> Hi, >> >> I am sad to say that there was a compromise of the WineHQ database system. >> >> What we know at this point that someone was able to obtain unauthorized >> access to the phpmyadmin utility. We do not exactly how they obtained >> access; it was either by compromising an admins credentials, or by >> exploiting an unpatched vulnerability in phpmyadmin. >> >> We had reluctantly provided access to phpmyadmin to the appdb developers >> (it is a very handy tool, and something they very much wanted). But it >> is a prime target for hackers, and apparently our best efforts at >> obscuring it and patching it were not sufficient. >> >> So we have removed all access to phpmyadmin from the outside world. >> >> We do not believe the attackers obtained any other form of access to the >> system. >> >> On the one hand, we saw no evidence of harm to any database. We saw no >> evidence of any attempt to change the database (and candidly, using the >> real appdb or bugzilla is the easy way to change the database). >> >> Unfortunately, the attackers were able to download the full login >> database for both the appdb and bugzilla. This means that they have all >> of those emails, as well as the passwords. The passwords are stored >> encrypted, but with enough effort and depending on the quality of the >> password, they can be cracked. >> >> This, I'm afraid, is a serious threat; it means that anyone who uses the >> same email / password on other systems is now vulnerable to a malicious >> attacker using that information to access their account. >> >> We are going to be resetting every password and sending a private email >> to every affected user. >> >> This is again another reminder to never use a common username / password >> pair. This web site provides further advice as well: >> http://asiknews.wordpress.com/2011/03/02/best-practice-password-management-for-internet-web-sites/ >> >> I am very sad to have to report this. We have so many challenges in our >> world today that this is a particularly painful form of salt for our wounds. >> >> However, I think it is urgent for everyone to know what happened. >> >> Cheers, >> >> Jeremy >> >> >> > > > Thanks for the early notice ! Testbot passwords should also be reset as it seems it doesn't allow password reset / change ATM. (At least I wasn't able to find that possibility) -- Nicolas Le Cam
Re: winspool.drv: Correct test for Device Capabilities
2011/9/9 Alistair Leslie-Hughes : > On 8/09/2011 8:35 PM, Marvin wrote: >> >> Hi, >> >> While running your changed tests on Windows, I think I found new failures. >> Being a bot and all I'm not very good at pattern recognition, so I might >> be >> wrong, but could you please double-check? >> Full results can be found at >> http://testbot.winehq.org/JobDetails.pl?Key=14060 >> >> Your paranoid android. >> >> >> === WINEBUILD (build) === >> Can't determine base name >> > Can someone explain what this error is and how to rectify it? > > Best Regards > Alistair Leslie-Hughes > > TestBot can't determine basename (winspool.drv) from the test executable name (winspool.drv_test.exe) because of a too restrictive regex in bin/WineRunBuild.pl line 180 [1]. Changing it to 'if ($OtherFileName =~ m/^([\w_\-]+)(|\.[\w]+)_test(|64)\.exe$/)' should fix the problem (same change should be applied at line 258). [1] http://wine.git.sourceforge.net/git/gitweb.cgi?p=wine/winetestbot;a=blob;f=bin/WineRunBuild.pl;h=4b85ac719edfabdb88c32698f2e8474090454ac5;hb=HEAD#l180 -- Nicolas Le Cam
Re: (resend)usp10/test: test ScriptXtoX on an RTL set with differring cChars and cGlyphs
2011/8/25 Aric Stewart : > Ah i see what you are seeing. > > I will see if that helps. However it is still strange that the tests are > all working for me and when i submit tests but not when it is submitted as a > patch. > > -aric > > On 8/25/11 7:47 AM, Hans Leidekker wrote: >> >> On Thu, 2011-08-25 at 07:38 -0500, Aric Stewart wrote: >>> >>> Yes, it depends on if it is a RTL or LTR string. That is correct. >> >> What I meant is that it does not always match the right hand operand >> in the test condition. >> >> > > > toolchain differences ? -- Nicolas Le Cam
Re: About building test suite for Windows
2011/6/12 Patrick Gauthier : > Hi, > > As I was writing my task dialog test I ran into a few problems trying to > test on Windows... > > First, I tried building it using make crosstest but I keep getting this: > > $ gmake crosstest > crosstest is not supported (mingw not installed?) > gmake: *** [crosstest] Error 1 > > I am on FreeBSD 8.2-RELEASE (i386), I have the following mingw ports > installed (using pkg_add) > > mingw32-bin-msvcrt-r3.18.a3.14 > mingw32-binutils-2.21,1 > mingw32-directx-20020518 > mingw32-gcc-4.5.0_1,1 > mingw32-pdcurses-3.4 > mingw32-pthreads-2.8.0 > > I deleted config.status (there was no config.cache) and re-ran > ./configure, it fails to detect mingw, so I gave up on that. > > I then tried building them on Windows directly instead (using Visual > Studio 2008 with Windows SDK v7.0) as describred there: > http://www.winehq.org/docs/winedev-guide/testing-windows > > However, trying to compile comctl32_tests using the WINE headers would > complain about EXCEPTION_EXECUTE_HANDLER being undefined. On the other > hand, compiling with the MSVC headers would complain about TVIS_FOCUSED > not being present. According to this: > http://support.microsoft.com/kb/166471 it has been deprecated and > removed from MS headers a long time ago. > > Eventually I would like to just be able to make crosstest so that I can > stay in one dev environments and not two, so if anybody could help me > about why isn't mingw32 detected, I would like it. > > Thanks. > - Patrick > > > If I read the port's makefile right, using ./configure CROSSCC="mingw32-gcc" should help. -- Nicolas Le Cam
Re: po: Update French translation
Le 6 mai 2011 08:41, Frédéric Delanoy a écrit : > 2011/5/6 Nicolas Le Cam : >>> #: regedit.rc:88 >>> -#, fuzzy >>> msgid "Modify Binary Data..." >>> -msgstr "Modifier les données &binaires" >>> +msgstr "Modifier les données &binaires..." >> I'm not sure you can add a keyboard accelerator if there isn't one in >> the original message. > > Well actually, it's more like an error/omission in the original En version. > > POPUP "" > BEGIN > MENUITEM "&Modify...", ID_EDIT_MODIFY > MENUITEM "Modify Binary Data...", ID_EDIT_MODIFY_BIN > MENUITEM SEPARATOR > MENUITEM "&Delete\tDel", ID_EDIT_DELETE > MENUITEM "&Rename", ID_EDIT_RENAME > END > > As you can see, there's an accelerator on 3 out of 4 entries. For > consistency sake, the remaining one should have one as well. > I'll send a patch for this. > >> -- >> Nicolas Le Cam > > Frédéric Delanoy > IMHO it isn't. It duplicates Windows behaviour : Modify / Delete and Rename have accelerators, Modify Binary Data doesn't. -- Nicolas Le Cam
Re: po: Update French translation
> #: regedit.rc:88 > -#, fuzzy > msgid "Modify Binary Data..." > -msgstr "Modifier les données &binaires" > +msgstr "Modifier les données &binaires..." I'm not sure you can add a keyboard accelerator if there isn't one in the original message. -- Nicolas Le Cam
Re: po: Update French translation
Hi Frédéric, Le 29 avril 2011 00:16, Frédéric Delanoy a écrit : > #: winerror.mc:441 > msgid "No more search handles\n" > -msgstr "Il n'y a plus de descripteurs de recherche\n" > +msgstr "Il n'y a plus de descripteur de recherche\n" This one isn't correct. There's not only one handle when available but many so it should take an 's' in the negative form too. Thanks for your work ! -- Nicolas Le Cam
Re: d3dx9_36: Fix uninitialized variable warnings.
2011/4/26 Matteo Bruni : > 2011/4/26 Nicolas Le Cam : >> msdn tells us to use 0 to disable colorkey [1]. Let me know if you >> think it isn't the correct things to do. >> >> [1] http://msdn.microsoft.com/en-us/library/bb172902%28v=vs.85%29.aspx >> >> -- >> Nicolas Le Cam >> > > Argh, this was already spotted by Gerald Pfeifer some time ago and I > told him I was going to send a patch, which didn't happen yet... > I'm sending it now (I prefer to fix this in a different way), assuming > your patch wasn't already committed by AJ. > No problem ! -- Nicolas Le Cam
Re: inetcpl: Update French translation
Hi Frédéric, Le 13 avril 2011 23:16, Frédéric Delanoy a écrit : > --- > dlls/inetcpl.cpl/cpl_Fr.rc | 42 > +- > 1 files changed, 41 insertions(+), 1 deletions(-) > > diff --git a/dlls/inetcpl.cpl/cpl_Fr.rc b/dlls/inetcpl.cpl/cpl_Fr.rc > index 1244ff6..432a8c3 100644 > --- a/dlls/inetcpl.cpl/cpl_Fr.rc > +++ b/dlls/inetcpl.cpl/cpl_Fr.rc > @@ -2,7 +2,7 @@ > * Internet control panel applet > * French language support > * > - * Copyright 2010 Frédéric Delanoy > + * Copyright 2010-2011 Frédéric Delanoy > * > * This library is free software; you can redistribute it and/or > * modify it under the terms of the GNU Lesser General Public > @@ -49,6 +49,46 @@ BEGIN > > END > > +/* "Delete browsing history" dialog */ > +IDD_DELETE_HISTORY DIALOG 0, 0, 250, 250 > +STYLE DS_MODALFRAME | WS_CAPTION | WS_SYSMENU > +FONT 8, "MS Shell Dlg" > +CAPTION "Effacer l'historique de navigation" > +BEGIN > + > +AUTOCHECKBOX "Fichiers internet temporaires\nCopies en cache de > pages web, d'images et de certificats.", > +IDC_DELETE_TEMP_FILES, 10, 8, 230, 30, BS_TOP | > BS_MULTILINE > +AUTOCHECKBOX "Cookies\nFichiers sauvés sur votre ordinateur par des > sites web, qui y stockent des informations comme des préférences utilisateur > et des informations de connexion", > You should use sauvegardés instead of sauvés which doesn't apply to computers. I would also use "qui y stockent des choses comme les préférences utilisateurs et les informations de connexion". It better follows the original text and avoid a repetition. > +IDC_DELETE_COOKIES, 10, 32, 230, 35, BS_TOP | > BS_MULTILINE > +AUTOCHECKBOX "Historique\nListe des sites web accédés.", > +IDC_DELETE_HISTORY, 10, 73, 230, 30, BS_TOP | > BS_MULTILINE > +AUTOCHECKBOX "Données de formulaires\nNoms d'utilisateur et autres > informations entrées dans des formulaires.", > +IDC_DELETE_FORM_DATA, 10, 98, 230, 30, BS_TOP | > BS_MULTILINE > +AUTOCHECKBOX "Mots de passe\nMots de passe entrés dans des > formulaires et sauvegardés.", > +IDC_DELETE_PASSWORDS, 10, 128, 230, 30, BS_TOP | > BS_MULTILINE > +DEFPUSHBUTTON "Annuler", IDCANCEL, 185, 228, 60, 15, WS_GROUP > +PUSHBUTTON "Effacer", IDOK, 120, 228, 60, 15, WS_GROUP > + > +END > + > +/* "Security" propsheet */ > +IDD_SECURITY DIALOG 0, 0, 320, 220 > +STYLE WS_CAPTION | WS_CHILD | WS_DISABLED > +FONT 8, "MS Shell Dlg" > +CAPTION "Security" > +BEGIN > + > +CONTROL "Listview", IDC_SEC_LISTVIEW, "SysListView32", > +LVS_ICON | LVS_ALIGNLEFT | LVS_AUTOARRANGE | LVS_SINGLESEL > | LVS_SHOWSELALWAYS | WS_BORDER | WS_VSCROLL, > +4, 4, 312, 58 > +LTEXT "", IDC_SEC_ZONE_INFO, 4, 68, 312, 20 > +GROUPBOX"", IDC_SEC_GROUP, 4, 88, 312, 126 > +CONTROL "trackbar", IDC_SEC_TRACKBAR, "msctls_trackbar32", > +TBS_VERT | TBS_AUTOTICKS | TBS_BOTH | TBS_REVERSED, 8, 98, > 32, 100 > +LTEXT "", IDC_SEC_LEVEL, 48, 102, 180, 12 > +LTEXT "", IDC_SEC_LEVEL_INFO, 48, 114, 260, 80 > +END > + > /* "Content" propsheet */ > IDD_CONTENT DIALOG 0, 0, 320, 220 > STYLE WS_CAPTION | WS_CHILD | WS_DISABLED > -- > 1.7.4.3 > > > > -- Nicolas Le Cam
Re: inetcpl.cpl: Update French translation
Hi Frédéric, Le 12 mars 2011 09:09, Frédéric Delanoy a écrit : > --- > dlls/inetcpl.cpl/cpl_Fr.rc | 12 ++-- > 1 files changed, 6 insertions(+), 6 deletions(-) > > diff --git a/dlls/inetcpl.cpl/cpl_Fr.rc b/dlls/inetcpl.cpl/cpl_Fr.rc > index 54d19e9..1244ff6 100644 > --- a/dlls/inetcpl.cpl/cpl_Fr.rc > +++ b/dlls/inetcpl.cpl/cpl_Fr.rc > @@ -35,17 +35,17 @@ CAPTION "Général" > BEGIN > > GROUPBOX" Page d'accueil ", IDC_STATIC, 4, 4, 312, 52 > -LTEXT "Vous pouvez spécifier une adresse à utiliser comme page > d'accueil :", > +LTEXT "Vous pouvez spécifier l'adresse à utiliser comme page > d'accueil :", > IDC_STATIC, 68, 10, 242, 10 > EDITTEXTIDC_HOME_EDIT, 68, 22, 242, 12, WS_VISIBLE | ES_AUTOHSCROLL > PUSHBUTTON "Page &courante", IDC_HOME_CURRENT, 68, 36, 77, 14 > PUSHBUTTON "Page par &défaut", IDC_HOME_DEFAULT, 151, 36, 77, 14 > PUSHBUTTON "Page &blanche", IDC_HOME_BLANK, 233, 36, 77, 14 > -GROUPBOX" Browsing history ", IDC_STATIC, 4, 60, 312, 46 > -LTEXT "You can delete cached pages, cookies and other data.", > -IDC_STATIC, 58, 72, 252, 10 > -PUSHBUTTON "Delete &files...", IDC_HISTORY_DELETE, 144, 86, 80, 14 > -PUSHBUTTON "&Settings...", IDC_HISTORY_SETTINGS, 230, 86, 80, 14 > +GROUPBOX" Historique de navigation ", IDC_STATIC, 4, 60, 312, 46 > +LTEXT "Vous pouvez effacer les pages en cache, les cookies et > d'autres données.", > +IDC_STATIC, 68, 72, 242, 10 > "Vous pouvez effacer les pages en cache, les cookies et autres données." should be better. > +PUSHBUTTON "&Effacer les fichiers...", IDC_HISTORY_DELETE, 151, 86, > 77, 14 > +PUSHBUTTON "&Paramètres...", IDC_HISTORY_SETTINGS, 233, 86, 77, 14 > > END > > -- > 1.7.4.1 > > -- Nicolas Le Cam
Re: Try to Implement my first Stub function - AbortPrinter() - (try 2).
2011/2/8 Loïc Maury
>
> Hello Mr.Timoshkov,
>
> Thank you for your reply.
>
>> Loīc Maury wrote:
>>
>>
>> After the various comments, I have modified the patch.
>>>
>> First of all set your tab size to 8, and ask your editor to not use tabs
>> at all.
>>
> I have modified my editor, but I don't know if it 's correct now ?
>
>> + TRACE("(%s, %s, %p, %d, %d)\n",debugstr_w(printer->name)
>>>
>>> + ,debugstr_w(printer->printername)
>>> + ,printer->backend_printer
>>> + ,printer->queue->ref
>>> + ,list_count(&printer->queue->jobs));
>>>
>> TRACE() with the API parameters usually is the very first statement in
>> the API implementation, comma should be placed at the end of the
>> statement,
>> not before.
>>
> Ok, I have remplaced this TRACE().
>
>> + GetPrinterW(hPrinter, 2, NULL, 0,&needed);
>>>
>>> + pi2 = HeapAlloc(GetProcessHeap(), 0,
>>> needed);
>>> + GetPrinterW(hPrinter, 2, (LPBYTE)pi2,
>>> needed,&needed);
>>>
>> You need to check the return value of GetPrinterW() and handle the errors.
>>
> Ok
>
>> + if(pi2)
>>> + HeapFree(GetProcessHeap(), 0, pi2);
>>>
>> NULL check before HeapFree() is not needed.
>>
> Ok, I have removed the NULL check.
>
> + TRACE("return %d\n", ret);
>>>
>> This trace is redundant.
>>
> Ok, I have removed this TRACE().
>
> I have make an other patch.
>
> Thank you
>
> Loīc
>
>
>
>
>
Hi Loïc,
In addition to Dmitry and Andrew comments, you're adding a lot of trailing
spaces (git apply output : warning: squelched 22 whitespace errors warning:
27 lines add whitespace errors.), there's also no need for an extra newline
after the end label.
--
Nicolas Le Cam
Re: gdi32/dib.c: Write true bitmap height into info and copy scanlines in the correct order.
to.*/
> +memset(&bi, 0, sizeof(bi));
> +/*Now test with a BITMAPCOREHEADER.*/
> +bi.bmiHeader.biSize=sizeof(BITMAPCOREHEADER);
> +GetDIBits(hdc, bmp, 0, 0, NULL, &bi, DIB_RGB_COLORS);
> +ok(((BITMAPCOREHEADER*)&bi)->bcHeight == (WORD)-2, "Height should be
> -2.");
> +ok(((BITMAPCOREHEADER*)&bi)->bcWidth == (WORD)2, "Width should be
> 2.");
> +/*Clean up.*/
> +DeleteObject(bmp);
> +}
> +
> +static void test_GetDIBits_single_pixel_destination(void)
> +{
> +BITMAPINFO bi;
> +HBITMAP bmptb, bmpbt;
> +HDC hdc;
> +int pixelOut;
> +int *picture;
> +bi.bmiHeader.biSize=sizeof(bi.bmiHeader);
> +bi.bmiHeader.biWidth=2;
> +bi.bmiHeader.biHeight=2;
> +bi.bmiHeader.biPlanes=1;
> +bi.bmiHeader.biBitCount=32;
> +bi.bmiHeader.biCompression=BI_RGB;
> +
> +/*Get the device context for the screen.*/
> +hdc=GetDC(NULL);
> +
> +/*Create the bottom to top image (image's bottom scan line is at the
> top in memory).*/
> +bmpbt=CreateDIBSection(hdc, &bi, DIB_RGB_COLORS, (void**)&picture,
> NULL, 0);
> +/*Now that we have a pointer to the pixels, we write to them.*/
> +picture[0]=1;
> +picture[1]=2;
> +picture[2]=3;
> +picture[3]=4;
> +/*Create the top to bottom image (images' bottom scan line is at the
> bottom in memory).*/
> +bi.bmiHeader.biHeight=-2; /*We specify that we want a top to bottom
> image by specifying a negative height.*/
> +bmptb=CreateDIBSection(hdc, &bi, DIB_RGB_COLORS, (void**)&picture,
> NULL, 0);
> +/*Write to this top to bottom bitmap.*/
> +picture[0]=1;
> +picture[1]=2;
> +picture[2]=3;
> + picture[3]=4;
> +
> +bi.bmiHeader.biWidth=1;
> +
> +bi.bmiHeader.biHeight=2;
> +GetDIBits(hdc, bmpbt, 0, 1, &pixelOut, &bi, DIB_RGB_COLORS);
> +ok(pixelOut==1, "Bottom-up -> bottom-up should have first scanline.");
> +GetDIBits(hdc, bmptb, 0, 1, &pixelOut, &bi, DIB_RGB_COLORS);
> +ok(pixelOut==3, "Top-down -> bottom-up should have last scanline.");
> +
> +bi.bmiHeader.biHeight=-2;
> +GetDIBits(hdc, bmpbt, 0, 1, &pixelOut, &bi, DIB_RGB_COLORS);
> +ok(pixelOut==1, "Bottom-up -> top-down should have first scanline.");
> +GetDIBits(hdc, bmptb, 0, 1, &pixelOut, &bi, DIB_RGB_COLORS);
> +ok(pixelOut==3, "Top-down -> top-down should have last scanline.");
> +
> +DeleteObject(bmpbt);
> +DeleteObject(bmptb);
> +}
> +
> START_TEST(bitmap)
> {
> HMODULE hdll;
> @@ -3080,4 +3190,6 @@ START_TEST(bitmap)
> test_bitmapinfoheadersize();
> test_get16dibits();
> test_clipping();
> +test_GetDIBits_single_pixel_destination();
> +test_GetDIBits_info_query();
> }
> --
> 1.7.1
>
>
>
>
Hi Jack,
You forgot trailing \n in the ok() calls.
--
Nicolas Le Cam
Re: tests/amstream.c doesn't test anything
2011/1/12 > Hi, > > please take a look at test.winehq.org > http://test.winehq.org/data/tests/amstream:amstream.html > > It appears that almost all native machines perform 0 tests on amstream. > As no skip is flagged, results appear all green. > The only exception are Wylda's XP machines. They execute 16 tests > but fail one of them. > > Can we conclude that the amstream tests are in a bad shape, despite green > colour? > Or that some amstream components are optional and should be installed on > more test bots? > (Note that the amstream.dll is present, otherwise the message would be > different) > > Most Wine machines also execute 0 tests, except Nicolas Le Cam's (nlc) > amstream.c:163: Test marked todo: IDirectDrawMediaStream_CreateSample > returned: 80004001 > What's different about these machines? > > Should I take this to bugzilla? I know next to nothing about > amstream. It is about streaming to audio or a DirectDraw surface. > http://msdn.microsoft.com/en-us/library/dd390909%28v=VS.85%29.aspx > > Regards, > Jörg Höhle > > Hi Jörg, The difference is that I'm creating a test.avi symlink to an avi file in the working directory before launching winetest. This avi file is also used by tests/avisplitter.c (skip) and tests/filtergraph.c (no skip) and I'm creating another msrle.avi symlink to the same file to avoid skipping in tests/mmio.c. The file used is ED_1024.avi from the Elephant Dream short film. As I'm using winetest_latest.exe, I also need to use the -d switch to be able to skip the temp dir creation and put symlink in it. BTW, tests/filtergraph.c also tries to use a test.mpg file (no skip), but I didn't found one under CC when I added this to my automated test script. I'll add one this evening now that I've just found http://learn.creativecommons.org/. -- Nicolas Le Cam
Re: kernel32/tests: typo fixes
2010/9/7 Austin English > I initially noticed the wrong hemisphere label, but then the > capitalization was bugging me :-) > > -- > -Austin Hi Austin, @@ -449,18 +449,18 @@ static void test_TzSpecificLocalTimeToSystemTime(void) > tzW.DaylightBias=-60; > tzW.StandardDate.wMonth=10; > tzW.StandardDate.wDayOfWeek=0; /*sunday */ > > You missed that one! -- Nicolas Le Cam
Re: Must copy static const D3DVERTEXELEMENT9 into dynamically alllocated D3DVERTEXELEMENT9 * before pointer passed correctly in Wine?
2010/9/7 misha680
>
> Sorry for reposting - apparently my original nabble link did not work :(
>
> ---
>
> Dear All:
>
> Sorry to bother... I am working on a D3DXCreateMesh/ID3DXMesh patch, and I
> encountered a very strange error.
>
> Specifically, it seems that when passing a LPD3DVERTEXELEMENT9 * parameter
> to D3DXCreateMesh,
> a) in Windows - one can create
>
>static const D3DVERTEXELEMENT9 decl1[3] = {
>{0, 0, D3DDECLTYPE_FLOAT3, D3DDECLMETHOD_DEFAULT,
> D3DDECLUSAGE_POSITION, 0},
>{0, 0xC, D3DDECLTYPE_FLOAT3, D3DDECLMETHOD_DEFAULT,
> D3DDECLUSAGE_NORMAL, 0},
>D3DDECL_END(), };
>
> and pass (LPD3DVERTEXELEMENT9 *)&decl1 directly.
>
> b) in Wine tests - I must first allocate a D3DVERTELEMENT9 *, then call
> HeapAlloc, and finally copy my original decl1 and pass &decl (pointer to
> newly allocated structure) for it to work. Any ideas?
>
> Here is my git diff
> http://wine.1045685.n5.nabble.com/file/n2805603/patch patch
>
> Thx
> Misha
>
> --
> View this message in context:
> http://wine.1045685.n5.nabble.com/Must-copy-static-const-D3DVERTEXELEMENT9-into-dynamically-alllocated-D3DVERTEXELEMENT9-before-pointe-tp2805603p2805603.html
> Sent from the Wine - Devel mailing list archive at Nabble.com.
>
>
> Hi Misha,
It's currently a stub in wine [1] and tests are using a static const
D3DVERTEXELEMENT9 array as parameter [2] so it should be because of your
modified D3DXCreateMesh implementation which isn't visible in your patch.
[1]
http://source.winehq.org/git/wine.git/?a=blob;f=dlls/d3dx9_36/mesh.c#l586
[2]
http://source.winehq.org/git/wine.git/?a=blob;f=dlls/d3dx9_36/tests/mesh.c#l988
--
Nicolas Le Cam
Re: mmdevapi: Make MMDevice_[GS]etPropValue() static.
2010/8/31 Francois Gouget > On Tue, 31 Aug 2010, Alexandre Julliard wrote: > > > Francois Gouget writes: > > > > > http://source.winehq.org/patches/data/65442 > > > > > > According to http://source.winehq.org/patches/ this patch causes a > build > > > error (or maybe a new warning). However here (gcc 4.4) I see no warning > > > at all. > [...] > > It's an undefined reference, probably you don't have OpenAL so that code > > doesn't get compiled. > > Ah, right, it's MMDevice_GetPropValue() that gets used from audio.c if > OpenAL is supported. And OpenAL is missing because I'm on a Debian 64 > system so there's no package providing the 32bit version :-( > > Does anyone know of 'clean' ways of getting libv4l, libgsm, libmpg123 > and libopenal on a 64bit Debian system? I would try apt-cross but I was > once told that using it to get 32bit libraries on 64bit system was > stupid, not meant to work, etc. > > > -- > Francois Gouget http://fgouget.free.fr/ >Linux: It is now safe to turn on your computer. > > > I don't know of a 'clean' way (and I'm also interested if anyone knows) but, at least, lib32v4l-0 is available for squeeze and sid since early june (it also seems to be in lenny-backports but from the older, now removed, libv4l source package). -- Nicolas Le Cam
Re: jscript: Added support for Function.arguments property.
2010/7/27 Jacek Caban :
> On 7/27/10 12:18 PM, (Marvin) wrote:
>>
>> Hi,
>>
>> While running your changed tests on Windows, I think I found new failures.
>> Being a bot and all I'm not very good at pattern recognition, so I might
>> be
>> wrong, but could you please double-check?
>> Full results can be found at
>> http://testbot.winehq.org/JobDetails.pl?Key=3956
>>
>> Your paranoid android.
>
> This is a problem that I change files in test directory that are stored in
> resources, so Test Bot doesn't know, which test should it run. Can we do
> something about it? There are a few options that come to my mind:
>
> - Add magic keyword that would be present in patch mail telling which tests
> should be ran
> - Detect that the patched file is not a test file and run all tests
> corresponding to dll or ignore the patch
> - Store a map associating such files with tests somewhere
>
> Jacek
>
>
>
If resource files are only used by one testset a simple option could
be to name it like the source file and change the testbot to handle
that :
--- a/lib/WineTestBot/Patches.pm2010-07-27 13:58:41 +0200
+++ b/lib/WineTestBot/Patches.pm2010-07-27 14:10:07 +0200
@@ -102,7 +102,7 @@
my $FileType = "patch$1";
my $BaseName = $2;
my $TestSet = $3;
- if ($TestSet =~ m/^(.*)\.c$/)
+if ($TestSet =~ m/^(.*)\..*$/)
{
$TestSet = $1;
}
--
Nicolas Le Cam
Re: mmio: Wrap TRACE strings with debugstr_a / debugstr_an (try 2)
2010/7/20 Tim Cadogan-Cowper : > Fixes bug 10280 (http://bugs.winehq.org/show_bug.cgi?id=10280). Thanks to > Eric > Pouech for some feedback on previous attempt and to Maarten Lankhorst for > pointing out a more appropriate way to solve the mmio TRACE buffer overflow > problem. > > IDs of the previous attempt and discussion (now redundant) are 63620, 63625 > and > 63725. > > Tim > > Hi Tim, Format specifiers shouldn't be necessary now that you use debugstr_an. -- Nicolas Le Cam
Re: shell32_test64.exe shlexec: 5-6 DDE tests always fail on testbot W7PROX64
2010/7/20 Ilya Basin : > M> VM Status Number of test failures > M> WINEBUILD completed > M> W98SE completed 0 > M> WNT4WSSP6 completed 0 > M> W2KPROSP4 completed 0 > M> WXPPROSP3 completed 0 > M> W2K3R2SESP2 completed 0 > M> WVISTAADM completed 0 > M> W2K8SE completed 0 > M> W7PRO completed 0 > M> W7PROX64 completed 0 > M> W7PROX64 completed 5 > > M> === WINEBUILD (build) === > M> No build failures found > > M> === W98SE (32 bit shlexec) === > M> No test failures found > > M> === WNT4WSSP6 (32 bit shlexec) === > M> No test failures found > > M> === W2KPROSP4 (32 bit shlexec) === > M> No test failures found > > M> === WXPPROSP3 (32 bit shlexec) === > M> No test failures found > > M> === W2K3R2SESP2 (32 bit shlexec) === > M> No test failures found > > M> === WVISTAADM (32 bit shlexec) === > M> No test failures found > > M> === W2K8SE (32 bit shlexec) === > M> No test failures found > > M> === W7PRO (32 bit shlexec) === > M> No test failures found > > M> === W7PROX64 (32 bit shlexec) === > M> No test failures found > > M> === W7PROX64 (64 bit shlexec) === > > M> shell32: > M> shlexec.c:1738: Test failed: ShellExecuteEx(null, > "C:\Users\winetest\AppData\Local\Temp\wt7045.tmp\test file.sde", null, null) > failed: rc=29 err=2 > M> shlexec.c:1738: Test failed: ShellExecuteEx(null, > "C:\Users\winetest\AppData\Local\Temp\wt7045.tmp\test file.sde", null, null) > failed: rc=29 err=2 > M> shlexec.c:1738: Test failed: ShellExecuteEx(null, > "C:\Users\winetest\AppData\Local\Temp\wt7045.tmp\test file.sde", null, null) > failed: rc=29 err=2 > M> shlexec.c:1738: Test failed: ShellExecuteEx(null, > "C:\Users\winetest\AppData\Local\Temp\wt7045.tmp\test file.sde", null, null) > failed: rc=29 err=2 > M> shlexec.c:1738: Test failed: ShellExecuteEx(null, > "C:\Users\winetest\AppData\Local\Temp\wt7045.tmp\test file.sde", null, null) > failed: rc=29 err=2 > > Hi! I sent multiple different patches for shlexec and ever since > W7PROX64 (64 bit shlexec) is used by testbot, 5 DDE tests always fail > on it. I can't reproduce it on local W7PROX64: No shlexec tests fail. > > test.winehq.org has the same problem > http://test.winehq.org/data/d494bda30f1b5b9bc37f094bd8874d3aeeaf8840/win7_wtb-w7prox64-64/shell32:shlexec.html > > Another question: winetest64-latest.exe extracts individual test > binaries to the temp folder and runs them. How do you extract the > binaries without running? > > -- > > > > winetest64-latest.exe -x DIR (use --help or have a look in programs/winetest/main.c to see other possibilities). -- Nicolas Le Cam
Re: configure.ac: Don't try to rm dirs.
2010/6/28 Alexandre Julliard : > Nicolas Le Cam writes: > >> Hi, >> >> This patch allows to do a make clean in a wine tree configured with >> with-wine64 option and fix following errors : >> rm: cannot remove `fonts': Is a directory >> rm: cannot remove `server': Is a directory > > These should be symlinks in a wow64 tree. Probably you didn't start from > a fresh tree. > > -- > Alexandre Julliard > julli...@winehq.org > You're right even if I can't remember creating it so long ago. Sorry for the noise. -- Nicolas Le Cam
Re: How do you make x64 crosstests?
2010/6/26 Austin English : > On Fri, Jun 25, 2010 at 2:49 AM, Ilya Basin wrote: > > Should be install 64-bit mingw, compile wine in 64-bit mode, and run > 'make crosstest'. Though I just tried this on Ubuntu Lucid, and it > fails for me there (configure is looking for > checking for x86_64-pc-mingw32-gcc... no > checking for x86_64-w64-mingw32-gcc... no > > while on Ubuntu, it is: > amd64-mingw32msvc-gcc > > however, it seems compiling with it is broken: > aus...@midna:~/64-wine-git$ amd64-mingw32msvc-gcc foo.c > /usr/lib/gcc/amd64-mingw32msvc/4.4.2/../../../../amd64-mingw32msvc/bin/ld: > cannot find -lgcc > collect2: ld returned 1 exit status > > perhaps someone else has tried and had better luck... > > -- > -Austin > > > For the configure part you could use CROSSCC=amd64-mingw32msvc-gcc to help on debian/ubuntu but I'm stuck with the same problem, it can't find libgcc, although it is installed in /usr/lib/gcc/amd64-mingw32msvc/4.4.4/ by gcc-mingw32 package. I remember seeing documentation on how to build crosstests on the wiki but it seems to have disappeared from it (with a circular reference now between ConformanceTests and MakeTestFailures pages). -- Nicolas Le Cam
Re: Tests for msvcrt
2010/6/24 Paul Chitescu : > Hi! > > What would be the best way of testing MSVCRT.DLL considering that many > functions may or may be not present in the native version? > >> > /* >> > + * getenv_s - not exported in native msvcrt >> > + */ >> > +int CDECL getenv_s(size_t *size, char *buffer, size_t bufLen, const char > *name >> Both getenv_s and _wgetenv_s are exported in native msvcrt. > > In older versions of MSVCRT.DLL (XP and earlier, no idea about Vista) these > functions are not exported. They were added first in Visual Studio 2005 > (MSVCRT80.DLL) and somehow made they way back in MSVCRT. > > Using LoadLibrary / GetProcAddress would fail on all older Windows platforms. > > It would be possible to test MSVCR80 instead but that may not be installed on > the tested system. > > Any thoughts? > > Paul Chitescu > > > > What about loading msvcrt, fallback on loading msvcrt80 and win_skip if you can't find them in both libraries? -- Nicolas Le Cam
Re: Running tests on wine
2010/6/6 Nikolay Sivov : > On 6/6/2010 21:03, GOUJON Alexandre wrote: >> >> Hi, >> >> I would like to do some (typelib) tests on wine. >> >> So I followed the instructions at >> http://www.winehq.org/docs/winedev-guide/testing-wine >> ( cd dlls/oleaut32/tests/ ; rm typelib.ok && make typelib.ok in my case) >> >> but I have err's and fixme's whereas the output on wineTestBot is quite >> different >> >> (http://test.winehq.org/data/9aa9a1229f2195a8b3ac575645a10242ae6e9bc8/wine_nlecam-lap-ub1004-64/oleaut32:typelib.html) > > It's not a test bot, it's a test result uploaded by contributor. >> >> I tried WINETEST_DEBUG=1 make typelib.ok but it's the same output. >> >> Am I missing something ? > > You're running it with make, and a test results are from winetest runs. As I > remember winetest runs it as 'wine oleaut32_tests.exe typelib' with some env > variable to set a platform (this will enable todos output, AFAIK). >> >> Thanks >> >> Results are from a winetest64 test suite running under wine64. If it's the failure on this particular box that you want to debug, just ask, results were sent from my laptop. -- Nicolas Le Cam
Re: wineserver: Fix French manpage
Le 12 avril 2010 11:02, Frédéric Delanoy a écrit : > 2010/4/9 Nicolas Le Cam : >> Le 9 avril 2010 13:30, Frédéric Delanoy a écrit >> : >>> 2010/4/9 Nicolas Le Cam : >>>> Hi Frédéric, >>>> >>>>>+processus clients se sont terminés. Ceci évite le coût inhérent à l'arrêt >>>> sont -> soient >>>> >>>>>+\fIwineserver\fR dans le chemin système ou quelques autres emplacements >>>>>vraisemblables. >>>> "potentiels" or "possibles" suit better. >>>> >>> >>> My understanding was that it looked first in the system path, then >>> tried in, e.g., the home dir or other >>> directories. >>> I guess it looks in a hardcoded list of dirs, or sthg like that. In >>> that sense, "possibles" does not fit IMO. >>> "potentiels" or "vraisemblables" could both fit, but I wanted to >>> insist on the probability for the command >>> to be there (sthg like P[potentiels] < P[vraisemblables]). >>> >>> Frédéric >>> >> It tries PATH and BINDIR (and server/wineserver if in a build >> directory). See >> http://source.winehq.org/git/wine.git/?a=blob;f=libs/wine/config.c#l480 >> So 'potentiels' or 'possibles' fit better IMHO. > > "Probables" may possibly fit even better (altough "potentiels" should be OK)? > > Frédéric > IMHO, "Probables" or "Vraisemblables" mean that it tries randomly some paths and isn't at all certain to succeed, IOW it sounds really weak ; where "Potentiels" or "Possibles" mean that if wineserver can't be found in a fixed number of (logically computed) places, you need to fix your system because you have a problem. I really prefer the second option. -- Nicolas Le Cam
Re: WineTestBot: phase 3 implemented
2010/4/12 Greg Geldorp : > I'm happy to announce that WineTestBot (http://winetestbot.geldorp.nl) is now > actively scanning wine-patches submissions for changes to tests. If it finds > a test change, it will apply the changes, build the affected test executables > and run them on the base VMs. Results will be mailed back to the submitter. > It will also try to determine if new failures were introduced, by comparing > the test results to the most recent run using winetest.exe from WineHQ. If it > thinks there are new failures, a message is sent to the author with a copy to > wine-devel. > > The bot will only process complete series, so it will queue up patches that > appear to be part of a series. Then when the series is complete, it generates > one big patch file by adding all the individual patches from the series > together before submitting it. We'll have to see how robust this is, it is > quite possible to mess up this algorithm. > > Only patches that contain changes to tests are run. It checks to see if any > dlls//tests/* files were changed, if so it is deemed a change to the > tests. This should cover most cases, but again is not 100% correct all the > time (if you only change a file in include/ then the tests depending on the > header files don't get run). In the end we still have the daily run that's > done when Alexandre publishes a new winetest.exe. > > There's a new item in the WineTestBot menu, "Wine-patches". It will show > which patches have been received via the mailing list and what the bot has > done with them. > > Of course, you'll still be able to manually submit a patch to the bot too. > These run at higher priority than the jobs generated from wine-patches > submissions. > > Happy testing, Ge. > > > > Hi Greg, Perhaps you could also check for programs//tests/ now that at least cmd has tests. WineTestBot is a wonderful tool, thanks for supporting and improving it! -- Nicolas Le Cam
Re: wineserver: Fix French manpage
Le 9 avril 2010 13:30, Frédéric Delanoy a écrit : > 2010/4/9 Nicolas Le Cam : >> Hi Frédéric, >> >>>+processus clients se sont terminés. Ceci évite le coût inhérent à l'arrêt >> sont -> soient >> >>>+\fIwineserver\fR dans le chemin système ou quelques autres emplacements >>>vraisemblables. >> "potentiels" or "possibles" suit better. >> > > My understanding was that it looked first in the system path, then > tried in, e.g., the home dir or other > directories. > I guess it looks in a hardcoded list of dirs, or sthg like that. In > that sense, "possibles" does not fit IMO. > "potentiels" or "vraisemblables" could both fit, but I wanted to > insist on the probability for the command > to be there (sthg like P[potentiels] < P[vraisemblables]). > > Frédéric > It tries PATH and BINDIR (and server/wineserver if in a build directory). See http://source.winehq.org/git/wine.git/?a=blob;f=libs/wine/config.c#l480 So 'potentiels' or 'possibles' fit better IMHO. -- Nicolas Le Cam
Re: tools: Add French translation of wineprefixcreate manpage
Le 9 avril 2010 13:23, Frédéric Delanoy a écrit : > Well I thought about putting it in non-infinitive form, but it didn't > sound/feel right to me. > > In fact "N'affiche" would be more like a description, while > "N'afficher" is more an action/modifier/behaviour "alterator" > which seems the purpose of an command-line option IMHO. > > Frédéric > > On Fri, Apr 9, 2010 at 9:25 AM, Nicolas Le Cam wrote: >> Hi Frédéric, >> >>>+N'afficher aucun message de statut. >> It doesn't really matter but as you don't use infinitive form >> elsewhere perhaps "N'affiche" could be better. >> >> Thanks again for your work. >> >> -- >> Nicolas Le Cam >> > What about 'Masque (tous) les messages de statut', that should do the trick. -- Nicolas Le Cam
Re: loader: Fix French translation of wine manpage
Le 9 avril 2010 13:37, Frédéric Delanoy a écrit : > 2010/4/9 Nicolas Le Cam : >> Hi Frédéric, >> >>>+\fIwineserver\fR dans le chemin système ou quelques autres emplacements >>>vraisemblables. >>>[...] >>>+"wine" dans le chemin système ou quelques autres emplacements >>>vraisemblables. >> Even if "likely" literally means "vraisemblable" I think the previous >> use of "potentiel" or even "possible" suits better. > > See my comments in the mail "wineserver: Fix French manpage" >> >>>+n'est spécifiée, le caractère + peut être omis. Notez que les espaces ne >>>sont pas >>>+autorisées dans cette chaîne de caractères. >> Should be "autorisés" > > "espace" is feminine when talking about the typographical sign (cf > http://fr.wikipedia.org/wiki/Espace_typographique). > Now if \t or similar had been relevant in that sentence, it would have > been "caractères d'espacement". Oh didn't know that. Thanks for the explanation. >> >>>+Définit le type de remplacement et l'ordre de chargement des DLL utilisées >>>lors du >>>+processus de chargement d'une DLL. Le comportement par défaut est spécifié >>>dans le >>>+fichier de configuration. Deux types de bibliothèques peuvent actuellement >>>être chargées >>>+dans l'espace d'adressage d'un processus : les DLL natives de >>>+Windows >> Should be "chargés" > > What's loaded? The types or the libraries? I think the latter... It's the "two types of libraries" that can be loaded. -- Nicolas Le Cam
Re: tools: Add French translation of wineprefixcreate manpage
Hi Frédéric, >+N'afficher aucun message de statut. It doesn't really matter but as you don't use infinitive form elsewhere perhaps "N'affiche" could be better. Thanks again for your work. -- Nicolas Le Cam
Re: wineserver: Fix French manpage
Hi Frédéric, >+processus clients se sont terminés. Ceci évite le coût inhérent à l'arrêt sont -> soient >+\fIwineserver\fR dans le chemin système ou quelques autres emplacements >vraisemblables. "potentiels" or "possibles" suit better. -- Nicolas Le Cam
Re: loader: Fix French translation of wine manpage
Hi Frédéric, >+\fIwineserver\fR dans le chemin système ou quelques autres emplacements >vraisemblables. >[...] >+"wine" dans le chemin système ou quelques autres emplacements vraisemblables. Even if "likely" literally means "vraisemblable" I think the previous use of "potentiel" or even "possible" suits better. >+n'est spécifiée, le caractère + peut être omis. Notez que les espaces ne sont >pas >+autorisées dans cette chaîne de caractères. Should be "autorisés" >+Définit le type de remplacement et l'ordre de chargement des DLL utilisées >lors du >+processus de chargement d'une DLL. Le comportement par défaut est spécifié >dans le >+fichier de configuration. Deux types de bibliothèques peuvent actuellement >être chargées >+dans l'espace d'adressage d'un processus : les DLL natives de >+Windows Should be "chargés" Thanks for your work. -- Nicolas Le Cam
Re: [PATCH] user32/tests: check that SetCursorPos doesn't call hooks.
2010/1/21 Lauri Kenttä :
> SetCursorPos should not call mouse low-level hooks.
> ---
> dlls/user32/tests/input.c | 16
> 1 files changed, 16 insertions(+), 0 deletions(-)
>
> diff --git a/dlls/user32/tests/input.c b/dlls/user32/tests/input.c
> index 7713ff6..a5dba06 100644
> --- a/dlls/user32/tests/input.c
> +++ b/dlls/user32/tests/input.c
> @@ -1198,6 +1198,7 @@ static void test_keynames(void)
>
> static POINT pt_old, pt_new;
> static BOOL clipped;
> +static int hook_proc2_call_times;
> #define STEP 3
>
> static LRESULT CALLBACK hook_proc1( int code, WPARAM wparam, LPARAM lparam )
> @@ -1231,6 +1232,8 @@ static LRESULT CALLBACK hook_proc2( int code, WPARAM
> wparam, LPARAM lparam )
> MSLLHOOKSTRUCT *hook = (MSLLHOOKSTRUCT *)lparam;
> POINT pt;
>
> + ++hook_proc2_call_times;
> +
> if (code == HC_ACTION)
> {
> ok(hook->pt.x == pt_new.x && hook->pt.y == pt_new.y,
> @@ -1281,6 +1284,7 @@ static void test_mouse_ll_hook(void)
> HHOOK hook1, hook2;
> POINT pt_org, pt;
> RECT rc;
> + int hook_proc2_call_times_old;
>
> GetCursorPos(&pt_org);
> hwnd = CreateWindow("static", "Title", WS_OVERLAPPEDWINDOW | WS_VISIBLE,
> @@ -1347,6 +1351,18 @@ static void test_mouse_ll_hook(void)
> GetCursorPos(&pt);
> ok(pt.x == pt_new.x && pt.y == pt_new.y, "Position changed: (%d,%d)\n",
> pt.x, pt.y);
>
> + /* Check that SetCursorPos doesn't call hooks.
> + * Check twice: first moving to old coordinates, then to new. */
> + SetCursorPos(10, 10);
> +
> + hook_proc2_call_times_old = hook_proc2_call_times;
> + SetCursorPos(10, 10);
> + ok(hook_proc2_call_times_old == hook_proc2_call_times, "Hooks called\n");
> +
> + hook_proc2_call_times_old = hook_proc2_call_times;
> + SetCursorPos(20, 20);
> + ok(hook_proc2_call_times_old == hook_proc2_call_times, "Hooks called\n");
> +
> UnhookWindowsHookEx(hook2);
> done:
> DestroyWindow(hwnd);
> --
> 1.6.6
>
>
>
>
Hi Lauri,
What about resetting hook_proc2_call_times to 0 before calling
SetCursorPos and just checking if it has changed ?
Also other static variables used in hook procs aren't prefixed, this
is more trivial but everyone is encouraged to follow current code
style of the file.
--
Nicolas Le Cam
Re: d3d8: Fix a ptrdiff_t warning on 64-bit.
2010/1/11 Alexandre Julliard :
> Nicolas Le Cam writes:
>
>> @@ -175,7 +175,7 @@ static DWORD d3d8_allocate_handle(struct
>> d3d8_handle_table *t, void *object, enu
>> entry = t->free_entries;
>> if (entry->type != D3D8_HANDLE_FREE)
>> {
>> - ERR("Handle %u(%p) is in the free list, but has type %#x.\n",
>> (entry - t->entries), entry, entry->type);
>> + ERR("Handle %tu(%p) is in the free list, but has type %#x.\n",
>> (entry - t->entries), entry, entry->type);
>
> Please don't use that kind of printf formats, they are not portable.
>
> --
> Alexandre Julliard
> julli...@winehq.org
>
Sorry about that, I did see a 'C90' mention on an online printf manual
that I can't find anymore (I should have compiled with -pedantic
before submitting).
--
Nicolas Le Cam
Re: Use GCC's -Wlogical-op if possible
2010/1/4 Paul Vriens :
> On 01/03/2010 10:12 PM, Gerald Pfeifer wrote:
>>
>> On Sun, 3 Jan 2010, Austin English wrote:
>>>>
>>>> On my FreeBSD test system I am see no warnings triggered by -Wlogical-op
>>>> any more. How does it look on your side?
>>>
>>> ole32:
>>> usrmarshal.c:485: warning: logical ?&&? with non-zero constant will
>>> always evaluate as true
>>> usrmarshal.c:1098: warning: logical ?&&? with non-zero constant will
>>> always evaluate as true
>>> usrmarshal.c:1290: warning: logical ?&&? with non-zero constant will
>>> always evaluate as true
>>>
>>> oleaut32:
>>> variant.c:2090: warning: logical ?||? with non-zero constant will
>>> always evaluate as true
>>> variant.c:2090: warning: logical ?&&? with non-zero constant will
>>> always evaluate as true
>>>
>>> comctl32/tests:
>>> tab.c:520: warning: logical ?&&? with non-zero constant will always
>>> evaluate as true
>>> tab.c:540: warning: logical ?&&? with non-zero constant will always
>>> evaluate as true
>>> tab.c:563: warning: logical ?&&? with non-zero constant will always
>>> evaluate as true
>>> tab.c:978: warning: logical ?&&? with non-zero constant will always
>>> evaluate as true
>>
>> I had a patch for this one (comctl32/tests) which I received feedback on
>> and need to brush up. I should be able to do so coming week. Anybody
>> volunteering to look into the other ones?
>>
>>> kernel32/tests:
>>> atom.c:70: warning: logical ?||? with non-zero constant will always
>>> evaluate as true
>>
>> Gerald
>
> The attached is what I have on my F12 box (gcc 4.4.2 20091222):
>
> --
> Cheers,
>
> Paul.
>
>
>
>
Most of them are false positives because of a problem between gcc
4.{3,4}.x and the strchr being defined as a macro in libc, see gcc bug
#36513 [1]. My karmic box seems to output the same.
[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36513
--
Nicolas Le Cam
Re: Conformance tess for cmd?
2009/12/19 Eric Pouech : > Dan Kegel a écrit : >> >> On Fri, Dec 18, 2009 at 11:50 PM, Eric Pouech >> wrote: >> >>> >>> If you want to control more closely commands vs output you can toy with >>> http://github.com/ericZp/wdtp/blob/master/test_cl.h >>> >> >> I would have thought that overkill for a batch mode program like cmd, >> but it appears to have several interactive commands: >> pause >> choice >> set /p >> so yeah, something like that will be needed. >> >> Then there's the question of how to integrate it into the wine >> test suite. I suspect the way to go is >> to have a make rule that converts the input and expected output >> files into hex byte arrays in a generated .c file, >> to use the normal wine test infrastructure by copying >> dlls/Maketest.rules.in to programs/Maketest.rules.in >> >> Sound good? >> >> >> > > the idea of test_cl.h is to have something similar to our test suite, but > for command line programs > so you can still have the ok() rules, the only thing that test_cl.h does is > to give helpers to drive the program to be tested, and simplify sending > commands and fetching their output > > but, of course, you need first to allow test Make rules to be allowed in > programs/ subdirectory > A+ > > -- > Eric Pouech > "The problem with designing something completely foolproof is to > underestimate the ingenuity of a complete idiot." (Douglas Adams) > What about redirecting io pipes and use CreateProcess ? msdn has some examples : http://msdn.microsoft.com/en-us/library/ms682499%28VS.85%29.aspx -- Nicolas Le Cam
Re: mapi32: add French translation
Hi Frédéric, Using "absence" and "installé" in the same sentence doesn't sound right. Something like "L'envoi de courriel a échoué car vous n'avez pas de client mail MAPI installé." or "L'envoi de courriel a échoué du fait de l'absence de client mail MAPI." should be simpler and more correct. -- Nicolas Le Cam
Re: shdocvw: Fix test for non-english IE MUI (try 2)
2009/12/11 Alistair Leslie-Hughes : > Hi, > > > Changelog: > shdocvw: Fix test for non-english IE MUI > > Best Regards > Alistair Leslie-Hughes > > > > Hi Alistair, -ok(!strcmp_wa(sName, "Microsoft Web Browser Control"), "got '%s', expected 'Microsoft Web Browser Control'\n", wine_dbgstr_w(sName)); +if (PRIMARYLANGID(LANGIDFROMLCID(GetThreadLocale())) == LANG_ENGLISH) +ok(!strcmp_wa(sName, "Microsoft Web Browser Control"), "got '%s', expected 'Microsoft Web Browser Control'\n", wine_dbgstr_w(sName)); +else /* Non-English cannot be blant. */ +ok(sName!=NULL, "get_Name return a NULL string.\n"); Did you mean blank ? -- Nicolas Le Cam
Re: My script for doing testing
2009/11/25 Austin English : > On Wed, Nov 25, 2009 at 4:45 PM, Marcus Meissner > wrote: >> On Wed, Nov 25, 2009 at 05:21:30PM -0500, Steven Edwards wrote: >>> On Wed, Nov 25, 2009 at 12:08 PM, Austin English >>> wrote: >>> > The other neat thing is that it will run git fetch in a loop every 30 >>> > minutes (again, overridable), so that you can run it in the morning >>> > while waiting for AJ to commit. Once commits are made to the git >>> > master branch (but not stable), the script will kick into motion. >>> >>> It would be nice to dummy email account subscribed to the commit >>> messages that it could poll to trigger the checkout, build, test >>> cycle. >>> >>> To make a Continuous Integration Service around it it should run as a >>> background process under another user out of init in a Xnest/VNC >>> session. I am thinking something like a winecis user which would run >>> these scripts, fetch and the Xnest session as a service we could call >>> winecis. >>> >>> I did something similar recently for a stupid java service that had to >>> have an interactive gui. >> >> As AJ is pushing just once a day you can also run your fetch script >> once a day... Perhaps triggered by a commit mail. > > Sure, that would be an option if the system has e-mail configured, but > since I use webmail, I went with the 'sit and wait' method. For other > projects that script would obviously need a different strategy (though > I don't other projects are running winetest.exe daily ;-)). > > -- > -Austin > > > You could watch http://test.winehq.org/builds/ to see if there is any update (a push is followed by a test build). -- Nicolas Le Cam
Re: shell32/tests: Fix Program Manager DDE Conformance Test Failures
2009/11/15 Mikey Alexander : > You really don't want to skip this one as the api is supposed to create the > window, but you can't be absolutely sure it is a failure, hence the error > message being what it is. If you are going to skip the timeout if it fails, > why bother checking for the window creation at all? > > The real question is what is the real worst case expected time to wait before > failing because the window was not created? I upped it to 45 seconds. > > I could have implemented a window message thread to detect the window > creation, but it doesn't change the problem. Window creation is not given a > deadline. 10 seconds was obviously too short. Several machines failed on > the first longer load with 10 seconds and a couple failed most of the > timeouts with 10 seconds. > > I'd be more than willing to up the timeout longer, but if you really do > encounter a failure, it makes the failed test take that much longer. > > - Mikey > I think you misunderstood me. The window is created but as you're searching for a "Startup" window's title it fails on localized systems. So the test is not completely correct and only work on English system. That's why I proposed to skip the two tests on (and only on) such systems. I'll try to use a window message thread to see if it helps. PS: Please bottom post on wine-devel -- Nicolas Le Cam
Re: shell32/tests: Fix Program Manager DDE Conformance Test Failures
2009/11/14 Mikey Alexander : > Fixes a memory leak, non connection to the progman dde on early windows, and > timeout problems with the conformance tests. > > --- > dlls/shell32/tests/progman_dde.c | 25 + > 1 files changed, 17 insertions(+), 8 deletions(-) > Hi Mikey, There's also a test failure on localized Windows (see http://test.winehq.org/data/8a17a028b73d1ccc5b7ebaa9e135a1bfbf159615/2000_w2k-sp4-fr/shell32:progman_dde.html for example) because the window doesn't have the expected title. I tried to skip the ShowGroupTest call at line 510 (before your patch) but then the next call fails. Is there a better solution than skipping those two calls ? If not I'll just send a skipping patch. -- Nicolas Le Cam
Re: (retry) msctf/tests: handle an occassional unexpected SetFocus from wine
2009/11/7 Aric Stewart :
> ---
> dlls/msctf/tests/inputprocessor.c | 7 +--
> 1 files changed, 5 insertions(+), 2 deletions(-)
>
Here are the results for 100 consecutive runs :
$ for i in {1..100}; do wine msctf_test.exe.so >> msctf_tests.log 2>&1; done
$ grep "tests executed" msctf_tests.log | sort | uniq -c | sort -nr
77 inputprocessor: 230 tests executed (0 marked as todo, 0
failures), 0 skipped.
18 inputprocessor: 231 tests executed (0 marked as todo, 3
failures), 0 skipped.
3 inputprocessor: 234 tests executed (0 marked as todo, 4
failures), 0 skipped.
1 inputprocessor: 238 tests executed (0 marked as todo, 8
failures), 0 skipped.
1 inputprocessor: 236 tests executed (0 marked as todo, 6
failures), 0 skipped.
I also did try to sleep between tests in case it could help but it
doesn't seem so :
$ for i in {1..100}; do wine msctf_test.exe.so >> msctf_tests.log
2>&1; sleep 1; done
$ grep "tests executed" msctf_tests.log | sort | uniq -c | sort -nr
78 inputprocessor: 230 tests executed (0 marked as todo, 0
failures), 0 skipped.
17 inputprocessor: 231 tests executed (0 marked as todo, 3
failures), 0 skipped.
3 inputprocessor: 238 tests executed (0 marked as todo, 8
failures), 0 skipped.
2 inputprocessor: 236 tests executed (0 marked as todo, 6
failures), 0 skipped.
For info, here is a run without your patch.
$ for i in {1..100}; do wine msctf_test.exe.so >> msctf_tests.log
2>&1; sleep 1; done
$ grep "tests executed" msctf_tests.log | sort | uniq -c | sort -nr
64 inputprocessor: 230 tests executed (0 marked as todo, 0
failures), 0 skipped.
18 inputprocessor: 236 tests executed (0 marked as todo, 4
failures), 0 skipped.
12 inputprocessor: 237 tests executed (0 marked as todo, 7
failures), 0 skipped.
3 inputprocessor: 234 tests executed (0 marked as todo, 4
failures), 0 skipped.
2 inputprocessor: 236 tests executed (0 marked as todo, 6
failures), 0 skipped.
1 inputprocessor: 238 tests executed (0 marked as todo, 8
failures), 0 skipped.
If you need me to do more tests, just ask, I'm willing to go green ;)
--
Nicolas Le Cam
Re: msctf/tests: handle an occassional unexpected SetFocus from wine
2009/11/7 Aric Stewart : > --- > dlls/msctf/tests/inputprocessor.c | 5 - > 1 files changed, 4 insertions(+), 1 deletions(-) > > > > > > Aric, is this for my versatile machine ? -- Nicolas Le Cam
Re: mshtml/tests: Fix events test when pointer is on a corner.
2009/10/30 Jacek Caban :
> Hi Nicolas,
>
> Nicolas Le Cam wrote:
>>
>> Hi Jacek,
>>
>> Thanks for feedback.
>> It should handle pointer in every corners IMHO, the left corner can
>> cause failures in winetest.
>>
>> I'll try to find a better solution. Do you have any hints ?
>>
>
> The test in line 472 is invalid. It looks like all we can do is check if
> get_x returned something. I'd suggest to set l to 0xdeadbeef before get_x
> call and test that the value has changed (ok(x != 0xdeadbeef, ...)). That's
> all we can do. The same applies to get_client[XY] and get_offset[XY] tests.
>
>
> Thanks,git br
> Jacek
>
>
Hi Jacek,
I did what you've suggested (patch's attached for reference) but I
don't think it's the right solution.
Test passes on Wine and Windows with such a patch, but we're now
ignoring the fact that values are completely different on Wine (only
-1 and 0) and Windows (cursor's position relative to something).
I'm trying to find a way to compare values against results from
GetCursorPos and friends. What do you think about that, could that be
a solution ?
Thanks,
Nicolas Le Cam
From f8a5e03e8ac228e0ad22af07d4bb3e5a9853a9a5 Mon Sep 17 00:00:00 2001
From: Nicolas Le Cam
Date: Sat, 31 Oct 2009 14:31:41 +0100
Subject: mshtml/tests: Fix events test when pointer is on a corner.
---
dlls/mshtml/tests/events.c | 40
1 files changed, 16 insertions(+), 24 deletions(-)
diff --git a/dlls/mshtml/tests/events.c b/dlls/mshtml/tests/events.c
index 9d23775..d781e00 100644
--- a/dlls/mshtml/tests/events.c
+++ b/dlls/mshtml/tests/events.c
@@ -65,7 +65,6 @@ DEFINE_EXPECT(timeout);
static HWND container_hwnd = NULL;
static IHTMLWindow2 *window;
static IOleDocumentView *view;
-static BOOL xy_todo;
typedef struct {
LONG x;
@@ -466,10 +465,11 @@ static void _test_event_x(unsigned line, IHTMLEventObj
*event, LONG exl)
LONG l;
HRESULT hres;
+l = 0xdeadbeef;
hres = IHTMLEventObj_get_x(event, &l);
ok_(__FILE__,line)(hres == S_OK, "get_x failed: %08x\n", hres);
if(exl == -10) /* don't test the exact value */
-todo_wine ok_(__FILE__,line)(l > 0, "x = %d\n", l);
+ok_(__FILE__,line)(l != 0xdeadbeef, "x = %d\n", l);
else
ok_(__FILE__,line)(l == exl, "x = %d, expected %d\n", l, exl);
}
@@ -479,10 +479,11 @@ static void _test_event_y(unsigned line, IHTMLEventObj
*event, LONG exl)
LONG l;
HRESULT hres;
+l = 0xdeadbeef;
hres = IHTMLEventObj_get_y(event, &l);
ok_(__FILE__,line)(hres == S_OK, "get_y failed: %08x\n", hres);
if(exl == -10) /* don't test the exact value */
-todo_wine ok_(__FILE__,line)(l > 0, "y = %d\n", l);
+ok_(__FILE__,line)(l != 0xdeadbeef, "y = %d\n", l);
else
ok_(__FILE__,line)(l == exl, "y = %d, expected %d\n", l, exl);
}
@@ -492,13 +493,11 @@ static void _test_event_clientx(unsigned line,
IHTMLEventObj *event, LONG exl)
LONG l;
HRESULT hres;
+l = 0xdeadbeef;
hres = IHTMLEventObj_get_clientX(event, &l);
ok_(__FILE__,line)(hres == S_OK, "get_clientX failed: %08x\n", hres);
if(exl == -10) {/* don't test the exact value */
-if(xy_todo)
-todo_wine ok_(__FILE__,line)(l > 0, "clientX = %d\n", l);
-else
-ok_(__FILE__,line)(l > 0, "clientX = %d\n", l);
+ok_(__FILE__,line)(l != 0xdeadbeef, "clientX = %d\n", l);
}else {
ok_(__FILE__,line)(l == exl, "clientX = %d, expected %d\n", l, exl);
}
@@ -509,13 +508,11 @@ static void _test_event_clienty(unsigned line,
IHTMLEventObj *event, LONG exl)
LONG l;
HRESULT hres;
+l = 0xdeadbeef;
hres = IHTMLEventObj_get_clientY(event, &l);
ok_(__FILE__,line)(hres == S_OK, "get_clientY failed: %08x\n", hres);
if(exl == -10) {/* don't test the exact value */
-if(xy_todo)
-todo_wine ok_(__FILE__,line)(l > 0, "clientY = %d\n", l);
-else
-ok_(__FILE__,line)(l > 0, "clientY = %d\n", l);
+ok_(__FILE__,line)(l != 0xdeadbeef, "clientY = %d\n", l);
}else {
ok_(__FILE__,line)(l == exl, "clientY = %d, expected %d\n", l, exl);
}
@@ -526,10 +523,11 @@ static void _test_event_offsetx(unsigned line,
IHTMLEventObj *event, LONG exl)
LONG l;
HRESULT hres;
+l = 0xdeadbeef;
hres = IHTMLEventObj_get_offsetX(event, &l);
ok_(__FILE__,line)(hres == S_OK, "get_offsetX failed: %08x\n", hres);
if(exl == -10) /* don't test the exact value */
-todo_wine ok_(__FILE__,line)(l > 0, "offsetX = %d\n&
Re: mshtml/tests: Fix events test when pointer is on a corner.
2009/10/30 Jacek Caban : > Hi Nicolas, > > Nicolas Le Cam wrote: >> >> Hi, >> >> Since commit 8272ecd3f2235b923f2ec67bb51d051bdfbf466f I'm having >> errors on events tests. >> >> I just found that it only fails if pointer is on any corner. As I'm >> always putting it on upper right corner when running winetest it was >> always failing for me. >> >> Minimizing the test window fixed it for me. >> Tested on Win2k SP4 and WinXP SP2 (both with IE6). >> > > Minimizing window changes what we test and will break test interactive mode. > We should change tests to accept cursor in left corner. > > > Thanks, > Jacek > > > Hi Jacek, Thanks for feedback. It should handle pointer in every corners IMHO, the left corner can cause failures in winetest. I'll try to find a better solution. Do you have any hints ? -- Nicolas Le Cam
Re: kernel32/tests: add more tests for Formatmessage{A,W} (try 2)
2009/10/30 Paul Vriens : > On 10/29/2009 01:09 AM, Louis Lenders wrote: >> >> changes: >> >> -fixed typo in ok-call >> -removed FormatMessageW-tests (W behaves same as A) >> -removed useless test for GetLastError in case FormatMessageA succeeds >> >> > > Hi Louis, > > These new tests introduce some test failures on several platforms: > > http://test.winehq.org/data/tests/kernel32:format_msg.html > > On Win9x/WinMe it seems like just another last error. > > There seems to be an issue with a particular test when run on a Windows box > with no English locale (or something different about the locale): > > http://test.winehq.org/data/1be99033b1892aa59589e7997f4c5a0ce77e2b42/2000_w2k-sp4-fr/kernel32:format_msg.html > > On Vista/Win7/W2K8 there are also different last errors but some are not yet > defined in our headers: > > 15100 : ERROR_MUI_FILE_NOT_FOUND > 15105 : ERROR_MUI_FILE_NOT_LOADED > > Could you have a look? > > -- > Cheers, > > Paul. > > > w2k-sp4-fr has French locale. I didn't have time to investigate right now but if you need more tests just ask. -- Nicolas Le Cam
[RFC] mshtml/tests: Fix events test when pointer is on a corner.
Hi, Since commit 8272ecd3f2235b923f2ec67bb51d051bdfbf466f I'm having errors on events tests. I just found that it only fails if pointer is on any corner. As I'm always putting it on upper right corner when running winetest it was always failing for me. Minimizing the test window fixed it for me but I'm not sure it's the right fix, so I'm sending it to wine-devel. Tested on Win2k SP4 and WinXP SP2 (both with IE6). -- Nicolas Le Cam From 27f127c3e61fa7108f13b7582875681a39b752c6 Mon Sep 17 00:00:00 2001 From: Nicolas Le Cam Date: Tue, 27 Oct 2009 19:05:47 +0100 Subject: mshtml/tests: Fix events test when pointer is on a corner. --- dlls/mshtml/tests/events.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/dlls/mshtml/tests/events.c b/dlls/mshtml/tests/events.c index 9d23775..ebff925 100644 --- a/dlls/mshtml/tests/events.c +++ b/dlls/mshtml/tests/events.c @@ -1608,7 +1608,7 @@ static HWND create_container_window(void) RegisterClassExA(&wndclass); return CreateWindowA(szHTMLDocumentTest, szHTMLDocumentTest, -WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT, +WS_OVERLAPPEDWINDOW | WS_ICONIC, CW_USEDEFAULT, CW_USEDEFAULT, 300, 300, NULL, NULL, NULL, NULL); } -- 1.6.3.3
Re: [1/2] user32/tests/cursoricon.c: DrawState: New Testcase for correct drawing of Icons
2009/10/1 Wilfried Pasquazzo : > [1/2] New Testcase to check if DrawState() behaves correctly when drawing > Icons. > > affected files: dlls/user32/tests/cursoricon.c > > Currently checks: > > - if the Icons are drawn at the correct size. Should always be the > original icon size, > independent of the width and height parameters passed to DrawState(). > - if Icons without a bit-mask are drawn with correct color. > - if Icons with a bit-mask are drawn with correct color. > > Test is successful in WindowsXP SP2, but fails in git-Wine, because > the Icons are > drawn too big. > > > > [2/2] Make Wine pass the new Testcase and Fix Regression Bug 20153 > > affected files: dlls/user32/uitools.c > > Make DrawState() use the Icon dimensions when drawing. This makes it pass all > in [1/2] implemented tests and fixes regression > http://bugs.winehq.org/show_bug.cgi?id=20153 . The width and height, that are > passed to UITOOLS_DrawStateJam() are taken directly from the icon that is to > be > drawn (see implementation of UITOOLS_DrawState()), therefore it is correct to > simply use them as the target drawing dimensions. > > Note: This fix was sent before without the testcase (see > http://www.winehq.org/pipermail/wine-patches/2009-September/078927.html), > but not committed. Didn't get feedback on that, so I guessed the reason was > the > missing testcase. > > > > Feedback is welcome! > > Wilfried Pasquazzo > > PS: When this gets committed, I can add other tests for DrawState(), > to e.g. test for > correct drawing of the "Disabled" effect. > > > > Hi Wilfried, If test fails on Wine, mark them todo_wine. -- Nicolas Le Cam
Re: cppcheck sept 18 redux
2009/9/22 Luke Benstead :
> 2009/9/22 Ben Klein :
>> 2009/9/22 Vitaliy Margolen :
>>> Mike Kaplinskiy wrote:
>>>> It actually does not dereference anything. Try passing null into the
>>>> function - it will work just fine. This is a special case because the
>>>> array isn't dynamically allocated but is part of the struct, which
>>>> means that dmW->dmFormName == (dmW+__offset of dmFormName) and not
>>>> *(dmW+__offset of dmFormName). You can try writing a test program
>>>> yourself - it will run just fine.
>>> It does dereference the pointer. Here is your simple test. Compile it and
>>> run it. See what happens.
>>>
>>> #include
>>>
>>> typedef struct _s_test
>>> {
>>> void *pointer;
>>
>> No. Array, not pointer. E.g.:
>> int array[1];
>>
>>> } s_test;
>>
>>
>>
>
> If it IS the case that this doesn't cause a crash and is perfectly
> valid, can someone explain to me how/why this works? Or point me (no
> pun intended) to the bit in the C spec that explains it? Coz the way I
> read it, it has to dereference dmW, otherwise how would the compiler
> find the address of the array? ... so confused :)
>
> Luke.
>
>
>
Luke,
Wine's current code is basically equivalent to the one above, where
there's no dereference :
#include
typedef struct _s_test
{
char pointer[5];
} s_test;
int main()
{
s_test *s = NULL;
long diff = (const char*)(&s->pointer[0]) - (const char*)s;
printf("diff=%ld\n", diff);
return 0;
}
--
Nicolas Le Cam
Re: cppcheck Sept 18
2009/9/19 Joris Huizer > [/home/cahrendt/wine-git/dlls/wineps.drv/init.c:270]: (error) Possible > null pointer dereference: dmW - otherwise it is redundant to check if > dmW is null at line 272 > > That is a bug, sent a patch > > HTH, > > Joris > Joris, As explained in a previous mail, there's no bug and the code is perfectly valid. Even if you send a patch to please cppcheck, you should report it as being a false positive. Chris, Please try to filter out those lines, they were already there in your previous reports. -- Nicolas Le Cam
Re: Sept 11 with tools and tests removed
2009/9/12 Mike Kaplinskiy : > On Sat, Sep 12, 2009 at 11:24 AM, Mike Kaplinskiy > wrote: >> On Sat, Sep 12, 2009 at 11:19 AM, Nicolas Le Cam >> wrote: >>> 2009/9/12 chris ahrendt : >>>> >>>> Here is the run for Friday Sept. 11 with the tools and the tests >>>> directory results removed. >>>> >>>> >>>> [/home/cahrendt/wine-git/dlls/ntdll/server.c:802]: (error) Resource leak: >>>> fd >>>> [/home/cahrendt/wine-git/dlls/ntdll/server.c:882]: (error) Resource >>>> leak: fd_cwd >>>> [/home/cahrendt/wine-git/dlls/wineps.drv/init.c:270]: (error) Possible >>>> null pointer dereference: dmW - otherwise it is redundant to check if >>>> dmW is null at line 272 >>>> >>>> >>>> Chris >>>> >>>> >>> Hi Chris, >>> >>> All false positives, you can filter them. >>> >>> >>> -- >>> Nicolas Le Cam >>> >>> >>> >> >> They're not false positives. The first one may be (tell cppcheck guys >> that if we're calling exit on all paths, we shouldn't bother to free >> resources), but the next few aren't. >> >> fd_cwd is leaked if server connection fails, >> the bug in wineps is very real, we deref before we check for null on >> the next line. >> >> Mike. >> > > Sorry, sent a little too quickly, the fd_cwd case being leaked is also > the same exit false positive. You can ignore these two for next time. > > Mike. > Last one is also a false positive, it's just two pointers being subtracted to retrieve an offset. -- Nicolas Le Cam
Re: Sept 11 with tools and tests removed
2009/9/12 chris ahrendt : > > Here is the run for Friday Sept. 11 with the tools and the tests > directory results removed. > > > [/home/cahrendt/wine-git/dlls/ntdll/server.c:802]: (error) Resource leak: fd > [/home/cahrendt/wine-git/dlls/ntdll/server.c:882]: (error) Resource > leak: fd_cwd > [/home/cahrendt/wine-git/dlls/wineps.drv/init.c:270]: (error) Possible > null pointer dereference: dmW - otherwise it is redundant to check if > dmW is null at line 272 > > > Chris > > Hi Chris, All false positives, you can filter them. -- Nicolas Le Cam
Re: CPPCheck for Sept 8th
2009/9/9 chris ahrendt : > Nicolas Le Cam wrote: >> 2009/9/9 Alexandre Julliard : >>> chris ahrendt writes: >>> >>>> [/home/cahrendt/wine-git/dlls/ntdll/directory.c:2339]: (error) Resource >>>> leak: old_cwd >>> This is the only one that looks a real bug, all the rest are false >>> positives. Please filter them out from future reports. >>> >>> -- >>> Alexandre Julliard >>> julli...@winehq.org >>> >>> >>> >> >> Not necessary false positives. Errors in dlls/msvcrt/tests/file.c, for >> example, are real but expected errors, as it's the purpose of the test >> to see how it behaves on Windows in such situation. >> > > So continue to send everything then? > Since I have been running them the size has not really been that > large... just let me know what you want me to send and I will > send it in... > > Chris > This was just a clarification so that you won't report everything as false positives to cppcheck devs, only real ones : [/home/cahrendt/wine-git/dlls/msvcrt/tests/heap.c:433]: (possible error) Memory leak: mem [/home/cahrendt/wine-git/dlls/rpcrt4/tests/server.c:1189]: (possible error) Array index out of bounds [/home/cahrendt/wine-git/dlls/wineps.drv/init.c:270]: (error) Possible null pointer dereference: dmW - otherwise it is redundant to check if dmW is null at line 272 [/home/cahrendt/wine-git/dlls/ntdll/server.c:802]: (error) Resource leak: fd [/home/cahrendt/wine-git/dlls/ntdll/server.c:882]: (error) Resource leak: fd_cwd IMHO, those are potential leaks : [/home/cahrendt/wine-git/dlls/wineoss.drv/mmaux.c:146]: (error) Resource leak: mixer [/home/cahrendt/wine-git/dlls/wineoss.drv/mmaux.c:208]: (error) Resource leak: mixer Basically, filter out everything except the one Alexandre pointed out. You can also exclude tools and tests subdirectories. -- Nicolas Le Cam
Re: CPPCheck for Sept 8th
2009/9/9 Alexandre Julliard : > chris ahrendt writes: > >> [/home/cahrendt/wine-git/dlls/ntdll/directory.c:2339]: (error) Resource >> leak: old_cwd > > This is the only one that looks a real bug, all the rest are false > positives. Please filter them out from future reports. > > -- > Alexandre Julliard > julli...@winehq.org > > > Not necessary false positives. Errors in dlls/msvcrt/tests/file.c, for example, are real but expected errors, as it's the purpose of the test to see how it behaves on Windows in such situation. -- Nicolas Le Cam
Re: More winehq.org improvements and issues: About page now links to articles in the wiki
2009/8/4 Francois Gouget : > * Shouldn't we have a way to switch between languages? Hi François, You can switch between languages on home page. Link "Français (Changez la langue)" (which IMHO should be Changer la langue) is below the left blank square. It could be a good idea to duplicate this possibility on every pages. -- Nicolas Le Cam
Re: [2/2] comdlg32/tests: Fix a failing test on Win2k and above.
2009/8/4 Paul Vriens : > Nicolas Le Cam wrote: >> >> Hi, >> >> Following Rein's commit 1f825a3631c78ac08383dd6062005526fc9c483d I've >> got a new failure on my Win2k box. >> >> I did a first patch to filter Win2k failure that happens on >> GetSaveFileNameW case only but, according to test.winehq.org, Win9x >> boxes are failing on more cases so I did a more general (and simple) >> fix. >> >> -- >> Nicolas Le Cam >> >> >> >> >> > Hi Nicolas, > > Judging by the results on test.winehq.org I'd say that W2K and below (except > ME) fails these tests (and there is even a Win95 box that doesn't fail so it > seems). > > I guess just changing that comment should do the trick, not? > > -- > Cheers, > > Paul. > Utch, I'll change that, sorry. -- Nicolas Le Cam
Re: Testers on windows needed
2009/7/28 Stefan Leichter :
> Hello,
>
> i'm looking for some good souls testing the attached patch one windows.
>
> While looking for bug 7701 i found that the function __vbaNew2 of the
> MSVBVM60.dll does not like return values from SHGetFileInfoA bigger than
> 0x7fff
>
> Can you please report at least the results of the trace statements and if any
> modified test fails for you, the console output is fine for me too.
>
> Thanks for your help
> Stefan
>
>
>
>
Hi Stefan, here are the results on my boxes.
French 2K SP4 :
shlfileop.c:192: SHGetFileInfoA('') 1
shlfileop.c:229: SHGetFileInfoA(c:\nonexistent) 1
shlfileop.c:251: SHGetFileInfoA(c:\nonexistent) 1
shlfileop.c:270: SHGetFileInfoA(C:\WINNT\system32\notepad.exe) 1
shlfileop.c:277: SHGetFileInfoA(C:\WINNT\system32\notepad.exe) 1
shlfileop.c:292: SHGetFileInfoA(test4.txt) 1
shlfileop.c:299: SHGetFileInfoA(test4.txt) 1
shlfileop.c:313: SHGetFileInfoA(c:\) 1
shlfileop: 622 tests executed (0 marked as todo, 0 failures), 0 skipped.
French XP SP3 :
shlfileop.c:192: SHGetFileInfoA('') 1
shlfileop.c:229: SHGetFileInfoA(c:\nonexistent) 1
shlfileop.c:251: SHGetFileInfoA(c:\nonexistent) 1
shlfileop.c:270: SHGetFileInfoA(C:\WINDOWS\system32\notepad.exe) 1
shlfileop.c:277: SHGetFileInfoA(C:\WINDOWS\system32\notepad.exe) 1
shlfileop.c:292: SHGetFileInfoA(test4.txt) 1
shlfileop.c:299: SHGetFileInfoA(test4.txt) 1
shlfileop.c:313: SHGetFileInfoA(c:\) 1
shlfileop: 622 tests executed (0 marked as todo, 0 failures), 0 skipped.
No new failures on root drive directories or network directories.
--
Nicolas Le Cam
Re: Create our own temp directory to make sure it's not the Windows directory.
2009/7/24 Paul Vriens : > Paul Vriens wrote: >> >> Nicolas Le Cam wrote: >>> >>> 2009/7/24 Paul Vriens : >>>> >>>> Nicolas Le Cam wrote: >>>>> >>>>> 2009/7/24 Paul Vriens : >>>>>> >>>>>> Hi Alexandre, >>>>>> >>>>>> This one introduced a test failure on several W2K, XP and W2K3 boxes. >>>>>> No >>>>>> idea why (yet) though. >>>>>> >>>>>> -- >>>>>> Cheers, >>>>>> >>>>>> Paul. >>>>>> >>>>>> >>>>>> >>>>> Hi Paul, Alexandre, >>>>> >>>>> It seems to only be a short vs long pathname problem. >>>>> >>>>> >>>> But where? There doesn't seem to be much difference in the tmpdir >>>> variable >>>> before or after this patch (both short pathname, with the one after the >>>> patch being slightly longer of course). >>>> >>>> -- >>>> Cheers, >>>> >>>> Paul. >>>> >>> I will have a look at it this evening as one of the failing boxes is >>> mine. >>> Perhaps GetTempFileName is now returning a short path to not override >>> MAX_PATH characters. >>> >> My W2K fails as well, so I'm able to test something. >> >> From test.winehq.org one can see that this test only seems to fail for >> boxes with a TMP/TEMP variable that's converted to a short notation (see the >> kernel32/path tests for that). >> >> Adding a "GetLongPathName(filename, filename, MAX_PATH);" hack just before >> the failing test fixes the failure. >> >> So, for some reason this test now fails whereas before it would succeed >> and the differences between before and after the patch are not that big. >> > Looks like there is a behavior changes somewhere when double backslashes are > involved. > > This fixes the issue on my W2K box: > > diff --git a/dlls/shell32/tests/shlexec.c b/dlls/shell32/tests/shlexec.c > index 5f0776a..0b06154 100644 > --- a/dlls/shell32/tests/shlexec.c > +++ b/dlls/shell32/tests/shlexec.c > @@ -1527,6 +1527,7 @@ static void init_test(void) > DeleteFileA( tmpdir ); > rc = CreateDirectoryA( tmpdir, NULL ); > ok( rc, "failed to create %s err %u\n", tmpdir, GetLastError() ); > + lstrcatA(tmpdir, "\\"); > rc = GetTempFileNameA(tmpdir, "wt", 0, child_file); > assert(rc != 0); > init_event(child_file); > > This is not a fix as it will introduce the issue with the double backslashes > on Win95 again. > > -- > Cheers, > > Paul. > You were right, IShellLinkA_SetPath's behavior changes when double backslashes are involved. Traces before Alexandre's patch : shlexec.c:996: filename: 'C:\DOCUME~1\nlecam\LOCALS~1\Temp\\test file.shlexec' shlexec.c:998: argvA4: 'C:\DOCUME~1\nlecam\LOCALS~1\Temp\test file.shlexec' and after : shlexec.c:996: filename: 'C:\DOCUME~1\nlecam\LOCALS~1\Temp\wt2.tmp\test file.shlexec' shlexec.c:998: argvA4: 'C:\Documents and Settings\nlecam\Local Settings\Temp\wt2.tmp\test file.shlexec' Before this patch the created link was having a double backslashes in its path and IShellLinkA_SetPath was only removing one of them (and StrCmpPath was handling the backslashes differences). Now that the path is completely valid, IShellLinkA_SetPath seems to save it as a long pathname. I will add tests for IShellLinkA_SetPath with short pathes and double backslashes and fix this one with a call to GetLongPathName on tmpdir. -- Nicolas Le Cam
Re: Create our own temp directory to make sure it's not the Windows directory.
2009/7/24 Paul Vriens : > Nicolas Le Cam wrote: >> >> 2009/7/24 Paul Vriens : >>> >>> Hi Alexandre, >>> >>> This one introduced a test failure on several W2K, XP and W2K3 boxes. No >>> idea why (yet) though. >>> >>> -- >>> Cheers, >>> >>> Paul. >>> >>> >>> >> Hi Paul, Alexandre, >> >> It seems to only be a short vs long pathname problem. >> >> > But where? There doesn't seem to be much difference in the tmpdir variable > before or after this patch (both short pathname, with the one after the > patch being slightly longer of course). > > -- > Cheers, > > Paul. > I will have a look at it this evening as one of the failing boxes is mine. Perhaps GetTempFileName is now returning a short path to not override MAX_PATH characters. -- Nicolas Le Cam
Re: Create our own temp directory to make sure it's not the Windows directory.
2009/7/24 Paul Vriens : > Hi Alexandre, > > This one introduced a test failure on several W2K, XP and W2K3 boxes. No > idea why (yet) though. > > -- > Cheers, > > Paul. > > > Hi Paul, Alexandre, It seems to only be a short vs long pathname problem. -- Nicolas Le Cam
Re: [winhttp/tests] Fix a test failure on some W2K/XP systems
2009/7/22 Paul Vriens : > Changelog > Fix a test failure on some W2K/XP systems > > -- > Cheers, > > Paul. > > From f9708be5421888568cacfd5144aec0ea0a7877ce Mon Sep 17 00:00:00 2001 > From: Paul Vriens > Date: Wed, 22 Jul 2009 11:30:01 +0200 > Subject: [PATCH] Fix a test failure on some W2K/XP systems > > --- > dlls/winhttp/tests/winhttp.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/dlls/winhttp/tests/winhttp.c b/dlls/winhttp/tests/winhttp.c > index bce91fe..d74b9c2 100644 > --- a/dlls/winhttp/tests/winhttp.c > +++ b/dlls/winhttp/tests/winhttp.c > @@ -939,7 +939,8 @@ static void test_set_default_proxy_config(void) > info.lpszProxy = wideString; > SetLastError(0xdeadbeef); > ret = WinHttpSetDefaultProxyConfiguration(&info); > - ok(!ret && GetLastError() == ERROR_INVALID_PARAMETER, > + ok((!ret && GetLastError() == ERROR_INVALID_PARAMETER) || > + broken(ret), /* Earlier winhhtp versions on W2K/XP */ > "expected ERROR_INVALID_PARAMETER, got %d\n", GetLastError()); > > info.lpszProxy = normalString; > -- > 1.6.0.6 > > > > > Hi Paul, You did a small typo here. winhhtp -> winhttp Bye -- Nicolas Le Cam
Re: How to expanding environmental variables?
2009/7/18 Austin English : > Howdy all, > > I'm working on a automated test for Photoshop CS 2. As before, I'm > trying to do so in a portable way, so it works on various > locales/windows versions (or as much as possible). Because of > wine/windows differences, I need a portable way to get to the shared > documents folder, e.g.,: > Windows XP: > C:\Documents and Settings\All Users\Shared Documents > WIndows Vista: > C:\users\Public\Public Documents > Wine: > C:\users\Public\Documents > > Windows has several variables for this sort of thing > (http://msdn.microsoft.com/en-us/library/ms933062(WinEmbedded.5).aspx). > In particular, I need a way to return what %16430% is on the target > system. I've tried using cmd.exe to echo it, but it's not expanding > it. Does anyone know how I can expand this type of variable? I figured > there's probably something in shell32 that can accomplish this, but > nothing popped up at me immediately (and I'm about to run, so I wanted > to e-mail before I leave). Surely there's an easy way and I'm just > overlooking it... > > Thanks! > -- > -Austin > > > On a French XP SP3 explorer sees this folder as "C:\Documents and Settings\All Users\Documents Partagés" but it points in fact to "C:\Documents and Settings\All Users\Documents", and under cmd only the second one is accessible. On 2K there's no linking at all, it's "C:\Documents and Settings\All Users\Documents" on both sides. If you have access to the registry, the full path of this folder is contained (at least on 2K and XP) in the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common Documents -- Nicolas Le Cam
Re: Doing better than barely keeping up with bug reports - Bug Day this Monday (July 20)
2009/7/17 Rosanne DiMesio : >> > >> > I've created a wiki page for the event here: http://wiki.winehq.org/BugDay > > "This page does not exist yet. You can create a new empty page, or use one of > the page templates." > > > -- > Rosanne DiMesio > > > RecentChanges page says : DELETED BugDay 12:33 InformationsDmitryTimoshkov #01 Not useful, eveone works on bugs or features at its own preference, at its own time -- Nicolas Le Cam
Build a6beb5066884 w2k-sp4-fr-netwrkdrv test results
Hello, Strangely the network drive has been disconnected during the test. Could you remove it ? I will rerun and resubmit it after checking that results are correct. -- Nicolas Le Cam
Re: kernel32: Add a trailing '\n' to a MESSAGE trace
Le 2 juillet 2009 09:29, Frédéric Delanoy a écrit : > Last time I submitted this (pretty trivial) patch, it got ignored. > If it's in a bad format, please let me know! > > Frédéric Hi Frédéric, System messages already contain a new line, you don't need to add a second one. -- Nicolas Le Cam
Re: NT4 passing
2009/6/17 Austin English : > 2009/6/17 Paul Vriens : >> André Hentschel wrote: >>> >>> WinNT4 is passing now for the first time since a long time(maybe since >>> ever?). >>> So special congratulations to Paul Vriens, who spent much time making the >>> test-suite run on NT4. >>> This is a great step for the test-suite. Now NT4, 2K, XP and 2K3 are >>> passing partially. >>> Keep it up! >>> >>> >> Yep, another milestone. >> >> Several areas that would solve a bunch of test failures on several >> platforms: >> >> - IE8 >> - Different dpi settings (only Detlef I guess ;) ) >> - Locale dependent tests >> - comctl32 < 5.80 >> - < IE6 (or even earlier on none IE). > > Also tests dependent on the system drive being C:\. > > -- > -Austin > > > And tests that don't work on root drive directories or network drives. -- Nicolas Le Cam
Re: user32: Test request (cursoricon)
2009/6/8 Daniel Santos : > I've tested this on XP, but I would like to get somebody to test on 9x and > maybe even vista please and thank you. These tests are the prelude to > cursoricon patches including Griswold's animated cursors & themed cursors and > my fixes for LOTRO (mostly handling invalid calls properly). > > Thanks, > Daniel > > > > > > Tested on a French Win2k SP4 (on VirtualBox). No failures. -- Nicolas Le Cam
Re: Which virtualization software should I choose
2009/6/11 Paul Vriens : > On 06/11/2009 11:30 AM, Nicolas Le Cam wrote: >> >> 2009/6/11 Paul Vriens: >>> >>> Hi, >>> >>> Just upgraded to Fedora 11 and (yet again) having issues with VMware >>> Workstation. >>> >>> VMware still doesn't support Fedora (as a host) and I'm tired of >>> fixing/patching things, again and again. >>> >>> I need to run several Windows versions (95 up to Vista for now) for our >>> winetest and I really like the snapshot possibilities of VMware. >>> >>> Suggestions, recommendations? >>> >>> -- >>> Cheers, >>> >>> Paul. >>> >>> >>> >> >> I'm using VirtualBox. Apart from some problems around d3d/opengl and >> interruptions, it works quiet well. It also manages snapshots and have >> a CLI. >> See w2k-sp4-fr results on winetest. It has passed the test suite once >> (I didn't run latest builds but I will). >> >> Unfortunately, I don't know VMWare Workstation at all, so I can't tell >> you what are the differences. >> > Just installed VirtualBox and it does have snaphots but not so extensive as > VMware. In VMware I have some W2K snapshots: > > - out-of-the-box > - SP1 > - SP2 > - SP3 > - SP4 + Windows Update > > I can freely choose which I want to go to. Not so with VirtualBox I'm afraid > as they are all on top of each other. > > (I guess for now I keep my other, F10, box around). > > -- > Cheers, > > Paul. > I thought it was possible but never tried as I'm just using an up-to-date clean install, it suffices for my needs. If I have some time I'll try more things with those snapshots. -- Nicolas Le Cam
Re: Which virtualization software should I choose
2009/6/11 Paul Vriens : > Hi, > > Just upgraded to Fedora 11 and (yet again) having issues with VMware > Workstation. > > VMware still doesn't support Fedora (as a host) and I'm tired of > fixing/patching things, again and again. > > I need to run several Windows versions (95 up to Vista for now) for our > winetest and I really like the snapshot possibilities of VMware. > > Suggestions, recommendations? > > -- > Cheers, > > Paul. > > > I'm using VirtualBox. Apart from some problems around d3d/opengl and interruptions, it works quiet well. It also manages snapshots and have a CLI. See w2k-sp4-fr results on winetest. It has passed the test suite once (I didn't run latest builds but I will). Unfortunately, I don't know VMWare Workstation at all, so I can't tell you what are the differences. -- Nicolas Le Cam
Re: Tests passing on one more platform!
2009/6/3 Dan Kegel : > I just had a look at http://test.winehq.org > and it seems that as of a couple days ago, a > Win2000 machine has started passing all the > tests! That's three OSs now: Win2000, Win2003, and WinXP. > (Not all systems with those OSs pass the tests, > but still, having even one box per OS pass them is a nice > milestone.) > > Congratulations and thanks to all the people > (notably Paul Vriens and of course Alexandre) who have > been cleaning up the tests! > - Dan > One of them is my test machine ;) It should also pass the latest winetest (will run it this evening). I was able to go down to one test failure on it since some weeks already but didn't found a way to fix the rpcrt4 test that was crashing on every 2k machines, Rob said [1] on wine-devel that this test needs to be replaced by a widl generated one. rpcrt4 was already an unknown part of Windows for me, with widl added it was way over my head. Alexandre saved my day by disabling it :) Now back to fix tests on root drive directory and network drive. [1] http://www.winehq.org/pipermail/wine-devel/2009-April/074843.html -- Nicolas Le Cam
Re: (resubmit: need a hint) user32: when needed, recalculate menu size of menu bar before tracking starts.
2009/5/7 Rein Klazes : > On Thu, 7 May 2009 01:54:23 -0500, you wrote: > >>On Thu, May 7, 2009 at 1:52 AM, Rein Klazes wrote: >>> Fixes bug 10845 >>> >>> Changes from previous patch: menu position calculations moved to >>> nonclient.c. >> >>Can you add a testcase? > > I don't see what you would like to test. The menu->Height == zero has > the meaning "menusize needs recalculation" all over the code. That you > need to have the menu size right before doing a hittest (in > MENU_ButtonDown) is even more obvious. > > I expect the problem is more the form: touching sensitive nonclient > code. > > Rein. > > > Even if it's obvious that this is the right behavior, it's always useful to add a test, at least to prevent regressions. -- Nicolas Le Cam
Re: [4/4] (Try2) msi/tests: Fix package test when run on a different drive than C:\.
2009/4/22 James Hawkins : > On Wed, Apr 22, 2009 at 12:05 PM, Nicolas Le Cam wrote: >> Try2: Use helper function added in second patch, as suggested by James. >> >> This one finally fixes current relative path test to expect correct >> value. >> > > This version isn't using a helper function. Please thoroughly go over > your patches before submitting them. Your subject says try2, but I > know it's been more than that, so we've seen at least 12-16 > emails/patches for this set now. > > -- > James Hawkins > Outch sorry about that. I will resubmit right version. You're right, it should be Try7 but as part of the previous series was accepted, except this patch and another one trying to fix test when running on a root drive dir, I did thought creating a new series would erase counters. I'm sorry that you seems upset by that and it won't happen again. Should I resubmit with Try8 as object? Thanks again for your reviews, and sorry for my mistakes, I will pay more attention to what I'm submitting. -- Nicolas Le Cam
Re: [4/4] msi/tests: Fix package test when run on a different drive than C:\.
2009/4/21 James Hawkins :
> On Tue, Apr 21, 2009 at 2:30 PM, Nicolas Le Cam wrote:
>> This one finally fixes current relative path test to expect correct
>> value.
>>
>
> + drives = GetLogicalDrives();
> + lstrcpyA(path, "A:\\");
> + for (i = 0; i < 26; path[0] = '\0', i++)
> + {
> + if (!(drives & (1 << i)))
> + continue;
> +
> + path[0] = 'A' + i;
> + if (GetDriveType(path) != DRIVE_FIXED)
> + continue;
> +
> + lstrcatA(path + 3, CURR_DIR + 3);
> + attr = GetFileAttributesA(path);
> + if (attr != INVALID_FILE_ATTRIBUTES && (attr &
> FILE_ATTRIBUTE_DIRECTORY))
> + {
> + if (path[lstrlenA(path)-1] != '\\')
> + lstrcatA(path, "\\");
> + break;
> + }
> + path[3] = '\0';
> + }
>
>
> Same as 2/4. Please refactor and add many nice comments detailing
> exactly what is happening in native msi to make this necessary.
>
> --
> James Hawkins
>
Hi James, thanks for review.
Will resubmit tomorrow.
To answer your question, basically native msi is doing exactly what
wine is doing (ACTION_SearchDirectory in appsearch.c) except for the
corner case I'm trying to solve, too bad I did find this piece of code
after hours of testing to found out what is native behavior, at least
it has confirmed what I have found :).
--
Nicolas Le Cam
Re: (Try2) wininet/tests: Fix HttpSendRequestW test on Win2k platform.
2009/4/20 Hans Leidekker : > On Monday 20 April 2009 20:14:14 Nicolas Le Cam wrote: > >> Win2k SP4 seems to be the only platform that follows what msdn says (see >> http://msdn.microsoft.com/en-us/library/aa384247(VS.85).aspx). > > wininet is bundled with Internet Explorer, so it's more useful to look at > the Explorer version than the Windows version. > >> Perhaps passing header's length to HttpSendRequest instead of adding a >> broken expected value would be better. Let me know. > > No, the length parameter is the essence of this test. I wrote it > because I saw IE7 call HttpSendRequestW like this which contradicts MSDN. > The test shows that MSDN is outdated; on recent wininet HttpSendRequestW > will calculate the header length for you. > > -Hans > > > As I didn't get any comments for my previous patch neither on wine-devel nor on IRC I did thought my remark was the right way to go. This is wininet 5.0.3700.6713. I will resend making this test broken on IE 5.01. Thanks for review. -- Nicolas Le Cam
Re: [1/2] msi/tests: Test MsiRecordGetString on null and empty strings.
2009/4/16 James Hawkins : > On Wed, Apr 15, 2009 at 5:21 PM, Nicolas Le Cam wrote: >> 2009/4/16 James Hawkins : >>> On Wed, Apr 15, 2009 at 4:34 PM, Nicolas Le Cam >>> wrote: >>>> While trying to solve ACTION_AppSearchDr problem revealed by my previous >>>> patch, I discovered that MSI_RecordGetStringW was returning a buffer >>>> length of 1 on null and empty strings. >>>> >>>> Here is the test, the fix follows. >>>> >>>> Tested on WinXP and Wine. >>>> >>> >>> This patch has 39 lines of test code without a single empty line. >>> Unit tests test one thing at a time and should be well documented and >>> easy to read. >>> >>> -- >>> James Hawkins >>> >> >> Hi James, >> >> Even if I was tempted to changed it, I tried to follow original code >> style, as stated multiple times on wine-devel. >> >> I will resubmit with empty lines between the different tests. >> > > With a unit test, you're testing one piece of functionality. Each of > these tests has a comment above it explaining what you're testing. > > /* check behaviour of a record with 0 elements */ > > The following chunk of code tests different aspects of having a record > with 0 elements. > > You've added to the comment and tests when you really should have > started a new chunk of tests for the two new cases you're testing. To > summarize, you should have three chunks of tests. > * record with a non-empty string > * record with null string > * record with empty string Test is already testing for null and empty strings but only call MsiRecordIsNull against them. It is also doing a lot of test on non empty string in the same function, even returned buffer length but that was not the purpose of my patch. As i'm just completing current test (with a lot of lines I admit) moving it into it's own chunk seems too much to me. As I'm only interested in buffer length value, I can limit the test to that (remove MsiRecordDataSize part and string content verification) but I thought it was better to have all returned value checked instead of needing to expand the test another time in case of a regression / discovery of a new bug. I will try to make this patch cleaner. >> What do you mean by well documented ? Isn't the test self explanatory ? >> I'm setting a null or empty string and verify that getting it back >> give me an empty string with a null buffer length for both A and W >> versions. >> > > These tests are rarely self explanatory. Come back in a couple months > and try to see what you're testing in those 39 lines. It won't be > obvious. > It was the first time I looked at this part of wine, and it took me 5 min to understand what the test currently does and what I need to add to demonstrate the bug I discovered. But it's true that compact code style didn't help me. >> Is a comment like "MsiRecordGetString should return an empty string >> and null buffer length when getting back a null or empty string" will >> help understanding what I'm trying to do ? >> > > No, the results of the test *are* explanatory. > >> BTW, this patch fixes all current failures in wine for msi package >> tests when run on a root drive dir. Unfortunately it also creates 12 >> new failures. I need to investigate. >> >> Seems that this msi patch series will be bigger than expected ;) >> > > I suggest you break the fixes up into small chunks of "fix + test for fix". > Doh, I was comparing results with another patch that I'm currently trying to rework (http://www.winehq.org/pipermail/wine-patches/2009-April/071756.html). This series doesn't introduce new failures. It unfortunately doesn't fix any failures in msi package tests too, (only 12 failures actually but expected values for 106 tests are wrong if test is run on a root drive directory). Sorry for the mess. > -- > James Hawkins > Thank you for feedback James, Austin. -- Nicolas Le Cam
Re: [1/2] msi/tests: Test MsiRecordGetString on null and empty strings.
2009/4/16 James Hawkins : > On Wed, Apr 15, 2009 at 4:34 PM, Nicolas Le Cam wrote: >> While trying to solve ACTION_AppSearchDr problem revealed by my previous >> patch, I discovered that MSI_RecordGetStringW was returning a buffer >> length of 1 on null and empty strings. >> >> Here is the test, the fix follows. >> >> Tested on WinXP and Wine. >> > > This patch has 39 lines of test code without a single empty line. > Unit tests test one thing at a time and should be well documented and > easy to read. > > -- > James Hawkins > Hi James, Even if I was tempted to changed it, I tried to follow original code style, as stated multiple times on wine-devel. I will resubmit with empty lines between the different tests. What do you mean by well documented ? Isn't the test self explanatory ? I'm setting a null or empty string and verify that getting it back give me an empty string with a null buffer length for both A and W versions. Is a comment like "MsiRecordGetString should return an empty string and null buffer length when getting back a null or empty string" will help understanding what I'm trying to do ? BTW, this patch fixes all current failures in wine for msi package tests when run on a root drive dir. Unfortunately it also creates 12 new failures. I need to investigate. Seems that this msi patch series will be bigger than expected ;) Thanks for the review. -- Nicolas Le Cam
Re: [PATCH 1/2] comctl32/tests: Test expanding of a invisible sub tree.
2009/4/15 Florian Köberle :
> ---
> dlls/comctl32/tests/treeview.c | 80
>
> 1 files changed, 80 insertions(+), 0 deletions(-)
>
> diff --git a/dlls/comctl32/tests/treeview.c b/dlls/comctl32/tests/treeview.c
> index 5f310b5..7d9fcfa 100644
> --- a/dlls/comctl32/tests/treeview.c
> +++ b/dlls/comctl32/tests/treeview.c
> @@ -748,6 +748,84 @@ static LRESULT CALLBACK MyWndProc(HWND hWnd, UINT msg,
> WPARAM wParam, LPARAM lPa
> return 0L;
> }
>
> +static void TestExpandInvisible(void)
> +{
> + static CHAR nodeRText[] = "R",
> + nodeIText[] = "I",
> + nodeIIText[] = "II",
> + node1Text[] = "1",
> + node2Text[] = "2";
> + TVINSERTSTRUCTA ins;
> + HTREEITEM nodeR;
> + HTREEITEM nodeI;
> + HTREEITEM nodeII;
> + HTREEITEM node1;
> + HTREEITEM node2;
> + RECT dummyRect;
> + BOOL nodeIVisible;
> + BOOL nodeIIVisible;
> + BOOL node1Visible;
> + BOOL node2Visible;
> + HWND window = CreateWindowExA(0, "MyTestWnd", "treeview:
> TestExpandInvisible", WS_OVERLAPPEDWINDOW,
> + CW_USEDEFAULT, CW_USEDEFAULT, 130, 105, NULL, NULL,
> GetModuleHandleA(NULL), 0);
> +
> + HWND tree = CreateWindowExA(WS_EX_CLIENTEDGE, WC_TREEVIEWA, NULL,
> WS_CHILD|WS_VISIBLE|
> + TVS_LINESATROOT|TVS_HASLINES|TVS_HASBUTTONS|TVS_EDITLABELS,
> + 0, 0, 120, 100, window, (HMENU)100, GetModuleHandleA(0), 0);
> +
> +
> + ins.hParent = TVI_ROOT;
> + ins.hInsertAfter = TVI_ROOT;
> + U(ins).item.mask = TVIF_TEXT;
> + U(ins).item.pszText = nodeRText;
> + nodeR = TreeView_InsertItem(tree, &ins);
> + assert(nodeR);
> +
> + ins.hInsertAfter = TVI_LAST;
> + U(ins).item.mask = TVIF_TEXT;
> + ins.hParent = nodeR;
> +
> + U(ins).item.pszText = nodeIText;
> + nodeI = TreeView_InsertItem(tree, &ins);
> + assert(nodeI);
> + U(ins).item.pszText = nodeIIText;
> + nodeII = TreeView_InsertItem(tree, &ins);
> + assert(nodeII);
> +
> + ins.hParent = nodeI;
> +
> + U(ins).item.pszText = node1Text;
> + node1 = TreeView_InsertItem(tree, &ins);
> + assert(node1);
> + U(ins).item.pszText = node2Text;
> + node2 = TreeView_InsertItem(tree, &ins);
> + assert(node1);
> +
> + nodeIVisible = TreeView_GetItemRect(tree, nodeI, &dummyRect, FALSE);
> + ok(!nodeIVisible, "Node I should not be visible.\n");
> + node1Visible = TreeView_GetItemRect(tree, node1, &dummyRect, FALSE);
> + ok(!node1Visible, "Node 1 should not be visible.\n");
> + node2Visible = TreeView_GetItemRect(tree, node2, &dummyRect, FALSE);
> + ok(!node2Visible, "Node 2 should not be visible.\n");
> + nodeIIVisible = TreeView_GetItemRect(tree, nodeII, &dummyRect, FALSE);
> + ok(!nodeIIVisible, "Node II should not be visible.\n");
> +
> + ok(TreeView_Expand(tree, nodeI, TVE_EXPAND), "Expand of node I
> failed.\n");
> +
> + nodeIVisible = TreeView_GetItemRect(tree, nodeI, &dummyRect, FALSE);
> + ok(!nodeIVisible, "Node I should not be visible.\n");
> + node1Visible = TreeView_GetItemRect(tree, node1, &dummyRect, FALSE);
> +todo_wine
> + ok(!node1Visible, "Node 1 should not be visible.\n");
> + node2Visible = TreeView_GetItemRect(tree, node2, &dummyRect, FALSE);
> +todo_wine
> + ok(!node2Visible, "Node 2 should not be visible.\n");
> + nodeIIVisible = TreeView_GetItemRect(tree, nodeII, &dummyRect, FALSE);
> +todo_wine
> + ok(!nodeIIVisible, "Node II should not be visible.\n");
> +}
> +
> +
> START_TEST(treeview)
> {
> HMODULE hComctl32;
> @@ -819,4 +897,6 @@ START_TEST(treeview)
> TranslateMessage(&msg);
> DispatchMessageA(&msg);
> }
> +
> + TestExpandInvisible();
> }
> --
> 1.5.4.3
>
>
>
>
Hi Florian,
I think you should use already created dialog and treeview.
Place your new function just after TestCallback(), clear tree view and
fill it, then just test visibility of expandable items.
--
Nicolas Le Cam
Re: Re : [4/4] (Try4) msi/tests: Fix package test when run on root drive directory.
2009/4/13 James McKenzie : > Nicolas Le Cam wrote: >> 2009/4/13 James McKenzie : >> >>> Nicolas Le Cam wrote: >>> >>>> James, >>>> >>>> Here are updated patches for part 3 & 4 of my previous patch set. Tell >>>> me if you think I could submit them to wine-patches. >>>> >>>> For patch 3, the only todo_wine is when launched from root drive dir >>>> as explained in my previous mail. >>>> For patch 4, I skip a test if test is executed on root drive dir, as >>>> it doesn't make sense to execute it in this case. >>>> >>>> If needed I can remove the skip and change expected value to be first >>>> fixed drive when test is run on root drive dir. But this is already >>>> tested by patch 3 (when run on a root drive dir). >>>> >>>> >>>> >>> Did these work with WindowsXP or Windows Vista as expected? I don't >>> have them here to test, only Wine. >>> >>> I would defer the todo_wine to others with more experience, as this >>> marks the tested function needs more work with Wine and my experience >>> with msi is only as a user. >>> >>> James McKenzie >>> >>> >>> >>> >> >> It worked as expected on Win2k and Wine. I can test it on WinXP if >> wanted, but I don't own any Vista. >> > > I would try it on XP as that is the default Windows we try to reproduce now. >> The todo_wine is to handle root drive directories where Windows output >> first fixed drive where Wine currently output an empty string as >> demonstrated on . >> >> > Yep, that I do know about. >> Fix seems to be simple. We just need to break the for loop after the >> GetDriveType test in ACTION_SearchDirectory function in appseach.c if >> path is only three characters long (attr should also be checked >> against INVALID_FILE_ATTRIBUTES just after it). >> > Simple fixes always turn out to be the most complex whenever I've dealt > with them. >> ACTION_CheckDirectory could perhaps be updated to handle root drive >> directories too, but I'm not certain with this one. >> >> > I agree. I don't know of any software package that should be installed > to any root drive that would be handled by msi. >> As I don't have any experience with msi at all even as user, I will >> certainly wait for someone to validate what I'm saying. >> > I do have experience using msi as the installer. In my experience, no > program installed by me was to a root directory. However, some programs > installed were run from the D:\ and C:\. So, it may be a good idea to > insure that Wine's msi can handle these cases. > >> Thanks for review > You are welcome. I hope that the root directory case can be corrected > as well. > > James McKenzie > > If test passes on WinXP, I will submit patches to wine-patches with a fix for msi. If something is wrong I will surely get feedback as it was the case for previous series. This will only let rpcrt4 test as a failing test (crash) on my Win2k test platform (others are caused by the VM). I will run all tests on a root drive directory to see if I can find more failures, then switch to XP testing. -- Nicolas Le Cam
Re: Re : [4/4] (Try4) msi/tests: Fix package test when run on root drive directory.
2009/4/13 James McKenzie : > Nicolas Le Cam wrote: >> James, >> >> Here are updated patches for part 3 & 4 of my previous patch set. Tell >> me if you think I could submit them to wine-patches. >> >> For patch 3, the only todo_wine is when launched from root drive dir >> as explained in my previous mail. >> For patch 4, I skip a test if test is executed on root drive dir, as >> it doesn't make sense to execute it in this case. >> >> If needed I can remove the skip and change expected value to be first >> fixed drive when test is run on root drive dir. But this is already >> tested by patch 3 (when run on a root drive dir). >> >> > Did these work with WindowsXP or Windows Vista as expected? I don't > have them here to test, only Wine. > > I would defer the todo_wine to others with more experience, as this > marks the tested function needs more work with Wine and my experience > with msi is only as a user. > > James McKenzie > > > It worked as expected on Win2k and Wine. I can test it on WinXP if wanted, but I don't own any Vista. The todo_wine is to handle root drive directories where Windows output first fixed drive where Wine currently output an empty string as demonstrated on . Fix seems to be simple. We just need to break the for loop after the GetDriveType test in ACTION_SearchDirectory function in appseach.c if path is only three characters long (attr should also be checked against INVALID_FILE_ATTRIBUTES just after it). ACTION_CheckDirectory could perhaps be updated to handle root drive directories too, but I'm not certain with this one. As I don't have any experience with msi at all even as user, I will certainly wait for someone to validate what I'm saying. Thanks for review. -- Nicolas Le Cam
Re: wininet: Add tests for asynchronous HttpSendRequestEx/HttpEndRequest.
2009/4/11 Hans Leidekker : > On Saturday 11 April 2009 15:20:06 Nicolas Le Cam wrote: > >> Is there no way to avoid use of cached connections or to clean the >> cache before those two tests ? >> Perhaps moving both tests up and down instead of sleeping at end of >> them could help. > > I looked for a way to disable it but couldn't find any. Moving the tests > around doesn't really help; if the machine and network are fast enough > you will still run into this problem. > > I thought about merging the tests too, but we want synchronous request > in the first and asynchronous requests in the second, and you can't have > both within the same session. > > A simple workaround would be to host the posttest.php script on a second > web server. > > -Hans > It seems moving HttpSendRequestEx_test() to be the last one make test pass on my machine, but I don't think sending a patch just for that is worthwhile. What I don't understand is that my test platform is a virtual one, running on a laptop, so shouldn't be that fast, and (according to test.winehq.org) it seems to be the only platform where it occurs (other platforms timing out were already doing that before your patch). Last thing that I don't understand is that it hangs on HttpEndRequest in HttpSendRequestEx_test(), like if server wasn't answering the second query. Where it works multiple times for test.winehq.org. Anyway I will let this one as is, as I can't see a real solution except moving one of the test to another php script or host posttest.php script on two different servers. Thanks for your answers -- Nicolas Le Cam
Re: Re : [4/4] (Try4) msi/tests: Fix package test when run on root drive directory.
James,
Here are updated patches for part 3 & 4 of my previous patch set. Tell
me if you think I could submit them to wine-patches.
For patch 3, the only todo_wine is when launched from root drive dir
as explained in my previous mail.
For patch 4, I skip a test if test is executed on root drive dir, as
it doesn't make sense to execute it in this case.
If needed I can remove the skip and change expected value to be first
fixed drive when test is run on root drive dir. But this is already
tested by patch 3 (when run on a root drive dir).
--
Nicolas Le Cam
From 5ffbc8a513d97c0c7c488b4dc692c7aab8e728f9 Mon Sep 17 00:00:00 2001
From: Nicolas Le Cam
Date: Sun, 12 Apr 2009 23:50:36 +0200
Subject: msi/tests: Fix test when run on a different drive than C:\.
---
dlls/msi/tests/package.c | 36
1 files changed, 32 insertions(+), 4 deletions(-)
diff --git a/dlls/msi/tests/package.c b/dlls/msi/tests/package.c
index c5c3b67..2825e41 100644
--- a/dlls/msi/tests/package.c
+++ b/dlls/msi/tests/package.c
@@ -8562,8 +8562,8 @@ static void test_appsearch_drlocator(void)
CHAR prop[MAX_PATH];
BOOL version;
LPCSTR str;
-DWORD size;
-UINT r;
+DWORD size, drives, attr;
+UINT r, i;
version = TRUE;
if (!create_file_with_version("test.dll", MAKELONG(2, 1), MAKELONG(4, 3)))
@@ -8724,10 +8724,38 @@ static void test_appsearch_drlocator(void)
ok(!lstrcmpA(prop, path), "Expected \"%s\", got \"%s\"\n", path, prop);
size = MAX_PATH;
-sprintf(path, "%s\\", CURR_DIR);
+drives = GetLogicalDrives();
+lstrcpyA(path, "A:\\");
+for (i = 0; i < 26; i++)
+{
+if (!(drives & (1 << i)))
+continue;
+
+path[0] = 'A' + i;
+path[3] = '\0';
+if (GetDriveType(path) != DRIVE_FIXED)
+continue;
+
+if (!CURR_DIR[3])
+break;
+
+lstrcatA(path + 3, CURR_DIR + 3);
+attr = GetFileAttributesA(path);
+if (attr != INVALID_FILE_ATTRIBUTES && (attr &
FILE_ATTRIBUTE_DIRECTORY))
+{
+lstrcatA(path, "\\");
+break;
+}
+}
+if (i >= 26)
+path[0] = '\0';
r = MsiGetPropertyA(hpkg, "SIGPROP3", prop, &size);
ok(r == ERROR_SUCCESS, "Expected ERROR_SUCCESS, got %d\n", r);
-ok(!lstrcmpA(prop, path), "Expected \"%s\", got \"%s\"\n", path, prop);
+if (CURR_DIR[3])
+ok(!lstrcmpA(prop, path), "Expected \"%s\", got \"%s\"\n", path, prop);
+else
+todo_wine
+ok(!lstrcmpA(prop, path), "Expected \"%s\", got \"%s\"\n", path, prop);
size = MAX_PATH;
r = MsiGetPropertyA(hpkg, "SIGPROP4", prop, &size);
--
1.6.0.4
From 16ab3f313dcdacfe954c75e9f1d4ae519f7bfc7b Mon Sep 17 00:00:00 2001
From: Nicolas Le Cam
Date: Sun, 12 Apr 2009 23:51:23 +0200
Subject: msi/tests: Fix package test when run on root drive directory.
---
dlls/msi/tests/package.c | 157 +++---
1 files changed, 78 insertions(+), 79 deletions(-)
diff --git a/dlls/msi/tests/package.c b/dlls/msi/tests/package.c
index 2825e41..63eee56 100644
--- a/dlls/msi/tests/package.c
+++ b/dlls/msi/tests/package.c
@@ -31,6 +31,8 @@
static const char msifile[] = "winetest.msi";
char CURR_DIR[MAX_PATH];
+char FULL_DIR[MAX_PATH];
+DWORD DIR_LEN;
static void get_user_sid(LPSTR *usersid)
{
@@ -220,8 +222,7 @@ static void set_component_path(LPCSTR filename,
MSIINSTALLCONTEXT context,
RegCreateKeyA(HKEY_LOCAL_MACHINE, comppath, &hkey);
-lstrcpyA(path, CURR_DIR);
-lstrcatA(path, "\\");
+lstrcpyA(path, FULL_DIR);
if (!dir) lstrcatA(path, filename);
RegSetValueExA(hkey, prod, 0, REG_SZ, (LPBYTE)path, lstrlenA(path));
@@ -7512,43 +7513,43 @@ static void test_appsearch_complocator(void)
ok(r == ERROR_SUCCESS, "Expected ERROR_SUCCESS, got %d\n", r);
size = MAX_PATH;
-sprintf(path, "%s\\FileName1", CURR_DIR);
+sprintf(path, "%sFileName1", FULL_DIR);
r = MsiGetPropertyA(hpkg, "SIGPROP1", prop, &size);
ok(r == ERROR_SUCCESS, "Expected ERROR_SUCCESS, got %d\n", r);
ok(!lstrcmpA(prop, path), "Expected \"%s\", got \"%s\"\n", path, prop);
size = MAX_PATH;
-sprintf(path, "%s\\FileName2", CURR_DIR);
+sprintf(path, "%sFileName2", FULL_DIR);
r = MsiGetPropertyA(hpkg, "SIGPROP2", prop, &size);
ok(r == ERROR_SUCCESS, "Expected ERROR_SUCCESS, got %d\n", r);
ok(!lstrcmpA(prop, path), "Expected \"%s\", got \"%s\"\n", path, prop);
size = MAX_PATH;
-sprin
Re: Re : [4/4] (Try4) msi/tests: Fix package test when run on root drive directory.
2009/4/12 James McKenzie : > Nicolas Le Cam wrote: >> 2009/4/11 Ben Klein : >> >>> 2009/4/11 Nicolas Le Cam : >>> >>>> 2009/4/11 James Hawkins : >>>> Let met explain : >>>> >>>> Running test on wine in folder C:\test : works (expected "C:\test" got >>>> "C:\test") >>>> Running test on wine in folder C:\ : works (expected "C:\" got "C:\") >>>> Running test on wine in folder >>>> Z:\home\nlecam\Projects\wine\wine-git\dlls\msi\tests : works (expected >>>> "Z:\home\nlecam\Projects\wine\wine-git\dlls\msi\tests" got >>>> "Z:\home\nlecam\Projects\wine\wine-git\dlls\msi\tests") >>>> Running test on Windows in folder C:\test : works (expected "C:\test" >>>> got "C:\test") >>>> Running test on Windows in folder C:\ : fails (expected "C:\" got "") >>>> >>> This looks to me like it would be dependent on the WAY you run the test. >>> >>> >>>> Running test on Windows in folder X:\Documents And >>>> Settings\nlecam\Desktop : fails (expected "X:\Documents And >>>> Settings\nlecam\Desktop" got "C:\Documents And >>>> Settings\nlecam\Desktop") >>>> >>> This looks like X: is mapped to the same place as C:, and wine's path >>> translation is picking C: first. If that's so, it would also depend on >>> the way you run the test. >>> >>> Of course, I could be astronomically wrong :D >>> >>> >> >> Hi Ben, >> >> Tests were launched from cmd.exe, current directory was where >> executable resides. >> >> Those results (blank and X: becomming C:) were from Windows not Wine. >> X: is a network drive. >> >> I admit I should do more tests, at least : >> * launch test from a real drive other than C:\ >> * launch test from another directory than where executable resides. >> * install Windows on another drive than C:\, with or without a C:\ >> drive, to see if it's really SystemDrive that msi takes or just the >> first drive it can find. >> >> > Nicolas: > > You should also test the cases that are failing from within Wine as > well. We do have the capability to map to a X: drive by mapping a > network drive to this letter as well. > > It appears that C:\ is not returning a proper value either from Windows > (which would not surprise me) or that Wine is not functioning the same > as Windows in this case. You cannot mark this 'todo_wine' the code has > to be fixed or the test has to be fixed. > > James McKenzie > > Ok I did more tests, basically msi is only wrong on root drive directories, test is wrong on everything except when run on a local drive where pathes don't exist on a drive before (alphabetically sorted). On this special test, msi enumerates local drives (and only local drives) and returns the first path that matches what was passed, if nothing match it returns an empty string. Attached all tests I did. I will try to update my patch to handle every corner cases. -- Nicolas Le Cam Windows installed on E:\ (drives C:\ Z:\ exists, network drive on X:\, all pathes only exist on X:\) Executed on X:\ package.c:8730: Test failed: Expected "X:\\", got "C:\" Executed on X:\test package.c:8730: Test failed: Expected "X:\test\", got "" Executed on X:\Documents And Settings\nlecam package.c:8730: Test failed: Expected "X:\Documents And Settings\nlecam\", got "E:\Documents And Settings\nlecam\" Windows installed on E:\ (drives C:\ Z:\ exists, network drive on X:\, all pathes exist on X:\ and Z:\) Executed on X:\ package.c:8730: Test failed: Expected "X:\\", got "C:\" Executed on X:\test package.c:8730: Test failed: Expected "X:\test\", got "Z:\test\" Executed on X:\Documents And Settings\nlecam package.c:8730: Test failed: Expected "X:\Documents And Settings\nlecam\", got "E:\Documents And Settings\nlecam\" Executed on Z:\ package.c:8730: Test failed: Expected "Z:\\", got "C:\" Executed on Z:\test test passes Executed on Z:\Documents And Settings\nlecam package.c:8730: Test failed: Expected "Z:\Documents And Settings\nlecam\", got "E:\Documents And Settings\nlecam\" Windows installed on E:\ (drives C:\ Z:\ exists, network drive on X:\, all pathes exist on C:\, X:\ and Z:\) Executed on X:\ package.c:8730: Test failed: Expected "X:\\", got "C:\" Executed on X:\test package.c:8730: Test failed: Expected "X:\test\",
