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

d3dx9 patches
by tony.wasserka＠freenet.de 15 Feb '08

15 Feb '08

Hi, It's nearly two weeks ago that I sent those patches, so I was curious if there are any problems with it? http://www.winehq.org/pipermail/wine-patches/2008-February/049554.html http://www.winehq.org/pipermail/wine-patches/2008-February/049667.html http://www.winehq.org/pipermail/wine-patches/2008-February/049677.html http://www.winehq.org/pipermail/wine-patches/2008-February/049679.html http://www.winehq.org/pipermail/wine-patches/2008-February/049705.html

2 1

Windows Mobile API
by Arthur Maciel 15 Feb '08

15 Feb '08

Hi there. I´m not part of the mailing list, but I really want to know if there is any port of WINE to support Windows Mobile API (that is Windows for pocket pc, handhelds and pocket phones). This would come as a great solution for me, as I need specific WM programs on my pda. I really appreciate any help and information. Regards, Arthur

2 3

Google's support for Wine in 2007
by Dan Kegel 15 Feb '08

15 Feb '08

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

5 6

Re: [PATCH] winex11.drv: get hwnd for injected mouse events
by Alexandre Julliard 15 Feb '08

15 Feb '08

"Lei Zhang" <thestig(a)google.com> writes: > --- a/dlls/winex11.drv/mouse.c > +++ b/dlls/winex11.drv/mouse.c > @@ -278,6 +278,7 @@ void X11DRV_send_mouse_input( HWND hwnd, DWORD flags, DWORD x, DWORD y, > { > pt.x = (x * screen_width) >> 16; > pt.y = (y * screen_height) >> 16; > + hwnd = GetAncestor(WindowFromPoint(pt), GA_PARENT); This should not be needed, for injected events the window is determined on the server side. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: systray [4/4]: implement systray transparency
by Kirill K. Smirnov 15 Feb '08

15 Feb '08

> We don't want to export such a specific function. Besides, it should > really be setting the window shape. I've just understood why we cannot rely upon setting window shape to get transparency. Let's consider almost empty icon or even empty - this may happen when application "flashes" icon, e.g. on incoming ICQ message. 1) Can be there active windows with empty visible area? 2) This windows do not correctly relay mouse events. -- Kirill

1 0

Re: systray [4/4]: implement systray transparency
by Kirill K. Smirnov 15 Feb '08

15 Feb '08

> "Kirill K. Smirnov" <lich(a)math.spbu.ru> writes: > > diff --git a/dlls/winex11.drv/winex11.drv.spec > > b/dlls/winex11.drv/winex11.drv.spec index 36b83d7..126cbc5 100644 > > --- a/dlls/winex11.drv/winex11.drv.spec > > +++ b/dlls/winex11.drv/winex11.drv.spec > > @@ -130,6 +130,7 @@ # Desktop > > > > # System tray > > @ cdecl wine_make_systray_window(long) X11DRV_make_systray_window > > +@ cdecl wine_systray_window_clear(long) X11DRV_systray_window_clear > > We don't want to export such a specific function. Besides, it should > really be setting the window shape. Do I understand you correct that we should cut off transparent parts of icon, thus making window shape to match solid part of icon? Taking into account that almost every xembed-systray-aware application uses ParentRelative attribute (and KDE developers assumes this as I noticed at bug #3534), the idea of changing window shape sounds really strange. 1) Is there any strong reason why we really must change windows shape to achieve visual transparency? 2) Will it be better to stop embedding wine windows in favor of embedding pure X windows (like other apps do)? This way assumes implementing all xembed-specific stuff at winex11.drv side and exporting ONLY ONE function like wine_xembed_systray_handler(int cmd, void *data), which converts windows icon to X11 icon, creates X11 window with ParentRelative bkgrnd and embeds it. Explorer will use this function when it adds/removes icon to/from system tray. Also, this function will detect the case of wine virtual desktop and notify explorer to stop using xembed. I'm just not sure that this way will not break relaying mouse events. -- Kirill

2 1

Re: shell32: Fix character count passed into lstrcpnA in SHGetDataFromIDListA.
by Francois Gouget 15 Feb '08

15 Feb '08

if (shortname) - lstrcpynA(pfd->cAlternateFileName, shortname, MAX_PATH); + lstrcpynA(pfd->cAlternateFileName, shortname, 14); sizeof(*pfd->cAlternateFileName) would be better than the magic 14 here. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ You can have my guns when you pry them from my kids cold, dead hands.

1 1

Re: Don't use GetExceptionCode and GetExceptionInformation in exception filter functions.
by Alexandre Julliard 15 Feb '08

15 Feb '08

Robert Shearman <rob(a)codeweavers.com> writes: > Alternatively, we could get rid of the WINE_EXCEPTION_FILTER and > WINE_FINALLY_FUNC functions and make users of __EXCEPT and __FINALLY > declare the functions themselves and access the exception data > directly without use of macros. That would be better, the macros only make sense if we can use the standard ones. If we have to use a Wine-specific approach anyway then the macros are just making it harder to see what's going on. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: ddraw / wined3d fighting over the resolution!
by Peter Dons Tychsen 15 Feb '08

15 Feb '08

On Thu, 2008-02-14 at 09:18 +0100, Stefan Dösinger wrote: > 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 OK, i have now eaten enough wine-gums to comprehend this.... I think there is a general problem in swapchain->release. The swapchain should only change the resolution back to the original *if* the current resolution is still the same as the swapchain enforced. If someone else has intervened, it should let it be. This fixes the problem at hand, but would also fix other silly problems. Some could for example have called Release() while the "window" is not even visible (tabbed to desktop for example). Please review my patch and let med know if it is submittable. If you hate it, i will eat more wine-gums. :-) /pedro

2 1

What's up with GetPrivateProfileString?
by Johan Gill 15 Feb '08

15 Feb '08

http://bugs.winehq.org/show_bug.cgi?id=5424 The bug above is causing me some confusion regarding how GetPrivateProfileString should behave. Wine looks for maxis.ini in C:\Windows, and does not find it there. Therefore, Setup.exe exits. MSDN claims that if an absolute path is not provided, the windows directory is searched for the file. There are also some registry things to take into account, but maxis.ini should not be referenced in the registry since it is located on a CD-ROM and read before the autorun screen is shown. It seems very likely that GetPrivateProfileString on real Windows with just a filename as path argument looks in the current directory, but it would be nice if someone with a real Windows installation would check that. I can have a try at writing the test source if necessary.

1 0