January 2014 - Wine-Devel - list.winehq.org

Re: [pkg-wine-party] Bug#733605: [PATCH] Add support for GNU/Hurd

by Michael Gilbert

On Fri, Jan 3, 2014 at 6:32 AM, Svante Signell wrote: > - dlls/ntdll/directory.c: Define a character array on the heap of size > 4096 instead of using PATH_MAX, which is not defined for GNU/Hurd. This > approach was used in dlls/ntdll/file.c:server_get_unix_name() where an > array of size 1024 was defined. In case this solution is not OK, a fixed > size array on the stack could be used, or as a last resort adding > #ifndef PATH_MAX; #define PATH_MAX 4096 to that file (not recommended, > at least from a GNU/Hurd aspect). This version of the patch still hard-codes data_size. The Debian hurd porting guide requires paths to be dynamically allocated. Best wishes, Mike

Jan. 3, 2014

Re: [PATCH] Add support for GNU/Hurd

by André Hentschel

Am 03.01.2014 12:32, schrieb Svante Signell: > Hi, > > Currently wine-1.6.1 FTBFS on Debian GNU/Hurd, see > https://buildd.debian.org/status/fetch.php?pkg=wine&arch=hurd-i386&ver=1.6.… This winterbreak i looked into this again, too. I was quite suprised that i had no problems with socket credentials, but it might still be a problem in other hurd distros. > Attached is a patch enabling the build: > > - dlls/ntdll/directory.c: Define a character array on the heap of size > 4096 instead of using PATH_MAX, which is not defined for GNU/Hurd. This > approach was used in dlls/ntdll/file.c:server_get_unix_name() where an > array of size 1024 was defined. In case this solution is not OK, a fixed > size array on the stack could be used, or as a last resort adding > #ifndef PATH_MAX; #define PATH_MAX 4096 to that file (not recommended, > at least from a GNU/Hurd aspect). I recently sent a patch for this and failed, problem is that you can't allocate memory inside an APC callback. I think we should address this first before the other issues. > - libs/wine/ldt.c: Add LDT support for GNU/Hurd > > - dlls/ntdll/signal_i386.c: Add i386 signal handling support for > GNU/Hurd The interesting part of these patches were made by Andrew Nguyen some years ago, i already contacted him some days ago to ask how he wants to proceed with this, no response yet. > Applications tested so far (slow to start) include cmd, hostname, clock, > winemine, wineconsole, notepad, wordpad and explorer. These are winelib apps and a bad indicator for functionality. I tried PowerPointViewer here for this reason and it installs and runs.

Jan. 3, 2014

Re: [PATCH 4/5] scrrun: Implement IEnumVARIANT stub for folder collection (try2)

by Dmitry Timoshkov

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > +static inline ULONG get_refcount(IUnknown *iface) > +{ > + ULONG ref = IUnknown_AddRef(iface); > + IUnknown_Release(iface); > + return ref-1; > +} This one still looks somewhat strange. Why not do something more straightforward like the following one? static inline ULONG get_refcount(IUnknown *iface) { IUnknown_AddRef(iface); return IUnknown_Release(iface); } -- Dmitry.

Jan. 3, 2014

Re: [PATCH 4/5] scrrun: Implement IEnumVARIANT stub for folder collection

by Nikolay Sivov

On 1/3/2014 16:03, Dmitry Timoshkov wrote: > Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > >>>> +static inline ULONG get_refcount(IUnknown *iface) >>>> +{ >>>> + ULONG ref = IUnknown_AddRef(iface); >>>> + IUnknown_Release(iface); >>>> + return ref; >>>> +} >>> This implementation may lead to wrong conclusions. >>> >> What you mean? > It doesn't do what its name suggests. > Ah, ok.

Jan. 3, 2014

Re: How to bisect the 1.6.x series of commits

by Frédéric Delanoy

On Fri, Jan 3, 2014 at 8:18 AM, Alan W. Irwin <irwin(a)beluga.phys.uvic.ca> wrote: > On 2014-01-02 13:07-0600 Ken Thomases wrote: > Just out of curiosity what would git do if you tried to do a bisect > between 1.6.1 (for a case where that was "good") and the latest 1.7.x > release (for a case where that was "bad"). There is obviously no > direct forward development path between the two cases. Would git > error out or would it automatically bisect using a development path > consisting of the reverse development path back to 1.6 combined with > the forward development path from there to the latest 1.7 release? It would find a common ancestor, and have you test thie (1.6 in this case (and warn you about this). e.g. in this case: $ git bisect start $ git bisect bad master $ git bisect good wine-1.6.1 Bisecting: a merge base must be tested [50dc4cd636cc88031e0a49697ccc9f03b398e449] Release 1.6. -- Frédéric Delanoy

Jan. 3, 2014

Re: [PATCH 4/5] scrrun: Implement IEnumVARIANT stub for folder collection

by Dmitry Timoshkov

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > >> +static inline ULONG get_refcount(IUnknown *iface) > >> +{ > >> + ULONG ref = IUnknown_AddRef(iface); > >> + IUnknown_Release(iface); > >> + return ref; > >> +} > > This implementation may lead to wrong conclusions. > > > What you mean? It doesn't do what its name suggests. -- Dmitry.

Jan. 3, 2014

[PATCH] Add support for GNU/Hurd

by Svante Signell

Hi, Currently wine-1.6.1 FTBFS on Debian GNU/Hurd, see https://buildd.debian.org/status/fetch.php?pkg=wine&arch=hurd-i386&ver=1.6.… Attached is a patch enabling the build: - dlls/ntdll/directory.c: Define a character array on the heap of size 4096 instead of using PATH_MAX, which is not defined for GNU/Hurd. This approach was used in dlls/ntdll/file.c:server_get_unix_name() where an array of size 1024 was defined. In case this solution is not OK, a fixed size array on the stack could be used, or as a last resort adding #ifndef PATH_MAX; #define PATH_MAX 4096 to that file (not recommended, at least from a GNU/Hurd aspect). - libs/wine/ldt.c: Add LDT support for GNU/Hurd - dlls/ntdll/signal_i386.c: Add i386 signal handling support for GNU/Hurd Applications tested so far (slow to start) include cmd, hostname, clock, winemine, wineconsole, notepad, wordpad and explorer. This patch is sent upstream on recommendation by the Debian Wine maintainers, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733605 Thanks!

Jan. 3, 2014

Re: [PATCH 4/5] scrrun: Implement IEnumVARIANT stub for folder collection

by Nikolay Sivov

On 1/3/2014 14:25, Dmitry Timoshkov wrote: > Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > >> +static inline ULONG get_refcount(IUnknown *iface) >> +{ >> + ULONG ref = IUnknown_AddRef(iface); >> + IUnknown_Release(iface); >> + return ref; >> +} > This implementation may lead to wrong conclusions. > What you mean?

Jan. 3, 2014

Re: [PATCH 4/5] scrrun: Implement IEnumVARIANT stub for folder collection

by Dmitry Timoshkov

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > +static inline ULONG get_refcount(IUnknown *iface) > +{ > + ULONG ref = IUnknown_AddRef(iface); > + IUnknown_Release(iface); > + return ref; > +} This implementation may lead to wrong conclusions. -- Dmitry.

Jan. 3, 2014

Re: How to bisect the 1.6.x series of commits

by Alan W. Irwin

On 2014-01-02 13:07-0600 Ken Thomases wrote: > On Jan 2, 2014, at 1:01 PM, Alan W. Irwin wrote: > >> I have bisected Wine regressions several times in the last year >> following the cookbook in http://wiki.winehq.org/RegressionTesting. >> Those bisections were for the principal branch (or whatever you call >> it) of development. How do you do similar bisections for the branch of >> development from 1.6 to 1.6.1? I need the name of that branch of >> development and how you specify it to the bisect process. Sorry for >> the git newbie question, but following the above cookbook has been >> essentially my only git experience to date. >> >> The reason I am asking about bisecting from 1.6 to 1.6.1 is I have >> recently found some fairly strong evidence that there is an important >> regression in behavior between 1.6-rc4 and 1.6.1. > > You can simply do "git bisect good wine-1.6-rc4" and "git bisect bad wine-1.6.1" or the equivalent. Git will traverse the commits between them. It doesn't need a branch name or anything like that. Thanks to you and André Hentschel for responding to my git question. Just out of curiosity what would git do if you tried to do a bisect between 1.6.1 (for a case where that was "good") and the latest 1.7.x release (for a case where that was "bad"). There is obviously no direct forward development path between the two cases. Would git error out or would it automatically bisect using a development path consisting of the reverse development path back to 1.6 combined with the forward development path from there to the latest 1.7 release? Although I am interested in the answer to the above question for future reference, it turns out I am not going to need to do a git bisect at the present time; I used bash.exe up-arrow to reconstruct the exact commands I used that generated the dynamic load errors before and put those commands in a script in preparation for a bisect. However,that script cannot reproduce the error and gives the same good test result for 1.6.1 that I got with 1.6-rc4 before! The good script result is for a fresh restart of wineconsole and bash.exe however, so I ascribe the previous dynamic load error results I observed with 1.6.1 to a stale wineconsole/bash.exe environment that had somehow been clobbered by previous commands I had done in that environment. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net) the Time Ephemerides project (timeephem.sf.net) PLplot scientific plotting software package (plplot.sf.net) the libLASi project (unifont.org/lasi) the Loads of Linux Links project (loll.sf.net) and the Linux Brochure Project (lbproject.sf.net) __________________________ Linux-powered Science __________________________

Jan. 3, 2014