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

Re: Wine FAQ edits

by Albert Lee

On Sat, Feb 5, 2011 at 3:05 AM, Gert van den Berg <wine-devel(a)mohag.net> wrote: > On Thu, Feb 3, 2011 at 18:17, Albert Lee <trisk(a)forkgnu.org> wrote: >> The instructions were intended to give some context for users who >> might not be familiar with the ~ expansion. > > Using {$HOME} would be more portable. The Bourne shell (/bin/sh) on > Solaris (9/10 - OpenSolaris defaulted to ksh) doesn't support ~ > (although csh, zsh, bash, tcsh, ksh and just about all the other > bundled shells does, it sh is the default shell) > Anyone using the original Bourne sh *interactively* is in for a world of pain anyway (speaking as someone who often had to before the ksh93 replacement). I think relying on tilde expansion can can be considered good practice for the interactive use case. -Albert

Feb. 6, 2011

RE: shell32/tests: Clean make new folder test (Valgrind)

by Michael Mc Donnell

Hi! What is the reason this patch by Nikolay Sivov was not included in the latest version of wine? It fixes a clean-up bug on some Windows XP machines, and tidies up the code nicely. Wine-patches archive link: http://www.winehq.org/pipermail/wine-patches/2011-January/098342.html Regards, Michael Mc Donnell P.S. Thanks Nikolay for fixing my first win32 test.

Feb. 5, 2011

Re: Pulling Patch

by Shachar Shemesh

On 05/02/11 00:24, James McKenzie wrote: > Actually, the latest patch is what I don't want reused. And no, you > don't put it in the LGPL until it is committed, which I don't expect > AJ to do anyway. > > However, I'm moving in a different direction since my Mac needs more > repairs than I'm willing to spend money on. > > Besides, I've been a big enough pain that my existence here is > unwarranted and unneeded. > As anyone who attended the last WineConf probably already knows, you have my complete sympathies in that regard. I also doubt very much anyone would use your uncommitted patches against your will, so in that respect, you probably have nothing to worry about. That said, I believe your claim to the right to demand no use is wrong. It is my understanding that by submitting your patches to wine-patches, you have placed them under the LGPL, which is a non-revocable license. Again, in all likely hood, this is a purely hypothetical question. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com

Feb. 5, 2011

Re: Killing WineAPI project on SourceForge.

by Max TenEyck Woodbury

On 02/05/2011 10:38 AM, Steve Brown wrote: > On Sat, 5 Feb 2011, GOUJON Alexandre wrote: > >> On 02/05/2011 02:59 PM, André Hentschel wrote: >>> Which WineAPI on the regular Wine Wiki??? URL? >> I guess he's talking about this >> http://source.winehq.org/WineAPI/ >> >> It says "generated automatically" but where is the script ? >> >> Max, if you want, you can still improve the script and make it more >> useful. >> For instance, instead of "Statistics" which give simple numbers, I >> think a link to each function in the wine source code should be great. >> I have some ideas like adding a "search" feature, a link to the test >> that implement the selected function ..etc >> >> It may be useful when you want modify a function but you don't know >> where it is. >> For instance, wine_dbgstr_w() is used everywhere. But where is it >> defined ? >> It should be a usage of the WineAPI but that's only my point of view. > > I've seen this discussion come and go a few times... Would something > like LXR be appropriate for generating a web front-end to searching and > indexing the Wine source code? I've used the various Linux kernel sites > a time or two: > > http://sourceforge.net/projects/lxr/ > > Steve Brown > sbrown7(a)umbc.edu Script is 'tools/c2man.pl'. There are several things in it that need improvement. See my other thread from yesterday. Max

Feb. 5, 2011

Re: Killing WineAPI project on SourceForge.

by Max TenEyck Woodbury

On 02/05/2011 08:59 AM, André Hentschel wrote: > Am 05.02.2011 06:36, schrieb Max TenEyck Woodbury: >> No feedback and apparently no interest in the WineAPI project on >> SourceForge. Understandable since there is now a WineAPI on the regular Wine Wiki. Unless someone objects, I'm going to ask that it be shutdown on SourceForge. >> > > Which WineAPI on the regular Wine Wiki??? URL? > Sorry, not Wiki. http://source.winehq.org/WineAPI/ Max

Feb. 5, 2011

Re: Killing WineAPI project on SourceForge.

by Steve Brown

On Sat, 5 Feb 2011, GOUJON Alexandre wrote: > On 02/05/2011 02:59 PM, André Hentschel wrote: >> Which WineAPI on the regular Wine Wiki??? URL? > I guess he's talking about this > http://source.winehq.org/WineAPI/ > > It says "generated automatically" but where is the script ? > > Max, if you want, you can still improve the script and make it more useful. > For instance, instead of "Statistics" which give simple numbers, I think > a link to each function in the wine source code should be great. > I have some ideas like adding a "search" feature, a link to the test > that implement the selected function ..etc > > It may be useful when you want modify a function but you don't know > where it is. > For instance, wine_dbgstr_w() is used everywhere. But where is it defined ? > It should be a usage of the WineAPI but that's only my point of view. I've seen this discussion come and go a few times... Would something like LXR be appropriate for generating a web front-end to searching and indexing the Wine source code? I've used the various Linux kernel sites a time or two: http://sourceforge.net/projects/lxr/ Steve Brown sbrown7(a)umbc.edu

Feb. 5, 2011

Re: Wine FAQ edits

by David Laight

On Sat, Feb 05, 2011 at 10:14:07AM +0200, Gert van den Berg wrote: > On Sat, Feb 5, 2011 at 10:05, Gert van den Berg <wine-devel(a)mohag.net> wrote: > > On Thu, Feb 3, 2011 at 18:17, Albert Lee <trisk(a)forkgnu.org> wrote: > >> The instructions were intended to give some context for users who > >> might not be familiar with the ~ expansion. > > > > Using {$HOME} would be more portable. > > And using "${WINEPREFIX:-${HOME}/.wine}/dosdevices/c:/Program Files" > should work correctly in any Wine setup (on a Bourne-compatible > shell), including one using a custom WINEPREFIX. Better still "${WINEPREFIX:-${HOME:?}/.wine}/dosdevices/c:/Program Files" which will generate an error if HOME isn't set. David -- David Laight: david(a)l8s.co.uk

Feb. 5, 2011

Re: Killing WineAPI project on SourceForge.

by GOUJON Alexandre

On 02/05/2011 06:36 AM, Max TenEyck Woodbury wrote: > No feedback and apparently no interest in the WineAPI project on > SourceForge. The subject has been debated before you launched the WineAPI project on SF. Some questions may help to understand why does nobody is interested : + Why a WineAPI should be needed ? + Who would use it ? + What can people using it expect to see ? > Understandable since there is now a WineAPI on the regular Wine Wiki. On 02/05/2011 02:59 PM, André Hentschel wrote: > Which WineAPI on the regular Wine Wiki??? URL? I guess he's talking about this http://source.winehq.org/WineAPI/ It says "generated automatically" but where is the script ? Max, if you want, you can still improve the script and make it more useful. For instance, instead of "Statistics" which give simple numbers, I think a link to each function in the wine source code should be great. I have some ideas like adding a "search" feature, a link to the test that implement the selected function ..etc It may be useful when you want modify a function but you don't know where it is. For instance, wine_dbgstr_w() is used everywhere. But where is it defined ? It should be a usage of the WineAPI but that's only my point of view. Hope that helps !

Feb. 5, 2011

Re: user32: Don't try to move mouse to (-1,0).

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=8925 Your paranoid android. === W7PROX64 (64 bit msg) === Timeout

Feb. 5, 2011

Re: Killing WineAPI project on SourceForge.

by André Hentschel

Am 05.02.2011 06:36, schrieb Max TenEyck Woodbury: > No feedback and apparently no interest in the WineAPI project on > SourceForge. Understandable since there is now a WineAPI on the regular Wine Wiki. Unless someone objects, I'm going to ask that it be shutdown on SourceForge. > Which WineAPI on the regular Wine Wiki??? URL? -- Best Regards, André Hentschel

Feb. 5, 2011

Re: Pulling Patch

by GOUJON Alexandre

On 02/04/2011 07:13 PM, James McKenzie wrote: > Since my Mac is dying I have decided to return to the Windows world. It's your choice so I can't comment it but I bet you know what I think. Please remember what you wrote to me (May, 2010) : > Don't give up on it, just take a break away from it, please. The > solution might just come to you while you are working on something > else. I've been working on a patch for two years and the > implementation was completely wrong. I will go back to it in about a > month, and actually fix two missing functions rather than one. This > was the benefit of a mandatory break insisted upon by Alexandre. He > does not want me to touch it until early October. > That's fine. Just don't let this get you into a negative spirial. > Alexandre and others have very good advice. > Please pull any and all patches. I have envoked the right to > copyright and none of my code can or will be used in Wine. Life's hard, unfair and never goes as we thought. Does it worth the fight ? Yeah, of course ! Just as you told me, don't give up and have a break, have a K*t K*t. Every mail and patch you sent is now archived and may be referred when relevant. I'm sure you did great things and whatever you think, you're part of Wine. We don't often say "good job !" because it often imply something in return (mostly money) but we should. It's always pleasant to see our work useful and that makes us proud. So "Good job !", have a nice day and take care.

Feb. 5, 2011

Re: Wine FAQ edits

by Gert van den Berg

On Sat, Feb 5, 2011 at 10:05, Gert van den Berg <wine-devel(a)mohag.net> wrote: > On Thu, Feb 3, 2011 at 18:17, Albert Lee <trisk(a)forkgnu.org> wrote: >> The instructions were intended to give some context for users who >> might not be familiar with the ~ expansion. > > Using {$HOME} would be more portable. And using "${WINEPREFIX:-${HOME}/.wine}/dosdevices/c:/Program Files" should work correctly in any Wine setup (on a Bourne-compatible shell), including one using a custom WINEPREFIX. (But might be somewhat hard to follow for someone not familiar with the technicalities of the Bourne shell)

Feb. 5, 2011

Re: Wine FAQ edits

by Gert van den Berg

Correction: ${HOME}

Feb. 5, 2011

Re: Wine FAQ edits

by Gert van den Berg

On Thu, Feb 3, 2011 at 18:17, Albert Lee <trisk(a)forkgnu.org> wrote: > The instructions were intended to give some context for users who > might not be familiar with the ~ expansion. Using {$HOME} would be more portable. The Bourne shell (/bin/sh) on Solaris (9/10 - OpenSolaris defaulted to ksh) doesn't support ~ (although csh, zsh, bash, tcsh, ksh and just about all the other bundled shells does, it sh is the default shell) (Checkin proper quoting in case it contains spaces might be necessary..) Gert

Feb. 5, 2011

Re: winspool.drv: make sure to use return values (LLVM/Clang)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=8921 Your paranoid android. === WINEBUILD (build) === Can't determine base name

Feb. 5, 2011

Wine API documentation questions.

by Max TenEyck Woodbury

I've been going through the Wine API documentation and there seem to be some things that I think should be changed: - There are references to Wine documents that do not include links to the pages. The links should be included. - Some 'implementation' sections claim that the API is not declared but there are declarations, just not in headers that 'c2man' is looking at. It should also look in any sub-directories (except for 'tests') of the '-I' directories it is told about for additional headers. (I have very little skill with Perl at present, so someone else might be able to add this much faster than I will be able to do it.) - There are quite a few APIs implemented but without standard documentation. All accessible APIs should have enough documentation so that there is a page for it, even if it is only a synopsis. - Mangled interface names only appear in their mangled form. The documentation should include the demangled name as well. Should the demangled names also appear in the indexes? - The 'synopsis' does not include needed '#include' directives. This may need to be fixed in each API description rather than trying to get 'c2man' to generate it. - The name of the file containing the implementation is included in each 'implementation' section and includes a link to the appropriate repository source entry. The name of the appropriate header is also included, but does not include a link. A link should be included. Max

Feb. 5, 2011

Killing WineAPI project on SourceForge.

by Max TenEyck Woodbury

No feedback and apparently no interest in the WineAPI project on SourceForge. Understandable since there is now a WineAPI on the regular Wine Wiki. Unless someone objects, I'm going to ask that it be shutdown on SourceForge. Max

Feb. 5, 2011

Re: kernel32/process: Add stderr redirection for native linux programs started from windows program

by Igor Egorov

On 02/04/2011 06:25 PM, Austin English wrote: > On Fri, Feb 4, 2011 at 18:22, Igor Egorov<atohom(a)gmail.com> wrote: >> This is my first patch, not sure if I done all right. > I didn't look at the actual change, but: >> mode change 100644 => 100755 dlls/kernel32/process.c > doesn't seem necessary to me. > Yes, thanks, I resent the patch

Feb. 5, 2011

Re: kernel32/process: Add stderr redirection for native linux programs started from windows program

by Austin English

On Fri, Feb 4, 2011 at 18:22, Igor Egorov <atohom(a)gmail.com> wrote: > This is my first patch, not sure if I done all right. I didn't look at the actual change, but: > mode change 100644 => 100755 dlls/kernel32/process.c doesn't seem necessary to me. -- -Austin

Feb. 5, 2011

Re: gdi32/tests: make sure to use return value (LLVM/Clang)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=8891 Your paranoid android. === WVISTAADM (32 bit font) === Failure running script in VM: The specified guest user must be logged in interactively to perform this operation

Feb. 5, 2011

Including winegcc-built shared library in Debian binary package

by Robert McDonald

I've got a Debian binary package configured. A wrapper script is installed in /usr/bin that invokes wine on the winegcc-built shared library that implements the program. The shared library is installed in /usr/lib and then ldconfig is run during the installation process. The shared library build product seems to be a special case because it is built by winegcc and referenced on the wine command line when run. I've got questions about this even though the product works OK as packaged. Is there a more appropriate installation directory than /usr/lib for the shared library (although lintian complains if I don't put it in /usr/lib)? Does ldconfig need to be run after installing/uninstalling the shared library (other than to satisfy lintian complaints if ldconfig isn't run from postinst/postrm)? Is there any reason to bother with version numbering the shared library (other than using one version number for all library releases just to keep lintian happy by having the version number) since the library is prepared by winegcc and will only be loaded by wine? To look for answers, I've done the following: * searched the web * searched the WineHQ web site and read the FAQ there * scanned the subject lines of a couple of months of this mailing list * read http://wiki.winehq.org/Packaging * used https://wiki.ubuntu.com/PackagingGuide/Complete for some packaging instructions * read http://www.bytehold.com/index.php/projects/176-debian-binary-package-and-re… for general instructions in setting up a Debian binary package * read http://www.pathname.com/fhs/ for recommendations on locating files URLs to relevant resources would be welcome. -- Robert McDonald BitTorrent, Inc.

Feb. 4, 2011

Re: Pulling Patch

by Dan Kegel

James McKenzie wrote: > Actually, the latest patch is what I don't want reused. This one? http://www.winehq.org/pipermail/wine-patches/2011-January/098431.html Why don't you want it reused? > And no, you don't put it in the LGPL until it is committed, That's interesting. I always thought it was LGPL'd as soon as it was sent to the patches list... maybe we should add a note to the mailing list description clarifying this. > Besides, I've been a big enough pain that my existence here is > unwarranted and unneeded. Sounds like you're sore from beating your head against the wall trying to get patches in. Sorry to hear it. So long! - Dan

Feb. 4, 2011

Re: Pulling Patch

by James McKenzie

On 2/4/11 1:18 PM, Dan Kegel wrote: > James McKenzie wrote: >> Since my Mac is dying I have decided to return to the Windows world. >> >> Please pull any and all patches. I have envoked the right to copyright >> and none of my code can or will be used in Wine. > Sorry to see you go, but... why would you want to prohibit people from > using your patches? > > (I only see two typo changes committed: > http://source.winehq.org/git/wine.git/?a=search&h=HEAD&st=author&s=James+Mc… > Presumably you don't mean those, since they were trivial comment changes.) > > I guess you mean patches like > http://www.winehq.org/pipermail/wine-patches/2010-June/089537.html > > When you sent those to wine-patches, weren't you placing them > under the LGPL? Actually, the latest patch is what I don't want reused. And no, you don't put it in the LGPL until it is committed, which I don't expect AJ to do anyway. However, I'm moving in a different direction since my Mac needs more repairs than I'm willing to spend money on. Besides, I've been a big enough pain that my existence here is unwarranted and unneeded. James McKenzie

Feb. 4, 2011

Re: Tray icon not showing up if wine was run previously with DISPLAY unset?

by Alexandre Julliard

Dan Kegel <dank(a)kegel.com> writes: > I guess I could do "sleep 5" but that's an awful kludge. > Probably I'll go back to letting the ugly virtual desktop pop up. > So, what's the proper way to run one app under wine *without* X > while letting other apps run wine *with* X? You can't, but winepath shouldn't be popping up a virtual desktop, that's a bug. -- Alexandre Julliard julliard(a)winehq.org

Feb. 4, 2011

re: Pulling Patch

by Dan Kegel

James McKenzie wrote: > Since my Mac is dying I have decided to return to the Windows world. > > Please pull any and all patches. I have envoked the right to copyright > and none of my code can or will be used in Wine. Sorry to see you go, but... why would you want to prohibit people from using your patches? (I only see two typo changes committed: http://source.winehq.org/git/wine.git/?a=search&h=HEAD&st=author&s=James+Mc… Presumably you don't mean those, since they were trivial comment changes.) I guess you mean patches like http://www.winehq.org/pipermail/wine-patches/2010-June/089537.html When you sent those to wine-patches, weren't you placing them under the LGPL? - Dan

Feb. 4, 2011