November 2009 - Wine-Devel - list.winehq.org

Re: today's git broke winetricks gecko :-(

by Ben Klein

2009/11/13 Jacek Caban <jacek(a)codeweavers.com>: > Downloading Gecko on the first use is technically a pain. I argue that forcing all of Wine to *depend* on wine-gecko is more of a pain ... > We constantly have bugs from users complaining about > it they are resolved as invalid. ... however I do understand this. > I've even considered removing the whole downloader, > but after a talk with Alexandre we decided to try with the > current solution. Any chance of including gecko in the git repository?

Nov. 13, 2009

Re: today's git broke winetricks gecko :-(

by Jacek Caban

Dan Kegel wrote: > On Thu, Nov 12, 2009 at 12:50 PM, Dan Kegel <dank(a)kegel.com> wrote: > >> That kind of makes sense. As long as you don't break >> the ability to run commandline apps without X, I'm ok. >> (I just checked, it's still fine.) >> > > Whoops, I checked on a system with your change reverted. > I'll check again on a current system when I get a chance > (this system's in the middle of a chromium valgrind test run). > I've just checked and it works fine for me. Jacek

Nov. 12, 2009

Re: today's git broke winetricks gecko :-(

by Jacek Caban

Dan Kegel wrote: > On Thu, Nov 12, 2009 at 12:14 PM, Jacek Caban <jacek(a)codeweavers.com> wrote: > >> The question is why people are using winetricks for installing Gecko. >> > > Do we have a scorecard showing which distros package Wine properly? > > AFAIK we don't. I've just created a list on: http://wiki.winehq.org/Gecko I know that Gentoo is not the only distribution that packages it, but I don't want to add info about distributions that I've never seen working myself. Thanks, Jacek

Nov. 12, 2009

Re: today's git broke winetricks gecko :-(

by Tom Wickline

On Fri, Nov 13, 2009 at 4:23 AM, Jacek Caban <jacek(a)codeweavers.com> wrote: > Tom Wickline wrote: > > >> >> On Fri, Nov 13, 2009 at 3:44 AM, Jacek Caban <jacek(a)codeweavers.com<mailto: >> jacek(a)codeweavers.com>> wrote: >> >> The plan is that winetricks should not be used for installing Gecko. >> >> >> So you intentionally broke it? >> > > No, I was actually fixing the bug that caused the downloader to crash as > you described. > Thanks! Tom > > Jacek >

Nov. 12, 2009

Re: today's git broke winetricks gecko :-(

by Dan Kegel

On Thu, Nov 12, 2009 at 12:50 PM, Dan Kegel <dank(a)kegel.com> wrote: > That kind of makes sense. As long as you don't break > the ability to run commandline apps without X, I'm ok. > (I just checked, it's still fine.) Whoops, I checked on a system with your change reverted. I'll check again on a current system when I get a chance (this system's in the middle of a chromium valgrind test run).

Nov. 12, 2009

Re: today's git broke winetricks gecko :-(

by Dan Kegel

On Thu, Nov 12, 2009 at 12:14 PM, Jacek Caban <jacek(a)codeweavers.com> wrote: > Downloading Gecko on the first use is technically a pain. It can't work > correctly unless we'd freeze the whole app. We constantly have bugs from > users complaining about it they are resolved as invalid. I've even > considered removing the whole downloader, but after a talk with Alexandre we > decided to try with the current solution. That kind of makes sense. As long as you don't break the ability to run commandline apps without X, I'm ok. (I just checked, it's still fine.) > The question is why people are using winetricks for installing Gecko. Do we have a scorecard showing which distros package Wine properly? - Dan

Nov. 12, 2009

Re: today's git broke winetricks gecko :-(

by Jacek Caban

Hi again, I think I should make it cleaner: *The change wasn't meant against winetricks. I didn't even think of it when I was writing the patch, but I don't think it's a reason to revert my patch.* Thanks, Jacek

Nov. 12, 2009

Re: today's git broke winetricks gecko :-(

by Jacek Caban

Tom Wickline wrote: > > > On Fri, Nov 13, 2009 at 3:44 AM, Jacek Caban <jacek(a)codeweavers.com > <mailto:jacek(a)codeweavers.com>> wrote: > > The plan is that winetricks should not be used for installing Gecko. > > > So you intentionally broke it? No, I was actually fixing the bug that caused the downloader to crash as you described. The downloader was *accidentally* broken some time ago and then I've decided that we need a better solution. That's why it was broken for a while. I didn't want to fix something that is broken by design. Jacek

Nov. 12, 2009

Re: today's git broke winetricks gecko :-(

by Jacek Caban

Dan Kegel wrote: > On Thu, Nov 12, 2009 at 11:44 AM, Jacek Caban <jacek(a)codeweavers.com> wrote: > >>> as of today, "winetricks gecko" triggers the download >>> dialog box :-( >>> >> The plan is that winetricks should not be used for installing Gecko. Users >> really should use packagers. People compiling Wine themselves should read >> this: >> http://wiki.winehq.org/Gecko >> If it's not clear enough, we should fix it. >> > > Those users are already accustomed to using > winetricks, so I should probably make 'winetricks gecko' > implement those steps. Sadly, that means it will have to > use sudo, which is kind of ugly. > > I'm sad that this change happened; it makes things harder for > me. I can't figure out why gecko is needed for, say, cmd. > > Why did you make that change? > > For now I've reverted the change locally until I > implement the sudo-ized gecko verb Downloading Gecko on the first use is technically a pain. It can't work correctly unless we'd freeze the whole app. We constantly have bugs from users complaining about it they are resolved as invalid. I've even considered removing the whole downloader, but after a talk with Alexandre we decided to try with the current solution. It wasn't meant against winetricks. The question is why people are using winetricks for installing Gecko. Users should not notice this change if both wine and gecko are packaged correctly. I also believe that downloading manually Gecko once per a few months is not too much pain for developers. And if you have it correctly installed in Linux, you don't have to care about it every time you create a new wineprefix. BTW, users use it with no understanding. I've seen things like 'winetricks gecko ie6' which obviously doesn't make sense. I wouldn't be surprised if most of these users already had gecko installed. Thanks, Jacek

Nov. 12, 2009

Re: today's git broke winetricks gecko :-(

by Tom Wickline

On Fri, Nov 13, 2009 at 3:44 AM, Jacek Caban <jacek(a)codeweavers.com> wrote: > The plan is that winetricks should not be used for installing Gecko. > So you intentionally broke it? The Gecko install in 1.1.32 is a total *POS* as it stands, everytime it tries to install it crashes, at least I can install it with winetricks.. Well at least we could in the past! tom(a)tom-laptop:~$ winecfg wine: created the configuration directory '/home/tom/.wine' err:alsa:ALSA_CheckSetVolume Could not find 'PCM Playback Volume' element err:alsa:ALSA_CheckSetVolume Could not find 'PCM Playback Volume' element fixme:mixer:ALSA_MixerInit No master control found on ATI IXP Modem, disabling mixer Could not load wine-gecko. HTML rendering will be disabled. wine: configuration in '/home/tom/.wine' has been updated. err:alsa:ALSA_CheckSetVolume Could not find 'PCM Playback Volume' element err:alsa:ALSA_CheckSetVolume Could not find 'PCM Playback Volume' element fixme:mixer:ALSA_MixerInit No master control found on ATI IXP Modem, disabling mixer tom(a)tom-laptop:~$ wine iexplore fixme:ole:CoResumeClassObjects stub fixme:urlmon:URLMoniker_BindToObject use running object table fixme:shdocvw:BindStatusCallback_OnProgress status code 1 fixme:shdocvw:BindStatusCallback_OnProgress status code 2 fixme:shdocvw:BindStatusCallback_OnProgress status code 11 fixme:shdocvw:BindStatusCallback_OnProgress status code 5 wine: Unhandled page fault on read access to 0x00000000 at address 0x7e1f0313 (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x7e1f0313). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:7e1f0313 ESP:0032df20 EBP:0032df58 EFLAGS:00010202( R- -- I - - - ) EAX:00000000 EBX:7e243c2c ECX:7e243c2c EDX:0032df44 ESI:00181b78 EDI:00181b78 Stack dump: 0x0032df20: 00000000 00000000 0032df88 00000000 0x0032df30: 00181b78 00110000 0000000a 7e1bb1c0 0x0032df40: 00000000 00000000 00110014 7e243c2c 0x0032df50: 00181b78 00000000 0032df88 7e1f22c8 0x0032df60: 00181b78 00181b88 7e2514d4 7e1b7e9e 0x0032df70: 00181db0 00181d8c 00181b88 7e243c2c Backtrace: =>0 0x7e1f0313 update_window_doc+0x23() in mshtml (0x0032df58) 1 0x7e1f22c8 HTMLWindow_Create+0xb8() in mshtml (0x0032df88) 2 0x7e1baf2e HTMLDocument_Create+0x1be() in mshtml (0x0032dfe8) 3 0x7e1f4bb0 in mshtml (+0x54bb0) (0x0032e008) 4 0x7e4e5a54 CoCreateInstance+0x1c4() in ole32 (0x0032e068) 5 0x7e30fe46 in urlmon (+0xfe46) (0x0032e108) 6 0x7e31027c in urlmon (+0x1027c) (0x0032e148) 7 0x7e314ab4 in urlmon (+0x14ab4) (0x0032e9a8) 8 0x7e314e1e in urlmon (+0x14e1e) (0x0032e9c8) 9 0x7e31310b in urlmon (+0x1310b) (0x0032e9f8) 10 0x7ebc19ba WINPROC_wrapper+0x1a() in user32 (0x0032ea28) 11 0x7ebc207e WINPROC_wrapper+0x6de() in user32 (0x0032ea68) 12 0x7ebc73ab in user32 (+0xb73ab) (0x0032eaa8) 13 0x7eb88e9e DispatchMessageW+0x9e() in user32 (0x0032eb98) 14 0x7eb56321 in user32 (+0x46321) (0x0032ebe8) 15 0x7eb56537 DialogBoxParamW+0x87() in user32 (0x0032ec08) 16 0x7e1f41c1 install_wine_gecko+0x391() in mshtml (0x0032ec78) 17 0x7e1fdc7d load_gecko+0x10d() in mshtml (0x0032f0f8) 18 0x7e1fe6c5 NSContainer_Create+0x25() in mshtml (0x0032f158) 19 0x7e1baec1 HTMLDocument_Create+0x151() in mshtml (0x0032f1b8) 20 0x7e1f4bb0 in mshtml (+0x54bb0) (0x0032f1d8) 21 0x7e4e5a54 CoCreateInstance+0x1c4() in ole32 (0x0032f238) 22 0x7e30fe46 in urlmon (+0xfe46) (0x0032f2d8) 23 0x7e31027c in urlmon (+0x1027c) (0x0032f318) 24 0x7e314ab4 in urlmon (+0x14ab4) (0x0032fb78) 25 0x7e314e1e in urlmon (+0x14e1e) (0x0032fb98) 26 0x7e31310b in urlmon (+0x1310b) (0x0032fbc8) 27 0x7ebc19ba WINPROC_wrapper+0x1a() in user32 (0x0032fbf8) 28 0x7ebc207e WINPROC_wrapper+0x6de() in user32 (0x0032fc38) 29 0x7ebc73ab in user32 (+0xb73ab) (0x0032fc78) 30 0x7eb88e9e DispatchMessageW+0x9e() in user32 (0x0032fd68) 31 0x7ee45953 IEWinMain+0x153() in shdocvw (0x0032fde8) 32 0x7ee7b504 WinMain+0x24() in iexplore (0x0032fe08) 33 0x7ee7b645 main+0xa5() in iexplore (0x0032fe88) 34 0x7ee7b567 in iexplore (+0xb567) (0x0032feb8) 35 0x7b875305 in kernel32 (+0x55305) (0x0032fee8) 36 0x7bc6ae74 call_thread_func+0xc() in ntdll (0x0032fef8) 37 0x7bc6ce51 in ntdll (+0x5ce51) (0x0032ffc8) 38 0x7bc4820a in ntdll (+0x3820a) (0x0032ffe8) 0x7e1f0313 update_window_doc+0x23 in mshtml: movl 0x0(%eax),%ecx Modules: Module Address Debug info Name (76 modules) ELF 7b800000-7b96e000 Export kernel32<elf> \-PE 7b820000-7b96e000 \ kernel32 ELF 7bc00000-7bcaf000 Export ntdll<elf> \-PE 7bc10000-7bcaf000 \ ntdll ELF 7bf00000-7bf03000 Deferred <wine-loader> ELF 7e182000-7e18d000 Deferred libgcc_s.so.1 ELF 7e18d000-7e252000 Export mshtml<elf> \-PE 7e1a0000-7e252000 \ mshtml ELF 7e252000-7e265000 Deferred libresolv.so.2 ELF 7e265000-7e26b000 Deferred libnss_dns.so.2 ELF 7e26b000-7e26e000 Deferred libnss_mdns4_minimal.so.2 ELF 7e27f000-7e2a1000 Deferred mpr<elf> \-PE 7e290000-7e2a1000 \ mpr ELF 7e2a1000-7e2f7000 Deferred wininet<elf> \-PE 7e2b0000-7e2f7000 \ wininet ELF 7e2f7000-7e33c000 Export urlmon<elf> \-PE 7e300000-7e33c000 \ urlmon ELF 7e33c000-7e41b000 Deferred oleaut32<elf> \-PE 7e350000-7e41b000 \ oleaut32 ELF 7e43f000-7e4aa000 Deferred rpcrt4<elf> \-PE 7e450000-7e4aa000 \ rpcrt4 ELF 7e4aa000-7e5a2000 Export ole32<elf> \-PE 7e4c0000-7e5a2000 \ ole32 ELF 7e5cc000-7e5ff000 Deferred uxtheme<elf> \-PE 7e5d0000-7e5ff000 \ uxtheme ELF 7e5ff000-7e608000 Deferred libxcursor.so.1 ELF 7e608000-7e60d000 Deferred libxfixes.so.3 ELF 7e60d000-7e610000 Deferred libxcomposite.so.1 ELF 7e610000-7e616000 Deferred libxrandr.so.2 ELF 7e616000-7e61e000 Deferred libxrender.so.1 ELF 7e61e000-7e623000 Deferred libxxf86vm.so.1 ELF 7e623000-7e626000 Deferred libxinerama.so.1 ELF 7e626000-7e646000 Deferred imm32<elf> \-PE 7e630000-7e646000 \ imm32 ELF 7e646000-7e64b000 Deferred libxdmcp.so.6 ELF 7e64b000-7e663000 Deferred libxcb.so.1 ELF 7e663000-7e666000 Deferred libxau.so.6 ELF 7e666000-7e74d000 Deferred libx11.so.6 ELF 7e74d000-7e75b000 Deferred libxext.so.6 ELF 7e75b000-7e773000 Deferred libice.so.6 ELF 7e773000-7e77b000 Deferred libsm.so.6 ELF 7e78c000-7e827000 Deferred winex11<elf> \-PE 7e7a0000-7e827000 \ winex11 ELF 7e83a000-7e85b000 Deferred libexpat.so.1 ELF 7e85b000-7e885000 Deferred libfontconfig.so.1 ELF 7e885000-7e887000 Deferred libxcb-xlib.so.0 ELF 7e896000-7e8ab000 Deferred libz.so.1 ELF 7e8ab000-7e918000 Deferred libfreetype.so.6 ELF 7e929000-7e93d000 Deferred system.drv16.so PE 7e930000-7e93d000 Deferred system.drv16 ELF 7e93d000-7ea04000 Deferred comctl32<elf> \-PE 7e950000-7ea04000 \ comctl32 ELF 7ea04000-7ea5a000 Deferred advapi32<elf> \-PE 7ea10000-7ea5a000 \ advapi32 ELF 7ea5a000-7eaf9000 Deferred gdi32<elf> \-PE 7ea70000-7eaf9000 \ gdi32 ELF 7eaf9000-7ec3f000 Export user32<elf> \-PE 7eb10000-7ec3f000 \ user32 ELF 7ec3f000-7ec9a000 Deferred shlwapi<elf> \-PE 7ec50000-7ec9a000 \ shlwapi ELF 7ec9a000-7ee29000 Deferred shell32<elf> \-PE 7ecb0000-7ee29000 \ shell32 ELF 7ee29000-7ee6a000 Export shdocvw<elf> \-PE 7ee30000-7ee6a000 \ shdocvw ELF 7ee6a000-7ee7d000 Export iexplore<elf> \-PE 7ee70000-7ee7d000 \ iexplore ELF 7ef9d000-7efa8000 Deferred libnss_files.so.2 ELF 7efa8000-7efb2000 Deferred libnss_nis.so.2 ELF 7efb2000-7efca000 Deferred libnsl.so.1 ELF 7efca000-7efef000 Deferred libm.so.6 ELF 7eff7000-7f000000 Deferred libnss_compat.so.2 ELF b7c51000-b7c55000 Deferred libdl.so.2 ELF b7c55000-b7da4000 Deferred libc.so.6 ELF b7da5000-b7dbd000 Deferred libpthread.so.0 ELF b7dce000-b7f09000 Deferred libwine.so.1 ELF b7f0b000-b7f27000 Deferred ld-linux.so.2 Threads: process tid prio (all id:s are in hex) 00000008 (D) C:\windows\system32\iexplore.exe 0000001d 0 0000001b 0 0000001a 0 00000009 0 <== 0000000e 00000014 0 00000010 0 0000000f 0 00000011 00000017 0 00000016 0 00000013 0 00000012 0 00000018 00000019 0 Backtrace: =>0 0x7e1f0313 update_window_doc+0x23() in mshtml (0x0032df58) 1 0x7e1f22c8 HTMLWindow_Create+0xb8() in mshtml (0x0032df88) 2 0x7e1baf2e HTMLDocument_Create+0x1be() in mshtml (0x0032dfe8) 3 0x7e1f4bb0 in mshtml (+0x54bb0) (0x0032e008) 4 0x7e4e5a54 CoCreateInstance+0x1c4() in ole32 (0x0032e068) 5 0x7e30fe46 in urlmon (+0xfe46) (0x0032e108) 6 0x7e31027c in urlmon (+0x1027c) (0x0032e148) 7 0x7e314ab4 in urlmon (+0x14ab4) (0x0032e9a8) 8 0x7e314e1e in urlmon (+0x14e1e) (0x0032e9c8) 9 0x7e31310b in urlmon (+0x1310b) (0x0032e9f8) 10 0x7ebc19ba WINPROC_wrapper+0x1a() in user32 (0x0032ea28) 11 0x7ebc207e WINPROC_wrapper+0x6de() in user32 (0x0032ea68) 12 0x7ebc73ab in user32 (+0xb73ab) (0x0032eaa8) 13 0x7eb88e9e DispatchMessageW+0x9e() in user32 (0x0032eb98) 14 0x7eb56321 in user32 (+0x46321) (0x0032ebe8) 15 0x7eb56537 DialogBoxParamW+0x87() in user32 (0x0032ec08) 16 0x7e1f41c1 install_wine_gecko+0x391() in mshtml (0x0032ec78) 17 0x7e1fdc7d load_gecko+0x10d() in mshtml (0x0032f0f8) 18 0x7e1fe6c5 NSContainer_Create+0x25() in mshtml (0x0032f158) 19 0x7e1baec1 HTMLDocument_Create+0x151() in mshtml (0x0032f1b8) 20 0x7e1f4bb0 in mshtml (+0x54bb0) (0x0032f1d8) 21 0x7e4e5a54 CoCreateInstance+0x1c4() in ole32 (0x0032f238) 22 0x7e30fe46 in urlmon (+0xfe46) (0x0032f2d8) 23 0x7e31027c in urlmon (+0x1027c) (0x0032f318) 24 0x7e314ab4 in urlmon (+0x14ab4) (0x0032fb78) 25 0x7e314e1e in urlmon (+0x14e1e) (0x0032fb98) 26 0x7e31310b in urlmon (+0x1310b) (0x0032fbc8) 27 0x7ebc19ba WINPROC_wrapper+0x1a() in user32 (0x0032fbf8) 28 0x7ebc207e WINPROC_wrapper+0x6de() in user32 (0x0032fc38) 29 0x7ebc73ab in user32 (+0xb73ab) (0x0032fc78) 30 0x7eb88e9e DispatchMessageW+0x9e() in user32 (0x0032fd68) 31 0x7ee45953 IEWinMain+0x153() in shdocvw (0x0032fde8) 32 0x7ee7b504 WinMain+0x24() in iexplore (0x0032fe08) 33 0x7ee7b645 main+0xa5() in iexplore (0x0032fe88) 34 0x7ee7b567 in iexplore (+0xb567) (0x0032feb8) 35 0x7b875305 in kernel32 (+0x55305) (0x0032fee8) 36 0x7bc6ae74 call_thread_func+0xc() in ntdll (0x0032fef8) 37 0x7bc6ce51 in ntdll (+0x5ce51) (0x0032ffc8) 38 0x7bc4820a in ntdll (+0x3820a) (0x0032ffe8) Killed tom(a)tom-laptop:~$ *If it's not clear enough, we should fix it.* > > Thanks, > Jacek > > >

Nov. 12, 2009

Re: today's git broke winetricks gecko :-(

by Dan Kegel

On Thu, Nov 12, 2009 at 11:44 AM, Jacek Caban <jacek(a)codeweavers.com> wrote: >> as of today, "winetricks gecko" triggers the download >> dialog box :-( > > The plan is that winetricks should not be used for installing Gecko. Users > really should use packagers. People compiling Wine themselves should read > this: > http://wiki.winehq.org/Gecko > If it's not clear enough, we should fix it. Those users are already accustomed to using winetricks, so I should probably make 'winetricks gecko' implement those steps. Sadly, that means it will have to use sudo, which is kind of ugly. I'm sad that this change happened; it makes things harder for me. I can't figure out why gecko is needed for, say, cmd. Why did you make that change? For now I've reverted the change locally until I implement the sudo-ized gecko verb. - Dan

Nov. 12, 2009

Re: user32: Add argument check for PTITLEBARINFO in GetTitleBarInfo().

by Paul Vriens

On 11/12/2009 07:43 PM, Rico Schüller wrote: > + if(!tbi) { > + TRACE("Invalid TITLEBARINFO: %p\n", tbi); Hi Rico, So your printing the NULL pointer? -- Cheers, Paul.

Nov. 12, 2009

Re: today's git broke winetricks gecko :-(

by Jacek Caban

Hi Dan, Dan Kegel wrote: > Hi Jacek, > as of today, "winetricks gecko" triggers the download > dialog box :-( > Presumably this was caused by > http://www.winehq.org/pipermail/wine-cvs/2009-November/061489.html > > Even if I rearrange the script so there are no invocations > of wine before unpacking gecko, it still puts up > the dialog box when I run regedit to tell wine > about the gecko I unpacked! > > Got any suggestions? > The plan is that winetricks should not be used for installing Gecko. Users really should use packagers. People compiling Wine themselves should read this: http://wiki.winehq.org/Gecko If it's not clear enough, we should fix it. BTW, I've just noticed that we should also change the text in download dialog. Here is my proposal: "Wine could not find a Gecko package which is needed for applications embedding HTML to work correctly. Wine can automatically download and install it for you. Note: it's recommended to use distro packages instead. See http://wiki.winehq.org/Gecko for details." Any suggestions are welcome. Thanks, Jacek

Nov. 12, 2009

Re: today's git broke winetricks gecko :-(

by Dan Kegel

In fact, even the simple command wine cmd /c echo yes now downloads gecko. This doesn't seem right... On Thu, Nov 12, 2009 at 11:23 AM, Dan Kegel <dank(a)kegel.com> wrote: > Hi Jacek, > as of today, "winetricks gecko" triggers the download > dialog box :-( > Presumably this was caused by > http://www.winehq.org/pipermail/wine-cvs/2009-November/061489.html > > Even if I rearrange the script so there are no invocations > of wine before unpacking gecko, it still puts up > the dialog box when I run regedit to tell wine > about the gecko I unpacked! > > Got any suggestions? > - Dan >

Nov. 12, 2009

today's git broke winetricks gecko :-(

by Dan Kegel

Hi Jacek, as of today, "winetricks gecko" triggers the download dialog box :-( Presumably this was caused by http://www.winehq.org/pipermail/wine-cvs/2009-November/061489.html Even if I rearrange the script so there are no invocations of wine before unpacking gecko, it still puts up the dialog box when I run regedit to tell wine about the gecko I unpacked! Got any suggestions? - Dan

Nov. 12, 2009

Re: What to do when un-nominating bugs for 1.2

by Scott Ritchie

Vitaliy Margolen wrote: > Dan Kegel wrote: >> Can we do the same this time, and retarget 1.2 bugs for 1.4 >> if they're not going to be fixed for 1.2? > At least simple explanation for why bugs were un-nominated from 1.2 would > have been great. Half of bugs had no explanation whatsoever. > > Sorry, this would be my fault. There were only one or two of us actually updating bugzilla during the session and I was busy trying to actually keep up with the decisions. So a few I just unnominated without comment because we were already talking about one 10 bugs down the list. Thanks, Scott Ritchie

Nov. 12, 2009

Re: user32: Add argument check for PTITLEBARINFO in GetTitleBarInfo().

by Rico Schüller

Am 12.11.2009 20:51, schrieb Paul Vriens: > On 11/12/2009 07:43 PM, Rico Schüller wrote: >> + if(!tbi) { >> + TRACE("Invalid TITLEBARINFO: %p\n", tbi); > > Hi Rico, > > So your printing the NULL pointer? > Hi Paul, yes, it's better to remove the %p. It doesn't add any useful information to the trace. Thanks for the hint. Cheers Rico

Nov. 12, 2009

Re: comctl32/tests: Move message testing helpers to header

by Nikolay Sivov

Ignore this one, it's a old patch which is wrong but wants to live so much that I send it accidentally. Forget about it.

Nov. 12, 2009

Re: Question about GetTokenInformation and memory leaks

by Rob Shearman

2009/11/11 Dan Kegel <dank(a)kegel.com>: > On Mon, Nov 9, 2009 at 2:12 PM, Rob Shearman <robertshearman(a)gmail.com> wrote: >> 2009/11/9 Dan Kegel <dank(a)kegel.com>: >>> 16 bytes in 1 blocks are definitely lost in loss record 123 of 728 >>> at RtlAllocateHeap (heap.c:1423) >>> by RtlAllocateAndInitializeSid (sec.c:156) >>> by NtQueryInformationToken (nt.c:379) >>> by GetTokenInformation (security.c:676) >> >> The bug is in the Wine code. Try the attached patch, which should fix >> it as a side-effect. > > Works great, thanks. Is that submitted / going to be submitted soon? Given the possibility of these changes breaking installers I plan to submit it after the next release of Wine. -- Rob Shearman

Nov. 12, 2009

Re: [try 2] [PATCH 01/12] comctl32: Add basic structure for IImageList interface

by Alexandre Julliard

Owen Rudge <orudge(a)codeweavers.com> writes: > @@ -2926,10 +2927,295 @@ ImageList_SetColorTable (HIMAGELIST himl, UINT uStartIndex, UINT cEntries, CONST > HRESULT WINAPI > ImageList_CoCreateInstance (REFCLSID rclsid, const IUnknown *punkOuter, REFIID riid, void **ppv) > { > - FIXME("STUB: %s %p %s %p\n", debugstr_guid(rclsid), punkOuter, debugstr_guid(riid), ppv); > - return E_NOINTERFACE; > + TRACE("(%s,%p,%s,%p)\n", debugstr_guid(rclsid), punkOuter, debugstr_guid(riid), ppv); > + > + if (!IsEqualIID(&IID_IImageList, riid)) > + return E_NOINTERFACE; You should be checking the clsid here. The iid is checked in QueryInterface. > @@ -2948,6 +3234,38 @@ ImageList_CoCreateInstance (REFCLSID rclsid, const IUnknown *punkOuter, REFIID r > HRESULT WINAPI > HIMAGELIST_QueryInterface (HIMAGELIST himl, REFIID riid, void **ppv) > { > - FIXME("STUB: %p %s %p\n", himl, debugstr_guid(riid), ppv); > - return E_NOINTERFACE; > + TRACE("(%p,%s,%p)\n", himl, debugstr_guid(riid), ppv); > + > + *ppv = NULL; > + > + /* TODO: IID_IImageList2 support */ > + if (!IsEqualIID(&IID_IImageList, riid)) > + return E_NOINTERFACE; This one is redundant too. > @@ -30,6 +30,9 @@ > /* the ones with offsets at the end are the same as in Windows */ > struct _IMAGELIST > { > + const struct IImageListVtbl *lpVtbl;/* IImageList vtable */ > + LONG ref; /* reference count */ > + > DWORD magic; /* 00: 'SAMX' */ > INT cCurImage; /* 04: ImageCount */ > INT cMaxImage; /* 08: maximages */ Please update the comment since the offsets no longer match Windows. -- Alexandre Julliard julliard(a)winehq.org

Nov. 12, 2009

Re: [PATCH 5/9] avrt: Add stub for Av(Set, Revert)MMThreadCharacteristics

by Alexandre Julliard

Maarten Lankhorst <m.b.lankhorst(a)gmail.com> writes: > +HANDLE WINAPI AvSetMmThreadCharacteristicsW(LPCWSTR TaskName, LPDWORD TaskIndex) > +{ > + FIXME("(%s,%p): stub\n", debugstr_w(TaskName), TaskIndex); > + > + if (!TaskName) > + { > + SetLastError(ERROR_INVALID_TASK_NAME); > + return NULL; > + } > + if (!TaskIndex) > + { > + SetLastError(ERROR_INVALID_HANDLE); > + return NULL; > + } > + return (HANDLE)(LONG_PTR)-1; -1 is not a good choice for a valid handle value. -- Alexandre Julliard julliard(a)winehq.org

Nov. 12, 2009

Re: [3/3] d3d9: Accept the geforce 8 fog+srgb result

by Henri Verbeet

2009/11/12 Stefan Dösinger <stefan(a)codeweavers.com>: > - ok(color_match(color, 0x00808080, 1), > + ok(color_match(color, 0x00808080, 1) || broken(color_match(color, 0x00bcbcbc, 1)), Just because drivers hack around HL2 doesn't mean it's broken.

Nov. 12, 2009

Bugging people about test failures

by Paul Vriens

Hi, I hope people don't mind me sending the occasional email about failing tests on Windows. The test.winehq.org pages are usually very red so it can be a bit hard sometimes to spot any 'regressions' in the conformance tests. I haven't payed much attention for 2 weeks and that (partly) results in what can be currently seen on test.winehq.org. I have of course limits in what I can fix so I need other people (especially the authors) to help me out here. Thanks to Juan and Rob for fixing loads of the failures already. Oh, and btw. not fixing your newly introduced failing tests in a timely matter (or at least paying attention to them) can even effect your Julliard ranking ;) -- Cheers, Paul.

Nov. 12, 2009

winscard: add pcsc-lite helpers for upcoming(?) implementation

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, looking for PCSC-card-reader support in Wine, I came across old mails from 2007. http://www.winehq.org/pipermail/wine-devel/2007-May/057052.html What's the current state of PCSC support in Wine? When I recently looked, winscard seemed full of stubs. OTOH, there's a company http://www.starmoney.de/index.php?id=243 that seems to use Wine (and Darwine?) with card readers to make its software available for Linux & Mac. Also seems ~2007. I believe that a winscard<->PCSC<->PCSC-Lite bridge would be much easier to achieve than USB support in Wine. Thanks for your help, Jörg Höhle

Nov. 12, 2009

Re: [try 2] [PATCH 03/12] comctl32: Implement Add, ReplaceIcon, GetImageCount, SetImageCount in IImageList

by Henri Verbeet

2009/11/11 Owen Rudge <orudge(a)codeweavers.com>: > @@ -2985,15 +2985,37 @@ static ULONG WINAPI ImageListImpl_Release(IImageList *iface) > static HRESULT WINAPI ImageListImpl_Add(IImageList *iface, HBITMAP hbmImage, > HBITMAP hbmMask, int *pi) > { > - FIXME("STUB: %p %p %p %p\n", iface, hbmImage, hbmMask, pi); > - return E_NOTIMPL; > + HIMAGELIST This = (HIMAGELIST) iface; > + int ret; > + > + if (!This || !hbmImage || !pi) > + return E_FAIL; I don't know if you have tests for the other parameters, but "iface" should never be NULL for COM methods.

Nov. 12, 2009

Re: Still a crash in the rpcrt4 tests

by Rob Shearman

2009/11/12 Paul Vriens <paul.vriens.wine(a)gmail.com>: > Hi Rob, > > There is still a crash in the rpcrt4 tests on NT4+. > > These 2 tests both crash actually: > > 886 x = echo_ranged_int(0); > 887 ok(x == 0, "echo_ranged_int() returned %d instead of 0\n", x); > 888 x = echo_ranged_int(100); > 889 ok(x == 100, "echo_ranged_int() returned %d instead of 100\n", x); > > but only in the "ncalrpc_basic" case. I have a fix in widl for these which I'll send shortly. -- Rob Shearman

Nov. 12, 2009

Still a crash in the rpcrt4 tests

by Paul Vriens

Hi Rob, There is still a crash in the rpcrt4 tests on NT4+. These 2 tests both crash actually: 886 x = echo_ranged_int(0); 887 ok(x == 0, "echo_ranged_int() returned %d instead of 0\n", x); 888 x = echo_ranged_int(100); 889 ok(x == 100, "echo_ranged_int() returned %d instead of 100\n", x); but only in the "ncalrpc_basic" case. -- Cheers, Paul.

Nov. 12, 2009

Re: d3d8/tests: Avoid a crash, when CreateTexture failed

by Detlef Riekenberg

On Mi, 2009-11-11 at 15:16 +0100, Henri Verbeet wrote: > I.e., does the attached patch work for you? yes, with 0 failures :-) d3d9 has the same code (but i cant test d3d9 on my machine). Thanks. Do you want to send the patches yourself? -- By by ... Detlef

Nov. 11, 2009

Re: What's the use of volatile in Wine code?

by Rob Shearman

2009/11/11 <Joerg-Cyril.Hoehle(a)t-systems.com>: > Hi, > > AJ wrote in http://www.winehq.org/pipermail/wine-devel/2009-November/079575.html >>If there is proper synchronization you don't need >>volatile, and if there isn't volatile won't magically fix it. > > However, mcimidi has in its code since pre 1999: > :/* it seems that in case of multi-threading, gcc is optimizing just a little bit > : * too much. Tell gcc not to optimize status value using volatile. > : */ > :while (((volatile WINE_MCIMIDI*)wmm)->dwStatus == MCI_MODE_PAUSE); > > The comment is right. Any C compiler is allowed to optimize this into > an endless loop without volatile. But I'd rather see the following: > :volatile dwStatus = NOT_READY; /* one central declaration */ > :... > :while (wmm->dwStatus == PAUSE) ; /* what, busy wait!?! */ > > So what's the use of volatile? When is it appropriate in Wine? I haven't looked in detail at the context of your patch, but this looks appropriate to it: http://lkml.indiana.edu/hypermail/linux/kernel/0607.0/1566.html Particularly the part about volatile storage vs. access. -- Rob Shearman

Nov. 11, 2009

Re: Fun new valgrind warnings in rpc code?

by Rob Shearman

2009/11/11 Dan Kegel <dank(a)kegel.com>: > As of today, six tests: > > http://kegel.com/wine/valgrind/logs/2009-11-11-07.36/diff-rpcrt4_server.txt > http://kegel.com/wine/valgrind/logs/2009-11-11-07.36/diff-ole32_marshal.txt > http://kegel.com/wine/valgrind/logs/2009-11-11-07.36/diff-ole32_moniker.txt > http://kegel.com/wine/valgrind/logs/2009-11-11-07.36/diff-rpcrt4_ndr_marsha… > http://kegel.com/wine/valgrind/logs/2009-11-11-07.36/diff-ole32_moniker.txt > http://kegel.com/wine/valgrind/logs/2009-11-11-07.36/diff-rpcrt4_server.txt > > all report the new valgrind warning > > Syscall param socketcall.send(msg) points to uninitialised byte(s) > at send (socket.S:100) > by rpcrt4_conn_write (rpc_binding.h:170) > by RPCRT4_SendWithAuth (rpc_message.c:841) > by RPCRT4_Send (rpc_message.c:983) > by process_bind_packet (rpc_server.c:281) > by RPCRT4_process_packet (rpc_server.c:412) > by RPCRT4_worker_thread (rpc_server.c:435) > by worker_thread_proc (threadpool.c:114) > by ??? (signal_i386.c:2279) > by call_thread_entry_point (signal_i386.c:2306) > by start_thread (thread.c:469) > by start_thread (pthread_create.c:297) > by clone (clone.S:130) > Address 0x7f037e28 is 40 bytes inside a block of size 60 alloc'd > at notify_alloc (heap.c:214) > by RtlAllocateHeap (heap.c:1421) > by RPCRT4_SendWithAuth (rpc_message.c:800) > by RPCRT4_Send (rpc_message.c:983) > by process_bind_packet (rpc_server.c:281) > by RPCRT4_process_packet (rpc_server.c:412) > by RPCRT4_worker_thread (rpc_server.c:435) > by worker_thread_proc (threadpool.c:114) > by ??? (signal_i386.c:2279) > by call_thread_entry_point (signal_i386.c:2306) > by start_thread (thread.c:469) > by start_thread (pthread_create.c:297) > by clone (clone.S:130) > Uninitialised value was created by a client request > at mark_block_uninitialized (heap.c:187) > by RtlAllocateHeap (heap.c:1429) > by I_RpcAllocate (rpcrt4_main.c:574) > by RPCRT4_ReceiveWithAuth (rpc_message.c:1160) > by RPCRT4_Receive (rpc_message.c:1298) > by RPCRT4_io_thread (rpc_server.c:453) > by ??? (signal_i386.c:2279) > by call_thread_entry_point (signal_i386.c:2306) > by start_thread (thread.c:469) > by start_thread (pthread_create.c:297) > by clone (clone.S:130) > > I don't think that happened before today. > > Rob/Hans, could you have a look? Probably caused by: http://source.winehq.org/git/wine.git/?a=commitdiff;h=59ba6d2573532c15e2487… I'll take a look. -- Rob Shearman

Nov. 11, 2009

Re: Question about GetTokenInformation and memory leaks

by Dan Kegel

On Mon, Nov 9, 2009 at 2:12 PM, Rob Shearman <robertshearman(a)gmail.com> wrote: > 2009/11/9 Dan Kegel <dank(a)kegel.com>: >> 16 bytes in 1 blocks are definitely lost in loss record 123 of 728 >> at RtlAllocateHeap (heap.c:1423) >> by RtlAllocateAndInitializeSid (sec.c:156) >> by NtQueryInformationToken (nt.c:379) >> by GetTokenInformation (security.c:676) > > The bug is in the Wine code. Try the attached patch, which should fix > it as a side-effect. Works great, thanks. Is that submitted / going to be submitted soon? - Dan

Nov. 11, 2009

Re: Any Wineconf results?

by Zachary Goldberg

On Wed, Nov 11, 2009 at 11:08 AM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: > Hi, guys. > I'd like to read something about decisions if any you've made at this > conf, some principle ideas or something. Wiki page > doesn't talk too much - but thanks for Michael's slides about > wine-oopses. All I'm able to find is Marcus' flickr photoset and > I'm not satisfied with that :). I've noticed some 1.2 target bugs > dropping and a bunch of rpcrt4 and sound patches, > and that's great. > In addition, if anybody wants to get in touch with me with some material I may be able to put together a WWN with Wineconf notes. I unfortunately was not there this year so I do not have any notes of my own to publish :(. -Zach

Nov. 11, 2009

RE: Owen Rudge : comctl32: Add support for scrolling during marquee selection.

by Owen Rudge

Hi Nikolay, > I've tested this a bit and it flickers like hell in some cases. Looks > like list requests redraw even if selection doesn't change (pointer is > still over already selected item). Hmm, yes, it seems it does still redraw if you move the mouse when selecting, although it shouldn't if the mouse is stationary. Trying with regedit does show it flickering a bit. I'll see what I can do to improve this. > - selection logic is wrong when some items are already selected before > marquee. On native it deselects those items, your code leave them as > is. This is visible in regedit (report mode listview) - select first > entry and start selection -> first item remains selected. This appears to be a bug that, as far as I can see, only shows up in report mode. Additionally, even if you don't select any item, the first item will be selected upon starting a drag. Items are cleared as intended when clicking, the bug seems to be that the first item in the list automatically selects itself. Again, I shall work on a patch for this. > - sometimes I get corrupted focus rectangle - moving pointer down > causes bottom side to clear, rectangle contains three side after that > (it could be a problem for my virtual box of course, or some embedded > video drivers, but I don't see a problem moving up for example). I'll have a play around and see if I can reproduce this. Cheers, Owen

Nov. 11, 2009

Fun new valgrind warnings in rpc code?

by Dan Kegel

As of today, six tests: http://kegel.com/wine/valgrind/logs/2009-11-11-07.36/diff-rpcrt4_server.txt http://kegel.com/wine/valgrind/logs/2009-11-11-07.36/diff-ole32_marshal.txt http://kegel.com/wine/valgrind/logs/2009-11-11-07.36/diff-ole32_moniker.txt http://kegel.com/wine/valgrind/logs/2009-11-11-07.36/diff-rpcrt4_ndr_marsha… http://kegel.com/wine/valgrind/logs/2009-11-11-07.36/diff-ole32_moniker.txt http://kegel.com/wine/valgrind/logs/2009-11-11-07.36/diff-rpcrt4_server.txt all report the new valgrind warning Syscall param socketcall.send(msg) points to uninitialised byte(s) at send (socket.S:100) by rpcrt4_conn_write (rpc_binding.h:170) by RPCRT4_SendWithAuth (rpc_message.c:841) by RPCRT4_Send (rpc_message.c:983) by process_bind_packet (rpc_server.c:281) by RPCRT4_process_packet (rpc_server.c:412) by RPCRT4_worker_thread (rpc_server.c:435) by worker_thread_proc (threadpool.c:114) by ??? (signal_i386.c:2279) by call_thread_entry_point (signal_i386.c:2306) by start_thread (thread.c:469) by start_thread (pthread_create.c:297) by clone (clone.S:130) Address 0x7f037e28 is 40 bytes inside a block of size 60 alloc'd at notify_alloc (heap.c:214) by RtlAllocateHeap (heap.c:1421) by RPCRT4_SendWithAuth (rpc_message.c:800) by RPCRT4_Send (rpc_message.c:983) by process_bind_packet (rpc_server.c:281) by RPCRT4_process_packet (rpc_server.c:412) by RPCRT4_worker_thread (rpc_server.c:435) by worker_thread_proc (threadpool.c:114) by ??? (signal_i386.c:2279) by call_thread_entry_point (signal_i386.c:2306) by start_thread (thread.c:469) by start_thread (pthread_create.c:297) by clone (clone.S:130) Uninitialised value was created by a client request at mark_block_uninitialized (heap.c:187) by RtlAllocateHeap (heap.c:1429) by I_RpcAllocate (rpcrt4_main.c:574) by RPCRT4_ReceiveWithAuth (rpc_message.c:1160) by RPCRT4_Receive (rpc_message.c:1298) by RPCRT4_io_thread (rpc_server.c:453) by ??? (signal_i386.c:2279) by call_thread_entry_point (signal_i386.c:2306) by start_thread (thread.c:469) by start_thread (pthread_create.c:297) by clone (clone.S:130) I don't think that happened before today. Rob/Hans, could you have a look?

Nov. 11, 2009

Re: Cpp Check Nov. 7th

by chris ahrendt

Alexandre Julliard wrote: > chris ahrendt <celticht32(a)yahoo.com> writes: > >> Alexandre Julliard wrote: >>> chris ahrendt <celticht32(a)yahoo.com> writes: >>> >>>> Well its been a few since I ran CPP Check and so I ran it today and got the following: >>>> >>>> New CPP Check Errors for the Wine Code: >>>> >>>> [/home/cahrendt/wine-git/dlls/comctl32/imagelist.c:1908]: (error) Uninitialized variable: bmi_buf >>>> [/home/cahrendt/wine-git/dlls/ntdll/server.c:802]: (error) Resource leak: fd >>>> [/home/cahrendt/wine-git/dlls/ntdll/server.c:882]: (error) Resource leak: fd_cwd >>>> [/home/cahrendt/wine-git/dlls/shell32/shellord.c:416]: (error) Uninitialized variable: szText >>>> [/home/cahrendt/wine-git/dlls/shell32/shellord.c:416]: (error) Uninitialized variable: szTitle >>>> [/home/cahrendt/wine-git/dlls/shell32/shellpath.c:1360]: (error) Uninitialized variable: InfoBuffer >>>> [/home/cahrendt/wine-git/dlls/winex11.drv/xfont.c:2963]: (possible error) Resource leak: fd >>>> [/home/cahrendt/wine-git/server/mapping.c:118]: (error) Uninitialized variable: page_size >>> These are once again all false positives. I don't think there's any >>> point in continuing to post such reports, at least not until cppcheck >>> becomes more reliable. >>> >> Will report them to CPPcheck >> >> are you sure though all of these are false positives? > > Yes, there isn't a single legitimate bug in there. > Ticket open... chris

Nov. 11, 2009

Re: howto document for valgrinding application test suites (starting with chromium)

by Reece Dunn

2009/11/11 Dan Kegel <dank(a)kegel.com>: > http://winezeug.googlecode.com/svn/trunk/valgrind/doc/win32.html > shows (using Chromium as an example) how windows > developers can find memory errors in their > windows code by running their test suites under valgrind+wine. > It's still an early draft; I expect to improve it as I gain experience > tracking down the problems that happen when running this test suite > under valgrind+wine. > > Chromium makes a great example because it has a really > good test suite, and, um, because it's my day job :-) > > This is currently an experiment. If it works out, I might > get to do a lot more along these lines. Cool. BTW, I have some CSS stylesheets under the Creative Commons license that you can use to prettify the document at http://rhdunn.github.com/web-documents/. Feedback welcome :D. - Reece

Nov. 11, 2009

howto document for valgrinding application test suites (starting with chromium)

by Dan Kegel

http://winezeug.googlecode.com/svn/trunk/valgrind/doc/win32.html shows (using Chromium as an example) how windows developers can find memory errors in their windows code by running their test suites under valgrind+wine. It's still an early draft; I expect to improve it as I gain experience tracking down the problems that happen when running this test suite under valgrind+wine. Chromium makes a great example because it has a really good test suite, and, um, because it's my day job :-) This is currently an experiment. If it works out, I might get to do a lot more along these lines. - Dan

Nov. 11, 2009

hang in mci tests?

by Joerg-Cyril.Hoehle＠t-systems.com

Dan Kegel wrote: >I had a new hang on yesterday's git under valgrind: >err:wave:wodPlayer_WriteMaxFrags Error in writing wavehdr. Reason: >Resource temporarily unavailable >... 1600 dup lines removed ... >ALSA lib ../../../src/pcm/pcm.c:7228:(snd_pcm_recover) underrun occured Good that I'm not alone. I had these specific two yesterday for the first time ever as well, without valgrind. I attributed it to "yet another flaky error in the audio drivers" -- I mean I don't entirely trust the audio drivers because winmm/tests/wave.c has shown flaky failures (WOD_PREPARED msg) for ages, without being driven by the MCI. IIRC, Wine did not hang as I waited long enough, but maybe I did ^C. Facts: - The MCI play loop is still buggy w.r.t. sample size (witness the 333ms multiples) That could explain the underrun log that I've also seen (which I believe is a very recent log addition from Maarten). - winmm/wave.ok produces errors from time to time in test.winehq as well as on my machines. Suppositions: - the broken MCI play loop causes the above errors, randomly. But we have nothing to prove that. Well, I don't know where to look for the wave.ok intermittent failures (not in MCI), but my goal is to write a correct MCI play/record loop that will also be usable in mciavi32. Oh well, another piece to the puzzle: using my interactive MCI shell, play 2 sounds in parallel [*]. *Sometimes* the second one manages to halt the first sound. I see no reason/code in MCI's waveaudio that can do that! The error must be elsewhere (-> wave or audio drivers). [*] open long-sound.wav alias a open other.wav alias b play a from 0 play b from 0 Repeat play until a is interrupted (i.e. nothing is heard any more). The playloop appears to hang. Regards, Jörg Höhle

Nov. 11, 2009

Amicus curiae: winenas.drv: Remove broken driver

by Michael Stefaniuc

Hello Alexandre and Maarten, as you guys where discussing right now on irc about it I'm rushing this email out. On 11/07/2009 02:45 PM, Maarten Lankhorst wrote: > --- > From 88fde5ad95a33dc2da29757605891ccc5047c12f Mon Sep 17 00:00:00 2001 > From: mlankhorst <mlankhorst(a)eee.(none)> > Date: Sat, 7 Nov 2009 13:34:54 +0000 > Subject: [PATCH] winenas.drv: Remove broken driver Data: ----- wine-bugs, wine-devel, wine-users archives from May 2008 to October 2009. Total of 133699 emails and 8313 bugs.winehq.org attachments. Tools: wineoops --------------- - Wine crashes parsed: select count(*) from crash; 2711 - Nr of crashes with module info associated: select count(*) from (select crash_id from crash_modules group by crash_id); 2319 - List of all the Wine audio drivers loaded: select count(*) as nr, name from crash_modules, module where module_id=id and name like "wine%" group by name order by nr desc; 1367|winealsa 156|wineoss 12|wineesd 4|winepulse 3|wineal 3|wineasio 3|winecoreaudio 2|winejack 1|winenas The one crash that has winenas in it is from May 2009. bye michael

Nov. 11, 2009

Any Wineconf results?

by Nikolay Sivov

Hi, guys. Unfortunately, but as I expected, I wasn't able to participate in Wineconf2009 (I'm business tripping for 3 weeks in central Asia now). I'd like to read something about decisions if any you've made at this conf, some principle ideas or something. Wiki page doesn't talk too much - but thanks for Michael's slides about wine-oopses. All I'm able to find is Marcus' flickr photoset and I'm not satisfied with that :). I've noticed some 1.2 target bugs dropping and a bunch of rpcrt4 and sound patches, and that's great. Anyway thanks for this year, all of you, it's really interesting to contribute here.

Nov. 11, 2009

new Lucid gcc compiles wine o

by Susan Cragin

Lucid has fixed the bug I mentioned earlier, and now Wine can be compiled in pre-alpha Lucid Lynx, providing all updates are as-of today, ll/11. In case anyone is interested, the working gcc is: gcc (Ubuntu 4.4.2-1ubuntu4) 4.4.2

Nov. 11, 2009

new invalid read errors in winhttp

by Dan Kegel

http://kegel.com/wine/valgrind/logs/2009-11-10-17.32/diff-winhttp_notificat… http://kegel.com/wine/valgrind/logs/2009-11-10-17.32/vg-winhttp_notificatio… has a bunch of new errors, all of which seem to look like this: Invalid read of size 4 at check_notification (notification.c:65) by send_callback (session.c:56) by close_connection (request.c:978) by release_object (handle.c:79) by task_thread (request.c:181) by worker_thread_proc (threadpool.c:114) by ??? (signal_i386.c:2279) by call_thread_entry_point (signal_i386.c:2306) by start_thread (thread.c:469) by start_thread (pthread_create.c:297) by clone (clone.S:130) Address 0x7f21f8f8 is not stack'd, malloc'd or (recently) free'd but I don't see any recent changes in that area? - Dan

Nov. 11, 2009

hang in mci tests?

by Dan Kegel

Hi Joerg, I had a new hang on yesterday's git under valgrind: ../../../tools/runtest -q -P wine -M winmm.dll -T ../../.. -p winmm_test.exe.so mci.c && touch mci.ok preloader: Warning: failed to reserve range 00110000-68000000 mci.c:186: Test failed: mci close all notify (without buffer) returned error: 281 mci.c:190: Test failed: mci close all notify (with output buffer) returned error: 281 mci.c:199: Test failed: mci sysinfo waveaudio quantity open, expected output buffer '0', got: '1' mci.c:279: Test failed: mci status position gave 2333, expected 2000, some tests will fail mci.c:288: Test failed: recorded 74662 bytes, expected 64000 mci.c:298: Test failed: recorded 37331 samples, expected 32000 mci.c:330: Test failed: mci status length gave 2333, expected 2000, some tests will fail. mci.c:333: Test failed: mci incorrect cue output returned: MCIERR_EXTENSION_NOT_FOUND mci.c:148: Test failed: got 0001 instead of MCI_NOTIFY_xyz 0002 from command play mci.c:149: Test failed: PeekMessage should succeed for command status mci.c:437: Test failed: Expected full pathname from info file: tempfile.wav err:wave:wodPlayer_WriteMaxFrags Error in writing wavehdr. Reason: Resource temporarily unavailable err:wave:wodPlayer_WriteMaxFrags Error in writing wavehdr. Reason: Resource temporarily unavailable err:wave:wodPlayer_WriteMaxFrags Error in writing wavehdr. Reason: Resource temporarily unavailable err:wave:wodPlayer_WriteMaxFrags Error in writing wavehdr. Reason: Resource temporarily unavailable ... 1600 dup lines removed ... ALSA lib ../../../src/pcm/pcm.c:7228:(snd_pcm_recover) underrun occured 16 bytes in 1 blocks are definitely lost in loss record 148 of 913 by: RtlAllocateHeap (heap.c:1421) by: mciSendStringW (mci.c:1319) by: mciSendStringA (mci.c:1448) by: test_openCloseWAVE (mci.c:164) by: func_mci (mci.c:652) I had to kill it; dunno if the leak was because I interrupted it or not. - Dan

Nov. 11, 2009

Re: Wineconf?

by Michael Stefaniuc

Hello! Damjan Jovanovic wrote: > Can someone please write a bit about Wineconf 2009, for those of us > that didn't go? > > Also is there videos/presentations to see? I have added mine to the bottom of http://wiki.winehq.org/WineConf2009 bye michael

Nov. 11, 2009

Re: d3d8/tests: Avoid a crash, when CreateTexture failed

by Henri Verbeet

2009/11/6 Henri Verbeet <hverbeet(a)gmail.com>: > If changing the usage makes it work, that's ok. Maybe try just passing > 0 for usage. The texture doesn't have to be lockable, all we care > about is having a unique texture pointer for the > SetTexture()/GetTexture() calls. > I.e., does the attached patch work for you?

Nov. 11, 2009

Wineconf?

by Damjan Jovanovic

Hi Can someone please write a bit about Wineconf 2009, for those of us that didn't go? Also is there videos/presentations to see? Thank you Damjan Jovanovic

Nov. 11, 2009

Re: [Fwd: 64bit wine]

by Ben Klein

2009/11/11 Michael Stefaniuc <mstefani(a)redhat.com>: > Ben Klein wrote: >> 2009/11/11 Michael Stefaniuc <mstefani(a)redhat.com>: >>> For fedora it will not be possible to do a special 32bit compile on the x86_64 >>> arch. >> >> Wait ... no gcc -m32 on Fedora x86_64? > The compiler is not the problem but the missing i586 libraries+headers > in the x86_64 build tree. Sounds broken to me :P > Huh? Wine's WoW64 is well underway and is the feature that will make > Wine reach the 1.2 milestone. > > The solution is for distributions to not ship Wine64 to the users yet. > >> Note that they would have the same issues if they were running Windows natively. > We know that. I misinterpreted. My apologies :)

Nov. 11, 2009

Re: Where to receive MCI PostMessageW notifications?

by Eric Pouech

Joerg-Cyril.Hoehle(a)t-systems.com a écrit : > Hi, > > the MCI relies on notification to implement auto-open correctly. When > the command is done, it must send out a notification via PostMessageW. > The receiver then ought to call mciClose. > > One possible implementation would be to have auto-open start a thread > that does nothing else but wait for this message to arrive, then call > mciClose. I wonder if there's something more lightweight than a > thread (this is not Erlang) that could be used inside Wine. > > What could be used that reacts asynchronously to PostMessageW? > > Currently, the missing auto-open functionality causes > - unclosed files (some seen as error messages when Wine exits) > (here it is essential that the notification works 100%) > - some application hangs, some of them in Bugzilla. > > Thanks, > Jörg Höhle > create a (hidden) window (in winmm) where you handle the mci notification (which means you must force MCI_NOTIFY flag with this window handle when sending a MCI command down to a driver) I wonder how native does when no message loop exists in the application (should be tested) (maybe peek for the notif message upon entrance of some of the MCI funcs ?) A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

Nov. 11, 2009

Re: What's the use of volatile in Wine code?

by Marcus Meissner

On Wed, Nov 11, 2009 at 11:13:06AM +0100, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Hi, > > AJ wrote in http://www.winehq.org/pipermail/wine-devel/2009-November/079575.html > >If there is proper synchronization you don't need > >volatile, and if there isn't volatile won't magically fix it. > > However, mcimidi has in its code since pre 1999: > :/* it seems that in case of multi-threading, gcc is optimizing just a little bit > : * too much. Tell gcc not to optimize status value using volatile. > : */ > :while (((volatile WINE_MCIMIDI*)wmm)->dwStatus == MCI_MODE_PAUSE); > > The comment is right. Any C compiler is allowed to optimize this into > an endless loop without volatile. But I'd rather see the following: > :volatile dwStatus = NOT_READY; /* one central declaration */ > :... > :while (wmm->dwStatus == PAUSE) ; /* what, busy wait!?! */ > > So what's the use of volatile? When is it appropriate in Wine? As Alexandre said only in special places. variables set out of line by signal handlers for instance. > I found this article from MSDN about memory acquire and release > semantics, volatile and multiple processors very interesting. MS-VC > changed the code generator for 'volatile' between 2003 and 2005 to > accomodate multi-processor systems: > http://msdn.microsoft.com/en-us/library/ms686355(VS.85).aspx It pretty much depends on how dwStatus is changed actually. The code above has "wmm" changed by threads, so just reading it might be broken anyhow, as it might only be modified half-way by the other thread. Using correct locking, or atomics would help and also not make it an endless loop. Ciao, Marcus

Nov. 11, 2009

Re: shell32: Use Unicode for GetFileNameFromBrowse

by Alexandre Julliard

Owen Rudge <orudge(a)codeweavers.com> writes: > For some reason, we have implemented the GetFileNameFromBrowse > function in shell32 with ANSI functions. According to MSDN, the > function should use Unicode, and IE7 (which uses the function for its > File -> Open routine) expects this. This patch fixes that. It should probably be an AW function instead. -- Alexandre Julliard julliard(a)winehq.org

Nov. 11, 2009