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

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

by Jacek Caban

Tom Wickline wrote: > Jacek, > > How does this work off line? If Wine cant download and install gecko > at wineprefix > creation then Wine wont work? And if so every time you create a > wineprefix your going to > have to be connected and the server is going to have to be up 100% of > the time or Wine > wont properly create a prefix.. You could time out and move to a > backup server but it still > begs the question of what if the servers are down, then what? > > Can you please comment on this.. The answer is not to use the downloader. You've just given another reasons to install Gecko properly. Jacek

Nov. 16, 2009

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

by Jacek Caban

Steven Edwards wrote: > Hi Jacek, > > On Mon, Nov 16, 2009 at 10:16 AM, Jacek Caban <jacek(a)codeweavers.com> wrote: > >> Did you read the page from the link that is on the dialog informing about >> missing Gecko? >> > > I've been kind of following this thread and see where Jörg is coming > from. I don't think the argument about broken wine due to missing > gecko makes much sense given the way we have other soft dependencies > that can be missing if you build Wine yourself. A good example is the > xml or opengl libraries. It's possible to have a working wine for > specific needs without this package. If we are going to require this > package for every wine install then I would argue we should not have > any other soft dependencies either. > These dependences are different because they are Linux dependences. There is no way we could tread Gecko the same way. > If a packager has not packaged Gecko or a hacker has built from source > it seems like winecfg should be invoked when a new prefix is created > rather than prompting for the download. Maybe for the general usage > case we should do it anyway. Alternatively, if we are going to have > this hook in here to satisfy this dependency during prefix creation > due to packagers not following a required guideline, maybe a little > public ridicule will force them to fix the package. Something along > the lines of 'your version of wine does not contain the gecko package, > please contact the package maintainer and inform them about this > issue' or something and let it proceed to download at least. > 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> - 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. Jacek

Nov. 16, 2009

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

by Tom Wickline

On Mon, Nov 16, 2009 at 11:38 PM, Steven Edwards <winehacker(a)gmail.com>wrote: > Hi Jacek, > > On Mon, Nov 16, 2009 at 10:16 AM, Jacek Caban <jacek(a)codeweavers.com> > wrote: > > Did you read the page from the link that is on the dialog informing about > > missing Gecko? > > I've been kind of following this thread and see where Jörg is coming > from. I don't think the argument about broken wine due to missing > gecko makes much sense given the way we have other soft dependencies > that can be missing if you build Wine yourself. A good example is the > xml or opengl libraries. It's possible to have a working wine for > specific needs without this package. If we are going to require this > package for every wine install then I would argue we should not have > any other soft dependencies either. > > If a packager has not packaged Gecko or a hacker has built from source > it seems like winecfg should be invoked when a new prefix is created > rather than prompting for the download. Maybe for the general usage > case we should do it anyway. Alternatively, if we are going to have > this hook in here to satisfy this dependency during prefix creation > due to packagers not following a required guideline, maybe a little > public ridicule will force them to fix the package. Something along > the lines of 'your version of wine does not contain the gecko package, > please contact the package maintainer and inform them about this > issue' or something and let it proceed to download at least. > > > -- > 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 > > > Jacek, How does this work off line? If Wine cant download and install gecko at wineprefix creation then Wine wont work? And if so every time you create a wineprefix your going to have to be connected and the server is going to have to be up 100% of the time or Wine wont properly create a prefix.. You could time out and move to a backup server but it still begs the question of what if the servers are down, then what? Can you please comment on this.. Tom

Nov. 16, 2009

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

by Ben Peddell

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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? - ---- server/file.c | 6 ++++-- server/security.h | 1 + server/token.c | 2 +- 3 files changed, 6 insertions(+), 3 deletions(-) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksBcpAACgkQTHDAI68Nsuny6ACfXu3vvWS6O27Z/mfozb4e/ZMG MYQAoItP8P75a3l54TYrLnQbk7lNyaaQ =7QsU -----END PGP SIGNATURE----- server/file.c | 6 ++++-- server/security.h | 1 + server/token.c | 2 +- 3 files changed, 6 insertions(+), 3 deletions(-) diff --git a/server/file.c b/server/file.c index a74de14..793c24a 100644 --- a/server/file.c +++ b/server/file.c @@ -485,7 +485,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 ) || + 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 +510,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 ) || + 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 Steven Edwards

Hi Jacek, On Mon, Nov 16, 2009 at 10:16 AM, Jacek Caban <jacek(a)codeweavers.com> wrote: > Did you read the page from the link that is on the dialog informing about > missing Gecko? I've been kind of following this thread and see where Jörg is coming from. I don't think the argument about broken wine due to missing gecko makes much sense given the way we have other soft dependencies that can be missing if you build Wine yourself. A good example is the xml or opengl libraries. It's possible to have a working wine for specific needs without this package. If we are going to require this package for every wine install then I would argue we should not have any other soft dependencies either. If a packager has not packaged Gecko or a hacker has built from source it seems like winecfg should be invoked when a new prefix is created rather than prompting for the download. Maybe for the general usage case we should do it anyway. Alternatively, if we are going to have this hook in here to satisfy this dependency during prefix creation due to packagers not following a required guideline, maybe a little public ridicule will force them to fix the package. Something along the lines of 'your version of wine does not contain the gecko package, please contact the package maintainer and inform them about this issue' or something and let it proceed to download at least. -- 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

Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Hi, > > >> wine cmd /c echo yes now downloads gecko. >> > > Me to -- I'm not pleased with Wine-1.1.33 starting an installation request upon startup. > - How am I going to automate regression testing when it hangs waiting for a mouse click? > - 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? Jacek

Nov. 16, 2009

today's git broke winetricks gecko :-(

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

Hi, >wine cmd /c echo yes now downloads gecko. Me to -- I'm not pleased with Wine-1.1.33 starting an installation request upon startup. - How am I going to automate regression testing when it hangs waiting for a mouse click? - 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. >Any suggestions are welcome. Winecfg would be a better place to propose the installation of an optional component. Perhaps I'm a very atypical Wine user: - no MMORPG, no ie6 - My Wine is not used for anything online. Quite to the contrary, I have some iptables firewall rules to disable Wine IP traffic should anything ever manage to get in. - I never used winetricks. I sometimes peeked at it. When I needed Gecko long ago, I saw that the Wine source contains code to install it, downloaded Gecko.cab myself, modified the one registry entry to point to the .cab and let it install. Worked. IMHO, no general-purpose application should attempt to talk to the internet when it starts. Please leave that behaviour to viruses and trojans only (and alikes, e.g. Adobe's pdf). Maybe I'm too old-fashioned in this decade of "always online even in the subway" technical achievements. Or I've been in the privacy-protection (Datenschutz) and security business for too long. Regarding winecfg, it could display "no Gecko/HTML support, click here to install it (need be online)" in flashing red to attract the user's attention once you start it. I wouldn't mind. Regards, Jörg Höhle.

Nov. 16, 2009

Re: comctl32/listview: use the infile ImageListRelease

by André Hentschel

Nikolay Sivov schrieb: > Hi, Andre. > > Could you please wait with that? I have some similar patches already sent... > > On 11/16/09, André Hentschel <nerv(a)dawncrow.de> wrote: >> Otherwise Apps crash on exit(e.g. uninstaller) >> --- >> dlls/comctl32/imagelist.c | 3 ++- >> 1 files changed, 2 insertions(+), 1 deletions(-) >> >> diff --git a/dlls/comctl32/imagelist.c b/dlls/comctl32/imagelist.c >> index 82d2664..44084fd 100644 >> --- a/dlls/comctl32/imagelist.c >> +++ b/dlls/comctl32/imagelist.c >> @@ -81,6 +81,7 @@ static INTERNALDRAG InternalDrag = { 0, 0, 0, 0, 0, 0, >> FALSE, 0 }; >> >> static HBITMAP ImageList_CreateImage(HDC hdc, HIMAGELIST himl, UINT count, >> UINT width); >> static HRESULT ImageListImpl_CreateInstance(const IUnknown *pUnkOuter, >> REFIID iid, void** ppv); >> +static ULONG WINAPI ImageListImpl_Release(IImageList *iface); >> >> static inline BOOL is_valid(HIMAGELIST himl) >> { >> @@ -716,7 +717,7 @@ ImageList_Destroy (HIMAGELIST himl) >> DeleteObject (himl->hbrBlend50); >> >> /* Free the IImageList instance */ >> - IImageList_Release((IImageList *) himl); >> + ImageListImpl_Release((IImageList *) himl); >> return TRUE; >> } >> >> -- >> >> Best Regards, André Hentschel >> >> >> > > ok, of course! -- Best Regards, André Hentschel

Nov. 16, 2009

Re: [PATCH 2/2] dsound: Simplify duplex code

by Alexandre Julliard

Maarten Lankhorst <m.b.lankhorst(a)gmail.com> writes: > @@ -48,37 +50,20 @@ typedef struct IDirectSoundFullDuplexImpl > > /* IDirectSoundFullDuplexImpl fields */ > DirectSoundDevice *renderer_device; > - DirectSoundCaptureDevice *capture_device; > - > - LPUNKNOWN pUnknown; > - LPDIRECTSOUND pDS; > - LPDIRECTSOUND8 pDS8; > - LPDIRECTSOUNDCAPTURE pDSC; > + IDirectSoundCapture *capture_device; > + > + const IUnknownVtbl *lpUnkVtbl; > + const IDirectSoundVtbl *lpDSVtbl; > + const IDirectSound8Vtbl *lpDS8Vtbl; > + const IDirectSoundCaptureVtbl *lpDSCVtbl; > + LONG unk_ref; > + LONG ds_ref; > + LONG ds8_ref; > + LONG dsc_ref; > } IDirectSoundFullDuplexImpl; > > -typedef struct IDirectSoundFullDuplex_IUnknown { > - const IUnknownVtbl *lpVtbl; > - LONG ref; > - IDirectSoundFullDuplexImpl *pdsfd; > -} IDirectSoundFullDuplex_IUnknown; > - > -typedef struct IDirectSoundFullDuplex_IDirectSound { > - const IDirectSoundVtbl *lpVtbl; > - LONG ref; > - IDirectSoundFullDuplexImpl *pdsfd; > -} IDirectSoundFullDuplex_IDirectSound; > - > -typedef struct IDirectSoundFullDuplex_IDirectSound8 { > - const IDirectSound8Vtbl *lpVtbl; > - LONG ref; > - IDirectSoundFullDuplexImpl *pdsfd; > -} IDirectSoundFullDuplex_IDirectSound8; > - > -typedef struct IDirectSoundFullDuplex_IDirectSoundCapture { > - const IDirectSoundCaptureVtbl *lpVtbl; > - LONG ref; > - IDirectSoundFullDuplexImpl *pdsfd; > -} IDirectSoundFullDuplex_IDirectSoundCapture; > +#define ICOM_THIS_MULTI(impl,field,iface) \ > + impl* const This=(impl*)((char*)(iface) - offsetof(impl,field)) Please define inline functions instead of ICOM_THIS_MULTI. Also the IUnknown vtable is most likely unnecessary. -- Alexandre Julliard julliard(a)winehq.org

Nov. 16, 2009

Re: [PATCH 1/3] user32: Free window text to prevent leak in case whenWM_NCDESTROY doesn't get to default procedure

by Nikolay Sivov

The only case why I left it was that I thought about app that directly sends this message for some insane reason. I just don't want to touch default handler. On 11/16/09, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: > "Nikolay Sivov" <bunglehead(a)gmail.com> wrote: > >> This fixes a leak spotted by valgrind. >> >> Changelog: >> - free window text to prevent leak in case when WM_NCDESTROY >> doesn't get to default procedure > > Then WM_NCDESTROY handler should be removed from DefWindowProc > to avoid a confusing duplication. > > -- > Dmitry. >

Nov. 16, 2009

Re: comctl32/listview: use the infile ImageListRelease

by Nikolay Sivov

Hi, Andre. Could you please wait with that? I have some similar patches already sent... On 11/16/09, André Hentschel <nerv(a)dawncrow.de> wrote: > Otherwise Apps crash on exit(e.g. uninstaller) > --- > dlls/comctl32/imagelist.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/dlls/comctl32/imagelist.c b/dlls/comctl32/imagelist.c > index 82d2664..44084fd 100644 > --- a/dlls/comctl32/imagelist.c > +++ b/dlls/comctl32/imagelist.c > @@ -81,6 +81,7 @@ static INTERNALDRAG InternalDrag = { 0, 0, 0, 0, 0, 0, > FALSE, 0 }; > > static HBITMAP ImageList_CreateImage(HDC hdc, HIMAGELIST himl, UINT count, > UINT width); > static HRESULT ImageListImpl_CreateInstance(const IUnknown *pUnkOuter, > REFIID iid, void** ppv); > +static ULONG WINAPI ImageListImpl_Release(IImageList *iface); > > static inline BOOL is_valid(HIMAGELIST himl) > { > @@ -716,7 +717,7 @@ ImageList_Destroy (HIMAGELIST himl) > DeleteObject (himl->hbrBlend50); > > /* Free the IImageList instance */ > - IImageList_Release((IImageList *) himl); > + ImageListImpl_Release((IImageList *) himl); > return TRUE; > } > > -- > > Best Regards, André Hentschel > > >

Nov. 16, 2009

Re: [PATCH] winex11.drv: check for org = NULL (Coverity)

by Roderick Colenbrander

On Mon, Nov 16, 2009 at 11:02 AM, Marcus Meissner <meissner(a)suse.de> wrote: > On Sun, Nov 15, 2009 at 10:37:27PM +0100, Roderick Colenbrander wrote: >> Hi Marcus, >> >> A couple of hours ago I submitted a patch rewrites the function. It >> suffers from the same 'issue'. This and any other wgl function are >> called from gdi32/opengl.c which perform magic to arrive here and in >> case of wglsharelists it also performs the filtering. > > Do I understand right that this is actually something we should mark > as FALSE or IGNORE in Coverity? Yeah, it can be set to ignore. Roderick

Nov. 16, 2009

Re: [PATCH] winex11.drv: check for org = NULL (Coverity)

by Marcus Meissner

On Sun, Nov 15, 2009 at 10:37:27PM +0100, Roderick Colenbrander wrote: > Hi Marcus, > > A couple of hours ago I submitted a patch rewrites the function. It > suffers from the same 'issue'. This and any other wgl function are > called from gdi32/opengl.c which perform magic to arrive here and in > case of wglsharelists it also performs the filtering. Do I understand right that this is actually something we should mark as FALSE or IGNORE in Coverity? Ciao, Marcus > Roderick > > On Sun, Nov 15, 2009 at 7:28 PM, Marcus Meissner <marcus(a)jet.franken.de> wrote: > > Hi, > > > > Coverity spotted some inconsistencies in "org" NULL > > checking. > > > > org originates via Windows code (I think) so we better check it. > > > > Ciao, Marcus > > --- > > dlls/winex11.drv/opengl.c | 8 ++++++-- > > 1 files changed, 6 insertions(+), 2 deletions(-) > > > > diff --git a/dlls/winex11.drv/opengl.c b/dlls/winex11.drv/opengl.c > > index 45da479..774b205 100644 > > --- a/dlls/winex11.drv/opengl.c > > +++ b/dlls/winex11.drv/opengl.c > > @@ -1918,11 +1918,15 @@ BOOL CDECL X11DRV_wglShareLists(HGLRC hglrc1, HGLRC hglrc2) { > > > > if (!has_opengl()) return FALSE; > > > > + if (NULL == org) { > > + ERR("Could not share display lists, original context required.\n"); > > + return FALSE; > > + } > > if (NULL != dest && dest->ctx != NULL) { > > - ERR("Could not share display lists, context already created !\n"); > > + ERR("Could not share display lists, context already created!\n"); > > return FALSE; > > } else { > > - if(org && dest && (GetObjectType(org->hdc) == OBJ_MEMDC) ^ (GetObjectType(dest->hdc) == OBJ_MEMDC)) { > > + if(dest && (GetObjectType(org->hdc) == OBJ_MEMDC) ^ (GetObjectType(dest->hdc) == OBJ_MEMDC)) { > > WARN("Attempting to share a context between a direct and indirect rendering context, expect issues!\n"); > > } > > > > -- > > 1.5.6 > > > > > > > -- Working, but not speaking, for the following german company: SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)

Nov. 16, 2009

Re: Working on avifil32, sudden "non enough memory" error

by Marcus Meissner

On Mon, Nov 16, 2009 at 10:52:04AM +0100, Julius Schwartzenberg wrote: > Dan Kegel wrote: > >Julius wrote: > >>With one file however (GOODTIME.AVI from the win95 cd) I get this > >>error after about a second: > >>err:heap:HEAP_ValidateInUseArena Heap 0x110000: in-use arena 0x184420 > >>next block has PREV_FREE flag > >>non enough memory > >> > >>I have no idea where this comes from and why it happens. (It appears to > >>be unrelated to the memcpy call in avifile.c around line 1114.) With > >>+heap I also get this before the error: > >>HIGHPERF/GOODTIME.AVI: heap.c:403: HEAP_GetPtr: Controletest '0' faalt. > >>(the assert fails) > > > >Sounds like heap corruption. You might want to cut down the > >file to the shortest one that causes the crash, then go > >after it (possibly using valgrind or the like) to look for > >the error. > > With valgrind I was able to find the problem actually happens when > AVIFILE_ReadBlock is called and a new block is about to be read. > There doesn't seem to be anything special about this however, as for > the previous blocks (and different files) it works just fine. You could insert HeapValidate(GetProcessHeap(),0,0);FIXME("at place x\n"); at multiple interesting places in your code and +heap will then trigger on when the corruption happens. Ciao, Marcus

Nov. 16, 2009

Re: Working on avifil32, sudden "non enough memory" error

by Julius Schwartzenberg

Dan Kegel wrote: > Julius wrote: >> With one file however (GOODTIME.AVI from the win95 cd) I get this >> error after about a second: >> err:heap:HEAP_ValidateInUseArena Heap 0x110000: in-use arena 0x184420 >> next block has PREV_FREE flag >> non enough memory >> >> I have no idea where this comes from and why it happens. (It appears to >> be unrelated to the memcpy call in avifile.c around line 1114.) With >> +heap I also get this before the error: >> HIGHPERF/GOODTIME.AVI: heap.c:403: HEAP_GetPtr: Controletest '0' faalt. >> (the assert fails) > > Sounds like heap corruption. You might want to cut down the > file to the shortest one that causes the crash, then go > after it (possibly using valgrind or the like) to look for > the error. With valgrind I was able to find the problem actually happens when AVIFILE_ReadBlock is called and a new block is about to be read. There doesn't seem to be anything special about this however, as for the previous blocks (and different files) it works just fine. > Does your implementation of avifil32 and friends work > properly on windows? It appears this is not trivial to test. I had to include Wine's advapi32.dll in addition to avifil32.dll and then I got an error about a missing Wine symbol in ntdll.dll. I understand this means I cannot trivially use this Wine dll on Windows. Thanks, Julius

Nov. 16, 2009

Re: [RFC] Extended Attributes for Dos Attributes, Creation Time, etc.

by Ben Peddell

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dan Kegel wrote: > Hi Ben, > did you see > http://bugs.winehq.org/show_bug.cgi?id=15679 > http://www.winehq.org/pipermail/wine-patches/2009-October/079842.html > ? > > IMHO the way the Samba sources merged the fd and filename > version of the calls makes for less duplication of code. > (I tried to do it the other way first, and it seemed ugly.) > - Dan I saw that, and that's at least part of why I created that extended attribute portability patch for libport. Serves as one location to fix any bugs in it, or extend the support to other platforms. I noticed that the portability functions in libport were each in their own separate C file, and that's why I did it like that. I can see what you're saying about duplication of code, and it would make sense to merge the xattr portability functions into a single C file (e.g. xattr.c). If there's a better place for the xattr portability code, please say so. I know it's unlikely to be merged until a few units actually start using extended attributes. Thinking about the NT ACL storage issue (brought up by bug #20643), rather than using xattrs for that, POSIX ACLs would be a better target. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksBFp8ACgkQTHDAI68NsukTqQCfcFNsC+1o0YjSbBf9kHW3w0nF 2IkAnicyCrgnmqZl+Qd+DAmke+C0yHVA =ANKR -----END PGP SIGNATURE-----

Nov. 16, 2009

Re: user32: Destroy EDITSTATE structure in the WM_NCDESTROY messageprocessing

by Dmitry Timoshkov

"Ilya Shpigor" <shpigor(a)etersoft.ru> wrote: > + SendMessageA(hWnd, WM_SETTEXT, 0, (LPARAM)str); > + SendMessageA(hWnd, WM_GETTEXT, MAXLEN, (LPARAM)buf); > + ok(!lstrcmp(buf, str), "Wrong contents of edit: %s\n", buf); > + lstrcpy(buf, ""); > + SendMessageA(hWnd, WM_DESTROY, 0, 0); > + SendMessageA(hWnd, WM_GETTEXT, MAXLEN, (LPARAM)buf); > + ok(!lstrcmp(buf, str), "Wrong contents of edit: %s\n", buf); > + lstrcpy(buf, ""); > + SendMessageA(hWnd, WM_NCDESTROY, 0, 0); > + SendMessageA(hWnd, WM_GETTEXT, MAXLEN, (LPARAM)buf); > + ok(!lstrcmp(buf, ""), "Wrong contents of edit: %s\n", buf); You should check return values of each SendMessage above. -- Dmitry.

Nov. 15, 2009

Re: [PATCH 1/3] user32: Free window text to prevent leak in case whenWM_NCDESTROY doesn't get to default procedure

by Dmitry Timoshkov

"Nikolay Sivov" <bunglehead(a)gmail.com> wrote: > This fixes a leak spotted by valgrind. > > Changelog: > - free window text to prevent leak in case when WM_NCDESTROY > doesn't get to default procedure Then WM_NCDESTROY handler should be removed from DefWindowProc to avoid a confusing duplication. -- Dmitry.

Nov. 15, 2009

re: [RFC] Extended Attributes for Dos Attributes, Creation Time, etc.

by Dan Kegel

Hi Ben, did you see http://bugs.winehq.org/show_bug.cgi?id=15679 http://www.winehq.org/pipermail/wine-patches/2009-October/079842.html ? IMHO the way the Samba sources merged the fd and filename version of the calls makes for less duplication of code. (I tried to do it the other way first, and it seemed ugly.) - Dan

Nov. 15, 2009

[Fwd: Interesting Problem Building Wine for Regression Test]

by James McKenzie

All: I continue to work with Tony Rollo's code as presented in bug 6254. I've found a problem with Wordpad's Print Preview between wine-1.1.10 and wine-1.1.11 and I attempted to run a regression test and end up with errors in makedep.c as follows: makedep.c:21:20: error: config.h: No such file or directory makedep.c:23:23: error: wine/port.h: No such file or directory makedep.c:35:23: error: wine/list.h: No such file or directory makedep.c:42: error: field ‘entry’ has incomplete type makedep.c:53: error: variable ‘sources’ has initializer but incomplete type makedep.c:53: error: ‘sources’ has an incomplete type makedep.c:54: error: variable ‘includes’ has initializer but incomplete type the list of errors continues but they are all related to the first three lines. These files exist in the include directory. What makes troubleshooting these errors difficult is that wine-1.1.10 AND wine-1.1.11 from the same git repository will build without these errors. What I did was: git bisect start git bisect good wine-1.1.10 git bisect bad wine-1.1.11 and I received the bisect message that there were 240 more changes to check. I do have an idea what commit caused the problem and attempted to manually backout the change, but the build also failed. I diffed the configure line and found no major differences between the configure on the build that finishes and the one that errors. Any idea on what I am doing incorrect? Just as a followup, I rebased my local git and received error messages relating to tools/Makefile.in. Forced a regit in the branch I had been working in and the builds are working again. Funny thing is that I did nothing to this file. James McKenzie

Nov. 15, 2009

Re: winscard: add pcsc-lite helpers for upcoming(?) implementation

by Juan Lang

> To my knowledge the integration of the patches by Mounir IDRASSI has been > rejected due to missing automated tests. This is a problem since for a full > test someone has to write/provide an IFD handler which emulates some stuff. IIRC, there was also a problem with the way it integration was done. It assumed the types between the Windows scard API and the Linux one were compatible, but in fact they may not be. I don't recall that this was ever addressed. --Juan

Nov. 15, 2009

Interesting Problem Building Wine for Regression Test

by James McKenzie

All: I continue to work with Tony Rollo's code as presented in bug 6254. I've found a problem with Wordpad's Print Preview between wine-1.1.10 and wine-1.1.11 and I attempted to run a regression test and end up with errors in makedep.c as follows: makedep.c:21:20: error: config.h: No such file or directory makedep.c:23:23: error: wine/port.h: No such file or directory makedep.c:35:23: error: wine/list.h: No such file or directory makedep.c:42: error: field ‘entry’ has incomplete type makedep.c:53: error: variable ‘sources’ has initializer but incomplete type makedep.c:53: error: ‘sources’ has an incomplete type makedep.c:54: error: variable ‘includes’ has initializer but incomplete type the list of errors continues but they are all related to the first three lines. These files exist in the include directory. What makes troubleshooting these errors difficult is that wine-1.1.10 AND wine-1.1.11 from the same git repository will build without these errors. What I did was: git bisect start git bisect good wine-1.1.10 git bisect bad wine-1.1.11 and I received the bisect message that there were 240 more changes to check. I do have an idea what commit caused the problem and attempted to manually backout the change, but the build also failed. I diffed the configure line and found no major differences between the configure on the build that finishes and the one that errors. Any idea on what I am doing incorrect? James McKenzie

Nov. 15, 2009

[RFC] Extended Attributes for Dos Attributes, Creation Time, etc.

by Ben Peddell

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 What are your thoughts on using Extended Attributes for items such as: * Dos Attributes (like samba's "store dos attributes = yes") * File Creation Times (like samba's proposed user.crtime) * An option for alternate storage of NT ACLs (like samba's "vfs object = acl-xattr") Are Extended Attributes acceptable? Or should they never touch the wine source? Where would the portability functions for Extended Attributes on Linux, Mac OS X, FreeBSD and Solaris belong? I would think in libport. Attached is a patch to add extended attribute portability functions for fgetxattr, fsetxattr and fremovexattr to libport. Please give me any comments on this patch, and the idea of using extended attributes. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksAm/4ACgkQTHDAI68NsumFzwCbBDcRbB8kFXroLeskA+hzgswu i0UAn3NHbau8AjSgtoruggBH3py+orcZ =tEvP -----END PGP SIGNATURE----- >From 2ef84c7f8c849db18ce15366e72c6787fa83597d Mon Sep 17 00:00:00 2001 From: Benjamin Peddell <klightspeed(a)netspace.net.au> Date: Mon, 16 Nov 2009 01:23:28 +1000 Subject: [PATCH] Add Extended Attribute support to libport --- configure | 178 ++++++++++++++++++++++++++++++++++++++++++++++ configure.ac | 45 ++++++++++++ include/config.h.in | 39 ++++++++++ include/wine/port.h | 36 +++++++++ libs/port/Makefile.in | 3 + libs/port/fgetxattr.c | 96 +++++++++++++++++++++++++ libs/port/fremovexattr.c | 75 +++++++++++++++++++ libs/port/fsetxattr.c | 102 ++++++++++++++++++++++++++ 8 files changed, 574 insertions(+), 0 deletions(-) create mode 100644 libs/port/fgetxattr.c create mode 100644 libs/port/fremovexattr.c create mode 100644 libs/port/fsetxattr.c diff --git a/configure b/configure index 15652b4..c9322b3 100755 --- a/configure +++ b/configure @@ -5747,6 +5747,7 @@ for ac_header in \ sys/errno.h \ sys/event.h \ sys/exec_elf.h \ + sys/extattr.h \ sys/filio.h \ sys/inotify.h \ sys/ioctl.h \ @@ -5782,6 +5783,7 @@ for ac_header in \ sys/utsname.h \ sys/vm86.h \ sys/wait.h \ + sys/xattr.h \ syscall.h \ termios.h \ unistd.h \ @@ -12084,6 +12086,9 @@ for ac_func in \ chsize \ dlopen \ epoll_create \ + extattr_delete_fd \ + extattr_get_fd \ + extattr_set_fd \ ffs \ finite \ fnmatch \ @@ -12105,6 +12110,7 @@ for ac_func in \ lstat \ memmove \ mmap \ + openat \ pclose \ pipe2 \ poll \ @@ -12137,6 +12143,7 @@ for ac_func in \ tcgetattr \ thr_kill2 \ timegm \ + unlinkat \ usleep \ vsnprintf \ wait4 \ @@ -12262,6 +12269,81 @@ fi fi +{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for library containing fgetxattr" >&5 +$as_echo_n "checking for library containing fgetxattr... " >&6; } +if test "${ac_cv_search_fgetxattr+set}" = set; then : + $as_echo_n "(cached) " >&6 +else + ac_func_search_save_LIBS=$LIBS +cat confdefs.h - <<_ACEOF >conftest.$ac_ext +/* end confdefs.h. */ + +/* Override any GCC internal prototype to avoid an error. + Use char because int might match the return type of a GCC + builtin and then its argument prototype would still apply. */ +#ifdef __cplusplus +extern "C" +#endif +char fgetxattr (); +int +main () +{ +return fgetxattr (); + ; + return 0; +} +_ACEOF +for ac_lib in '' attr; do + if test -z "$ac_lib"; then + ac_res="none required" + else + ac_res=-l$ac_lib + LIBS="-l$ac_lib $ac_func_search_save_LIBS" + fi + if ac_fn_c_try_link "$LINENO"; then : + ac_cv_search_fgetxattr=$ac_res +fi +rm -f core conftest.err conftest.$ac_objext \ + conftest$ac_exeext + if test "${ac_cv_search_fgetxattr+set}" = set; then : + break +fi +done +if test "${ac_cv_search_fgetxattr+set}" = set; then : + +else + ac_cv_search_fgetxattr=no +fi +rm conftest.$ac_ext +LIBS=$ac_func_search_save_LIBS +fi +{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_search_fgetxattr" >&5 +$as_echo "$ac_cv_search_fgetxattr" >&6; } +ac_res=$ac_cv_search_fgetxattr +if test "$ac_res" != no; then : + test "$ac_res" = "none required" || LIBS="$ac_res $LIBS" + +fi + + +for ac_func in \ + fgetxattr \ + fremovexattr \ + fsetxattr \ + +do : + as_ac_var=`$as_echo "ac_cv_func_$ac_func" | $as_tr_sh` +ac_fn_c_check_func "$LINENO" "$ac_func" "$as_ac_var" +eval as_val=\$$as_ac_var + if test "x$as_val" = x""yes; then : + cat >>confdefs.h <<_ACEOF +#define `$as_echo "HAVE_$ac_func" | $as_tr_cpp` 1 +_ACEOF + +fi +done + + { $as_echo "$as_me:${as_lineno-$LINENO}: checking for library containing gethostbyname" >&5 $as_echo_n "checking for library containing gethostbyname... " >&6; } if test "${ac_cv_search_gethostbyname+set}" = set; then : @@ -12616,6 +12698,102 @@ $as_echo "#define HAVE_ONE_ARG_MKDIR 1" >>confdefs.h fi +{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether fgetxattr takes six arguments" >&5 +$as_echo_n "checking whether fgetxattr takes six arguments... " >&6; } +if test "${wine_cv_six_arg_fgetxattr+set}" = set; then : + $as_echo_n "(cached) " >&6 +else + cat confdefs.h - <<_ACEOF >conftest.$ac_ext +/* end confdefs.h. */ +#include <sys/xattr.h> +int +main () +{ +fgetxattr(0, "foo", "foo", 3, 0, 0); + ; + return 0; +} +_ACEOF +if ac_fn_c_try_compile "$LINENO"; then : + wine_cv_six_arg_fgetxattr=yes +else + wine_cv_six_arg_fgetxattr=no +fi +rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext +fi +{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $wine_cv_six_arg_fgetxattr" >&5 +$as_echo "$wine_cv_six_arg_fgetxattr" >&6; } +if test "$wine_cv_six_arg_fgetxattr" = "yes" +then + +$as_echo "#define HAVE_SIX_ARG_FGETXATTR 1" >>confdefs.h + +fi + +{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether fsetxattr takes six arguments" >&5 +$as_echo_n "checking whether fsetxattr takes six arguments... " >&6; } +if test "${wine_cv_six_arg_fsetxattr+set}" = set; then : + $as_echo_n "(cached) " >&6 +else + cat confdefs.h - <<_ACEOF >conftest.$ac_ext +/* end confdefs.h. */ +#include <sys/xattr.h> +int +main () +{ +fsetxattr(0, "foo", "foo", 3, 0, 0); + ; + return 0; +} +_ACEOF +if ac_fn_c_try_compile "$LINENO"; then : + wine_cv_six_arg_fsetxattr=yes +else + wine_cv_six_arg_fsetxattr=no +fi +rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext +fi +{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $wine_cv_six_arg_fsetxattr" >&5 +$as_echo "$wine_cv_six_arg_fsetxattr" >&6; } +if test "$wine_cv_six_arg_fsetxattr" = "yes" +then + +$as_echo "#define HAVE_SIX_ARG_FSETXATTR 1" >>confdefs.h + +fi + +{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether fremovexattr takes three arguments" >&5 +$as_echo_n "checking whether fremovexattr takes three arguments... " >&6; } +if test "${wine_cv_three_arg_fremovexattr+set}" = set; then : + $as_echo_n "(cached) " >&6 +else + cat confdefs.h - <<_ACEOF >conftest.$ac_ext +/* end confdefs.h. */ +#include <sys/xattr.h> +int +main () +{ +fremovexattr("foo", "foo", 0); + ; + return 0; +} +_ACEOF +if ac_fn_c_try_compile "$LINENO"; then : + wine_cv_three_arg_fremovexattr=yes +else + wine_cv_three_arg_fremovexattr=no +fi +rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext +fi +{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $wine_cv_three_arg_fremovexattr" >&5 +$as_echo "$wine_cv_three_arg_fremovexattr" >&6; } +if test "$wine_cv_three_arg_fremovexattr" = "yes" +then + +$as_echo "#define HAVE_THREE_ARG_FREMOVEXATTR 1" >>confdefs.h + +fi + { $as_echo "$as_me:${as_lineno-$LINENO}: checking for an ANSI C-conforming const" >&5 $as_echo_n "checking for an ANSI C-conforming const... " >&6; } diff --git a/configure.ac b/configure.ac index a5f1b8a..c0f5380 100644 --- a/configure.ac +++ b/configure.ac @@ -384,6 +384,7 @@ AC_CHECK_HEADERS(\ sys/errno.h \ sys/event.h \ sys/exec_elf.h \ + sys/extattr.h \ sys/filio.h \ sys/inotify.h \ sys/ioctl.h \ @@ -419,6 +420,7 @@ AC_CHECK_HEADERS(\ sys/utsname.h \ sys/vm86.h \ sys/wait.h \ + sys/xattr.h \ syscall.h \ termios.h \ unistd.h \ @@ -1684,6 +1686,9 @@ AC_CHECK_FUNCS(\ chsize \ dlopen \ epoll_create \ + extattr_delete_fd \ + extattr_get_fd \ + extattr_set_fd \ ffs \ finite \ fnmatch \ @@ -1705,6 +1710,7 @@ AC_CHECK_FUNCS(\ lstat \ memmove \ mmap \ + openat \ pclose \ pipe2 \ poll \ @@ -1737,6 +1743,7 @@ AC_CHECK_FUNCS(\ tcgetattr \ thr_kill2 \ timegm \ + unlinkat \ usleep \ vsnprintf \ wait4 \ @@ -1757,6 +1764,16 @@ then AC_CHECK_LIB(poll,poll,[AC_DEFINE(HAVE_POLL,1) AC_SUBST(LIBPOLL,"-lpoll")]) fi +dnl Check for -lattr for the old attr package +AC_SEARCH_LIBS(fgetxattr,attr) + +dnl Check for xattr functions which may rely on -lattr on Linux +AC_CHECK_FUNCS(\ + fgetxattr \ + fremovexattr \ + fsetxattr \ +) + dnl Check for -lnsl for Solaris AC_SEARCH_LIBS(gethostbyname, nsl) @@ -1816,6 +1833,34 @@ then AC_DEFINE(HAVE_ONE_ARG_MKDIR, 1, [Define if mkdir takes only one argument]) fi +dnl Check xattr functions +AC_CACHE_CHECK([whether fgetxattr takes six arguments], + wine_cv_six_arg_fgetxattr, + AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include <sys/xattr.h>]],[[fgetxattr(0, "foo", "foo", 3, 0, 0);]])], + [wine_cv_six_arg_fgetxattr=yes],[wine_cv_six_arg_fgetxattr=no])) +if test "$wine_cv_six_arg_fgetxattr" = "yes" +then + AC_DEFINE(HAVE_SIX_ARG_FGETXATTR, 1, [Define if fgetxattr takes six arguments, as in Mac OS X]) +fi + +AC_CACHE_CHECK([whether fsetxattr takes six arguments], + wine_cv_six_arg_fsetxattr, + AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include <sys/xattr.h>]],[[fsetxattr(0, "foo", "foo", 3, 0, 0);]])], + [wine_cv_six_arg_fsetxattr=yes],[wine_cv_six_arg_fsetxattr=no])) +if test "$wine_cv_six_arg_fsetxattr" = "yes" +then + AC_DEFINE(HAVE_SIX_ARG_FSETXATTR, 1, [Define if fsetxattr takes six arguments, as in Mac OS X]) +fi + +AC_CACHE_CHECK([whether fremovexattr takes three arguments], + wine_cv_three_arg_fremovexattr, + AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include <sys/xattr.h>]],[[fremovexattr("foo", "foo", 0);]])], + [wine_cv_three_arg_fremovexattr=yes],[wine_cv_three_arg_fremovexattr=no])) +if test "$wine_cv_three_arg_fremovexattr" = "yes" +then + AC_DEFINE(HAVE_THREE_ARG_FREMOVEXATTR, 1, [Define if fremovexattr takes three arguments, as in Mac OS X]) +fi + dnl **** Check for types **** AC_C_CONST diff --git a/include/config.h.in b/include/config.h.in index 16b2e90..1c6ec57 100644 --- a/include/config.h.in +++ b/include/config.h.in @@ -93,9 +93,21 @@ /* Define if you have EsounD sound server */ #undef HAVE_ESD +/* Define to 1 if you have the `extattr_delete_fd' function. */ +#undef HAVE_EXTATTR_DELETE_FD + +/* Define to 1 if you have the `extattr_get_fd' function. */ +#undef HAVE_EXTATTR_GET_FD + +/* Define to 1 if you have the `extattr_set_fd' function. */ +#undef HAVE_EXTATTR_SET_FD + /* Define to 1 if you have the `ffs' function. */ #undef HAVE_FFS +/* Define to 1 if you have the `fgetxattr' function. */ +#undef HAVE_FGETXATTR + /* Define to 1 if you have the `finite' function. */ #undef HAVE_FINITE @@ -156,9 +168,15 @@ /* Define to 1 if you have the <freetype/tttables.h> header file. */ #undef HAVE_FREETYPE_TTTABLES_H +/* Define to 1 if you have the `fremovexattr' function. */ +#undef HAVE_FREMOVEXATTR + /* Define to 1 if the system has the type `fsblkcnt_t'. */ #undef HAVE_FSBLKCNT_T +/* Define to 1 if you have the `fsetxattr' function. */ +#undef HAVE_FSETXATTR + /* Define to 1 if the system has the type `fsfilcnt_t'. */ #undef HAVE_FSFILCNT_T @@ -561,6 +579,9 @@ /* Define to 1 if you have the <OpenAL/al.h> header file. */ #undef HAVE_OPENAL_AL_H +/* Define to 1 if you have the `openat' function. */ +#undef HAVE_OPENAT + /* Define if OpenGL is present on the system */ #undef HAVE_OPENGL @@ -699,6 +720,12 @@ /* Define to 1 if the system has the type `sigset_t'. */ #undef HAVE_SIGSET_T +/* Define if fgetxattr takes six arguments, as in Mac OS X */ +#undef HAVE_SIX_ARG_FGETXATTR + +/* Define if fsetxattr takes six arguments, as in Mac OS X */ +#undef HAVE_SIX_ARG_FSETXATTR + /* Define to 1 if the system has the type `size_t'. */ #undef HAVE_SIZE_T @@ -855,6 +882,9 @@ /* Define to 1 if you have the <sys/exec_elf.h> header file. */ #undef HAVE_SYS_EXEC_ELF_H +/* Define to 1 if you have the <sys/extattr.h> header file. */ +#undef HAVE_SYS_EXTATTR_H + /* Define to 1 if you have the <sys/filio.h> header file. */ #undef HAVE_SYS_FILIO_H @@ -984,12 +1014,18 @@ /* Define to 1 if you have the <sys/wait.h> header file. */ #undef HAVE_SYS_WAIT_H +/* Define to 1 if you have the <sys/xattr.h> header file. */ +#undef HAVE_SYS_XATTR_H + /* Define to 1 if you have the `tcgetattr' function. */ #undef HAVE_TCGETATTR /* Define to 1 if you have the <termios.h> header file. */ #undef HAVE_TERMIOS_H +/* Define if fremovexattr takes three arguments, as in Mac OS X */ +#undef HAVE_THREE_ARG_FREMOVEXATTR + /* Define to 1 if you have the `thr_kill2' function. */ #undef HAVE_THR_KILL2 @@ -1005,6 +1041,9 @@ /* Define to 1 if you have the <unistd.h> header file. */ #undef HAVE_UNISTD_H +/* Define to 1 if you have the `unlinkat' function. */ +#undef HAVE_UNLINKAT + /* Define to 1 if you have the `usleep' function. */ #undef HAVE_USLEEP diff --git a/include/wine/port.h b/include/wine/port.h index 61c8399..6568dae 100644 --- a/include/wine/port.h +++ b/include/wine/port.h @@ -48,6 +48,9 @@ # include <unistd.h> #endif +#ifdef HAVE_SYS_XATTR_H +# include <sys/xattr.h> +#endif /**************************************************************** * Type definitions @@ -117,6 +120,18 @@ struct statvfs #define mkdir(path,mode) mkdir(path) #endif +#ifdef HAVE_SIX_ARG_FGETXATTR +#define fgetxattr(fd,name,val,size) fgetxattr(fd,name,val,size,0,0) +#endif + +#ifdef HAVE_SIX_ARG_FSETXATTR +#define fsetxattr(fd,name,val,size,opts) fsetxattr(fd,name,val,size,0,opts) +#endif + +#ifdef HAVE_THREE_ARG_FREMOVEXATTR +#define fremovexattr(fd,name) fremovexattr(fd,name,0) +#endif + #if !defined(HAVE_FTRUNCATE) && defined(HAVE_CHSIZE) #define ftruncate chsize #endif @@ -328,6 +343,21 @@ int symlink(const char *from, const char *to); int usleep (unsigned int useconds); #endif /* !defined(HAVE_USLEEP) */ +#ifndef HAVE_FGETXATTR +size_t fgetxattr (int fd, const char *name, void *value, size_t size); +#endif /* !defined(HAVE_FGETXATTR) */ + +#ifndef HAVE_FSETXATTR +#define XATTR_CREATE 1 +#define XATTR_REPLACE 2 +size_t fsetxattr (int fd, const char *name, const void *value, size_t size, + int opts); +#endif /* !defined(HAVE_FSETXATTR) */ + +#ifndef HAVE_FREMOVEXATTR +size_t fremovexattr (int fd, const char *name); +#endif /* !defined(HAVE_FREMOVEXATTR) */ + #ifdef __i386__ static inline void *memcpy_unaligned( void *dst, const void *src, size_t size ) { @@ -470,6 +500,12 @@ extern unsigned char interlocked_cmpxchg128( __int64 *dest, __int64 xchg_high, #define strerror __WINE_NOT_PORTABLE(strerror) #define strncasecmp __WINE_NOT_PORTABLE(strncasecmp) #define usleep __WINE_NOT_PORTABLE(usleep) +#undef fgetxattr +#define fgetxattr __WINE_NOT_PORTABLE(fgetxattr) +#undef fsetxattr +#define fsetxattr __WINE_NOT_PORTABLE(fsetxattr) +#undef fremovexattr +#define fremovexattr __WINE_NOT_PORTABLE(fremovexattr) #endif /* NO_LIBWINE_PORT */ diff --git a/libs/port/Makefile.in b/libs/port/Makefile.in index c4c0127..e046562 100644 --- a/libs/port/Makefile.in +++ b/libs/port/Makefile.in @@ -8,6 +8,9 @@ MODULE = libwine_port.a C_SRCS = \ ffs.c \ + fgetxattr.c \ + fremovexattr.c \ + fsetxattr.c \ fstatvfs.c \ futimes.c \ getopt.c \ diff --git a/libs/port/fgetxattr.c b/libs/port/fgetxattr.c new file mode 100644 index 0000000..196d11a --- /dev/null +++ b/libs/port/fgetxattr.c @@ -0,0 +1,96 @@ +/* + * fgetxattr function + * + * Copyright 2009 Benjamin Peddell + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA + */ + +#include "config.h" +#include "wine/port.h" + +#ifndef HAVE_FGETXATTR + +#include <sys/types.h> +#include <sys/stat.h> +#include <fcntl.h> +#ifdef HAVE_SYS_EXTATTR_H +# include <sys/extattr.h> +#endif +#ifdef HAVE_UNISTD_H +# include <unistd.h> +#endif +#include <errno.h> + +size_t fgetxattr (int fd, const char *name, void *value, size_t size){ +/* Solaris openat(fd,path,O_XATTR) support */ +#ifdef defined(HAVE_OPENAT) && defined(O_XATTR) + int ret; + size_t attrsize = -1; + off_t pos; + struct stat statbuf; + int attrfd; + if (strchr(name, '/') != NULL){ + errno = EINVAL; + return -1; + } + attrfd = openat(fd, name, O_XATTR | O_RDONLY); + if (attrfd >= 0){ + ret = fstat(attrfd, &statbuf); + if (ret >= 0){ + attrsize = (size_t)statbuf.st_size; + if (attrsize >= 0 && attrsize <= size){ + pos = 0; + while (pos < attrsize){ + ret = read(attrfd, value + pos, attrsize - pos); + if (ret > 0){ + pos += ret; + } else { + attrsize = pos; + } + } + } else { + errno = ERANGE; + } + } + close(attrfd); + } + if (attrsize >= 0){ + return attrsize; + } else { + return (size_t)ret; + } +/* FreeBSD extattr_get_fd support */ +#elif defined(HAVE_EXTATTR_GET_FD) + int nameofs; + int namespace; + if (strncmp (name, "user.", 5) == 0){ + namespace = EXTATTR_NAMESPACE_USER; + nameofs = 5; + } else if (strncmp (name, "system.", 7) == 0){ + namespace = EXTATTR_NAMESPACE_SYSTEM; + nameofs = 7; + } else { + errno = ENOENT; + return -1; + } + return extattr_get_fd (fd, namespace, name + nameofs, value, size); +#else + errno = ENOSYS; + return -1; +#endif +} + +#endif /* HAVE_FGETXATTR */ diff --git a/libs/port/fremovexattr.c b/libs/port/fremovexattr.c new file mode 100644 index 0000000..b752fb8 --- /dev/null +++ b/libs/port/fremovexattr.c @@ -0,0 +1,75 @@ +/* + * fremovexattr function + * + * Copyright 2009 Benjamin Peddell + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA + */ + +#include "config.h" +#include "wine/port.h" + +#ifndef HAVE_FREMOVEXATTR + +#include <sys/types.h> +#include <sys/stat.h> +#include <fcntl.h> +#ifdef HAVE_SYS_EXTATTR_H +# include <sys/extattr.h> +#endif +#ifdef HAVE_UNISTD_H +# include <unistd.h> +#endif +#include <errno.h> + +size_t fremovexattr (int fd, const char *name){ +/* Solaris openat(fd,path,O_XATTR) support */ +#ifdef defined(HAVE_UNLINKAT) && defined(HAVE_OPENAT) && defined(O_XATTR) + int ret; + int attrfd; + if (strchr(name, '/') != NULL){ + errno = EINVAL; + return -1; + } + attrfd = openat(fd, ".", O_RDONLY | O_XATTR); + if (attrfd >= 0){ + ret = unlinkat(attrfd, name, 0); + close(attrfd); + } else { + ret = attrfd; + } + return ret; +/* FreeBSD extattr_delete_fd support */ +#elif defined(HAVE_EXTATTR_SET_FD) + int nameofs; + int namespace; + if (strncmp (name, "user.", 5) == 0){ + namespace = EXTATTR_NAMESPACE_USER; + nameofs = 5; + } else if (strncmp (name, "system.", 7) == 0){ + namespace = EXTATTR_NAMESPACE_SYSTEM; + nameofs = 7; + } else { + errno = ENOENT; + return -1; + } + return extattr_delete_fd (fd, namespace, name + nameofs); +#else + errno = ENOSYS; + return -1; +#endif +} + +#endif /* HAVE_FREMOVEXATTR */ diff --git a/libs/port/fsetxattr.c b/libs/port/fsetxattr.c new file mode 100644 index 0000000..7640f81 --- /dev/null +++ b/libs/port/fsetxattr.c @@ -0,0 +1,102 @@ +/* + * fsetxattr function + * + * Copyright 2009 Benjamin Peddell + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA + */ + +#include "config.h" +#include "wine/port.h" + +#ifndef HAVE_FSETXATTR +#include <sys/types.h> +#include <sys/stat.h> +#include <fcntl.h> +#ifdef HAVE_SYS_EXTATTR_H +# include <sys/extattr.h> +#endif +#ifdef HAVE_UNISTD_H +# include <unistd.h> +#endif +#include <errno.h> + +size_t fsetxattr (int fd, const char *name, const void *value, size_t size, + int opts){ +/* Solaris openat(fd,path,O_XATTR) support */ +#ifdef defined(HAVE_OPENAT) && defined(O_XATTR) + int ret; + size_t attrsize = -1; + off_t pos; + struct stat statbuf; + int attrfd; + int flags = O_XATTR | O_WRONLY | O_CREAT; + if (strchr(name, '/') != NULL){ + errno = EINVAL; + return -1; + } else if (strncmp (name, "SUNW", 4) == 0){ + errno = EINVAL; + return -1; + } else if (opts & XATTR_CREATE && opts & XATTR_REPLACE){ + errno = EINVAL; + return -1; + } else if (opts & XATTR_CREATE){ + flags |= O_EXCL; + } else if (opts & XATTR_REPLACE){ + flags &= ~O_CREAT; + } + attrfd = openat(fd, name, flags, 0666); + if (attrfd >= 0){ + pos = 0; + attrsize = size; + while (pos < attrsize){ + ret = write(attrfd, value + pos, attrsize - pos); + if (ret > 0){ + pos += ret; + } else { + attrsize = pos; + } + } + close(attrfd); + } else { + ret = attrfd; + } + if (attrsize >= 0){ + return attrsize; + } else { + return (size_t)ret; + } +/* FreeBSD extattr_set_fd support */ +#elif defined(HAVE_EXTATTR_SET_FD) + int nameofs; + int namespace; + if (strncmp (name, "user.", 5) == 0){ + namespace = EXTATTR_NAMESPACE_USER; + nameofs = 5; + } else if (strncmp (name, "system.", 7) == 0){ + namespace = EXTATTR_NAMESPACE_SYSTEM; + nameofs = 7; + } else { + errno = ENOENT; + return -1; + } + return extattr_set_fd (fd, namespace, name + nameofs, value, size); +#else + errno = ENOSYS; + return -1; +#endif +} + +#endif /* HAVE_FSETXATTR */ -- 1.6.4.4

Nov. 15, 2009

Re: wined3d: Fix some typos

by Roderick Colenbrander

Hi Anders, Your patch changes to two different dlls in one patch. In general a patch should only change one thing. It would be nice if you could separate it because else I'm not sure if it will be added. Roderick On Sun, Nov 15, 2009 at 9:12 PM, Anders Jonsson <anders.jonsson(a)norsjonet.se> wrote: > Fixes some typos in comctl32 and wined3d. > > >From 0656be69a97b7aae11b760fc4a436eb30191d527 Mon Sep 17 00:00:00 2001 > From: Anders Jonsson <anders.jonsson(a)norsjonet.se> > Date: Sun, 15 Nov 2009 21:05:22 +0100 > Subject: Fix some typos > > --- > dlls/comctl32/updown.c | 4 ++-- > dlls/wined3d/state.c | 2 +- > 2 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/dlls/comctl32/updown.c b/dlls/comctl32/updown.c > index a212073..773d359 100644 > --- a/dlls/comctl32/updown.c > +++ b/dlls/comctl32/updown.c > @@ -550,7 +550,7 @@ UPDOWN_Buddy_SubclassProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam) > * > * Sets bud as a new Buddy. > * Then, it should subclass the buddy > - * If window has the UDS_ARROWKEYS, it subcalsses the buddy window to > + * If window has the UDS_ARROWKEYS, it subclasses the buddy window to > * process the UP/DOWN arrow keys. > * If window has the UDS_ALIGNLEFT or UDS_ALIGNRIGHT style > * the size/pos of the buddy and the control are adjusted accordingly. > @@ -659,7 +659,7 @@ static HWND UPDOWN_SetBuddy (UPDOWN_INFO* infoPtr, HWND bud) > * 'delta' amount according to the 'action' flag which can be a > * combination of FLAG_INCR and FLAG_DECR > * It notifies the parent as required. > - * It handles wraping and non-wraping correctly. > + * It handles wrapping and non-wrapping correctly. > * It is assumed that delta>0 > */ > static void UPDOWN_DoAction (UPDOWN_INFO *infoPtr, int delta, int action) > diff --git a/dlls/wined3d/state.c b/dlls/wined3d/state.c > index 94fe19e..6df6e54 100644 > --- a/dlls/wined3d/state.c > +++ b/dlls/wined3d/state.c > @@ -1636,7 +1636,7 @@ static void state_wrap(DWORD state, IWineD3DStateBlockImpl *stateblock, struct w > stateblock->renderState[WINED3DRS_WRAP13] || > stateblock->renderState[WINED3DRS_WRAP14] || > stateblock->renderState[WINED3DRS_WRAP15] ) { > - FIXME("(WINED3DRS_WRAP0) Texture wraping not yet supported\n"); > + FIXME("(WINED3DRS_WRAP0) Texture wrapping not yet supported\n"); > } > } > > -- > 1.6.3.3 > > > > >

Nov. 15, 2009

Re: [PATCH] winex11.drv: check for org = NULL (Coverity)

by Roderick Colenbrander

Hi Marcus, A couple of hours ago I submitted a patch rewrites the function. It suffers from the same 'issue'. This and any other wgl function are called from gdi32/opengl.c which perform magic to arrive here and in case of wglsharelists it also performs the filtering. Roderick On Sun, Nov 15, 2009 at 7:28 PM, Marcus Meissner <marcus(a)jet.franken.de> wrote: > Hi, > > Coverity spotted some inconsistencies in "org" NULL > checking. > > org originates via Windows code (I think) so we better check it. > > Ciao, Marcus > --- > dlls/winex11.drv/opengl.c | 8 ++++++-- > 1 files changed, 6 insertions(+), 2 deletions(-) > > diff --git a/dlls/winex11.drv/opengl.c b/dlls/winex11.drv/opengl.c > index 45da479..774b205 100644 > --- a/dlls/winex11.drv/opengl.c > +++ b/dlls/winex11.drv/opengl.c > @@ -1918,11 +1918,15 @@ BOOL CDECL X11DRV_wglShareLists(HGLRC hglrc1, HGLRC hglrc2) { > > if (!has_opengl()) return FALSE; > > + if (NULL == org) { > + ERR("Could not share display lists, original context required.\n"); > + return FALSE; > + } > if (NULL != dest && dest->ctx != NULL) { > - ERR("Could not share display lists, context already created !\n"); > + ERR("Could not share display lists, context already created!\n"); > return FALSE; > } else { > - if(org && dest && (GetObjectType(org->hdc) == OBJ_MEMDC) ^ (GetObjectType(dest->hdc) == OBJ_MEMDC)) { > + if(dest && (GetObjectType(org->hdc) == OBJ_MEMDC) ^ (GetObjectType(dest->hdc) == OBJ_MEMDC)) { > WARN("Attempting to share a context between a direct and indirect rendering context, expect issues!\n"); > } > > -- > 1.5.6 > > >

Nov. 15, 2009

Implementing a cooling-off list in the heap

by Dan Kegel

Valgrind has a nice option --freelist_vol which is the total size of blocks to hold on the freed block queue. It does this to help detect double free errors. Where in Wine's heap would one want to keep a free list like that? My first idea is to just add another element to the freeList array; rather than putting freed blocks into the normal element by size, they'd all go into the purgatory element until it filled up, after which they would be transferred to the normal free list according to their size. (Now off to ride the new light rail. In Los Angeles, any time they open a new one, it's cause for celebration... you kinda have to go there and see if some of the improbability will rub off on you.)

Nov. 15, 2009

Re: ddraw/tests: Add test for refcounts of surface objects.

by Vincent Povirk

Ah, I only checked refcount.c. On Sun, Nov 15, 2009 at 2:12 PM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > > Am 15.11.2009 um 20:55 schrieb Vincent Povirk: > >> >> >> <0001-ddraw-tests-Add-test-for-refcounts-of-surface-object.txt> > I think we already have tests for that - see IFaceRefCount() in dsurface.c > > > > -- Vincent Povirk

Nov. 15, 2009

Re: ddraw/tests: Add test for refcounts of surface objects.

by Stefan Dösinger

Am 15.11.2009 um 20:55 schrieb Vincent Povirk: > > > <0001-ddraw-tests-Add-test-for-refcounts-of-surface-object.txt> I think we already have tests for that - see IFaceRefCount() in dsurface.c

Nov. 15, 2009

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

by Greg Geldorp

> I think you misunderstood me. The window is created but as you're > searching for a "Startup" window's title it fails on localized > systems. So the test is not completely correct and only work on > English system. That's why I proposed to skip the two tests on (and > only on) such systems. I haven't tested this, but perhaps it's possible to use SHGetSpecialFolderPath(..., CSIDL_STARTUP, ...) to obtain the (localized) file system location of the "Startup" folder, then use the last part of that path as the window title to search for. E.g. on English Windows the path retrieved by the call would be "C:\Documents and Settings\<username>\Start Menu\Programs\Startup", taking the last component would result in "Startup". On Dutch Windows the path would be "C:\Documents and Settings\<username>\Menu Start\Programma's\Opstarten", resulting in a last component of "Opstarten" which most likely is also the window title. Greg.

Nov. 15, 2009

re: Working on avifil32, sudden "non enough memory" error

by Dan Kegel

Julius wrote: >With one file however (GOODTIME.AVI from the win95 cd) I get this > error after about a second: > err:heap:HEAP_ValidateInUseArena Heap 0x110000: in-use arena 0x184420 > next block has PREV_FREE flag > non enough memory > > I have no idea where this comes from and why it happens. (It appears to > be unrelated to the memcpy call in avifile.c around line 1114.) With > +heap I also get this before the error: > HIGHPERF/GOODTIME.AVI: heap.c:403: HEAP_GetPtr: Controletest '0' faalt. > (the assert fails) Sounds like heap corruption. You might want to cut down the file to the shortest one that causes the crash, then go after it (possibly using valgrind or the like) to look for the error. Does your implementation of avifil32 and friends work properly on windows?

Nov. 15, 2009

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

by Nicolas Le Cam

2009/11/15 Mikey Alexander <firesword14(a)yahoo.com>: > You really don't want to skip this one as the api is supposed to create the window, but you can't be absolutely sure it is a failure, hence the error message being what it is. If you are going to skip the timeout if it fails, why bother checking for the window creation at all? > > The real question is what is the real worst case expected time to wait before failing because the window was not created? I upped it to 45 seconds. > > I could have implemented a window message thread to detect the window creation, but it doesn't change the problem. Window creation is not given a deadline. 10 seconds was obviously too short. Several machines failed on the first longer load with 10 seconds and a couple failed most of the timeouts with 10 seconds. > > I'd be more than willing to up the timeout longer, but if you really do encounter a failure, it makes the failed test take that much longer. > > - Mikey > I think you misunderstood me. The window is created but as you're searching for a "Startup" window's title it fails on localized systems. So the test is not completely correct and only work on English system. That's why I proposed to skip the two tests on (and only on) such systems. I'll try to use a window message thread to see if it helps. PS: Please bottom post on wine-devel -- Nicolas Le Cam

Nov. 15, 2009

Re: winscard: add pcsc-lite helpers for upcoming(?) implementation

by Heiko Nardmann

To my knowledge the integration of the patches by Mounir IDRASSI has been rejected due to missing automated tests. This is a problem since for a full test someone has to write/provide an IFD handler which emulates some stuff. So far I haven't found some kind of virtual card reader - maybe attached to a virtual USB hub. Regards Heiko Am Freitag, 13. November 2009 09:32:24 schrieb viny: > Joerg-Cyril.Hoehle(a)t-systems.com a écrit : > > Hi, > > > > looking for PCSC-card-reader support in Wine, I came across old mails > > from 2007. > > http://www.winehq.org/pipermail/wine-devel/2007-May/057052.html > > > > What's the current state of PCSC support in Wine? When I recently looked, > > winscard seemed full of stubs. > > > > OTOH, there's a company > > http://www.starmoney.de/index.php?id=243 > > that seems to use Wine (and Darwine?) with card readers to make > > its software available for Linux & Mac. Also seems ~2007. > > > > I believe that a winscard<->PCSC<->PCSC-Lite bridge would be much > > easier to achieve than USB support in Wine. > > > > Thanks for your help, > > Jörg Höhle > > Hi, > > There is a working binary winscard.dll for wine here : > > http://www.idrix.fr/Root/SCard4Wine/winscard.tar.gz > > But I'm waiting for official wine winscard too !

Nov. 15, 2009

Working on avifil32, sudden "non enough memory" error

by Julius Schwartzenberg

Hi, I'm working on fixing some things in avifil32. Several problems should be gone when using the attached four patches and most AVI files play back properly. With one file however (GOODTIME.AVI from the win95 cd) I get this error after about a second: err:heap:HEAP_ValidateInUseArena Heap 0x110000: in-use arena 0x184420 next block has PREV_FREE flag non enough memory I have no idea where this comes from and why it happens. (It appears to be unrelated to the memcpy call in avifile.c around line 1114.) With +heap I also get this before the error: HIGHPERF/GOODTIME.AVI: heap.c:403: HEAP_GetPtr: Controletest '0' faalt. (the assert fails) The whole output is here: http://haar.student.utwente.nl/~julius/avifile-heaperr.log.gz What could I try to figure out the cause of this problem? I can provide both the file and my test program if necessary. Note that on MS Windows XP it all works without problems. Thanks in advance, Julius >From a5fdf2316923e9b4fd254e571b5f70cb5a5ee87f Mon Sep 17 00:00:00 2001 From: Julius Schwartzenberg <julius.schwartzenberg(a)gmail.com> Date: Sun, 8 Nov 2009 15:18:26 +0100 Subject: avifile: Fix header for audio stream --- dlls/avifil32/avifile.c | 10 +++++++++- 1 files changed, 9 insertions(+), 1 deletions(-) diff --git a/dlls/avifil32/avifile.c b/dlls/avifil32/avifile.c index 49e141f..4ecc6f6 100644 --- a/dlls/avifil32/avifile.c +++ b/dlls/avifil32/avifile.c @@ -1816,7 +1816,15 @@ static HRESULT AVIFILE_LoadFile(IAVIFileImpl *This) if (FAILED(hr)) return hr; }; - + if (pStream->lpFormat != NULL && pStream->sInfo.fccType == streamtypeAUDIO) + { + WAVEFORMATEX *wfx = pStream->lpFormat; + wfx->nBlockAlign = wfx->nChannels * wfx->wBitsPerSample / 8; + pStream->sInfo.dwSampleSize = wfx->nBlockAlign; + TRACE("Block size reset to %u, chan=%u bpp=%u\n", wfx->nBlockAlign, wfx->nChannels, wfx->wBitsPerSample); + pStream->sInfo.dwScale = 1; + pStream->sInfo.dwRate = wfx->nSamplesPerSec; + } if (mmioAscend(This->hmmio, &ck, 0) != S_OK) return AVIERR_FILEREAD; } -- 1.6.3.3 >From 84a0ee0327569c91c74d99be3c124c09cfc45cb9 Mon Sep 17 00:00:00 2001 From: Julius Schwartzenberg <julius.schwartzenberg(a)gmail.com> Date: Sun, 8 Nov 2009 15:28:19 +0100 Subject: avifile: Fix header suggested buffersize --- dlls/avifil32/avifile.c | 12 +++++++++--- 1 files changed, 9 insertions(+), 3 deletions(-) diff --git a/dlls/avifil32/avifile.c b/dlls/avifil32/avifile.c index 4ecc6f6..c40cbd9 100644 --- a/dlls/avifil32/avifile.c +++ b/dlls/avifil32/avifile.c @@ -1652,7 +1652,7 @@ static HRESULT AVIFILE_LoadFile(IAVIFileImpl *This) This->fInfo.dwCaps = AVIFILECAPS_CANREAD|AVIFILECAPS_CANWRITE; This->fInfo.dwLength = MainAVIHdr.dwTotalFrames; This->fInfo.dwStreams = MainAVIHdr.dwStreams; - This->fInfo.dwSuggestedBufferSize = MainAVIHdr.dwSuggestedBufferSize; + This->fInfo.dwSuggestedBufferSize = 0; This->fInfo.dwWidth = MainAVIHdr.dwWidth; This->fInfo.dwHeight = MainAVIHdr.dwHeight; LoadStringW(AVIFILE_hModule, IDS_AVIFILETYPE, This->fInfo.szFileType, @@ -1754,8 +1754,7 @@ static HRESULT AVIFILE_LoadFile(IAVIFileImpl *This) pStream->sInfo.dwRate = streamHdr.dwRate; pStream->sInfo.dwStart = streamHdr.dwStart; pStream->sInfo.dwLength = streamHdr.dwLength; - pStream->sInfo.dwSuggestedBufferSize = - streamHdr.dwSuggestedBufferSize; + pStream->sInfo.dwSuggestedBufferSize = 0; pStream->sInfo.dwQuality = streamHdr.dwQuality; pStream->sInfo.dwSampleSize = streamHdr.dwSampleSize; pStream->sInfo.rcFrame.left = streamHdr.rcFrame.left; @@ -1905,6 +1904,13 @@ static HRESULT AVIFILE_LoadFile(IAVIFileImpl *This) } } + for (nStream = 0; nStream < This->fInfo.dwStreams; nStream++) + { + DWORD sugbuf = This->ppStreams[nStream]->sInfo.dwSuggestedBufferSize; + if (This->fInfo.dwSuggestedBufferSize < sugbuf) + This->fInfo.dwSuggestedBufferSize = sugbuf; + } + /* find other chunks */ FindChunkAndKeepExtras(&This->fileextra, This->hmmio, &ck, &ckRIFF, 0); -- 1.6.3.3 >From c6437174e6c2241b95b0d9b30ae6d2cac8218cdc Mon Sep 17 00:00:00 2001 From: Julius Schwartzenberg <julius.schwartzenberg(a)gmail.com> Date: Sun, 8 Nov 2009 15:32:33 +0100 Subject: avifile: Fix playback of fixed sample size audio stream --- dlls/avifil32/avifile.c | 14 ++++++++++---- 1 files changed, 10 insertions(+), 4 deletions(-) diff --git a/dlls/avifil32/avifile.c b/dlls/avifil32/avifile.c index c40cbd9..5fa45ae 100644 --- a/dlls/avifil32/avifile.c +++ b/dlls/avifil32/avifile.c @@ -1093,6 +1093,9 @@ static HRESULT WINAPI IAVIStream_fnRead(IAVIStream *iface, LONG start, /* convert samples to bytes */ samples *= This->sInfo.dwSampleSize; + if (!buffer) + buffersize = samples; + while (samples > 0 && buffersize > 0) { if (block != This->dwCurrentFrame) { hr = AVIFILE_ReadBlock(This, block, NULL, 0); @@ -1102,11 +1105,12 @@ static HRESULT WINAPI IAVIStream_fnRead(IAVIStream *iface, LONG start, size = min((DWORD)samples, (DWORD)buffersize); size = min(size, This->cbBuffer - offset); - memcpy(buffer, ((BYTE*)&This->lpBuffer[2]) + offset, size); - + if (buffer) + memcpy(buffer, ((BYTE*)&This->lpBuffer[2]) + offset, size); block++; offset = 0; - buffer = ((LPBYTE)buffer)+size; + if (buffer) + buffer = ((LPBYTE)buffer)+size; samples -= size; buffersize -= size; @@ -1117,7 +1121,9 @@ static HRESULT WINAPI IAVIStream_fnRead(IAVIStream *iface, LONG start, *samplesread += size / This->sInfo.dwSampleSize; } - if (samples == 0) + TRACE("Returning %d/%d\n", bytesread ? *bytesread : -1, samplesread ? *samplesread : -1); + + if (samples == 0 || !buffer) return AVIERR_OK; else return AVIERR_BUFFERTOOSMALL; -- 1.6.3.3 >From 9a429b3146f6718b3742816e2ff163e65e1ad748 Mon Sep 17 00:00:00 2001 From: Julius Schwartzenberg <julius.schwartzenberg(a)gmail.com> Date: Sun, 15 Nov 2009 17:07:52 +0100 Subject: Fix ticking problem which occured when reading through a block --- dlls/avifil32/avifile.c | 7 ++++++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/dlls/avifil32/avifile.c b/dlls/avifil32/avifile.c index 5fa45ae..88bf2ab 100644 --- a/dlls/avifil32/avifile.c +++ b/dlls/avifil32/avifile.c @@ -1089,6 +1089,7 @@ static HRESULT WINAPI IAVIStream_fnRead(IAVIStream *iface, LONG start, /* convert start sample to block,offset pair */ AVIFILE_SamplesToBlock(This, &block, &offset); + TRACE("block=%d, offset=%d\n", block, offset); /* convert samples to bytes */ samples *= This->sInfo.dwSampleSize; @@ -1097,6 +1098,7 @@ static HRESULT WINAPI IAVIStream_fnRead(IAVIStream *iface, LONG start, buffersize = samples; while (samples > 0 && buffersize > 0) { + LONG blocksize; if (block != This->dwCurrentFrame) { hr = AVIFILE_ReadBlock(This, block, NULL, 0); if (FAILED(hr)) @@ -1104,7 +1106,10 @@ static HRESULT WINAPI IAVIStream_fnRead(IAVIStream *iface, LONG start, } size = min((DWORD)samples, (DWORD)buffersize); - size = min(size, This->cbBuffer - offset); + blocksize = (BYTE*)This->lpBuffer[1]; +/* blocksize = This->cbBuffer; */ + TRACE("blocksize = %u\n",blocksize); + size = min(size, blocksize - offset); if (buffer) memcpy(buffer, ((BYTE*)&This->lpBuffer[2]) + offset, size); block++; -- 1.6.3.3

Nov. 15, 2009

Re: avifile bugfixes

by Julius Schwartzenberg

Detlef Riekenberg wrote: > On Di, 2009-11-10 at 00:43 +0100, Julius Schwartzenberg wrote: >> I will add tests to show this and submit the patches then. > > I created a test for avifil32 in June 2008, but it was not comitted. > ( http://www.winehq.org/pipermail/wine-patches/2008-June/056310.html ) Thanks for the pointer. I was already wondering why there were no tests in the avifil32 directory. I'll keep this in mind. There are some tests that use avifile in winmm though. Julius

Nov. 15, 2009

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

by Mikey Alexander

You really don't want to skip this one as the api is supposed to create the window, but you can't be absolutely sure it is a failure, hence the error message being what it is. If you are going to skip the timeout if it fails, why bother checking for the window creation at all? The real question is what is the real worst case expected time to wait before failing because the window was not created? I upped it to 45 seconds. I could have implemented a window message thread to detect the window creation, but it doesn't change the problem. Window creation is not given a deadline. 10 seconds was obviously too short. Several machines failed on the first longer load with 10 seconds and a couple failed most of the timeouts with 10 seconds. I'd be more than willing to up the timeout longer, but if you really do encounter a failure, it makes the failed test take that much longer. - Mikey --- On Sat, 11/14/09, Nicolas Le Cam <niko.lecam(a)gmail.com> wrote: > From: Nicolas Le Cam <niko.lecam(a)gmail.com> > Subject: Re: shell32/tests: Fix Program Manager DDE Conformance Test Failures > To: wine-devel(a)winehq.org > Cc: firesword14(a)yahoo.com > Date: Saturday, November 14, 2009, 9:09 AM > 2009/11/14 Mikey Alexander <firesword14(a)yahoo.com>: > > Fixes a memory leak, non connection to the progman dde > on early windows, and timeout problems with the conformance > tests. > > > > --- > > dlls/shell32/tests/progman_dde.c | 25 > +++++++++++++++++-------- > > 1 files changed, 17 insertions(+), 8 deletions(-) > > > Hi Mikey, > > There's also a test failure on localized Windows (see > http://test.winehq.org/data/8a17a028b73d1ccc5b7ebaa9e135a1bfbf159615/2000_w… > for example) because the window doesn't have the expected > title. > > I tried to skip the ShowGroupTest call at line 510 (before > your patch) > but then the next call fails. Is there a better solution > than skipping > those two calls ? If not I'll just send a skipping patch. > > > -- > Nicolas Le Cam >

Nov. 15, 2009

Re: user32/tests: Test edit control to WM_GETTEXT processing after WM_DESTROY

by Ilya Shpigor

Please don't commit this test. Instead use or comment next try: user32: Destroy EDITSTATE structure in the WM_NCDESTROY message processing -- Best regards, Ilya Shpigor.

Nov. 15, 2009

commit 70ae1ba4 caused regression in dinpu9

by Vitaliy Margolen

Markus, You patch caused regression: http://bugs.winehq.org/show_bug.cgi?id=20711 Please take a look. Vitaliy.

Nov. 15, 2009

Implementing FLG_HEAP_ENABLE_TAIL_CHECK

by Dan Kegel

Running Chromium's test suite under valgrind+wine did find a handful of interesting Wine problems, and one or two Chromium problems, but it seems to miss a whole bunch of problems Purify catches. Thinking about it a bit, I realized that Valgrind replaces the linux heap with one that puts guard bytes before and after each allocation, and marks those guard bytes as inaccessible. Valgrind's replacement heap also keeps freed blocks out of circulation for a while, marking them completely inaccessible so that references to freed blocks are caught. At the moment, nothing does this when running win32 apps under wine+valgrind; sure, wine informs Valgrind about the allocations made by the NT heap, but it doesn't put any guard bytes around them. So, how can we achieve this on Wine? The Wine philosophy is to look for how Windows likes to do things, and sure enough, there are ways to tell the Windows kernel to do similar things. http://technet.microsoft.com/en-us/library/cc736347(WS.10).aspx describes the gflags utility, used to set registry flags that end up controlling the NtGlobalFlags field of each processes' PEB. FLG_HEAP_ENABLE_TAIL_CHECK tells the heap to add guard bytes at the end of each allocation. FLG_HEAP_PAGE_ALLOCS tells the heap to add a whole guard page at the end of each allocation. (The /backwards option to gflags modifies this to put the page at the beginning of the allocation, but I don't know what NtGlobalFlags value this corresponds to.) I don't see any option there for "keep newly freed blocks out of circulation for the moment"; FLG_HEAP_DISABLE_COALESCING is kind of close. I'm tempted to try implementing enough of this so Wine+Valgrind can catch more of the Chromium errors that Purify can. Thoughts? - Dan

Nov. 14, 2009

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

by Nicolas Le Cam

2009/11/14 Mikey Alexander <firesword14(a)yahoo.com>: > Fixes a memory leak, non connection to the progman dde on early windows, and timeout problems with the conformance tests. > > --- > dlls/shell32/tests/progman_dde.c | 25 +++++++++++++++++-------- > 1 files changed, 17 insertions(+), 8 deletions(-) > Hi Mikey, There's also a test failure on localized Windows (see http://test.winehq.org/data/8a17a028b73d1ccc5b7ebaa9e135a1bfbf159615/2000_w… for example) because the window doesn't have the expected title. I tried to skip the ShowGroupTest call at line 510 (before your patch) but then the next call fails. Is there a better solution than skipping those two calls ? If not I'll just send a skipping patch. -- Nicolas Le Cam

Nov. 14, 2009

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

by Dan Kegel

<jacek(a)codeweavers.com> wrote: > I've got an idea for you to workaround the problem. Something like: > > $ WINEDLLOVERRIDES=mshtml= wine cmd /C echo test Thanks, I'll give that a shot. - Dan

Nov. 13, 2009

Re: (try 2) user32: Add argument check for PTITLEBARINFO in GetTitleBarInfo().

by Rico Schüller

Am 13.11.2009 15:16, schrieb Rob Shearman: > 2009/11/12 Rico Schüller<kgbricola(a)web.de>: > >> Hi, >> >> this patch adds a check for PTITLEBARINFO in GetTitleBarInfo() to avoid a >> crash. This fixes bug 20249 . >> >> Try 2 improvement: >> - do not print the null pointer, it's useless >> >> Cheers >> Rico >> >> --- >> dlls/user32/nonclient.c | 6 ++++++ >> 1 files changed, 6 insertions(+), 0 deletions(-) >> > You could easily add a testcase for this behaviour. > > Sure, I could. Would you please name the file, where I should put the test in, please? Otherwise a test is attached to bug 20249 . Cheers Rico

Nov. 13, 2009

Re: user32/tests: Test edit control to WM_GETTEXT processing after WM_DESTROY

by Nikolay Sivov

On 11/13/09, Ilya Shpigor <shpigor(a)etersoft.ru> wrote: > Hi, > > There is a problem to get edit control text after It has processed > WM_DESTROY > message. Perhaps, problem with EDITSTATE structure what contain this text. > WM_DESTROY cause destroying this structure. This is currently a place where control releases its data, and that's fine in that sense. > > Is it possible to solve this problem properly without hacks? > Yes, if destruction itself is made on WM_NCDESTROY for example, or even DestroyWindow knows Edit class and handles its specific data releasing internally. > -- > Best regards, > Ilya Shpigor. >

Nov. 13, 2009

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

by Jacek Caban

Hi Dan, I've got an idea for you to workaround the problem. Something like: $ WINEDLLOVERRIDES=mshtml= wine cmd /C echo test $ wine regsvr32 mshtml will do the trick. Note that we prevent registration of the whole mshtml in the first command, so we have to make sure it's registered later. I still think that the proper way is to use packages and I strongly recommend it. Jacek

Nov. 13, 2009

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

by Vitaliy Margolen

Jacek Caban wrote: > Austin English wrote: > When you run iexplore, wineprefix has to be created first, so it won't > work unless we'd add some sort of environment variable, but I don't see > the point. How would it be better than current solution? Simple - it could be automated on distros/environments without installed gecko package. Vitaliy.

Nov. 13, 2009

Re: (try 2) user32: Add argument check for PTITLEBARINFO in GetTitleBarInfo().

by Rob Shearman

2009/11/12 Rico Schüller <kgbricola(a)web.de>: > Hi, > > this patch adds a check for PTITLEBARINFO in GetTitleBarInfo() to avoid a > crash. This fixes bug 20249 . > > Try 2 improvement: > - do not print the null pointer, it's useless > > Cheers > Rico > > --- > dlls/user32/nonclient.c | 6 ++++++ > 1 files changed, 6 insertions(+), 0 deletions(-) You could easily add a testcase for this behaviour. -- Rob Shearman

Nov. 13, 2009

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

by Jacek Caban

Ben Klein wrote: > 2009/11/13 Jacek Caban <jacek(a)codeweavers.com>: >> I've even considered removing the whole downloader, >> but after a talk with Alexandre we decided to try with the >> current solution. >> > > Any chance of including gecko in the git repository? > http://wine.git.sourceforge.net/git/gitweb.cgi?p=wine/wine-gecko;a=summary If you mean including the cab file in Wine git, that doesn't look right. Jacek

Nov. 13, 2009

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

by Jacek Caban

Austin English wrote: > On Thu, Nov 12, 2009 at 2:23 PM, Jacek Caban <jacek(a)codeweavers.com> wrote: > >> Tom Wickline wrote: >> >>> On Fri, Nov 13, 2009 at 3:44 AM, Jacek Caban <jacek(a)codeweavers.com >>> <mailto:jacek(a)codeweavers.com>> wrote: >>> >>> The plan is that winetricks should not be used for installing Gecko. >>> >>> >>> So you intentionally broke it? >>> >> No, I was actually fixing the bug that caused the downloader to crash as you >> described. The downloader was *accidentally* broken some time ago and then >> I've decided that we need a better solution. That's why it was broken for a >> while. I didn't want to fix something that is broken by design. >> > > Perhaps the downloader/installer could be automated? E.g., currently, doing: > $ rm -rf ~/.wine ; wineboot > brings up the installer, where the user only clicks install, nothing > else. Could an automated option be added, say: > $ wine iexplore.exe -install_gecko > that way winetricks can still install it for users quickly and > painlessly, without having to mess with sudo/etc.? > When you run iexplore, wineprefix has to be created first, so it won't work unless we'd add some sort of environment variable, but I don't see the point. How would it be better than current solution? Jacek

Nov. 13, 2009

Re: [try 3] [PATCH 03/12] comctl32: Implement Add, ReplaceIcon, GetImageCount, SetImageCount in IImageList

by Alexandre Julliard

Owen Rudge <orudge(a)codeweavers.com> writes: > @@ -2985,15 +2985,37 @@ static ULONG WINAPI ImageListImpl_Release(IImageList *iface) > static HRESULT WINAPI ImageListImpl_Add(IImageList *iface, HBITMAP hbmImage, > HBITMAP hbmMask, int *pi) > { > - FIXME("STUB: %p %p %p %p\n", iface, hbmImage, hbmMask, pi); > - return E_NOTIMPL; > + HIMAGELIST This = (HIMAGELIST) iface; > + int ret; > + > + if (!This || !hbmImage || !pi) > + return E_FAIL; It doesn't make sense to check the interface pointer, it can't be NULL. Also please don't resend the full series once again, when things don't get committed on the first try you need to proceed in smaller steps. -- Alexandre Julliard julliard(a)winehq.org

Nov. 13, 2009

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

by Austin English

On Thu, Nov 12, 2009 at 2:23 PM, Jacek Caban <jacek(a)codeweavers.com> wrote: > Tom Wickline wrote: >> >> >> On Fri, Nov 13, 2009 at 3:44 AM, Jacek Caban <jacek(a)codeweavers.com >> <mailto:jacek(a)codeweavers.com>> wrote: >> >> The plan is that winetricks should not be used for installing Gecko. >> >> >> So you intentionally broke it? > > No, I was actually fixing the bug that caused the downloader to crash as you > described. The downloader was *accidentally* broken some time ago and then > I've decided that we need a better solution. That's why it was broken for a > while. I didn't want to fix something that is broken by design. Perhaps the downloader/installer could be automated? E.g., currently, doing: $ rm -rf ~/.wine ; wineboot brings up the installer, where the user only clicks install, nothing else. Could an automated option be added, say: $ wine iexplore.exe -install_gecko that way winetricks can still install it for users quickly and painlessly, without having to mess with sudo/etc.? -- -Austin

Nov. 13, 2009

Re: winscard: add pcsc-lite helpers for upcoming(?) implementation

by viny

Joerg-Cyril.Hoehle(a)t-systems.com a écrit : > Hi, > > looking for PCSC-card-reader support in Wine, I came across old mails from 2007. > http://www.winehq.org/pipermail/wine-devel/2007-May/057052.html > > What's the current state of PCSC support in Wine? When I recently looked, > winscard seemed full of stubs. > > OTOH, there's a company > http://www.starmoney.de/index.php?id=243 > that seems to use Wine (and Darwine?) with card readers to make > its software available for Linux & Mac. Also seems ~2007. > > I believe that a winscard<->PCSC<->PCSC-Lite bridge would be much > easier to achieve than USB support in Wine. > > Thanks for your help, > Jörg Höhle > > > Hi, There is a working binary winscard.dll for wine here : http://www.idrix.fr/Root/SCard4Wine/winscard.tar.gz But I'm waiting for official wine winscard too !

Nov. 13, 2009