January 2011 - Wine-Devel - list.winehq.org

Re: FYI: OpenCL/opencl.h from NVIDIA...

by Peter Urbanec

On 21/01/11 13:21, James McKenzie wrote: > As far as I knew from information I gathered here, the only OS that > supports OpenCL was MacOSX. Sorry for the misleading information. I developed wine OpenCL support under Gentoo, using the Gentoo provided NVidia drivers and NVidia CUDA packages. I'm not sure if anyone got it working on OSX. You should be able to: 1. Install the NVidia drivers 2. Install NVidia CUDA/OpenCL SDK 3. Make a link /usr/include/CL -> /opt/cuda/include/CL (or wherever you installed the SDK) After that, configure should find OpenCL and use it. If you want RPMs or other distro specific packages, hassle your distribution maintainers. (Or switch to Gentoo ;-) Both AMD and Intel also have OpenCL implementations/SDKs available. Their distro support varies. Best regards, Peter Urbanec

Jan. 28, 2011

Wine Source Study

by Pankaj Swami

Please help me..... I am last year Computer Engineering student & I want to study wine source code but I'm unable to decide from where to start studying wine source code.........? I have wine source code.

Jan. 28, 2011

Re: Another milestone

by Saulius Krasuckas

* On Thu, 27 Jan 2011, Greg Geldorp wrote: > > Today we had a clean winetest.exe run on all 31 TestBot VMs for the > first time. Although there are still failures on other test machines and > some tests fail occasionally on TestBot, I still think this is a > significant milestone. Congrats to all! And thanks :) > Hopefully the "Wine" column on http://test.winehq.org/data/ will soon > start to show some yellow spots too! I'm waiting years for this (since probably 2004:) My thanks go to all the developers and testers. S.

Jan. 28, 2011

Re: Ubuntu 10.04 x86-64 test failures -- dsound:ds3d and mmdevapi

by Reece Dunn

On 28 January 2011 01:44, Scott Ritchie <scott(a)open-vote.org> wrote: > On 01/27/2011 02:20 PM, Reece Dunn wrote: >> === Steps to Reproduce === >> >> Machine: Ubuntu 10.04 64-bit with NVidia binary drivers. >> >> 1/ Build the latest version of wine with no special options -- >> `./configure && make` >> 2/ Remove any previously run test result -- `find . -type f | grep >> .ok | xargs rm` >> 3/ Ensure running in a clean wine prefix -- `rm -rf ~/.wine` >> 4/ Run the tests -- `make test` >> >> This will download the gecko package and then fail in the dsound:ds3d >> tests with: >> >> ds3d.c:467: Test failed: buffer size changed after SetFormat() >> - previous size was 88200, current size is 22052 >> >> This error seems to be specific to 64-bit versions of the Ubuntu >> family, looking at the http://test.winehq.org/data/ results. >> > > Is this with the ia32-libs from the Wine PPA? $ dpkg -s ia32-libs Package: ia32-libs Status: install ok installed Priority: extra Section: libs Installed-Size: 143224 Maintainer: Ubuntu Developers <ubuntu-devel-discuss(a)lists.ubuntu.com> Architecture: amd64 Version: 20090808ubuntu9 I am not using wine from the PPA, I am building it from git myself. - Reece

Jan. 28, 2011

Policy regarding 3rd party "windows" distributions and winetest

by Dan Kegel

I suspect that we should discourage people from submitting winetest results from 3rd party repackagings of Microsoft Windows, e.g. http://thepiratebay.org/torrent/4254053/MicroXP_v0.82_-_eXPerience Agreed?

Jan. 28, 2011

Re: Ubuntu 10.04 x86-64 test failures -- dsound:ds3d and mmdevapi

by Austin English

On Thu, Jan 27, 2011 at 17:44, Scott Ritchie <scott(a)open-vote.org> wrote: > On 01/27/2011 02:20 PM, Reece Dunn wrote: >> === Steps to Reproduce === >> >> Machine: Ubuntu 10.04 64-bit with NVidia binary drivers. >> >> 1/ Build the latest version of wine with no special options -- >> `./configure && make` >> 2/ Remove any previously run test result -- `find . -type f | grep >> .ok | xargs rm` >> 3/ Ensure running in a clean wine prefix -- `rm -rf ~/.wine` >> 4/ Run the tests -- `make test` >> >> This will download the gecko package and then fail in the dsound:ds3d >> tests with: >> >> ds3d.c:467: Test failed: buffer size changed after SetFormat() >> - previous size was 88200, current size is 22052 >> >> This error seems to be specific to 64-bit versions of the Ubuntu >> family, looking at the http://test.winehq.org/data/ results. >> > > Is this with the ia32-libs from the Wine PPA? > > Is 10.10 unaffected? 10.04 and 10.04 are both affected, the dsound tests fail with pulseaudio installed, see http://bugs.winehq.org/show_bug.cgi?id=20604 -- -Austin

Jan. 28, 2011

Re: Ubuntu 10.04 x86-64 test failures -- dsound:ds3d and mmdevapi

by Scott Ritchie

On 01/27/2011 02:20 PM, Reece Dunn wrote: > === Steps to Reproduce === > > Machine: Ubuntu 10.04 64-bit with NVidia binary drivers. > > 1/ Build the latest version of wine with no special options -- > `./configure && make` > 2/ Remove any previously run test result -- `find . -type f | grep > .ok | xargs rm` > 3/ Ensure running in a clean wine prefix -- `rm -rf ~/.wine` > 4/ Run the tests -- `make test` > > This will download the gecko package and then fail in the dsound:ds3d > tests with: > > ds3d.c:467: Test failed: buffer size changed after SetFormat() > - previous size was 88200, current size is 22052 > > This error seems to be specific to 64-bit versions of the Ubuntu > family, looking at the http://test.winehq.org/data/ results. > Is this with the ia32-libs from the Wine PPA? Is 10.10 unaffected? Thanks, Scott Ritchie

Jan. 28, 2011

RFC: Adding Mac support to secur32/schannel.c

by Ken Thomases

Hi, I'm planning to add an alternative implementation of schannel (SSL/TLS) support for the Mac. The current implementation is based on GnuTLS. That library is not typically found on Mac OS X. Although packagers can build it and ship it and its dependencies with Wine for Mac OS X, I think it's better (especially for security-related functionality) to use the system-provided library. I'm attaching a patch. It is _not_ intended as a proposed commit. It's just a proof-of-concept that shows the direction that I'm going. I plan to introduce a new internal interface (the schan_imp_* stuff in my patch) and incrementally refactor the code to hide uses of GnuTLS behind that interface. Then, I'm thinking of breaking the GnuTLS implementation out into a separate module, schannel_gnutls.c. Then, I'd add a second implementation module, schannel_mac.c, based on the Mac Secure Transport API (as shown in the patch). Each of the two modules would be made "empty" by preprocessor conditionals, as appropriate. I'd appreciate a review of this general plan. Thanks, Ken

Jan. 28, 2011

Re: msvcrt: Forward _realloc_crt to realloc

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=8669 Your paranoid android. === WVISTAADM (32 bit msvcr90) === msvcr90: unhandled exception c0000005 at 77497580 === W2K8SE (32 bit msvcr90) === msvcr90: unhandled exception c0000005 at 778A814C === W7PRO (32 bit msvcr90) === msvcr90: unhandled exception c0000005 at 772D2B79 === W7PROX64 (32 bit msvcr90) === msvcr90: unhandled exception c0000005 at 77E03100 === W7PROX64 (64 bit msvcr90) === No test summary line found

Jan. 27, 2011

Re: [4/4] gdi32: Move common code into helper function.

by Nikolay Sivov

On 1/27/2011 12:23, Kusanagi Kouichi wrote: > On 2011-01-26 19:28:29 +0300, Nikolay Sivov wrote: >> On 1/26/2011 19:09, Kusanagi Kouichi wrote: >>> -static LPSTR FONT_GetCharsByRangeA(HDC hdc, UINT firstChar, UINT lastChar, PINT pByteLen) >>> +static LPWSTR FONT_GetCharsByRangeA(HDC hdc, UINT firstChar, UINT lastChar, PINT pLen) >>> { >> It's better to change naming too, since it's won't return char >> string anymore. > What name do you think is better? > Is FONT_GetCharsByRange or FONT_GetCharsByRangeAToW OK? I think FONT_GetCharsByRangeW would be fine. Note that I don't know this code, and probably it should be done another way to avoid conversion in a first place (if possible at all).

Jan. 27, 2011