Re: Patchsets that need review by experienced Wine Developers

[Michael Ost]

Hi, list.

We at Muse Research are happy help move our patches from custom one-offs 
to the main fork. Background info below...
> > > The original patches/sources (that i have based my version on, are
> > > found here: http://www.museresearch.com/support/receptor-faq.php
> > >
> > > ...at the bottom of the page / last link:
> > > http://www.museresearch.com/support/receptor-faq.php
> >
> > I looked over them briefly.
> > 0005-Expand-dos-has-entropy-in-order-to-make-collision-le.patch
> >          Not sure why this is needed?
>
> I'm not sure why either, but i am guessing it improves things in a
> linux-rt/VST setting (in fact, removing it causes regressions on my
> L_pa systems - so i am keeping it.

This is a really old patch. IIRC there were different long filenames 
that were being converted to the same 8.3 filename. I don't have more 
details.
> > 0010-If-a-child-of-the-window-being-disabled-is-the-captu.patch
> >          a user32.EnableWindow 2008 patch ... is it still needed for you,
> >          as quite some enhancements have happened...
> >
> > Would need review (likely from julliard or other user32 guru)
> >          and testcases.
>
> Seems to be, yeah.

This fixed a problem where FM8's 'save' window would get stuck. Once you 
opened and cancelled it, any mouse click would open it again.
> > 0012-ntdll-Use-pipes-for-synchronization-objects.patch
> > 0050-pipe-check-and-thread-safe-read.patch
> >
> > A new synchronization method using UNIX pipe(2)s.
> >          This is definitely not going in as is...
>
> Figured as much :)  (that was pretty obvious lol.)
> > It would be interesting to know what deficit in regular Wine is
> >          fixed by it. wineserver overhead?
>
> Yeah, Wineserver is probably the number one thing that slows down
> when, when you are looking for low-latency / high-performance. (ext4
> is also terrible on stock settings).

This removes key synchronization calls from the wineserver and keeps 
them on the app side. Without it realtime performance is impossible. We 
developed this with Codeweavers, and they were pretty sure it wasn't 
general enough for the main fork.
> > 0023-improve-IoRegisterDeviceInterface.patch
> >
> > Remove the MUSE specific fixmes and use the same FIXME() style
> >          for stub parameters as in the other FIXME()s. Then
> >          its ready for wine-patches I would say.
>
> Awesome :) I must have missed that ~ you will notice that i removed
> them from the new variables used by L_ (didn't want any
> hassles/trademark issues with Muse).

Don't worry, no problem with us! This was helpful in getting Pace CDRM 
ilok support to work.
> > 0025-Add-stub-for-IoSetDeviceInterfaceState.patch
> >          Use same FIXME() style as used for other stub functions, then
> >          ready for submission.
>
> Great.
> > 0027-Add-stub-for-PoSetPowerState.patch
> >          Good for submission as-is.
>
> Great. :)

Ditto from 0023.
> > 0033-overridable-default-filesystem-type.patch
> >          Not submittable as-is ...
> >          It would be good to know the reason and/or what MUSE expects.
>
> You can contact them. They don't seem to get the idea of FOSS - by
> having our help, they could have _Less_ of a delta they are keeping.
> But as far as this patch is concerned, i am not sure. (this is why i
> got in touch with you guys).

This is internal and not generally useful.
> > 0044-get-windows-label-from-registry.patch
> >          Smells like the wrong place to do it. Perhaps mountmgr.sys,
> >          but perhaps different.
> >          Also unclear if Alexandre likes it.
>
> I think for their purposes it probably is though, so i have kept it as
> well (for now, unless told that i shouldn't for good reason).

This one is internal too.
> > 0052-NI-drag-and-drop.patch
> >          Looks already good for submission to me.
>
> Yeah, it fixes BIG hassles for N.I users like myself.

Cool.
> > 0054-set-realtime-priority-without-wineserver.patch
> > wine-rt-101107.patch
> >          Needs design and discussion... So far a RT solution
> >          was not accepted for Wine yet.
>
> Yeah - that is in fact, one of the most important patches for us
> (linuxaudio folks). The FSThost developer (wraps wineVSTs, single
> hosted) said it is the 'holy grail' for fixing his software to
> properly handle windows VSTs and it does so very well :)  ~ windows
> VSTs are highly performant, synchronized and run like normal
> Jack_cleints without wineserver getting in the way.

Same as above, moving sync calls out of the wineserver is the only way 
to use Wine for realtime audio applications. Especially with more 
complicated plugins like Kontakt.
> > 0061-fix-broken-cross-compiled-winegcc.patch

This fixed a compiler problem when cross compiling a 32bit winelib 
application on a 64bit system. The messages were:
> /usr/include/wine/windows/rpcndr.h:176:16: error: ‘_MIDL_STUB_MESSAGE’ has a
> field ‘_MIDL_STUB_MESSAGE::SavedContextHandles’ whose type uses the anonymous
> namespace [-Werror]
> /usr/include/wine/windows/rpcndr.h:479:16: error: ‘_SCONTEXT_QUEUE’ has a field
> ‘_SCONTEXT_QUEUE::ArrayOfObjects’ whose type uses the anonymous namespace
> [-Werror]
> > 0063-disable-winedbg-auto-crash-dialog.patch
> >          local hacks

Yep. One-offs for us.
> k.
> > 0062-disable-crashing-alpha-bitmaps-for-gdb.patch
> >          Seems like a mistaken patch that was needed as we had
> >          the old DIB sections.
> >
> > gdb would have accepted "continue" here.
> >
> > Should not be necessary anymore these days with the
> >          DIBENGINE.
>
> Okay, i will try reverting it locally and make sure everything is good.

Yes to all of that. I just hated having to hit CONTINUE all the time. 
And, right, my understanding is that the DIBENGINE no longer uses the 
same tricks with memory that it used to.
> > add-implementation-setProcessWorkingSetSize.patch
> >          Might be submittable as-is.
> >
> > Might need autoconf checks for non-Linux.
>
> good. but i am not the guy to do this ~ i have a _ton_ of work right
> now, both professionally and for my own projects. I just wanted to
> make sure anything that _should_ be in wine goes into Wine to improve
> the experience for everyone.

Ditto that on the "busy" thing. ;)
> > Fix-disk-geometry-ioctl.patch
> >          Alexandre usually does not like override files
> >          like this unless necessary.
> >
> > What is actually expected? you mentioned rendering issues?
>
> I am not sure about this one. it needs investigating but i have it
> applied.  As far as rendering issues, yes upstream wine causes ugly

The drive geometry from a disk wasn't being reported correctly or 
consistently. It caused problems with SampleTank from IK Multimedia.
> flickering in some apps/VSTs, while L_pa-Wine does not (at all, ever).
> > fix-obscured-windows.patch
> >          Hmm, needs user32 windowing guru review.
>
> probably.

The 'prefs' menu from SampleTank wasn't opening with Metacity.

Old bugzilla notes say "It comes down to the WS_DLGFRAME|WS_THICKFRAME 
flags. If they are both present then the window is not visible. Turn on 
or the other off in the example and the window shows up.

The second window must have a parent and have the WS_OVERLAPPED style as 
well."

Hope that helps.

-- Michael Ost
Muse Research and Development

Patchsets that need review by experienced Wine Developers

[jordan]

> We at Muse Research are happy help move our patches from custom one-offs to
> the main fork. Background info below...
> -- Michael Ost
> Muse Research and Development

Hi Michael, I recognize your name from years ago on various
(linux-related) lists.

I hope you don't mind that i took the initiative here. :) This
benefits us all ~ less of a delta for you, less for me and improved
Wine support for everybody ~ it's a win win situation. In reality, the
strength of your product line is not secret sauce to wine, when you
really think about it... the benefit is the amazing software + H/W
that you guys have designed.  ~ i've used them, but can't _justify_
the expense, at this point ~ although i would love a Receptor :) (and
_would_ own one if i was a touring professional, since it is simply
the best option available)

Anyway, Michael - i hope you didn't take any of this as 'stepping on
your toes'. I also hope it isn't a problem that within my project;
L_ProAudio that i have _renamed_ all of the MUSE stuff ~ being as that
is your trademark.

also, if you are interested later down the line (once, the project is
slightly more mature), we could share some tips on taming linux-rt,
but that is entirely upto you guys.

lastly, thank you very much for publishing your GPL'd code. It fixes a
lot of hassles for me.

cheerz

Jordan

Patchsets that need review by experienced Wine Developers

[Louis Gorenfeld]

Hi!
  I'm really happy that some of our patches are making it into WINE! If I could chime in...
> > > 0005-Expand-dos-has-entropy-in-order-to-make-collision-le.patch
> > >         Not sure why this is needed?
> >
> > I'm not sure why either, but i am guessing it improves things in a
> > linux-rt/VST setting (in fact, removing it causes regressions on my
> > L_pa systems - so i am keeping it.
>
> This is a really old patch. IIRC there were different long filenames that were being converted to the same 8.3 filename. I don't have more details.

That was because of a name collision that'd happen when running the installer for NI's Akoustik Piano plugin. It creates hundreds (or thousands?) of files with similar names in one directory, and the installer would name the file one thing but in the file would be another file's contents. IIRC, it was a pretty unusual case.
> > > 0012-ntdll-Use-pipes-for-synchronization-objects.patch
> > > 0050-pipe-check-and-thread-safe-read.patch
> > >
> > > A new synchronization method using UNIX pipe(2)s.
> > >         This is definitely not going in as is...
> >
> > Figured as much :)  (that was pretty obvious lol.)
> > > It would be interesting to know what deficit in regular Wine is
> > >         fixed by it. wineserver overhead?
> >
> > Yeah, Wineserver is probably the number one thing that slows down
> > when, when you are looking for low-latency / high-performance. (ext4
> > is also terrible on stock settings).
>
> This removes key synchronization calls from the wineserver and keeps them on the app side. Without it realtime performance is impossible. We developed this with Codeweavers, and they were pretty sure it wasn't general enough for the main fork.

This might also end up being generally useful for programs that are realtime and make a lot of wineserver calls. I believe the mutexes were taking too long to access because they were going through wineserver, which was already handling a lot of other calls in serial. Basically, it was a traffic jam. That's my understanding and recollection, at least (I wasn't the original author of the patch but I did do some work on it later).

Louis Gorenfeld
Muse Research

Patchsets that need review by experienced Wine Developers

[André Hentschel]

On 04.01.2013 22:33, Louis Gorenfeld wrote:
> Hi!
>   I'm really happy that some of our patches are making it into WINE! If I could chime in...
> > > > 0005-Expand-dos-has-entropy-in-order-to-make-collision-le.patch
> > > >         Not sure why this is needed?
> > >
> > > I'm not sure why either, but i am guessing it improves things in a
> > > linux-rt/VST setting (in fact, removing it causes regressions on my
> > > L_pa systems - so i am keeping it.
> >
> > This is a really old patch. IIRC there were different long filenames that were being converted to the same 8.3 filename. I don't have more details.
>
> That was because of a name collision that'd happen when running the installer for NI's Akoustik Piano plugin. It creates hundreds (or thousands?) of files with similar names in one directory, and the installer would name the file one thing but in the file would be another file's contents. IIRC, it was a pretty unusual case.

We should decide soon if we want to accept that patch, because it breaks DOSBox compatiblity. So in case we commit it we should change it in dosbox before they release 0.75
AJ?

Patchsets that need review by experienced Wine Developers

[Alexandre Julliard]

André Hentschel <nerv(a)dawncrow.de> writes:
> We should decide soon if we want to accept that patch, because it
> breaks DOSBox compatiblity. So in case we commit it we should change
> it in dosbox before they release 0.75
> AJ?

No, that would also break compatibility with existing prefixes.

-- 
Alexandre Julliard
julliard(a)winehq.org

Patchsets that need review by experienced Wine Developers

[jordan]

> This might also end up being generally useful for programs that are realtime and make a lot of wineserver calls. I believe > the mutexes were taking too long to access because they were going through wineserver, which was already handling a > lot of other calls in serial. Basically, it was a traffic jam. That's my understanding and recollection, at least (I wasn't the > > original author of the patch but I did do some work on it later).

+1

That matches my experiences, as well, Louis.

ext4 likes to jam up things to, so ideally if these problems are going
to be solved upstream ~ wine-devs also will likely want to look at
problems with ext4 (possibly, btrfs down the line ~ since i think i
remember noticing a kernel hack for btrfs(?).

anyway, that is another issue all together.

Jordan