January 2013 - Wine-devel - list.winehq.org

Re: Patchsets that need review by experienced Wine Developers
by Michael Ost 05 Jan '13

05 Jan '13

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

5 5

Re: [website] Wine 1.5.21 freigegeben
by Frédéric Delanoy 05 Jan '13

05 Jan '13

On Fri, Jan 4, 2013 at 10:33 PM, André Hentschel <nerv(a)dawncrow.de> wrote: > --- > news/de/2012122101.xml~ | 17 +++++++++++++++++ Not sure checking in your editor backup file is a good idea ;) Frédéric

1 0

Re: [1/4] windowscodecs: Introduce 24bppRGB PixelFormat
by Vincent Povirk 04 Jan '13

04 Jan '13

The series looks good to me. Of course, we can already read 8-bit tiffs just fine, but I guess your app makes use of the 8bpp RGB format. We could probably avoid a double conversion between rgb and bgr when reading an 8-bit tiff as rgb, by implementing and using the IWICBitmapSourceTransform interface, but MSDN seems to claim that the native TIFF decoder doesn't do this.

1 0

Re: [3/4] windowscodecs: Test conversions of the 24bpp PixelFormats
by Marvin 04 Jan '13

04 Jan '13

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=23739 Your paranoid android. === W2K8SE (32 bit converter) === Failure running script in VM: The specified guest user must be logged in interactively to perform this operation

1 0

Patchsets that need review by experienced Wine Developers
by jordan 04 Jan '13

04 Jan '13

Hi, I have been experimenting with some patchsets for Wine -> based on an implementation of Wine originally developed By Muse Research. It has improved support for a bunch of stuff, fixes (most) bottlenecks for Linux proaudio folks making use of Wine + Jack, and also contains some bug fixes for wine (that may or may not be acceptable to wine-devs.) I have a project that now lives on SF.net, but has been running for months now, on my machine(s), locally. It's called L-ProAudio, and the version of wine (L_pa-Wine) is geared towards proaudio users. We also have support in 1 linux application ~ which now properly handles the new method of mapping win/prio -> linux/prio. Some of the patchset fixes synchronization issues (with jack), disk geomtery-io-syscl, fixes rendering bugs in VSTs (probably other apps too) and a bunch of other improvements (geared for proaudio users). L_ProAudio SF.net Page: https://sourceforge.net/projects/l-proaudio/ -> Wine-L_Proaudio_Arch_n_patches.tar.gz contains a pkgbuild for Archlinux (like gentoo' ebuild) + all patches (and probably one or two others, not used in my builds). But please note: this is NOT a fork of Wine. It is necessary for me to be able to run the applications that i want with Wine. I am just carrying patchwork and re-basing it, as time passes. But i decided to release it - since it benefits the larger community who uses this stuff (greatly). note 2: I am posting, in order to shed light on any improvements/bug fixes that _might_ be suitable for upstream. ~ If so, once a given stable release of Wine is issued, I would then be able to remove them from my patchset, minimizing duplicate efforts, among other things. 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 these patches fix Wine problems (in most areas) for people using linux(-rt) + jack + ProAudio ... but may have other benefits/bug-fixes for wine. It's Gpl'd (obviously), so it would be worthwhile to have a look anyway. - didn't include every patch (some of them aren't of interest to me, outdated, etc). Take care Jordan

2 3

Re: windowscodecs: Implement ComponentFactory_CreateBitmapFromMemory. Take 2.
by Vincent Povirk 04 Jan '13

04 Jan '13

This looks good to me (and it's hard for me to stick to my preference for IWICBitmapLock, given how little code is needed here to accomplish the same thing). The remaining todo is an unrelated bug that's my fault, and I'll resend my patch for it if this one is accepted.

1 0

Re: windowscodecs: Implement ComponentFactory_CreateBitmapFromMemory. Take 2.
by Marvin 04 Jan '13

04 Jan '13

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=23734 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: [PATCH] d3dx9_36: Implement ID3DXFileImpl_RegisterTemplates + tests. (resend)
by Marvin 04 Jan '13

04 Jan '13

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=23733 Your paranoid android. === W2K8SE (32 bit xfile) === Failure running script in VM: The specified guest user must be logged in interactively to perform this operation

1 0

Fwd: Re: netstat: Initial implementation (try 2)
by André Hentschel 04 Jan '13

04 Jan '13

-------- Original-Nachricht -------- Betreff: Re: netstat: Initial implementation (try 2) Datum: Sat, 29 Dec 2012 15:39:54 +0100 Von: André Hentschel <nerv(a)dawncrow.de> An: Wine Devel <wine-devel(a)winehq.org> Am 28.12.2012 23:10, schrieb Frédéric Delanoy: > On Thu, Dec 27, 2012 at 7:03 PM, André Hentschel <nerv(a)dawncrow.de> wrote: >> +#define IDS_TCP_UNKNOWN 0 >> +#define IDS_TCP_CLOSED 1 >> +#define IDS_TCP_LISTENING 2 >> +#define IDS_TCP_SYN_SENT 3 >> +#define IDS_TCP_SYN_RCVD 4 >> +#define IDS_TCP_ESTABLISHED 5 >> +#define IDS_TCP_FIN_WAIT1 6 >> +#define IDS_TCP_FIN_WAIT2 7 >> +#define IDS_TCP_CLOSE_WAIT 8 >> +#define IDS_TCP_CLOSING 9 >> +#define IDS_TCP_LAST_ACK 10 >> +#define IDS_TCP_TIME_WAIT 11 >> +#define IDS_TCP_DELETE_TCB 12 >> <...> >> + IDS_TCP_CLOSED, "CLOSED" >> + IDS_TCP_LISTENING, "LISTENING" >> + IDS_TCP_SYN_SENT, "SYN_SENT" >> + IDS_TCP_SYN_RCVD, "SYN_RCVD" >> + IDS_TCP_ESTABLISHED, "ESTABLISHED" >> + IDS_TCP_FIN_WAIT1, "FIN_WAIT1" >> + IDS_TCP_FIN_WAIT2, "FIN_WAIT2" >> + IDS_TCP_CLOSE_WAIT, "CLOSE_WAIT" >> + IDS_TCP_CLOSING, "CLOSING" >> + IDS_TCP_LAST_ACK, "LAST_ACK" >> + IDS_TCP_TIME_WAIT, "TIME_WAIT" >> + IDS_TCP_DELETE_TCB, "DELETE_TCB" > > Are these really supposed to be translated? If not they probably > should be "hardcoded" in a C file. > > Frédéric > In german Windows they are, not sure about the french one. see also http://www.winehq.org/pipermail/wine-devel/2012-December/098259.html -- Best Regards, André Hentschel

3 2

Re: user32: Initialize cbSize of NONCLIENTMETRICSW struct in GetSystemMetrics
by Dmitry Timoshkov 03 Jan '13

03 Jan '13

Jacek Caban <jacek(a)codeweavers.com> wrote: > - NONCLIENTMETRICSW ncm; > + NONCLIENTMETRICSW ncm = {sizeof(ncm)}; ncm.cbSize = sizeof(ncm); would be more explicit IMO. -- Dmitry.

1 0