December 2012 - Wine-Devel - list.winehq.org

Re: windowscodecs: Adjust a type in PngDecoder_Frame_GetColorContexts.

by Alexandre Julliard

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > Current snapshots of GCC 4.8.0 issue a warning about some of the > new code in windowscodecs/pngformat.c: > > pngformat.c: In function 'PngDecoder_Frame_GetColorContexts': > pngformat.c:882:5: warning: passing argument 5 of 'ppng_get_iCCP' from > incompatible pointer type [enabled by default] > if (ppng_get_iCCP(This->png_ptr, This->info_ptr, &name, &compression_type,&profile, &len)) > pngformat.c:882:5: note: expected 'png_bytepp' but argument is of type 'char **' > > The patch below addresses this. That will break on older libpng. -- Alexandre Julliard julliard(a)winehq.org

Dec. 15, 2012

Re: [2/2] gdi32/tests: Added tests for GetFontResourceInfoW

by Dmitry Timoshkov

Stefan Leichter <Stefan.Leichter(a)camline.com> wrote: > > > > Google points to http://www.undocprint.org/winspool/getfontresourceinfo > > > > which seems to have some description of this API, with symbolic names > > > > of the type parameter, so testing something besides type == 1 would be > > > > a good idea as well. > > > > > > The tests show what needs to be implemented to fix bug #30514. Feel free > > > to send tests for other query types ;-) > > > > Adding such tests isn't too hard, but anyway please check at least contents > > of the buffer you get, and use symbolic names for query types. > > Do you know an offical header file containing the symbolic names? So fare i did > not find any. Therefore the symbolic names are just fantasy names for me till > now. I have no additional information except what google points to. > If there is no header file for the symbolic names do i have to define the > symbolic names twice (dll and test) or do we have a common way to include a > private header file of a dll into the tests ot the dll? Since it's a gdi32 API I'd guess that both the API declaration and related defines should be in wingdi.h, but taking into account that it's undocumented (yet) probably it's better to put defines in the same file that uses the API. -- Dmitry.

Dec. 15, 2012

Re: [PATCH 1/3] [cmd] Convert the set /a tests to validate better

by Frédéric Delanoy

On Fri, Dec 14, 2012 at 4:50 PM, Ann and Jason Edmeades <us(a)edmeades.me.uk> wrote: > Hiya, > > Thanks for the comments > >>I don't really like hardcoding a variable name in a function... > I don't mind not having the variable hardcoded in the function, but I dont > like the solution(s), and after all they are only test routines! Being test routines doesn't mean they don't have to be "clean". Harcoding variable names is almost alway a bad thing(TM) >One > extremely useful benefit of naming the variable and checking the expected > contents rather than just echoing them, is that you can extract the chunk of > the test script into a standalone testcase and run/debug that on whatever > o/s without needing to go through the test infrastructure - whereas getting > output from the command script and not knowing whether it is right or wrong > until you go off and compare it to some hard coded list of values is much > harder to work with. I don't really understand your point here. You're echoing the variable name anyway, so if the 'set foo' displays it as well; I don't see the advantage of your method > An interim option might be something like 'checkcontents var value var > value' type routine - would that be better? Seems convoluted. Why just no go KISS? >>2. The check for the presence of the first parameter is unneeded since >>you always call with at least one param (you control all calls) > > Its just an example of defensive coding, for which I make no excuse :-) Well, unneeded here, and to quote you: "after all they are only test routines" ;-) Also, the "shift solution" keeps your defensive check at all times (even if > 3 arguments). >>3. When only 1 variable is used, no need to add a '1' suffix as in >>'foo1' or 'WINE_foo1': the '1' doesn't help/add useful information > > No, but it doesnt hurt either and gives consistency with the other tests In other "non-for /a" test, there's never a WINE_foo1 anywhere. Using "foo", "bar" and "baz" when you have at most 3 arguments seems standard practice to me. Using an enumeration suffix for only 1! variable is not reasonable IMHO (imagine a mathematical "fun(x1)", people might wonder why there's no x2, x3, ...) > If the patch doesnt go in as-is, I'll recode the check routine using what I > describe above and if it does, I'll just patch the routine... If its a > generic routine as described above it can then be reused elsewhere in the > tests potentially as well > > Thanks for the review! > Jason > You're welcome. Frédéric NB: replies on wine-devel should be only the bottom

Dec. 15, 2012

Re: [2/2] gdi32/tests: Added tests for GetFontResourceInfoW

by Stefan Leichter

Friday 14 December 2012 Dmitry Timoshkov <dmitry(a)baikal.ru> > Stefan Leichter <Stefan.Leichter(a)camline.com> wrote: > > > > + pCopyFileW = (void *)GetProcAddress(hkernel32, "CopyFileW"); > > > > + pExpandEnvironmentStringsW = (void *)GetProcAddress(hkernel32, > > > > "ExpandEnvironmentStringsW"); + pGetCurrentDirectoryW = (void > > > > *)GetProcAddress(hkernel32, "GetCurrentDirectoryW"); > > > > > > There is no reason to import these APIs using GetProcAddress. Also > > > testing GetFontResourceInfo without checking actual buffer contents is > > > not very useful. > > > > According to MSDN this APIs are WIn2k++ and WinXP++ only > > That's not true. You can always send a test to testbot and see what > happens. > > > > Google points to http://www.undocprint.org/winspool/getfontresourceinfo > > > which seems to have some description of this API, with symbolic names > > > of the type parameter, so testing something besides type == 1 would be > > > a good idea as well. > > > > The tests show what needs to be implemented to fix bug #30514. Feel free > > to send tests for other query types ;-) > > Adding such tests isn't too hard, but anyway please check at least contents > of the buffer you get, and use symbolic names for query types. Do you know an offical header file containing the symbolic names? So fare i did not find any. Therefore the symbolic names are just fantasy names for me till now. If there is no header file for the symbolic names do i have to define the symbolic names twice (dll and test) or do we have a common way to include a private header file of a dll into the tests ot the dll? -- Stefan

Dec. 14, 2012

Re: [PATCH 0/3] Add O_DENY* flags to fcntl and cifs

by Steve French

On Fri, Dec 14, 2012 at 9:30 AM, Alan Cox <alan(a)lxorguk.ukuu.org.uk> wrote: >> We can make this feature (passing O_DENY* flags received from clients >> to filesystem) can be turned on/off on Samba/NFS server to let this >> particular use case work. In general, I think we really need to be >> sure that nobody has a read access for files that a Windows process >> opened with O_DENYREAD (because there can be important reasons for the >> Windows process to do so). > > It should only affect windows emulated tasks, nothing else yes, but not just wine - there is probably a case for Samba server and NFSv4 to optionally request such behafvior). Also we are likely to see more cases where users want to run Samba over an NFS mount and vice versa. -- Thanks, Steve

Dec. 14, 2012

Sponsorship to FOSDEM's Wine room

by Jeremy White

The Wine project has a limited fund to sponsor travel to the Wine conference. If you are interested in attending the Wine DevRoom at FOSDEM, but could only do so with financial assistance, we may be able to help! To apply, simply email me a request and indicate if you need help with transportation costs, lodging costs, or both. If you need help with transportation costs, please provide an estimate of your travel costs. Funding decisions will be made by a five member committee including myself, Alexandre, Michael Stefaniuc, Austin English, and Marcus Meissner. Priority will be given to those that have contributed to the Wine project in some form (not necessarily patches). Please send your request to me no later than December 31, 2012. We will try to communicate decisions on or before January 5th, 2013. Cheers, Jeremy

Dec. 14, 2012

Re: We're in at FOSDEM!

by Jeremy White

Hey Jerome, On 12/12/2012 07:04 PM, Jerome Leclanche wrote: > Has there been any further decision about this? I'll be at FOSDEM on > behalf of Razor and would love to sit in at the Wine talks. I'm not entirely sure what you're asking. We will definitely be at FOSDEM and will have a DevRoom on Sunday. We don't (yet) have a hotel, nor do we have a full agenda. But we're not alone, I gather it's typical of most projects to scramble at the last minute. At the moment, I'm considering booking the Best Western Royale Centre: http://www.royalcentre.be/ It has the right combination of moderate price and a hotel bar :-/. It's really hard to judge location; it's a 30 minute tram ride away from the conference, but it seems as though most hotels are going to be a fairly ways away. Of course, everyone is welcome to make their own decisions, but it seems like it would be more fun if we all stay together. Again, if anyone has any opinion on this, or first hand knowledge of Brussels, that would be welcome. Cheers, Jeremy p.s. Please follow up on the wineconf list.

Dec. 14, 2012

Re: wined3d: Recognize Nvidia GTX660 cards.

by Henri Verbeet

On 14 December 2012 17:01, Caron Jensen <caron(a)codeweavers.com> wrote: > @@ -2018,6 +2020,7 @@ static enum wined3d_pci_device select_card_nvidia_mesa(const struct wined3d_gl_i > { > /* Kepler */ > {"NVE4", CARD_NVIDIA_GEFORCE_GTX680}, > + {"NVE7", CARD_NVIDIA_GEFORCE_GTX660}, > /* Fermi */ > {"NVCF", CARD_NVIDIA_GEFORCE_GTX550}, > {"NVCE", CARD_NVIDIA_GEFORCE_GTX560}, That's ok in principle, but please keep the table ordered, so NVE7 above NVE4.

Dec. 14, 2012

Re: oleaut32: Added a test for prop getter invocation with different flags

by Nikolay Sivov

Heh, sure I can do that. I did that initially with test_tlb.idl but after that I got a bunch of failures cause of existing tests. I will update existing tests then. On Fri, Dec 14, 2012 at 7:09 PM, Alexandre Julliard <julliard(a)winehq.org>wrote: > Nikolay Sivov <bunglehead(a)gmail.com> writes: > > > Don't know what it wants here. Probably it doesn't like new idl file? > > I don't like it either ;-) Any chance you could put that in one of the > existing files? > > -- > Alexandre Julliard > julliard(a)winehq.org >

Dec. 14, 2012

Re: oleaut32: Added a test for prop getter invocation with different flags

by Alexandre Julliard

Nikolay Sivov <bunglehead(a)gmail.com> writes: > Don't know what it wants here. Probably it doesn't like new idl file? I don't like it either ;-) Any chance you could put that in one of the existing files? -- Alexandre Julliard julliard(a)winehq.org

Dec. 14, 2012