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

Re: Concerning the separate OpenAL32.dll thunk patch and OpenALwinmm driver patch

by Nick Burns

Ok this is some good feedback... (usually i dont get such a massive response from emails...) -- I was under the impression that RFC was the second to last line of defense (so it appears to be the third) I do not use IRC (unless you count the irc client in Tribes) I can demacroize the patch -- it was written that way to make it small and easy to add to (since 99% of the functions are pure passthru -- one extra line to the macro adds it and all that it needs) Personally I think its cleaner -- but it has the problem of being a macro "There not much worse than a macro -- except dare I mention templates (the crowd runs for cover)" Again -- for the sound drivers -- Mac OSX has ONE sound driver ONE I would like to have a choice. Yes my wineopenal patch is not perfect (based on broken code does not help) -- I know that -- but thats why i want to get it into wine -- so other people who know more about audio can add to it and make it better If the audio drivers are going to collapse -- I could wait until then and 'try' add my winmm patch in that realm. - Nick >From: Alexandre Julliard <julliard(a)winehq.org> >To: Detlef Riekenberg <wine.dev(a)web.de> >CC: Nick Burns <adger44(a)hotmail.com>, wine-devel <wine-devel(a)winehq.org> >Subject: Re: Concerning the separate OpenAL32.dll thunk patch and >OpenALwinmm driver patch >Date: Thu, 30 Nov 2006 19:58:36 +0100 > >Detlef Riekenberg <wine.dev(a)web.de> writes: > > > I don't know, if wineaudio.drv this is still the way to go, but we have > > sound crackeling and Buffer-underun Bugs, and adding another copy of > > the "not very well working" code might be a "no go" for Alexandre. > >Exactly, we already have 8 sound drivers, and not a single one >actually works properly, so I'm pretty reluctant to add yet another >copy of the same broken code. > >The openal dll can certainly go in, but you'll need to clean up the >code first, right now it looks like a pretty bad case of macro abuse. > >-- >Alexandre Julliard >julliard(a)winehq.org

Nov. 30, 2006

Re: msi: Add handling for the StartServices action [try2]

by Robert Shearman

James Hawkins wrote: > + scm = OpenSCManagerW(NULL, NULL, SC_MANAGER_ALL_ACCESS); This can be just SC_MANAGER_CONNECT instead. -- Rob Shearman

Nov. 30, 2006

Re: make check_no_exec() work reliable

by Alexandre Julliard

Peter Beutner <p.beutner(a)gmx.net> writes: > Why should this exception be visible to the application? > Plus if you make it visible, you can just forget this whole workaround idea, > because it won't work reliable anyways. Well, yes, the workaround is really a hack that should be replaced by a proper fix; I was hoping it would encourage someone to look into it and fix it properly, I can't do it because my box doesn't have noexec support. > Certainly some more testing on windows is needed, but this > check_no_exec() workaround was regardless introduced a long time ago. > This patch just fixes this workaround. > Otherwise it could as well be removed at all. Well, yes, it could certainly be removed; I added it mostly to make sure that we generated the exception properly, and to demonstrate how the exception can be handled. The proper fix is clearly more complex than that, but moving that hack into the exception code isn't a step in the right direction IMO. -- Alexandre Julliard julliard(a)winehq.org

Nov. 30, 2006

Re: Concerning the separate OpenAL32.dll thunk patch and OpenAL winmm driver patch

by Stefan Dösinger

Am Donnerstag 30 November 2006 07:00 schrieb Nick Burns: > The patches have been split in 2 one for the thunk and one for the winmm > driver. > > Have these patches been rejected? > (I still dont know how to tell that -- other than checking wine-cvs) The best thing is to ask AJ directly why he didn't apply the patches. From my personal experiance it is best to ask him on irc

Nov. 30, 2006

Re: Concerning the separate OpenAL32.dll thunk patch and OpenAL winmm driver patch

by Alexandre Julliard

Detlef Riekenberg <wine.dev(a)web.de> writes: > I don't know, if wineaudio.drv this is still the way to go, but we have > sound crackeling and Buffer-underun Bugs, and adding another copy of > the "not very well working" code might be a "no go" for Alexandre. Exactly, we already have 8 sound drivers, and not a single one actually works properly, so I'm pretty reluctant to add yet another copy of the same broken code. The openal dll can certainly go in, but you'll need to clean up the code first, right now it looks like a pretty bad case of macro abuse. -- Alexandre Julliard julliard(a)winehq.org

Nov. 30, 2006

Re: user32: Factorize graphics driver's WindowCreate and ShowWindow in user32.

by Pierre d'Herbemont

On 30 nov. 06, at 05:34, Dmitry Timoshkov wrote: > "Pierre d'Herbemont" <pdherbemont(a)free.fr> wrote: > >> At the same time ShowWindow gets factorized because WindowCreate >> and ShowWindow share both the use of WINPOS_MinMaximize, so it is >> easier to factorize both functions in a single patch. In fact >> ShowWindow is removed entirely from the drivers as it is driver >> independant. >> To properly factorize WindowCreate we have to export 3 new >> functions from the graphics driver which are SetIconicState, >> SyncWindowStyle, SystrayDockWindow. > > I'd suggest to leave ShowWindow in the driver's interface. You already > have created 3 new entry points to replace its partial functionality, > but still miss ShowWindow functionality for at least SW_RESTORE and > SW_MAXIMIZE. My patch is wrong, but I am not sure we should leave ShowWindow in the driver: It contains only Win32 calls (appart from WINPOS_MinMaximize), and is indeed a wrapper for SetWindowPos. And the exports are needed for CreateWindow, not ShowWindow. What makes me move ShowWindow in user is the call to WINPOS_MinMaximize which is shared with CreateWindow, and this one needs the SetIconicState. > Also did you run 'make test' after this patch? I am sorry I missed that point which shows that my patch is wrong, thanks for pointing this to me. I'll try to fix that. Pierre.

Nov. 30, 2006

Re: [winetest] Make sure we can send larger files

by Dimi Paun

On Thu, November 30, 2006 1:01 pm, Paul Vriens wrote: > I'm hitting the 1MB limit already with my win98 tests. Most other tests > are about to reach that threshold as well. I'd make it 2MB, what's 1MB these days... :) -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

Nov. 30, 2006

Re: make check_no_exec() work reliable

by Peter Beutner

Alexandre Julliard wrote: > Peter Beutner <p.beutner(a)gmx.net> writes: > >> Peter Beutner wrote: >>> Before starting to make this whole noexecute override behaviour configurable, >>> it first must work reliable. In its current form there is no guarantee that >>> the check_no_exec() function is actually called, because any other installed >>> exception handler might decide to handle the exception itself. >>> And as seen by the number of failing applications, this seems to happen >>> quite a lot. >>> This patch therefore makes check_no_exec() to be called before any other >>> exception handler. >>> >>> --- >> Any comments what is wrong with this one? > > If the exception is not made visible to the app then there is no point > in having one at all, we might just as well turn off the protection > right away. Why should this exception be visible to the application? Plus if you make it visible, you can just forget this whole workaround idea, because it won't work reliable anyways. And remembering the last discussion I thought "just turning off the protection" wasn't your preferred solution either. > What really needs to be done is to investigate the Windows > behavior and determine which parts of the app memory should be > protected and which shouldn't, depending on the exe flags etc. and > then replicate that behavior. > Certainly some more testing on windows is needed, but this check_no_exec() workaround was regardless introduced a long time ago. This patch just fixes this workaround. Otherwise it could as well be removed at all.

Nov. 30, 2006

Re: Concerning the separate OpenAL32.dll thunk patch and OpenAL winmm driver patch

by Steven Edwards

On 11/30/06, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > What makes it worth including it in wine is that a huge number of games use it > too. Thunking directly to the Linux / macos openal lib avoids the whole > openal->directsound->winmm->driver->linux audio api rollercoaster. I agree, if having this lib in the wine tree lets us skip the whole rollercoaster and produces better results for the users then we should include it. -- 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. 30, 2006

Re: make check_no_exec() work reliable

by Alexandre Julliard

Peter Beutner <p.beutner(a)gmx.net> writes: > Peter Beutner wrote: >> Before starting to make this whole noexecute override behaviour configurable, >> it first must work reliable. In its current form there is no guarantee that >> the check_no_exec() function is actually called, because any other installed >> exception handler might decide to handle the exception itself. >> And as seen by the number of failing applications, this seems to happen >> quite a lot. >> This patch therefore makes check_no_exec() to be called before any other >> exception handler. >> >> --- > Any comments what is wrong with this one? If the exception is not made visible to the app then there is no point in having one at all, we might just as well turn off the protection right away. What really needs to be done is to investigate the Windows behavior and determine which parts of the app memory should be protected and which shouldn't, depending on the exe flags etc. and then replicate that behavior. -- Alexandre Julliard julliard(a)winehq.org

Nov. 30, 2006