June 2015 - Wine-Devel - list.winehq.org

Re: include: Convert vfw.h to vfw.idl.

by Nikolay Sivov

Hi, I see it went to pending, so let me suggest something. We need this idl mostly for automated proxy/stub generation and registration, right? Maybe we could introduce an idl that contains interfaces only and not all regular header stuff that vfw.h is made of. I would probably work to duplicate interfaces locally at dll level, and leave header alone.

June 7, 2015

Re: Wineconf: workshop(s)?

by Michael Stefaniuc

On 06/07/2015 04:20 AM, Marcus Meissner wrote: > I am wondering if it makes sense to hold a workshop / hack session > and how to. > > As we seem to be accustomed to working as single developers this is a bit hard, > also "making good use of available time" is a factor. > > > Do we have scenarios where some hours of short term working together would benefit us? > > - We had regression triaging some years ago which was working okish I think, but > might not have been the best use of time. > > - We also had a "make all tests green on my laptop" shared activity, > which was also a bit useful. Well, Jeremy has his usual "Wine Tests Hackathon" on the agenda. There is also a proposal to hack on upstreaming some of the patches in Wine Staging. > - Bug triaging is not really a team activity, although if its necessary we could > just force everyone present to do it for some hours. > > - other things? bye michael

June 7, 2015

Wineconf: workshop(s)?

by Marcus Meissner

Hi, I am wondering if it makes sense to hold a workshop / hack session and how to. As we seem to be accustomed to working as single developers this is a bit hard, also "making good use of available time" is a factor. Do we have scenarios where some hours of short term working together would benefit us? - We had regression triaging some years ago which was working okish I think, but might not have been the best use of time. - We also had a "make all tests green on my laptop" shared activity, which was also a bit useful. - Bug triaging is not really a team activity, although if its necessary we could just force everyone present to do it for some hours. - other things? Ciao, Marcus

June 7, 2015

Wineconf talk proposal: Wine and Valgrind

by Austin English

Howdy all, If anyone is interested, I can give a presentation on Wine/Valgrind, i.e. current status, major outstanding issues on either side, issues found/fixed, etc. Please let me know if you'd be interested. -Austin

June 7, 2015

Re: kernel32: Fail properly for unsupported classes in GetFileInformationByHandleEx

by Marvin

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 https://testbot.winehq.org/JobDetails.pl?Key=13968 Your paranoid android. === wvistau64 (32 bit file) === file.c:444: Test failed: attributes of file "testfile.xxx" are 0x0820 === wvistau64 (64 bit file) === file.c:444: Test failed: attributes of file "testfile.xxx" are 0x0820

June 7, 2015

Re: wine CPU usage and CreateWaitableTimer

by andrea

On 01/06/15 20:43, andrea wrote: > Hi, > > I'm trying to understand why AppleWin uses 100% CPU when running in wine vs ~1% in Windows. > > my case is wine 1.7.43 vs Windows 7 > > https://appdb.winehq.org/objectManager.php?sClass=version&iId=29403 > https://bugs.winehq.org/show_bug.cgi?id=34945 > > basically 97% time is spent in a WaitForSingleObject on a semaphore signalled by a DirectSound > IReferenceClock via AdvisePeriodic. > The timer period is set to 1 millisecond. > > I have tried an other Windows call to create the timer: CreateWaitableTimer > The latter uses about 50% CPU, so it is much better, but still not very good. > > This is true even on a simple app that does nothing other than waiting for this timer all the time. > > Does anybody know > > 1) is this normal? should these waits be almost free like they are in Windows? > 2) what is the best implemented timer in wine that can be used for a periodic event (~1ms)? > > Thanks > > > > I've tried 4 different function to create a period timer http://pastebin.com/wt4iTL78 you can compiler it as // winegcc -g timers.cpp -lwinmm -lole32 -lstrmiids and then run it as ./a.out X Y where X is the period of wait in ms, and Y the method it will wait till 10 seconds and print some statistics (you can use "time" to time it) 1 - CreateWaitableTimer 2 - IReferenceClock->AdvisePeriodic 3 - CreateTimerQueueTimer 4 - timeSetEvent if the wait is 1 ms each time I get the following system times (out of ~10 sec of execution, compute with "time") 1 - 0.33s 2 - 4.05s 3 - 0.57s 4 - 0.54s if I wait every 5 ms I get 1 - 0.15s 2 - 3.95s 3 - 0.28s 4 - 0.20s It feels like option 2 (IReferenceClock) is implemented as a sort of spin lock, its system time does not decrease with longer waits. What do you think? Andrea

June 6, 2015

Re: Migrating away from Sourceforge

by Jeremy Newman

Who created this Git mirror? I'd be fine using it, but I'd want to be made an administrator of it so I could handle any issues with it. On 06/04/2015 11:57 PM, Michael Cronenworth wrote: > On 06/04/2015 11:55 PM, Michael Cronenworth wrote: >> >> There is always the github route. All the cool kids are doing it these >> days. >> >> They don't have any expressed bandwidth or disk space limits on open >> source software repos. It would be completely free. > > It looks like this is already setup? > > https://github.com/wine-mirror/wine > > Any release tarballs are handled via: > > https://github.com/wine-mirror/wine/archive/wine-1.7.44.tar.gz > > >

June 5, 2015

Re: Migrating away from Sourceforge

by Vincent Povirk

> Note, though, while there are not explicit bandwidth caps, their terms > of service does say: > >> If your bandwidth usage significantly exceeds the average bandwidth usage (as determined solely by GitHub) of other GitHub customers, we reserve the right to immediately disable your account or throttle your file hosting until you can reduce your bandwidth consumption. My impression is that GitHub would much rather we ask permission than forgiveness. Make sure they know what kind of bandwidth we expect to use and are OK with this.

June 5, 2015

Re: inetcpl: implement default page button (try 2)

by Andrew Eikum

Wine doesn't use the L string prefix, because unfortunately some compilers don't support it. Your previous patch has been marked Pending: <http://source.winehq.org/patches/>. I'd wait for another commit release cycle on Monday to see if that changes. Andrew On Fri, Jun 05, 2015 at 12:59:17PM -0500, Jared Smudde wrote: > This patch implements the button default page to set back the default homepage is the user changes the homepage. > --- >

June 5, 2015

Re: [wine-tools] patches: Add a "Staging" status.

by Erich E. Hoover

On Fri, Jun 5, 2015 at 10:35 AM, Austin English <austinenglish(a)gmail.com> wrote: > ... > I'm not sure we want to encourage wine-stating from Upstream (I'm not > convinced either way), but in any case, the grammar seems wrong to me > as a native speaker, how about: > "The patch needs more work or wider testing. Please try to get into > Wine-Staging." > > or something similar? I would say "The patch needs more work or wider testing. Please try submitting the patch to Wine-Staging." A link to "https://github.com/wine-compholio/wine-staging/wiki/Development" might be good too. Best, Erich

June 5, 2015