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

Re: gdi32/tests: simplify testcase

by Paul Vriens

On 11/17/2009 05:14 PM, André Hentschel wrote: > + for(i=0;i<sizeof(TestName)/sizeof(TestName[0]);i++) > + { > + lstrcpyA(lf.lfFaceName, TestName[i]); Hi André, Even though it would slightly change the size of the patch, I wouldn't mind some indentation here (and it would be more in line with the style of the file). You should also try to keep with the current style in that file (meaning a space after the semi-colon) with respect to the for() statement. -- Cheers, Paul.

Nov. 17, 2009

Re: today's git broke winetricks gecko :-(

by Jacek Caban

Peter Urbanec wrote: > Vincent Povirk wrote: >> Distro-specific packages just put the >> .cab file in the right place. Gecko binaries target windows, not unix >> (hence the need for mingw) so they really just depend on a functional >> x86 Wine. > > There's a lot of talk about the new Gecko requirement. At the end of > the day, adding the .cab file to a binary distribution was a trivial > 10 minute exercise. It took another 20 minutes to test everything and > figure out that the wiki page was wrong and the .cab file needs to go > in $PREFIX/share/wine/gecko NOT in $PREFIX/share/gecko. The wiki page > is now fixed, so it really should be trivial to add the gecko runtime > to most binary distributions. Sorry about that. I've noticed it trying to help Vincent to install Gecko. > > Yes, my new wine binary package has doubled in size due to a HTML > component that is actually never used directly by the target > application. A bit of a bother, but if the inclusion of the gecko > binary blob as a .cab file means more reliable wine runtime, it's a > small price to pay. > At the end of the day, the only objection I have is the fact that > building the binary release of the .cab file from source is such an > ordeal. It would be nice if the requirement for gecko could be > satisfied as part of the normal wine build process. > > Jacek, any ideas on what could/should be done to align the Gecko build > process with the wine build process? Is it possible to have minimal > Win32 stubs and keep most of the Gecko engine native? Unfortunately it's not so easy. We would have to compile Gecko with winelib target. We already have a lots of problems with Mozilla build system to cross compile it and I'm expecting much more problems if we tried to use winelib. Perhaps someday it will be possible, but wouldn't expect it in the near future. Also it would mean that the build wouldn't be portable across distros, but it's not an issue for distro packages. Jacek

Nov. 17, 2009

Re: shell32/tests: Fix Program Manager DDE Conformance Test Failures

by Mikey Alexander

--- On Tue, 11/17/09, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > From: Paul Vriens <paul.vriens.wine(a)gmail.com> > Subject: Re: shell32/tests: Fix Program Manager DDE Conformance Test Failures > To: "Mikey Alexander" <firesword14(a)yahoo.com> > Cc: "'wine-devel(a)winehq.org'" <wine-devel(a)winehq.org> > Date: Tuesday, November 17, 2009, 6:26 AM > On 11/17/2009 10:10 AM, Paul Vriens > wrote: > > On 11/14/2009 05:31 PM, Mikey Alexander wrote: > >> /* Timeout on DdeClientTransaction Call */ > >> #define MS_TIMEOUT_VAL 1000 > >> /* # of times to poll for window creation */ > >> -#define PDDE_POLL_NUM 50 > >> +#define PDDE_POLL_NUM 150 > >> /* time to sleep between polls */ > >> -#define PDDE_POLL_TIME 200 > >> +#define PDDE_POLL_TIME 300 > > > > Hi Mikey, > > > > Just raising the timeout was not enough to fix the > test failures so > > something else must be going on? > > > > Some of the test results on test.winehq.org now show a > general timeout > > for these tests (there is a hardcoded 120 second > timeout for every test > > module). > > > > Another thing I saw is that on XP we have a window title of > "Group1" for > example, whereas on W2K3 I see "C:\Documents and > Settings\All > Users\Start Menu\Programs\Group1". > > The latter will of course never be found if we only search > for "Group1". > > On W2K3 I also see that the 'group' windows are closed but > not the > 'startup one'. > > -- > Cheers, > > Paul. > Thanks for all the feedback. I'll take a look at everything later this week (completely swamped today and tomorrow)

Nov. 17, 2009

Owen Rudge : shell32: Implement SHGetImageList and remove todo_wine from imagelist tests.

by Nikolay Sivov

Hi, Owen. There's a mistake here. + hNew = ImageList_Duplicate(iImageList == SHIL_LARGE ? hLarge : hSmall); + + /* Get the interface for the new image list */ + if (hNew) + { + ret = HIMAGELIST_QueryInterface(hNew, riid, ppv); + + if (!SUCCEEDED(ret)) + ImageList_Destroy(hNew); + } After duplication hNew already has refcount == 1, after HIMAGELIST_QueryInterface is goes to 2, and it isn't what you want. To hide checking riid just remove condition before ImageList_Destroy.

Nov. 17, 2009

Re: today's git broke winetricks gecko :-(

by Peter Urbanec

Vincent Povirk wrote: > Distro-specific packages just put the > .cab file in the right place. Gecko binaries target windows, not unix > (hence the need for mingw) so they really just depend on a functional > x86 Wine. There's a lot of talk about the new Gecko requirement. At the end of the day, adding the .cab file to a binary distribution was a trivial 10 minute exercise. It took another 20 minutes to test everything and figure out that the wiki page was wrong and the .cab file needs to go in $PREFIX/share/wine/gecko NOT in $PREFIX/share/gecko. The wiki page is now fixed, so it really should be trivial to add the gecko runtime to most binary distributions. Yes, my new wine binary package has doubled in size due to a HTML component that is actually never used directly by the target application. A bit of a bother, but if the inclusion of the gecko binary blob as a .cab file means more reliable wine runtime, it's a small price to pay. At the end of the day, the only objection I have is the fact that building the binary release of the .cab file from source is such an ordeal. It would be nice if the requirement for gecko could be satisfied as part of the normal wine build process. Jacek, any ideas on what could/should be done to align the Gecko build process with the wine build process? Is it possible to have minimal Win32 stubs and keep most of the Gecko engine native? Cheers, Peter Urbanec

Nov. 17, 2009

Re: today's git broke winetricks gecko :-(

by Henri Verbeet

2009/11/17 Joerg Mayer <jmayer(a)loplof.de>: > There is one point in this discussion that I've been asking myself: > Why does Wine need a Windows Gecko instead of a native (Unix/Linux) > one? And if the question before makes any sense, wouldn't a native I'd guess to allow it to interact with Win32 windows etc. instead of having to get e.g. an X window from somewhere to render to, since only winex11.drv should know about those.

Nov. 17, 2009

Re: today's git broke winetricks gecko :-(

by Juan Lang

> Gecko is not a core part of Wine. It is only needed for an MSHTML > implementation. There are plenty of apps in existence that do not and > will not have any use for Gecko. I argue that the size of Gecko is a > good reason to not require it to be installed for those users who > *know* they don't need it. How do they know that? Things show up in surprising places, and we don't always know why it is that an app is failing. > No, you didn't. But how can you support a scheme where running "wine > cmd /c echo yes" prompts for Gecko download? I never said whether I support it or not. I was annoyed that you were making specious arguments. You're doing it again, by assuming I have a particular position. I'm saying, it's worth listening to Jacek's (and now Alexandre's) positions. --Juan

Nov. 17, 2009

Re: today's git broke winetricks gecko :-(

by Vincent Povirk

On Tue, Nov 17, 2009 at 8:52 AM, James Mckenzie <jjmckenzie51(a)earthlink.net> wrote: > Are there not installer packages for the different UNIXes for Gecko? If there are not, then the package should install everywhere, including MacOSX and OpenSolaris. If they are system/OS dependent, then my comment stands. Nope, there's just wine_gecko-1.0.0-x86.cab and wine_gecko-1.0.0-x86-dbg.cab. Distro-specific packages just put the .cab file in the right place. Gecko binaries target windows, not unix (hence the need for mingw) so they really just depend on a functional x86 Wine. -- Vincent Povirk

Nov. 17, 2009

Re: today's git broke winetricks gecko :-(

by Joerg Mayer

There is one point in this discussion that I've been asking myself: Why does Wine need a Windows Gecko instead of a native (Unix/Linux) one? And if the question before makes any sense, wouldn't a native version be part of a firefox package and thus not need extra packaging? I'm sorry to ask such a simple question, but it's a long time that I've had any insight into the Wine details. Ciao Joerg -- Joerg Mayer <jmayer(a)loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology.

Nov. 17, 2009

Re: today's git broke winetricks gecko :-(

by ovek＠arcticnet.no

Jacek Caban skrev: > Ove Kaaven wrote: >> Vincent Povirk skrev: >> >>> On Mon, Nov 16, 2009 at 5:52 PM, Ove Kaaven <ovek(a)arcticnet.no> wrote: >>> >>>> (It is actually for similar reasons that binaries must be buildable >>>> on a >>>> clean system (say, a build daemon), without any special (non-free) >>>> tools >>>> or sourceless libraries. Magic libshell32.a in the source package fails >>>> this requirement, and so does usage of non-free cabinet.dll to make cab >>>> file.) >>>> >>> I don't suppose the build could be fixed? >>> >> >> Possibly. For the .a files, either the rules that generated them has to >> be documented somehow so the procedure can be replicated in the source >> package's build system, or mingw's w32api has to be patched to fix the >> problems that required them in the first place. (The latter probably >> won't happen overnight, I suppose.) >> > > $ cd dlls/shell32 > $ make libshell32.a So this is confirmation that all the .a files included in the source are generated from a Wine build tree, there's no other patches or anything? So to achieve a binary-less source package, perhaps I can do something with a Wine build-dependency or something, I suppose. I'll take a look at whether that suffices. > In the official build I also include there a little virus that checks > for Oven Kaaven user name and if it finds one, it silently replaces > Debian installation with Ubuntu at 18 November each year. Like I would run it as root... (even if you had spelled my name right) > But seriously, patches are welcome. The build process is far from > perfect, but it slowly improves. There are problems with gcc, mingw and > mozilla itself. Patches are welcome. It's easy to complain, but a lot > harder to fix. I thought mingw needed patching the most.

Nov. 17, 2009

Re: today's git broke winetricks gecko :-(

by James Mckenzie

Jacek Caban wrote: >Sent: Nov 17, 2009 7:40 AM >To: Tom Wickline <twickline(a)gmail.com> >Cc: James Mckenzie <jjmckenzie51(a)earthlink.net>, Vincent Povirk <madewokherd+8cd9(a)gmail.com>, wine-devel(a)winehq.org >Subject: Re: today's git broke winetricks gecko :-( > >Tom Wickline wrote: >> >> >> On Tue, Nov 17, 2009 at 10:27 PM, James Mckenzie >> <jjmckenzie51(a)earthlink.net <mailto:jjmckenzie51(a)earthlink.net>> wrote: >> >> >> > >> +1 as well. Not all UNIXes have Gecko support packages built for them >> >> >> +1 as well, I haven't tested the changes on OpenSolaris yet, but I >> plan to. :) > >Which makes -0 from both of you as you clearly don't understand the way >Gecko package works. These are .dll files so they are only arch >dependent from Wine point of view. Are there not installer packages for the different UNIXes for Gecko? If there are not, then the package should install everywhere, including MacOSX and OpenSolaris. If they are system/OS dependent, then my comment stands. James McKenzie

Nov. 17, 2009

Re: today's git broke winetricks gecko :-(

by Jacek Caban

Marcus Meissner wrote: > On Mon, Nov 16, 2009 at 11:29:51PM +0100, Ove Kaaven wrote: > >> Jacek Caban skrev: >> >>> Well, I hope that a side effect of installation during wineprefix >>> creation is that it will force packagers to package gecko <g> >>> >> You can't *force* the creation of packages which would likely fail to >> meet the requirements for inclusion into Debian's main archive. Even if >> I didn't think the package's build system is a problem, the ftpmasters >> likely would. >> > > I btw thought of actually building wine-gecko using mingw instead of > just distributing the .cab. > > Just did not have the time to try it in the .spec file. > > This is also the 1 problem I see with distro inclusion here, so far > I just have it in my openSUSE buildservice repos. > I'm afraid it won't work well ATM. We're quite not yet there with Wine Gecko source and build system. I hope it will be possible at some point, but we're far from there. Jacek

Nov. 17, 2009

Re: today's git broke winetricks gecko :-(

by Jacek Caban

Ove Kaaven wrote: > Vincent Povirk skrev: > >> On Mon, Nov 16, 2009 at 5:52 PM, Ove Kaaven <ovek(a)arcticnet.no> wrote: >> >>> (It is actually for similar reasons that binaries must be buildable on a >>> clean system (say, a build daemon), without any special (non-free) tools >>> or sourceless libraries. Magic libshell32.a in the source package fails >>> this requirement, and so does usage of non-free cabinet.dll to make cab >>> file.) >>> >> I don't suppose the build could be fixed? >> > > Possibly. For the .a files, either the rules that generated them has to > be documented somehow so the procedure can be replicated in the source > package's build system, or mingw's w32api has to be patched to fix the > problems that required them in the first place. (The latter probably > won't happen overnight, I suppose.) > $ cd dlls/shell32 $ make libshell32.a In the official build I also include there a little virus that checks for Oven Kaaven user name and if it finds one, it silently replaces Debian installation with Ubuntu at 18 November each year. But seriously, patches are welcome. The build process is far from perfect, but it slowly improves. There are problems with gcc, mingw and mozilla itself. Patches are welcome. It's easy to complain, but a lot harder to fix. Jacek

Nov. 17, 2009

Re: shell32/tests: Fix Program Manager DDE Conformance Test Failures

by Paul Vriens

On 11/17/2009 03:26 PM, Paul Vriens wrote: > On 11/17/2009 10:10 AM, Paul Vriens wrote: >> On 11/14/2009 05:31 PM, Mikey Alexander wrote: >>> /* Timeout on DdeClientTransaction Call */ >>> #define MS_TIMEOUT_VAL 1000 >>> /* # of times to poll for window creation */ >>> -#define PDDE_POLL_NUM 50 >>> +#define PDDE_POLL_NUM 150 >>> /* time to sleep between polls */ >>> -#define PDDE_POLL_TIME 200 >>> +#define PDDE_POLL_TIME 300 >> >> Hi Mikey, >> >> Just raising the timeout was not enough to fix the test failures so >> something else must be going on? >> >> Some of the test results on test.winehq.org now show a general timeout >> for these tests (there is a hardcoded 120 second timeout for every test >> module). >> > > Another thing I saw is that on XP we have a window title of "Group1" for > example, whereas on W2K3 I see "C:\Documents and Settings\All > Users\Start Menu\Programs\Group1". > > The latter will of course never be found if we only search for "Group1". > > On W2K3 I also see that the 'group' windows are closed but not the > 'startup one'. > And yet another thing. This longer window title on my W2K3 box is because I've activated 'Display the full path in the title bar' in the 'Folder Options'. I'm not sure if this is the default on some boxes or if I did this manually. One can see if this is activated at HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\CabinetState\FullPath (1 meaning active). -- Cheers, Paul.

Nov. 17, 2009

Re: today's git broke winetricks gecko :-(

by Jacek Caban

Tom Wickline wrote: > > > On Tue, Nov 17, 2009 at 10:27 PM, James Mckenzie > <jjmckenzie51(a)earthlink.net <mailto:jjmckenzie51(a)earthlink.net>> wrote: > > > > > +1 as well. Not all UNIXes have Gecko support packages built for them > > > +1 as well, I haven't tested the changes on OpenSolaris yet, but I > plan to. :) Which makes -0 from both of you as you clearly don't understand the way Gecko package works. These are .dll files so they are only arch dependent from Wine point of view. Jacek

Nov. 17, 2009

Re: today's git broke winetricks gecko :-(

by Tom Wickline

On Tue, Nov 17, 2009 at 10:27 PM, James Mckenzie <jjmckenzie51(a)earthlink.net > wrote: > > > > +1 as well. Not all UNIXes have Gecko support packages built for them > +1 as well, I haven't tested the changes on OpenSolaris yet, but I plan to. :) Tom > James McKenzie > > > -- http://www.wine-reviews.net/

Nov. 17, 2009

Re: today's git broke winetricks gecko :-(

by Paul Chitescu

On Tuesday 17 November 2009 04:15:29 pm Nate Gallaher wrote: > I would just like to second Vincent's suggestion. > > Vincent Povirk wrote: > > It also seems to me that a --disable-gecko-downloader configure switch > > that would disable the dialog COMPLETELY (even "when needed") would > > put gecko on equal footing with optional library requirements. It > > would mean: > > * You can warn about the perils of not having gecko at configure time. > > * If gecko is installed properly, it's used properly, installed at > > prefix creation time. > > * If gecko is not installed properly, programs that need it will > > simply fail, and you'll see an ERR in the console, as well as a nice > > "HTML rendering is disabled" message you wouldn't get from other > > components. Plus a button or link to (download and) install it for the next time I'd say.

Nov. 17, 2009

Re: today's git broke winetricks gecko :-(

by James Mckenzie

Nate Gallaher wrote: >Vincent Povirk wrote: >> It also seems to me that a --disable-gecko-downloader configure switch >> that would disable the dialog COMPLETELY (even "when needed") would >> put gecko on equal footing with optional library requirements. It >> would mean: >> * You can warn about the perils of not having gecko at configure time. >> * If gecko is installed properly, it's used properly, installed at >> prefix creation time. >> * If gecko is not installed properly, programs that need it will >> simply fail, and you'll see an ERR in the console, as well as a nice >> "HTML rendering is disabled" message you wouldn't get from other >> components. >> >> > > >I would just like to second Vincent's suggestion. > +1 as well. Not all UNIXes have Gecko support packages built for them James McKenzie >

Nov. 17, 2009

Re: shell32/tests: Fix Program Manager DDE Conformance Test Failures

by Paul Vriens

On 11/17/2009 10:10 AM, Paul Vriens wrote: > On 11/14/2009 05:31 PM, Mikey Alexander wrote: >> /* Timeout on DdeClientTransaction Call */ >> #define MS_TIMEOUT_VAL 1000 >> /* # of times to poll for window creation */ >> -#define PDDE_POLL_NUM 50 >> +#define PDDE_POLL_NUM 150 >> /* time to sleep between polls */ >> -#define PDDE_POLL_TIME 200 >> +#define PDDE_POLL_TIME 300 > > Hi Mikey, > > Just raising the timeout was not enough to fix the test failures so > something else must be going on? > > Some of the test results on test.winehq.org now show a general timeout > for these tests (there is a hardcoded 120 second timeout for every test > module). > Another thing I saw is that on XP we have a window title of "Group1" for example, whereas on W2K3 I see "C:\Documents and Settings\All Users\Start Menu\Programs\Group1". The latter will of course never be found if we only search for "Group1". On W2K3 I also see that the 'group' windows are closed but not the 'startup one'. -- Cheers, Paul.

Nov. 17, 2009

Re: today's git broke winetricks gecko :-(

by Nate Gallaher

I would just like to second Vincent's suggestion. Vincent Povirk wrote: > It also seems to me that a --disable-gecko-downloader configure switch > that would disable the dialog COMPLETELY (even "when needed") would > put gecko on equal footing with optional library requirements. It > would mean: > * You can warn about the perils of not having gecko at configure time. > * If gecko is installed properly, it's used properly, installed at > prefix creation time. > * If gecko is not installed properly, programs that need it will > simply fail, and you'll see an ERR in the console, as well as a nice > "HTML rendering is disabled" message you wouldn't get from other > components. > >

Nov. 17, 2009

Re: WGL: add initial WGL_ARB_create_context support

by Alexandre Julliard

Roderick Colenbrander <thunderbird2k(a)gmail.com> writes: > This patch adds an initial implementation of WGL_ARB_create_context > which is required for OpenGL 3.x support. I have tried some basic GL3 > samples which work and the initial Wine tests. It doesn't work here: ../../../tools/runtest -q -P wine -M opengl32.dll -T ../../.. -p opengl32_test.exe.so opengl.c && touch opengl.ok opengl.c:562: Test failed: wglCreateContextAttribs with major version=0 should fail! X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 128 (GLX) Minor opcode of failed request: 34 () Value in failed request: 0x0 Serial number of failed request: 370 Current serial number in output stream: 373 make: *** [opengl.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

Nov. 17, 2009

Re: [PATCH 1/2] mshtml: Also search by node name attribute in IHTMLDocument3::getElementById

by Alexandre Julliard

Andrew Eikum <aeikum(a)codeweavers.com> writes: > --- > dlls/mshtml/htmldoc3.c | 26 ++++++++++++++++++++++---- > dlls/mshtml/tests/dom.c | 29 ++++++++++++++++++++++++++++- > 2 files changed, 50 insertions(+), 5 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M mshtml.dll -T ../../.. -p mshtml_test.exe.so dom.c && touch dom.ok dom.c:5401: Test failed: Got wrong tag: L"OPTION" make: *** [dom.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

Nov. 17, 2009

Re: [PATCH 4/5] comctl32/tests: Add further tests for IImageList

by Nikolay Sivov

Owen, also please use more reasonable names for particular tests - dotest means nothing. On 11/17/09, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > On 11/13/2009 06:14 PM, Owen Rudge wrote: >> --- >> dlls/comctl32/tests/imagelist.c | 80 >> +++++++++++++++++++++++++++++++++++++++ >> 1 files changed, 80 insertions(+), 0 deletions(-) >> > > Hi Owen, > > These tests introduce 3 failures on all 32bit XP boxes: > > http://test.winehq.org/data/tests/comctl32:imagelist.html > > Could you have a look? > > -- > Cheers, > > Paul. > > >

Nov. 17, 2009

Re: [PATCH 4/5] comctl32/tests: Add further tests for IImageList

by Paul Vriens

On 11/13/2009 06:14 PM, Owen Rudge wrote: > --- > dlls/comctl32/tests/imagelist.c | 80 > +++++++++++++++++++++++++++++++++++++++ > 1 files changed, 80 insertions(+), 0 deletions(-) > Hi Owen, These tests introduce 3 failures on all 32bit XP boxes: http://test.winehq.org/data/tests/comctl32:imagelist.html Could you have a look? -- Cheers, Paul.

Nov. 17, 2009

Re: [RFC] Handle process token groups in server/file.c::sd_to_mode

by Ben Peddell

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Chitescu wrote: > Hi! > > How should server/file.c sd_to_mode() deal with filesystems that don't > support full POSIX ownership and access permissions? It is quite > popular to mount FAT filesystems - either from a removable media or a > partition shared with a Windows installation. > > Furthermore, there could be symlinks to such files so filesystem > capability should be detected somehow from the file itself. The only portable way I can think of is having certain "drives" marked as e.g. FAT32 (instead of NTFS), and having dlls/ntdll/sec.c::NtSetSecurityObject() either fake success, or (with support from other areas) do whatever it does on FAT32 (and I don't know what that is). The fstatvfs portability function in libport only reports filesystem space, and not type or id, so that cannot be used to portably detect what type of filesystem the file sits on. > Since recently I am unable to patch WoW since it started to call > SetFileSecurity on the program directory which is located on a FAT32 > partition. Everything appears owned by root but with rwxrwxrwx access. > Wine tries to set ---rwx--- which is, to say the least, not commonly > seen. > > http://bugs.winehq.org/show_bug.cgi?id=20643 The World of Warcraft Launcher tries to set the directory to Full Access only to the Users group, which wine currently does put the user in. This is a World of Warcraft bug in that it also affects Windows users. However, it exposes a shortcoming in the ACL handling in wine. The setting to ---???--- is one of the bugs I am hoping to fix with this patch. Currently, server/file.c::sd_to_mode() only honours owner and world permissions, and does not look at what groups the owner is a member of. After this patch, the Launcher (through wine) should set the permissions to rwx???--- if the user owns the directory. I can see multiple bug reports in bugs.winehq.org involving either programs removing the owner permissions or FAT32 mounts not working due to failed permission setting. <http://bugs.winehq.org/show_bug.cgi?id=17672> Wine denies access to Oracle Client install folder <http://bugs.winehq.org/show_bug.cgi?id=20357> Problem with wine creating folders on installs <http://bugs.winehq.org/show_bug.cgi?id=19588> Wine is setting incorrect permissions in some instances <http://bugs.winehq.org/show_bug.cgi?id=10067> Steam Failed to set file attrbutes <http://bugs.winehq.org/show_bug.cgi?id=17776> Installing on Fat32 partitions seems to be impossible nowadays <http://bugs.winehq.org/show_bug.cgi?id=18359> InstallShield fails with "Access Denied" dialog when trying to install to FAT32 volume <http://bugs.winehq.org/show_bug.cgi?id=20643> World of Warcraft launcher tries to change folder permissions (Not a Wine bug) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksCnvIACgkQTHDAI68NsumTLwCdGcE4Pd52d/P1yAZThqSSEefk Z9cAnRjBdMy0TbF0ET1NGKm7Nbs+lx1h =+HHN -----END PGP SIGNATURE-----

Nov. 17, 2009

Re: [RFC] Handle process token groups in server/file.c::sd_to_mode

by Paul Chitescu

Hi! How should server/file.c sd_to_mode() deal with filesystems that don't support full POSIX ownership and access permissions? It is quite popular to mount FAT filesystems - either from a removable media or a partition shared with a Windows installation. Furthermore, there could be symlinks to such files so filesystem capability should be detected somehow from the file itself. Since recently I am unable to patch WoW since it started to call SetFileSecurity on the program directory which is located on a FAT32 partition. Everything appears owned by root but with rwxrwxrwx access. Wine tries to set ---rwx--- which is, to say the least, not commonly seen. http://bugs.winehq.org/show_bug.cgi?id=20643 Paul

Nov. 17, 2009

Re: today's git broke winetricks gecko :-(

by Alexandre Julliard

Ben Klein <shacklein(a)gmail.com> writes: > 2009/11/17 Juan Lang <juan.lang(a)gmail.com>: >>> If a previously-optional component is now deemed to be mandatory, and >>> that component *on its own* happens to double the download size >>> required to install Wine, I consider that a problem. Not everyone has >>> a cable or ADSL2+ connection. >> >> Yes, but it's not updated as frequently. > > What guarantee is there of this in the future? In fact, if you can > guarantee that there will never be another update to Gecko, then the > argument on the size of Gecko disappears. Obviously there will be some updates, and obviously they are not as frequent as Wine releases. Since Gecko was added there have been 3 updates, for 56 Wine releases in the same period. The download size is not a valid argument. >>>>wine cmd /c echo yes now downloads gecko. >>> How can you possibly justify this? >> >> Is this to me? I didn't say that. > > No, you didn't. But how can you support a scheme where running "wine > cmd /c echo yes" prompts for Gecko download? It's not running cmd that needs it, it's creating a new functional Wine prefix. Like it or not, there are many things that need to be part of a proper Windows environment, and we can't predict which will be needed, or install everything on demand. That's not how Windows works. Yes, the download dialog is annoying, but once most packages do the right thing we can take it down and put up a "mshtml support broken, complain to your packager" dialog box instead. -- Alexandre Julliard julliard(a)winehq.org

Nov. 17, 2009

Re: today's git broke winetricks gecko :-(

by Ove Kaaven

Vincent Povirk skrev: > On Mon, Nov 16, 2009 at 5:52 PM, Ove Kaaven <ovek(a)arcticnet.no> wrote: >> (It is actually for similar reasons that binaries must be buildable on a >> clean system (say, a build daemon), without any special (non-free) tools >> or sourceless libraries. Magic libshell32.a in the source package fails >> this requirement, and so does usage of non-free cabinet.dll to make cab >> file.) > > I don't suppose the build could be fixed? Possibly. For the .a files, either the rules that generated them has to be documented somehow so the procedure can be replicated in the source package's build system, or mingw's w32api has to be patched to fix the problems that required them in the first place. (The latter probably won't happen overnight, I suppose.) For the cab file, I suppose it would work to use one of those simple Linux tools for making cab files that don't actually compress the data like the native cabinet.dll do. The package will be larger, but it would be acceptable as DFSG-free.

Nov. 17, 2009

Re: ddraw/tests: Fix test failure for D3DFMT_A2R10G10B10 pixel format in GetDC tests

by Stefan Dösinger

Am 17.11.2009 um 10:38 schrieb Austin Lund: > > <0001-ddraw-tests-Fix-test-failure-for-D3DFMT_A2R10G10B10-.txt> Where did this test fail? On Wine or Windows? If it was on windows, which windows version and GPU did you use?

Nov. 17, 2009

Re: [PATCH 2/2] [Msvcrt]: in undname functions, no longer use a fixed-size array for storing internal information

by Paul Vriens

On 11/15/2009 10:07 PM, Eric Pouech wrote: > > (fix for #20681) Hi Eric, This new test fails on all 32bit systems: http://test.winehq.org/data/tests/msvcrt:cpp.html The only box where there are no failures is a 64bit one, but no tests are actually run there ;) Could you have a look? -- Cheers, Paul.

Nov. 17, 2009

Re: shell32/tests: Fix Program Manager DDE Conformance Test Failures

by Paul Vriens

On 11/14/2009 05:31 PM, Mikey Alexander wrote: > /* Timeout on DdeClientTransaction Call */ > #define MS_TIMEOUT_VAL 1000 > /* # of times to poll for window creation */ > -#define PDDE_POLL_NUM 50 > +#define PDDE_POLL_NUM 150 > /* time to sleep between polls */ > -#define PDDE_POLL_TIME 200 > +#define PDDE_POLL_TIME 300 Hi Mikey, Just raising the timeout was not enough to fix the test failures so something else must be going on? Some of the test results on test.winehq.org now show a general timeout for these tests (there is a hardcoded 120 second timeout for every test module). -- Cheers, Paul.

Nov. 17, 2009

Re: today's git broke winetricks gecko :-(

by Ben Klein

2009/11/17 Juan Lang <juan.lang(a)gmail.com>: >> If a previously-optional component is now deemed to be mandatory, and >> that component *on its own* happens to double the download size >> required to install Wine, I consider that a problem. Not everyone has >> a cable or ADSL2+ connection. > > Yes, but it's not updated as frequently. What guarantee is there of this in the future? In fact, if you can guarantee that there will never be another update to Gecko, then the argument on the size of Gecko disappears. > The development version of Wine is updated roughly every > two weeks, so if a user is willing to download a development version > approximately that often, why should a single, equally sized download > be an impediment? Gecko is not a core part of Wine. It is only needed for an MSHTML implementation. There are plenty of apps in existence that do not and will not have any use for Gecko. I argue that the size of Gecko is a good reason to not require it to be installed for those users who *know* they don't need it. >>>wine cmd /c echo yes now downloads gecko. >> How can you possibly justify this? > > Is this to me? I didn't say that. No, you didn't. But how can you support a scheme where running "wine cmd /c echo yes" prompts for Gecko download? 2009/11/17 Marcus Meissner <marcus(a)jet.franken.de>: > On Mon, Nov 16, 2009 at 11:29:51PM +0100, Ove Kaaven wrote: >> You can't *force* the creation of packages which would likely fail to >> meet the requirements for inclusion into Debian's main archive. Even if >> I didn't think the package's build system is a problem, the ftpmasters >> likely would. > > I btw thought of actually building wine-gecko using mingw instead of > just distributing the .cab. > > Just did not have the time to try it in the .spec file. > > This is also the 1 problem I see with distro inclusion here, so far > I just have it in my openSUSE buildservice repos. If Gecko is to be included as a requirement in the current fassion, I argue that it should be made packageable/installable from wine-git. I support Vincent's suggestion of "--disable-gecko-downloader", and would also like to see "--enable-gecko"/"--disable-gecko" to build the .cab file (on "make") and install it to the correct location (on "make install"). Or perhaps, a "make gecko"/"make install-gecko" pair (which would be more convenient for me as a package maintainer).

Nov. 17, 2009

Re: today's git broke winetricks gecko :-(

by Marcus Meissner

On Mon, Nov 16, 2009 at 11:29:51PM +0100, Ove Kaaven wrote: > Jacek Caban skrev: > > Well, I hope that a side effect of installation during wineprefix > > creation is that it will force packagers to package gecko <g> > > You can't *force* the creation of packages which would likely fail to > meet the requirements for inclusion into Debian's main archive. Even if > I didn't think the package's build system is a problem, the ftpmasters > likely would. I btw thought of actually building wine-gecko using mingw instead of just distributing the .cab. Just did not have the time to try it in the .spec file. This is also the 1 problem I see with distro inclusion here, so far I just have it in my openSUSE buildservice repos. Ciao, Marcus

Nov. 17, 2009

Re: today's git broke winetricks gecko :-(

by Vincent Povirk

On Mon, Nov 16, 2009 at 5:52 PM, Ove Kaaven <ovek(a)arcticnet.no> wrote: > (It is actually for similar reasons that binaries must be buildable on a > clean system (say, a build daemon), without any special (non-free) tools > or sourceless libraries. Magic libshell32.a in the source package fails > this requirement, and so does usage of non-free cabinet.dll to make cab > file.) I don't suppose the build could be fixed? "The wine-gecko build is unclean" is a separate issue from "Wine-gecko should/shouldn't be a run-time requirement". Both of them are important issues, and the unclean gecko build would still be important (if not as visible) without this change. I wouldn't expect anything less of Debian than to refuse to include wine-gecko in the free parts or as a download at startup for exactly the reasons you describe. I hope they do. These are valid concerns, and someone has to stubbornly insist that they be addressed, pointing to clear, inhuman policies. As for the run-time requirement, I think it's good for calling attention to the fact that gecko is a requirement for a fully functional Wine (even though configure doesn't warn about it) and that "when needed" is too late, but it's absolutely useless in terms of *forcing* packagers to do anything and much more annoying than it needs to be for calling attention to the requirement. (It also doesn't seem to actually find the .cab file, even though I'm sure I've put it in the right place, but that's a third issue that I'll have to test more carefully and possibly file a bug for.) Providing, say, an environment variable that one could use to specify a path of the .cab would make things much less annoying for me (I'd have a work-around for the aforementioned bug-or-user-error, and I wouldn't have to copy a .cab whenever I make a new wine install in a new directory, which is fairly often.) and would make 'winetricks gecko' fixable. You'd still see the message box when invoking wine for the first time absolutely any other way, or if you do it wrong, so I don't see the problem there. It also seems to me that a --disable-gecko-downloader configure switch that would disable the dialog COMPLETELY (even "when needed") would put gecko on equal footing with optional library requirements. It would mean: * You can warn about the perils of not having gecko at configure time. * If gecko is installed properly, it's used properly, installed at prefix creation time. * If gecko is not installed properly, programs that need it will simply fail, and you'll see an ERR in the console, as well as a nice "HTML rendering is disabled" message you wouldn't get from other components. -- Vincent Povirk

Nov. 16, 2009

Re: [RFC] Handle process token groups in server/file.c::sd_to_mode

by Ben Peddell

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rob Shearman wrote: > While I agree that there is a problem that needs to be fixed, I'm not > sure this is the right approach. I think you need to take a step back > and consider the meanings of the different SIDs in a token by default > and how they map wine running inside the Unix permissions model. For > example, maybe these mappings make sense: > > security_local_sid -> user + group + others > security_interactive_sid -> user + group + others > alias_users_sid -> user + group + others? > > Now it's likely that the bugs you are trying to fix are trying to set > the SD for a file to alias_admins_sid or alias_users_sid. The mapping > for alias_admins_sid is less clear - one could argue that all Wine > users on a given system would present themselves as admins to apps, > but then again the apps may be restricting permissions on a file > because it contains sensitive data and should only be shared with > other admins (which would be trusted as such, unlike other users on a > system). > Currently, the wine NT DACL -> unix permission code works as follows: * The permissions start as deny all. * If the world SID is granted a permission, then that permission is added to both owner and others. * If the owner SID is explicitly granted a permission, then that permission is added to owner. * If the world SID is denied a permission, then that permission is removed from both owner and others. * If the owner SID is explicitly denied a permission, then that permission is removed from owner. This means that if neither owner nor world are listed in the NT DACL, the owner of the file is denied all permissions on that file, even if they would have been granted access by one of their groups. Windows Access Control Lists act as a series of grant/deny Access Control Entries, and the entire Access Control List must be consulted to determine the rights of the user. If none of the user, the user's groups or the world SID are mentioned in the DACL, then that user is denied all permissions. No SIDs are treated specially (not even SYSTEM). Unix permissions and Access Control Lists act as a set of definitive Access Control Entries, and the first Access Control Entry that applies to the user or one of their groups is used to determine the rights of the user. The superuser is treated specially, and is always granted permission (unless squashed by the filesystem or a security module). As the owner permission is consulted before any entries in the ACL, the owner permission cannot be overridden by an entry in the ACL. I have modified my patch to only check the groups in the process token if the owner of the process is the owner of the file. This patch: * in server/token.c: * exposes token_sid_present(), which tests whether an SID is present in the token. * in server/file.c::sd_to_mode(): * Sets the local boolean variable user_is_owner if the owner of the process and the owner of the file are the same. * Denies permissions from the owner of the file if user_is_owner is true and the SID denying permissions is present in the token. * Grants permissions to the owner of the file if user_is_owner is true and the SID granting permissions is present in the token, and is not a deny-only SID. The patch seeks to ensure that the owner of the file is granted and/or denied permissions based on the permissions of their groups. At the moment, it only does this if the owner of the file is also the owner of the process, as I don't know how to look up the groups of other users. The only other way I can see of doing this is to pre-process the SID and add a grant and/or deny ACE for the owner based on the access given by their groups. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksB7AoACgkQTHDAI68NsumA4wCfc61LXxavFTe82jXC2DjTMrXH iN0An3+hI0dFBYbsb7hY3JRyjXTD0eD3 =Ch74 -----END PGP SIGNATURE----- server/file.c | 7 +++++-- server/security.h | 1 + server/token.c | 2 +- 3 files changed, 7 insertions(+), 3 deletions(-) diff --git a/server/file.c b/server/file.c index a74de14..db9dd5f 100644 --- a/server/file.c +++ b/server/file.c @@ -461,6 +461,7 @@ mode_t sd_to_mode( const struct security_descriptor *sd, const SID *owner ) if (present && dacl) { const ACE_HEADER *ace = (const ACE_HEADER *)(dacl + 1); + int user_is_owner = security_equal_sid( owner, token_get_user( current->process->token) ); ULONG i; for (i = 0; i < dacl->AceCount; i++, ace = ace_next( ace )) { @@ -485,7 +486,8 @@ mode_t sd_to_mode( const struct security_descriptor *sd, const SID *owner ) if (access & FILE_EXECUTE) denied_mode |= S_IXUSR|S_IXGRP|S_IXOTH; } - else if (security_equal_sid( sid, owner )) + else if (security_equal_sid( sid, owner ) || + (user_is_owner && token_sid_present( current->process->token, sid, 1 ))) { unsigned int access = generic_file_map_access( ad_ace->Mask ); if (access & FILE_READ_DATA) @@ -509,7 +511,8 @@ mode_t sd_to_mode( const struct security_descriptor *sd, const SID *owner ) if (access & FILE_EXECUTE) new_mode |= S_IXUSR|S_IXGRP|S_IXOTH; } - else if (security_equal_sid( sid, owner )) + else if (security_equal_sid( sid, owner ) || + (user_is_owner && token_sid_present( current->process->token, sid, 0 ))) { unsigned int access = generic_file_map_access( aa_ace->Mask ); if (access & FILE_READ_DATA) diff --git a/server/security.h b/server/security.h index 39b1d2f..33cf5da 100644 --- a/server/security.h +++ b/server/security.h @@ -55,6 +55,7 @@ extern int token_check_privileges( struct token *token, int all_required, extern const ACL *token_get_default_dacl( struct token *token ); extern const SID *token_get_user( struct token *token ); extern const SID *token_get_primary_group( struct token *token ); +extern int token_sid_present( struct token *token, const SID *sid, int deny); static inline const ACE_HEADER *ace_next( const ACE_HEADER *ace ) { diff --git a/server/token.c b/server/token.c index ce896ac..461e79d 100644 --- a/server/token.c +++ b/server/token.c @@ -776,7 +776,7 @@ int token_check_privileges( struct token *token, int all_required, return (enabled_count > 0); } -static int token_sid_present( struct token *token, const SID *sid, int deny ) +int token_sid_present( struct token *token, const SID *sid, int deny ) { struct group *group;

Nov. 16, 2009

Re: today's git broke winetricks gecko :-(

by Ben Klein

2009/11/17 Juan Lang <juan.lang(a)gmail.com>: >> However, I refuse to force the Wine >> package to depend on it because this wine-gecko-1.0 package doubles >> the required download (7.8MB wine-gecko-1.0, 7.8MB wine 1.1.33 >> package). I realise that this will not be required to download on >> every upgrade, but I also can't predict when wine-gecko releases are >> made. > > What's the download size got to do with anything? Do you want to > force people to use an old, unsupported version of Wine because its > download size is smaller? Please, don't conflate unrelated issues. If a previously-optional component is now deemed to be mandatory, and that component *on its own* happens to double the download size required to install Wine, I consider that a problem. Not everyone has a cable or ADSL2+ connection. >> say it is". If this was something like, e.g., my decision to not >> separate OpenGL from the core Wine package, it wouldn't be a real >> problem (OpenGL support is used by the majority of Wine users, and >> takes up very little space in the binary distrobution), but it's not. > > Says who? Don't make unsupported claims, please. I've never used > OpenGL support in Wine, but I have used gecko. Most users, espcecially new users, seem to want to use Wine for games. Perhaps they are merely the most vocal. > Jacek's justification has been the number of bugs that are closed > invalid due to an invalid configuration. Strongly encouraging people > to install gecko would reduce the time we all spend looking at bogus > bug reports. Personally, I think that's worth considering, especially > because developer man hours are perhaps the most scarce resource for > the Wine project. I understand this, but it's a quick-fix to a problem that has long-term ramifications which were not even considered when the decision was made. It is simply not satisfactory that ALL use-cases of Wine now present the users with the "you need Gecko" dialog. >wine cmd /c echo yes now downloads gecko. How can you possibly justify this?

Nov. 16, 2009

Re: today's git broke winetricks gecko :-(

by Ove Kaaven

Jacek Caban skrev: > Ove Kaaven wrote: >> Jacek Caban skrev: >> >>> Well, I hope that a side effect of installation during wineprefix >>> creation is that it will force packagers to package gecko <g> >>> >> >> You can't *force* the creation of packages which would likely fail to >> meet the requirements for inclusion into Debian's main archive. Even if >> I didn't think the package's build system is a problem, the ftpmasters >> likely would. >> > > Then I can't see better solution for Debian users than downloading Gecko > on wineprefix creation. It's not perfect, but we don't have much choice. It really should be optional. Making it mandatory for a program to go out on the Internet, download 'untrusted' binaries, and then running them, without the user actually having (and knowing) a reason for the program to do this, might be too much for some security-conscious (and spyware-hating) people to handle. Debian packagers have been forced to turn off that kind of automatic behaviour before. Hence, it's possible that downloading Gecko on wineprefix creation is not a solution for Debian users at all, and that any attempt at this will result in a release-critical bug (with a "security problem" tag to boot, claiming "a dns spoof could mean someone could control your computer" etc) requiring this to be turned off in the Debian package. (It is actually for similar reasons that binaries must be buildable on a clean system (say, a build daemon), without any special (non-free) tools or sourceless libraries. Magic libshell32.a in the source package fails this requirement, and so does usage of non-free cabinet.dll to make cab file.) Maybe I could ask on debian-devel if there's a good way to handle this, maybe someone can come up with a good answer beyond the typical "upstream developers suck", or at least agree that a kludgy package might be acceptable in this case. (I'd need some time to prepare something to ask, though.) But in any case, I really don't think Gecko should be any less optional than, say, OpenGL, lcms, or ALSA/OSS/etc, without which Wine will reduce functionality (even at runtime, not only compile time), but still allow programs that don't need that functionality to work. You don't need CUPS to run games and you don't need OpenGL to run Office, why should you need Gecko for anything that won't ever do any HTML rendering? There's often much to be said for only installing what you need... and some people like that. (Wasn't there a reason Gentoo was popular?)

Nov. 16, 2009

Re: today's git broke winetricks gecko :-(

by Juan Lang

> However, I refuse to force the Wine > package to depend on it because this wine-gecko-1.0 package doubles > the required download (7.8MB wine-gecko-1.0, 7.8MB wine 1.1.33 > package). I realise that this will not be required to download on > every upgrade, but I also can't predict when wine-gecko releases are > made. What's the download size got to do with anything? Do you want to force people to use an old, unsupported version of Wine because its download size is smaller? Please, don't conflate unrelated issues. > say it is". If this was something like, e.g., my decision to not > separate OpenGL from the core Wine package, it wouldn't be a real > problem (OpenGL support is used by the majority of Wine users, and > takes up very little space in the binary distrobution), but it's not. Says who? Don't make unsupported claims, please. I've never used OpenGL support in Wine, but I have used gecko. Jacek's justification has been the number of bugs that are closed invalid due to an invalid configuration. Strongly encouraging people to install gecko would reduce the time we all spend looking at bogus bug reports. Personally, I think that's worth considering, especially because developer man hours are perhaps the most scarce resource for the Wine project. --Juan

Nov. 16, 2009

Re: today's git broke winetricks gecko :-(

by Ben Klein

2009/11/17 Jacek Caban <jacek(a)codeweavers.com>: > I can see three types of Wine users: > > - regular users > They use Wine packages that should guarantee presence of Gecko (as Wine > dependency or in Wine package, depends on packagers preferences). The > current situation will probably force packagers to do the right thing <g> > > - Wine developers > I'm surprised how many developers are affected by this change. It means that > developers were not aware of the right way to install Gecko (probably > because winetricks is too good :-) ). I'm sure it will change now. > > - Users who compile Wine themselves > Well... the information about proper Gecko installation is easy to find and > it's pointed on every wineprefix creation. They should survive as long as > they read what's . > > Given that, I think this change will force changes that will allow us to > forget about the problem soon. You're missing a type of user that has been quite vocal on this thread: - Users who have no need for Gecko These are "regular users" who don't use applications or games that require MSHTML/Gecko/IE6/whatever. They don't view .chm files either, and most of them don't run the test suite. This group has been completely forgotten in the decision to force Gecko. OK, so you can hit "Cancel" to stop the download. This is *not* satisfactory. As it is at the moment, Gecko sits half-way between an opt-in and an opt-out system. It should be made one or the other - either force it to be installed (by all package maintainers) on first install and then have it optionally removed *without* causing a stupid pop-up box saying it's missing, or have a button in winecfg or similar that downloads it if it is missing. As the maintainer of WineHQ's Debian packages, I have produced a new wine-gecko-1.0 package for use with 1.1.33, something that I was considering for a long time. However, I refuse to force the Wine package to depend on it because this wine-gecko-1.0 package doubles the required download (7.8MB wine-gecko-1.0, 7.8MB wine 1.1.33 package). I realise that this will not be required to download on every upgrade, but I also can't predict when wine-gecko releases are made. Currently, the wine-gecko-1.0 package I have produced depends on Wine. I may need to rethink this to cater for user groups 2 and 3 above. Furthermore, I have not yet packaged earlier versions of wine-gecko for use with earlier versions of Wine, but I believe I have had the foresight to think of this potential situation. This is in direct contrast to the obviously low about of thought that went into the change to how Wine downloads Gecko. 2009/11/17 Jacek Caban <jacek(a)codeweavers.com>: >> You can't *force* the creation of packages which would likely fail to >> meet the requirements for inclusion into Debian's main archive. Even if >> I didn't think the package's build system is a problem, the ftpmasters >> likely would. > > Then I can't see better solution for Debian users than downloading Gecko on > wineprefix creation. It's not perfect, but we don't have much choice. It shouldn't even be an option. What's wrong with adding an opt-in button to "winecfg"? The rigidity of proponents of the "new way" is disheartening. The feeling coming across is "this way is better for everyone because we say it is". If this was something like, e.g., my decision to not separate OpenGL from the core Wine package, it wouldn't be a real problem (OpenGL support is used by the majority of Wine users, and takes up very little space in the binary distrobution), but it's not. Gecko is purely optional (although not recommended, "winetricks ie6" does get some apps working where Gecko doesn't), and quite large.

Nov. 16, 2009

Re: today's git broke winetricks gecko :-(

by Steven Edwards

On Mon, Nov 16, 2009 at 12:58 PM, Jacek Caban <jacek(a)codeweavers.com> wrote: > You should understand, that we don't want users to have problems due to > *lack* of Gecko. Any solution like moving installation to winecfg means that > most user (at least these, who don't get Gecko from their distro packages) > will have this problem. You also didn't give me any single good reason to > not install Gecko properly. Instead you just said that you pollute winetest > results with your bad configuration. Isn't winetest web configured to reject certain classes of test results already? I seem to recall Alexandre adding some magic to winetest and the site to reject reports or flag them if they were with a sha1hash that did not match a git revision. Could we not do something like this with gecko? If it's not installed then just ignore those results? -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

Nov. 16, 2009

Re: today's git broke winetricks gecko :-(

by Jacek Caban

Ove Kaaven wrote: > Jacek Caban skrev: > >> Well, I hope that a side effect of installation during wineprefix >> creation is that it will force packagers to package gecko <g> >> > > You can't *force* the creation of packages which would likely fail to > meet the requirements for inclusion into Debian's main archive. Even if > I didn't think the package's build system is a problem, the ftpmasters > likely would. > Then I can't see better solution for Debian users than downloading Gecko on wineprefix creation. It's not perfect, but we don't have much choice. Jacek

Nov. 16, 2009

Re: today's git broke winetricks gecko :-(

by Ove Kaaven

Jacek Caban skrev: > Well, I hope that a side effect of installation during wineprefix > creation is that it will force packagers to package gecko <g> You can't *force* the creation of packages which would likely fail to meet the requirements for inclusion into Debian's main archive. Even if I didn't think the package's build system is a problem, the ftpmasters likely would.

Nov. 16, 2009

Re: [PATCH] jscript: Implement decodeURIComponent

by Andrew Eikum

Jacek Caban wrote: > Hi Andrew, > > Andrew Eikum wrote: >> --- >> dlls/jscript/global.c | 104 >> ++++++++++++++++++++++++++++++++++++++++++++- >> dlls/jscript/tests/api.js | 20 +++++++++ >> 2 files changed, 122 insertions(+), 2 deletions(-) >> > > > + while(*ptr == '%') { > + if(hex_to_int(*(ptr+1)) < 0 || hex_to_int(*(ptr+2)) < 0) { > + WARN("Invalid hex sequence: 0x%x 0x%x\n", *(ptr+1), > *(ptr+2)); > + SysFreeString(str); > + return E_FAIL; > > URIError should be thrown here. If it's not, then you should put FIXME > here. Same for other places where you return E_FAIL. > > + } > + ptr += 3; > + ++buf_len; > + } > + octets = heap_alloc(buf_len); > > > You don't check allocation failure and leak octets here. You may avoid > dynamic allocation at all by processing one utf8 char at the time. Then > you know that it's not longer than 4 bytes. Ecma specification describes > it well, although you may simplify the algorithm by checking number of > bytes from the first byte, fetching bytes to the array and then use > MultiByteToWideChar for conversion to UTF-16 and validation. > > > Thanks, > Jacek > Thanks for looking it over, Jacek. I've resent with your suggestions. Andrew

Nov. 16, 2009

Re: [PATCH] jscript: Implement decodeURIComponent

by Jacek Caban

Hi Andrew, Andrew Eikum wrote: > --- > dlls/jscript/global.c | 104 > ++++++++++++++++++++++++++++++++++++++++++++- > dlls/jscript/tests/api.js | 20 +++++++++ > 2 files changed, 122 insertions(+), 2 deletions(-) > + while(*ptr == '%') { + if(hex_to_int(*(ptr+1)) < 0 || hex_to_int(*(ptr+2)) < 0) { + WARN("Invalid hex sequence: 0x%x 0x%x\n", *(ptr+1), *(ptr+2)); + SysFreeString(str); + return E_FAIL; URIError should be thrown here. If it's not, then you should put FIXME here. Same for other places where you return E_FAIL. + } + ptr += 3; + ++buf_len; + } + octets = heap_alloc(buf_len); You don't check allocation failure and leak octets here. You may avoid dynamic allocation at all by processing one utf8 char at the time. Then you know that it's not longer than 4 bytes. Ecma specification describes it well, although you may simplify the algorithm by checking number of bytes from the first byte, fetching bytes to the array and then use MultiByteToWideChar for conversion to UTF-16 and validation. Thanks, Jacek

Nov. 16, 2009

Re: today's git broke winetricks gecko :-(

by Jacek Caban

Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Jacek, > > >>> - I tried to think positively about it and expected the winetest-1.1.33.exe >>> to install Gecko and perform the mshtml tests when online. Curiously they >>> were skipped. I have yet to find out why. >>> >> Did you read the page from the link that is on the dialog informing >> about missing Gecko? >> > > What part from wiki/Gecko did you have in mind? > Regarding the above, I see the following explanation: > http://wiki.winehq.org/Gecko > >> Wine 1.1.33 and later will download Gecko when a prefix is created. >> 'If your distribution of Wine doesn't put the .cab file in the right place for you, you can avoid problems by putting it there yourself as follows: (...)' > Aha -- I did not run winetest creating a prefix at the same time. > I created the prefix earlier, running winecfg. So that's why winetest did > not download Gecko and why I saw no dialog box at winetest time. > >> I can see three types of Wine users: >> > I don't find myself in the description you gave. > You're a user compiling Wine himself. > I've a feeling that I'm misunderstood. I have nothing against > Gecko. I simply tend to test apps in a minimal configuration > environment. Optional packages like Gecko are not part of that > environment, and I always saw a risk that a nMB third-party Gecko > package introduces its own bugs when I want to find out about > the ones in Wine (or the app). > If you run winetest, you *should* have Gecko installed. Otherwise your test results are confusing. Also bugs in Gecko are as bad for Wine as Wine own bugs. Consider Gecko as a part of mshtml.dll. > None but three of the many apps that I've tested depended on HTML/Gecko. > That is my experience. Sometimes, when I thought Gecko should be > needed (to view advanced .hlp or .chm files), I tested with Gecko > -- or so I thought -- but it didn't help rendering the .hlp pages > (witness bug #17682). > .chm files require Gecko and if they don't work, it's due to bugs that you claim to want to find. >> allow us to forget about the problem soon >> > What actually is *the* problem? > The problem is that you have to click install during wineprefix creation. The fix is to install Gecko correctly. > It seems to me like "Gecko is not compulsory" is the problem in > your eyes, isn't it? > It's surely strongly recommended. The configuration without Gecko is still possible, you just have to click cancel. No better solution was proposed so far. > This is not my experience. To me, Gecko appears strictly > optional, and rarely needed (for the kind of apps that I'm running). > I've no problem with the Wine team now declaring Gecko as compulsory, > and would then start to use it. But the wiki/Gecko page right now > does not say that it is so. > Feel free to change wiki. > My problem, namely rm -rf ~/.wine; wine /c cmd or wine xyz > hanging in a dialog box or believing that it is allowed to access > the network, then of course would go away > (at the cost of a larger .wine tree). > Again, install Gecko properly if you don't want the dialog box. You should understand, that we don't want users to have problems due to *lack* of Gecko. Any solution like moving installation to winecfg means that most user (at least these, who don't get Gecko from their distro packages) will have this problem. You also didn't give me any single good reason to not install Gecko properly. Instead you just said that you pollute winetest results with your bad configuration. Jacek

Nov. 16, 2009

Re: today's git broke winetricks gecko :-(

by Joerg-Cyril.Hoehle＠t-systems.com

Jacek, >> - I tried to think positively about it and expected the winetest-1.1.33.exe >> to install Gecko and perform the mshtml tests when online. Curiously they >> were skipped. I have yet to find out why. >Did you read the page from the link that is on the dialog informing >about missing Gecko? What part from wiki/Gecko did you have in mind? Regarding the above, I see the following explanation: http://wiki.winehq.org/Gecko >Wine 1.1.33 and later will download Gecko when a prefix is created. Aha -- I did not run winetest creating a prefix at the same time. I created the prefix earlier, running winecfg. So that's why winetest did not download Gecko and why I saw no dialog box at winetest time. >I can see three types of Wine users: I don't find myself in the description you gave. I've a feeling that I'm misunderstood. I have nothing against Gecko. I simply tend to test apps in a minimal configuration environment. Optional packages like Gecko are not part of that environment, and I always saw a risk that a nMB third-party Gecko package introduces its own bugs when I want to find out about the ones in Wine (or the app). None but three of the many apps that I've tested depended on HTML/Gecko. That is my experience. Sometimes, when I thought Gecko should be needed (to view advanced .hlp or .chm files), I tested with Gecko -- or so I thought -- but it didn't help rendering the .hlp pages (witness bug #17682). >allow us to forget about the problem soon What actually is *the* problem? It seems to me like "Gecko is not compulsory" is the problem in your eyes, isn't it? This is not my experience. To me, Gecko appears strictly optional, and rarely needed (for the kind of apps that I'm running). I've no problem with the Wine team now declaring Gecko as compulsory, and would then start to use it. But the wiki/Gecko page right now does not say that it is so. My problem, namely rm -rf ~/.wine; wine /c cmd or wine xyz hanging in a dialog box or believing that it is allowed to access the network, then of course would go away (at the cost of a larger .wine tree). Regards, Jörg Höhle.

Nov. 16, 2009

Re: WineD3D: fix bug 20522

by Alexandre Julliard

Roderick Colenbrander <thunderbird2k(a)gmail.com> writes: > This patch fixes bug 20522 which was uncovered by 32-bit dibsection > support. I have added a test to show that the patch is correct. Like > with Blt the results varry depending on the drivers. It doesn't work here: ../../../tools/runtest -q -P wine -M ddraw.dll -T ../../.. -p ddraw_test.exe.so visual.c && touch visual.ok visual.c:2349: Test failed: got R 80 G 00 B 00, expected R 00 G FF B 00 make: *** [visual.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

Nov. 16, 2009

Re: today's git broke winetricks gecko :-(

by Jacek Caban

Marcus Meissner wrote: > On Mon, Nov 16, 2009 at 05:08:21PM +0100, Jacek Caban wrote: > >> Well, I hope that a side effect of installation during wineprefix >> creation is that it will force packagers to package gecko <g> The >> brutal true is that we had a very bad situation for a long time. I >> can see three types of Wine users: >> >> - regular users >> They use Wine packages that should guarantee presence of Gecko (as >> Wine dependency or in Wine package, depends on packagers >> preferences). The current situation will probably force packagers to >> do the right thing <g> >> > > The Wine packages for openSUSE now do the right thing, since last Friday ;) > It will hopefully get this way into openSUSE 11.3 too. > Thanks! I've added openSUSE to the list on: http://wiki.winehq.org/Gecko It would be great if others could update the list for their distros. AFAIK Ubuntu packages also support Gecko, but I've never touched it, so I can't be sure. I don't know about other distros. Jacek

Nov. 16, 2009

Re: [RFC] Handle process token groups in server/file.c::sd_to_mode

by Rob Shearman

2009/11/16 Ben Peddell <klightspeed(a)netspace.net.au>: > This proposed patch (which I believe will contribute toward solving bugs > 17672, 19588 and 20643, and any others where the permissions are set too > restrictive) exposes the token_sid_present call in token.c, > and uses it to check the SIDs in the security descriptor against those > in the process token. > > Are there any changes anyone can think of before I submit it to > wine-patches? > > Is there a better (already exposed) way of checking a SID against the > process token's group list? Hi Ben, While I agree that there is a problem that needs to be fixed, I'm not sure this is the right approach. I think you need to take a step back and consider the meanings of the different SIDs in a token by default and how they map wine running inside the Unix permissions model. For example, maybe these mappings make sense: security_local_sid -> user + group + others security_interactive_sid -> user + group + others alias_users_sid -> user + group + others? Now it's likely that the bugs you are trying to fix are trying to set the SD for a file to alias_admins_sid or alias_users_sid. The mapping for alias_admins_sid is less clear - one could argue that all Wine users on a given system would present themselves as admins to apps, but then again the apps may be restricting permissions on a file because it contains sensitive data and should only be shared with other admins (which would be trusted as such, unlike other users on a system). -- Rob Shearman

Nov. 16, 2009

Re: today's git broke winetricks gecko :-(

by Marcus Meissner

On Mon, Nov 16, 2009 at 05:08:21PM +0100, Jacek Caban wrote: > Well, I hope that a side effect of installation during wineprefix > creation is that it will force packagers to package gecko <g> The > brutal true is that we had a very bad situation for a long time. I > can see three types of Wine users: > > - regular users > They use Wine packages that should guarantee presence of Gecko (as > Wine dependency or in Wine package, depends on packagers > preferences). The current situation will probably force packagers to > do the right thing <g> The Wine packages for openSUSE now do the right thing, since last Friday ;) It will hopefully get this way into openSUSE 11.3 too. Ciao, Marcus

Nov. 16, 2009