February 2013 - Wine-Devel - list.winehq.org

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

Feb. 13, 2013

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 Feb. 13, 2013

Feb. 13, 2013

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 Feb. 13, 2013

Feb. 13, 2013

"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 Feb. 13, 2013

Feb. 13, 2013

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 Feb. 13, 2013

Feb. 13, 2013

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=24381 Your paranoid android. === WNT4WSSP6 (32 bit install) === install.c:5673: Test failed: Per-user icon file isn't where it's expected (C:\WINNT\Profiles\Default User\Application Data\Microsoft\Installer\{7DF88A49-996F-4EC8-A022-BF956F9B2CBB}\testicon)

1 0

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

Feb. 13, 2013

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 Feb. 12, 2013

Feb. 12, 2013

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 Feb. 12, 2013

Feb. 12, 2013

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 Feb. 12, 2013

Feb. 12, 2013

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 Feb. 12, 2013

Feb. 12, 2013

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=24350 Your paranoid android. === WINEBUILD (build) === Can't determine base name

1 0