July 2012 - Wine-Devel - list.winehq.org

Re: winebuild port to ARM?

by André Hentschel

Am 18.04.2012 00:16, schrieb André Hentschel: > Am 17.04.2012 03:09, schrieb Roger Cruz: >> Hi Andre, >> >> I am willing to help as much as my knowledge allows me to port this. The last time I wrote anything in ARM was about 15+ years ago so my knowledge of it is rather limited. I'm also trying to understand what every line of the assembly code is doing in x86. If someone with more knowledge were willing to port this file for us, it would be a great start :-) but failing that, I can fold up my sleeves and take a crack at it. > > First: Please bottom post on this list. > I doubt someone else will port it anytime soon, so maybe you start trying it and i try to help you as much as i can or you wait until i get time to do it myself. It seems we were misreading the source. winebuilds relay.c has nothing to do with relay tracing. the code is in ntdlls relay.c and in winebuilds spec32.c in function output_relay_debug. I'm working on it as it's much easier than what i've seen in the wrong file :) Expect a patch quite soon. -- Best Regards, André Hentschel

July 6, 2012

Re: Building Wine on amd64 FreeBSD?

by Tijl Coosemans

On 05-07-2012 23:37, Hilko Bengen wrote: > Following Marcus Meissner's advice how to build a WoW64 setup (thanks!), > I have succeeded in building a set of co-installable i386/amd64 Debian > packages. Those won't make it into the "wheezy" release as I was just a > bit late for the freeze, but I have uploaded packages to experimental. > > What didn't work was building the 64-bits of wine on > Debian/kfreebsd-amd64 (Debian userland including GNU libc on a FreeBSD > kernel): <https://buildd.debian.org/status/fetch.php%3Fpkg%3Dwine%26arch%3Dkfreebsd-a…> > > Apparently the reason is that the uc_mcontext structure does not store > the DS, ES, FS, and GS registers. After I made the changes below, > everything compiled, but how useful is the result? Are those registers > contained in uc_mcontext on "plain" FreeBSD? They were added in FreeBSD 8: http://svnweb.freebsd.org/base/head/sys/amd64/include/ucontext.h

July 6, 2012

Building Wine on amd64 FreeBSD?

by Hilko Bengen

Following Marcus Meissner's advice how to build a WoW64 setup (thanks!), I have succeeded in building a set of co-installable i386/amd64 Debian packages. Those won't make it into the "wheezy" release as I was just a bit late for the freeze, but I have uploaded packages to experimental. What didn't work was building the 64-bits of wine on Debian/kfreebsd-amd64 (Debian userland including GNU libc on a FreeBSD kernel): <https://buildd.debian.org/status/fetch.php%3Fpkg%3Dwine%26arch%3Dkfreebsd-a…> Apparently the reason is that the uc_mcontext structure does not store the DS, ES, FS, and GS registers. After I made the changes below, everything compiled, but how useful is the result? Are those registers contained in uc_mcontext on "plain" FreeBSD? Cheers, -Hilko

July 5, 2012

Re: [PATCH 1/8] hhctrl.ocx: Implement HH_CLOSE_ALL.

by Erich E. Hoover

On Thu, Jul 5, 2012 at 3:09 AM, Jacek Caban <jacek(a)codeweavers.com> wrote: > ... > While it's not about this particular patch, I can see that you're > changing hhctrl.ocx to the point where it has an useful API (as opposed > to simple hh.exe-like help viewer). It is really nice to see, thanks. It > would be great to have some tests for this. Please consider adding them > (I'm sure you already have some code for testing, so I imagine it would > be mostly integrating it with Wine test suite). Once the get/set HH_WINTYPE commands are in then the only thing that remains in order to construct tests is the ability to build CHM files. I've been working on trying to get HTML Help Workshop to be able to compile CHM files, but so far this endeavor has not met with much success. Did you see anything in these patches that you would like changed? I just noticed a double-free mistake, so I'm going to resubmit with that fixed when I get a chance and can include any suggestions you might have. Erich

July 5, 2012

Re: include: fix mingw64 build

by Austin English

On Wed, Jul 4, 2012 at 8:13 AM, Jacek Caban <jacek(a)codeweavers.com> wrote: > On 07/03/12 20:10, Jacek Caban wrote: >> On 06/29/12 03:35, Austin English wrote: >>> On Thu, Jun 28, 2012 at 6:30 PM, Nicolas Le Cam <niko.lecam(a)gmail.com> wrote: >>>> 2012/6/29 Austin English <austinenglish(a)gmail.com>: >>>>> Fixes http://bugs.winehq.org/show_bug.cgi?id=30980 >>>>> >>>>> -- >>>>> -Austin >>>>> >>>>> >>>>> >>>> Hi Austin, >>>> >>>> I already tried to fix it on Wine side, see [1], >>>> but Alexandre told me on IRC that the bug needs to be fixed in mingw-w64, >>>> as it shouldn't include crtdefs.h by default. >>>> >>>> BTW, won't that break mingw32 build ? >>>> >>>> [1] http://source.winehq.org/patches/data/84070 >>>> >>>> -- >>>> Nicolas Le Cam >>> Thanks for the info. Have you or anyone else discussed this with >>> mingw64? I did a quick search on their bugtracker, but don't see >>> anything.. >>> http://sourceforge.net/search/?group_artifact_id=983354&type_of_search=arti… >> FWIW, here is my proposed patch to mingw-w64: >> >> http://repo.or.cz/w/mingw-w64/jacek.git/commitdiff/5db96424c7b9ac4aa5a66bd0… >> >> We will see if they like it. > > The (extended) fix is in mingw-w64 SVN now. > > Jacek > > Nice! Thanks. -- -Austin

July 5, 2012

Re: kernel32: add a stub for WerSetFlags

by Dmitry Timoshkov

Austin English <austinenglish(a)gmail.com> wrote: > +HRESULT WINAPI WerSetFlags(DWORD flags) > +{ > + FIXME("(%d) stub!\n", flags); > + return E_NOTIMPL; > +} 1. 'flags' is unsigned 2. if it's supposed to be bit flags then printing it in decimal is not helpful. -- Dmitry.

July 5, 2012

Re: [PATCH 1/8] hhctrl.ocx: Implement HH_CLOSE_ALL.

by Jacek Caban

Hi Erich, On 07/04/12 20:32, Erich E. Hoover wrote: > This series of patches is intended to fix the problems with HTML Help > associated with Bug #11303 (HtmlHelp causes problems in Elster). This > patch implements some of the framework required by the other patches > through implementing the HH_CLOSE_ALL functionality needed by the > application to safely shutdown the HTML Help windows on exit. The > framework provided in this patch is the ability to register specific > HTML Help windows (needed later to set and get window properties on > the fly). While it's not about this particular patch, I can see that you're changing hhctrl.ocx to the point where it has an useful API (as opposed to simple hh.exe-like help viewer). It is really nice to see, thanks. It would be great to have some tests for this. Please consider adding them (I'm sure you already have some code for testing, so I imagine it would be mostly integrating it with Wine test suite). Thanks, Jacek

July 5, 2012

"winetricks dotnet40" fails verifier because System.EnterpriseServices.Wrapper.dll missing?

by Dan Kegel

With current git, when I try rm -rf .wine sh winetricks -q dotnet40 sh winetricks -q dotnet_verifier wine netfx_setupverifier.exe the verifier reports failure: ... [07/04/12,21:45:13] ****ERROR**** File C:\windows\Microsoft.NET\assembly\GAC_32\System.EnterpriseServices\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.EnterpriseServices.Wrapper.dll is not installed on the system ... [07/04/12,21:45:15] ****ERROR**** Verification failed for product .NET Framework 4 Client That file does seem to be on disc, but somewhere else: c:/windows/Microsoft.NET/Framework/v4.0.30319/System.EnterpriseServices.Wra… Not sure how serious it is that that's misplaced. Have other folks seen this? - Dan

July 5, 2012

Policy for the Wiki?

by Kyle Auble

Hello all, I've been working on the wiki recently and noticed that a lot of out-of-date or redundant information is retained. For example, completed tasks on to-do lists are checked off and never removed. Isthere an unofficial policy of not deleting info, even if it may exist elsewhere (in the git repo history, wikipage revision history, etc)? Other instances might be stubs dedicated to features in development years ago, or pages on bugs that have already been fixed or triaged in Bugzilla.I know even page deletions can still be reverted, but I wanted to check first before cleaning things out more aggressively. If there are a few unwritten rules everyone likes the wiki to follow, I could add them somewhere as editing guidelines. While the topic's up, I was also wondering how moinmoin was chosen as the wiki engine. I couldn't really find a discussion on the mailing lists so I figured it was the best option when the wiki was first started. I can appreciate that it doesn't require a database and it's written in python instead of php. Allowing only inline CSS in tables causes some headaches, but mainly it can be really slow sometimes, especially when editing, and unless using wikilinks or going directly to a page, navigation is tricky. Has the possibility of migrating the wiki to a different engine ever come up? Or does the Wine wiki code just need some tweaking and maybe some tools? To be honest, I don't know if there is a better alternative (MediaWiki is designed for a very different use case and has really messy code). It just seems like something is discouraging even basic upkeep on the wiki, which kind of defeats its whole purpose. -Kyle

July 4, 2012

Re: [PATCH] winepulse.drv: Add PulseAudio driver

by Maarten Lankhorst

Hey Joerg, 2012/6/26 <Joerg-Cyril.Hoehle(a)t-systems.com>: > Hi, > >>If you don't paste all the mmdevapi tests with the fix in my git tree, it's a >>regression. I don't want to see held_Frames because it's a shadow buffer. >>If winmm and dsound don't work without it, they're wrong, fix those. > > I won't comment on the two individual pulseaudio drivers. Unfortunately, none > of the two authors bothered to point me to a verbose log of the mmdevapi > tests for my scrutiny. > > The tests should pass like they do on native. > > Regarding latency, I'm not aware of a flaw in Wine's winmm. > HOWEVER, Wine's DSound needs a patch. Here the reason. > > To recap, latency is somehow related to the "distance" between what > one hears and the PCM frames sent to the device. GetPosition is the > only API call in that area in both winmm and mmdevapi. > > Buffer size is a completely different thing. I find it useful to have > in mind a cascade of audio filters performing some buffering each. > Then it's obvious that an app only sees the frontmost buffer size and > knows nothing about the others. High latencies imply that there > must be some large buffer space(s), somewhere. > > Period is an artificial entity related to how often the frontmost > buffer is drained to feed the next buffer in the chain, in case that > happens regularly. This is not guaranteed nor necessarily documented. > > You get the idea: regardless of arbitrary (front) buffer sizes and > periods not worth this name, try and send a stable flow of data to > play music without glitches and let explosions be heard ASAP. > > So far the situation, now the issue. It appears easier to write code > that provides (frontmost) buffer space behaviour similar to native than > one that provides similar latency. > > Alas, behaviour observable on MS-Windows differs from what we get with > PulseAudio and some ALSA devices. > > Tests seem to indicate a latency of around 30-70ms from mmdevapi with > MS-Windows. That good enough for games. OTOH if ALSA or PA gives us > 2 seconds on Linux, that's a big cause of trouble. The authors of MS > apps could never test them in an environment with such high latency. > What happens with software not tested? It happens not to work. > > Two solutions: > - Reduce actual latency or > - lie about latency. > > Lying about latency causes apps to loose the ability to sync audio and > video. However, given a choice between loss of lip sync and possible > crashes or other weird behaviour because an app is executed in a > environment that its developers never experienced, I consider the loss > of lip sync to be less worrying. > > We designed the winealsa driver to accomodate an arbitrary latency and > accept a large variation of periods. (Some bug report from Jack users > seem to imply that it should accept even larger periods, e.g. 150ms, > yet still pretend to use 10ms on the mmdevapi side). > > We choose to have the winealsa driver not lie about latency. That > should be left to high level APIs. > > DirectSound is built around the "Direct" HW (lack of) abstraction: a > circular buffer of samples is played by a DAC. The converted signal > is immediately sent to the speaker. Hence: > > 1. GetPosition information in the DSound abstraction translates to > a "playpos" -- well known. > > 2. No provision is made for additional buffering. The playpos must > lie within the circular buffer. The reported free (writable) space > shall never cross the playpos -- with subtle consequences. > > Wine's DSound needs a patch to ensure this second property. Given a > 80ms primary buffer, Wine's DSound must not pretend its playpos is 2 > seconds late! > > I think Wine should try and reduce latency but lie if that does not suffice. > > What's needed? > 1. Have DSound always use a buffer large enough for typical situations > (I believe 100-200ms). > > 2. Clamp the reported position such that it won't leave the (virtual) > primary buffer. As a result, DSound must pretend to play even when > Wine is solely pumping the huge 2s of cascading SW audio buffers. > > 3. Work on reducing the latency of the cascading audio filters. > That device-level work is independent on the DSound one. > > Native's 30-70ms has the benefit that it nicely fits within typical > DSound primary buffer sizes. PulseAudio's 2s does not (yet). > I believe a total 80ms latency would be acceptable with games. > > > Further areas of investigation and effort: > > - Maybe clamp latency in the mmdevapi drivers after all? After all, > huge latencies are known to cause dead-locks in apps and we don't > know what all apps or libraries built atop mmdevapi or winmm expect. > (If yes, to what value? 150% buffer size?) > > - Try and find MS setups with huge latencies. > USB headphones are said to be candidates, but I've yet to see an > excellent and trustworthy report about what happens in that case. > > - Work on reducing the cascades of audio buffers > > - Work on further decoupling mmdevapi periods from UNIX audio API ones > > - Research the trade-off between glitch free playback and buffering in UNIX. > The current settings in Wine's audio are IMHO not good enough yet. Lowering latency is overrated, I can get 8 ms between play position and hardware queue length, you just need to be willing to patch dsound to do that. http://repo.or.cz/w/wine/multimedia.git/shortlog does just that, but there might be a reference leak somewhere in dsound, didn't look yet. With events triggered by winepulse it seems to work and 20 ms buffer + 10ms periods works fine, but it's not really recommended on plain wine since it lacks the rtkit patch to reduce jitter to close to 0 ms, and winealsa lacks proper event driven mode, it just uses a floating timer based on nothing, so it would never be able to come close to that. However dmix works fine if you only fill 3 periods. It would be trivial to fix winealsa for dmix to do the same but that would probably cause it to fail tests, even though it wouldn't be against the spirit of the tests. Sometimes it's an error to pass tests. :-) ~Maarten

July 4, 2012