December 2010 - Wine-Devel - list.winehq.org

Re: [PATCH 2/7] quartz: Add support for filtermapper3 to filtergraph, try 2

by Alexandre Julliard

Maarten Lankhorst <m.b.lankhorst(a)gmail.com> writes: > @@ -177,7 +177,7 @@ typedef struct _IFilterGraphImpl { > > LONG ref; > IUnknown *punkFilterMapper2; > - IFilterMapper2 * pFilterMapper2; > + IFilterMapper3 * pFilterMapper2; You should rename it then. -- Alexandre Julliard julliard(a)winehq.org

Dec. 6, 2010

Re: [PATCH 1/4] wineaddon.cpl: Added initial Wine Add-ons Manager stub.

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> writes: > The following series of patches is a first step towards Wine Add-ons > tool. These patches move Gecko installation to wineaddon.cpl. They do > nothing about making install code generic nor provide any new GUI yet. > They only place the code in the right place so that it can be improved > further. Is a separate control panel really the right place? It seems to me that it would be preferable if add-ons were treated more like normal packages, and in particular registered in the installed packages list. This would make it possible to manage them from the appwiz control panel, and from other tools that use install information like uninstaller. -- Alexandre Julliard julliard(a)winehq.org

Dec. 6, 2010

Re: [PATCH 01/11] mshtml: Added IOleControl calls test.

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 http://testbot.winehq.org/JobDetails.pl?Key=7457 Your paranoid android. === WXPPROSP3 (32 bit activex) === activex.c:127: Test failed: unexpected call FreezeEvents_TRUE activex.c:129: Test failed: unexpected call FreezeEvents_FALSE === WVISTAADM (32 bit activex) === activex.c:127: Test failed: unexpected call FreezeEvents_TRUE activex.c:129: Test failed: unexpected call FreezeEvents_FALSE === W7PRO (32 bit activex) === activex.c:127: Test failed: unexpected call FreezeEvents_TRUE activex.c:129: Test failed: unexpected call FreezeEvents_FALSE === W7PROX64 (32 bit activex) === activex.c:127: Test failed: unexpected call FreezeEvents_TRUE activex.c:129: Test failed: unexpected call FreezeEvents_FALSE === W7PROX64 (64 bit activex) === activex.c:127: Test failed: unexpected call FreezeEvents_TRUE activex.c:129: Test failed: unexpected call FreezeEvents_FALSE

Dec. 5, 2010

Re: [1/4] shdocvw: skip some tests if a modern IE is not present

by Paul Vriens

On 12/02/2010 04:38 AM, Andrew Bogott wrote: > As suggested by Jacek. > Hi Andrew, Even IE6 does things differently as can be seen: http://test.winehq.org/data/tests/shdocvw:intshcut.html Just a matter of adding a broken() statement and bailing out (with cleanup) if the IPropertyStorage_ReadMultiple() fails? -- Cheers, Paul.

Dec. 5, 2010

How to deal with variables where the size differs for 32 and 64bit

by Paul Vriens

Hi, Just found the fix for the oledb32:convert tests on 64bit. We need to adjust our oledb.idl (see patch attached). How should I deal with the ok() messages where we currently specify the 32bit variant? I mean this will of course introduce warnings on the 64bit side. Do I need to create a wrapper for the ok() messages, with a _WIN64 check somewhere? Or use a different printf format identifier? The same is also true for the TRACE() messages in our implementation. -- Cheers, Paul.

Dec. 5, 2010

Re: Use of the L prefix for wide strings in resource files

by Paul Vriens

On 12/05/2010 04:14 PM, Alexandre Julliard wrote: > Paul Vriens<paul.vriens.wine(a)gmail.com> writes: > >> Hi, >> >> Yaron just made me aware of something he and I discussed briefly a few >> weeks ago. >> >> The shlwapi resource files uses the following: >> >> PUSHBUTTON L"&OK", IDOK, 105, 40, 50, 14, WS_GROUP | WS_TABSTOP >> PUSHBUTTON L"&Cancel", IDCANCEL, 160, 40, 50, 14, WS_GROUP | WS_TABSTOP >> PUSHBUTTON L"&Yes", IDYES, 105, 40, 50, 14, WS_GROUP | WS_TABSTOP >> PUSHBUTTON L"&No", IDNO, 160, 40, 50, 14, WS_GROUP | WS_TABSTOP >> >> There doesn't seem to be an issue with most of the languages as our >> resource compiler seem to do things just right. >> >> I did however see strangeness for some languages and also the not yet >> submitted Hebrew translation (maybe more?): >> >> http://source.winehq.org/transl/resource.php?branch=master&lang=011%3A01&re… >> http://source.winehq.org/transl/resource.php?branch=master&lang=022%3A01&re… >> >> ResHacker shows the same strangeness so it appears not only to be the >> translation site. >> >> Any idea where to start looking? > > L"" strings are simply expanded from 8-bit to 16-bit, so it's only > suitable for strings encoded in Latin-1. In fact the parser should > probably reject anything that doesn't fit in 7-bit ASCII. > So we can have a patch that removes those L"" strings and one to change the behavior of the parser? I guess we can get safely rid of all L"" strings instead of just the ones that show the issue. -- Cheers, Paul.

Dec. 5, 2010

Re: Use of the L prefix for wide strings in resource files

by Alexandre Julliard

Paul Vriens <paul.vriens.wine(a)gmail.com> writes: > Hi, > > Yaron just made me aware of something he and I discussed briefly a few > weeks ago. > > The shlwapi resource files uses the following: > > PUSHBUTTON L"&OK", IDOK, 105, 40, 50, 14, WS_GROUP | WS_TABSTOP > PUSHBUTTON L"&Cancel", IDCANCEL, 160, 40, 50, 14, WS_GROUP | WS_TABSTOP > PUSHBUTTON L"&Yes", IDYES, 105, 40, 50, 14, WS_GROUP | WS_TABSTOP > PUSHBUTTON L"&No", IDNO, 160, 40, 50, 14, WS_GROUP | WS_TABSTOP > > There doesn't seem to be an issue with most of the languages as our > resource compiler seem to do things just right. > > I did however see strangeness for some languages and also the not yet > submitted Hebrew translation (maybe more?): > > http://source.winehq.org/transl/resource.php?branch=master&lang=011%3A01&re… > http://source.winehq.org/transl/resource.php?branch=master&lang=022%3A01&re… > > ResHacker shows the same strangeness so it appears not only to be the > translation site. > > Any idea where to start looking? L"" strings are simply expanded from 8-bit to 16-bit, so it's only suitable for strings encoded in Latin-1. In fact the parser should probably reject anything that doesn't fit in 7-bit ASCII. -- Alexandre Julliard julliard(a)winehq.org

Dec. 5, 2010

Re: Use of the L prefix for wide strings in resource files

by Reece Dunn

On 5 December 2010 14:09, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > Hi, > > Yaron just made me aware of something he and I discussed briefly a few weeks > ago. > > The shlwapi resource files uses the following: > > PUSHBUTTON L"&OK", IDOK, 105, 40, 50, 14, WS_GROUP | WS_TABSTOP > PUSHBUTTON L"&Cancel", IDCANCEL, 160, 40, 50, 14, WS_GROUP | WS_TABSTOP > PUSHBUTTON L"&Yes", IDYES, 105, 40, 50, 14, WS_GROUP | WS_TABSTOP > PUSHBUTTON L"&No", IDNO, 160, 40, 50, 14, WS_GROUP | WS_TABSTOP > > There doesn't seem to be an issue with most of the languages as our resource > compiler seem to do things just right. > > I did however see strangeness for some languages and also the not yet > submitted Hebrew translation (maybe more?): > > http://source.winehq.org/transl/resource.php?branch=master&lang=011%3A01&re… > http://source.winehq.org/transl/resource.php?branch=master&lang=022%3A01&re… > > ResHacker shows the same strangeness so it appears not only to be the > translation site. > > Any idea where to start looking? The Cancel button in Japanese looks like raw ShiftJIS in windows 1252 or utf8 encoding. What appears to be happening is: 1/ the localised strings are being converted to their multi-byte representation (e.g. ShiftJIS for the Japanese (lang=011) text) 2/ the multi-byte string is being encoded in the resource codepage (utf8?) This would make sense if the L"..." string is going through MultiByteToWideCharacter with the ShiftJIS encoding (for Japanese) and then the resource is assuming this is utf8 (or whatever the resource file codepage is) and is going through MultiByteToWideCharacter for that as well. I can't recognise the latin character sequences in the Cyrillic dialogs (lang 022); these may be the utf8 sequences. - Reece

Dec. 5, 2010

Use of the L prefix for wide strings in resource files

by Paul Vriens

Hi, Yaron just made me aware of something he and I discussed briefly a few weeks ago. The shlwapi resource files uses the following: PUSHBUTTON L"&OK", IDOK, 105, 40, 50, 14, WS_GROUP | WS_TABSTOP PUSHBUTTON L"&Cancel", IDCANCEL, 160, 40, 50, 14, WS_GROUP | WS_TABSTOP PUSHBUTTON L"&Yes", IDYES, 105, 40, 50, 14, WS_GROUP | WS_TABSTOP PUSHBUTTON L"&No", IDNO, 160, 40, 50, 14, WS_GROUP | WS_TABSTOP There doesn't seem to be an issue with most of the languages as our resource compiler seem to do things just right. I did however see strangeness for some languages and also the not yet submitted Hebrew translation (maybe more?): http://source.winehq.org/transl/resource.php?branch=master&lang=011%3A01&re… http://source.winehq.org/transl/resource.php?branch=master&lang=022%3A01&re… ResHacker shows the same strangeness so it appears not only to be the translation site. Any idea where to start looking? -- Cheers, Paul.

Dec. 5, 2010

Hebrew website issues

by Yaron Shahrabani

The following picture demonstrates the issues: http://lh3.ggpht.com/_QXJR6RTu0qE/TPpTZnza_wI/AAAAAAAADak/yGzX7y8sQI8/winew… <http://lh3.ggpht.com/_QXJR6RTu0qE/TPpTZnza_wI/AAAAAAAADak/yGzX7y8sQI8/winew…>1. The flags are left aligned instead of right aligned (All browsers) 2. The search box is right aligned instead of left aligned (Chromium mostly, sometimes also happens in Firefox) Kind regards, Yaron Shahrabani <Hebrew translator>

Dec. 4, 2010

Re: Death to win9x?

by Jacek Caban

On 12/3/10 7:15 PM, André Hentschel wrote: > As the VMs in Testbot are now retired we might want to delete the "old" win9x testdata from test.winehq.org(we need a name for this, testviewer?) manually? I don't think we need it. We may just start rejecting new reports and old ones will disappear from the report page after some time. Jacek

Dec. 4, 2010

Re: [try 2] msvcrt: Implement wcsnicoll

by Andrew Nguyen

On Fri, Dec 3, 2010 at 11:21 AM, Mike Gibson <mike.gibson(a)storagecraft.com> wrote: > Had a typo in the first try. > --- > dlls/msvcr100/msvcr100.spec | 2 +- > dlls/msvcr70/msvcr70.spec | 2 +- > dlls/msvcr80/msvcr80.spec | 2 +- > dlls/msvcr90/msvcr90.spec | 2 +- > dlls/msvcrt/msvcrt.spec | 2 +- > dlls/msvcrt/wcs.c | 9 +++++++++ > include/msvcrt/string.h | 1 + > include/msvcrt/wchar.h | 1 + > 8 files changed, 16 insertions(+), 5 deletions(-) > > > You forgot to attach the patch.

Dec. 4, 2010

Re: Death to win9x?

by James McKenzie

On 12/3/10 11:15 AM, André Hentschel wrote: > As the VMs in Testbot are now retired we might want to delete the "old" win9x testdata from test.winehq.org(we need a name for this, testviewer?) manually? > André: I almost have to agree with this because we should not expect improvements for these versions. However, I'm thinking of making a change to the richedit test as a prototype to a final introduction for what should be an improvement over using broken() for test cases for the older versions of Windows. The reason I'm picking on richedit is because there is vastly different results for the various riched versions that came with Windows 9x/ME and the current functionality. James McKenzie

Dec. 3, 2010

Re: Death to win9x?

by Saulius Krasuckas

* On Fri, 3 Dec 2010, André Hentschel wrote: > As the VMs in Testbot are now retired we might want to delete the "old" > win9x testdata from test.winehq.org(we need a name for this, > testviewer?) manually? Wait, please. Was there some voting been held to make such sentence official? I think no. * On Tue, 30 Nov 2010, Alexandre Julliard wrote: > > The value of running tests on Win9x these days is certainly > questionable. We don't try to emulate the Win9x behavior anyway, except > in a very few cases (which most likely don't have tests...) So would someone try doing this (testing these rare cases, as Jerome Leclanche wrote), one wouldn't have a chance then (except for running Winetest on Win9x manually) ? I disagree. * On Thu, 2 Dec 2010, Alexandre Julliard wrote: > > That's not useful. The whole point is that we don't want to spend the > effort required to keep the tests error-free on platforms that we don't > care about. That makes it easier to write tests for platforms that > actually matter, which is a more productive use of everybody's time. I believe most of devs writing test cases don't care about Win9x branch already. Here reds count about 5x more than reds from WinNT branch. * On Fri, 3 Dec 2010, Dmitry Timoshkov wrote: > > Right now all the test results that differ for win9x versions are marked > as broken(), Dmitry, you are mistaken. I put the ERROR_NOT_LOGGED_ON case for Win98 in 2005[*], and it's still not broken(). How were you checking that? [*] http://source.winehq.org/git/wine.git/?a=commitdiff;h=5cd099290c5333206e25f… In the worst case I would agree with alternative ways around: 1, to hide Win9x data by moving it to some other page (/data_all); 2, to separate tests into winetest-HASH.exe and winetest9x-HASH.EXE. This would require separate page for the (9x or total) data also. Thanks all for reading this long, S.

Dec. 3, 2010

Re: Death to win9x?

by André Hentschel

As the VMs in Testbot are now retired we might want to delete the "old" win9x testdata from test.winehq.org(we need a name for this, testviewer?) manually? -- Best Regards, André Hentschel

Dec. 3, 2010

Re: [PATCH 2/6] quartz: Add support for filtermapper3 to filtergraph

by Alexandre Julliard

Maarten Lankhorst <m.b.lankhorst(a)gmail.com> writes: > @@ -269,6 +269,9 @@ static HRESULT WINAPI FilterGraphInner_QueryInterface(IUnknown * iface, > } else if (IsEqualGUID(&IID_IFilterMapper2, riid)) { > *ppvObj = This->pFilterMapper2; > TRACE(" returning IFilterMapper2 interface from aggregated filtermapper (%p)\n", *ppvObj); > + } else if (IsEqualGUID(&IID_IFilterMapper3, riid)) { > + *ppvObj = This->pFilterMapper2; > + TRACE(" returning IFilterMapper3 interface from aggregated filtermapper (%p)\n", *ppvObj); You have to query that interface first. -- Alexandre Julliard julliard(a)winehq.org

Dec. 3, 2010

Re: [PATCH] user32/tests: Disable IME for msg tests.

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 http://testbot.winehq.org/JobDetails.pl?Key=7434 Your paranoid android. === W7PROX64 (64 bit msg) === Timeout

Dec. 3, 2010

Re: [PATCH] user32/tests: Close second window in DBCS WM_CHAR tests.

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 http://testbot.winehq.org/JobDetails.pl?Key=7432 Your paranoid android. === W7PROX64 (64 bit msg) === Timeout

Dec. 3, 2010

Re: [1/7] urlmon: Standardize COM implementation of IUri

by Alexandre Julliard

Thomas Mullaly <thomas.mullaly(a)gmail.com> writes: > @@ -3567,7 +3567,7 @@ static HRESULT set_builder_component(LPWSTR *component, DWORD *component_len, LP > return S_OK; > } > > -#define URI(x) ((IUri*) &(x)->lpIUriVtbl) > +#define URI(x) ((IUri*) &(x)->IUri_iface.lpVtbl) > #define URIBUILDER(x) ((IUriBuilder*) &(x)->lpIUriBuilderVtbl) You should also get rid of these macros. -- Alexandre Julliard julliard(a)winehq.org

Dec. 3, 2010

Re: Death to win9x?

by K.King

<<< A majority of that effort is rewriting tests to make win9x happy, not rewriting behavior to fix win9x applications. >>> Understood <<< Few people (if any) want to intentionally break win9x applications, but spending a large amount of developer effort to maintain the tests there isn't really the best investment, when it could instead be spent fixing real bugs. >>> Regressions are a normal part of large scale development. Regressions are real bugs. Unless you are becoming what you imitate:-) <<< I could drop the Win9x tests and concentrate on Windows 2000 and higher. Would this be a good course of action? >>> Drop seems harsh, prioritize seems reasonable. If you are 199% confident nothing you do would affect Win9x (famous developer last words) Or AJ says put the Win9x users in the lifeboat then it's a good course for you And a not so good one for Win9x users.

Dec. 3, 2010

Re: Death to win9x?

by Dmitry Timoshkov

James McKenzie <jjmckenzie51(a)earthlink.net> wrote: > True, but what happens IF the game stops working? Will a bug report > with regression test be accepted or will it be rejected? Are you kidding? Something tells me that you have no idea what you are talking about. > You can see there is a little fear if we stop testing Windows9x > completely. However, if we move the Windows9x VMs out of the way so we > can concentrate on current versions, that is a good idea as some > functionality of the current Windows versions does not exist or is > vastly different. Right now all the test results that differ for win9x versions are marked as broken(), i.e. Wine intentionally makes an effort to NOT replicate it. So removing checks for (broken) results will change nothing. People complaining that Wine no more cares about applications written for Win9x should calm down, support for win9x apps and removing broken() statements from tests has no any connection. -- Dmitry.

Dec. 2, 2010

Re: ddeml: More calling convention fixes

by Dmitry Timoshkov

Tristan Schmelcher <tristan_schmelcher(a)alumni.uwaterloo.ca> wrote: > I think CBR_BLOCK is only for values of type HDDEDATA. The cbData > value here is a DWORD (specifying a length). (DWORD)-1 seems to be the > preferred way of checking this condition in the existing code, e.g. > see dlls/user32/dde_client.c lines 637, 648, etc. You are right. -- Dmitry.

Dec. 2, 2010

Re: msvcrt: Implement wcsnicoll

by Juan Lang

Hi Mike, --- a/dlls/msvcr70/msvcr70.spec +++ b/dlls/msvcr70/msvcr70.spec @@ -601,7 +601,7 @@ @ cdecl _wcslwr(wstr) msvcrt._wcslwr @ stub _wcsncoll @ cdecl _wcsnicmp(wstr wstr long) msvcrt._wcsnicmp -@ stub _wcsnicoll +@ cdecl _wcsnicoll(wstr wstr long) msvcrt._wcsnicmp Typo?

Dec. 2, 2010

Re: [3/7] urlmon: Implemented PARSE_PATH_FROM_URL for CoInternetParseIUri

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 http://testbot.winehq.org/JobDetails.pl?Key=7419 Your paranoid android. === WVISTAADM (32 bit uri) === Failure running script in VM: The specified guest user must be logged in interactively to perform this operation

Dec. 2, 2010

Re: Death to win9x?

by James McKenzie

On 12/2/10 10:43 AM, André Hentschel wrote: > Am 02.12.2010 16:11, schrieb James Mckenzie: >> Should I just go out and find a copy of Windows98SE and VirtualBox to run this on? Your reply makes it sound like the Wine program just does not care if Windows9x functionality does not matter, it does. > Shutting down the test does not necessary meens wine will break the 9x stuff over time. actually we just always need to do something like skip() or broken() and that's nothing else as ignoring the test results of 9x and as you still play that game i guess wine still works here. True, but what happens IF the game stops working? Will a bug report with regression test be accepted or will it be rejected? You can see there is a little fear if we stop testing Windows9x completely. However, if we move the Windows9x VMs out of the way so we can concentrate on current versions, that is a good idea as some functionality of the current Windows versions does not exist or is vastly different. James McKenzie

Dec. 2, 2010

Re: wineqtdecoder: initial commit of the video decoder using Mac OS/X QuickTime Framework

by Aric Stewart

Humm, Yup you are right. I was chatting with Ken Thomases earlier today and he was talking about QTKit and how it is only Objective-C and the next step beyond QuickTime. I had not realized that there where no 64 bit versions of the Quicktime framework. I think we are stuck. Since we are using the Carbon framework not Cocoa we don't really have access to QTKit. We may as well use Quicktime since it is still available. -aric On 12/2/10 8:10 PM, Charles Davis wrote: > On 12/2/10 7:06 PM, Aric Stewart wrote: >> That was true of the first set of APIs i used. But I believe the >> ICMDecompressionSession APIs are available on 64-bit and not deprecated. > > chips-computer:/System/Library/Frameworks/QuickTime.framework chip$ nm > -arch x86_64 QuickTime > nm: file: QuickTime does not contain architecture: x86_64 > chips-computer:/System/Library/Frameworks/QuickTime.framework chip$ > > Chip > >

Dec. 2, 2010

Re: wineqtdecoder: initial commit of the video decoder using Mac OS/X QuickTime Framework

by Charles Davis

On 12/2/10 7:06 PM, Aric Stewart wrote: > That was true of the first set of APIs i used. But I believe the > ICMDecompressionSession APIs are available on 64-bit and not deprecated. chips-computer:/System/Library/Frameworks/QuickTime.framework chip$ nm -arch x86_64 QuickTime nm: file: QuickTime does not contain architecture: x86_64 chips-computer:/System/Library/Frameworks/QuickTime.framework chip$ Chip

Dec. 2, 2010

Re: wineqtdecoder: initial commit of the video decoder using Mac OS/X QuickTime Framework

by Aric Stewart

That was true of the first set of APIs i used. But I believe the ICMDecompressionSession APIs are available on 64-bit and not deprecated. -aric On 12/2/10 3:46 PM, C.W. Betts wrote: > The main problem when using the QuickTime C APIs is that the majority, if not all of it, is deprecated and not available on 64-bit code. I would suggest using the Objective-C QTKit, but apparently Objective-C code is a no-no in Wine. > On Nov 29, 2010, at 10:31 AM, Aric Stewart wrote: > >> --- >> configure | 8 +- >> configure.ac | 5 + >> dlls/wineqtdecoder/Makefile.in | 11 + >> dlls/wineqtdecoder/main.c | 135 +++++++++ >> dlls/wineqtdecoder/qtvdecoder.c | 536 +++++++++++++++++++++++++++++++++ >> dlls/wineqtdecoder/version.rc | 26 ++ >> dlls/wineqtdecoder/wineqtdecoder.spec | 4 + >> 7 files changed, 724 insertions(+), 1 deletions(-) >> create mode 100644 dlls/wineqtdecoder/Makefile.in >> create mode 100644 dlls/wineqtdecoder/main.c >> create mode 100644 dlls/wineqtdecoder/qtvdecoder.c >> create mode 100644 dlls/wineqtdecoder/version.rc >> create mode 100644 dlls/wineqtdecoder/wineqtdecoder.spec >> >> >> <89fa3b1cdaca45ec01cde9e2350010b82c985666.diff> > > >

Dec. 2, 2010

Re: user32/tests: skip more input tests on 98 and ME

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 http://testbot.winehq.org/JobDetails.pl?Key=7412 Your paranoid android. === WVISTAADM (32 bit input) === Failure running script in VM: The specified guest user must be logged in interactively to perform this operation

Dec. 2, 2010

Re: d3d8/d3d9: fix compiler warnings on non x86/x86_64

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 http://testbot.winehq.org/JobDetails.pl?Key=7411 Your paranoid android. === WVISTAADM (32 bit device) === device.c:2512: Test failed: Expected foreground window 000101D6, got 000101D2. === W7PRO (32 bit device) === device.c:2512: Test failed: Expected foreground window 00020158, got 00020058. device.c:2651: Test failed: Expected foreground window 00030158, got 00020058. === W7PROX64 (64 bit device) === device.c:2512: Test failed: Expected foreground window 00000000000F0176, got 0000000000010068. device.c:2651: Test failed: Expected foreground window 0000000000100176, got 0000000000010068.

Dec. 2, 2010

Re: d3d8/d3d9: fix compiler warnings on non x86/x86_64

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 http://testbot.winehq.org/JobDetails.pl?Key=7410 Your paranoid android. === W2K8SE (32 bit device) === device.c:1671: Test failed: Expected foreground window 00010126, got 0001011A. === W7PROX64 (32 bit device) === device.c:1671: Test failed: Expected foreground window 00030186, got 00010068. device.c:1810: Test failed: Expected foreground window 00040186, got 00010068.

Dec. 2, 2010

Re: wineqtdecoder: initial commit of the video decoder using Mac OS/X QuickTime Framework

by C.W. Betts

The main problem when using the QuickTime C APIs is that the majority, if not all of it, is deprecated and not available on 64-bit code. I would suggest using the Objective-C QTKit, but apparently Objective-C code is a no-no in Wine. On Nov 29, 2010, at 10:31 AM, Aric Stewart wrote: > --- > configure | 8 +- > configure.ac | 5 + > dlls/wineqtdecoder/Makefile.in | 11 + > dlls/wineqtdecoder/main.c | 135 +++++++++ > dlls/wineqtdecoder/qtvdecoder.c | 536 +++++++++++++++++++++++++++++++++ > dlls/wineqtdecoder/version.rc | 26 ++ > dlls/wineqtdecoder/wineqtdecoder.spec | 4 + > 7 files changed, 724 insertions(+), 1 deletions(-) > create mode 100644 dlls/wineqtdecoder/Makefile.in > create mode 100644 dlls/wineqtdecoder/main.c > create mode 100644 dlls/wineqtdecoder/qtvdecoder.c > create mode 100644 dlls/wineqtdecoder/version.rc > create mode 100644 dlls/wineqtdecoder/wineqtdecoder.spec > > > <89fa3b1cdaca45ec01cde9e2350010b82c985666.diff>

Dec. 2, 2010

Re: Death to win9x?

by Wolfram Sang

> The only problem is that testbot does not allow me to set an environment > variable. All testbot knows are command line arguments. Well, you can use 7zip and its SFX-capabilities to do a lot more with testbot. I used this to invoke winhlp showing a specific helpfile :) For your case, you might embed a shell script or similar? Regards, Wolfram

Dec. 2, 2010

Re: Death to win9x?

by James Mckenzie

Austin English <austinenglish(a)gmail.com> wrote: > >On Thu, Dec 2, 2010 at 8:00 PM, K.King <k.king177(a)ntlworld.com> wrote: >> <<< >> That's not useful. The whole point is that we don't want to spend the >> effort required to keep the tests error-free on platforms that we don't >> care about. That makes it easier to write tests for platforms that >> actually matter, which is a more productive use of everybody's time. >>>>> >> You may not care, but I know a number of people who do. >> For some running the older software is more important, of interest, or use. > >A majority of that effort is rewriting tests to make win9x happy, not >rewriting behavior to fix win9x applications. > >Few people (if any) want to intentionally break win9x applications, >but spending a large amount of developer effort to maintain the tests >there isn't really the best investment, when it could instead be spent >fixing real bugs. > This I do agree with. I'm working on tests for richedit and the expected reaction of the Win9x version is much different than the reaction of the WindowsXP version. I could drop the Win9x tests and concentrate on Windows 2000 and higher. Would this be a good course of action? James McKenzie

Dec. 2, 2010

Re: Death to win9x?

by Austin English

On Thu, Dec 2, 2010 at 8:00 PM, K.King <k.king177(a)ntlworld.com> wrote: > <<< > That's not useful. The whole point is that we don't want to spend the > effort required to keep the tests error-free on platforms that we don't > care about. That makes it easier to write tests for platforms that > actually matter, which is a more productive use of everybody's time. >>>> > You may not care, but I know a number of people who do. > For some running the older software is more important, of interest, or use. A majority of that effort is rewriting tests to make win9x happy, not rewriting behavior to fix win9x applications. Few people (if any) want to intentionally break win9x applications, but spending a large amount of developer effort to maintain the tests there isn't really the best investment, when it could instead be spent fixing real bugs. -- -Austin

Dec. 2, 2010

Re: Death to win9x?

by K.King

<<< That's not useful. The whole point is that we don't want to spend the effort required to keep the tests error-free on platforms that we don't care about. That makes it easier to write tests for platforms that actually matter, which is a more productive use of everybody's time. >>> You may not care, but I know a number of people who do. For some running the older software is more important, of interest, or use.

Dec. 2, 2010

Re: Death to win9x?

by André Hentschel

Am 02.12.2010 19:17, schrieb Joerg-Cyril.Hoehle(a)t-systems.com: > André Hentschel wrote: > >> I recently sent a patch to have a new debuglevel "2", but AJ wisely >> pointed out we can simply set WINETEST_PLATFORM=wine on Windows >> which has the same effect. So no need for such hacks :D > > I once submitted a similar command line patch: runtest --strict :-) > > AJ is right. The only problem is that testbot does not allow me to set an environment > variable. All testbot knows are command line arguments. you are free to send a patch for testbot to handle that (yes, testbot is open source) :) -- Best Regards, André Hentschel

Dec. 2, 2010

Re: [PATCH 5/7] npmshtml: Added Mozilla plugin for mshtml ActiveX controls.

by Jacek Caban

On 12/2/10 2:23 PM, Alexandre Julliard wrote: > Jacek Caban<jacek(a)codeweavers.com> writes: > >> Um, that was stupid from me. I've previously made NP_* function >> failing, but it didn't work well, so I've changed it to DllMain. I >> don't see a clean way to fix registration. We could set these >> registries from mshtml.dll, but then we lose the ability to easily >> unregister npmshtml.dll. >> >> I've sent a patch that checks if it's running from rundll32 or >> regsvr32 and allows the DLL to load them. I hope it's not too hackish. > I don't think it's a good idea to try to magically fail on DLL load. It > would prevent registering from other tools, loading to check version > resources, etc. It's preferable to always allow it to load. Agreed, but everything we can do will be some kind of hack. I've found the solution that seems much better. Although Gecko standard plugin directory service doesn't work well for us (the API is in place, it's just used by a high embedding layer in the way that prevents us from using it properly), but there is an environment variable that we can use to specify a custom plugin directory. The only drawback of it is that we need a special directory, but on the other side not having Wine-specific DLL in system directory is a good thing. > Of course an even better way would be to change Gecko to make it > possible to not have a separate dll at all... That's true and it was my initial intention. There was even partial support for such solution in Gecko (called XPCOM plugins), but it was removed from the tree. The only supported way for plugins is NPAPI. Its requirement for DLLs in rooted deep in the code. It means that if we decided to have a Wine-specific changes, we'd have to maintain more changes that I'd like. Integrating it with mainstream may be tricky. Partial solution that would require less Gecko changes is also possible, but it would still be a hack, just living in a different place. Jacek

Dec. 2, 2010

Death to win9x?

by Joerg-Cyril.Hoehle＠t-systems.com

André Hentschel wrote: >I recently sent a patch to have a new debuglevel "2", but AJ wisely >pointed out we can simply set WINETEST_PLATFORM=wine on Windows >which has the same effect. So no need for such hacks :D I once submitted a similar command line patch: runtest --strict :-) AJ is right. The only problem is that testbot does not allow me to set an environment variable. All testbot knows are command line arguments. One idea would be to be able to run winetest.exe inside testbot with enough command line arguments that it runs all tests and submits results on its own. Regards, Jörg Höhle

Dec. 2, 2010

Re: ddeml: More calling convention fixes

by Tristan Schmelcher

I think CBR_BLOCK is only for values of type HDDEDATA. The cbData value here is a DWORD (specifying a length). (DWORD)-1 seems to be the preferred way of checking this condition in the existing code, e.g. see dlls/user32/dde_client.c lines 637, 648, etc. I will re-send the patch in two parts. On Thu, Dec 2, 2010 at 12:19 AM, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: > Tristan Schmelcher <tristan_schmelcher(a)alumni.uwaterloo.ca> wrote: > >> + if (cbData != (DWORD)-1) >> + { >> + /* pData is not a pointer if cbData is -1, so we linearize the address >> + * here rather than in the calling code. */ >> + pData = MapSL((SEGPTR)pData); >> + } > > -1 here should be replaced by CBR_BLOCK, and this piece of the patch > should be sent separately from .spec file fixes. > > -- > Dmitry. >

Dec. 2, 2010

Re: [1/2] wininet: Use proper error code define instead of its value

by Alexandre Julliard

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > @@ -270,7 +270,7 @@ static DWORD netconn_verify_cert(PCCERT_CONTEXT cert, HCERTSTORE store, > else if (chain->TrustStatus.dwErrorStatus & ~supportedErrors) > err = ERROR_INTERNET_SEC_INVALID_CERT; > } > - if (!err) > + if (err == ERROR_SUCCESS) There's no reason to change this. 0 meaning success is a common convention, and at least as clear as using an error code for no error. -- Alexandre Julliard julliard(a)winehq.org

Dec. 2, 2010

Re: wineps.drv: return error if unable to select a builtin font

by Alexandre Julliard

Aric Stewart <aric(a)codeweavers.com> writes: > @@ -191,6 +191,12 @@ BOOL PSDRV_SelectBuiltinFont(PSDRV_PDEVICE *physDev, HFONT hfont, > if(!family) > family = physDev->pi->Fonts; > > + if (!family) > + { > + ERR("Unable to get any font for printer\n"); > + return FALSE; > + } If this is something that can legitimately happen it should be handled correctly. -- Alexandre Julliard julliard(a)winehq.org

Dec. 2, 2010

Re: Death to win9x?

by André Hentschel

Am 02.12.2010 16:11, schrieb James Mckenzie: > Should I just go out and find a copy of Windows98SE and VirtualBox to run this on? Your reply makes it sound like the Wine program just does not care if Windows9x functionality does not matter, it does. Shutting down the test does not necessary meens wine will break the 9x stuff over time. actually we just always need to do something like skip() or broken() and that's nothing else as ignoring the test results of 9x and as you still play that game i guess wine still works here. -- Best Regards, André Hentschel

Dec. 2, 2010

Re: Death to win9x?

by André Hentschel

Am 02.12.2010 13:46, schrieb Joerg-Cyril.Hoehle(a)t-systems.com: > An independent idea is to run a special winetest.exe compiled with > int broken(int condition) { return 0; } I recently sent a patch to have a new debuglevel "2", but AJ wisely pointed out we can simply set WINETEST_PLATFORM=wine on Windows which has the same effect. So no need for such hacks :D -- Best Regards, André Hentschel

Dec. 2, 2010

Re: Death to win9x?

by James Mckenzie

Alexandre Julliard <julliard(a)winehq.org> wrote: >Sent: Dec 2, 2010 6:30 AM >To: Joerg-Cyril.Hoehle(a)t-systems.com >Cc: wine-devel(a)winehq.org >Subject: Re: Death to win9x? > ><Joerg-Cyril.Hoehle(a)t-systems.com> writes: > >> However, this only allows to run one test at a time, i.e. the big picture is missing. >> Therefore I'd suggest running winetest.exe on all testbot machines once a week >> or some such, e.g. only for releases. > >That's not useful. The whole point is that we don't want to spend the >effort required to keep the tests error-free on platforms that we don't >care about. That makes it easier to write tests for platforms that >actually matter, which is a more productive use of everybody's time. > YOU might not care about them AJ, but we have Wine users that are still using Windows95 programs with Wine on Linux and there are NO suitable replacements for them. Several recent user reports have asked how do I get program X (released for Windows95) to work on Wine. One of my test programs is dOOmII, released in 1996 and I use Wine to run it. Should I just go out and find a copy of Windows98SE and VirtualBox to run this on? Your reply makes it sound like the Wine program just does not care if Windows9x functionality does not matter, it does. I do agree that not much effort should be expended to incorporate more 'A' functionality, but breaking what does work is not reflect well on this project. Remember the original purpose and I think it is still the purpose is to build out the ENTIRE Windows64/32 API, not just a portion of it. If I'm wrong, feel free to chastise me. James McKenzie

Dec. 2, 2010

Re: Death to win9x?

by Jerome Leclanche

My very tentative $.02: If there are tests we care about on Win9x (for old apps), wouldn't it be easier to move them to their own file/folder, and only run those and only those on 9x? If the regular tests are going to lose all their broken() calls and become meaningless on 9x, we still will want to test specific features on old versions of Windows (for old apps as Dan mentioned). That way, tests are still easier to write, but we don't lose that ability. JL On Thu, Dec 2, 2010 at 1:30 PM, Alexandre Julliard <julliard(a)winehq.org> wrote: > <Joerg-Cyril.Hoehle(a)t-systems.com> writes: > >> However, this only allows to run one test at a time, i.e. the big picture is missing. >> Therefore I'd suggest running winetest.exe on all testbot machines once a week >> or some such, e.g. only for releases. > > That's not useful. The whole point is that we don't want to spend the > effort required to keep the tests error-free on platforms that we don't > care about. That makes it easier to write tests for platforms that > actually matter, which is a more productive use of everybody's time. > > -- > Alexandre Julliard > julliard(a)winehq.org > > >

Dec. 2, 2010

Re: Death to win9x?

by Alexandre Julliard

<Joerg-Cyril.Hoehle(a)t-systems.com> writes: > However, this only allows to run one test at a time, i.e. the big picture is missing. > Therefore I'd suggest running winetest.exe on all testbot machines once a week > or some such, e.g. only for releases. That's not useful. The whole point is that we don't want to spend the effort required to keep the tests error-free on platforms that we don't care about. That makes it easier to write tests for platforms that actually matter, which is a more productive use of everybody's time. -- Alexandre Julliard julliard(a)winehq.org

Dec. 2, 2010

Re: [PATCH 5/7] npmshtml: Added Mozilla plugin for mshtml ActiveX controls.

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> writes: > Um, that was stupid from me. I've previously made NP_* function > failing, but it didn't work well, so I've changed it to DllMain. I > don't see a clean way to fix registration. We could set these > registries from mshtml.dll, but then we lose the ability to easily > unregister npmshtml.dll. > > I've sent a patch that checks if it's running from rundll32 or > regsvr32 and allows the DLL to load them. I hope it's not too hackish. I don't think it's a good idea to try to magically fail on DLL load. It would prevent registering from other tools, loading to check version resources, etc. It's preferable to always allow it to load. Of course an even better way would be to change Gecko to make it possible to not have a separate dll at all... -- Alexandre Julliard julliard(a)winehq.org

Dec. 2, 2010

Re: [PATCH 5/7] npmshtml: Added Mozilla plugin for mshtml ActiveX controls.

by Jacek Caban

On 12/2/10 12:49 PM, Alexandre Julliard wrote: > Jacek Caban<jacek(a)codeweavers.com> writes: > >> I know that this patch is the most questionable. Gecko expects us to >> give it a DLL named np*.dll, so we can't do it in mshtml. Also, this >> plugin will be visible to other NPAPI-based browsers running in Wine >> (that's a matter of change in the next Gecko release), so it's good >> that it's a tiny wrapper that fails to load if mshtml is not loaded >> (meaning that we're not running in Wine Gecko). > This prevents the dll registration code from running, since mshtml is > not loaded at that point. Um, that was stupid from me. I've previously made NP_* function failing, but it didn't work well, so I've changed it to DllMain. I don't see a clean way to fix registration. We could set these registries from mshtml.dll, but then we lose the ability to easily unregister npmshtml.dll. I've sent a patch that checks if it's running from rundll32 or regsvr32 and allows the DLL to load them. I hope it's not too hackish. Jacek

Dec. 2, 2010

Death to win9x?

by Joerg-Cyril.Hoehle＠t-systems.com

Dan Kegel wrote: >Like you, I'm afraid that dropping the win9x tests will lead >to regressions old older apps. Greg Geldorp wrote: >However, they [Win9x VMs] would be available for selection >if you click "Show all VMs" button when submitting a job. This sounds very desirable. However, this only allows to run one test at a time, i.e. the big picture is missing. Therefore I'd suggest running winetest.exe on all testbot machines once a week or some such, e.g. only for releases. Later a student may write a thesis about the degradation of SW over time ;-) An independent idea is to run a special winetest.exe compiled with int broken(int condition) { return 0; } once a week on (some of?) the regular machines. However this is best performed *not* on release days, based on the assumption that more people submit test data for release versions than the day to day ones, and we don't want to "pollute" these with stricter tests. Regards, Jörg Höhle

Dec. 2, 2010

Re: [PATCH 5/7] npmshtml: Added Mozilla plugin for mshtml ActiveX controls.

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> writes: > I know that this patch is the most questionable. Gecko expects us to > give it a DLL named np*.dll, so we can't do it in mshtml. Also, this > plugin will be visible to other NPAPI-based browsers running in Wine > (that's a matter of change in the next Gecko release), so it's good > that it's a tiny wrapper that fails to load if mshtml is not loaded > (meaning that we're not running in Wine Gecko). This prevents the dll registration code from running, since mshtml is not loaded at that point. -- Alexandre Julliard julliard(a)winehq.org

Dec. 2, 2010

Re: [4/4] shdocvw: In PersistFile_Save, output the Icon Path and Icon Index properties

by Damjan Jovanovic

On Thu, Dec 2, 2010 at 5:39 AM, Andrew Bogott <Andrew(a)codeweavers.com> wrote: > This gets Icon Path and Icon Index written out to .url files if they've been > set previously. > > > > I think you leak a reference to pPropStgRead here. Nice patch set otherwise :-) Damjan

Dec. 2, 2010

Re: [2/2] msi: Clear last error on success in MsiQueryFeatureState and MsiQueryProductState.

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 http://testbot.winehq.org/JobDetails.pl?Key=7392 Your paranoid android. === W2KPROSP4 (32 bit msi) === msi.c:618: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:633: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:646: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:666: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:677: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:695: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:705: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:716: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:727: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:736: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:972: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:979: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:994: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:1004: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:1028: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:1037: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:1046: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:1055: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:1064: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:1086: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:1095: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:1104: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:1114: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:1124: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:1134: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:1144: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:1154: Test failed: expected ERROR_SUCCESS, got 1008

Dec. 2, 2010

Re: poor Wine performance creating fat dialogs

by Marcus Meissner

On Wed, Dec 01, 2010 at 11:42:44PM +0100, Andreas Pflug wrote: > Am 26.11.2010 13:39, schrieb Marcus Meissner: > >On Fri, Nov 26, 2010 at 01:06:32PM +0100, Andreas Pflug wrote: > >>I'm investigating running a commercial ERP system under Wine (only > >>binary available). It mostly works, but creating the main dialogs > >>for item, customer and such will need around 25 seconds, while > >>running on Wxx it takes 2-3 seconds. After that, there's no serious > >>performance impact working on these dialogs. > >> > >>The dialogs contain a lot of controls, like 500 or so each, so I > >>suspect that's what makes things slow. > >> > >>I'm willing to investigate this in the wine sources, if it makes > >>sense. So before I start I'd like to know if there are known or > >>suspected inefficient code regions that might cause the problem? > >>Maybe some win<->x11 translation tables that degrade with 1000+ > >>windows? Or has this been observed before, and the problem is > >>outside of wine's scope? > >In 1.2.0 there was such a bug which was fixed in 1.2.1. What version > >do you use? If not, have you tried the current development version? > > > > Maybe some regression in the git HEAD I'm using? If it would be a regression, do you know a "good version" which performs better? If you can pinpoint a good and a bad version, you can also try running a "git bisect". See http://wiki.winehq.org/RegressionTesting Given the number of controls there probably are some scaling issues, not just one :/ ciao, Marcus

Dec. 2, 2010

Re: ddeml: More calling convention fixes

by Dmitry Timoshkov

Tristan Schmelcher <tristan_schmelcher(a)alumni.uwaterloo.ca> wrote: > + if (cbData != (DWORD)-1) > + { > + /* pData is not a pointer if cbData is -1, so we linearize the address > + * here rather than in the calling code. */ > + pData = MapSL((SEGPTR)pData); > + } -1 here should be replaced by CBR_BLOCK, and this piece of the patch should be sent separately from .spec file fixes. -- Dmitry.

Dec. 2, 2010

Re: [PATCH] shell32/tests: Fixed SHPathPrepareForWriteW tests on Asian platforms.

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 http://testbot.winehq.org/JobDetails.pl?Key=7381 Your paranoid android. === WNT4WSSP6 (32 bit shlfileop) === shlfileop.c:2207: Test failed: SHGetNewLinkInfoA succeeded

Dec. 2, 2010

Re: poor Wine performance creating fat dialogs

by Andreas Pflug

Am 26.11.2010 13:39, schrieb Marcus Meissner: > On Fri, Nov 26, 2010 at 01:06:32PM +0100, Andreas Pflug wrote: >> I'm investigating running a commercial ERP system under Wine (only >> binary available). It mostly works, but creating the main dialogs >> for item, customer and such will need around 25 seconds, while >> running on Wxx it takes 2-3 seconds. After that, there's no serious >> performance impact working on these dialogs. >> >> The dialogs contain a lot of controls, like 500 or so each, so I >> suspect that's what makes things slow. >> >> I'm willing to investigate this in the wine sources, if it makes >> sense. So before I start I'd like to know if there are known or >> suspected inefficient code regions that might cause the problem? >> Maybe some win<->x11 translation tables that degrade with 1000+ >> windows? Or has this been observed before, and the problem is >> outside of wine's scope? > In 1.2.0 there was such a bug which was fixed in 1.2.1. What version > do you use? If not, have you tried the current development version? > Maybe some regression in the git HEAD I'm using? Regards Andreas

Dec. 1, 2010

Re: Death to win9x?

by Dan Kegel

Joerg-Cyril.Hoehle wrote: > Is it "Death to 16bit" you meant? No. Sorry, I probably should have written more carefully, or not at all. The subject line was chosen to stimulate discussion of the possible consequences of dropping the win9x test runs. Like you, I'm afraid that dropping the win9x tests will lead to regressions old older apps. But Alexandre said he favors dropping the win9x test runs to save developer effort, and I trust his judgment.

Dec. 1, 2010

Death to win9x?

by Joerg-Cyril.Hoehle＠t-systems.com

Dan Kegel wrote: >I'm all for removing stuff that nobody needs anymore. Who said nobody needs Win9x anymore? > I imagine there >are still a few popular older apps that will force us to keep some old >win9x behaviors around, though, so we probably won't be able >to remove the 'emulate win98' choice from winecfg any time soon. Probably half of the apps I bought during the last years work with Win9X. Just the other day I saw a mciSendCommand16 in a log. Well, 16bit != win9x. Is it "Death to 16bit" you meant? What's the motivation behind removing stuff *now* suddenly? Is it the perceived effort needed to fix the tests to all green colour on testbot's win9x machines? Why was this topic not discussed recently at Wineconf? It would be a very bad idea to remove win9x from testbot. We need these old systems to understand what behaviour old apps expect. And I'm very thankful to Greg for his testbot service. Without it, we would know next to nothing about win9x. The fact that a random old app works in native XP (in compatibility mode) teaches us nothing for Wine. Unless we start to run winetest in compatibility mode! I've already mentioned in the past the idea to run testbot sometimes with all broken() disabled, to assess failures on newer systems. broken() may shadow errors in the tests and lull Wine developers into wrong beliefs. Paul Vriens wrote: >The little bits and pieces we have in our code should stay as we >probably need that to cope with old apps that expect a different behavior. Actually, I've even been thinking about implementing the opposite behaviour: Old APIs are mostly used by old apps, while newer apps moved to newer ones (e.g. DirectSound, then mmdev). Therefore it would make a lot of sense to have old APIs (e.g. WINMM/MCI/VfW) mimic the behaviour observable when these apps were developed: win9x! (win3.x?) We don't even know whether MS' compatibility mode does precisely that. Regards, Jörg Höhle

Dec. 1, 2010

Re: [PATCH 4/5] quartz: Add quality control to sound renderer

by Alexandre Julliard

Maarten Lankhorst <m.b.lankhorst(a)gmail.com> writes: > --- > dlls/quartz/dsoundrender.c | 29 +++++++++++++++++++++++++++++ > 1 files changed, 29 insertions(+), 0 deletions(-) It breaks here: ../../../tools/runtest -q -P wine -M quartz.dll -T ../../.. -p quartz_test.exe.so dsoundrender.c && touch dsoundrender.ok dsoundrender.c:153: Test succeeded inside todo block: IUnknown_QueryInterface returned 0 dsoundrender.c:153: Test succeeded inside todo block: Pointer is NULL dsoundrender.c:154: Test succeeded inside todo block: IUnknown_Release should return 1, got 1 make: *** [dsoundrender.ok] Error 3 -- Alexandre Julliard julliard(a)winehq.org

Dec. 1, 2010

Re: Stopping Win9x testing

by Greg Geldorp

> From: Wolfram Sang > > > I'll mark the Win9x VMs offline when there's nothing queued to run on them. > > Then in a weeks time I can delete them after all jobs referring to them > > have been retired/deleted (referential integrity in the database). > > That means they even won't be available then for some specific corner-case > tests (in which they are selected manually)? Hmm, is there much overhead > involved to keep them "just in case"? Yeah, that might be a good idea. Currently VMs are divided into a "Base" and a "Extra" group, I can add a "Retired" group to hold the Win9x VMs. VMs in this group wouldn't participate in the daily winetest run, wouldn't be used for verification of wine-patches submissions and wouldn't be selected by default when manually submitting a job. However, they would be available for selection if you click "Show all VMs" button when submitting a job. This will require some changes to the code, but nothing major. I'll look into it. Greg.

Dec. 1, 2010

Re: [PATCH 2/2] opencl: Basic OpenCL 1.0 implementation. (try 2)

by Alexandre Julliard

Peter Urbanec <winehq.org(a)urbanec.net> writes: > Would you like me to resubmit the patch with the dynamic loading > replaced with a simpler linked version? I guess once we see OpenCL 1.1 > implementations in the real world, we can add dynamic loading only for > the affected functions, if any. That would be better, yes. -- Alexandre Julliard julliard(a)winehq.org

Dec. 1, 2010

Re: [PATCH 2/2] opencl: Basic OpenCL 1.0 implementation. (try 2)

by Peter Urbanec

On 01/12/10 22:47, Alexandre Julliard wrote: > Peter Urbanec<winehq.org(a)urbanec.net> writes: >> Second, I am anticipating that when wine OpenCL 1.1 support >> is added, we'll need to determine whether the host is using OpenCL 1.0 >> or 1.1, at runtime. > > How is that going to work? OpenCL 1.1 removed the clSetCommandQueueProperty API, which means that it's probably no longer going to be exported from the OpenCL 1.1 .so file. On the other hand, OpenCL 1.1 introduces a number of new APIs, such as SubBuffers and BufferRects that won't be in the OpenCL 1.0 .so file. I have no idea how the various vendors will deal with these changes, so my strategy was to implement a dynamic solution. The idea being that I can figure out whether an implementation is OpenCL 1.0 or 1.1 compliant, without having to get a list of platform IDs and then query the CL_PLATFORM_VERSION and parse the string. Perhaps I'm over-engineering this and I should just concentrate on current OpenCL 1.0 functionality and deal with OpenCL 1.1 when it hits mainstream. As it is, the current incarnation of the dynamic loading will fail in more or less the same way as a linked version would. Would you like me to resubmit the patch with the dynamic loading replaced with a simpler linked version? I guess once we see OpenCL 1.1 implementations in the real world, we can add dynamic loading only for the affected functions, if any. Best regards, Peter Urbanec

Dec. 1, 2010

Re: [PATCH 2/2] opencl: Basic OpenCL 1.0 implementation. (try 2)

by Peter Urbanec

On 01/12/10 12:33, Roderick Colenbrander wrote: > OpenCL is a little different of course, but I fear that not all OpenCL > implementations will like wrapping. What OpenCL applications have you > tried so far? The Nvidia GPU Computing SDK (or whatever it was called) > has a ton of samples for both Cuda and OpenCL. Do all their OpenCL > samples work? I added wine OpenCL support in order to get OpenCL functionality in eyeon Fusion 6.1 [*] and it works with both built-in tools and Fuses. I also tested with a number of (not all) samples from the Nvidia GPU Computing SDK. It works with the simple ones, like oclDeviceQuery.exe and oclBandwidthTest.exe as well as the more complex ones, like oclParticles.exe I only tested with Nvidia GT240 hardware, 260.19.x series drivers, but I will get a chance to test with an ATI FirePro V5800 at some point in the future. So far, I have only implemented support for the mandatory core OpenCL 1.0 functionality. In particular, native kernels (optional feature) are not supported and probably never will be. Extensions are not yet supported, they will each have to be dealt with on individual basis, but I suspect that features such as cl_khr_fp64 support should be doable. OpenGL sharing is also not supported yet - mainly because I don't know enough about wine OpenGL internals. I'm hoping that I will get some help with OpenGL sharing once the basic OpenCL implementation is in the wine tree. [*] http://www.eyeonline.com/Web/EyeonWeb/Products/fusion6/fusion6.aspx

Dec. 1, 2010

Re: [PATCH 2/2] opencl: Basic OpenCL 1.0 implementation. (try 2)

by Alexandre Julliard

Peter Urbanec <winehq.org(a)urbanec.net> writes: > Couple of reasons. First, a machine may or may not have an OpenCL > implementation installed and it may or may not have the required > hardware. That's not necessary, the dll will fail to load either way. > Second, I am anticipating that when wine OpenCL 1.1 support > is added, we'll need to determine whether the host is using OpenCL 1.0 > or 1.1, at runtime. How is that going to work? -- Alexandre Julliard julliard(a)winehq.org

Dec. 1, 2010

Re: [PATCH 2/2] opencl: Basic OpenCL 1.0 implementation. (try 2)

by Peter Urbanec

On 30/11/10 21:15, Alexandre Julliard wrote: > Why are you loading everything dynamically instead of simply linking > to it? > Couple of reasons. First, a machine may or may not have an OpenCL implementation installed and it may or may not have the required hardware. Second, I am anticipating that when wine OpenCL 1.1 support is added, we'll need to determine whether the host is using OpenCL 1.0 or 1.1, at runtime.

Dec. 1, 2010

Re: include: Fix error logic

by Alexandre Julliard

André Hentschel <nerv(a)dawncrow.de> writes: > The file is nearly always used with one of both, so "or" makes no sense. > Also if you have a look through tchar.h you see it catches all cases, > but not the case where both are defined It doesn't make any sense to define both. -- Alexandre Julliard julliard(a)winehq.org

Dec. 1, 2010

Re: Stopping Win9x testing

by Wolfram Sang

> I'll mark the Win9x VMs offline when there's nothing queued to run on them. > Then in a weeks time I can delete them after all jobs referring to them > have been retired/deleted (referential integrity in the database). That means they even won't be available then for some specific corner-case tests (in which they are selected manually)? Hmm, is there much overhead involved to keep them "just in case"? Regards, Wolfram

Dec. 1, 2010

Re: [PATCH 2/2] opencl: Basic OpenCL 1.0 implementation. (try 2)

by Roderick Colenbrander

It looks fine to me, but I'm worried whether it can work properly in the end. A few months ago I worked on Cuda support for something (I implemented nvcuda.dll which is what cuda runtime libraries like cudart or physx are using). Certain lowlevel nvcuda applications worked, but more fancy applications didn't. I had some contact with Nvidia about it and it was not possible to support Cuda without assistance on their side. OpenCL is a little different of course, but I fear that not all OpenCL implementations will like wrapping. What OpenCL applications have you tried so far? The Nvidia GPU Computing SDK (or whatever it was called) has a ton of samples for both Cuda and OpenCL. Do all their OpenCL samples work? Roderick On Mon, Nov 29, 2010 at 2:39 PM, Peter Urbanec <winehq.org(a)urbanec.net> wrote: > Resending because previous patch was mangled by Thunderbird. > > --- > dlls/opencl/opencl.c | 1142 > +++++++++++++++++++++++++++++++++++++++++++++++ > dlls/opencl/opencl.spec | 159 ++++--- > 2 files changed, 1232 insertions(+), 69 deletions(-) > > > > > >

Nov. 30, 2010