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

Re: [PATCH 02/16] comctl32: Add basic structure for IImageList interface

by Henri Verbeet

2009/11/10 Owen Rudge <orudge(a)codeweavers.com>: > +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_NOINTERFACE; > +} This is minor at this point, but E_NOTIMPL is usually a more appropriate return code for stubs.

Nov. 11, 2009

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

by Alexandre Julliard

<Joerg-Cyril.Hoehle(a)t-systems.com> writes: > So what's the use of volatile? When is it appropriate in Wine? In general it's never appropriate. There are some very specific cases where it can be used, but you have to be sure to know what you are doing. Using proper synchronization instead is strongly recommended. -- Alexandre Julliard julliard(a)winehq.org

Nov. 11, 2009

Re: [PATCH 01/16] comctl32: Add class factory for IImageList interface

by Alexandre Julliard

Owen Rudge <orudge(a)codeweavers.com> writes: > These patches finish the implementation of the IImageList v6 interface > in comctl32. This doesn't seem to match Windows, even independently from the structure layout issue. There's no DllGetClassObject or clsid registration on Windows, it's not handled as a standard COM dll. -- Alexandre Julliard julliard(a)winehq.org

Nov. 11, 2009

What's the use of volatile in Wine code?

by Joerg-Cyril.Hoehle＠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 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 Regards, Jörg Höhle

Nov. 11, 2009

MCI and application-level thread-safety?

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

Hi, So far my my patches have dealt only with "internal thread consistency", i.e. to avoid bogus conditions that result by using threads *internal* to the MCI. I wonder whether the individual MCI devices must protect themselves from application-level threads, i.e. an application issuing commands to the same device from several threads? (Also needed for auto-close...) This for sure would require the addition of critical sections which currently only mciavi32 has. These have to be thought about very carefully to avoid dead-locks (give me Erlang or Occam, or queues like in the audio drivers instead of this lock-based error-prone stuff!). Regards, Jörg Höhle

Nov. 11, 2009

Where to receive MCI PostMessageW notifications?

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

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

Nov. 11, 2009

Re: [Fwd: 64bit wine]

by Michael Stefaniuc

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. >> Hence the only way is to have the default x86_32 version and a x86_64 >> version to be parallel installable. While it may be possible to use a different >> WINEPREFIX for the x86_64 version (which would have been my short term >> solution) it is not desirable for the users. > > Until WIne's WoW64 implementation works (which from what you said > before may be never), users will have to put up with separated 64bit Huh? Wine's WoW64 is well underway and is the feature that will make Wine reach the 1.2 milestone. > and 32bit Windows apps. The best solution is to use a separate > WINEPREFIX. 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 have forwarded the email basically as a follow-up to the WineConf 64bit session. We (as in Wine) needs to speed up the Wine64 documentation for our downstream packagers. I'll start it once i get a free round tuit. bye michael

Nov. 11, 2009

Re: Cpp Check Nov. 7th

by Alexandre Julliard

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. -- Alexandre Julliard julliard(a)winehq.org

Nov. 11, 2009

Re: [Fwd: 64bit wine]

by Marcus Meissner

On Wed, Nov 11, 2009 at 11:05:49AM +1100, 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? > > > Hence the only way is to have the default x86_32 version and a x86_64 > > version to be parallel installable. While it may be possible to use a different > > WINEPREFIX for the x86_64 version (which would have been my short term > > solution) it is not desirable for the users. > > Until WIne's WoW64 implementation works (which from what you said > before may be never), users will have to put up with separated 64bit > and 32bit Windows apps. The best solution is to use a separate > WINEPREFIX. > > Note that they would have the same issues if they were running Windows natively. On Wineconf we discussed how a mixed 64/32 wine will work. Largest part currently missing is the 64<->32 bit crosscall and doing 32/64 bit shared wineprefixes. So it is not yet ready to be setup and for regular users a 32bit only wine should be provided. Ciao, Marcus

Nov. 11, 2009

Re: [PATCH 02/16] comctl32: Add basic structure for IImageList interface

by Owen Rudge

> is wrong because it changes offsets... but it also breaks > those comments. (Can you put the vtable at the end?) In comctl32 v6, IImageList and HIMAGELIST are the same thing. See, for instance, http://msdn.microsoft.com/en-us/library/bb762185%28VS.85%29.aspx: "The IImageList pointer type, such as that returned in the ppv parameter, can be cast as an HIMAGELIST as needed; for example, for use in a list view. Conversely, an HIMAGELIST can be cast as a pointer to an IImageList." Obviously, the IImageList requires the vtable to be placed at the first offset. If any applications do rely on the (undocumented) imagelist structure, then these patches will indeed break them. Nikolay's solution would be a possibility, although it would complicate the code a bit. I would probably prefer to wait and see if we get reports of anything actually breaking, but I realise others may disagree there. Cheers, -- Owen Rudge http://www.owenrudge.net/

Nov. 10, 2009

re: [PATCH 02/16] comctl32: Add basic structure for IImageList interface

by Dan Kegel

As Nikolay pointed out, the change > /* 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' */ is wrong because it changes offsets... but it also breaks those comments. (Can you put the vtable at the end?)

Nov. 10, 2009

Re: [PATCH 02/16] comctl32: Add basic structure for IImageList interface

by Nikolay Sivov

On Wed, Nov 11, 2009 at 12:11 AM, Owen Rudge <orudge(a)codeweavers.com> wrote: > --- > dlls/comctl32/imagelist.c | 322 > ++++++++++++++++++++++++++++++++++++++++++++- > dlls/comctl32/imagelist.h | 3 + > 2 files changed, 319 insertions(+), 6 deletions(-) > After that: --- diff --git a/dlls/comctl32/imagelist.h b/dlls/comctl32/imagelist.h index 73ccd8a..51b8635 100644 --- a/dlls/comctl32/imagelist.h +++ b/dlls/comctl32/imagelist.h @@ -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 */ --- let's pray that nobody depends on structure layout :). If it'll be a problem the possible solution could be to use two structure types - one for traditional API and one for com-based. Choosing one of it could be done possibly in ImageList_Create checking for manifest enabled in activation context. All traditional calls should check for that then and apply an offset to pointer to get HIMAGELIST without vtbl. We'll see...

Nov. 10, 2009

Re: Cpp Check Nov. 7th

by chris ahrendt

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? chris

Nov. 10, 2009

Re: [Fwd: 64bit wine]

by Ben Klein

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? > Hence the only way is to have the default x86_32 version and a x86_64 > version to be parallel installable. While it may be possible to use a different > WINEPREFIX for the x86_64 version (which would have been my short term > solution) it is not desirable for the users. Until WIne's WoW64 implementation works (which from what you said before may be never), users will have to put up with separated 64bit and 32bit Windows apps. The best solution is to use a separate WINEPREFIX. Note that they would have the same issues if they were running Windows natively.

Nov. 10, 2009

Re: Wine 64-bit in Fedora ...

by Ben Klein

2009/11/10 Michael Stefaniuc <mstefani(a)redhat.com>: > Uwe Bonnes wrote: >> Did nobody of the packages test what they did? > It is easy to miss as it requires: > - Fresh install of Wine (via PackageKit or yum install) and > - Old 32-bit WINEPREFIX. Except that it's obvious that the packagers are not people who USE wine, or they would notice their ia32 Windows apps suddenly not running.

Nov. 10, 2009

Re: avifile bugfixes

by Detlef Riekenberg

On Di, 2009-11-10 at 00:43 +0100, Julius Schwartzenberg wrote: > I will add tests to show this and submit the patches then. I created a test for avifil32 in June 2008, but it was not comitted. ( http://www.winehq.org/pipermail/wine-patches/2008-June/056310.html ) The bug 14085 was created to document the required feature: http://bugs.winehq.org/show_bug.cgi?id=14085 an importlib for multiple dlls is not supported (avicap32 + avifil32 + msvfw32 => vfw32) You can and should create tests (crosscompile them to check the Windows results and to verify the implementation changes) and send them as a seperate patch, but the patche can't be comitted before bug 14085 is fixed. -- By by ... Detlef

Nov. 10, 2009

Re: setupapi: add stub and some tests for SetupGetInfFileListW [resend]

by Henri Verbeet

2009/11/10 Stefan Leichter <Stefan.Leichter(a)camline.com>: > When reviewing the patch i found two line containing only spaces. But this are > to my understanding no "whitespace errors". Can you please tell me what else > you have seen ? > That counts as trailing spaces. Note that git apply warns about white space errors by default.

Nov. 10, 2009

Re: setupapi: add stub and some tests for SetupGetInfFileListW [resend]

by Stefan Leichter

Am Tuesday 10 November 2009 10:09:22 schrieb Henri Verbeet: > 2009/11/9 Stefan Leichter <Stefan.Leichter(a)camline.com>: > > my crystal ball is still not working, therefore resending unchanged > > Try http://source.winehq.org/patches/ > > And indeed, the patch doesn't apply: > > diff -urw wine-git/dlls/setupapi/install.c > wine-build/dlls/setupapi/install.c --- a/wine-git/dlls/setupapi/install.c > +++ b/wine-build/dlls/setupapi/install.c > > Note that you're also adding whitespace errors. When reviewing the patch i found two line containing only spaces. But this are to my understanding no "whitespace errors". Can you please tell me what else you have seen ? Thanks Stefan

Nov. 10, 2009

RE: [PATCH 16/16] comctl32/tests: Remove todo_wine from SHGetImageList tests

by Owen Rudge

> This patch suggest that one of the previous patches in this series makes > the tests succeed or actually fail as they are inside a todo_wine(). The previous patch is the one that makes the tests succeed. I split the todo_wine removal from the tests due to the modifications being in separate parts of the source tree, although I realise now that means the tests will give an error for the prior commit. I've submitted an updated patch that merges the two. Cheers, Owen

Nov. 10, 2009

Re: [PATCH 16/16] comctl32/tests: Remove todo_wine from SHGetImageList tests

by Paul Vriens

On 11/10/2009 07:12 PM, Owen Rudge wrote: > --- > dlls/comctl32/tests/imagelist.c | 6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > Hi Owen, This patch suggest that one of the previous patches in this series makes the tests succeed or actually fail as they are inside a todo_wine(). -- Cheers, Paul.

Nov. 10, 2009

Re: setupapi: add stub and some tests for SetupGetInfFileListW [resend]

by Alexandre Julliard

Stefan Leichter <Stefan.Leichter(a)camline.com> writes: > Am Tuesday 10 November 2009 10:09:22 schrieb Henri Verbeet: >> 2009/11/9 Stefan Leichter <Stefan.Leichter(a)camline.com>: >> > my crystal ball is still not working, therefore resending unchanged >> >> Try http://source.winehq.org/patches/ >> >> And indeed, the patch doesn't apply: >> >> diff -urw wine-git/dlls/setupapi/install.c >> wine-build/dlls/setupapi/install.c --- a/wine-git/dlls/setupapi/install.c >> +++ b/wine-build/dlls/setupapi/install.c >> > > i don't know where this stupid a/ and b/ was added. They are not in the > original patch see > http://www.winehq.org/pipermail/wine-patches/attachments/20091109/8912a56f/… They are added by the new patch filter, which tries to make everything appliable with git apply, and currently requires non-git patches to be based at the top of the tree. I'll look into supporting your case, but using git to format patches is strongly recommended. -- Alexandre Julliard julliard(a)winehq.org

Nov. 10, 2009

Re: rsaenh/tests(3/5): Add round-trip test of RSA

by Paul Vriens

On 11/05/2009 07:11 PM, Juan Lang wrote: > --Juan > > Hi Juan, This one introduces some test failures on Win9x and WinMe: http://test.winehq.org/data/tests/rsaenh:rsaenh.html Could you have a look? -- Cheers, Paul.

Nov. 10, 2009

Re: [8/9] widl: Add support for varargs functions.

by Paul Vriens

On 11/07/2009 03:55 PM, Rob Shearman wrote: > --- > dlls/rpcrt4/tests/server.c | 3 ++ > dlls/rpcrt4/tests/server.idl | 2 + > tools/widl/header.c | 68 ++++++++++++++++++++++------------------- > tools/widl/parser.l | 1 + > tools/widl/parser.y | 12 +++++-- > 5 files changed, 51 insertions(+), 35 deletions(-) > hi Rob, Either this one or "widl: Implement [range] attribute." introduced quite some test failures: http://test.winehq.org/data/tests/rpcrt4:server.html Could you please take a look? -- Cheers, Paul.

Nov. 10, 2009

Re: [2/3] oledb32: Add test for marshalling IDBProperties.

by Paul Vriens

On 11/07/2009 01:29 PM, Rob Shearman wrote: > --- > dlls/oledb32/tests/Makefile.in | 5 +- > dlls/oledb32/tests/marshal.c | 272 ++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 275 insertions(+), 2 deletions(-) > create mode 100644 dlls/oledb32/tests/marshal.c > Hi Rob, The test results for these new tests don't look too great: http://test.winehq.org/data/tests/oledb32:marshal.html Could you have a look? -- Cheers, Paul.

Nov. 10, 2009

Re: setupapi: add stub and some tests for SetupGetInfFileListW [resend]

by Stefan Leichter

Am Tuesday 10 November 2009 10:09:22 schrieb Henri Verbeet: > 2009/11/9 Stefan Leichter <Stefan.Leichter(a)camline.com>: > > my crystal ball is still not working, therefore resending unchanged > > Try http://source.winehq.org/patches/ > > And indeed, the patch doesn't apply: > > diff -urw wine-git/dlls/setupapi/install.c > wine-build/dlls/setupapi/install.c --- a/wine-git/dlls/setupapi/install.c > +++ b/wine-build/dlls/setupapi/install.c > i don't know where this stupid a/ and b/ was added. They are not in the original patch see http://www.winehq.org/pipermail/wine-patches/attachments/20091109/8912a56f/… > Note that you're also adding whitespace errors. I will check for whitespace problems

Nov. 10, 2009

Re: Infinite loop with translation DLL

by Marcus Meissner

On Mon, Nov 09, 2009 at 04:53:31PM +0100, Uwe Bonnes wrote: > >>>>> "Henri" == Henri Verbeet <hverbeet(a)gmail.com> writes: > > Henri> 2009/11/9 Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de>: > >> Can anybody help with the flaw in my implementation? Or did anything > >> change in wine? > >> > Henri> I'm not sure if anything changed there recently, or if that's > Henri> even supposed to work, but I suppose that one way to solve the > Henri> problem would be to load the linux library dynamically with > Henri> wine_dlopen() and explicitly load the entry points with > Henri> wine_dlsym(). > > I wonder how it works in dll/glu32 or what is different in my approach? > > Marcus: Do you have an example that uses dll/glu32? No, I dont know. I have not used for years :/ Ciao, Marcus

Nov. 10, 2009

[Fwd: 64bit wine]

by Michael Stefaniuc

Nov. 10, 2009

Re: [PATCH] server, ntoskrnl: Implement support for IRP_MJ_CREATE requests.

by Charles Davis

Vitaliy Margolen wrote: > Charles Davis wrote: >> Also, add stub handlers in mountmgr. >> >> This patch fixes an issue with the previous one where wine would hang if >> ntoskrnl got a STATUS_BUFFER_OVERFLOW back from thes server. >> --- > >> +int suspend_thread( struct thread *thread ); >> +int resume_thread( struct thread *thread ); > >> +static void complete_open( struct open_call *open, unsigned int status ) >> +{ > ... >> + resume_thread( open->call.thread ); > > >> This static struct object *device_open_file( struct object *obj, unsigned int access, >> unsigned int sharing, unsigned int options ) >> { > ... >> + suspend_thread( current ); > > Looks like a hack to me. You shouldn't be suspending/resuming threads > directly like this. They should block on open operation. > > Vitaliy. > > I figured that. At the time, though, I thought that this was the path of least resistance, but I wasn't sure. I guess now I should make open_file_object return STATUS_PENDING, then make FILE_CreateFile() wait until some object is signaled. (This is the way we do IOCTLs.) I'll send a patch shortly for this. Chip

Nov. 10, 2009

Re: mciwave: Rework MCI notification system.

by Paul Vriens

On 11/10/2009 12:56 PM, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Hi, > > same patch as yesterday, with more spaces and volatile and mciSave fix thrown out. > > I was about to resend > [PATCH 2] winmm: MCI Close all causes one notification per open driver. > which I rebased as well when I realised that it's independent on the code here > (but should logically follow the present patch as #2). So I'm not resending that anew. > Please include it as well. > > Likewise, yesterday's > PATCH mciwave: Stop must not reset current position. > is completely independent on the notification stuff, so I'm not resubmitting it, > even though I sent it in third position. > > Well, I'll wait and see what feedback I get and what appears in git. > > Regards, > Jörg Höhle > Hi Jörg, Please resend all patches you want to have committed in a series with the proper numbering. If they can be applied independently then numbering is (strictly speeking) not needed but it does show where you're going. I'm not sure if it's only me but I have a hard time keeping tracking of all the patches you sent and what (or not) to apply in what order. -- Cheers, Paul.

Nov. 10, 2009

Re: Cpp Check Nov. 7th

by Alexandre Julliard

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. -- Alexandre Julliard julliard(a)winehq.org

Nov. 10, 2009

Re: Wine 64-bit in Fedora ...

by Michael Stefaniuc

Uwe Bonnes wrote: >>>>>> "Michael" == Michael Stefaniuc <mstefani(a)redhat.com> writes: > > Michael> Fedora includes now a 64-bit Wine package (at least in F11) > Michael> which of course breaks existing Wine setups. "yum install wine" > Michael> will install the 64-bit version... Looks like we had our > Michael> WineConf too late for this. > > Michael> I have opened > Michael> https://bugzilla.redhat.com/show_bug.cgi?id=533988 for this > Michael> problem. > > Michael> The quick fix is to just remove the wine*.x86_64 rpms and > Michael> install the wine*.i586 instead. > > Did nobody of the packages test what they did? It is easy to miss as it requires: - Fresh install of Wine (via PackageKit or yum install) and - Old 32-bit WINEPREFIX. An update of Wine will pull the packages from the same arch aka i586 and thus the problem won't be visible for the people that just update their packages. That explains the limited outcry considering the impact of the problem. bye michael

Nov. 10, 2009

Re: Wine 64-bit in Fedora ...

by Damjan Jovanovic

On Tue, Nov 10, 2009 at 1:48 PM, Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote: >>>>>> "Michael" == Michael Stefaniuc <mstefani(a)redhat.com> writes: > > Michael> Fedora includes now a 64-bit Wine package (at least in F11) > Michael> which of course breaks existing Wine setups. "yum install wine" > Michael> will install the 64-bit version... Looks like we had our > Michael> WineConf too late for this. > > Michael> I have opened > Michael> https://bugzilla.redhat.com/show_bug.cgi?id=533988 for this > Michael> problem. > > Michael> The quick fix is to just remove the wine*.x86_64 rpms and > Michael> install the wine*.i586 instead. > > Did nobody of the packages test what they did? No surprise there. At one point some distributions packaged wineserver as an /etc/init.d service, because it sounds like a system-wide server... Autopackage had the right idea: the developers of a project should do the packaging. > -- > Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- > > > Damjan

Nov. 10, 2009

Re: Wine 64-bit in Fedora ...

by Uwe Bonnes

>>>>> "Michael" == Michael Stefaniuc <mstefani(a)redhat.com> writes: Michael> Fedora includes now a 64-bit Wine package (at least in F11) Michael> which of course breaks existing Wine setups. "yum install wine" Michael> will install the 64-bit version... Looks like we had our Michael> WineConf too late for this. Michael> I have opened Michael> https://bugzilla.redhat.com/show_bug.cgi?id=533988 for this Michael> problem. Michael> The quick fix is to just remove the wine*.x86_64 rpms and Michael> install the wine*.i586 instead. Did nobody of the packages test what they did? -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Nov. 10, 2009

Re: Wine 64-bit in Fedora ...

by Michael Stefaniuc

Austin English wrote: > On Mon, Nov 9, 2009 at 5:54 PM, Michael Stefaniuc <mstefani(a)redhat.com> wrote: >> Fedora includes now a 64-bit Wine package (at least in F11) which of course >> breaks existing Wine setups. "yum install wine" will install the 64-bit >> version... Looks like we had our WineConf too late for this. >> >> I have opened https://bugzilla.redhat.com/show_bug.cgi?id=533988 for this >> problem. >> >> The quick fix is to just remove the wine*.x86_64 rpms and install the >> wine*.i586 instead. > > Actually, Roderick and I noticed this on IRC, with a user who couldn't > get wine to run more than a couple times on a single prefix. Oh, I didn't claim that I found the problem. I have seen arethusa on #winehq helping users get rid of Wine in the 64-bit flavor from Fedora. I have just verified that "yum install wine" will indeed give a 64-bit Wine, checked the (rpm) spec file and opened a bug in the Fedora bugzilla. Thanks for helping those users. bye michael

Nov. 10, 2009

Re: setupapi: add stub and some tests for SetupGetInfFileListW [resend]

by Henri Verbeet

2009/11/9 Stefan Leichter <Stefan.Leichter(a)camline.com>: > my crystal ball is still not working, therefore resending unchanged > Try http://source.winehq.org/patches/ And indeed, the patch doesn't apply: diff -urw wine-git/dlls/setupapi/install.c wine-build/dlls/setupapi/install.c --- a/wine-git/dlls/setupapi/install.c +++ b/wine-build/dlls/setupapi/install.c Note that you're also adding whitespace errors.

Nov. 10, 2009

Re: [PATCH 4] mciwave: Rework MCI notification system.

by Vitaliy Margolen

Vitaliy Margolen wrote: > Joerg-Cyril.Hoehle(a)t-systems.com wrote: >> + HANDLE old = InterlockedExchangePointer(&wmw->hCallback, NULL); >> + if (old) mciDriverNotify(old,wDevID,MCI_NOTIFY_SUPERSEDED); >> + mciDriverNotify(HWND_32(LOWORD(hWndCallBack)),wDevID,wStatus); > Here and everywhere else in your patches, please add space before commas. Of course I meant after comas. Vitaliy.

Nov. 9, 2009

Re: [PATCH] server, ntoskrnl: Implement support for IRP_MJ_CREATE requests.

by Vitaliy Margolen

Charles Davis wrote: > Also, add stub handlers in mountmgr. > > This patch fixes an issue with the previous one where wine would hang if > ntoskrnl got a STATUS_BUFFER_OVERFLOW back from thes server. > --- > +int suspend_thread( struct thread *thread ); > +int resume_thread( struct thread *thread ); > +static void complete_open( struct open_call *open, unsigned int status ) > +{ ... > + resume_thread( open->call.thread ); > This static struct object *device_open_file( struct object *obj, unsigned int access, > unsigned int sharing, unsigned int options ) > { ... > + suspend_thread( current ); Looks like a hack to me. You shouldn't be suspending/resuming threads directly like this. They should block on open operation. Vitaliy.

Nov. 9, 2009

Re: ntdll: fix memory leak in GetDiskFreeSpaceW

by Vitaliy Margolen

Dan Kegel wrote: > Found while valgrinding chromium's app_unittests. > > + done: > + RtlFreeHeap(GetProcessHeap(), 0, val.Buffer); > + You should us RtlFreeUnicodeString( &val ); instead. Vitaliy.

Nov. 9, 2009

Multithreaded debugging

by Peter Urbanec

Eric Pouech wrote: > Peter Urbanec a écrit : >> It can't be as simple as updating the value of dbg_curr_thread with >> the result of dbg_get_thread(dbg_curr_process, tid) and then calling >> GetThreadContext(dbg_curr_thread->handle, &dbg_context), can it? >> > the changes will need to be larger than that > winedbg assumes throughout the code that it's stopped in a single thread > but, if you change dbg_curr_thread, and enter the 'cont' command, you > have to decide which thread should be resumed > therefore, the changes imply to use two different objects: > - the thread on which an exception occured > - the thread you're currently examining > and that's not a simple task > moreover it'll be hard to understand the difference between the two > above mentionned thread objects > > so, finding another solution might be preferable > what are the thread's missing information you were thinking of ? I would like to do the following: [ exception / attach to process ] [ all threads in process are now suspended ] info threads thread 0x42 bt info locals print *some_class up info locals print *some_var Or in other words, being able to examine the state of any thread, including the state of local variables in various stack frames, would be invaluable in determining how various threads got to where they are and what they are doing. Obviously, the above example is only workable if all threads in the debugged process are suspended. If only the current thread is suspended, it makes it very difficult to debug multithreaded code anyway. Controlling execution of individual threads with cont is not very important to me. I'd be quite happy for the debugger to stop and start all threads in a process together. The application that I am working with routinely has around 20-30 threads in interactive use and the thread count goes even higher when rendering jobs are started. Best regards, Peter Urbanec

Nov. 9, 2009

Re: Wine 64-bit in Fedora ...

by Austin English

On Mon, Nov 9, 2009 at 5:54 PM, Michael Stefaniuc <mstefani(a)redhat.com> wrote: > Fedora includes now a 64-bit Wine package (at least in F11) which of course > breaks existing Wine setups. "yum install wine" will install the 64-bit > version... Looks like we had our WineConf too late for this. > > I have opened https://bugzilla.redhat.com/show_bug.cgi?id=533988 for this > problem. > > The quick fix is to just remove the wine*.x86_64 rpms and install the > wine*.i586 instead. Actually, Roderick and I noticed this on IRC, with a user who couldn't get wine to run more than a couple times on a single prefix. -- -Austin

Nov. 9, 2009

Wine 64-bit in Fedora ...

by Michael Stefaniuc

Fedora includes now a 64-bit Wine package (at least in F11) which of course breaks existing Wine setups. "yum install wine" will install the 64-bit version... Looks like we had our WineConf too late for this. I have opened https://bugzilla.redhat.com/show_bug.cgi?id=533988 for this problem. The quick fix is to just remove the wine*.x86_64 rpms and install the wine*.i586 instead. bye michael

Nov. 9, 2009

avifile bugfixes

by Julius Schwartzenberg

Here are some bugfixes for avifile that Maarten mainly did during WineConf. The behaviour corresponds to what native avifil32 does. I will add tests to show this and submit the patches then. (Maybe avifil32 does a few more hacks like these, I'll add those too when I find them when creating tests.) If anyone has any comments on the patches as they are now already, please let me know. Thanks! Julius >From 2e9c13211c0343fd59faf835a1d954416ab46203 Mon Sep 17 00:00:00 2001 From: Julius Schwartzenberg <julius.schwartzenberg(a)gmail.com> Date: Sun, 8 Nov 2009 15:18:26 +0100 Subject: [PATCH 1/3] avifile: Fix header for audio stream --- dlls/avifil32/avifile.c | 10 +++++++++- 1 files changed, 9 insertions(+), 1 deletions(-) diff --git a/dlls/avifil32/avifile.c b/dlls/avifil32/avifile.c index 49e141f..4ecc6f6 100644 --- a/dlls/avifil32/avifile.c +++ b/dlls/avifil32/avifile.c @@ -1816,7 +1816,15 @@ static HRESULT AVIFILE_LoadFile(IAVIFileImpl *This) if (FAILED(hr)) return hr; }; - + if (pStream->lpFormat != NULL && pStream->sInfo.fccType == streamtypeAUDIO) + { + WAVEFORMATEX *wfx = pStream->lpFormat; + wfx->nBlockAlign = wfx->nChannels * wfx->wBitsPerSample / 8; + pStream->sInfo.dwSampleSize = wfx->nBlockAlign; + TRACE("Block size reset to %u, chan=%u bpp=%u\n", wfx->nBlockAlign, wfx->nChannels, wfx->wBitsPerSample); + pStream->sInfo.dwScale = 1; + pStream->sInfo.dwRate = wfx->nSamplesPerSec; + } if (mmioAscend(This->hmmio, &ck, 0) != S_OK) return AVIERR_FILEREAD; } -- 1.6.3.3 >From 969620de75ae75d13cf5f443842cee8bf28c4362 Mon Sep 17 00:00:00 2001 From: Julius Schwartzenberg <julius.schwartzenberg(a)gmail.com> Date: Sun, 8 Nov 2009 15:28:19 +0100 Subject: [PATCH 2/3] avifile: Fix header suggested buffersize --- dlls/avifil32/avifile.c | 12 +++++++++--- 1 files changed, 9 insertions(+), 3 deletions(-) diff --git a/dlls/avifil32/avifile.c b/dlls/avifil32/avifile.c index 4ecc6f6..c40cbd9 100644 --- a/dlls/avifil32/avifile.c +++ b/dlls/avifil32/avifile.c @@ -1652,7 +1652,7 @@ static HRESULT AVIFILE_LoadFile(IAVIFileImpl *This) This->fInfo.dwCaps = AVIFILECAPS_CANREAD|AVIFILECAPS_CANWRITE; This->fInfo.dwLength = MainAVIHdr.dwTotalFrames; This->fInfo.dwStreams = MainAVIHdr.dwStreams; - This->fInfo.dwSuggestedBufferSize = MainAVIHdr.dwSuggestedBufferSize; + This->fInfo.dwSuggestedBufferSize = 0; This->fInfo.dwWidth = MainAVIHdr.dwWidth; This->fInfo.dwHeight = MainAVIHdr.dwHeight; LoadStringW(AVIFILE_hModule, IDS_AVIFILETYPE, This->fInfo.szFileType, @@ -1754,8 +1754,7 @@ static HRESULT AVIFILE_LoadFile(IAVIFileImpl *This) pStream->sInfo.dwRate = streamHdr.dwRate; pStream->sInfo.dwStart = streamHdr.dwStart; pStream->sInfo.dwLength = streamHdr.dwLength; - pStream->sInfo.dwSuggestedBufferSize = - streamHdr.dwSuggestedBufferSize; + pStream->sInfo.dwSuggestedBufferSize = 0; pStream->sInfo.dwQuality = streamHdr.dwQuality; pStream->sInfo.dwSampleSize = streamHdr.dwSampleSize; pStream->sInfo.rcFrame.left = streamHdr.rcFrame.left; @@ -1905,6 +1904,13 @@ static HRESULT AVIFILE_LoadFile(IAVIFileImpl *This) } } + for (nStream = 0; nStream < This->fInfo.dwStreams; nStream++) + { + DWORD sugbuf = This->ppStreams[nStream]->sInfo.dwSuggestedBufferSize; + if (This->fInfo.dwSuggestedBufferSize < sugbuf) + This->fInfo.dwSuggestedBufferSize = sugbuf; + } + /* find other chunks */ FindChunkAndKeepExtras(&This->fileextra, This->hmmio, &ck, &ckRIFF, 0); -- 1.6.3.3 >From 39d6ecab76989b93d35a0568e105fd306fa32706 Mon Sep 17 00:00:00 2001 From: Julius Schwartzenberg <julius.schwartzenberg(a)gmail.com> Date: Sun, 8 Nov 2009 15:32:33 +0100 Subject: [PATCH 3/3] avifile: Fix playback of fixed sample size audio stream --- dlls/avifil32/avifile.c | 14 ++++++++++---- 1 files changed, 10 insertions(+), 4 deletions(-) diff --git a/dlls/avifil32/avifile.c b/dlls/avifil32/avifile.c index c40cbd9..5fa45ae 100644 --- a/dlls/avifil32/avifile.c +++ b/dlls/avifil32/avifile.c @@ -1093,6 +1093,9 @@ static HRESULT WINAPI IAVIStream_fnRead(IAVIStream *iface, LONG start, /* convert samples to bytes */ samples *= This->sInfo.dwSampleSize; + if (!buffer) + buffersize = samples; + while (samples > 0 && buffersize > 0) { if (block != This->dwCurrentFrame) { hr = AVIFILE_ReadBlock(This, block, NULL, 0); @@ -1102,11 +1105,12 @@ static HRESULT WINAPI IAVIStream_fnRead(IAVIStream *iface, LONG start, size = min((DWORD)samples, (DWORD)buffersize); size = min(size, This->cbBuffer - offset); - memcpy(buffer, ((BYTE*)&This->lpBuffer[2]) + offset, size); - + if (buffer) + memcpy(buffer, ((BYTE*)&This->lpBuffer[2]) + offset, size); block++; offset = 0; - buffer = ((LPBYTE)buffer)+size; + if (buffer) + buffer = ((LPBYTE)buffer)+size; samples -= size; buffersize -= size; @@ -1117,7 +1121,9 @@ static HRESULT WINAPI IAVIStream_fnRead(IAVIStream *iface, LONG start, *samplesread += size / This->sInfo.dwSampleSize; } - if (samples == 0) + TRACE("Returning %d/%d\n", bytesread ? *bytesread : -1, samplesread ? *samplesread : -1); + + if (samples == 0 || !buffer) return AVIERR_OK; else return AVIERR_BUFFERTOOSMALL; -- 1.6.3.3

Nov. 9, 2009

Re: Question about GetTokenInformation and memory leaks

by Reece Dunn

2009/11/9 Dan Kegel <dank(a)kegel.com>: > I've never used the security apis, so I'm pretty unfamiliar with them. > Valgrinding chromium's sandbox_unittests.exe shows the leak > > (I think the code leaks token_handle, but fixing > that doesn't get rid of the reported leak.) token_handle does not leak -- access_token is managing it via `access_token.Attach(token_handle);` (when OpenProcessToken succeeds and token_handle is not NULL).

Nov. 9, 2009

Re: Question about GetTokenInformation and memory leaks

by Rob Shearman

2009/11/9 Dan Kegel <dank(a)kegel.com>: > I've never used the security apis, so I'm pretty unfamiliar with them. > Valgrinding chromium's sandbox_unittests.exe shows the leak > > 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) > by ATL::CAccessToken::GetInfoConvert<ATL::CSid,_TOKEN_PRIMARY_GROUP> > (atlsecurity.h:754) > by ATL::CAccessToken::GetPrimaryGroup (atlsecurity.inl:3623) > by sandbox::RestrictedTokenTest_CustomInit_Test::TestBody > (restricted_token_unittest.cc:92) > > The test in question is on line 92 of > http://src.chromium.org/viewvc/chrome/trunk/src/sandbox/src/restricted_toke… > > Can someone familiar with this stuff have a look? > I suspect it's a problem with the test, but > can't figure out what's going on. I would > have thought the destructors for ATL::CAccessToken > and ATL::CSid would have freed everything. > (I think the code leaks token_handle, but fixing > that doesn't get rid of the reported leak.) Hi Dan, The bug is in the Wine code. Try the attached patch, which should fix it as a side-effect. Thanks, -- Rob Shearman

Nov. 9, 2009

Question about GetTokenInformation and memory leaks

by Dan Kegel

I've never used the security apis, so I'm pretty unfamiliar with them. Valgrinding chromium's sandbox_unittests.exe shows the leak 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) by ATL::CAccessToken::GetInfoConvert<ATL::CSid,_TOKEN_PRIMARY_GROUP> (atlsecurity.h:754) by ATL::CAccessToken::GetPrimaryGroup (atlsecurity.inl:3623) by sandbox::RestrictedTokenTest_CustomInit_Test::TestBody (restricted_token_unittest.cc:92) The test in question is on line 92 of http://src.chromium.org/viewvc/chrome/trunk/src/sandbox/src/restricted_toke… Can someone familiar with this stuff have a look? I suspect it's a problem with the test, but can't figure out what's going on. I would have thought the destructors for ATL::CAccessToken and ATL::CSid would have freed everything. (I think the code leaks token_handle, but fixing that doesn't get rid of the reported leak.) - Dan

Nov. 9, 2009

Re: Question on using winedbg when program does not crash, just becomes unresponsive

by Eric Pouech

Peter Urbanec a écrit : > > Dan Kegel wrote: >> start winedbg without any app >> say 'bt all' in winedbg >> Voila, you now have backtraces for every process, including the hung >> one. >> It's your job to get that into a text file and remove the >> uninteresting ones... > > > I've also been trying to debug a multithreaded app. There are at least > two complications that winedbg throws up: > > 1. Is now documented in http://bugs.winehq.org/show_bug.cgi?id=20617 > > 2. As far as I can tell, winedbg will not allow you to switch the > current thread context. This means that even though you can get a > backtrace of all threads in all processes, you actually can not > examine the state of a specific thread. > > I don't know enough about the internals of wine to go ahead and > implement a "thread tid" command. I could manage the code in dbg.y and > debug.l to implement the command line interface. When it comes to the > actual implementation, I can sort of guess at what may need to be done > there. However, I suspect that my naive attempts at an implementation > are unlikely to produce an acceptable patch. > > It can't be as simple as updating the value of dbg_curr_thread with > the result of dbg_get_thread(dbg_curr_process, tid) and then calling > GetThreadContext(dbg_curr_thread->handle, &dbg_context), can it? > the changes will need to be larger than that winedbg assumes throughout the code that it's stopped in a single thread but, if you change dbg_curr_thread, and enter the 'cont' command, you have to decide which thread should be resumed therefore, the changes imply to use two different objects: - the thread on which an exception occured - the thread you're currently examining and that's not a simple task moreover it'll be hard to understand the difference between the two above mentionned thread objects so, finding another solution might be preferable what are the thread's missing information you were thinking of ? A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

Nov. 9, 2009

Re: The user32/win test crashes X on Intel cards

by Reece Dunn

2009/11/9 <Joerg-Cyril.Hoehle(a)t-systems.com>: > Hi, > >>Marcus got the same issue and he had an Intel card too > > Charles Davis wrote: >>This happens on Mac OS X, too. Check out >>http://xquartz.macosforge.org/trac/ticket/293 > > Charles forgot to mention that it affects NVidia on the Mac, which I did > not explicitly write in the above bug report (the Mac people will have > guessed it from the "early 2009 Mac mini" comment). > > More precisely > SetWindowPos(hwnd, 0, -32769, -40000, -32769, -90000, SWP_NOMOVE); > #if 0 > SetWindowPos(hwnd, 0, 32768, 40000, 32768, 40000, SWP_NOMOVE); > #endif > SetWindowPos(hwnd, 0, -32769, -40000, -32769, -90000, SWP_NOSIZE); > SetWindowPos(hwnd, 0, 32768, 40000, 32768, 40000, SWP_NOSIZE); > is enough to let the tests succeed with > Version: 2.3.3.2 (2.3.3) > Build Info: X11server-480700~6 > OS Version: Mac OS X 10.5.7 (9J61) > > This hints that the bug is in the X server, not the individual drivers? Shouldn't this be cross-posted to the Xorg mailing list so that the Xorg and driver devs can help out? Also, does anyone know if it is possible to see what calls to the X server are being made by these SetWindowPos calls (so that the Xorg devs have a better idea of what is going on). - Reece

Nov. 9, 2009

Re: To error out or to skip tests?

by Reece Dunn

2009/11/9 <Joerg-Cyril.Hoehle(a)t-systems.com>: > Reece, > > I think we reached agreement on: > a) Tests should "usually" succeed. > b) machines without sound are usual (e.g. in virtual server env.). > c) I'll modify the MCI tests to succeed on machines without sound. > But for some other points, I've trouble following you. Yes. >>> The relevant question becomes: when is a configuration unusual? When >>> can it be ignored for the purpose of Wine and when is it relevant? >>Answer: no configuration is unusual. > Huh? You asked "when is a configuration unusual?" That is, are the following unusual: 1/ using a non-English locale (e.g. German or Polish); 2/ using a non-Western locale (e.g. Chinese or Japanese); 3/ using classic theme in XP or later; 4/ using 120DPI or higher; 5/ using a high-contrast theme; 6/ not having DirectX installed; 7/ having a Windows install on a drive other than C:\ 8/ ... My point is that none of these (and other configurations/setups in Windows) should be considered unusual. They may (or may not) be the default, but they are possible. >From the perspective of Wine (and the Wine tests), if it is possible in Windows (on VMware or natively) then it should be handled properly in the tests and not fail the tests. >>The point is, if the machine has a broken soundcard (or in Wine does >>not have an available sound driver, or is broken due to PulseAudio on >>Ubuntu), the tests should still pass (or be skipped) as is >>appropriate. > > This seems wrong (in general) to me, even though Paul somehow > expresses an opinion similar to yours. I say you cannot write a > program meant to run in a completely unknown environment, doing > comprehensive tests and not stumbling upon strange behaviour. Write the tests initially for the known valid environments, then fix up issues as they are seen on test.winehq.org (for example, if some of the comctl32/user32 tests fail because they are run in 120DPI instead of 96DPI). You cannot cater for a completely unknown environment, but those on test.winehq.org are not unknown. Also, it is not feasible to always do comprehensive tests (e.g. on Win9x when *W functions are not present). The point is to do what you can in those cases. > The program is specifically designed to detect and flag deviant behaviour. > All that can be achieved in a program is to be prepared for a known > set of scenarios (a broken soundcard is such a scenerio), aka. use-case. > Outside these known use-cases, the tests throw an error. Otherwise > there's no point in ok() at all. You have a set of defined behaviour for the mci API when there is a sound card present. Good -- the tests should cover that. You also have a set of defined behaviour for the mci API when a sound card/driver is not present. Good -- the tests should handle this (e.g. by defining the set of valid return values). > I agree that for the known use-cases (these explicitly include > configurations without sound), the tests should succeed. Yes. > What can be done is what you say: >>If we find that other situations need correcting (due to >>failing tests), they can be looked at then. > ... then decide whether the cause of the failing test is "unusual" or not. No -- look at *why* the test is failing. This will either be that the test is doing something wrong (e.g. not creating a test file), or that it is not covering a valid situation. The cause being "unusual" or not has no relevance. Either the test is wrong, or Windows is broken. >>The point I am making is that: >> 1. The error and skip statements are saying the same thing; >> 2. But the skip message is misleading. > Indeed, sorry for that. > There's a dependency. The tests depend on record working to generate the > file to be played, instead of including one in git. > So they fail to test machines that can play but not record. Sure. > Obviously I'll have to do something else in the yet to be written MIDI tests. > > BTW, this raises the question whether Wine should include a tiny wave file > for completeness. Invoking the MCI Sound command always plays some sound. Is it possible to generate the wav file programatically, without using the record functionality? >>If I have counted the offsets correctly 275 is >>MCIERR_DEVICE_NOT_READY, *not* that tempfile.wav was not found. > Wrong. 275 - 256 is 19, which you look up in mmsystem.h: > #define MCIERR_FILE_NOT_FOUND (MCIERR_BASE + 19) Ah yes. >> default: >> ok(!err, "mciSendString('open') failed, expected NOERROR, got >>%s", dbg_mcierr(err)); >> } > In the default case, if (err) you must return (with or without skip message). > You cannot continue if open fails. So it summarizes to: > if (err) { > /* list of situations that were analysed as "usual": */ > ok(err=FILE_NOT_FOUND || err==MCIERR_CANNOT_LOAD_DRIVER || err==xyz ...); > skip("Cannot test playback, cause %s",dbg_mcierr(err)); > return > } > >> case MCIERR_CANNOT_LOAD_DRIVER: >> 2. sound is not present on the system. > Perhaps there's a misconception? That's not how MS-Windows systems without > sound drivers present themselves. Ge's, Paul's and my father in law's > machines all include the MCI (and waveaudio.dll etc.). It's only at > WAVE_Open time that failure is detected, e.g. Cue, Record or Play, and > the error is MCIERR_WAVE_INPUTSUNSUITABLE for instance. > (That's not entirely true, it does not explain the setformat pcm failure). > I.e. no mciwave present at all so far is an "unusual" situation, and generates an error. In the example I gave, don't look at the exact error codes -- look more at the situations (tempfile.wav does not exist, sound not available). Also, if (err==MCIERR_FILE_NOT_FOUND || err==...) { skip("Cannot test playback (err=%s)",dbg_mcierr(err)); return; } ok(!err, ...); The point here is that tempfile.wav not existing, sound not available, or a broken sound driver should not cause the ok line to fail. These are valid situations that mean that the playback tests cannot be run. Now, arguably the tests should be modified so that tempfile.wav always exist. This would then address a chunk of the test failures that are happening on all machines at present. IIUC, that file is being generated through the record API of mci? Isn't there a way to programatically create the WAV/PCM data through the use of math.h functions? - Reece

Nov. 9, 2009

Re: To error out or to skip tests?

by Reece Dunn

2009/11/9 Paul Vriens <paul.vriens.wine(a)gmail.com>: > On 11/09/2009 07:25 PM, Joerg-Cyril.Hoehle(a)t-systems.com wrote: >> >> Reece, >> >> I think we reached agreement on: >> a) Tests should "usually" succeed. > > I didn't read that in any of the emails. Tests should always succeed. the > broken() and skip() will help in achieving that. I used "usually" succeed to avoid handling out-of-memory cases and other similar cases. - Reece

Nov. 9, 2009

The user32/win test crashes X on Intel cards

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

Hi, >Marcus got the same issue and he had an Intel card too Charles Davis wrote: >This happens on Mac OS X, too. Check out >http://xquartz.macosforge.org/trac/ticket/293 Charles forgot to mention that it affects NVidia on the Mac, which I did not explicitly write in the above bug report (the Mac people will have guessed it from the "early 2009 Mac mini" comment). More precisely SetWindowPos(hwnd, 0, -32769, -40000, -32769, -90000, SWP_NOMOVE); #if 0 SetWindowPos(hwnd, 0, 32768, 40000, 32768, 40000, SWP_NOMOVE); #endif SetWindowPos(hwnd, 0, -32769, -40000, -32769, -90000, SWP_NOSIZE); SetWindowPos(hwnd, 0, 32768, 40000, 32768, 40000, SWP_NOSIZE); is enough to let the tests succeed with Version: 2.3.3.2 (2.3.3) Build Info: X11server-480700~6 OS Version: Mac OS X 10.5.7 (9J61) This hints that the bug is in the X server, not the individual drivers? Regards, Jörg Höhle

Nov. 9, 2009