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

Re: why is Kronenberg's Wine/Mac work blacklisted on winehq?

by Brian Vincent

On Fri, Jun 26, 2009 at 2:42 PM, Mike Kronenberg < mike.kronenberg(a)kronenberg.org> wrote: > OS X > My main concern is to have usable builds. Ie, usable without the need of a > terminal. People on OS X don't care about how stuff works, it just has to > work. > > Vanilla build > I totally agree that by adding certain patches, the builds can't be > considered as vanilla. > I'll recheck the necessity of the patches again on Tiger and Leopard and > they really get less and less. My $.02: we've got two different problems we're trying to solve with the same build. We're trying to give the user a great user experience by including lots of extras; and this is a Noble Goal and a Good Thing. We're also trying to collect good bug reports that aren't tainted by crap; and this is also a Noble Goal and Good Thing. It seems like this could be solved by two different builds. Keep the Darwine stuff the way it is, just put a huge warning label on it that says the code is unsupported. Second, provide another binary build that's as much of a vanilla wine as possible. Because we like our user community and we like to be nice to them, we'll provide links to BOTH of them from the Wine website as well as put the giant UNSUPPORTED stamp on the first one. Then we tell Mac users if they want to submit a bug report they should download and install this other package and try to reproduce their bug. Now, the side effect there is that maybe it will improve the quality of bugs being reported. Folks who take the time to download that extra package, set up their environment properly, etc, etc, well, they probably have the ability to also write a coherent bug report. (You could also argue that rather than provide this second package you could simply make people compile it themselves, but I'd argue that it makes it an order of magnitude harder to submit a bug report and we'd effectively alienate the vast majority of the user community.) Oh, and we have a branding issue where this code magically transforms from Wine into something by another name. I completely understand why we're not a big fan of that. I also understand it could break things if you attempt to change paths. However, the sooner you do that, the sooner it gets done. It's actually doing the user community a disservice by calling it Darwine rather than Wine. If you throw "Darwine" into Google, you don't turn up a single site on the first page that's a Wine web page. As a result, all the great things like our AppDB, Wiki, developer tips, etc aren't a resource for that user community. (Wow! Look at our Page Rank for "Wine". We need to start selling bottles of wine on winehq.org.) -Brian

June 30, 2009

Re: [3/7] [wined3d] add NP2 fixup code to shader_arb_generate_pshader (resend)

by Tobias Jakobi

Won't work since the GL_LIMITS macro is defined in this way: #define GL_LIMITS(ExtName) (GLINFO_LOCATION.max_##ExtName) I don't think changing the variable name is an option, since keeping consistency there should be priority: ps_arb_max_local_constants -> ??? (I don't think it's wise to drop the ps_arb prefix, since it's specific to ARB and specific to PS).

June 30, 2009

Re: [4/7] [wined3d] add NP2 fixup code to shader_hw_sample (ARB) (resend)

by Tobias Jakobi

It's very easy. Only ordinary sampling is supported, because I have no application which I can use to test the others variants (only support the features you can actually test).

June 30, 2009

Re: [2/7] [wined3d] add arb_ps_np2fixup_info structure (resend)

by Tobias Jakobi

*hint* *hint* See the commit message!

June 30, 2009

Re: server/fd.c: Prevent using uninitialized pointers

by Henri Verbeet

2009/6/30 Daniel Santos <javatroubadour(a)yahoo.com>: > Some pointers are getting used prior to initialization. It would appear that the current compilers are initializing them to zero or we've been lucky. > No, the C standard specifies that these are initialized to NULL, since they have static storage duration.

June 30, 2009

Re: server/fd.c: Prevent using uninitialized pointers

by Matteo Bruni

I'm quite sure that C standards guarantee global variables are initialized to 0. 2009/6/30 Daniel Santos <javatroubadour(a)yahoo.com>: > Some pointers are getting used prior to initialization. It would appear that the current compilers are initializing them to zero or we've been lucky. > > > > > >

June 30, 2009

Appdb flight simulation sub category

by Keith Muir

Hi, Any chance of a games> simulation> flight simulation sub category? Regards, Keith

June 30, 2009

Re: Fw: Re: Removing active maintainers

by Austin English

On Tue, Jun 30, 2009 at 10:21 AM, James Mckenzie<jjmckenzie51(a)earthlink.net> wrote: > Sent to Rosanne only, meant to send it to the list as a comment to this thread. > > James McKenzie > > -----Forwarded Message----- >>From: James Mckenzie <jjmckenzie51(a)earthlink.net> >>Sent: Jun 29, 2009 6:36 PM >>To: Rosanne DiMesio <dimesio(a)earthlink.net> >>Subject: Re: Removing active maintainers >> >>Rosanne DiMesio <dimesio(a)earthlink.net> Subject: Re: Removing active maintainers >>> >>>On Mon, 29 Jun 2009 14:56:23 +0200 >>>Remco <remco47(a)gmail.com> wrote: >>> >>>> On Mon, Jun 29, 2009 at 2:22 PM, Rosanne DiMesio<dimesio(a)earthlink.net> wrote: >>>> > That would still leave the test results sitting there unprocessed for weeks, which leaves a pretty bad impression on the users who submitted them. Test results for apps without maintainers get processed by the admins within 24 hours. >>>> >>>> How about mailing admins after 24 hours? Maintainers are useful to >>>> offload tasks of admins. If they are away for a while, admins just get >>>> the mail as if there were no maintainer. If you have to remove a >>>> maintainer every time he can't respond in 24 hours, you won't have >>>> many left after a while. >>>> >>>> Remco >>> >>>Nobody's suggesting a 24 hour time limit for maintainers. >>> >>>As for emailing the admins, I know I turned off emails from the AppDB to avoid having my mailbox overwhelmed with hundreds of useless notices every day, >>>and I doubt I'm the only one who did this. http://bugs.winehq.org/show_bug.cgi?id=14755 needs to be fixed first for any solution that involves emailing >>>admins to be viable. >> >>I see several good ideas here: >> >>1. Maintainers should be able to mark themselves as not available. No reason should be required. >>2. Admins should have the ability to suspend a maintainer for non-response. There are several reasons for not responding and most of them would be considered an emergency. >>3. Any maintainer who fails, after three suspensions, to properly carry out the functions of being a maintainer, should be banned for a specific period of time, increases to a complete ban. >>4. What maintainers have to do to maintain their status should be posted on the Maintainers page when you sign up and a reminder message every 90 days or so should be sent out to keep maintainers honest. >>5. Maintainers should be given the option of gracefully resigning when they no longer can perform the duties of their position. A lot of these suggestions are overly complex and require a lot of modification to the AppDB. There's only one person really working on it (thanks Alexander!), but keep in mind that while it's easy to suggest lots of complex changes to the AppDB, it only matters if someone is willing to take the time to do that work. TL;DR AppDB patches needed. -- -Austin

June 30, 2009

Fw: Re: Removing active maintainers

by James Mckenzie

Sent to Rosanne only, meant to send it to the list as a comment to this thread. James McKenzie -----Forwarded Message----- >From: James Mckenzie <jjmckenzie51(a)earthlink.net> >Sent: Jun 29, 2009 6:36 PM >To: Rosanne DiMesio <dimesio(a)earthlink.net> >Subject: Re: Removing active maintainers > >Rosanne DiMesio <dimesio(a)earthlink.net> Subject: Re: Removing active maintainers >> >>On Mon, 29 Jun 2009 14:56:23 +0200 >>Remco <remco47(a)gmail.com> wrote: >> >>> On Mon, Jun 29, 2009 at 2:22 PM, Rosanne DiMesio<dimesio(a)earthlink.net> wrote: >>> > That would still leave the test results sitting there unprocessed for weeks, which leaves a pretty bad impression on the users who submitted them. Test results for apps without maintainers get processed by the admins within 24 hours. >>> >>> How about mailing admins after 24 hours? Maintainers are useful to >>> offload tasks of admins. If they are away for a while, admins just get >>> the mail as if there were no maintainer. If you have to remove a >>> maintainer every time he can't respond in 24 hours, you won't have >>> many left after a while. >>> >>> Remco >> >>Nobody's suggesting a 24 hour time limit for maintainers. >> >>As for emailing the admins, I know I turned off emails from the AppDB to avoid having my mailbox overwhelmed with hundreds of useless notices every day, >>and I doubt I'm the only one who did this. http://bugs.winehq.org/show_bug.cgi?id=14755 needs to be fixed first for any solution that involves emailing >>admins to be viable. > >I see several good ideas here: > >1. Maintainers should be able to mark themselves as not available. No reason should be required. >2. Admins should have the ability to suspend a maintainer for non-response. There are several reasons for not responding and most of them would be considered an emergency. >3. Any maintainer who fails, after three suspensions, to properly carry out the functions of being a maintainer, should be banned for a specific period of time, increases to a complete ban. >4. What maintainers have to do to maintain their status should be posted on the Maintainers page when you sign up and a reminder message every 90 days or so should be sent out to keep maintainers honest. >5. Maintainers should be given the option of gracefully resigning when they no longer can perform the duties of their position. > >James McKenzie > >> >>-- >>Rosanne DiMesio <dimesio(a)earthlink.net> >> >>

June 30, 2009

Re: configure.ac: make sure we can run cmdlgtst and view from outside wine tree

by Austin English

On Tue, Jun 30, 2009 at 6:17 AM, Michael Stefaniuc<mstefani(a)redhat.com> wrote: > Austin English wrote: >> On Mon, Jun 29, 2009 at 10:37 PM, Detlef Riekenberg<wine.dev(a)web.de> wrote: >>> On Mo, 2009-06-29 at 12:50 -0500, Austin English wrote: >>>> With this patch, they are treated like other programs, e.g., winhlp32, >>>> and installed, so one can use: >>>> $ wine view >>>> and get the same effect. >>> That parts of configure.ac are created by tools/make_makefiles >>> >>> tools/make_makefiles-50-# Programs that we don't want to install at all >>> tools/make_makefiles-51-my %dont_install = >>> tools/make_makefiles-52-( >>> tools/make_makefiles:53: "cmdlgtst" => 1, >>> tools/make_makefiles-54- "view" => 1, >>> tools/make_makefiles-55- "winetest" => 1, >>> tools/make_makefiles-56-); >> >> Good to know, thanks. But AJ told me on IRC he won't accept it, since >> he doesn't think those binaries should be used outside of the tree. > Right, those aren't needed by users. > > I really wonder what purpose cmdlgtest serves this days and if it > shouldn't be just removed. Actually, it's got a bug open that should probably be fixed before that's considered: http://bugs.winehq.org/show_bug.cgi?id=17495 -- -Austin

June 30, 2009

Re: [2/7] [wined3d] add arb_ps_np2fixup_info structure (resend)

by Henri Verbeet

2009/6/30 Stefan Dösinger <stefandoesinger(a)gmx.at>: > Am Monday 29 June 2009 21:41:33 schrieb Tobias Jakobi: > > Is there a particular reason why you reordered many elements in struct > arb_ps_np2fixup_info? > > > I'd guess for alignment.

June 30, 2009

Re: [3/7] [wined3d] add NP2 fixup code to shader_arb_generate_pshader (resend)

by Stefan Dösinger

Am Monday 29 June 2009 21:41:58 schrieb Tobias Jakobi: + const UINT max_lconsts = gl_info->ps_arb_max_local_constants; Please use the GL_LIMITS macro for consistency

June 30, 2009

Re: [4/7] [wined3d] add NP2 fixup code to shader_hw_sample (ARB) (resend)

by Stefan Dösinger

Am Monday 29 June 2009 21:42:20 schrieb Tobias Jakobi: > + if (flags) FIXME("Only ordinary sampling from NP2 textures is supported.\n"); Why does projected sampling not work? Is this a limit of Tex_rect or the NP2 fixup code? TXB certainly does not work because tex_rect doesn't support mipmapping Its fine with me if projected texturing is just not implemented in this patchset currently, I'm just curious. If it is not a GL limit it should just work with the code you wrote, unless I am missing something.

June 30, 2009

Re: [2/7] [wined3d] add arb_ps_np2fixup_info structure (resend)

by Stefan Dösinger

Am Monday 29 June 2009 21:41:33 schrieb Tobias Jakobi: Is there a particular reason why you reordered many elements in struct arb_ps_np2fixup_info?

June 30, 2009

Re: configure.ac: make sure we can run cmdlgtst and view from outside wine tree

by Michael Stefaniuc

Austin English wrote: > On Mon, Jun 29, 2009 at 10:37 PM, Detlef Riekenberg<wine.dev(a)web.de> wrote: >> On Mo, 2009-06-29 at 12:50 -0500, Austin English wrote: >>> With this patch, they are treated like other programs, e.g., winhlp32, >>> and installed, so one can use: >>> $ wine view >>> and get the same effect. >> That parts of configure.ac are created by tools/make_makefiles >> >> tools/make_makefiles-50-# Programs that we don't want to install at all >> tools/make_makefiles-51-my %dont_install = >> tools/make_makefiles-52-( >> tools/make_makefiles:53: "cmdlgtst" => 1, >> tools/make_makefiles-54- "view" => 1, >> tools/make_makefiles-55- "winetest" => 1, >> tools/make_makefiles-56-); > > Good to know, thanks. But AJ told me on IRC he won't accept it, since > he doesn't think those binaries should be used outside of the tree. Right, those aren't needed by users. I really wonder what purpose cmdlgtest serves this days and if it shouldn't be just removed. bye michael

June 30, 2009

Re: oleaut32: Build language resource files separately

by Michael Stefaniuc

Alexandre Julliard wrote: > Michael Stefaniuc <mstefani(a)redhat.com> writes: > >> Well, Alexandre did the first patch for programs/clock >> http://source.winehq.org/git/wine.git/?a=commit;h=aa41526c73a5fbcc2c08a9342… >> so it must be right ;). It increases the resilience as errors in one >> language rc file do not propagate to the other languages. There might be >> some other reason but I forgot. Alexandre asked me if I could do it as >> it is an easy search and replace style janitorial job. > > Another reason is that it makes it possible to update the makefile > automatically when a resource file is added. > > BTW 8-bit chars are mangled in most of your patches... I really *HATE* mutt's handling of 8bit emails. It always detects the character set wrong aka as UTF-8 and git checks that the file really is UTF-8. I'm resending the affected files. thanks bye michael

June 30, 2009

Re: oleaut32: Build language resource files separately

by Michael Stefaniuc

Paul Vriens wrote: > Michael Stefaniuc wrote: >> Hello Nikolay, >> >> Nikolay Sivov wrote: >>> Michael Stefaniuc wrote: >>>> instead of including them from an other rc file. >>>> --- >>>> >>> What is the purpose of these changes? I'm not talking it's wring :), >>> just interested. >> Well, Alexandre did the first patch for programs/clock >> http://source.winehq.org/git/wine.git/?a=commit;h=aa41526c73a5fbcc2c08a9342… >> >> so it must be right ;). It increases the resilience as errors in one >> language rc file do not propagate to the other languages. There might be >> some other reason but I forgot. Alexandre asked me if I could do it as >> it is an easy search and replace style janitorial job. >> >> > Well the next steps could be: > > - unify the names of the resource files <dll>_<countrycode>.rc I hate those names. <countrycode>.rc is so much easier to find and access. > - have make_makefiles do the real work so we don't have to change the > makefile manually. > > (not sure if that first step is needed or if we could just check for all > .rc files). Well, we had at one point in time commented out included of language rc files. If a big change invalidates a rc file (doesn't build anymore) it is easy to workaround by temporary removing the culprit rc file from the Makefile.in. If instead all rc files are build and linked automatically one would have to git rm the broken rc files. bye michael

June 30, 2009

Re: oleaut32: Build language resource files separately

by Alexandre Julliard

Michael Stefaniuc <mstefani(a)redhat.com> writes: > Well, Alexandre did the first patch for programs/clock > http://source.winehq.org/git/wine.git/?a=commit;h=aa41526c73a5fbcc2c08a9342… > so it must be right ;). It increases the resilience as errors in one > language rc file do not propagate to the other languages. There might be > some other reason but I forgot. Alexandre asked me if I could do it as > it is an easy search and replace style janitorial job. Another reason is that it makes it possible to update the makefile automatically when a resource file is added. BTW 8-bit chars are mangled in most of your patches... -- Alexandre Julliard julliard(a)winehq.org

June 30, 2009

Re: [PATCH 4/4] gdi32: Add tests for the GetWinMetaFileBits MFCOMMENT record.

by Huw Davies

On Tue, Jun 30, 2009 at 12:40:54PM +0200, Paul Vriens wrote: > Huw Davies wrote: >> --- >> dlls/gdi32/tests/metafile.c | 80 +++++++++++++++++++++++++++++++++++++++++++ >> 1 files changed, 80 insertions(+), 0 deletions(-) >> >> >> ------------------------------------------------------------------------ >> >> > Hi Huw, > > Could you use CreateEnhMetaFileA here: > > + SetRect(&rc, 1000,2000, 3000, 6000); > + emf_dc = CreateEnhMetaFileW(display_dc, NULL, &rc, NULL); > > The W-version is not implemented on Win9x so this test would crash. Hi Paul, Yup, resent. Thanks! Huw.

June 30, 2009

Re: oleaut32: Build language resource files separately

by Paul Vriens

Michael Stefaniuc wrote: > Hello Nikolay, > > Nikolay Sivov wrote: >> Michael Stefaniuc wrote: >>> instead of including them from an other rc file. >>> --- >>> >> What is the purpose of these changes? I'm not talking it's wring :), >> just interested. > Well, Alexandre did the first patch for programs/clock > http://source.winehq.org/git/wine.git/?a=commit;h=aa41526c73a5fbcc2c08a9342… > so it must be right ;). It increases the resilience as errors in one > language rc file do not propagate to the other languages. There might be > some other reason but I forgot. Alexandre asked me if I could do it as > it is an easy search and replace style janitorial job. > > bye > michael > > Well the next steps could be: - unify the names of the resource files <dll>_<countrycode>.rc - have make_makefiles do the real work so we don't have to change the makefile manually. (not sure if that first step is needed or if we could just check for all .rc files). -- Cheers, Paul.

June 30, 2009

Re: oleaut32: Build language resource files separately

by Nikolay Sivov

Michael Stefaniuc wrote: > Hello Nikolay, > > Nikolay Sivov wrote: > >> Michael Stefaniuc wrote: >> >>> instead of including them from an other rc file. >>> --- >>> >>> >> What is the purpose of these changes? I'm not talking it's wring :), >> just interested. >> > Well, Alexandre did the first patch for programs/clock > http://source.winehq.org/git/wine.git/?a=commit;h=aa41526c73a5fbcc2c08a9342… > so it must be right ;). Didn't spot that, sorry. > It increases the resilience as errors in one > language rc file do not propagate to the other languages. There might be > some other reason but I forgot. Alexandre asked me if I could do it as > it is an easy search and replace style janitorial job. > > bye > michael Thanks for reply.

June 30, 2009

Re: [PATCH 4/4] gdi32: Add tests for the GetWinMetaFileBits MFCOMMENT record.

by Paul Vriens

Huw Davies wrote: > --- > dlls/gdi32/tests/metafile.c | 80 +++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 80 insertions(+), 0 deletions(-) > > > ------------------------------------------------------------------------ > > Hi Huw, Could you use CreateEnhMetaFileA here: + SetRect(&rc, 1000,2000, 3000, 6000); + emf_dc = CreateEnhMetaFileW(display_dc, NULL, &rc, NULL); The W-version is not implemented on Win9x so this test would crash. -- Cheers, Paul.

June 30, 2009

Re: oleaut32: Build language resource files separately

by Michael Stefaniuc

Hello Nikolay, Nikolay Sivov wrote: > Michael Stefaniuc wrote: >> instead of including them from an other rc file. >> --- >> > What is the purpose of these changes? I'm not talking it's wring :), > just interested. Well, Alexandre did the first patch for programs/clock http://source.winehq.org/git/wine.git/?a=commit;h=aa41526c73a5fbcc2c08a9342… so it must be right ;). It increases the resilience as errors in one language rc file do not propagate to the other languages. There might be some other reason but I forgot. Alexandre asked me if I could do it as it is an easy search and replace style janitorial job. bye michael

June 30, 2009

Removing active maintainers

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

Hi, so far I found that Remco made the best suggestions. >From a quality of service point of view, unmaintained apps provide a more pleasing experience to the test data submiter: data is generally accepted within a fraction of a day. Not so for maintained apps. Why? Simple: there's a (large?) pool of general admins, so response time is low. OTOH, what response time can you expect from a single maintainer? My suggestion variant is: Delegate submissions after no more than 3 days from the maintainer to the general pool. Or what Remco suggested: accept by default pool, still notify maintainers so they can edit it afterwards. Easy to understand; easy to implement; best response time. Why look elsewhere? Find something else for removing people who volunteered(!) to maintain something. E.g. I'll be on vacation for 3 weeks, I'll never leave a ~/.vacation to please spammers, so I find the "8day response or be kicked" pretty tough. Regards, Jörg Höhle

June 30, 2009

Re: configure.ac: make sure we can run cmdlgtst and view from outside wine tree

by Austin English

On Mon, Jun 29, 2009 at 10:37 PM, Detlef Riekenberg<wine.dev(a)web.de> wrote: > On Mo, 2009-06-29 at 12:50 -0500, Austin English wrote: >> With this patch, they are treated like other programs, e.g., winhlp32, >> and installed, so one can use: >> $ wine view >> and get the same effect. > > That parts of configure.ac are created by tools/make_makefiles > > tools/make_makefiles-50-# Programs that we don't want to install at all > tools/make_makefiles-51-my %dont_install = > tools/make_makefiles-52-( > tools/make_makefiles:53: "cmdlgtst" => 1, > tools/make_makefiles-54- "view" => 1, > tools/make_makefiles-55- "winetest" => 1, > tools/make_makefiles-56-); Good to know, thanks. But AJ told me on IRC he won't accept it, since he doesn't think those binaries should be used outside of the tree. -- -Austin

June 30, 2009