July 2007 - Wine-Devel - list.winehq.org

Re: inkobj: Add stub header, implementation, and test for inkobj.dll
by Stefan Dösinger July 28, 2007

July 28, 2007

Am Freitag, 27. Juli 2007 23:09 schrieb John Klehm: > Hello, > > This patch adds stub files for inkobj.dll. Is this a standard Windows DLL? I cannot find it on my Vista installation.

2 2

Getting CA certificates into the registry
by Juan Lang July 28, 2007

July 28, 2007

(Apologies if you get this twice - I wasn't subscribed to wine-devel on this account, and apparently it didn't get moderated through.) Folks, I'm hoping for feedback on how to get CA certificates into Wine's registry. We'll need them in order to verify signatures on things. A number of apps depend on this [1]. We have a few choices: 1. Include them in a .inf file and install them with wine. There are two problems with this that I see: Signatures are opaque (asn.1 encoded) and thus hard to verify, and there's a potential maintenance hassle. It's by far the simplest though. 2. We search for certificates installed locally and import them into the registry. The trouble with this is that different distros, and even different versions of the same distro, install them in different locations. There are also usually several potential sources on the same machine, installed by different apps, and it's not clear which certs are meant to be trusted and which are not. (For example, there are several "example" certs installed on my system, and I can identify them as such, but a tool would not be able to tell the difference.) We could write a script that checks in several likely locations, but that seems dangerous: one of those locations might inadvertently be world-writable, so an attacker could possibly put untrustworthy certificates there. 2.a. We write a tool to import local certs, but make you specify the path. Ugly, but punts the problem to the user. 3. We do what the distros do: get the certificates from Mozilla's CVS, and munge them into the right format. (Google for mkcabundle.pl) This is similar to what we do for the unicode tables, but it does introduce a dependency on CVS (or perhaps wget from a web CVS front end.) I suppose I should mention there's another option: 4. We don't load certs in Wine at all, and don't implement certificate chain verification, but dynamically load openssl or gnutls and ask them to do it for us. I don't think this is simpler than the alternatives, as I've already put a fair amount of work into crypt32, but if none of the other options is acceptable I can look into it. I'd very much appreciate feedback on which option seems the best, or, most likely to get committed ;) Thanks, --Juan [1] Here's a partial list - there are more: Bug 5423, AOL AIM won't install, http://bugs.winehq.org/show_bug.cgi?id=5423 Bug 7892, iTunes startup, http://bugs.winehq.org/show_bug.cgi?id=7892 Bug 8870, Outlook can't open signed messages, http://bugs.winehq.org/show_bug.cgi?id=8870

5 7

Re: [PATCH] winecfg: Add trackbar to set screen resolution in graphicstab
by Dmitry Timoshkov July 28, 2007

July 28, 2007

"Nigel Liang" <ncliang(a)gmail.com> wrote: > diff --git a/programs/winecfg/En.rc b/programs/winecfg/En.rc > index 5972c3b..9243e3c 100644 > --- a/programs/winecfg/En.rc > +++ b/programs/winecfg/En.rc Please add appropriate changes to other languages .rc files to keep them in sync. I don't think you will like if say I while adding a feature just modify a russian language resource file. -- Dmitry.

2 2

InputHint and WM_TAKE_FOCUS
by Tomas Carnecky July 27, 2007

July 27, 2007

Commit d836a5062141dd42293ed044debbaf25f914f383 broke sound in World of Warcraft. Yes, it sound strange but after I analyzed the issue it makes perfectly sense: a commit to dlls/winex11.drv/event.c broke sound. According to the wine source and the ICCCM spec, wine uses either the 'Passive' or 'Locally active' input model. InputHint is always set and WM_TAKE_FOCUS only if "UseTakeFocus" is set in the registry. InputHint indicates that the window will have focus set by the WM, and WM_TAKE_FOCUS indicates that the app may set focus to it's own subwindows. Both metacity an compiz _don't_ send WM_TAKE_FOCUS to windows that have InputHint set! The problem that arises from [1] is the following: If the WM calls XSetInputFocus() then the xserver sends a FocusIn event to the wine window, but wine ignores that event and waits for an WM_TAKE_FOCUS message. But that message never arrives because the WM never sends it. The above mentioned commit sets the foreground window to desktop if the WoW window looses focus. This makes WoW stop sound output. But the WoW window never regains focus and WoW won't resume sound output. I assume this bug has been in wine for a long time and even though it's a bug I enjoyed being able to switch away from WoW and still hear the sound (fishing/grinding while reading slashdot, hacking on wine etc). The solution? Remove [1] (to process the FocusIn event) or remove InputHint from WM_HINTS. That would fix around the missing sound. Anyhow, 'sound while WoW lost focus' will be lost forever and I imagine there's no way to make that possible again but using a custom patch. tom [1]: http://source.winehq.org/source/dlls/winex11.drv/event.c#L509

1 1

Re: [1/4] gdi32: limit PS_USERSTYLE style count to 16
by Evan Stade July 27, 2007

July 27, 2007

On 7/26/07, Evan Stade <estade(a)gmail.com> wrote: > Hi, > > this patch is needed to prevent wine from crashing on the test that > comprises my next patch > > dlls/gdi32/pen.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > -- > Evan Stade > > Any insight into what is wrong with these patches? -- Evan Stade

1 0

re: winex11: manage one more case
by Dan Kegel July 27, 2007

July 27, 2007

The discussion in http://bugs.winehq.org/show_bug.cgi?id=3997 and offline makes it seem as if the z-order problem is very hard to get right. Yet there is some urgency to solving this problem for at least the most popular apps that suffer from it. So, perhaps it's time to consider solving it wrong. I wrote: > + /* photoshop cs installer wizard should not hide "please close" dialog */ > + if (style == (WS_CLIPSIBLINGS|WS_POPUP)) return TRUE; Now, I realize this is probably wrong, but it gets both Photoshop CS's installer and Bricscad 8's installer past their z-order problems. What would it break? (If it's not obvious, I'm not very well informed about window styles, window management, and all that.) If the patch I proposed would break too many things, perhaps we should make it conditional on particular executables, with the list of executables configurable via the registry and winecfg, as we do with library overrides. That way the damage would be limited. Thoughts? - Dan

2 1

WGL: pbuffer improvements 3 [take 2]
by Roderick Colenbrander July 26, 2007

July 26, 2007

The previous version contained a bug in the GLX context creation code of wglShareLists. The error led to a BadMatch in demos which work using upcoming patches. Roderick On Thursday 26 July 2007 20:52, Roderick Colenbrander wrote: > This patch enables the newly added offscreen formats for use with pbuffers. > Note that this function uses a GLX 1.3 function (glXCreateNewContext). This > function is needed to handle fbconfigs without a visual. Such fbconfigs > only exist on GLX 1.3 or higher (without glXCreateNewContext you can't even > use them). > > Roderick Colenbrander

1 0

Re: ntdll: Cast-qual warning fix (Resend)
by Alexandre Julliard July 26, 2007

July 26, 2007

Andrew Talbot <Andrew.Talbot(a)talbotville.com> writes: > What is wrong with this patch, please? You broke the function completely. Look closer... -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: faultrep
by Detlef Riekenberg July 26, 2007

July 26, 2007

On Do, 2007-07-26 at 02:44 +0200, Peter Dons Tychsen wrote: > I have added a missing DLL to wine. Nice. > I do have a question though: When adding new files, who runs > autoconf and automake, to reflect on the changes in Makefile.in and > configure.ac? You? Do we need to update the Wiki (#8 and the last note)? http://wiki.winehq.org/Developers-Hints#head-30a7f7f51ce0e42b4141749c9832ba… > dlls/dxguid/Makefile \ > - dlls/gdi32/Makefile \ > + dlls/faultrep/Makefile \ > + dlls/gdi32/Makefile \ Did you mixed space and tab here? This code is autogenerated by tools/make_makefiles, when your Patch is commited by Alexandre. > + * License along with this library; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA > 02110-1301, USA > + */ Please fix the line-wrap (you can attach the Patch) > +#include <wine/debug.h> > + > +WINE_DEFAULT_DEBUG_CHANNEL(faultrep); You should add a "DllMain" here. (with DisableThreedLibraryCalls(), when possible) Thanks for improving wine -- By by ... Detlef

1 0

Re: Ukrainian translation of MSI
by Stefan Dösinger July 26, 2007

July 26, 2007

Am Donnerstag, 26. Juli 2007 08:13 schrieb Reznikov Artyom: > Hello! I'm translating ReactOS into Ukrainian. I was told in in ROS > bugzilla (http://www.reactos.org/bugzilla/show_bug.cgi?id=2420) that my MSI > translation should be sent to wine. So I'm sending it in this letter. Am I > doing this correctly and in right place? The place is correct, but the format is not. You should send a diff with your modifications against the winehq git HEAD instead of just an .rc file

1 0