wine-devel February 2013

wine-devel@winehq.org

62 participants
126 discussions

Where to put Chinese translation of the Wine user guide?
by Jactry Zeng 14 Feb '13

14 Feb '13

Hi folks, A Chinese Wine user Liu Hongcong had translated [1] the Wine user guide [2] to Chinese three years ago, the translation looks mostly good to me. It is a pity to leave his translation outside of the official wine website. With his consent, I want to put his translation to winehq. But I can't find where to add it into in website's source [3]. Or I should add it into wiki? Thanks for any comment! [1] http://blog.csdn.net/hongmy525/article/details/2238600 [2] http://www.winehq.org/docs/wineusr-guide/index [3] http://source.winehq.org/git/website.git/

2 2

Re: [3/4] gdi32: IntersectClipRect should update actual clipping region for a EMF DC.
by Marvin 14 Feb '13

14 Feb '13

1 0

Re: [2/4] gdi32: OffsetClipRgn should update actual clipping region for a EMF DC.
by Marvin 14 Feb '13

14 Feb '13

1 0

Re: [1/4] gdi32: Add more EMF clipping tests.
by Marvin 14 Feb '13

14 Feb '13

1 0

Re: [PATCH] dsound: copy program parameters in SetFormat
by Andrew Eikum 13 Feb '13

13 Feb '13

On Mon, Feb 11, 2013 at 02:06:42PM +0100, Maarten Lankhorst wrote: > Fixes bug #32312, apparently some programs depend on the format it specifies being returned. > > Just set wBitsPerSample, nSamplesPerSec and nChannels to make those applications happy. > The patch seems fine, but can you add some tests for this so we can nail down exactly what we should be taking from the SetFormat format? E.g. should we just do "device->primary_fmt = CopyFormat(passed_fmt)" in all cases, or can you find a case where the GetFormat() result is changed? FYI, your patch applies with an offset and the Wine patch tracker didn't like this: > --- a/dlls/dsound/primary.c > +++ a/dlls/dsound/primary.c but git-am imported the raw mail file just fine. Andrew

1 0

Re: winmm: More compatible waveIn/Out[Un]Prepare WHDR_* flag handling.
by Andrew Eikum 13 Feb '13

13 Feb '13

These two patches look fine to me. Thanks! On Mon, Feb 11, 2013 at 01:28:09PM +0100, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Hi, > > This completes my winmm Prepare Header changes on the wave side. > > XyzPrepare: > + header->dwFlags &= ~(WHDR_DONE|WHDR_INQUEUE); /* flags cleared since w2k */ > > I choose to implement the behavior since w2k. Hopefully this will not break some w9x app. > > > WINMM_UnprepareHeader: > - header->dwFlags |= WHDR_DONE; > Never ever observed. Neither w95 nor xp or w7. > Perhaps MS would have been wise to do so, as simply looking at a header you cannot > tell whether it's been processed or not (returned with error code). > I choose to implement compatible behaviour. > > > - if(!(lpWaveInHdr->dwFlags & WHDR_PREPARED)) > - return MMSYSERR_NOERROR; > if(lpWaveInHdr->dwFlags & WHDR_INQUEUE) > return WAVERR_STILLPLAYING; > + if(!(lpWaveInHdr->dwFlags & WHDR_PREPARED)) > + return MMSYSERR_NOERROR; > Note the subtle difference in behaviour between wave and midi headers... > > > >IMHO calling named winmm:xyz functions should be equivalent to dispatching MM* messages > > I forgot to add that I'm still surprised that Andrew Eikum could reimplement > waveIn/OutMessage *without* using MMDRV_Message by simply returning MMSYSERR_NOTSUPPORTED. > > Either all apps use the named winmm:waveIn/OutXyz functions instead of calling waveOutMessage() > or nobody bothered to complain that some apps (perhaps w3.1 ones?) lack sound. > > That area obviously needs some testing... > > Regards, > Jörg Höhle

1 0

Re: kernel32: Indicate that HeapValidate called by GlobalHandle is not the sign of heap corruption.
by Alexandre Julliard 13 Feb '13

13 Feb '13

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > This helps to distinguish this one from real signs of heap corruption, > and saves quite a bit of effort analysing +heap or warn+heap logs. Avoiding HeapValidate would probably be a better approach. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: advapi32: Report world-access ownership by default for registry objects (try 2).
by Alexandre Julliard 13 Feb '13

13 Feb '13

"Erich E. Hoover" <ehoover(a)mymail.mines.edu> writes: > The attached patch fixes an issue where the Opera installer expects > registry keys to return ownership information (Bug #32904), concluding > the cleanup of [Get|Set]NamedSecurityInfo. This patch addresses the > issue by ensuring that NULL owner and group information is never > returned for registry keys and instead returns the World SID (S-1-1-0) > when this information is unavailable, which is sufficient to keep the > Opera installer from encountering an error. The included test shows > that this behavior is essentially the case for system keys on Windows, > though the Administrators SID is returned instead. Since > GetNamedSecurityInfo historically returned the World SID, and several > other routines use it as well) I've opted to use the World SID for > now. We should do the same as Windows unless there's a very good reason to be different. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] netstat: Clarify labels in UDP statistics.
by Frédéric Delanoy 13 Feb '13

13 Feb '13

On Sat, Feb 9, 2013 at 1:03 PM, Lauri Kenttä <lauri.kentta(a)gmail.com> wrote: > Change labels in UDP statistics so that they better reflect the actual meanings as described in MSDN [1]. > > [1] http://msdn.microsoft.com/en-us/library/windows/desktop/aa366929%28v=vs.85%… > --- > - IDS_UDP_NO_PORTS, "No Ports" > - IDS_UDP_RECV_ERRORS, "Receive Errors" > + IDS_UDP_NO_PORTS, "Invalid Port Errors" > + IDS_UDP_RECV_ERRORS, "Invalid Datagrams" > IDS_UDP_DGRAMS_SENT, "Datagrams Sent" "Invalid Datagrams" is too vague. It could mean datagrams sent or received. If you want to disambiguate/explain, use message contexts as explained in http://wiki.winehq.org/Translating Frédéric

2 3

Re: msi/tests: Move a couple of tests from install.c to msi.c.
by Marvin 13 Feb '13

13 Feb '13

1 0

Re: gdi32: Make sure that actual clipping region is updated for a EMF DC.
by Alexandre Julliard 13 Feb '13

13 Feb '13

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > This patch not only fixes a todo_wine in the tests, but also makes print > preview and printing work in a pretty large application. You would most likely have to do that for all the clipping functions then. -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: d3dx9: Implement D3DXSHEvalConeLight
by Matteo Bruni 12 Feb '13

12 Feb '13

Hi, in addition to what I already told you in #winehackers (that is, please rename the test struct field red_in to red_out and red_out to red_expected, or something like that), you should take the chance to do some more cleanup. That means e.g. use "const" instead of "CONST" as Rico already suggested and fix the indentation of the last comment you're adding. There are a few other things I don't really like but it's about code style and my personal preferences, so you are free to ignore them. I'd write the test structure declaration as: struct { float *red_out, *green_out, *blue_out; const float *red_expected, *green_expected, *blue_expected; float radius, red_offset, green_offset, blue_offset; } test[] = { {rout, gout, bout, table, &table[72], &table[144], 0.5f, 1.01f, 1.02f, 1.03f}, ... (I'm sure Gmail will wrap and make this piece of code unreadable, but well...) In general I'd also avoid using caps in variable names (e.g. r_intensity instead of Rintensity).

1 0

Re: [PATCH 2/4] urlmon: Fixed QueryInfo tests during BINDSTATUS_PROXYDETECTING notification
by Marvin 12 Feb '13

12 Feb '13

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=24361 Your paranoid android. === WVISTAADM (32 bit url) === url.c:1868: Test failed: binding failed: 800c0005, expected 00000000 url.c:1879: Test failed: res = 00002ee7, expected 00000000 url.c:3035: Test failed: IMoniker_BindToStorage failed: 800c0005 url.c:3036: Test failed: unk == NULL url.c:1868: Test failed: binding failed: 800c0005, expected 00000000 url.c:1879: Test failed: res = 00002ee7, expected 00000000 url.c:3035: Test failed: IMoniker_BindToStorage failed: 800c0005 url.c:3036: Test failed: unk == NULL url.c:1658: Test failed: unexpected call Obj_OnProgress_FINDINGRESOURCE url.c:1868: Test failed: binding failed: 800c0005, expected 00000000 url.c:1879: Test failed: res = 00002ee7, expected 00000000 url.c:1662: Test failed: unexpected call OnProgress_FINDINGRESOURCE url.c:1868: Test failed: binding failed: 800c0005, expected 00000000 url.c:1879: Test failed: res = 00002ee7, expected 00000000 url.c:3035: Test failed: IMoniker_BindToStorage failed: 800c0005 url.c:3036: Test failed: unk == NULL url.c:1868: Test failed: binding failed: 800c0005, expected 800c0019 url.c:1879: Test failed: res = 00002efd, expected 800c0019 url.c:3024: Test failed: Got 800c0005 url.c:3119: Test failed: expected QueryInterface_IHttpSecurity url.c:3120: Test failed: expected QueryService_IHttpSecurity url.c:3121: Test failed: expected OnSecurityProblem url.c:1662: Test failed: unexpected call OnProgress_FINDINGRESOURCE url.c:1868: Test failed: binding failed: 800c0005, expected 800c0019 url.c:1879: Test failed: res = 00002efd, expected 800c0019 url.c:3024: Test failed: Got 800c0005 url.c:3119: Test failed: expected QueryInterface_IHttpSecurity url.c:3120: Test failed: expected QueryService_IHttpSecurity url.c:3121: Test failed: expected OnSecurityProblem url.c:1662: Test failed: unexpected call OnProgress_FINDINGRESOURCE url.c:1868: Test failed: binding failed: 800c0005, expected 00000000 url.c:1879: Test failed: res = 00002efd, expected 00000000 url.c:3035: Test failed: IMoniker_BindToStorage failed: 800c0005 url.c:3036: Test failed: unk == NULL url.c:3119: Test failed: expected QueryInterface_IHttpSecurity url.c:3120: Test failed: expected QueryService_IHttpSecurity url.c:3121: Test failed: expected OnSecurityProblem url.c:3139: Test failed: expected OnResponse url.c:3143: Test failed: expected OnProgress_MIMETYPEAVAILABLE url.c:3144: Test failed: expected OnProgress_BEGINDOWNLOADDATA url.c:3145: Test failed: expected OnProgress_ENDDOWNLOADDATA url.c:3153: Test failed: expected OnDataAvailable url.c:1662: Test failed: unexpected call OnProgress_FINDINGRESOURCE url.c:1868: Test failed: binding failed: 800c0005, expected 00000000 url.c:1879: Test failed: res = 00002efd, expected 00000000 url.c:3027: Test failed: IMoniker_BindToStorage failed: 800c0005 url.c:3028: Test failed: unk == NULL url.c:3030: Test failed: Expected security problem to be ignored. url.c:3119: Test failed: expected QueryInterface_IHttpSecurity url.c:3120: Test failed: expected QueryService_IHttpSecurity url.c:3121: Test failed: expected OnSecurityProblem url.c:1662: Test failed: unexpected call OnProgress_FINDINGRESOURCE url.c:1868: Test failed: binding failed: 800c0005, expected 00000000 url.c:1879: Test failed: res = 00002ee7, expected 00000000 url.c:3133: Test failed: expected OnProgress_SENDINGREQUEST url.c:3139: Test failed: expected OnResponse url.c:3143: Test failed: expected OnProgress_MIMETYPEAVAILABLE url.c:3144: Test failed: expected OnProgress_BEGINDOWNLOADDATA url.c:3145: Test failed: expected OnProgress_ENDDOWNLOADDATA url.c:3157: Test failed: expected OnDataAvailable url.c:1662: Test failed: unexpected call OnProgress_FINDINGRESOURCE url.c:1868: Test failed: binding failed: 800c0005, expected 00000000 url.c:1879: Test failed: res = 00002ee7, expected 00000000 url.c:3133: Test failed: expected OnProgress_SENDINGREQUEST url.c:3139: Test failed: expected OnResponse url.c:3143: Test failed: expected OnProgress_MIMETYPEAVAILABLE url.c:3144: Test failed: expected OnProgress_BEGINDOWNLOADDATA url.c:3145: Test failed: expected OnProgress_ENDDOWNLOADDATA url.c:3157: Test failed: expected OnDataAvailable url.c:1658: Test failed: unexpected call Obj_OnProgress_FINDINGRESOURCE url.c:1868: Test failed: binding failed: 800c0005, expected 00000000 url.c:1879: Test failed: res = 00002ee7, expected 00000000 url.c:3353: Test failed: expected Obj_OnProgress_SENDINGREQUEST url.c:3357: Test failed: expected OnResponse url.c:3359: Test failed: expected Obj_OnProgress_MIMETYPEAVAILABLE url.c:3360: Test failed: expected Obj_OnProgress_BEGINDOWNLOADDATA url.c:3366: Test failed: expected Obj_OnProgress_CLASSIDAVAILABLE url.c:3367: Test failed: expected Obj_OnProgress_BEGINSYNCOPERATION url.c:3368: Test failed: expected Obj_OnProgress_ENDSYNCOPERATION url.c:3369: Test failed: expected OnObjectAvailable url.c:1662: Test failed: unexpected call OnProgress_FINDINGRESOURCE url.c:1868: Test failed: binding failed: 800c0005, expected 00000000 url.c:1879: Test failed: res = 00002ee7, expected 00000000 url.c:3133: Test failed: expected OnProgress_SENDINGREQUEST url.c:3139: Test failed: expected OnResponse url.c:3143: Test failed: expected OnProgress_MIMETYPEAVAILABLE url.c:3144: Test failed: expected OnProgress_BEGINDOWNLOADDATA url.c:3145: Test failed: expected OnProgress_ENDDOWNLOADDATA url.c:3157: Test failed: expected OnDataAvailable url.c:1658: Test failed: unexpected call Obj_OnProgress_FINDINGRESOURCE Timeout

2 1

winealsa: Have the MIDI recorder wait in poll(), not snd_seq_event_input().
by Joerg-Cyril.Hoehle＠t-systems.com 12 Feb '13

12 Feb '13

Johannes Kroll asked: >Did this patch get through? I don't see it on >http://source.winehq.org/patches/ ... It did. You looked too late in patches/. Committed patches are deleted sooner than rejected ones that are in turn deleted sooner than new/pending patches. I'm still interested in your testing my other MIDI patches. I fact I have a queue of half a dozen patches ready for submission, except that I'd like somebody to test them with real MIDI HW. There's another patch yet to be written: midiOutLongMessage CAN be used for coalesced non-sysex messages. This affects winealsa. Wineoss needs no change, because it simply dumps the bytes, one by one, regardless of SysEx or standard message. ALSA needs different API functions to be used. I've yet to check MacOSX CoreMIDI. Regards, Jörg Höhle

2 1

Re: winspool.drv: There is no need to speculate about wineps.drv default DEVMODE.
by Marvin 12 Feb '13

12 Feb '13

1 0

Re: make_xftmpl: Explicitly use signed char when appropriate
by Alexandre Julliard 11 Feb '13

11 Feb '13

André Hentschel <nerv(a)dawncrow.de> writes: > For platforms where char is expected to be unsigned (e.g. it fixes a warning on ARM) There's no reason to make it signed. Please fix the bug correctly instead. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: windowscodecsext: Implement WICCreateColorTransform_Proxy and IWICColorTransform_Initialize_Proxy.
by Vincent Povirk 11 Feb '13

11 Feb '13

OK, I'm about to say something weird, and I'll understand if everyone else decides to ignore it. I don't think WICCreateColorTransform_Proxy, or any of the Proxy functions, should initialize or make use of COM. Instead, I think it should work by calling WICCreateImagingFactory_Proxy. I suspect that part of the purpose of the _Proxy functions is to make it possible to use WIC without needing COM at all, which is something we may want in the future if we want to use it from user32. (Another consequence of this is that we should be able to create instances of builtin decoders/encoders without COM, which we currently can't do. But I'd have to write a test for that, and currently there's been no demonstrated need for it.)

1 0

Re: winealsa: Have the MIDI recorder wait in poll(), not snd_seq_event_input().
by Johannes Kroll 11 Feb '13

11 Feb '13

On Thu, 24 Jan 2013 10:33:58 +0100 <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > Compare with wineoss which uses poll <= 0 already... > > Johannes Kroll mentioned that MIDIIn takes a long time to end. > Indeed, our testsuite ran 3 times into the "kill after 5s" timeout due to this bug. > Now the tests execute much faster. > > Regards, > Jörg höhle Did this patch get through? I don't see it on http://source.winehq.org/patches/ ...

1 0

Re: windowscodecsext: Implement WICCreateColorTransform_Proxy and IWICColorTransform_Initialize_Proxy.
by Marvin 11 Feb '13

11 Feb '13

1 0

Re: winspool.drv: Fallback to cupsGetPPD if cupsGetPPD3 is missing or failed.
by Huw Davies 11 Feb '13

11 Feb '13

On Mon, Feb 11, 2013 at 02:03:26PM +0800, Dmitry Timoshkov wrote: > - if (pcupsGetPPD3) return pcupsGetPPD3( http, name, modtime, buffer, bufsize ); > + if (pcupsGetPPD3) > + { > + http_status_t status; > + > + TRACE( "Calling cupsGetPPD3\n" ); > + status = pcupsGetPPD3( http, name, modtime, buffer, bufsize ); > + if (status == HTTP_OK) return HTTP_OK; > + TRACE("cupsGetPPD3 failed (status %d)\n", status); > + } > Under what conditions does cupsGetPPD succeed if cupsGetPPD3 fails? Huw.

2 2

Re: [2/2] xmllite: Basic test for chunk value read vs full value read
by Marvin 11 Feb '13

11 Feb '13

1 0

Debugging and steam
by Gediminas Jakutis 11 Feb '13

11 Feb '13

Good day! Does anyone has any experience on dealing with Steam when debugging a game which depends on Steam? I am trying to squash a bug which makes a game crash. I started from relay logs, but have a bit of a problem - calls from Steam itself produce a few megabytes worth of relay logs every second. Those get mixed together with calls originating from the game. Also, it appears the game takes a couple of seconds after that "bad" call before crashing. When it is mixed together with Steam's own spam, it is a nightmare finding where it went wrong. I tried every idea I could muster on how to get a "pure" log of the game. Not a single one turned out to be effective. I am all out of ideas now. So if anyone had to deal with this and found a satisfactory solution, please enlighten me. Thank You in advance! -- Gediminas Jakutis LDK Varčiai www.varciai.lt

2 1

Re: comctl32/listview: fix LVM_SETICONSPACING on 64bit machines
by Marvin 09 Feb '13

09 Feb '13

1 0

Re: ole32/tests: Add test for IDispatch interface in IOleObject_QueryInterface.
by Alistair Leslie-Hughes 09 Feb '13

09 Feb '13

On 9/02/2013 2:08 AM, Roman Dadkov wrote: > This test is necessary to show that the function > IOleObject_QueryInterface does not have enough processing IID_IDispatch, > but it works for Windose. Therefore, the creation of some objects in a > variety of applications leads to crash. > + hr = IOleObject_QueryInterface(ole_obj, &IID_IDispatch, (void**)&dispatch); > + todo_wine > + ok(hr == S_OK, "got %08x\n", hr); > The IDispatch Interface should be released. Best Regards Alistair Leslie-Hughes

1 0

Re: ole32/tests: Add test for IDispatch interface in IOleObject_QueryInterface.
by Dmitry Timoshkov 09 Feb '13

09 Feb '13

Roman Dadkov <romand(a)etersoft.ru> wrote: > + const CLSID non_existent_class = {0xa5f1772f, 0x3772, 0x490f, {0x9e, 0xc6, 0x77, 0x13, 0xe8, 0xb3, 0x4b, 0x5d}}; Probably it would be a good idea to try make CLSID really unique and bad enough that it's unlikely that somebody uses it for real. Something like 0xdeadbeef,0xde,0xad,0xbe,0xef,... -- Dmitry.

1 0

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 February 2013