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

Re: search path redux - if office 2007 always uses a private riched20, why does wine interpose its own global one?

by Dan Kegel

On Tue, Feb 17, 2009 at 4:07 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: >> Essentially, to run Office 2007, you have to set an override >> for riched20. Since Office installs a new, spiffier version >> of riched20 in its own private directory, and expects to >> find it there, isn't it a bug that we don't let it have it? > > There's no guarantee that using the private version would help. In some > cases it does, in other cases it makes things worse. So defaulting to > builtin is preferable, this way at least when it doesn't work we have a > chance of fixing it. OK, but that leaves Office 2007 broken for the average user, which can't be good. A whitelist of apps for which specific private DLLs are needed would solve this particular case. That's a hack, and against winehq policy, but because of the overwhelming popularity of the app, it's probably worth it for us to hold our noses and do that. No? - Dan

Feb. 17, 2009

Re: search path redux - if office 2007 always uses a private riched20, why does wine interpose its own global one?

by James Mckenzie

Dan Kegel <dank(a)kegel.com> >Sent: Feb 17, 2009 7:26 AM >To: James Mckenzie <jjmckenzie51(a)earthlink.net> >Cc: Alexandre Julliard <julliard(a)winehq.org>, "wine-devel(a)winehq.org" <wine-devel(a)winehq.org> >Subject: Re: search path redux - if office 2007 always uses a private riched20, why does wine interpose its own global one? > >On Tue, Feb 17, 2009 at 6:23 AM, James Mckenzie ><jjmckenzie51(a)earthlink.net> wrote: >> However, some programs will NOT function without their program specific dlls, and it appears that Office 2007 is one of them. Thus, it will be necessary to switch from built-in to native, built-in for this program until Wine incorporates all of the new functions. > >But in this case, the app is using a private fork of the DLL in question, >and the new functions in the private fork will probably never go >into the public one. Dan, never assume what the Evil Empire is going to do. They may or may not put this into the dlls in Windows7 (TM). Since I'm strictly Mac for now, I don't have any idea either. Maybe someone with this operating system can look into this and give us feedback, but I'm with you as this is another method of operation of this company. James McKenzie

Feb. 17, 2009

Re: search path redux - if office 2007 always uses a private riched20, why does wine interpose its own global one?

by Austin English

On Tue, Feb 17, 2009 at 6:07 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: > Dan Kegel <dank(a)kegel.com> writes: > >> See http://bugs.winehq.org/show_bug.cgi?id=14980 >> >> Essentially, to run Office 2007, you have to set an override >> for riched20. Since Office installs a new, spiffier version >> of riched20 in its own private directory, and expects to >> find it there, isn't it a bug that we don't let it have it? > > There's no guarantee that using the private version would help. In some > cases it does, in other cases it makes things worse. So defaulting to > builtin is preferable, this way at least when it doesn't work we have a > chance of fixing it. > > -- > Alexandre Julliard > julliard(a)winehq.org > > > What happened to 'bug for bug compatibility'? -- -Austin

Feb. 17, 2009

Re: tools/winemaker: change tabs into eight spaces

by James Mckenzie

André Hentschel <nerv(a)dawncrow.de> wrote: > > Changes the spacing of the entire file. Also, if you are going to take this time, change indenting to two or four per level. James McKenzie

Feb. 17, 2009

Re: search path redux - if office 2007 always uses a private riched20, why does wine interpose its own global one?

by Dan Kegel

On Tue, Feb 17, 2009 at 6:23 AM, James Mckenzie <jjmckenzie51(a)earthlink.net> wrote: > However, some programs will NOT function without their program specific dlls, and it appears that Office 2007 is one of them. Thus, it will be necessary to switch from built-in to native, built-in for this program until Wine incorporates all of the new functions. But in this case, the app is using a private fork of the DLL in question, and the new functions in the private fork will probably never go into the public one.

Feb. 17, 2009

Re: search path redux - if office 2007 always uses a private riched20, why does wine interpose its own global one?

by James Mckenzie

Alexandre Julliard <julliard(a)winehq.org> wrote: >Sent: Feb 17, 2009 5:07 AM >To: Dan Kegel <dank(a)kegel.com> >Cc: "wine-devel(a)winehq.org" <wine-devel(a)winehq.org> >Subject: Re: search path redux - if office 2007 always uses a private riched20, why does wine interpose its own global one? > >Dan Kegel <dank(a)kegel.com> writes: > >> See http://bugs.winehq.org/show_bug.cgi?id=14980 >> >> Essentially, to run Office 2007, you have to set an override >> for riched20. Since Office installs a new, spiffier version >> of riched20 in its own private directory, and expects to >> find it there, isn't it a bug that we don't let it have it? > >There's no guarantee that using the private version would help. In some >cases it does, in other cases it makes things worse. So defaulting to >builtin is preferable, this way at least when it doesn't work we have a >chance of fixing it. > I think the phrase for this is 'dll hell'. That is Application A ships with and places a copy of xyz.dll in the program directory and uses it, exclusively. This was fine for some versions of Windows when xyz.dll could add in its own functions at the end of the dll and include all of the functionality of the system provided xyz.dll. However, this breaks when the system is upgraded (witness what happened to a bunch of programs when XP SP2 was released or you upgraded from Windows 3.1 to Windows 3.11, etc.). This may or may not happen with Wine because we added the ability to first call the Native xyz.dll and if a function did not exist there, call Wine's xyz.dll. This allows the Wine project to call Wine specific versions of library code and continue to use program supplied dlls. Good idea and one that should be retained. However, some programs will NOT function without their program specific dlls, and it appears that Office 2007 is one of them. Thus, it will be necessary to switch from built-in to native, built-in for this program until Wine incorporates all of the new functions. This may also be true of other programs. James McKenzie

Feb. 17, 2009

Re: [1/4](try 2)wininet: parse cookie information from cookie value

by Alexandre Julliard

Aric Stewart <aric(a)codeweavers.com> writes: > + ptr = strchrW(ptr,';'); > + *ptr = 0; > + ptr++; > + while (*ptr == ' ') ptr++; /* whitespace */ > + /* FIXME use LOCALE_INVARIANT when implemented */ > + if (CompareStringW(MAKELCID(LANG_ENGLISH, SUBLANG_DEFAULT), > + NORM_IGNORECASE, ptr, 6, szDomain, 6) == 2) You need to check that the next char is a valid terminator (probably '=', not sure if other values are possible). Also using strncmpiW would make the code more readable. -- Alexandre Julliard julliard(a)winehq.org

Feb. 17, 2009

Re: winex11.drv: Map Super_L, Super_R, and Menu keys, correctly.

by James Mckenzie

Paul Bryan Roberts <pbronline-wine(a)yahoo.co.uk> wrote: > >> You need to generate the patch from the top of the wine directory. You >> also need to use your real name for copyright-tracking purposes. > >"copyright-tracking purposes" > That is a way of saying that we need, for legal reasons, to know the originator of each and every line of code that exists in the Wine project code base. >and there was me thinking you wanted my real name so I could take all your feedback personally. ;) > That's another reason for using your real name. However, the first reason is that if you do not supply your real name, your code will not be accepted into the project no matter how critically it is needed. James McKenzie

Feb. 17, 2009

Re: WINEGATE.DLL: Wine gateway to native Unix libraries

by Marco Meijer

Feb. 17, 2009

Re: big patch to implement SetupPromptForDisk (please comment)

by Ricardo Filipe

2009/2/17 Vincent Povirk <madewokherd+8cd9(a)gmail.com<madewokherd%2B8cd9(a)gmail.com> > > > I'm curious what happens if you tell if you're looking for a file on > C: that you know exists. If it doesn't bring up a dialog, that might > allow you to create a few tests that succeed. > > Vincent Povirk > > i could do that, if i had implemented IDF_CHECKFIRST :p that's one of the details missing :) so i gather only the pre dialog implementation is testable? i can make a test on invalid argument then, because that's about it i have right now before dialog.

Feb. 17, 2009