wine-devel October 2009

wine-devel@winehq.org

92 participants
261 discussions

Start a nNew thread

Re: [PATCH 03/14] mciwave: Do not lie about state when winmm fails in Pause or Resume.
by Christian Gmeiner 19 Oct '09

19 Oct '09

Patch is missing -- Christian Gmeiner, MSc

1 0

PATCH 0/14 mciwave aka. waveaudio patches
by Joerg-Cyril.Hoehle＠t-systems.com 19 Oct '09

19 Oct '09

Hi, Here's a series of patches to fix various bugs and increase compatibility. Alas, it is only yesterday night that I discovered that mciwave will only record samples in multiples of 333 milliseconds (from using 3 buffers / second). Thus in my testsuite, the comparisons against 2000ms give flaky results (sometimes 2333ms). However I don't want to delay the inclusion of the large testuite into Wine any further. I prefer 3 flaky test results than almost no test at all. Possibly the change of results between 2000 and 2333 is influenced by using MulDiv in patch 0007. More in the pipe: - notification fixes Yet to investigate: - safe concurrent operation, elimination of hangs etc. See bug 20232 - cause of samples sizes as multiples of 333ms only. Regards, Jörg Höhle

1 0

Re: [PATCH 1/4] comctl32/tooltips: Fix an obviously wrong structure size check (try2)
by Paul Vriens 19 Oct '09

19 Oct '09

On 10/15/2009 12:59 PM, Nikolay Sivov wrote: > Changelog: > - try2: fixed usage of W calls in tests, fixed some typos > - fix an obviously wrong structure size check > Hi Nikolay, I have been checking the failures for these tests. At first I just wanted to add some broken() statements. Looking at test.winehq.org I can see that the test failure output is different sometimes. Changing the following for every call: ti.cbSize = TTTOOLINFO[AW]_V2_SIZE - sizeof(void*); make the output consistent (still different from comctl32 > 5.81). What would be the best way to fix these tests? Add a define for the size of the struct that differs between "_WIN32_WINNT >= 0x0501" and the earlier versions and then have a second possible result (or broken())? Another thing is that this test doesn't have any ok()'s, what was the intention here?: 457 ti.cbSize = TTTOOLINFOA_V2_SIZE; 458 ti.uId = 0x1234ABCD; 459 ti.lParam = 0xaaaaaaaa; 460 r = SendMessageA(hwnd, TTM_SETTOOLINFOA, 0, (LPARAM)&ti); -- Cheers, Paul.

2 1

Re: Patch for bug 20227: msi: Table Join on two tables that have same (non-join) column name...
by Hans Leidekker 19 Oct '09

19 Oct '09

Hi Nate, Your patch applies with offsets, please rebase to current git. And get rid of this warning: db.c: In function ‘test_where_not_in_selected’: db.c:1576: warning: unused variable ‘count’ > + query = /*"Select IESTable.Action, IESTable.Condition from CATable, IESTable where "*/ > + "Select IESTable.Condition from CATable, IESTable where " > + //"CATable.Action = IESTable.Action and (CATable.Type = 51 or CATable.Type = 32) " > + "CATable.Action = IESTable.Action and CATable.Type = 32 " > + /*"order by IESTable.Sequence"*/; Please remove the commented strings. > static UINT ALTER_get_column_info( struct tagMSIVIEW *view, > - UINT n, LPWSTR *name, UINT *type, BOOL *temporary ) > + UINT n, LPWSTR *name, UINT *type, BOOL *temporary, > + LPWSTR *tableName) 'table_name' or just 'table' would be more in keeping with the existing style. > + printf("Returned entry: %s\n", buf); trace() is usually used for debug printing but you might want to turn this into a test instead, or just leave it out. And you should split off the tests to keep the patch size down. -Hans

2 2

acmMetrics(0,ACM_METRIC_MAX_SIZE_FORMAT,&size)
by Markus Stockhausen 19 Oct '09

19 Oct '09

Hi, maybe someone with deeper ACM knowledge can help me out. If I understand the above call correctly it should give the size of the largest WAVEFORMATEX structure of any driver. This should be more or less the maximum number of each second DWORD in the registry in the key Software \Microsoft\AudioCompressionManager\DriverCache\<driver name>\aFormatTagCache. In my Wine environment this gives me 50 because of driver msacm.msadpcm ( ... 0x32 0x00 0x00 0x00 ...). According to the bug I'm currently inspecting I have the feeling that in a Windows installation (even without additional acm drivers) this value could be larger than registry may tell. For that reason I ask if someone could run the attached testcase in an native environment and could tell me if he can see a difference between the result and the registry. Thanks in advance. Markus --- a/dlls/msacm32/tests/msacm.c +++ b/dlls/msacm32/tests/msacm.c @@ -485,6 +485,9 @@ static void msacm_tests(void) if (winetest_interactive) trace("enabled drivers:\n"); + rc = acmMetrics(0, ACM_METRIC_MAX_SIZE_FORMAT, &dwCount); + ok(1==0, "ACM_METRIC_MAX_SIZE_FORMAT=%u\n",dwCount); + rc = acmDriverEnum(DriverEnumProc, 0, 0); ok(rc == MMSYSERR_NOERROR, "acmDriverEnum() failed, rc=%08x, should be 0x%08x\n",

1 0

Have a feeling that the alsa cheese has been moved
by Susan Cragin 18 Oct '09

18 Oct '09

After using alsa very happily for several days or weeks, it no longer works for me. Changes I have noticed between the daily builds of 10/1 and 10/13 indicate that Ubuntu is working on alsa, and making changes. In the past, with my program, here's what happened. When sound didn't work, winecfg usually showed wave-in as "default." When it did, it showed as "dsnoop:0." Well, for a few days daily builds had been hell and sound didn't work at all. Then suddenly with today's daily build sound worked great -- once, with the wave-in showing "default." ??? Then the second time I logged in, it showed dsnoop and the message said the sound system wasn't being recognized.

1 0

Re: [1/1]oleaut32: Fix Testcases on NT4 and lower
by Nikolay Sivov 18 Oct '09

18 Oct '09

Wilfried Pasquazzo wrote: > A fix for my testcases of IPicture_Render method. > > affected files: oleaut32/tests/olepicture.c > > On older OS than Win2000 the testcase produces different results. > The method IPicture_Render isn't officially supported on those old OS, > therefore I just used the broken() statement with the results provided > by wines http://test.winehq.org/data/ to catch all of those errors. > > > Wilfried Pasquazzo > Hi. Maybe it's better to jump over tests basing on ::Render() return value? Or it claims that it succeeded?

2 1

Re: Debugging Xfire: need help
by Stefan Dösinger 18 Oct '09

18 Oct '09

Am 18.10.2009 um 16:24 schrieb Warren Dumortier: > I don't think it's worth to be tested, because if Xfire doesn't > crash (simply by not interacting with it) games are detected. > However i will try it, who knows! ;) An easier way to test is probably to disable Xfire In-Game, if you find out how to do that without using the normal options dialog. Game detection has nothing to do with hooking. Game detection just reads your registry keys, files on disk etc for known games. The hooking comes into action once you start a game. Xfire injects its DLL, hooks some calls, and then displays a message telling that Xfire- In-Game is enabled. That allows you to use Xfire features like the chat, screenshots and movie recording from inside the game, even if the game is running in fullscreen mode, and without tabbing out of the game. The Steam in-game overlay works in the same way. However, Steam only injects its DLL into games started by Steam, while Xfire injects its DLL into every running app, even if it was already running when Xfire was started.

1 0

Debugging Xfire: need help
by Warren Dumortier 18 Oct '09

18 Oct '09

Xfire was working until version 1.104, but since then it crashed on every Wine version, so the Xfire update broke it under Wine. Here's the problem: Xfire crashes every time you interact with it's GUI, well most of the time... When using the keyboard it crashes sometimes, but when using the mouse it crashes every time... I used winedbg to find the possible cause, but i can't figure it out myself, however here is the output: http://pastebin.be/21435 As you can see, it crashes in user32/button.c, because i clicked on a button. However it's the only thing i understand, can anyone help me? I'm really looking forward to get some help as i would really like to get it running. Thanks, kind regards.

2 1

Towards leveraging app build and unit tests as a way to test wine
by Dan Kegel 18 Oct '09

18 Oct '09

Wine is far enough along that it ought to be able to build and run unit test suites from apps like Inkscape, Firefox, and OpenOffice, so I'm trying to write scripts that download and build various apps unattended, and eventually run their own test suites. The scripts are written to run equally well on Windows and Wine. This is hard to do without something like Cygwin or Autohotkey; I'm using Cygwin for my scripts out of personal preference. I already did a build script for Inkscape using mingw; http://kegel.com/wine/inkscape-download-and-build.sh.txt Now I'm tackling Firefox. So far the script installs Visual C++ 2005 Express and the 2003 platform SDK; see http://kegel.com/wine/vc2005x.sh.txt Next step: grabbing firefox source and building. I'm also filing bugs as I go; 19673 Microsoft Platform Installer 2003 fails to install 19668 cmd /c doesn't wait for result before exiting? 19636 Vista SDK installer fails in "Microsoft VC Redist 2008" subinstaller 19615 Can't compile Inkscape with mingw on wine: fd leak? 19581 Visual Studio 2005: "cl : Command line error D8022 : cannot open 'foo.rsp' "; foo.rsp was created with FILE_ATTRIBUTE_TEMPORARY 19502 Visual Studio 2005 SP1 install seems to fail While one doesn't really need to build the apps under Wine to run their test suites, it's a pain to have to compile them on one system and ship them over to another. And supporting building might have a nice benefit: if it's easy to develop for Windows on Wine, more Windows developers might bother to test their apps on Wine. So I think it's worth the extra effort. - Dan

5 16

← Newer
1
...
9
10
11
12
13
14
15
...
27
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel October 2009