- wine-devel - winehq.org

Fwd: Google Summer of Code 2012 DEADLINE: 2012-02-27
by Jeremy White 12 Feb '12

12 Feb '12

Hi Folks, It's that time of year again - summer of code is going to start up soon. Maarten, you've been coordinating things for us for a while now - are you still game? Would you like help? Anyone else willing to volunteer to help admin the process? Cheers, Jeremy --- Conservancy Projects, I want to draw your attention to the fact that Google's Summer of Code program for 2012 is now accepting applications. Carol Smith wrote at 11:43 (EST) on Saturday: > We're pleased to announce that Google Summer of Code will be happening > for its eighth year this year: > > [1] - http://google-opensource.blogspot.com/2012/02/google-summer-of-code-2012-is… > [2] - http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc20… > [3] - http://www.google-melange.com/gsoc/events/google/gsoc2012 In particular, take a look at [3], which has the calendar for the SoC 2012 program.

6 7

Re: [PATCH 4/7] kernel32/tests: initial tests for cdrom.c (try 2)
by Charles Davis 10 Feb '12

10 Feb '12

On Feb 10, 2012, at 1:30 PM, Dan Kegel wrote: > +START_TEST(cdrom) > +{ [...] > + /* GENERIC_WRITE because without it, passthrough doesn't work on win7 */ But with it, you can't open the device at all on Mac. As I explained on bug 29669, the device file only has 0440 access. Chip

1 0

The audio GetPosition dilemma (long)
by Joerg-Cyril.Hoehle＠t-systems.com 10 Feb '12

10 Feb '12

Hi, mmdevapi's GetPosition returns "the stream position of the sample that is currently playing through the speakers", says MSDN. This is exactly what apps ought to use that want to synchronize audio & video (lip synchronisation). MSDN's wording about winmm's GetPosition is not exactly the same: "the current playback position of the given waveform-audio output device." However there's no other winmm function that could be used for lip-sync. Tests in winmm/tests/wave.c tend to show that WHDR_DONE notifications are only received after a position corresponding to the written number of bytes has been reached -- IOW the buffer has been played. Now look at winmm's PlaySound and mciwave code: /* make it so that 3 buffers per second are needed */ Both then proceed to play ping pong with two 1/3 second buffers. Every time WHDR_DONE is received, one of the two is empty, refilled and resubmitted using waveOutWrite. Now consider a system such as PulseAudio that wants to buffer 2 seconds of an audio stream internally. That scheme will fail completely. - If WHDR_DONE is based on GetPosition, notifications will only be sent after 2 seconds or an underrun. Neither PlaySound nor MCIWAVE buffer 2 seconds. They continuously hit an underrun as PA signals that it drained the tiny 40ms ALSA buffer we supplied. Is that PlaySound's fault? - If WHDR_DONE is instead based on buffer usage, it could be sent following snd_pcm_write and let PA buffer as much as it wants. But then our wave tests fail if GetPosition returns something like the position currently playing through the speakers, which is 2s late. Should we have GetPosition lie? And suffer loss of lip sync? DSound's GetCurrentPosition suffers from the exact same issue. For instance, playing an audio CD-ROM with mcicda in recent Wine causes constant underruns from DSound when Pulseaudio is involved. What's the root cause of the issue? 15 years ago, the audio HW would likely receive a pointer to the winmm header data and play that. Once played, the buffer was no more needed and returned to the app. Also, there was nothing sitting behind the audio HW causing significant latency (I mean DAC -> electronic -> speaker -> acoustic had latency negligible to the human brain). Equating GetPosition with the sample seen by the DAC was and is reasonable -- ALSA does exactly this with hw:0. DSound's model is that of a circular buffer from which the DAC is fed. No different. These days with mmdevapi, w7 users report a latency of 30-40ms introduced by the native mixer. Native's winmm might account for that in its GetPosition reports. This limit is below the threshold that my mmdevapi tests would notice. It is well below the approximately 100ms that matter to human perception when correlating visible and audible events. Note that native's mixer is the last in an audio graph before the HW. What happens in Linux with Wine? ALSA's dmix is known to introduce some latency as it operates in period-size chunks. However ALSA's periods are typically very small, e.g. 21.333ms and ALSA's dmix is typically connected to hw:0, immediately playing audio to the speakers. There's hardly a difference between audible GetPosition and a buffer position derived from snd_pcm_write (and old Wine mixed the two in the past). The picture looks a lot like with native's mmdevapi mixer. PulseAudio is entirely different. With PA, the wine mixer is no more near the end of the audio graph, rather than in front of a 2 second latency introducing element. A position derived from snd_pcm_write is 2s ahead of the true speaker position. How did we react? winealsa tried: 1. Using a small ALSA buffer so as to signal PA that large latencies are not ok. PA seems to ignore that hint. It still appears to buffer a lot somewhere internally (I've no experience with PA 1.0 or 1.1, please check). Even worse, small ALSA buffers like 40ms increased the risk of underruns and resulted in a worse audio experience to all users of wineALSA, whereas old wine would typically use a 100ms buffer. Small buffers are no issue to native's mixer. It's using "Pro Audio" priority, which is the highest priority on a native system AFAIK. By contrast, Wine is running at normal user priority. 2. Rate-Limiting. We currently believe we are doing it because we write no more than 3 periods at a time. But we're not. Nothing can prevent PA or any other device from filling its 2s buffer over time. It'll eventually do it, just slowly. We can't use our own clock to limit our writes because that would introduce clock skew issues with the audio HW clock. What if it runs faster than the system's interpretation of 48000fps? We can't second-guess the audio HW clock. IOW, we can't win a rate-limiting game. If the back-end signals via snd_pcm_avail that it has space, then we must feed it. Now we know the reason of our troubles. What can we do? 0. Ignore the issue. Equate GetPosition with Released_frames - GetCurrentPadding 1. Consider lip-sync important and strive to support audio & video applications. 2. mmdevapi appears to have a reasonable separation of concerns between buffering and speaker position. Leave as is. (It may happen though that apps built upon the assumption that they are no more than 40ms apart break when latencies like PA's enter the loop. Here it would be interesting to see whether native has some similar situation, like a remote desktop & audio environment). 3. Protect DSound from a too large delta between padding and position. The maximum is given by the DSound primary buffer size, since DSound's circular GetCurrentPosition abstraction breaks down completely should they be further apart. IOW, don't rate limit DSound writes, but lie about the position if the wineXYZ device says it's too far behind. Having this right may fix some of the bugs currently in bugzilla. That way, we'll get lip-sync with back-ends that don't introduce an unbearable latency. And we won't enter an underrun because the driver or the app never wait too much for the position to increase. 3. Protect winmm from a too large delta between padding and position. As there's no buffer limit to guide us, we must introduce an arbitrary one, around 100-200ms. I don't know whether a dynamic limit based on average supplied WHDR buffers would work. Regarding WHDR_DONE, I don't know whether we should then relax the tests. That feels unsafe, because an app may well wait for WHDR_DONE before calling waveOutReset or Close. WHDR_DONE should not come too early, or we may lose trailing sounds. Perhaps we should not delay the position when playing the last buffer in the list. Our winmm/tests/wave.c tests prove nothing more than that: at the end, the position corresponds to the sum of written samples. Perhaps a similar reflection on MS' side explains why in my tests native's mmdevapi GetPosition may stay 17 samples below the sum of written samples with some USB headsets (or is it just a bug in their driver?). 4. Observe the behaviour of libraries that target mmdevapi, winmm and DSound, e.g. OpenAL, XAudio2, bink, smack, SDL, FMOD and learn. Actually, thinking about what may happen to trailing samples in a system that introduces 2s latencies still gives headaches. If we issue snd_pcm_reset prior to snd_pcm_close, sound will be killed for sure. It looks like the device should remain open for some time. This applies to all wineXYZ devices, not just ALSA with PA. Some future OSS device may too introduce unforeseen latencies. Now I'll go and fix winmm as suggested above. Thank you for reading this far, Jörg Höhle

1 0

Re: [PATCH 3/3] ieframe: Added IProvideClassInfo::GetClassInfo tests
by Marvin 10 Feb '12

10 Feb '12

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=16906 Your paranoid android. === WNT4WSSP6 (32 bit webbrowser) === webbrowser.c:3189: Test failed: Creating WebBrowser object failed: 80040154 webbrowser.c:3189: Test failed: Creating WebBrowser object failed: 80040154 webbrowser.c:3189: Test failed: Creating WebBrowser object failed: 80040154 webbrowser.c:3189: Test failed: Creating WebBrowser object failed: 80040154 webbrowser.c:3304: Test failed: Creating WebBrowser object failed: 80040154 webbrowser.c:3281: Test failed: Could not get WebBrowserV1 instance: 80040154 webbrowser: unhandled exception c0000005 at 0040A9DE === W2KPROSP4 (32 bit webbrowser) === webbrowser.c:2539: Test failed: expected GetOverridesKeyPath webbrowser.c:2543: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2544: Test failed: expected Invoke_FILEDOWNLOAD webbrowser.c:2153: Test failed: put_Resizable failed: 80004001 webbrowser.c:2154: Test failed: expected Invoke_WINDOWSETRESIZABLE webbrowser.c:2158: Test failed: put_Resizable failed: 80004001 webbrowser.c:2159: Test failed: expected Invoke_WINDOWSETRESIZABLE webbrowser.c:2539: Test failed: expected GetOverridesKeyPath webbrowser.c:2543: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2544: Test failed: expected Invoke_FILEDOWNLOAD webbrowser.c:410: Test failed: unexpected call Exec_SETDOWNLOADSTATE_0 webbrowser.c:2153: Test failed: put_Resizable failed: 80004001 webbrowser.c:2154: Test failed: expected Invoke_WINDOWSETRESIZABLE webbrowser.c:2158: Test failed: put_Resizable failed: 80004001 webbrowser.c:2159: Test failed: expected Invoke_WINDOWSETRESIZABLE webbrowser.c:2539: Test failed: expected GetOverridesKeyPath webbrowser.c:2543: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2544: Test failed: expected Invoke_FILEDOWNLOAD webbrowser.c:469: Test failed: unexpected nCmdID 29 webbrowser.c:1007: Test failed: unexpected call GetContainer webbrowser.c:517: Test failed: unexpected call webbrowser.c:1007: Test failed: unexpected call GetContainer webbrowser.c:517: Test failed: unexpected call webbrowser.c:2702: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2829: Test failed: expected TranslateUrl webbrowser.c:2830: Test failed: expected Invoke_BEFORENAVIGATE2 webbrowser.c:2832: Test failed: expected Invoke_PROPERTYCHANGE webbrowser.c:2838: Test failed: ReadyState = 1, expected 4 webbrowser.c:2648: Test failed: ReadyState = 1, expected 4 webbrowser.c:839: Test failed: unexpected call Invoke_PROPERTYCHANGE webbrowser.c:855: Test failed: unexpected call Invoke_BEFORENAVIGATE2 webbrowser.c:862: Test failed: ReadyState = 1, expected 4 webbrowser.c:614: Test failed: unexpected call Invoke_AMBIENT_USERMODE webbrowser.c:614: Test failed: unexpected call Invoke_AMBIENT_USERMODE webbrowser.c:617: Test failed: unexpected call Invoke_AMBIENT_DLCONTROL webbrowser.c:621: Test failed: unexpected call Invoke_AMBIENT_USERAGENT webbrowser.c:625: Test failed: unexpected call Invoke_AMBIENT_PALETTE webbrowser.c:1557: Test failed: unexpected call GetOptionKeyPath webbrowser.c:359: Test failed: unexpected call QueryStatus_SETPROGRESSTEXT webbrowser.c:839: Test failed: unexpected call Invoke_PROPERTYCHANGE webbrowser.c:839: Test failed: unexpected call Invoke_PROPERTYCHANGE webbrowser.c:839: Test failed: unexpected call Invoke_PROPERTYCHANGE webbrowser.c:839: Test failed: unexpected call Invoke_PROPERTYCHANGE webbrowser.c:469: Test failed: unexpected nCmdID 26 webbrowser.c:469: Test failed: unexpected nCmdID 29 webbrowser.c:1007: Test failed: unexpected call GetContainer webbrowser.c:517: Test failed: unexpected call webbrowser.c:791: Test failed: ReadyState = 1, expected 4 webbrowser.c:1568: Test failed: unexpected call GetDropTarget webbrowser.c:1007: Test failed: unexpected call GetContainer webbrowser.c:517: Test failed: unexpected call webbrowser.c:2702: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:3225: Test failed: doc != doc2 webbrowser.c:614: Test failed: unexpected call Invoke_AMBIENT_USERMODE webbrowser.c:614: Test failed: unexpected call Invoke_AMBIENT_USERMODE webbrowser.c:617: Test failed: unexpected call Invoke_AMBIENT_DLCONTROL webbrowser.c:621: Test failed: unexpected call Invoke_AMBIENT_USERAGENT webbrowser.c:625: Test failed: unexpected call Invoke_AMBIENT_PALETTE webbrowser.c:1557: Test failed: unexpected call GetOptionKeyPath webbrowser.c:359: Test failed: unexpected call QueryStatus_SETPROGRESSTEXT webbrowser.c:469: Test failed: unexpected nCmdID 26 webbrowser.c:469: Test failed: unexpected nCmdID 29 webbrowser.c:1007: Test failed: unexpected call GetContainer webbrowser.c:517: Test failed: unexpected call webbrowser.c:1568: Test failed: unexpected call GetDropTarget webbrowser.c:1007: Test failed: unexpected call GetContainer webbrowser.c:517: Test failed: unexpected call webbrowser.c:2695: Test failed: expected TranslateUrl webbrowser.c:2702: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:3232: Test failed: doc != doc2 webbrowser.c:614: Test failed: unexpected call Invoke_AMBIENT_USERMODE webbrowser.c:614: Test failed: unexpected call Invoke_AMBIENT_USERMODE webbrowser.c:617: Test failed: unexpected call Invoke_AMBIENT_DLCONTROL webbrowser.c:621: Test failed: unexpected call Invoke_AMBIENT_USERAGENT webbrowser.c:625: Test failed: unexpected call Invoke_AMBIENT_PALETTE webbrowser.c:1557: Test failed: unexpected call GetOptionKeyPath webbrowser.c:359: Test failed: unexpected call QueryStatus_SETPROGRESSTEXT webbrowser.c:469: Test failed: unexpected nCmdID 26 webbrowser.c:469: Test failed: unexpected nCmdID 29 webbrowser.c:1007: Test failed: unexpected call GetContainer webbrowser.c:517: Test failed: unexpected call webbrowser.c:1568: Test failed: unexpected call GetDropTarget webbrowser.c:1007: Test failed: unexpected call GetContainer webbrowser.c:517: Test failed: unexpected call webbrowser.c:2695: Test failed: expected TranslateUrl webbrowser.c:2702: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2829: Test failed: expected TranslateUrl webbrowser.c:2830: Test failed: expected Invoke_BEFORENAVIGATE2 webbrowser.c:2838: Test failed: ReadyState = 1, expected 4 webbrowser.c:2648: Test failed: ReadyState = 1, expected 4 webbrowser.c:855: Test failed: unexpected call Invoke_BEFORENAVIGATE2 webbrowser.c:862: Test failed: ReadyState = 1, expected 4 webbrowser.c:614: Test failed: unexpected call Invoke_AMBIENT_USERMODE webbrowser.c:614: Test failed: unexpected call Invoke_AMBIENT_USERMODE webbrowser.c:617: Test failed: unexpected call Invoke_AMBIENT_DLCONTROL webbrowser.c:621: Test failed: unexpected call Invoke_AMBIENT_USERAGENT webbrowser.c:625: Test failed: unexpected call Invoke_AMBIENT_PALETTE webbrowser.c:1557: Test failed: unexpected call GetOptionKeyPath webbrowser.c:359: Test failed: unexpected call QueryStatus_SETPROGRESSTEXT webbrowser.c:469: Test failed: unexpected nCmdID 26 webbrowser.c:469: Test failed: unexpected nCmdID 29 webbrowser.c:1007: Test failed: unexpected call GetContainer webbrowser.c:517: Test failed: unexpected call webbrowser.c:791: Test failed: ReadyState = 1, expected 4 webbrowser.c:1568: Test failed: unexpected call GetDropTarget webbrowser.c:469: Test failed: unexpected nCmdID 16 webbrowser.c:469: Test failed: unexpected nCmdID 15 webbrowser.c:469: Test failed: unexpected nCmdID 16 webbrowser.c:469: Test failed: unexpected nCmdID 15 webbrowser.c:469: Test failed: unexpected nCmdID 16 webbrowser.c:469: Test failed: unexpected nCmdID 15 webbrowser.c:469: Test failed: unexpected nCmdID 16 webbrowser.c:469: Test failed: unexpected nCmdID 15 webbrowser.c:469: Test failed: unexpected nCmdID 16 webbrowser.c:469: Test failed: unexpected nCmdID 15 webbrowser.c:469: Test failed: unexpected nCmdID 16 webbrowser.c:469: Test failed: unexpected nCmdID 15 webbrowser.c:469: Test failed: unexpected nCmdID 16 webbrowser.c:469: Test failed: unexpected nCmdID 15 webbrowser.c:469: Test failed: unexpected nCmdID 16 webbrowser.c:469: Test failed: unexpected nCmdID 15 webbrowser.c:469: Test failed: unexpected nCmdID 16 webbrowser.c:469: Test failed: unexpected nCmdID 15 webbrowser.c:469: Test failed: unexpected nCmdID 16 webbrowser.c:469: Test failed: unexpected nCmdID 15 webbrowser.c:1007: Test failed: unexpected call GetContainer webbrowser.c:517: Test failed: unexpected call webbrowser.c:469: Test failed: unexpected nCmdID 16 webbrowser.c:469: Test failed: unexpected nCmdID 15 webbrowser.c:2702: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2648: Test failed: ReadyState = 1, expected 4 webbrowser.c:839: Test failed: unexpected call Invoke_PROPERTYCHANGE webbrowser.c:855: Test failed: unexpected call Invoke_BEFORENAVIGATE2 webbrowser.c:614: Test failed: unexpected call Invoke_AMBIENT_USERMODE webbrowser.c:614: Test failed: unexpected call Invoke_AMBIENT_USERMODE webbrowser.c:617: Test failed: unexpected call Invoke_AMBIENT_DLCONTROL webbrowser.c:621: Test failed: unexpected call Invoke_AMBIENT_USERAGENT webbrowser.c:625: Test failed: unexpected call Invoke_AMBIENT_PALETTE webbrowser.c:1557: Test failed: unexpected call GetOptionKeyPath webbrowser.c:359: Test failed: unexpected call QueryStatus_SETPROGRESSTEXT webbrowser.c:469: Test failed: unexpected nCmdID 26 webbrowser.c:469: Test failed: unexpected nCmdID 16 webbrowser.c:469: Test failed: unexpected nCmdID 15 webbrowser.c:469: Test failed: unexpected nCmdID 29 webbrowser.c:1007: Test failed: unexpected call GetContainer webbrowser.c:517: Test failed: unexpected call webbrowser.c:791: Test failed: ReadyState = 1, expected 4 webbrowser.c:1568: Test failed: unexpected call GetDropTarget webbrowser.c:1007: Test failed: unexpected call GetContainer webbrowser.c:517: Test failed: unexpected call webbrowser.c:2702: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2943: Test failed: expected RequestUIActivate webbrowser.c:3035: Test failed: Got 0x80004002 webbrowser.c:3130: Test failed: QueryService failed: 80004002 webbrowser: unhandled exception c0000005 at 0040D5A2

1 0

winealsa.drv patch to enum all software devices from .asoundrc
by Нискородов Серёжа 10 Feb '12

10 Feb '12

Hi, all. I'm not so good at programming. I just was looking for a way to make possible play sound from WINE to ALSA software device other than "default". I wrote a patch that allows you to select the ALSA software device from control panel, along with the hardware devices. Perhaps the code is not so clear and beautiful, but it works for me, and maybe someone wants to send it to the repository, or to correct and send a corrected.

2 5

[PATCH 1/6] include: new file ddk/scsi.h
by Dan Kegel 09 Feb '12

09 Feb '12

Only adds the minimum definitions needed to use SCSIOP_READ_DVD_STRUCTURE.

1 0

winetest can't remove its temp directory
by Joerg-Cyril.Hoehle＠t-systems.com 09 Feb '12

09 Feb '12

Hi, does anybody else see a message from winetest.exe about not being able to clean up at the end? This happened with e.g. winetest-1.4-rc2 and some earlier ones. Indeed, a temp directory with all the extracted *_test.exe is left half-full. It looks like files got deleted in alphabetical order starting with 'a'. mmdevapi_test.exe is the first one left, up to x*_test.exe Today's "[PATCH 2/4] mmdevapi/tests" adds a missing IAudioClock_Release(acl); Perhaps that prevented mmdevapi from cleaning up? How to explain such an effect? How to allow winetest to clean up and exit properly? That does not seem to be issue #12801. Thank you for your help, Jörg Höhle

2 1

Add a trailing full stop to the kernel32 error messages
by Francois Gouget 09 Feb '12

09 Feb '12

Translators: This may concern you! See the (*) below. (hence the post to wine-devel) It was discovered that the kernel32 error messages are supposed to all end with a full stop. This is a lot of strings and impacts a lot of translations. http://www.winehq.org/pipermail/wine-devel/2012-January/093969.html So this fix is not provided as a patch but as a set of two scripts. * mcfix adds a trailing full stop if needed to the kernel32 error messages. * pofix does the matching changes to the specified PO file both on the English and translated strings (taking into account the full-width for Chinese and Japanese translations). The advantage is that this can update everything with no fuzzying and without risking conflicts when applying it to Wine(*). To update Wine, simply run: ./mcfix dlls/kernel32/winerror.mc; for i in po/*.po;do ./pofix $i;done (*) As a translator if you have a local PO file that you took before this change and you modified some kernel32 error translations you patch will conflict. But that's easy to solve, simply run: ./pofix myfile.po -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ 145 = 1! + 4! + 5!

1 0

Re: [PATCH 1/2] winmm: Avoid using SuspendThread, it can hang Wine.
by Alexandre Julliard 09 Feb '12

09 Feb '12

Joerg-Cyril.Hoehle(a)t-systems.com writes: > @@ -1006,7 +1008,9 @@ static BOOL MMSYSTEM_MidiStream_MessageHandler(WINE_MIDIStream* lpMidiStrm, LPWI > LPMIDIHDR lpMidiHdr; > LPMIDIHDR* lpmh; > LPBYTE lpData; > + BOOL paused = FALSE; > > +still_paused: > switch (msg->message) { > case WM_QUIT: > SetEvent(lpMidiStrm->hEvent); > @@ -1028,6 +1032,16 @@ static BOOL MMSYSTEM_MidiStream_MessageHandler(WINE_MIDIStream* lpMidiStrm, LPWI > } > lpMidiStrm->lpMidiHdr = 0; > SetEvent(lpMidiStrm->hEvent); > + return TRUE; > + case WINE_MSM_RESUME: > + /* FIXME: send out cc64 0 (turn off sustain pedal) on every channel */ > + lpMidiStrm->dwStartTicks = GetTickCount() - lpMidiStrm->dwPositionMS; > + SetEvent(lpMidiStrm->hEvent); > + return TRUE; > + case WINE_MSM_PAUSE: > + /* FIXME: send out cc64 0 (turn off sustain pedal) on every channel */ > + paused = TRUE; > + SetEvent(lpMidiStrm->hEvent); > break; > case WINE_MSM_HEADER: > /* sets initial tick count for first MIDIHDR */ > @@ -1114,6 +1128,10 @@ static BOOL MMSYSTEM_MidiStream_MessageHandler(WINE_MIDIStream* lpMidiStrm, LPWI > FIXME("Unknown message %d\n", msg->message); > break; > } > + if (paused) { > + GetMessageA(msg, 0, 0, 0); > + goto still_paused; > + } Please stop abusing goto, write a proper loop instead. -- Alexandre Julliard julliard(a)winehq.org

3 4

Re: [PATCH 2/2] urlmon: Added more mk: combining tests
by Marvin 09 Feb '12

09 Feb '12

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=16890 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: [PATCH 4/4] mmdevapi/tests: Check GetService's output parameter.
by Marvin 09 Feb '12

09 Feb '12

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=16888 Your paranoid android. === WVISTAADM (32 bit render) === render.c:990: Test failed: ReleaseBuffer failed: 80070057 render.c:1013: Test failed: Position 0 vs. last 0 render.c:1076: Test failed: Reset failed: 8889000b render.c:1080: Test failed: Reset on a resetted stream returns 8889000b render.c:1089: Test failed: GetBuffer failed: 88890007 render.c:1094: Test failed: ReleaseBuffer failed: 80070057 render.c:1115: Test failed: Position 0 vs. last 0 render.c:1147: Test failed: Reset failed: 8889000b render.c:1154: Test failed: Reset on a resetted stream returns 8889000b render.c:1162: Test failed: GetBuffer failed: 88890007 render.c:990: Test failed: ReleaseBuffer failed: 80070057 render.c:1013: Test failed: Position 0 vs. last 0 render.c:1076: Test failed: Reset failed: 8889000b render.c:1080: Test failed: Reset on a resetted stream returns 8889000b render.c:1089: Test failed: GetBuffer failed: 88890007 render.c:1094: Test failed: ReleaseBuffer failed: 80070057 render.c:1115: Test failed: Position 0 vs. last 0 render.c:1147: Test failed: Reset failed: 8889000b render.c:1154: Test failed: Reset on a resetted stream returns 8889000b render.c:1162: Test failed: GetBuffer failed: 88890007 === W2K8SE (32 bit render) === render.c:990: Test failed: ReleaseBuffer failed: 80070057 render.c:1013: Test failed: Position 0 vs. last 0 render.c:1076: Test failed: Reset failed: 8889000b render.c:1080: Test failed: Reset on a resetted stream returns 8889000b render.c:1089: Test failed: GetBuffer failed: 88890007 render.c:1094: Test failed: ReleaseBuffer failed: 80070057 render.c:1115: Test failed: Position 0 vs. last 0 render.c:1147: Test failed: Reset failed: 8889000b render.c:1154: Test failed: Reset on a resetted stream returns 8889000b render.c:1162: Test failed: GetBuffer failed: 88890007 render.c:990: Test failed: ReleaseBuffer failed: 80070057 render.c:1013: Test failed: Position 0 vs. last 0 render.c:1076: Test failed: Reset failed: 8889000b render.c:1080: Test failed: Reset on a resetted stream returns 8889000b render.c:1089: Test failed: GetBuffer failed: 88890007 render.c:1094: Test failed: ReleaseBuffer failed: 80070057 render.c:1115: Test failed: Position 0 vs. last 0 render.c:1147: Test failed: Reset failed: 8889000b render.c:1154: Test failed: Reset on a resetted stream returns 8889000b render.c:1162: Test failed: GetBuffer failed: 88890007 === W7PRO (32 bit render) === render.c:990: Test failed: ReleaseBuffer failed: 80070057 render.c:1013: Test failed: Position 0 vs. last 0 render.c:1076: Test failed: Reset failed: 8889000b render.c:1080: Test failed: Reset on a resetted stream returns 8889000b render.c:1089: Test failed: GetBuffer failed: 88890007 render.c:1094: Test failed: ReleaseBuffer failed: 80070057 render.c:1115: Test failed: Position 0 vs. last 0 render.c:1147: Test failed: Reset failed: 8889000b render.c:1154: Test failed: Reset on a resetted stream returns 8889000b render.c:1162: Test failed: GetBuffer failed: 88890007 render.c:990: Test failed: ReleaseBuffer failed: 80070057 render.c:1013: Test failed: Position 0 vs. last 0 render.c:1076: Test failed: Reset failed: 8889000b render.c:1080: Test failed: Reset on a resetted stream returns 8889000b render.c:1089: Test failed: GetBuffer failed: 88890007 render.c:1094: Test failed: ReleaseBuffer failed: 80070057 render.c:1115: Test failed: Position 0 vs. last 0 render.c:1147: Test failed: Reset failed: 8889000b render.c:1154: Test failed: Reset on a resetted stream returns 8889000b render.c:1162: Test failed: GetBuffer failed: 88890007 === W7PROX64 (32 bit render) === render.c:990: Test failed: ReleaseBuffer failed: 80070057 render.c:1013: Test failed: Position 0 vs. last 0 render.c:1076: Test failed: Reset failed: 8889000b render.c:1080: Test failed: Reset on a resetted stream returns 8889000b render.c:1089: Test failed: GetBuffer failed: 88890007 render.c:1094: Test failed: ReleaseBuffer failed: 80070057 render.c:1115: Test failed: Position 0 vs. last 0 render.c:1147: Test failed: Reset failed: 8889000b render.c:1154: Test failed: Reset on a resetted stream returns 8889000b render.c:1162: Test failed: GetBuffer failed: 88890007 render.c:990: Test failed: ReleaseBuffer failed: 80070057 render.c:1013: Test failed: Position 0 vs. last 0 render.c:1076: Test failed: Reset failed: 8889000b render.c:1080: Test failed: Reset on a resetted stream returns 8889000b render.c:1089: Test failed: GetBuffer failed: 88890007 render.c:1094: Test failed: ReleaseBuffer failed: 80070057 render.c:1115: Test failed: Position 0 vs. last 0 render.c:1147: Test failed: Reset failed: 8889000b render.c:1154: Test failed: Reset on a resetted stream returns 8889000b render.c:1162: Test failed: GetBuffer failed: 88890007 === TEST64_W7SP1 (32 bit render) === render.c:990: Test failed: ReleaseBuffer failed: 80070057 render.c:1013: Test failed: Position 0 vs. last 0 render.c:1076: Test failed: Reset failed: 8889000b render.c:1080: Test failed: Reset on a resetted stream returns 8889000b render.c:1089: Test failed: GetBuffer failed: 88890007 render.c:1094: Test failed: ReleaseBuffer failed: 80070057 render.c:1115: Test failed: Position 0 vs. last 0 render.c:1147: Test failed: Reset failed: 8889000b render.c:1154: Test failed: Reset on a resetted stream returns 8889000b render.c:1162: Test failed: GetBuffer failed: 88890007 render.c:990: Test failed: ReleaseBuffer failed: 80070057 render.c:1013: Test failed: Position 0 vs. last 0 render.c:1076: Test failed: Reset failed: 8889000b render.c:1080: Test failed: Reset on a resetted stream returns 8889000b render.c:1089: Test failed: GetBuffer failed: 88890007 render.c:1094: Test failed: ReleaseBuffer failed: 80070057 render.c:1115: Test failed: Position 0 vs. last 0 render.c:1147: Test failed: Reset failed: 8889000b render.c:1154: Test failed: Reset on a resetted stream returns 8889000b render.c:1162: Test failed: GetBuffer failed: 88890007 === W7PROX64 (64 bit render) === render.c:990: Test failed: ReleaseBuffer failed: 80070057 render.c:1013: Test failed: Position 0 vs. last 0 render.c:1076: Test failed: Reset failed: 8889000b render.c:1080: Test failed: Reset on a resetted stream returns 8889000b render.c:1089: Test failed: GetBuffer failed: 88890007 render.c:1094: Test failed: ReleaseBuffer failed: 80070057 render.c:1115: Test failed: Position 0 vs. last 0 render.c:1147: Test failed: Reset failed: 8889000b render.c:1154: Test failed: Reset on a resetted stream returns 8889000b render.c:1162: Test failed: GetBuffer failed: 88890007 render.c:990: Test failed: ReleaseBuffer failed: 80070057 render.c:1013: Test failed: Position 0 vs. last 0 render.c:1076: Test failed: Reset failed: 8889000b render.c:1080: Test failed: Reset on a resetted stream returns 8889000b render.c:1089: Test failed: GetBuffer failed: 88890007 render.c:1094: Test failed: ReleaseBuffer failed: 80070057 render.c:1115: Test failed: Position 0 vs. last 0 render.c:1147: Test failed: Reset failed: 8889000b render.c:1154: Test failed: Reset on a resetted stream returns 8889000b render.c:1162: Test failed: GetBuffer failed: 88890007 === TEST64_W7SP1 (64 bit render) === render.c:990: Test failed: ReleaseBuffer failed: 80070057 render.c:1013: Test failed: Position 0 vs. last 0 render.c:1076: Test failed: Reset failed: 8889000b render.c:1080: Test failed: Reset on a resetted stream returns 8889000b render.c:1089: Test failed: GetBuffer failed: 88890007 render.c:1094: Test failed: ReleaseBuffer failed: 80070057 render.c:1115: Test failed: Position 0 vs. last 0 render.c:1147: Test failed: Reset failed: 8889000b render.c:1154: Test failed: Reset on a resetted stream returns 8889000b render.c:1162: Test failed: GetBuffer failed: 88890007 render.c:990: Test failed: ReleaseBuffer failed: 80070057 render.c:1013: Test failed: Position 0 vs. last 0 render.c:1076: Test failed: Reset failed: 8889000b render.c:1080: Test failed: Reset on a resetted stream returns 8889000b render.c:1089: Test failed: GetBuffer failed: 88890007 render.c:1094: Test failed: ReleaseBuffer failed: 80070057 render.c:1115: Test failed: Position 0 vs. last 0 render.c:1147: Test failed: Reset failed: 8889000b render.c:1154: Test failed: Reset on a resetted stream returns 8889000b render.c:1162: Test failed: GetBuffer failed: 88890007

1 0

Re: [PATCH 3/4] mmdevapi/tests: Perform renderer padding & position tests.
by Marvin 09 Feb '12

09 Feb '12

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=16887 Your paranoid android. === WVISTAADM (32 bit render) === render.c:980: Test failed: ReleaseBuffer failed: 80070057 render.c:1003: Test failed: Position 0 vs. last 0 render.c:1066: Test failed: Reset failed: 8889000b render.c:1070: Test failed: Reset on a resetted stream returns 8889000b render.c:1079: Test failed: GetBuffer failed: 88890007 render.c:1084: Test failed: ReleaseBuffer failed: 80070057 render.c:1105: Test failed: Position 0 vs. last 0 render.c:1137: Test failed: Reset failed: 8889000b render.c:1144: Test failed: Reset on a resetted stream returns 8889000b render.c:1152: Test failed: GetBuffer failed: 88890007 render.c:980: Test failed: ReleaseBuffer failed: 80070057 render.c:1003: Test failed: Position 0 vs. last 0 render.c:1066: Test failed: Reset failed: 8889000b render.c:1070: Test failed: Reset on a resetted stream returns 8889000b render.c:1079: Test failed: GetBuffer failed: 88890007 render.c:1084: Test failed: ReleaseBuffer failed: 80070057 render.c:1105: Test failed: Position 0 vs. last 0 render.c:1137: Test failed: Reset failed: 8889000b render.c:1144: Test failed: Reset on a resetted stream returns 8889000b render.c:1152: Test failed: GetBuffer failed: 88890007 === W2K8SE (32 bit render) === render.c:980: Test failed: ReleaseBuffer failed: 80070057 render.c:1003: Test failed: Position 0 vs. last 0 render.c:1066: Test failed: Reset failed: 8889000b render.c:1070: Test failed: Reset on a resetted stream returns 8889000b render.c:1079: Test failed: GetBuffer failed: 88890007 render.c:1084: Test failed: ReleaseBuffer failed: 80070057 render.c:1105: Test failed: Position 0 vs. last 0 render.c:1137: Test failed: Reset failed: 8889000b render.c:1144: Test failed: Reset on a resetted stream returns 8889000b render.c:1152: Test failed: GetBuffer failed: 88890007 render.c:980: Test failed: ReleaseBuffer failed: 80070057 render.c:1003: Test failed: Position 0 vs. last 0 render.c:1066: Test failed: Reset failed: 8889000b render.c:1070: Test failed: Reset on a resetted stream returns 8889000b render.c:1079: Test failed: GetBuffer failed: 88890007 render.c:1084: Test failed: ReleaseBuffer failed: 80070057 render.c:1105: Test failed: Position 0 vs. last 0 render.c:1137: Test failed: Reset failed: 8889000b render.c:1144: Test failed: Reset on a resetted stream returns 8889000b render.c:1152: Test failed: GetBuffer failed: 88890007 === W7PRO (32 bit render) === render.c:980: Test failed: ReleaseBuffer failed: 80070057 render.c:1003: Test failed: Position 0 vs. last 0 render.c:1066: Test failed: Reset failed: 8889000b render.c:1070: Test failed: Reset on a resetted stream returns 8889000b render.c:1079: Test failed: GetBuffer failed: 88890007 render.c:1084: Test failed: ReleaseBuffer failed: 80070057 render.c:1105: Test failed: Position 0 vs. last 0 render.c:1137: Test failed: Reset failed: 8889000b render.c:1144: Test failed: Reset on a resetted stream returns 8889000b render.c:1152: Test failed: GetBuffer failed: 88890007 render.c:980: Test failed: ReleaseBuffer failed: 80070057 render.c:1003: Test failed: Position 0 vs. last 0 render.c:1066: Test failed: Reset failed: 8889000b render.c:1070: Test failed: Reset on a resetted stream returns 8889000b render.c:1079: Test failed: GetBuffer failed: 88890007 render.c:1084: Test failed: ReleaseBuffer failed: 80070057 render.c:1105: Test failed: Position 0 vs. last 0 render.c:1137: Test failed: Reset failed: 8889000b render.c:1144: Test failed: Reset on a resetted stream returns 8889000b render.c:1152: Test failed: GetBuffer failed: 88890007 === W7PROX64 (32 bit render) === render.c:980: Test failed: ReleaseBuffer failed: 80070057 render.c:1003: Test failed: Position 0 vs. last 0 render.c:1066: Test failed: Reset failed: 8889000b render.c:1070: Test failed: Reset on a resetted stream returns 8889000b render.c:1079: Test failed: GetBuffer failed: 88890007 render.c:1084: Test failed: ReleaseBuffer failed: 80070057 render.c:1105: Test failed: Position 0 vs. last 0 render.c:1137: Test failed: Reset failed: 8889000b render.c:1144: Test failed: Reset on a resetted stream returns 8889000b render.c:1152: Test failed: GetBuffer failed: 88890007 render.c:980: Test failed: ReleaseBuffer failed: 80070057 render.c:1003: Test failed: Position 0 vs. last 0 render.c:1066: Test failed: Reset failed: 8889000b render.c:1070: Test failed: Reset on a resetted stream returns 8889000b render.c:1079: Test failed: GetBuffer failed: 88890007 render.c:1084: Test failed: ReleaseBuffer failed: 80070057 render.c:1105: Test failed: Position 0 vs. last 0 render.c:1137: Test failed: Reset failed: 8889000b render.c:1144: Test failed: Reset on a resetted stream returns 8889000b render.c:1152: Test failed: GetBuffer failed: 88890007 === TEST64_W7SP1 (32 bit render) === render.c:980: Test failed: ReleaseBuffer failed: 80070057 render.c:1003: Test failed: Position 0 vs. last 0 render.c:1066: Test failed: Reset failed: 8889000b render.c:1070: Test failed: Reset on a resetted stream returns 8889000b render.c:1079: Test failed: GetBuffer failed: 88890007 render.c:1084: Test failed: ReleaseBuffer failed: 80070057 render.c:1105: Test failed: Position 0 vs. last 0 render.c:1137: Test failed: Reset failed: 8889000b render.c:1144: Test failed: Reset on a resetted stream returns 8889000b render.c:1152: Test failed: GetBuffer failed: 88890007 render.c:980: Test failed: ReleaseBuffer failed: 80070057 render.c:1003: Test failed: Position 0 vs. last 0 render.c:1066: Test failed: Reset failed: 8889000b render.c:1070: Test failed: Reset on a resetted stream returns 8889000b render.c:1079: Test failed: GetBuffer failed: 88890007 render.c:1084: Test failed: ReleaseBuffer failed: 80070057 render.c:1105: Test failed: Position 0 vs. last 0 render.c:1137: Test failed: Reset failed: 8889000b render.c:1144: Test failed: Reset on a resetted stream returns 8889000b render.c:1152: Test failed: GetBuffer failed: 88890007 === W7PROX64 (64 bit render) === render.c:980: Test failed: ReleaseBuffer failed: 80070057 render.c:1003: Test failed: Position 0 vs. last 0 render.c:1066: Test failed: Reset failed: 8889000b render.c:1070: Test failed: Reset on a resetted stream returns 8889000b render.c:1079: Test failed: GetBuffer failed: 88890007 render.c:1084: Test failed: ReleaseBuffer failed: 80070057 render.c:1105: Test failed: Position 0 vs. last 0 render.c:1137: Test failed: Reset failed: 8889000b render.c:1144: Test failed: Reset on a resetted stream returns 8889000b render.c:1152: Test failed: GetBuffer failed: 88890007 render.c:980: Test failed: ReleaseBuffer failed: 80070057 render.c:1003: Test failed: Position 0 vs. last 0 render.c:1066: Test failed: Reset failed: 8889000b render.c:1070: Test failed: Reset on a resetted stream returns 8889000b render.c:1079: Test failed: GetBuffer failed: 88890007 render.c:1084: Test failed: ReleaseBuffer failed: 80070057 render.c:1105: Test failed: Position 0 vs. last 0 render.c:1137: Test failed: Reset failed: 8889000b render.c:1144: Test failed: Reset on a resetted stream returns 8889000b render.c:1152: Test failed: GetBuffer failed: 88890007 === TEST64_W7SP1 (64 bit render) === render.c:980: Test failed: ReleaseBuffer failed: 80070057 render.c:1003: Test failed: Position 0 vs. last 0 render.c:1066: Test failed: Reset failed: 8889000b render.c:1070: Test failed: Reset on a resetted stream returns 8889000b render.c:1079: Test failed: GetBuffer failed: 88890007 render.c:1084: Test failed: ReleaseBuffer failed: 80070057 render.c:1105: Test failed: Position 0 vs. last 0 render.c:1137: Test failed: Reset failed: 8889000b render.c:1144: Test failed: Reset on a resetted stream returns 8889000b render.c:1152: Test failed: GetBuffer failed: 88890007 render.c:980: Test failed: ReleaseBuffer failed: 80070057 render.c:1003: Test failed: Position 0 vs. last 0 render.c:1066: Test failed: Reset failed: 8889000b render.c:1070: Test failed: Reset on a resetted stream returns 8889000b render.c:1079: Test failed: GetBuffer failed: 88890007 render.c:1084: Test failed: ReleaseBuffer failed: 80070057 render.c:1105: Test failed: Position 0 vs. last 0 render.c:1137: Test failed: Reset failed: 8889000b render.c:1144: Test failed: Reset on a resetted stream returns 8889000b render.c:1152: Test failed: GetBuffer failed: 88890007

1 0

Re: winecfg: Center main window on the screen.
by Dmitry Timoshkov 09 Feb '12

09 Feb '12

Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > For bug 21645. What is this pending for? -- Dmitry.

1 0

libgcrypt thread safety
by Adam Martinson 08 Feb '12

08 Feb '12

I've been looking into bug 27036 <http://bugs.winehq.org/show_bug.cgi?id=27036> , and it's due to the lack of thread safety by default in libgcrypt (in this case via libgnutls in secur32.dll). To be thread safe, libgcrypt requires a call to gcry_control(GCRYCTL_SET_THREAD_CBS) before any libgcrypt initialization is done. However, libgcrypt is used by a lot of different libs, one of which is being used by some other dll that's loading before secur32.dll. My question is, is it acceptable to do the gcry_control() call in ntdll's DllMain()? The alternative seems to be tracking down every lib used by wine that uses libgcrypt and doing it in each of those dlls. What's the best way to handle this?

3 2

Re: Profiing windows apps
by Ralph Little 08 Feb '12

08 Feb '12

Hi, > Also please attach a full +ddraw log to the bug report. If it is too big > compress it. bzip2 should do a pretty decent job, if all fails try lrzip. OK, done! > If the testing doesn't reveal anything, look out for IDirectDraw::GetCaps > calls in the logs or IDirect3Dx::EnumZBufferFormats. IDirectDraw::GetCaps > returns a DDCAPS structure which has dwZBufferBitDepths containing some flags > for z buffer bit depths. EnumZBufferFormats calls a callback multiple times > with available DDPIXELFORMAT structures. The application may not like some > flags we set there. The Sims calls EnumDevices and I presume calls EnumZBufferFormats within the callback for each device: trace:ddraw:d3d3_EnumDevices Enumerating WineD3D D3DDevice interface. trace:ddraw:d3d3_EnumZBufferFormats iface 0x13d04c, device_iid {a4665c60-2673-11cf-a31a-00aa00b93356}, callback 0x586a7d, context 0xabc198. trace:ddraw:d3d7_EnumZBufferFormats iface 0x13d048, device_iid {a4665c60-2673-11cf-a31a-00aa00b93356}, callback 0x586a7d, context 0xabc198. trace:ddraw:d3d7_EnumZBufferFormats Asked for SW device. trace:ddraw:PixelFormat_WineD3DtoDD Converting wined3d format 0x52 to DDRAW. trace:ddraw:PixelFormat_WineD3DtoDD Returning: ( DDPF_ZBUFFER , Z bits : 16) trace:ddraw:d3d7_EnumZBufferFormats Enumerating wined3d format 0x52. trace:ddraw:d3d7_EnumZBufferFormats Format enumeration cancelled by application. trace:ddraw:d3d3_EnumDevices Enumerating HAL Direct3D device. trace:ddraw:d3d3_EnumZBufferFormats iface 0x13d04c, device_iid {84e63de0-46aa-11cf-816f-0000c020156e}, callback 0x586a7d, context 0xabc198. trace:ddraw:d3d7_EnumZBufferFormats iface 0x13d048, device_iid {84e63de0-46aa-11cf-816f-0000c020156e}, callback 0x586a7d, context 0xabc198. trace:ddraw:d3d7_EnumZBufferFormats Asked for HAL device. trace:ddraw:PixelFormat_WineD3DtoDD Converting wined3d format 0x52 to DDRAW. trace:ddraw:PixelFormat_WineD3DtoDD Returning: ( DDPF_ZBUFFER , Z bits : 16) trace:ddraw:d3d7_EnumZBufferFormats Enumerating wined3d format 0x52. trace:ddraw:d3d7_EnumZBufferFormats Format enumeration cancelled by application. trace:ddraw:d3d3_EnumDevices End of enumeration. I don't know if this looks sensible, though. I see from the code that there are a lot of "gotchas" (both in d3d7_EnumZBufferFormats and d3d3_EnumDevices) for a number of games expecting things to happen in specific sequences and containing specific responses. I wonder if the Sims is going to turn out to be another. Cheers, Ralph

1 0

OpenGL child windows (SketchUp)
by Brian Bloniarz 08 Feb '12

08 Feb '12

Hi all, I could use a little help fixing a window lag and screen corruption issue in SketchUp: http://bugs.winehq.org/show_bug.cgi?id=25912 Long story short, I think the implementation of OpenGL child rendering needs a small update. As a reminder, this is how an OpenGL child window is setup: static BOOL set_win_format( HWND hwnd, XID fbconfig_id ) { gl_drawable = XCreateWindow(...); // offscreen window XCompositeRedirectWindow(..., gl_drawable, CompositeRedirectManual); } Here XComposite extension is render into an offscreen window. When it's time to display, the contents of that window are copied into the visible onscreen parent window (physDev is the onscreen window, gl_drawable is the offscreen window): BOOL X11DRV_SwapBuffers(PHYSDEV dev) { ... glXSwapBuffers(gdi_display, gl_drawable); ... /* The GL drawable may be lagged behind if we don't flush first, so * flush the display make sure we copy up-to-date data */ XFlush(gdi_display); XCopyArea(gdi_display, gl_drawable, physDev...); } The XFlush() is the problem; the buffer swap must happen before the copy, and accelerated renderers wouldn't guarantee to do that on an X queue flush. So how do you wait for a buffer swap? I wrote a test program, can you say "undefined behavior"? I tested on a few drivers: 1) ATI fglrx binary driver: glXSwapBuffers is instantaneous, existing code works fine. 2) NVidia binary driver: glXSwapBuffers is asynchronous, neither XFlush() nor XSync() is enough. Calling glXWaitGL or glFinish works. 3) Mesa DRI driver (Intel i915): glXSwapBuffers is asynchronous. None of XFlush/XSync/glXWaitX/glXWaitGL is enough. glFinish works. 4) r600g (Open Source accelerated ATI) driver: glXSwapBuffers is asynchronous. None of the flush calls wait for it (XFlush/XSync/glXWaitGL/glXWaitX/glFinish). The last one is the tricky part -- this driver is also based on the DRI, so I'm guessing it may appear on other open-source accelerated drivers (looking at http://www.x.org/releases/current/doc/dri2proto/dri2proto.txt suggests that this is new behavior as of 1.99.2) So how to come up with a common fix? I could think of 3 possibilities: 1) Use the GLX_OML_sync_control extension, it has an explicit call to wait for a buffer swap. Not supported by NV or fglrx, but we could fallback to glXWaitGL on those drivers. Probably simplest. 2) Use the X Damage extension, wait for an XDamageNotify event before copying. This should work everywhere, all drivers probably implement damage so that compositing window managers can use it. 3) Talk to the DRI people, maybe glXWaitGL should't return when there's a pending a buffer swap. The GLX spec seems to say it should wait, but it's a grey area and the Composite extension was designed much later. Not a quick fix. Any ideas or thoughts? If I hear nothing, I can code up a patch that does (1), but it'd be great to hear from some people who know this area well. Thanks, Brian Bloniarz

3 2

Re: gdi32: Consider whether the logical font face is vertical when selecting.
by Marvin 08 Feb '12

08 Feb '12

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=16876 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: winecfg: Center main window on the screen.
by Vitaliy Margolen 08 Feb '12

08 Feb '12

Please don't! I want my window manager decide based on how I configured it where to position new windows. And not every program open in the middle of the screen just because it things it's the most important thing on my screen. Vitaliy.

4 3

winmm: TRACE unhandled messages
by Joerg-Cyril.Hoehle＠t-systems.com 08 Feb '12

08 Feb '12

Andrew, it's good that you log these now. I had a question in mind since your winmm rewrite: Your rewrite no more maps WOD_XYZ* messages to waveOut functions. I believe that it is possible that an old app entirely uses the generic SendDriverMessage function (esp. in the mciavi/msvfw area, cf. ICSendMessage) instead of the specific wave/midi* ones. Can you be sure that this is not supported by native, esp. w9x? If Wine does not map these, all we'll get to "hear" in AppDB is that attentive people miss sound or music that they remember listening to 10 years ago on native. Regards, Jörg Höhle

2 1

Re: [1/2] user32: Add a bunch of RealChildWindowFromPoint tests.
by Alexandre Julliard 08 Feb '12

08 Feb '12

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > win.c:6753: Test failed: FlashWindowEx succeeded > win.c:6764: Test failed: FlashWindowEx failed with -559038737 > > are intermittent, and have nothing to do with these tests. Maybe not directly, but the failures are clearly caused by your change, and they look pretty bad on the test results. Please fix that. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: po: Remove untranslated English strings from the Romanian translation
by Michael Stefaniuc 07 Feb '12

07 Feb '12

Hello Frédéric, the patch is wrong. Frédéric Delanoy wrote: > --- > po/ro.po | 6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/po/ro.po b/po/ro.po > index a0912c2..c9375c4 100644 > --- a/po/ro.po > +++ b/po/ro.po > @@ -11803,11 +11803,11 @@ msgstr "Bază" > > #: regedit.rc:282 > msgid "Hexadecimal" > -msgstr "Hexadecimal" > +msgstr "" > > #: regedit.rc:283 > msgid "Decimal" > -msgstr "Decimal" > +msgstr "" Those aren't untranslated but the Romanian words match the English ones. > #: regedit.rc:290 > msgid "Edit Binary" > @@ -13243,7 +13243,7 @@ msgstr "Afișează opțiunile a&vansate" > > #: winecfg.rc:240 > msgid "De&vice:" > -msgstr "De&vice:" > +msgstr "" > > #: winecfg.rc:242 > msgid "Bro&wse..." bye michael

3 3

Re: po: Fix some trailing ellipses errors in Catalan translation
by Alex Henrie 07 Feb '12

07 Feb '12

#: ieframe.rc:68 winhlp32.rc:66 msgid "Print..." -msgstr "Imprimeix" +msgstr "Imprimeix..." I intentionally left the ellipse off of the word "Imprimeix" in Internet Explorer so that the text would fit on the toolbar button. Any suggestions? -Alex

3 2

Re: po: Update finnish locales
by Lauri Kenttä 07 Feb '12

07 Feb '12

On 2012-02-06 23:00, Olli-Pekka Wallin wrote: > +msgstr "KB/s" > ... > +msgstr "Yksi sivua" > ... > +msgstr "Wordpad ojelman kÃƒÂ¤ynnistys epÃƒÂ¤onnistui" I'm sorry to say this, but these translations are really bad. I suggest you either have someone check your translations thoroughly before submitting or leave the whole job for others. (I'm already working on it.) The patch is also based on an old revision and changes a msgid. -- Lauri Kenttä

1 0

SourceForge forbids download
by Aidin Gharibnavaz 07 Feb '12

07 Feb '12

Dear Wine developers, SourceForge blocked download for some countries by default, such as Iran. (More detail can be found here<https://sourceforge.net/blog/some-good-news-SourceForge-removes-blanket-blo…> ) So, if it's not illegal to you to let Iranians download your software, please go to the SourceForge's ProjectAdmin, and set the ExportControl option, to let us enjoy the great work of yours. Thanks.

3 2

Re: po: Update finnish locales
by Francois Gouget 07 Feb '12

07 Feb '12

On Mon, 6 Feb 2012, Olli-Pekka Wallin wrote: > po: Update finnish locales > > #: appwiz.rc:49 > msgid "Installing..." > -msgstr "" > +msgstr "Asennetaan.." It looks like there's a missing dot here. But thanks a lot for the patch. Feel free to tackle any other issue in: http://fgouget.free.fr/wine-po/fi-errors.html Also don't hesitate to let me know about false positives so I can silence them. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Any sufficiently advanced bug is indistinguishable from a feature. -- from some indian guy

1 0

Re: ID3DXBaseEffect::SetValue
by luis.busquets＠ilidium.com 07 Feb '12

07 Feb '12

For the textures point, it is judt that the implemenyation is just the change of one pointer ----- Reply message ----- De: "Rico Schüller" <kgbricola(a)web.de> Para: "Luis Carlos Busquets Pérez" <luis.busquets(a)ilidium.com> CC: <wine-devel(a)winehq.org> Asunto: ID3DXBaseEffect::SetValue Fecha: mar., feb. 7, 2012 10:03 Am 07.02.2012 06:02, schrieb Luis Carlos Busquets Pérez: > 1. If the functions returns E_FAIL for a sample then > test_effect.c:1917: Test failed: Got result 80004005, expected 0 (D3D_OK) I'll have a look at those. > 2. For D3DXPT_VERTEXSHADER and D3DXPT_PIXELSHADER replying with E_FAIL > avoids > test_effect.c:1812: Test failed: Got result 0, expected 0x80004005 > (E_FAIL) > test_effect.c:1814: Test failed: Got result 0, expected 0x80004005 > (E_FAIL) > test_effect.c:1881: Test failed: Got result 0, expected 0x80004005 > (E_FAIL) Sure, that's not implemented, yet. You should get a FIXME for those cases. > 3. If the function just sets the memory with the data for a bool then > test_effect.c:969: Test failed: Got 46, expected 1 In this case it may be required, that the input has to be converted before it is put into data. A solution would be to use Set*Array to set the values. In general, I think it's also fine to convert the values in get_int() and get_float() in the case of D3DXPT_BOOL with get_bool(data) - I'll send a patch for this. But I also think a test to show, that the value is converted while it is set, is still the way to go. Well SetValue isn't complete, yet. > 5. Concerning textures, the compiler does not accept arrays of textures, > so any change to a texture type should be just a change of the pointer > to the texture at param->data (or NULL) I didn't got the point. Only that it is impossible to declare texture arrays in effect files, which I could confirm. Do you mean, that the HeapAlloc for the additional pointer for textures should be avoided? This could be done, it just needs separate handling for textures. As it is now, it mostly uses the same handling together with the shaders (e.g. IUnknown_Release(*(IUnknown **)param->data)). Cheers Rico

1 0

Re: ID3DXBaseEffect::SetValue
by luis.busquets＠ilidium.com 07 Feb '12

07 Feb '12

Concerning the vertrd a picel shadet, the truth is that sin e very soon in the history of d3dx the functions ID3DXEffect::SetPixelShader and ID3DXEffect::DetVertexShader wete removed. So actually it does not seem that you can change them. Because of that, the MS implementation replies with D3DERR_INVALIDCALL and their implementation in SetValue is straight. ----- Reply message ----- De: "Rico Schüller" <kgbricola(a)web.de> Para: "Luis Carlos Busquets Pérez" <luis.busquets(a)ilidium.com> CC: <wine-devel(a)winehq.org> Asunto: ID3DXBaseEffect::SetValue Fecha: mar., feb. 7, 2012 10:03 Am 07.02.2012 06:02, schrieb Luis Carlos Busquets Pérez: > 1. If the functions returns E_FAIL for a sample then > test_effect.c:1917: Test failed: Got result 80004005, expected 0 (D3D_OK) I'll have a look at those. > 2. For D3DXPT_VERTEXSHADER and D3DXPT_PIXELSHADER replying with E_FAIL > avoids > test_effect.c:1812: Test failed: Got result 0, expected 0x80004005 > (E_FAIL) > test_effect.c:1814: Test failed: Got result 0, expected 0x80004005 > (E_FAIL) > test_effect.c:1881: Test failed: Got result 0, expected 0x80004005 > (E_FAIL) Sure, that's not implemented, yet. You should get a FIXME for those cases. > 3. If the function just sets the memory with the data for a bool then > test_effect.c:969: Test failed: Got 46, expected 1 In this case it may be required, that the input has to be converted before it is put into data. A solution would be to use Set*Array to set the values. In general, I think it's also fine to convert the values in get_int() and get_float() in the case of D3DXPT_BOOL with get_bool(data) - I'll send a patch for this. But I also think a test to show, that the value is converted while it is set, is still the way to go. Well SetValue isn't complete, yet. > 5. Concerning textures, the compiler does not accept arrays of textures, > so any change to a texture type should be just a change of the pointer > to the texture at param->data (or NULL) I didn't got the point. Only that it is impossible to declare texture arrays in effect files, which I could confirm. Do you mean, that the HeapAlloc for the additional pointer for textures should be avoided? This could be done, it just needs separate handling for textures. As it is now, it mostly uses the same handling together with the shaders (e.g. IUnknown_Release(*(IUnknown **)param->data)). Cheers Rico

1 0

Re: comctl32: Remove an obsolete resource attribute.
by Marvin 07 Feb '12

07 Feb '12

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=16849 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

2 1

ID3DXBaseEffect::SetValue
by Luis Carlos Busquets Pérez 07 Feb '12

07 Feb '12

The functin returns D3DERR_INVALIDCALL whenever it is tried on a parameter with elements. A check should be included. Luis

2 3

Re: user32: Only call SetWindowPos() in UpdateLayeredWindowIndirect() if needed. (try 5)
by Dmitry Timoshkov 07 Feb '12

07 Feb '12

Adam Martinson <adam.r.martinson(a)gmail.com> wrote: > (We should not be calling SetWindowPos() in UpdateLayeredWindowIndirect() at all.) > Fixes bug 26924. Much better now, thanks. -- Dmitry.

1 0

Re: user32: Fix a couple of typos.
by Marvin 07 Feb '12

07 Feb '12

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=16847 Your paranoid android. === TEST64_W7SP1 (32 bit win) === win.c:6753: Test failed: FlashWindowEx succeeded win.c:6764: Test failed: FlashWindowEx failed with -559038737 === TEST64_W7SP1 (64 bit win) === win.c:6753: Test failed: FlashWindowEx succeeded win.c:6764: Test failed: FlashWindowEx failed with -559038737

1 0

Re: user32: Only call SetWindowPos() in UpdateLayeredWindowIndirect() if needed. (try 5)
by Marvin 07 Feb '12

07 Feb '12

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=16845 Your paranoid android. === WVISTAADM (32 bit msg) === Failure running script in VM: The specified guest user must be logged in interactively to perform this operation === TEST64_W7SP1 (32 bit win) === win.c:6825: Test failed: FlashWindowEx succeeded win.c:6836: Test failed: FlashWindowEx failed with -559038737 === TEST64_W7SP1 (64 bit win) === win.c:6825: Test failed: FlashWindowEx succeeded win.c:6836: Test failed: FlashWindowEx failed with -559038737

1 0

ID3DXEffect::SetValue
by Luis Carlos Busquets Pérez 06 Feb '12

06 Feb '12

The current implementation includes a check on param->bytes >= bytes specifically: if (data && param->bytes >= bytes) { ... } So if bytes<param->bytes returns D3DERR_INVALIDCALL. However, the MS version does not act that way: If the parameter is shorter than the length of the data, then the data that fits in the parameter is put and returns D3D_OK Therefore, the check of the size should be eliminated and in memcpy instead of referring to bytes, it should refer to min(bytes, param->bytes) Luis

3 2

Re: (try2) quartz: AMFilterData_ParseFilterData returns a pointer to a pointer to filter data
by Marvin 06 Feb '12

06 Feb '12

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=16838 Your paranoid android. === WINEBUILD (build) === Make failed

1 0

Re: [2/2] user32: RealChildWindowFromPoint should skip invisible windows.
by Marvin 06 Feb '12

06 Feb '12

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=16834 Your paranoid android. === W2KPROSP4 (32 bit win) === win.c:6753: Test failed: FlashWindowEx succeeded win.c:6764: Test failed: FlashWindowEx failed with -559038737 === WXPPROSP3 (32 bit win) === win.c:6753: Test failed: FlashWindowEx succeeded win.c:6764: Test failed: FlashWindowEx failed with -559038737 === W2K3R2SESP2 (32 bit win) === win.c:6753: Test failed: FlashWindowEx succeeded win.c:6764: Test failed: FlashWindowEx failed with -559038737 === WVISTAADM (32 bit win) === win.c:6753: Test failed: FlashWindowEx succeeded win.c:6764: Test failed: FlashWindowEx failed with -559038737 === W2K8SE (32 bit win) === win.c:6753: Test failed: FlashWindowEx succeeded win.c:6764: Test failed: FlashWindowEx failed with -559038737 === W7PRO (32 bit win) === win.c:6753: Test failed: FlashWindowEx succeeded win.c:6764: Test failed: FlashWindowEx failed with -559038737 === W7PROX64 (32 bit win) === win.c:6753: Test failed: FlashWindowEx succeeded win.c:6764: Test failed: FlashWindowEx failed with -559038737 === TEST64_W7SP1 (32 bit win) === win.c:6753: Test failed: FlashWindowEx succeeded win.c:6764: Test failed: FlashWindowEx failed with -559038737 === W7PROX64 (64 bit win) === win.c:6753: Test failed: FlashWindowEx succeeded win.c:6764: Test failed: FlashWindowEx failed with -559038737 === TEST64_W7SP1 (64 bit win) === win.c:6753: Test failed: FlashWindowEx succeeded win.c:6764: Test failed: FlashWindowEx failed with -559038737

1 0

Re: [1/2] user32: Add a bunch of RealChildWindowFromPoint tests.
by Marvin 06 Feb '12

06 Feb '12

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=16833 Your paranoid android. === W2KPROSP4 (32 bit win) === win.c:6753: Test failed: FlashWindowEx succeeded win.c:6764: Test failed: FlashWindowEx failed with -559038737 === WXPPROSP3 (32 bit win) === win.c:6753: Test failed: FlashWindowEx succeeded win.c:6764: Test failed: FlashWindowEx failed with -559038737 === W2K3R2SESP2 (32 bit win) === win.c:6753: Test failed: FlashWindowEx succeeded win.c:6764: Test failed: FlashWindowEx failed with -559038737 === WVISTAADM (32 bit win) === win.c:6753: Test failed: FlashWindowEx succeeded win.c:6764: Test failed: FlashWindowEx failed with -559038737 === W2K8SE (32 bit win) === win.c:6753: Test failed: FlashWindowEx succeeded win.c:6764: Test failed: FlashWindowEx failed with -559038737 === W7PRO (32 bit win) === win.c:6753: Test failed: FlashWindowEx succeeded win.c:6764: Test failed: FlashWindowEx failed with -559038737 === W7PROX64 (32 bit win) === win.c:6753: Test failed: FlashWindowEx succeeded win.c:6764: Test failed: FlashWindowEx failed with -559038737 === TEST64_W7SP1 (32 bit win) === win.c:6753: Test failed: FlashWindowEx succeeded win.c:6764: Test failed: FlashWindowEx failed with -559038737 === W7PROX64 (64 bit win) === win.c:6753: Test failed: FlashWindowEx succeeded win.c:6764: Test failed: FlashWindowEx failed with -559038737 === TEST64_W7SP1 (64 bit win) === win.c:6753: Test failed: FlashWindowEx succeeded win.c:6764: Test failed: FlashWindowEx failed with -559038737

1 0

Re: user32: Only call SetWindowPos() in UpdateLayeredWindowIndirect() if needed. (try 4)
by Dmitry Timoshkov 06 Feb '12

06 Feb '12

Adam Martinson <adam.r.martinson(a)gmail.com> wrote: > (We should not be calling SetWindowPos() in UpdateLayeredWindowIndirect() at all.) > Fixes bug 26924. That's not what I was asking about (a bunch of message tests with various parameters). Your current version essentially tests nothing. You should call UpdateLayeredWindowIndirect with a buch of differnt parameters, and check what message sequence they produce and how they change window state. See dlls/user32/tests/msg.c how to create a message test. -- Dmitry.

2 2

Re: [PATCH] [Kernel32]: added a couple of tests about console creation through CreateFile, and fix some corner cases
by Marvin 05 Feb '12

05 Feb '12

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=16816 Your paranoid android. === W7PRO (32 bit console) === console.c:1173: Test failed: Expected CreateFileW to succeed for index 0 console.c:1173: Test failed: Expected CreateFileW to succeed for index 2 console.c:1173: Test failed: Expected CreateFileW to succeed for index 7 console.c:1173: Test failed: Expected CreateFileW to succeed for index 9 === W7PROX64 (32 bit console) === console.c:1173: Test failed: Expected CreateFileW to succeed for index 0 console.c:1173: Test failed: Expected CreateFileW to succeed for index 2 console.c:1173: Test failed: Expected CreateFileW to succeed for index 7 console.c:1173: Test failed: Expected CreateFileW to succeed for index 9 === TEST64_W7SP1 (32 bit console) === console.c:1173: Test failed: Expected CreateFileW to succeed for index 0 console.c:1173: Test failed: Expected CreateFileW to succeed for index 2 console.c:1173: Test failed: Expected CreateFileW to succeed for index 7 console.c:1173: Test failed: Expected CreateFileW to succeed for index 9 === W7PROX64 (64 bit console) === console.c:1173: Test failed: Expected CreateFileW to succeed for index 0 console.c:1173: Test failed: Expected CreateFileW to succeed for index 2 console.c:1173: Test failed: Expected CreateFileW to succeed for index 7 console.c:1173: Test failed: Expected CreateFileW to succeed for index 9 === TEST64_W7SP1 (64 bit console) === console.c:1173: Test failed: Expected CreateFileW to succeed for index 0 console.c:1173: Test failed: Expected CreateFileW to succeed for index 2 console.c:1173: Test failed: Expected CreateFileW to succeed for index 7 console.c:1173: Test failed: Expected CreateFileW to succeed for index 9

1 0

Skype support status
by Artem S. Tashkinov 05 Feb '12

05 Feb '12

Hello everyone, It's not a secret that Skype was bought by Microsoft a few months back and that there's a great chance that its native Linux version will get even fewer updates in the future because I doubt that Microsoft is even remotely endorse the existence of Linux and open source, thus Skype may easily become a "burden" they don't want to bear. Another quite important fact to consider is that the Linux version of Skype has fewer features than its Windows counterpart and that there are multiple issues regarding Skype, like the absence of a native 64bit version and a number of quite serious bugs (crashes, exclusive sound card access preventing other applications from working, 100% CPU usage after hibernation/sleep). Currently under Wine 1.4-rc2 I wasn't able to even run any version of Skype even in a simple chat mode. Very old versions of Skype cannot get online, more recent ones crash when trying to get online, or crash when you just start them, the last few releases (5.5-5.8) use MSHTML as their logon form and the way it behaves under Wine you cannot make use of it. I know that Codeweavers resources are very limited and that your priorities and the priority of other programmers hacking Wine are mostly concerned about getting proper support for core Windows applications like MS Office, Adobe products and other crucial programs, but I think it would be wise to make even basic Skype functionality work, because there are operating systems other than Windows, MacOS (iOS), and Linux (Android) and many people are left without one of the most popular messengers in the world. In short this message is a cry for getting Skype to work _at all_, because now it's totally unusable. With respect, Artem S. Tashkinov

1 0

Re: kernel32: Add LCMapStringEx implementation and test it reusing tests from LCMapStringW (try 2)
by Dmitry Timoshkov 05 Feb '12

05 Feb '12

André Hentschel <nerv(a)dawncrow.de> wrote: > +@ stdcall LCMapStringEx(long long wstr long ptr long ptr ptr long) ... > +INT WINAPI LCMapStringEx(LPCWSTR name, DWORD flags, LPCWSTR src, INT srclen, LPWSTR dst, INT dstlen, > + LPNLSVERSIONINFO version, LPVOID reserved, LPARAM lparam) .spec file entry doesn't match the implementation. -- Dmitry.

1 0

Re: kernel32: Add LCMapStringEx implementation and test it reusing tests from LCMapStringW
by Dmitry Timoshkov 05 Feb '12

05 Feb '12

André Hentschel <nerv(a)dawncrow.de> wrote: > +/* Locale name special values */ > +#define LOCALE_NAME_INVARIANT L"" > +#define LOCALE_NAME_MAX_LENGTH 85 > +#define LOCALE_NAME_SYSTEM_DEFAULT L"!sys-default-locale" > +#define LOCALE_NAME_USER_DEFAULT NULL Have a look how unicode constants are defined in other header files, the above version can't work in Wine. Also just duplicating LCMapString tests is not a very good idea, it would be better to find a way to share the test data. -- Dmitry.

2 2

Re: ntdll: Remove dead code
by Marcus Meissner 05 Feb '12

05 Feb '12

On Sun, Feb 05, 2012 at 03:59:44PM +0100, André Hentschel wrote: > --- > dlls/ntdll/signal_x86_64.c | 4 ---- > 1 files changed, 0 insertions(+), 4 deletions(-) > > diff --git a/dlls/ntdll/signal_x86_64.c b/dlls/ntdll/signal_x86_64.c > index 0fc53c7..e9cefb8 100644 > --- a/dlls/ntdll/signal_x86_64.c > +++ b/dlls/ntdll/signal_x86_64.c > @@ -2629,10 +2629,6 @@ static BOOL is_inside_epilog( BYTE *pc ) > > for (;;) > { > - BYTE rex = 0; > - > - if ((*pc & 0xf0) == 0x40) rex = *pc++ & 0x0f; /* rex prefix */ > - This is not OK I think. The pc++ side effect is removed ... and is not handled in the switch() below. Ciao, Marcus

1 0

Re: user32: Only call SetWindowPos() in UpdateLayeredWindowIndirect() if needed. (try 3)
by Dmitry Timoshkov 04 Feb '12

04 Feb '12

Adam Martinson <adam.r.martinson(a)gmail.com> wrote: > +static HDC (WINAPI *pGetWindowDC)(HWND hWnd); > +static int (WINAPI *pReleaseDC)(HWND hWnd,HDC hDC); There is no need to dynamically import these APIs, they are always available. > +static DWORD WINAPI test_ulw_thread(void *data) > +{ > + struct test_ulw_tdata *tdata = data; > + DWORD res; > + > + res = WaitForSingleObject( tdata->hSem, 1000 ); > + ok( !res, "wait for semaphore failed: %08x\n", res ); > + if (!res) > + { > + HDC hdc = pGetWindowDC( tdata->hwnd ); > + res = pUpdateLayeredWindow( tdata->hwnd, 0, NULL, tdata->psz, hdc, tdata->ppt, 0, NULL, ULW_OPAQUE ); > + ok( res, "UpdateLayeredWindow failed: %08x\n", GetLastError() ); > + pReleaseDC( tdata->hwnd, hdc ); > + } > + > + return res; > +} I don't see how this is supposed to test what you presumably are trying to fix. A bunch of message tests that calls UpdateLayeredWindow with various flags and parameters and compares window extents before and after the call would be more convincing IMO. -- Dmitry.

1 0

re: Wine automated testing update
by Dan Kegel 03 Feb '12

03 Feb '12

Jeremy wrote: > the VMWare folks are not willing to provide a permanent license for VMWare to us. > > So, we've shifted gears, and are exploring whether something like qemu + > kvm would be a sufficient alternate. What's the plan for automated MacOSX testing? I hear 10.7 supports running in a VM...

3 2

Re: [2/3] msi: Use the return value of IXMLDOMNode_get_text (clang).
by Juan Lang 03 Feb '12

03 Feb '12

Hi Hans, hr = IXMLDOMNode_get_text( node, &s ); IXMLDOMNode_Release( node ); - if (!strcmpW( s, product_code )) r = ERROR_SUCCESS; - SysFreeString(s); + if (hr == S_OK && !strcmpW( s, product_code )) r = ERROR_SUCCESS; + SysFreeString( s ); Is it really safe to free s if IXMLDOMNode_get_text failed? --Juan

1 0

Re: quartz: AMFilterData_ParseFilterData returns a pointer to a pointer to filter data
by Dmitry Timoshkov 03 Feb '12

03 Feb '12

Aric Stewart <aric(a)codeweavers.com> wrote: > - REGFILTER2 *prf2; > + static REGFILTER2 *prf2; What's the point of this change? -- Dmitry.

3 2

Re: gdi32/tests: Add tests for default font selection.
by Marvin 03 Feb '12

03 Feb '12

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=16799 Your paranoid android. === W2KPROSP4 (32 bit font) === font.c:4145: Test failed: expected vertical face, got System === WXPPROSP3 (32 bit font) === font.c:4145: Test failed: expected vertical face, got System === W2K3R2SESP2 (32 bit font) === font.c:4145: Test failed: expected vertical face, got System

1 0

Profiing windows apps
by Ralph Little 02 Feb '12

02 Feb '12

Hi, I'm looking at bug #9672 again in the The Sims. The app crashes early on during initialisation in DirectDraw. The problem occurs after CreateSurface returns an error, since it would appear that the DDSURFACEDESC passed into the call is foobar. This would lead me to conclude that something on the lead up to that call is precipitating that rogue call. I have a legal Windows XP and I wish to trace the calls leading up to this point with real Windows/DirectX to compare with what is happening to Wine so that I can assess what is upsetting the application, since I can't see anything in the Wine trace prior to that that looks suspicious. Does anyone have any experience with tracing apps in real Windows in the context of Wine development? Should I use a profiler or is there a simpler method? Cheers, Ralph

3 5

Re: [PATCH 1/2] ddraw/tests: Add some IDirect3DViewport interface tests (try 2)
by Henri Verbeet 02 Feb '12

02 Feb '12

On 2 February 2012 14:57, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > +static ULONG get_refcount(IUnknown *test_iface) > +{ > + IUnknown_AddRef(test_iface); > + return IUnknown_Release(test_iface); > +} ... > + LONG ref; ... > + ref = get_refcount((IUnknown *)d3d); > + ok(ref == 2, "IDirect3D refcount is %d\n", ref); Well yeah, get_refcount() returns ULONG now, but you should fix the type of "ref" and the format strings as well.

2 1

Re: [PATCH 1/2] ddraw/tests: Add some IDirect3DViewport interface tests (try 2)
by Marvin 02 Feb '12

02 Feb '12

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=16784 Your paranoid android. === WNT4WSSP6 (32 bit ddraw2) === ddraw2.c:421: Test failed: Got unexpected count 3. ddraw2.c:430: Test failed: Got unexpected clip rect {14, 33, 646, 237}, expected {14, 33, 646, 486}.

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