February 2008 - Wine-Devel - list.winehq.org

Re: [RFC] winecfg enhancements

by Dmitry Timoshkov

"Reece Dunn" <msclrhd(a)googlemail.com> wrote: > Does anyone know how to set up the meta bug/group to track these? We decided to avoid meta bugs in Wine. I'd suggest to discuss the things first on wine-devel, and make sure that there is an agreement to what you are planning to change. Only then start adding features, change functionality. -- Dmitry.

Feb. 14, 2008

Re: Resend pdh[3:3]: remove unnecessary test done inPdhLookupPerfNameByIndexW

by Dmitry Timoshkov

"Jeff Latimer" <lats(a)yless4u.com.au> wrote: > I looked at that and it required another test. When I discussed this > last with Dmitry, I said it would be best to pass machine and he agreed > that this would be best. The checking for alloc failures will generate > similar amounts of code to what I am removing. I am happy to do it but > have a concern that the code will look to be inefficient and not > accepted. Logically, the patch is the correct way to proceed as machine > should be passed even if not implemented yet. That said, if the patch > is acceptable, there is another case that will need to be brought into line. Hans means something like the following done in PdhOpenQueryA: WCHAR *sourceW = NULL; if (source && !(sourceW = pdh_strdup_aw( source ))) return PDH_MEMORY_ALLOCATION_FAILURE; and that's certainly not a large amount of code. Actually all pdh_strdup_aw callers already check for a possible NULL, but that may be sent as a separate patch IMO. -- Dmitry.

Feb. 14, 2008

Re: Resend pdh[3:3]: remove unnecessary test done in PdhLookupPerfNameByIndexW

by Jeff Latimer

Hans Leidekker wrote: > On Thursday 14 February 2008 09:57:32 am Jeff Latimer wrote: > > >> + machineW = pdh_strdup_aw( machine ); >> + >> + if (!(ret = PdhLookupPerfNameByIndexW( machineW, index, bufferW, &sizeW ))) >> > > In the unlikely event that pdh_strdup_aw fails the query will be run on > the local machine instead of the remote machine. Please check for allocation > failures like most other functions in there do. > > -Hans > I looked at that and it required another test. When I discussed this last with Dmitry, I said it would be best to pass machine and he agreed that this would be best. The checking for alloc failures will generate similar amounts of code to what I am removing. I am happy to do it but have a concern that the code will look to be inefficient and not accepted. Logically, the patch is the correct way to proceed as machine should be passed even if not implemented yet. That said, if the patch is acceptable, there is another case that will need to be brought into line. Jeff

Feb. 14, 2008

Re: Resend pdh[3:3]: remove unnecessary test done in PdhLookupPerfNameByIndexW

by Hans Leidekker

On Thursday 14 February 2008 09:57:32 am Jeff Latimer wrote: > + machineW = pdh_strdup_aw( machine ); > + > + if (!(ret = PdhLookupPerfNameByIndexW( machineW, index, bufferW, &sizeW ))) In the unlikely event that pdh_strdup_aw fails the query will be run on the local machine instead of the remote machine. Please check for allocation failures like most other functions in there do. -Hans

Feb. 14, 2008

Re: Google's support for Wine in 2007

by Austin English

On Feb 14, 2008 12:03 AM, Dan Kegel <dank(a)kegel.com> wrote: > I also had the pleasure of hosting eight students as > Google interns working on Wine throughout the year. > Here are their names, and roughly what they worked on: > Dan Hipschman: widl > Evan Stade: gdiplus, Powerpoint Viewer > James Hawkins: msi > Jennifer Lai: win16 conformance tests > Juan Lang: crypt32, iTunes > Matt Jones: mono testing > Mikolaj Zalewski: Photoshop, Limux > Roy Shea: svchost, BITS What's the status of getting the win16 tests into wine? 16 bit support broke a while back for many apps and is still broken. -Austin

Feb. 14, 2008

Re: [RFC] winecfg enhancements

by Reece Dunn

On 13/02/2008, Jeff Zaroyko <jeffzaroyko(a)gmail.com> wrote: > Reece Dunn <msclrhd <at> googlemail.com> writes: > > > I am looking at how we can make winecfg more useful. I have already > > supplied patches to allow importing a ubuntu human theme to work :). > > So I am now looking at how to build on that. > > I think this could probably do with some consideration > http://bugs.winehq.org/show_bug.cgi?id=6233 , it describes how the > Applications tab does not belong among the other tabs because it should be > higher up in the hierarchy of things. There are several bugs related to winecfg currently. Also, the Ubuntu devs have some ideas on improvements to winecfg on their wiki, as well as some ideas for command line access to winecfg, install/uninstall and other functionality. Ideally, there should be a winecfg meta-bug, like what we have for 1.0 and have the various enhancements grouped into relevant bugs. This will allow attachments (like mockups to be added), as well as tracking patches and ideas. I'll start setting this up, and raising the Ubuntu comments as enhancements, to better track things and get the usability and scriptability of wine configuration and management up to where they should be. Does anyone know how to set up the meta bug/group to track these? - Reece

Feb. 14, 2008

Re: Fixing the last failing tests

by Dmitry Timoshkov

"Dan Kegel" <dank(a)kegel.com> wrote: > The test you submitted that checks this, > http://www.winehq.org/pipermail/wine-patches/2005-July/018839.html > must have passed once on Windows, > but it seems to be failing now; see e.g. > http://test.winehq.org/data/200802131000/xp_rs-winxp-sp2/user32:win.txt > which is full of lines like > win.c:3656: Test failed: IsWindowUnicode expected to return FALSE > > Do you have a Windows system where that test passes currently? Hmm, thanks for pointing this out. The test doesn't pass anymore for me under an up to date XP, and I don't have other systems to test with at the moment. Looks like at some point DefWindowProcA/W treatment in XP has changed after the introduction of IsWindowUnicode test (at that time the test passed), even a trick we use in class.c with GetProcAddress("DefWindowProcA") doesn't help anymore. I sent a fix to wine-patches. -- Dmitry.

Feb. 14, 2008

[advapi32/tests] Don't crash tests for NT4

by Paul Vriens

Hi, (Deliberately sent here and not to wine-patches). Hopefully someone can shed some light on this. I need this patch to have the security tests not crash on NT4. The part about the missing function is obvious. What is not so obvious though is that when I leave the LocalFree(NewAcl) in, the test crash. If I only do the LocalFree on success (as stated btw on MSDN for this function) this test doesn't crash. AFAIK LocalFree deals with passed NULL pointers so there must be something else going on. Changelog Don't crash tests for NT4 -- Cheers, Paul.

Feb. 14, 2008

Re: ddraw / wined3d fighting over the resolution!

by Stefan Dösinger

Am Donnerstag, 14. Februar 2008 04:22:16 schrieb Peter Dons Tychsen: > Why does the SwapChain-destroy function play around with the resolution > at all. Is that really necessary? I think it should not do it if the > caller is ddraw at least. I thought I'm filtering this out in the case of ddraw, but maybe that got lost. The reason why the swapchain restores the resolution is the different way ddraw/d3d8 and d3d8/d3d9 set up the screen. In ddraw the app calls IDirectDraw7::SetDisplayMode. This sets the mode. Then it creates a DDSCAPS_PRIMARYSURFACE surface, which creates the swapchain. In d3d8/d3d9 the swapchain controls the video mode I think the problem is that RestoreDisplayMode is called before the primary surface is destroyed. The question is why this happens. I can think of the following reasons: -> Refcounting problem, or the app just doesn't release the surfaces. Then ddraw.dll destroys the objects on DLL_PROCESS_DETACH -> The app calls it that way. This needs a test, but I think it is not allowed to call SetDisplayMode / RestoreDisplayMode while a primary surface is around

Feb. 14, 2008

Google's support for Wine in 2007

by Dan Kegel

As you might know, I work for Google, and part of my day job is to help improve Wine. Here's a little report about what we've been up to. Google uses Wine primarily as the basis for the Linux port of our photo management software, Picasa. In fact, the Linux version is exactly the Windows build of Picasa, bundled with a lightly patched version of Wine. Most of the work in that port was to improve Wine so it could handle Picasa, and that work is still going on. Codeweavers did the initial port, and Googlers Lei Zhang, Nigel Liang, and Michael Moss are improving Wine further for Picasa 2.7. Beyond Picasa, a few of us (Lei Zhang, Alex Balut, and I) have been fixing random Wine bugs in our 20% time. I've also been doing regular Valgrind runs over the Wine test suite, pestering developers who accidentally check in code that Valgrind doesn't like. Hats off to the Valgrind team for a great tool, and to the (non-Google) folks who work on Valgrind/Wine compatibility (Eric Pouech, Tom Hughes, and John Reiser, among others). Google also sponsored some work by Codeweavers to improve support for Photoshop ('cause so many people want it) and for Dragon Naturally Speaking ('cause even Linux users get RSI). While not yet perfect, those apps are a lot more usable now as a result. In particular, Photoshop CS and CS2 are quite usable indeed. (See http://wiki.winehq.org/AdobePhotoshop for details.) I also had the pleasure of hosting eight students as Google interns working on Wine throughout the year. Here are their names, and roughly what they worked on: Dan Hipschman: widl Evan Stade: gdiplus, Powerpoint Viewer James Hawkins: msi Jennifer Lai: win16 conformance tests Juan Lang: crypt32, iTunes Matt Jones: mono testing Mikolaj Zalewski: Photoshop, Limux Roy Shea: svchost, BITS So, you're wondering, what exactly does that all boil down to? I tallied all our accepted patches recently; the list is now up (along with the exact Wine source we use for Picasa) at http://code.google.com/opensource/wine.html I was pleasantly surprised at the size of the list. Separately, Google also sponsored nine Summer of Code students this year. Just to name two who remain active even after the end of summer: Alex Sørnes, who improved Wine's Wordpad, and Maarten Lankhorst, who solved tons of sound problems. (And oh, how nice it is to not have to change sound settings anymore!) All that may sound like a lot, and perhaps it is, but it pales compared to the work put in on Wine by the rest of the Wine developers. Thanks, everybody! I'm really looking forward to Wine 1.0 (which, according to Alexandre, is planned for sometime in 2008). Dan Kegel Software Engineer Google

Feb. 14, 2008