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

Re: [PATCH] Environment variable to specify X11 window for desktop

by Robert Shearman

Timothy Lee wrote: > The attached patch allows the WINE desktop to be embedded within an > existing X11 window, and is similar to the windowed mode in WINE. > > I've tested this feature using MS PowerPoint Viewer 2007, so that a > fullscreen slideshow can be fitted inside any X11 window. I'm struggling to imagine a case where the behaviour you've implemented is useful. -- Rob Shearman

Feb. 15, 2008

Re: shell32: Fix character count passed into lstrcpnA in SHGetDataFromIDListA.

by Francois Gouget

On Fri, 15 Feb 2008, Francois Gouget wrote: > > if (shortname) > - lstrcpynA(pfd->cAlternateFileName, shortname, MAX_PATH); > + lstrcpynA(pfd->cAlternateFileName, shortname, 14); > > sizeof(*pfd->cAlternateFileName) would be better than the magic 14 here. Whoops, no '*' of course. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ There are 10 types of people in the world... those who understand binary and those who don't.

Feb. 15, 2008

Re: Google's support for Wine in 2007

by Jeremy White

I just want to take a moment to personally and publicly thank Dan and Google. We have appreciated Google's support, and the work of all Google employees, interns, and SOC students very much; it has been a great boon to Wine. I also worry sometimes that Dan is overly humble. His direct technical work is brilliant and the untold secret is the amazing job Dan has done of stretching every tool and resource at his command at Google so as to maximize the positive impact for Wine. It's clear evidence that one person can truly make an enormous difference in the world. Thanks, Dan! Cheers, Jeremy

Feb. 15, 2008

Re: shell32: Fix character count passed into lstrcpnA in SHGetDataFromIDListA.

by Francois Gouget

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.

Feb. 15, 2008

Re: systray [4/4]: implement systray transparency

by Kirill K. Smirnov

> "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

Feb. 15, 2008

Re: Don't use GetExceptionCode and GetExceptionInformation in exception filter functions.

by Alexandre Julliard

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

Feb. 15, 2008

Re: Windows Mobile API

by Stefan Dösinger

Am Donnerstag, 14. Februar 2008 19:10:30 schrieb Arthur Maciel: > 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. This question is asked from time to time, and I think it is technically doable and a reasonable amount of code can be shared. However, the total interest has been too small for anything to happen. It might change if more Linux PDAs and cell phones appear in the future. So we're open to patches ;-) The obstacles may be loader specific parts, and PDA specific APIs, as well as the different CPU type.

Feb. 15, 2008

Re: ddraw / wined3d fighting over the resolution!

by Stefan Dösinger

Am Freitag, 15. Februar 2008 04:00:20 schrieb Peter Dons Tychsen: > 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). It sounds good and plausible, but I think a test case(preferably d3d8, d3d9 and ddraw) would make it even better. > Please review my patch and let med know if it is submittable. > If you hate it, i will eat more wine-gums. :-) I like them, but they make the teeth and everything in the mouth sticky due to all the sugar :-)

Feb. 15, 2008

What's up with GetPrivateProfileString?

by Johan Gill

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.

Feb. 15, 2008

Re: include: Fix the C_ASSERT macro to not generate an unused variable warning when compiling with gcc.

by Alexandre Julliard

Robert Shearman <rob(a)codeweavers.com> writes: > @@ -279,10 +279,10 @@ extern "C" { > > /* Compile time assertion */ > > -#if defined(_MSC_VER) > +#if defined(_MSC_VER) || defined(__GNUC__) > # define C_ASSERT(e) typedef char __C_ASSERT__[(e)?1:-1] > -#elif defined(__GNUC__) > -# define C_ASSERT(e) extern char __C_ASSERT__[(e)?1:-1] > +#else > +# define C_ASSERT(e) This will break if you do two C_ASSERTs in the same scope. -- Alexandre Julliard julliard(a)winehq.org

Feb. 15, 2008