wine-devel January 2011

[email protected]

87 participants
238 discussions

Start a nNew thread

Re: [PATCH 2/2] mshtml: Added support for recursive script runners

by Marvin

13 years, 3 months

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?

13 years, 3 months

MapleStory Wine Bug

by Jack Edmonds

I recently submitted a bug (http://bugs.winehq.org/show_bug.cgi?id=25934). I'm not sure if I did a good job on the submission, but if I did, I was thinking it would be a good first bug to work on so as to introduce me to the Wine source code. I was wondering if someone could help me get started on it.

13 years, 3 months

Re: user32: Replicate Windows behavior of WM_SETTEXT handler regarding WM_CTLCOLOR*

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=8728 Your paranoid android. === WNT4WSSP6 (32 bit msg) === msg.c:5644: Test failed: SETTEXT on a button: 2: the msg 0x0135 was expected, but got msg 0x8000 instead msg.c:5644: Test failed: SETTEXT on a button: 3: the msg sequence is not complete: expected 8000 - actual 0000 msg.c:5644: Test failed: SETTEXT on a button: 2: the msg 0x0135 was expected, but got msg 0x8000 instead msg.c:5644: Test failed: SETTEXT on a button: 3: the msg sequence is not complete: expected 8000 - actual 0000 msg.c:5644: Test failed: SETTEXT on a button: 2: the msg 0x0138 was expected, but got msg 0x8000 instead msg.c:5644: Test failed: SETTEXT on a button: 3: the msg sequence is not complete: expected 8000 - actual 0000 msg.c:5644: Test failed: SETTEXT on a button: 2: the msg 0x0138 was expected, but got msg 0x8000 instead msg.c:5644: Test failed: SETTEXT on a button: 3: the msg sequence is not complete: expected 8000 - actual 0000 msg.c:5644: Test failed: SETTEXT on a button: 2: the msg 0x0138 was expected, but got msg 0x8000 instead msg.c:5644: Test failed: SETTEXT on a button: 3: the msg sequence is not complete: expected 8000 - actual 0000 msg.c:5644: Test failed: SETTEXT on a button: 2: the msg 0x0138 was expected, but got msg 0x8000 instead msg.c:5644: Test failed: SETTEXT on a button: 3: the msg sequence is not complete: expected 8000 - actual 0000 msg.c:5644: Test failed: SETTEXT on a button: 2: the msg 0x0138 was expected, but got msg 0x8000 instead msg.c:5644: Test failed: SETTEXT on a button: 3: the msg sequence is not complete: expected 8000 - actual 0000 msg.c:5644: Test failed: SETTEXT on a button: 2: the msg 0x0135 was expected, but got msg 0x0111 instead msg.c:5644: Test failed: SETTEXT on a button: 3: the msg 0x0111 was expected, but got msg 0x8000 instead msg.c:5644: Test failed: SETTEXT on a button: 4: the msg sequence is not complete: expected 8000 - actual 0000 msg.c:5644: Test failed: SETTEXT on a button: 2: the msg 0x0138 was expected, but got msg 0x8000 instead msg.c:5644: Test failed: SETTEXT on a button: 3: the msg sequence is not complete: expected 8000 - actual 0000 msg.c:5644: Test failed: SETTEXT on a button: 2: the msg 0x0135 was expected, but got msg 0x002b instead msg.c:5644: Test failed: SETTEXT on a button: 3: the msg 0x002b was expected, but got msg 0x8000 instead msg.c:5644: Test failed: SETTEXT on a button: 4: the msg sequence is not complete: expected 8000 - actual 0000 === W7PROX64 (64 bit msg) === Timeout

13 years, 3 months

Re: [PATCH 1/2] winecoreaudio: Don't use Component Manager on Mac OS 10.6.

by Charles Davis

On 1/29/11 6:40 PM, James McKenzie wrote: > Chip: > > I'm assuming that this has been checked on Tiger/Leopard and it works. I checked that it would work if the AudioComponent header weren't present (which it isn't pre-SL). > > I don't have a Leopard system here and I'm reluctant to try it on one of > the systems I have Tiger installed on (it is a PowerPC Mac.) I can't imagine why... :) Chip

13 years, 3 months

RE: shdocvw: Implement IWebBrowser::ExecWB and IWebBrowser::QueryStatusWB.

by Greg Geldorp

From: Greg Geldorp <ggeldorp(a)vmware.com> > From: Erich Hoover > > On Thu, Jan 27, 2011 at 3:53 AM, Greg Geldorp <ggeldorp(a)vmware.com> wrote: > > > ... > > > Looking at http://test.winehq.org/data/tests/shdocvw:webbrowser.html, > > > the shdocvw:webbrowser test doesn't have a history of occasional > > > crashes. There are a few failures, but none of them are due to access > > > violations. Which kind of indicates that the crash is because of the > > > changes you made. > > > I know it sucks to investigate failures that don't repro consistently, > > > but I do think some more testing would be good here. Of course, if > > > there's any info you need about the VM just let me know. > > > > Well, I commandeered a XP SP3 box this morning and ran that exact same > > set of tests successfully 10,000 times. I don't have access to a Win7 > > box or I would have run the tests on that. Thoughts? > > I'll do a similar test on Win7 tomorrow and let you know the results. I started by running your test binary 10,000 times on W7PROX64. Not a single crash, so that looked kind of promising. Just to be sure, I then ran the binary on a dual-core Win7 x64 machine (the W7PROX64 VM has only one core assigned to it). This resulted in an immediate crash. Tried a few more times, it crashed 9 out of 10 times. To make sure that these crashes are related to your patch, I ran the test without your patch on the same dual-core machine. First few tries didn't produce crashes, I then ran it in a loop 10,000 times. Not a single crash. So, it looks like your patch introduces some multi-threading issue. I haven't investigated further, perhaps I'll have some time over the weekend to dig a bit deeper. Greg.

13 years, 3 months

Re: winex11.drv: When copying window bits exclude an update region only if the parent doesn't clip its children.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)codeweavers.com> writes: > @@ -1624,7 +1624,8 @@ static void move_window_bits( struct x11drv_win_data *data, const RECT *old_rect > hdc_src = hdc_dst = GetDCEx( data->hwnd, 0, DCX_CACHE ); > } > > - ExcludeUpdateRgn( hdc_dst, data->hwnd ); > + if (!parent || !(GetWindowLongW( parent, GWL_STYLE ) & WS_CLIPCHILDREN)) > + ExcludeUpdateRgn( hdc_dst, data->hwnd ); I don't see what the parent clipping has to do with this. Could you please explain? -- Alexandre Julliard julliard(a)winehq.org

13 years, 3 months

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

by Reece Dunn

=== Observations === 1/ The dsound:ds3d tests fail when using the ALSA audio driver on 64-bit (K)Ubuntu, but succeed with the OSS audio driver. 2/ The mmdevapi tests fail with a "Device not found"/"No driver" error (hr = 0x88780078) when running with the OSS driver. For the mmdevapi failures, the tests should skip when intercepting a "Device not found" error. === 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. 5/ Open winecfg -- `./wine winecfg` 6/ Select the Audio tab This should being up a message to recommend a driver (as no driver is set in the registry) and then select the ALSA driver. 7/ Switch the audio driver from ALSA to OSS and press OK. 8/ Re-run the tests -- `make test` This passes the ds3d tests, but fails with: ../../../tools/runtest -q -P wine -M mmdevapi.dll -T ../../.. -p mmdevapi_test.exe.so dependency.c && touch dependency.ok err:quartz:DSoundRender_create Cannot create Direct Sound object (88780078) fixme:ole:CoCreateInstance no instance created for interface {56a86895-0ad4-11ce-b03a-0020af0ba770} of class {79376820-07d0-11cf-a24d-0020afd79767}, hres is 0x88780078 dependency.c:85: Test failed: Activating bf failed: 0x88780078 9/ Open winecfg -- `./wine winecfg` 10/ Switch the audio driver from OSS back to ALSA and press OK. 11/ Re-run the tests -- `make test` The mmdevapi tests now pass. - Reece

13 years, 3 months

Re: Alexander Scott-Johns : ole32: Add support for rendering METAFILEPICT clipboard objects.

by Nikolay Sivov

On 1/28/2011 21:30, Alexandre Julliard wrote: > Module: wine > Branch: master > Commit: 0f4fbd30f6bf3d2ef471d3d75307c7fa8a7df137 > URL: http://source.winehq.org/git/wine.git/?a=commit;h=0f4fbd30f6bf3d2ef471d3d75… > > Author: Alexander Scott-Johns<alexander.scott.johns(a)googlemail.com> > Date: Tue Jan 25 15:09:21 2011 +0000 > > ole32: Add support for rendering METAFILEPICT clipboard objects. > > --- > dlls/ole32/clipboard.c | 97 +++++++++++++++++++++++++++++++++++++++++++++++- > 1 files changed, 96 insertions(+), 1 deletions(-) > > +/*************************************************************************** > + * get_data_from_metafilepict > + */ > +static HRESULT get_data_from_metafilepict(IDataObject *data, FORMATETC *fmt, HGLOBAL *mem) > +{ > + HGLOBAL copy; > + HRESULT hr; > + FORMATETC mem_fmt; > + STGMEDIUM med; > + > + *mem = NULL; > + > + mem_fmt = *fmt; > + mem_fmt.tymed = TYMED_MFPICT; > + > + hr = IDataObject_GetData(data,&mem_fmt,&med); > + if(FAILED(hr)) return hr; > + > + hr = dup_metafilepict(med.u.hMetaFilePict,&copy); > + if(FAILED(hr)) return hr; 'med' should be released here on failure. > + > + *mem = copy; > + > + ReleaseStgMedium(&med); > + > + return hr; > +} > + > /***********************************************************************

13 years, 3 months

Re: [PATCH 4/4] [Kernel32]: add ability to load additional terminfo data from Wine registry

by Eric Pouech

Le 19/01/2011 13:07, Alexandre Julliard a écrit : > Eric Pouech<eric.pouech(a)orange.fr> writes: > >> you mean hardwiring the missing keys (potentially different according to >> terminal type) in the code? > If they depend on terminal type they belong in terminfo, not in the > registry. > as I said, terminfo is not fully populated it misses lots of ctrl-<key> (left arrow, right arrow...) and has not been updated lately most of the common text editors come with their own config files for example, /etc/inputrc has the missing bindings for libreadline (and of course it depends on $TERM) so, updating terminfo isn't the solution would you consider inclusion in hklm (instead of hkcu) ? A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

13 years, 3 months

← Newer
1
2
3
4
5
6
7
...
24
Older →

Jump to page:

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 January 2011