June 2011 - Wine-Devel - list.winehq.org

re: cmd: add support for todo_wine constructions in testing infrastructure

by Dan Kegel

I agree @todo_space@ should go; it's never used, so it's dead code now. Tempting to say that removing it should be a separate patch, rather than combining that with adding a new feature. Since all the @keywords@ are poorly documented, I'm glad to see an unused one go. Your generic @todo_wine@ keyword seems useful. The current code is a bit ugly. If you're going to add a nice is_todo_wine_line() helper, it might make sense to do a cleanup patch that cleans up the @keyword@ recognition in general first. (Why the verbose array declaration instead of a "constant"? etc.) I see you're making every line of the .exp file count as a test. That seems ok. There's a fair bit of code duplication; I wonder if you could avoid that by refactoring things a bit. To avoid adding dead code, it might be nice to see a test that actually uses your new keyword. - Dan

June 13, 2011

Re: d3dx9: Implement GetImageInfoFromResource(A/W) for bitmaps.

by Charles Welton

On 06/13/2011 01:03 AM, Vincent Povirk wrote: > > You should probably call D3DXGetImageInfoFromFileInMemory for the real work. That is optimal, except I see no clear way to read the entire resource file(I'm quite new to winapi developing). LoadResource does read the file but it doesn't include the header, which seems necessary for D3DXGetImageInfoFromFileInMemory to properly recognize the file. > > On Sun, Jun 12, 2011 at 10:32 PM, Charles Welton <charleswfb(a)gmail.com> wrote: >> >> The code works except it doesn't try to detect the bitmap format. >> >> Kindly ask for review and how to properly implement this. Should >> >> GetDIBits be used? >> >> >> >> -- >> >> Charles Welton >> >> >> >> >> >> >> >> > > > > -- Charles Welton

June 13, 2011

Re: d3dx9: Implement GetImageInfoFromResource(A/W) for bitmaps.

by Vincent Povirk

You should probably call D3DXGetImageInfoFromFileInMemory for the real work. On Sun, Jun 12, 2011 at 10:32 PM, Charles Welton <charleswfb(a)gmail.com> wrote: > The code works except it doesn't try to detect the bitmap format. > Kindly ask for review and how to properly implement this. Should > GetDIBits be used? > > -- > Charles Welton > > > >

June 13, 2011

Re: GSoC: dinput8 Action Mapping

by Lucas Zawacki

I'm having some issues with test that inject input. For instance this code ( http://pastebin.com/gan0Niqj ) works as expected under wine and wine with dinput8.dll , but fails in every windows version... I tried a version with SendInput and had the same results... Anyone has some insight on this? Cheers

June 13, 2011

Re: comctl32/tests: Added first TaskDialog test.

by Patrick Gauthier

> Hey, Patrick. > > Look at tests/listview.c for example to see how I load version 6 with > activation context API. It doesn't work for some reason for XP SP3 (a > glitch I don't understand), but works fine for everything else. All > you need is v6util.h. > > Without version 6 activation this test is useless to run in auto mode, > it will never find TaskDialog entry points. > > Thanks for your interest. Thanks for the information. I have redone my patch using it. I looked at v6util.h and could not help but notice two things though: - There is no need to set processorArchitecture to "x86" or "amd64" as far as I know, Windows will happily take "*" to mean "whatever the currently applicable architecture is". - As a result of the previous comment, there would be no point to generate the manifest as a file, as it could be loaded from a resource (CreateActCtx supports this), that would seem cleaner to me than generating temporary files. - Patrick

June 12, 2011

Re: comctl32/tests: Added first TaskDialog test. (try 2)

by Marvin

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=11662 Your paranoid android. === WXPPROSP3 (32 bit taskdlg) === taskdlg.c:43: Test failed: COMCTL32.DLL is not loaded! === W2K3R2SESP2 (32 bit taskdlg) === taskdlg.c:43: Test failed: COMCTL32.DLL is not loaded! === W7PRO (32 bit taskdlg) === taskdlg.c:43: Test failed: COMCTL32.DLL is not loaded! === W7PROX64 (32 bit taskdlg) === taskdlg.c:43: Test failed: COMCTL32.DLL is not loaded! === W7PROX64 (64 bit taskdlg) === taskdlg.c:43: Test failed: COMCTL32.DLL is not loaded!

June 12, 2011

Re: About building test suite for Windows

by Alexandre Julliard

Patrick Gauthier <webmaster(a)korosoft.net> writes: > Now I am wondering if it's my system which is at fault for being badly > configured or if I should just modify winebuild so that it is more > lenient in its parsing of the target? You should fix your mingw package. We need a cpu name to know which architecture is supported, since there's a 64-bit mingw too. -- Alexandre Julliard julliard(a)winehq.org

June 12, 2011

Re: About building test suite for Windows

by Patrick Gauthier

On 06/12/11 07:03, André Hentschel wrote: > Hi, > i had a look in my config.log and found in my 32-bit tree: > ... > configure:7022: checking for i686-mingw32msvc-gcc > configure:7052: result: no > configure:7022: checking for i586-mingw32msvc-gcc > configure:7038: found /usr/bin/i586-mingw32msvc-gcc > configure:7049: result: i586-mingw32msvc-gcc > configure:7065: checking whether i586-mingw32msvc-gcc works > configure:7078: i586-mingw32msvc-gcc -c -g -O2 conftest.c >&5 > configure:7078: $? = 0 > configure:7079: result: yes > ... > > so i had a look at configure and if i understand it correct it simply searches for one of these in your $PATH: > i686-w64-mingw32-gcc i586-w64-mingw32-gcc i486-w64-mingw32-gcc i386-w64-mingw32-gcc > i686-pc-mingw32-gcc i586-pc-mingw32-gcc i486-pc-mingw32-gcc i386-pc-mingw32-gcc > i686-mingw32msvc-gcc i586-mingw32msvc-gcc i486-mingw32msvc-gcc i386-mingw32msvc-gcc > i686-mingw32-gcc i586-mingw32-gcc i486-mingw32-gcc i386-mingw32-gcc > > so to state Maartens question more precisely: where is your mingw32-gcc binary, what's its name and is its path in your $PATH? My mingw32-gcc is in /usr/local/bin, its name is simply "mingw32-gcc" (no CPU name in there) and yes it's in $PATH. On 06/12/11 07:10, Nicolas Le Cam wrote: > If I read the port's makefile right, using ./configure > CROSSCC="mingw32-gcc" should help. I tried this actually, and indeed the makefile stopped complaining, then winebuild started doing this instead: winebuild: Invalid target specification 'mingw32' A quick look in tools/winebuild/main.c (function set_target, line 194) shows that it chokes if the target specification does not contain at least one dash. Now I am wondering if it's my system which is at fault for being badly configured or if I should just modify winebuild so that it is more lenient in its parsing of the target? Thanks, - Patrick

June 12, 2011

Re: About building test suite for Windows

by Nicolas Le Cam

2011/6/12 Patrick Gauthier <webmaster(a)korosoft.net>: > 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

June 12, 2011

Re: About building test suite for Windows

by André Hentschel

Am 12.06.2011 07:54, schrieb 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 > > 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. Hi, i had a look in my config.log and found in my 32-bit tree: ... configure:7022: checking for i686-mingw32msvc-gcc configure:7052: result: no configure:7022: checking for i586-mingw32msvc-gcc configure:7038: found /usr/bin/i586-mingw32msvc-gcc configure:7049: result: i586-mingw32msvc-gcc configure:7065: checking whether i586-mingw32msvc-gcc works configure:7078: i586-mingw32msvc-gcc -c -g -O2 conftest.c >&5 configure:7078: $? = 0 configure:7079: result: yes ... so i had a look at configure and if i understand it correct it simply searches for one of these in your $PATH: i686-w64-mingw32-gcc i586-w64-mingw32-gcc i486-w64-mingw32-gcc i386-w64-mingw32-gcc i686-pc-mingw32-gcc i586-pc-mingw32-gcc i486-pc-mingw32-gcc i386-pc-mingw32-gcc i686-mingw32msvc-gcc i586-mingw32msvc-gcc i486-mingw32msvc-gcc i386-mingw32msvc-gcc i686-mingw32-gcc i586-mingw32-gcc i486-mingw32-gcc i386-mingw32-gcc so to state Maartens question more precisely: where is your mingw32-gcc binary, what's its name and is its path in your $PATH? -- Best Regards, André Hentschel

June 12, 2011

Re: winealsa.drv/midi.c: Adds the midi MTC Quarter Frame messages support.

by Maarten Lankhorst

Hey Stephane, Op 12-06-11 10:26, BACRI Stephane schreef: > Hi Maarten. > Thx for your answer. Joerg's comment was on the code surrounding the patch, > not on the patch. That's why I did not understand that I had to correct this > code. > Shall I propose a new patch with these correction? Or an additional one? Or > may the maintainer of winealsa.drv do so? I don't know why it was rejected, it might be best to fix the thing first. ~Maarten

June 12, 2011

Re: winealsa.drv/midi.c: Adds the midi MTC Quarter Frame messages support.

by BACRI Stephane

Hi Maarten. Thx for your answer. Joerg's comment was on the code surrounding the patch, not on the patch. That's why I did not understand that I had to correct this code. Shall I propose a new patch with these correction? Or an additional one? Or may the maintainer of winealsa.drv do so? Regards. Stéphane. 2011/6/11 Maarten Lankhorst <m.b.lankhorst(a)gmail.com> > Hello, > > 2011/6/11 BACRI Stephane <stephanebacri(a)gmail.com>: > > Hi all. > > Was there something incorrect in this patch I submitted in may, or in the > > way I submitted it? > > Perhaps should I have mentioned that it had been tested in several ways > with > > hardware & software. > joerg commented on this 11th may: > > > http://wine.1045685.n5.nabble.com/winealsa-drv-midi-c-Adds-the-midi-MTC-Qua… > > ~Maarten >

June 12, 2011

Re: About building test suite for Windows

by Maarten Lankhorst

Op 12-06-11 07:54, Patrick Gauthier schreef: > 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 What is your mingw prefix? ~Maarten

June 12, 2011

Re: comctl32/tests: Added first TaskDialog test.

by Nikolay Sivov

On Sun, Jun 12, 2011 at 9:32 AM, Patrick Gauthier <webmaster(a)korosoft.net> wrote: > This patch relies on my previous patch that sets the ordinals right. > > Given that these functions would only be available on COMCTL32 v6.x, > Vista+, I added a win_skip if the APIs are not present. However unless > the test EXE has a manifest on Windows I think it might never find them. > Hey, Patrick. Look at tests/listview.c for example to see how I load version 6 with activation context API. It doesn't work for some reason for XP SP3 (a glitch I don't understand), but works fine for everything else. All you need is v6util.h. Without version 6 activation this test is useless to run in auto mode, it will never find TaskDialog entry points. Thanks for your interest.

June 12, 2011

About building test suite for Windows

by 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

June 12, 2011

Re: Ge (Greg) van Geldorp

by James McKenzie

On 6/11/11 6:18 AM, Scott Ritchie wrote: > In tragic irony, I'm dealing with a father dying of very late stage > cancer at the moment, so forgive me if I'm slow for a bit. > First, how sad to read this about your father. Hopefully, he is receiving the best of care and is in little or no pain. Second, thank you for taking over the testbot (or at least appearing to do so, my apologies if this is incorrect.) It will take more than one person to fill Ge's shoes for providing the testbot system and for his actions to get our efforts recognized in the Virtual community. Very respectfully, James McKenzie

June 11, 2011

Re: Ge (Greg) van Geldorp

by Tom Wickline

Hi, I would like to give my condolences to the family and his many friends. Tom 2011/6/11 Paul Vriens <paul.vriens.wine(a)gmail.com> > Hi, > > The sad news reached me two days ago that Ge (Greg) van Geldorp passed > away. Please find below the mail from his brother. > > I've briefly talked to Jeremy and Alexandre about this loss and the idea > came up to have something on the winehq frontpage for a while. Jeremey also > mentioned to mark Greg's life and contributions to Wine at Wineconf this > year. Alexandre mentioned potentially hosting the winetestbot at codeweavers > in the future. Both the frontpage remembrance and the potential hosting > somewhere else has been discussed by me and Arno and will not be an issue. > > Cheers, > > Paul. > > -------- > > Hi all, > > > > My name is Arno van Geldorp. I’m the brother of Gé (Greg) van Geldorp. I’m > very sorry that I have to inform you that Greg has passed away almost 3 > weeks ago. 2 Months earlier he was diagnosed with cancer in a very > aggressive form. > > > > I know he made his contribution to the Wine project. And that one of them > is the WineTestBot. His passing away went so fast that he didn’t have the > time to inform me all about it. What he did ask me is to make sure that the > server where the WineTestBot is running on will be hosted for at least 2 > more years. So we will take care of that. But I don’t know if anyone took > over the administration off the server. > > > > If anyone took over the administration from Greg could you please contact > me at erven.van.geldorp at gmail.com > > > > Kind regards, > > > > Arno van Geldorp > > > >

June 11, 2011

Re: winealsa.drv/midi.c: Adds the midi MTC Quarter Frame messages support.

by Maarten Lankhorst

Hello, 2011/6/11 BACRI Stephane <stephanebacri(a)gmail.com>: > Hi all. > Was there something incorrect in this patch I submitted in may, or in the > way I submitted it? > Perhaps should I have mentioned that it had been tested in several ways with > hardware & software. joerg commented on this 11th may: http://wine.1045685.n5.nabble.com/winealsa-drv-midi-c-Adds-the-midi-MTC-Qua… ~Maarten

June 11, 2011

Re: [PATCH] wined3d: Dont just print a FIXME on error, handle it (Coverity)

by Henri Verbeet

On 11 June 2011 17:26, Marcus Meissner <marcus(a)jet.franken.de> wrote: > if (state <= HIGHEST_TRANSFORMSTATE) > + { > mat = &device->updateStateBlock->state.transforms[state]; > + } > else > + { > FIXME("Unhandled transform state %#x.\n", state); > + return WINED3D_OK; > + } > This works, so I'm not too bothered either way, but I think the following looks slightly nicer: if (state > HIGHEST_TRANSFORMSTATE) { WARN("Invalid transform state %#x.\n", state); return WINED3D_OK; } mat = &device->updateStateBlock->state.transforms[state]; multiply_matrix(&temp, mat, matrix);

June 11, 2011

Re: Ge (Greg) van Geldorp

by Scott Ritchie

On 06/10/2011 01:01 PM, Paul Vriens wrote: > My name is Arno van Geldorp. I’m the brother of Gé (Greg) van Geldorp. > I’m very sorry that I have to inform you that Greg has passed away > almost 3 weeks ago. 2 Months earlier he was diagnosed with cancer in a > very aggressive form. > > > > I know he made his contribution to the Wine project. And that one of > them is the WineTestBot. His passing away went so fast that he didn’t > have the time to inform me all about it. What he did ask me is to make > sure that the server where the WineTestBot is running on will be hosted > for at least 2 more years. So we will take care of that. But I don’t > know if anyone took over the administration off the server. I have the passwords, and I gave them to Maarten as well. We'll talk about this when I can. In tragic irony, I'm dealing with a father dying of very late stage cancer at the moment, so forgive me if I'm slow for a bit. Thanks, Scott Ritchie

June 11, 2011

Re: TaskDialog implementation

by André Hentschel

Am 11.06.2011 09:45, schrieb Hans Leidekker: > On Fri, 2011-06-10 at 23:29 -0500, Vincent Povirk wrote: >> Well, I think you may be right that changing it to E_NOTIMPL at this >> point would break something and might be a bad idea. Sadly, Hans >> didn't say what the stub was originally for. Hopefully, we'll soon >> have a working implementation and it won't matter. ;) > > I added it for the Internet Explorer 9 installer but it has been > broken already when someone changed it to return IDYES instead of > IDOK in pnButton. I don't know which app that was for. > Yes IE9 installer matters here and it's actually broken, so a working GUI implementation would be awesome. Am 11.06.2011 01:37, schrieb Patrick Gauthier: > What I seem to get from your input and reading SubmittingPatches, is > basically "tests, tests, tests". I thought a while about "how does one > automate tests on GUI stuff?" and "how can I ensure that my dialog > renders right in a test, short of using a flaky thing like GetPixel()?", > etc. > > Then it came to me. What I will do is first change the implementation to > return E_NOTIMPL as Vincent Povirk suggested. Then I will start writing > tests that show use TaskDialogIndirect and sends a bunch of TDM_xxx > messages and tests that the callback procedures receives all the right > TDN_xxx notifications, at least. It won't be able to test that the > dialog _displays_ right, but at least that it functions right from an > API point of view. As long as I can close the dialog when done testing, > the tests should not require any kind of user interaction. Right, you can send messages and maybe also send keys but not GetPixel(). One interessting part is the returnvalue for various "bad" inputs like NULL for pointers and so on. You can have a look at the user32 tests, maybe the file dlls/user32/tests/dialog.c is good to get inspired for some special things. > Thing is, however, that I already got the full implementation written > "as a block", short of "replaying my coding process", I don't see how I > could efficiently do that. I could always make different patches for > different parts, like, dialog creation, then layout, then message > handling, etc, but you would not get a working TaskDialog until the last > patch was integrated. It should work as your existing implementation after all patches are committed. Between the patches only the rules apply that Vincent just sent on that topic. In short it means if you send e.g. 10 patches and progressbar patch is patch 6, then Wine shouldn't suffer after patch 1-5 applied like compilation errors or at runtime crashes and the tests should still apply. But of course at this point a request to TaskDialog to display a progressbar won't show one, so it maybe should return E_NOTIMPL or something and print a FIXME. -- Best Regards, André Hentschel

June 11, 2011

Re: [PATCH 1/4] Check for null pointers before strcmp. (LLVM/Clang)

by David Laight

On Sat, Jun 11, 2011 at 01:15:42AM +0300, Lauri Kentt? wrote: > > >Second, the ok output message also dereferences pdst by printing it > > That's not true. "%s" formats null pointers as "(null)" instead of > dereferencing anything. That isn't a requirement of the C language, there are many implemenations which will fault. David -- David Laight: david(a)l8s.co.uk

June 11, 2011

Re: [PATCH] wined3d: Dont just print a FIXME on error, handle it (Coverity)

by Stefan Dösinger

On Saturday 11 June 2011 11:17:58 Marcus Meissner wrote: > else > + { > FIXME("Unhandled transform state %#x.\n", state); > + return WINED3DERR_INVALIDCALL; > + } Please return WINED3D_OK, like wined3d_device_set_sampler_state and other setters. Native doesn't do this kind of consistency checking, so apps will get D3D_OK returned if they pass an out of range state(unless the setter segfaults).

June 11, 2011

Re: winealsa.drv/midi.c: Adds the midi MTC Quarter Frame messages support.

by BACRI Stephane

Hi all. Was there something incorrect in this patch I submitted in may, or in the way I submitted it? Perhaps should I have mentioned that it had been tested in several ways with hardware & software. Regards. Stéphane.

June 11, 2011

Re: [PATCH] user32: initialize all of msg (Coverity)

by Marvin

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=11625 Your paranoid android. === W7PROX64 (64 bit msg) === Timeout

June 11, 2011