In-process wineserver

[Daniel Santos]

I've updated my in-process wineserver hack, cleaned it up a bit more and
fixed a few problems.  So, at least in Star Wars Battlefront II, the
sound and HID problems are fixed (the "select" server call must be made
via the pipe).  I presume there are other server calls with similar
properties.  Also, the wineserver now exits properly and cleans up it's
instance when the main process terminates.  Changed the enabling
enviroment variable to "WINESPEEDHACK".

So what would it take for this to be integrated into wine as an optional
feature?

[Alexandre Julliard]

Daniel Santos <danielfsantos(a)att.net> writes:
> I've updated my in-process wineserver hack, cleaned it up a bit more and
> fixed a few problems.  So, at least in Star Wars Battlefront II, the
> sound and HID problems are fixed (the "select" server call must be made
> via the pipe).  I presume there are other server calls with similar
> properties.  Also, the wineserver now exits properly and cleans up it's
> instance when the main process terminates.  Changed the enabling
> enviroment variable to "WINESPEEDHACK".
>
> So what would it take for this to be integrated into wine as an optional
> feature?

You'll probably have to kill me first ;-)

-- 
Alexandre Julliard
julliard(a)winehq.org

[Juan Lang]

Hi Daniel,

On Mon, Jan 23, 2012 at 3:15 AM, Alexandre Julliard <julliard(a)winehq.org> wrote:
> Daniel Santos <danielfsantos(a)att.net> writes:
> > I've updated my in-process wineserver hack, cleaned it up a bit more and
> > fixed a few problems.  So, at least in Star Wars Battlefront II, the
> > sound and HID problems are fixed (the "select" server call must be made
> > via the pipe).  I presume there are other server calls with similar
> > properties.  Also, the wineserver now exits properly and cleans up it's
> > instance when the main process terminates.  Changed the enabling
> > enviroment variable to "WINESPEEDHACK".
> >
> > So what would it take for this to be integrated into wine as an optional
> > feature?
>
> You'll probably have to kill me first ;-)

a more serious reply:  you may not be aware the Transgaming did just
such a thing years ago, and lobbied pretty heavily for it to be
included.  AJ declined at the time.  The reasons for not including it
remain the same:  because of the possibility of a buggy app taking
down the wineserver, we couldn't ever attempt to support such a beast.
 Any bug reported against it would be suspect.  Worse, people might
report bugs neglecting to mention that they'd enabled it.

So no, we really won't ever include such a feature as part of an
official release around here.  We already have enough trouble with
people reporting bugs in unsupported configurations.

You're welcome to maintain your own fork, or maintain your patch for
people to try in their own Wine builds if they like.
--Juan

[Daniel Santos]

On 01/23/2012 11:01 AM, Juan Lang wrote:
> Hi Daniel,
>
> On Mon, Jan 23, 2012 at 3:15 AM, Alexandre Julliard <julliard(a)winehq.org> wrote:
> > Daniel Santos <danielfsantos(a)att.net> writes:
> > > I've updated my in-process wineserver hack, cleaned it up a bit more and
> > > fixed a few problems.  So, at least in Star Wars Battlefront II, the
> > > sound and HID problems are fixed (the "select" server call must be made
> > > via the pipe).  I presume there are other server calls with similar
> > > properties.  Also, the wineserver now exits properly and cleans up it's
> > > instance when the main process terminates.  Changed the enabling
> > > enviroment variable to "WINESPEEDHACK".
> > >
> > > So what would it take for this to be integrated into wine as an optional
> > > feature?
> > > You'll probably have to kill me first ;-)
> > > Do you have a taster? :D  (jk)
> > > a more serious reply:  you may not be aware the Transgaming did just
> > > such a thing years ago, and lobbied pretty heavily for it to be
> > > included.  AJ declined at the time.  The reasons for not including it
> > > remain the same:  because of the possibility of a buggy app taking
> > > down the wineserver, we couldn't ever attempt to support such a beast.
> > >  Any bug reported against it would be suspect.  Worse, people might
> > > report bugs neglecting to mention that they'd enabled it.
>
> So no, we really won't ever include such a feature as part of an
> official release around here.  We already have enough trouble with
> people reporting bugs in unsupported configurations.
>
> You're welcome to maintain your own fork, or maintain your patch for
> people to try in their own Wine builds if they like.
> --Juan
> Thanks for the history and clarification.  Indeed, it's an ugly little
> beast.  I've tested it on a number of apps and uncovered some other
> other flaws in the patch (no surprise there).  However, I've so far
> found it handy for testing some things, so I think that it's useful. 
> For example, there a few performance bottlenecks I want to create
> specific (conventional) patches for and I already know it will help
> because I can toggle how the call is made (well yes, I know, I can also
> toggle logging, and I did that before, but this just confirms it).

So I can understand your reluctance, but I still think it might be worth
consideration at some point (or in some other incarnation).

Daniel