March 2013 - Wine-Bugs - list.winehq.org

[Bug 28069] Skype 5.5: Fails to launch after installation from msi with: Failed to get proc address for DnsFree (DNSAPI.dll)

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=28069 Bruno Jesus <00cpxxx(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |8a29a4a66776a1d8bb963d4092c | |b7d6a9af0b932 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

March 1, 2013

[Bug 12501] Multiple application installers need mspatcha.dll ApplyPatchToFileW implementation (Microsoft Delta Compression API)

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=12501 Detlef Riekenberg <wine.dev(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wine.dev(a)web.de -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

March 1, 2013

[Bug 28069] Skype 5.5: Fails to launch after installation from msi with: Failed to get proc address for DnsFree (DNSAPI.dll)

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=28069 --- Comment #8 from c.perin(a)live.fr 2013-03-01 08:18:43 CST --- Created attachment 43752 --> http://bugs.winehq.org/attachment.cgi?id=43752 patch skype -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

March 1, 2013

[Bug 25435] MS Access 2007 will not open any wizard.

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=25435 Jonathan <jcv1897(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jcv1897(a)gmail.com --- Comment #13 from Jonathan <jcv1897(a)gmail.com> 2013-03-01 07:49:35 CST --- I had the same problem. Templates wouldn't import and wizards would be blank and frozen. I have wine 1.4.1 installed and winetricks. I added a manual override the oleauth32 dll in winecfg, and ran winetricks vb6run jet40. That solved the problem for me. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

March 1, 2013

[Bug 30033] Office 2010 Standard, Pro Plus: Volume activation fails

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=30033 fincer89(a)hotmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fincer89(a)hotmail.com --- Comment #21 from fincer89(a)hotmail.com 2013-03-01 06:59:49 CST --- Confinming. The bug exists in version 1.5.24. I am unable to activate my Office 2010 installation. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

March 1, 2013

[Bug 32910] QQImage crashes when exiting it

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=32910 --- Comment #4 from Qian Hong <fracting(a)gmail.com> 2013-03-01 04:45:27 CST --- Created attachment 43751 --> http://bugs.winehq.org/attachment.cgi?id=43751 Hack: don't free interface when release This hack prevent the crashing. I'm not sure if it is a Wine bug or an App bug yet. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

March 1, 2013

[Bug 27003] Latest gnutls breaks wine ssl support

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=27003 Jacek Caban <jacek(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jacek(a)codeweavers.com --- Comment #4 from Jacek Caban <jacek(a)codeweavers.com> 2013-03-01 04:35:12 CST --- That's the status of this bug? Does AtchLinux still build Wine without GnuTLS support? That's a more serious problem now that winhttp uses GnuTLS via secur32, and will be even more serious soon, when wininet will switch. Given that it's been a while and that's the only report of the original problem, it sounds a lot like ArchLinux's bug. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

March 1, 2013

[Bug 33045] Bunch of Heroes freezing on start at the beginning of the intro video

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=33045 --- Comment #4 from Jörg Höhle <hoehle(a)users.sourceforge.net> 2013-03-01 04:05:13 CST --- >IOW, fix bug #TODO. That's bug #28464, comment #6. That would also prevent a possible dead-lock in win16 apps, because waveOut16 is not expected to use ReleaseThunkLock, unlike e.g. waveOutReset16 and all functions that can provoke a callback. http://source.winehq.org/source//dlls/mmsystem.dll16/mmsystem.c -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

March 1, 2013

[Bug 33045] Bunch of Heroes freezing on start at the beginning of the intro video

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=33045 Jörg Höhle <hoehle(a)users.sourceforge.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source --- Comment #3 from Jörg Höhle <hoehle(a)users.sourceforge.net> 2013-03-01 03:56:22 CST --- >Is the number of bytes not a multiple of nBlockAlign? That's it! Following an intuition, I added -1 to the one line in our winmm/wave tests "make sure fragment length is a multiple of block size" and got a deadlock resembling yours. There are 2 winmm tests that have been on my TODO list for long: 1. Tests with length not a multiple of block size ;-) 2. Tests involving WHDR_BEGIN&ENDLOOP. I'm convinced that native winmm operates at the level of bytes, not frames. That's what I derive from my overflow tests (see bug #23079, comment #4), performed on w95. Not having to consider block size also makes chaining ACM codecs somewhat easier: just operate on a stream of bytes. We need a fix to the MarkDoneHeaders/PushData pair. Things to consider: 1. Perform tests with length not a multiple of block size. 2. Investigate what native does with trailing bytes in case of underrun. - Throw away? - Do they prevent buffer notification, awaiting more bytes from the next header to complete a frame? That is a hairy situation! - Do they count in GetPosition? Alas, this mostly requires audible tests, not testbot. 3. Make MarkDoneHeaders optional, such that waveOutWrite -> BeginPlaying -> PushData(nomark) DevicesThreadProc -> PushData(mark&notify) IOW, fix bug #TODO. Ensure that PushData does not depend on state variables changes performed in the mark phase. I've had this change in mind for some time, but it's precisely the complicated logic in those two functions that prevented it. I ended up never reviewing this part of winmm. 4. Document the invariants. When is device->loop_start invalid? When is device->last invalid? 5. Safe guard against rogue IAC_GetPosition in MarkDone. Currently it seems that a header can be put into the notification list, yet still be referenced from device->playing. 6. WHDR_ENDLOOP is queried in 3 places. Have the code of all those similar, such that it becomes obvious that they all implement the same behaviour. - What about WHDR_ENDLOOP without BEGINLOOP? - What about consecutive WHDR_BEGINLOOP? - What about BEGINLOOP|ENDLOOP in one header? - What about BEGIN ... BEGIN|END ... END? - Handle BEGIN ... END ... BEGIN ... END well. Be careful about loops. One of my notes is that I suspect MarkDoneHeaders incorrect with waveOutBreakLoop & several loops, e.g. one already played and one playing. There are two traversals of the header list. One based on GetPosition (clock_frames), the other based on Get/ReleaseBuffer (queue_frames). Clearly, both cannot share the same device->loop_counter. I like Andrew's idea of a MarkDoneHeaders distinct from PushData. The code just needs to step the "done" and "playing" pointers into the header list more carefully. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

March 1, 2013

[Bug 23079] Track the number of audio bytes played as a 64 bit number

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=23079 Jörg Höhle <hoehle(a)users.sourceforge.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hoehle(a)users.sourceforge.ne | |t --- Comment #4 from Jörg Höhle <hoehle(a)users.sourceforge.net> 2013-03-01 03:47:44 CST --- Audio misbehaviour after a few days is still relevant, see http://www.winehq.org/pipermail/wine-devel/2013-February/098880.html There's also bug #26968 about foobar2000 stopping audio within 4-7 days. An overflow can occur within each of Wine's 3 audio layers: mmdevapi, winmm and DSound. Some patches were committed or submitted recently and more are to come. I distinguish internal from external (i.e. visible at the API) overflow. Some API function may overflow, e.g. GetPosition, yet the driver still produce steady output. Of course, API layering causes one layer's external API overflow (mmdevapi:GetPosition) to possibly break the next API's internal logic (e.g. winmm). I instrumented the winmm/wave tests to play forever with 3 buffers. - A w95 machine produced steady output for several days, despite several "missing WOM_DONE notification" (when the HD would resume from sleep?). Actually, I only listened from time to time, thus I don't know if the missed notifications caused a glitch. - I aborted a Linux ALSA box after 1-2 days to compile more of Wine, audio output was good, no warning. - After some while, MacOS 10.6.8 output clicked periodically as if playing from a single buffer. Some day later, there was no output at all. There were several "missing WOM_DONE notification". However, the Mac regularly entered suspend/resume cycles and that may have disturbed the tests. That driver needs more work. This is part of the w95 log: Time is from GetTickCount() (i.e. milliseconds) wave.c:779: Playing 1 second 440Hz tone at 48000x16x2 3 headers 0 loops 192000 bytes WAVE_FORMAT_PCM CALLBACK_EVENT wave.c:519: waveOutGetPosition(0): TIME_MS not supported, returned TIME_SAMPLES wave.c:609: Test failed: At 200608 from -1 to 71940 bytes -- just wave.c:605: Test failed: At 200608 from -1 to 18059 samples-- starting wave.c:596: Test failed: At 200608 time format changed from 1 to 2, value 18131 -- no milliseconds wave.c:609: Test failed: At 22567671 from -47352 to 36724 bytes wave.c:605: Test failed: At 22567671 from 1073729992 to 9181 samples wave.c:605: Test failed: At 22567671 from 1073729996 to 9181 samples wave.c:850: Test failed: missing WOM_DONE notification [9 times] wave.c:609: Test failed: At 45142970 from -47312 to 49428 bytes wave.c:605: Test failed: At 45142970 from 1073729996 to 12357 samples wave.c:605: Test failed: At 45142970 from 1073729996 to 12357 samples wave.c:850: Test failed: missing WOM_DONE notification [many times] wave.c:609: Test failed: At 68401620 from -21908 to 56852 bytes wave.c:605: Test failed: At 68401620 from 1073736347 to 22528 samples wave.c:605: Test failed: At 68401620 from 1073736347 to 22528 samples [...] wave.c:609: Test failed: At 325172108 from -46132 to 25860 bytes wave.c:605: Test failed: At 325172108 from 1073730291 to 14464 samples wave.c:605: Test failed: At 325172108 from 1073730291 to 14464 samples As you can see, w95 counts in bytes and derives samples from bytes. As the byte counter overflows, the number of samples is reset, never reaching the 32bit limit! Apps playing for several days must consider that. As the writer of an app playing with some unknown ACM codec, I would not know how far I am when using samples. With bytes, I could add 2^32 when detecting a wrap-around -- or write my code such that wrap-arounds don't cause breaks. Linux counts differently: wave.c:779: Playing 1 second 440Hz tone at 96000x16x2 3 headers 0 loops 384000 bytes WAVE_FORMAT_PCM CALLBACK_EVENT wave.c:609: Test failed: At 692163206 from -1 to 194048 bytes wave.c:605: Test failed: At 692163206 from -1 to 48512 samples wave.c:601: Test failed: At 692163206 from -1 to 505 ms wave.c:609: Test failed: At 703348338 from -109056 to 13824 bytes wave.c:609: Test failed: At 714533348 from -43520 to 87552 bytes wave.c:609: Test failed: At 725717953 from -100864 to 30208 bytes wave.c:609: Test failed: At 736904392 from -18944 to 103936 bytes wave.c:605: Test failed: At 736904392 from -4736 to 25984 samples wave.c:601: Test failed: At 736904392 from 44739193 to 270 ms - simultaneously wave.c:609: Test failed: At 748089576 from -76288 to 46592 bytes wave.c:609: Test failed: At 759274628 from -10752 to 120320 bytes You see that Linux counts in samples. Bytes grow 4 times faster and overflow more often. time_ms is derived from samples and reset as samples overflow, never growing beyond 45 million milliseconds despite playing longer. I want to perform more tests and check whether winmm:wave* GetPosition supports milliseconds at all, even on w7. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

March 1, 2013