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

Re: Add .cvsignore entries for .fake files

by Stephen Eilert

On Mon, Nov 23, 2009 at 7:07 AM, Paul Chitescu <paulc(a)voip.null.ro> wrote: > On Friday 20 November 2009 05:43:48 pm Charles Davis wrote: > > Paul Chitescu wrote: > > > On Monday 16 November 2009 04:11:25 pm Paul Chitescu wrote: > > >> Changelog: > > >> Add .cvsignore entries for .fake files. > > > > > > What's wrong with this? Applies cleanly to my pristine wine-CVS, tried > with > > > patch taken from wine-patches bounce. > > > > > > Whoever rejected with "fails to apply" please reply with the output. > > > > > > > > > > > We don't use CVS anymore. Now we use git. You need to first upgrade to > > git, then modify the .gitignore file. > > > > Chip > > Obviously I use CVS and the ? ......fake status reports are a nuissance. > The > fact you don't care about CVS doesn't mean everybody has to switch, > especially > since git isn't supported as widely as CVS. > What do you mean by "git isn't supported as widely as CVS"? In any case, CVS is *ancient*. You really should learn how to use git, specially if you want to contribute to wine. It'll make your life easier, after the initial learning curve. For instance, I'd hate to do regression testing using CVS, instead of a git bisect. --Stephen programmer, n: A red eyed, mumbling mammal capable of conversing with inanimate monsters.

Nov. 23, 2009

winmm: Don't stop parsing after MCI's alias keyword.

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

Dan Kegel wrote: >Looks like I ignore files that only contain leak errors: >You can still see the leaks in the full log, >http://kegel.com/wine/valgrind/logs/2009-11-19-08.35.log Ah, I was surprised to find no mention of winmm in the normal log ;) >should I stop ignoring modules that only have leak errors? I was lulled into false confidence by not seing errors. Perhaps I'd have caught a message at the top of the web logs page. >Also, mci tests hang on my system and need to be killed, >so I may be missing some errors because of that. Hmm, you already mentioned this one earlier: >err:wave:wodPlayer_WriteMaxFrags Error in writing wavehdr. > Reason: Resource temporarily unavailable Is there anything you can change to your sound configuration to avoid it? I don't see why the winmm wave and capture tests pass while only mci generates hundreds of this warning. Can you run WINETEST_INTERACTIVE=1 wave.ok or capture.ok? I've only seen this error sequence once or twice in my tests. >preloader: Warning: failed to reserve range 00110000-68000000 ?? Regards, Jörg Höhle.

Nov. 23, 2009

Re: winspool: Don't use 16Bit gdi.exe function for DeviceCapabilitiesA/W

by Alexandre Julliard

Detlef Riekenberg <wine.dev(a)web.de> writes: > - if (!GDI_CallDeviceCapabilities16) > - { > - GDI_CallDeviceCapabilities16 = (void*)GetProcAddress( GetModuleHandleA("gdi32"), > - (LPCSTR)104 ); > - if (!GDI_CallDeviceCapabilities16) return -1; > - } > - ret = GDI_CallDeviceCapabilities16(pDevice, pPort, cap, pOutput, lpdm); > - > - /* If DC_PAPERSIZE map POINT16s to POINTs */ > - if(ret != -1 && cap == DC_PAPERSIZE && pOutput) { > - POINT16 *tmp = HeapAlloc( GetProcessHeap(), 0, ret * sizeof(POINT16) ); > - POINT *pt = (POINT *)pOutput; You can't remove the 16-bit conversion if you are still calling the existing driver. Probably a better approach is to first add a DrvDeviceCapabilities to the wineps driver. -- Alexandre Julliard julliard(a)winehq.org

Nov. 23, 2009

re: winmm: Don't stop parsing after MCI's alias keyword.

by Dan Kegel

Joerg wrote: > I'm surprised that valgrind did not complain about the bug... Looks like I ignore files that only contain leak errors: http://code.google.com/p/winezeug/source/browse/trunk/valgrind/valgrind-spl… on the theory that we're already overwhelmed dealing with non-leak errors. You can still see the leaks in the full log, http://kegel.com/wine/valgrind/logs/2009-11-19-08.35.log What do people think - should we focus on non-leak errors for a while (in which case I should suppress all leak errors), or should I stop ignoring modules that only have leak errors? Also, mci tests hang on my system and need to be killed, so I may be missing some errors because of that. (Finally, my automated runs are on hold while I add use-after-free detection. I'm lame, and use the same source tree for develoment and for the automated runs. One of these days I should separate them. Or somebody else could do the automated runs...) - Dan

Nov. 23, 2009

Re: Add .cvsignore entries for .fake files

by Alexandre Julliard

Paul Chitescu <paulc(a)voip.null.ro> writes: > Can someone clarify if there's a relation between .gitignore and .cvsignore > files? Are they synchronized somehow? > > If .cvsignore is generated from .gitignore then there's something wrong. > > If .cvsignore files are stored separately in CVS then the patch can be applied > only there by AJ (I've seen the repository being locked by user "juillard" > while applying the patches). They are generated, IIRC they get updated when the makefile changes or something like that. The scripts are in tools.git if you want to improve them. -- Alexandre Julliard julliard(a)winehq.org

Nov. 23, 2009

Re: server: Only require REG_OPTION_VOLATILE when creating a new key.

by Paul Vriens

Hi Alexandre, With this patch the following errors are introduced when starting anything on a clean .wine : err:setupapi:registry_callback could not create key 0x80000002 L"HARDWARE\\DEVICEMAP\\PARALLEL PORTS" err:setupapi:registry_callback could not create key 0x80000002 L"HARDWARE\\DEVICEMAP\\SERIALCOMM" -- Cheers, Paul.

Nov. 23, 2009

Re: Add .cvsignore entries for .fake files

by Paul Chitescu

On Friday 20 November 2009 05:43:48 pm Charles Davis wrote: > Paul Chitescu wrote: > > On Monday 16 November 2009 04:11:25 pm Paul Chitescu wrote: > >> Changelog: > >> Add .cvsignore entries for .fake files. > > > > What's wrong with this? Applies cleanly to my pristine wine-CVS, tried with > > patch taken from wine-patches bounce. > > > > Whoever rejected with "fails to apply" please reply with the output. > > > > > > > We don't use CVS anymore. Now we use git. You need to first upgrade to > git, then modify the .gitignore file. > > Chip Obviously I use CVS and the ? ......fake status reports are a nuissance. The fact you don't care about CVS doesn't mean everybody has to switch, especially since git isn't supported as widely as CVS. Can someone clarify if there's a relation between .gitignore and .cvsignore files? Are they synchronized somehow? If .cvsignore is generated from .gitignore then there's something wrong. If .cvsignore files are stored separately in CVS then the patch can be applied only there by AJ (I've seen the repository being locked by user "juillard" while applying the patches). Regards, Paul

Nov. 23, 2009

Re: FAT32 support (was: [RFC] Handle process token groups in server/file.c::sd_to_mode)

by Ben Peddell

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Chitescu wrote: > How should server/file.c sd_to_mode() deal with filesystems that don't support > full POSIX ownership and access permissions? It is quite popular to mount FAT > filesystems - either from a removable media or a partition shared with a > Windows installation. A workaround for the moment on linux would be to use the uid=<your_uid> option when mounting the a FAT filesystem, as the linux vfat filesystem driver basically ignores chmod (except for the u+w bit) when the user executing chmod is the owner of the filesystem. I don't know if Mac OS X, *BSD or Solaris do the same. (tracing using procmon and setacl) NtQuerySecurityObject and NtSetSecurityObject return STATUS_INVALID_DEVICE_REQUEST on Windows XP when attempting to get or set a security descriptor on a FAT filesystem. (musing) I wonder if it'd be possible to have a special SD pointer (such as -1 or a special SD_INVALID_DEVICE_REQUEST descriptor) in a wineserver object to say that neither the object nor any of its children can hold security descriptors? After all, you cannot put volume mount points on a FAT filesystem, so nothing under a FAT filesystem would be able to hold a security descriptor. obj->get_sd() and obj->set_sd() would then be made to return STATUS_INVALID_DEVICE_REQUEST on such an object. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksJ6dQACgkQTHDAI68NsukvQQCePLlkXB7aT0HrrTUjarkdNAiv OcYAn3hYtfTwBveT/6ltNIiO8b2oD7ZH =bAgm -----END PGP SIGNATURE-----

Nov. 22, 2009

Re: Firefox not installing with winetricks. Reason: need to upgrade 3.5.3 to 3.5.5.

by Albert Lee

On Sat, 21 Nov 2009 20:49:13 -0800, Ido Tal <idotal(a)gmail.com> wrote: > Hi, > > I've just now tried to install firefox with winetricks and failed. A short > scan reveals what the problem is (I think): the version winetricks is > trying > to install is 3.5.3. Looking at > http://releases.mozilla.org/pub/mozilla.org/firefox/releases/ shows that > it's not there anymore. > > Hope this helps... > > Ido Hi, you may want to report the bug at http://code.google.com/p/winezeug/ since winetricks is hosted separately from winehq.org. -Albert

Nov. 22, 2009

Re: [PATCH 1/3] gdi32/tests: Test BitBlt() to an enhanced metafile.

by Austin English

On Sun, Nov 22, 2009 at 12:00 PM, Charles Davis <cdavis(a)mymail.mines.edu> wrote: > Austin English wrote: >> On Sat, Nov 21, 2009 at 11:15 PM, Charles Davis <cdavis(a)mymail.mines.edu> wrote: >>> Dmitry Timoshkov wrote: >>>> "Charles Davis" <cdavis(a)mymail.mines.edu> wrote: >>>> >>>>>> You forgot to remove if (1). >>>>>> >>>>> It goes away in patch #3. I thought I already had this discussion with >>>>> Paul. >>>>> >>>>> There's a reason it's there. EMF_BITBLT contains two BitBlt() records, >>>>> but the EMF we're comparing it to only has one. That's because one of >>>>> them is if(0)'d out because it crashes on Wine. So, if we try to compare >>>>> the EMF we produced to the EMF we expect, it will fail. Last I checked, >>>>> Alexandre doesn't like it when tests fail. All tests must pass on his >>>>> box. >>>> There are 2 solutions for that: >>>> 1. use todo_wine in the test, and remove it in a patch with the fix >>> The test will fail on Windows if I do that. >> >> That won't affect windows. It will only fail on wine if it passes. >> > You don't understand. The expected EMF bits contain TWO BitBlt() > records, but the EMF produced by the test contains only one. It will > contain only one on both Wine and Windows, because one of the calls to > BitBlt() is if(0)'d out. So the test will fail on Windows if the call to > compare_emf_bits() is marked todo_wine. Ah, my mistake. > Oh, and you didn't reply to all. Was that intentional? Yes, didn't think everyone needed to know what todo_wine did ;-). -- -Austin

Nov. 22, 2009

Re: Firefox not installing with winetricks. Reason: need to upgrade 3.5.3 to 3.5.5.

by Austin English

On Sat, Nov 21, 2009 at 10:49 PM, Ido Tal <idotal(a)gmail.com> wrote: > Hi, > > I've just now tried to install firefox with winetricks and failed. A short > scan reveals what the problem is (I think): the version winetricks is trying > to install is 3.5.3. Looking at > http://releases.mozilla.org/pub/mozilla.org/firefox/releases/ shows that > it's not there anymore. Hm, the link must of just broken today, because I ran winetrickstest yesterday and it was fine.. Fixed in SVN winetricks. -- -Austin

Nov. 22, 2009

Re: [PATCH 1/3] gdi32/tests: Test BitBlt() to an enhanced metafile.

by Charles Davis

Austin English wrote: > On Sat, Nov 21, 2009 at 11:15 PM, Charles Davis <cdavis(a)mymail.mines.edu> wrote: >> Dmitry Timoshkov wrote: >>> "Charles Davis" <cdavis(a)mymail.mines.edu> wrote: >>> >>>>> You forgot to remove if (1). >>>>> >>>> It goes away in patch #3. I thought I already had this discussion with >>>> Paul. >>>> >>>> There's a reason it's there. EMF_BITBLT contains two BitBlt() records, >>>> but the EMF we're comparing it to only has one. That's because one of >>>> them is if(0)'d out because it crashes on Wine. So, if we try to compare >>>> the EMF we produced to the EMF we expect, it will fail. Last I checked, >>>> Alexandre doesn't like it when tests fail. All tests must pass on his >>>> box. >>> There are 2 solutions for that: >>> 1. use todo_wine in the test, and remove it in a patch with the fix >> The test will fail on Windows if I do that. > > That won't affect windows. It will only fail on wine if it passes. > You don't understand. The expected EMF bits contain TWO BitBlt() records, but the EMF produced by the test contains only one. It will contain only one on both Wine and Windows, because one of the calls to BitBlt() is if(0)'d out. So the test will fail on Windows if the call to compare_emf_bits() is marked todo_wine. Oh, and you didn't reply to all. Was that intentional?

Nov. 22, 2009

Re: shell32/tests: Remove atime tests in ITEMIDLIST_format test.

by Paul Vriens

On 11/21/2009 12:18 AM, Austin Lund wrote: > 2009/11/21 Austin Lund<austin.lund(a)gmail.com>: >> 2009/11/21 Paul Vriens<paul.vriens.wine(a)gmail.com>: >> >>> if (abs(date2 - date1) == 1) >>> skip("We dont't check access times on a FAT filesystem\n"); >> >> >>> "The date is always within 1 day (plus or minus)." >> >> It isn't quite that easy as the date field is a bitpacked struct >> holding the year, month and day. So you have to account for month and >> year boundaries. In the absence of any other ideas or tips to where I >> can find a function to do this for me, I implement the calendaring >> increments and send a patch which follows the above idea. >> > > Here is an attempt at doing this. Is there a better/cleaner way to do this? A lot of code to get around this issue. I tried playing with DosDateTimeToFileTime() and CompareFileTime() but that doesn't help much either. I'm curious how important a test on a FAT filesystem is. If it's important we should test it otherwise I'd say your previous suggestion make sense: if (date1 == date2&& time1 == time2) ok(TRUE, "Blah"); else skip("Not testing access times on this filesystem\n"); What happens when these tests are run on Wine with a FAT filesystem btw? -- Cheers, Paul.

Nov. 22, 2009

Re: Someone please update the german translation of Ubuntu download page

by Marcus Meissner

On Sat, Nov 21, 2009 at 09:16:52PM -0600, Scott Ritchie wrote: > My German is inadequate and there are no instructions for Karmic users > there at the moment. I sent one just now. Also updated de/download.template Ciao, Marcus

Nov. 22, 2009

Re: [PATCH 1/3] gdi32/tests: Test BitBlt() to an enhanced metafile.

by Charles Davis

Dmitry Timoshkov wrote: > "Charles Davis" <cdavis(a)mymail.mines.edu> wrote: > >>> You forgot to remove if (1). >>> >> It goes away in patch #3. I thought I already had this discussion with >> Paul. >> >> There's a reason it's there. EMF_BITBLT contains two BitBlt() records, >> but the EMF we're comparing it to only has one. That's because one of >> them is if(0)'d out because it crashes on Wine. So, if we try to compare >> the EMF we produced to the EMF we expect, it will fail. Last I checked, >> Alexandre doesn't like it when tests fail. All tests must pass on his >> box. > > There are 2 solutions for that: > 1. use todo_wine in the test, and remove it in a patch with the fix The test will fail on Windows if I do that. > 2. add the test in the patch after a patch with the fix Very well then. I'll resend with the test reordered after the fix. > Chip

Nov. 21, 2009

Firefox not installing with winetricks. Reason: need to upgrade 3.5.3 to 3.5.5.

by Ido Tal

Hi, I've just now tried to install firefox with winetricks and failed. A short scan reveals what the problem is (I think): the version winetricks is trying to install is 3.5.3. Looking at http://releases.mozilla.org/pub/mozilla.org/firefox/releases/ shows that it's not there anymore. Hope this helps... Ido

Nov. 21, 2009

Next step: detect double-frees and use-after-free

by Dan Kegel

Now that the heap tail check is more or less working, I'm on to implementing protection against double frees and use-after-free for recently freed blocks. The idea is that HEAP_MakeInUseBlockFree() will take the block it's called with, push it onto a FIFO, pull an old block off the FIFO, and mark that old block free. The blocks languishing in the FIFO will be marked inaccessible. If you try to free one, realloc one, or even get its size, you'll get an immediate error; if you write to one, you'll get an error when it comes out of the FIFO or when the heap is validated; and if you're running Valgrind, you'll get an immediate error on read or write to the freed block. The FIFO will be drained when the heap is destroyed. It will be implemented using a standard wine list in an optional fixed-sized block at the tail of each allocation. Remind me again why we didn't do this years ago...

Nov. 21, 2009

Re: [PATCH 1/3] gdi32/tests: Test BitBlt() to an enhanced metafile.

by Dmitry Timoshkov

"Charles Davis" <cdavis(a)mymail.mines.edu> wrote: >> You forgot to remove if (1). >> > It goes away in patch #3. I thought I already had this discussion with > Paul. > > There's a reason it's there. EMF_BITBLT contains two BitBlt() records, > but the EMF we're comparing it to only has one. That's because one of > them is if(0)'d out because it crashes on Wine. So, if we try to compare > the EMF we produced to the EMF we expect, it will fail. Last I checked, > Alexandre doesn't like it when tests fail. All tests must pass on his box. There are 2 solutions for that: 1. use todo_wine in the test, and remove it in a patch with the fix 2. add the test in the patch after a patch with the fix -- Dmitry.

Nov. 21, 2009

Someone please update the german translation of Ubuntu download page

by Scott Ritchie

My German is inadequate and there are no instructions for Karmic users there at the moment. Thanks, Scott Ritchie

Nov. 21, 2009

Re: [PATCH 1/3] gdi32/tests: Test BitBlt() to an enhanced metafile.

by Charles Davis

Dmitry Timoshkov wrote: > "Charles Davis" <cdavis(a)mymail.mines.edu> wrote: > >> + if(1 || compare_emf_bits(hMetafile, EMF_BITBLT, sizeof(EMF_BITBLT), >> + "emf_BitBlt", FALSE) != 0) >> + { >> + dump_emf_bits(hMetafile, "emf_BitBlt"); >> + dump_emf_records(hMetafile, "emf_BitBlt"); >> + } > > You forgot to remove if (1). > It goes away in patch #3. I thought I already had this discussion with Paul. There's a reason it's there. EMF_BITBLT contains two BitBlt() records, but the EMF we're comparing it to only has one. That's because one of them is if(0)'d out because it crashes on Wine. So, if we try to compare the EMF we produced to the EMF we expect, it will fail. Last I checked, Alexandre doesn't like it when tests fail. All tests must pass on his box. Chip

Nov. 21, 2009

Re: [PATCH 1/3] gdi32/tests: Test BitBlt() to an enhanced metafile.

by Dmitry Timoshkov

"Charles Davis" <cdavis(a)mymail.mines.edu> wrote: > + if(1 || compare_emf_bits(hMetafile, EMF_BITBLT, sizeof(EMF_BITBLT), > + "emf_BitBlt", FALSE) != 0) > + { > + dump_emf_bits(hMetafile, "emf_BitBlt"); > + dump_emf_records(hMetafile, "emf_BitBlt"); > + } You forgot to remove if (1). -- Dmitry.

Nov. 21, 2009

Re: Difficulties with Regression Testing

by James McKenzie

Austin English wrote: > On Thu, Nov 19, 2009 at 9:41 AM, James Mckenzie > <jjmckenzie51(a)earthlink.net> wrote: > >>> From: Austin English <austinenglish(a)gmail.com> >>> Sent: Nov 19, 2009 10:31 AM >>> To: James Mckenzie <jjmckenzie51(a)earthlink.net> >>> Cc: Wine Development Mailing List <wine-devel(a)winehq.org> >>> Subject: Re: Difficulties with Regression Testing >>> >>> > >>>> 2. Something else is causing the check.bmp file not to be found and thus the tests fail on the fourth git bisect >>>> good. The .rc file that calls this file is located in two different directorys but the check.bmp file only exists in >>>> the tools/subdirectory. >>>> >>> IIRC, that was a file for the cryptui manager that AJ forgot to >>> include with the commit needing it. Try either putting it there >>> manually from another git branch, or using make -k. >>> >>> >> Where does this need to be added? I might be able to figure it out, but I don't want to go guessing. >> > > Put it in dlls/cryptui/, or just use make -k to ignore it. > > Thanks. The bug was not in that bisect. However, it did appear later in the sequence. Only two revisions left to test now. James McKenzie

Nov. 20, 2009

Re: UMR in CertIsRDNAttrsInCertificateName()

by Juan Lang

> http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/vg-crypt32_cert.txt > shows a new UMR (purify-speak for uninitialized memory read) error Patch sent: http://www.winehq.org/pipermail/wine-patches/2009-November/081698.html --Juan

Nov. 20, 2009

Re: shell32/tests: Remove atime tests in ITEMIDLIST_format test.

by Austin Lund

2009/11/21 Austin Lund <austin.lund(a)gmail.com>: > 2009/11/21 Paul Vriens <paul.vriens.wine(a)gmail.com>: > >> if (abs(date2 - date1) == 1) >> skip("We dont't check access times on a FAT filesystem\n"); > > >> "The date is always within 1 day (plus or minus)." > > It isn't quite that easy as the date field is a bitpacked struct > holding the year, month and day. So you have to account for month and > year boundaries. In the absence of any other ideas or tips to where I > can find a function to do this for me, I implement the calendaring > increments and send a patch which follows the above idea. > Here is an attempt at doing this. Is there a better/cleaner way to do this?

Nov. 20, 2009

Re: [PATCH 2/2] mshtml: Also search by node name attribute in IHTMLDocument3::getElementById

by Andrew Eikum

Jacek Caban wrote: > Hi Andrew, > > Andrew Eikum wrote: >> --- >> dlls/mshtml/htmldoc3.c | 58 >> +++++++++++++++++++++++++++++++++++++++++++--- >> dlls/mshtml/nsiface.idl | 33 ++++++++++++++++++++++++++ >> dlls/mshtml/tests/dom.c | 29 ++++++++++++++++++++++- >> 3 files changed, 115 insertions(+), 5 deletions(-) > > [ > object, > + uuid(29fb2a18-1dd2-11b2-8dd9-a6fd5d5ad12f), > + local > + /* FROZEN */ > +] > > This interface is not frozen, please change the comment to NOT_FROZEN so > that I we will know that we have to check it for changes on the next > Gecko update. > I meant to check this before I sent it off :) Thanks for the fixes. Andrew

Nov. 20, 2009

Re: [PATCH 2/2] mshtml: Also search by node name attribute in IHTMLDocument3::getElementById

by Jacek Caban

Hi Andrew, Andrew Eikum wrote: > --- > dlls/mshtml/htmldoc3.c | 58 > +++++++++++++++++++++++++++++++++++++++++++--- > dlls/mshtml/nsiface.idl | 33 ++++++++++++++++++++++++++ > dlls/mshtml/tests/dom.c | 29 ++++++++++++++++++++++- > 3 files changed, 115 insertions(+), 5 deletions(-) [ object, + uuid(29fb2a18-1dd2-11b2-8dd9-a6fd5d5ad12f), + local + /* FROZEN */ +] This interface is not frozen, please change the comment to NOT_FROZEN so that I we will know that we have to check it for changes on the next Gecko update. + hres = IHTMLElement_get_tagName(elem2, &str); + ok(hres == S_OK, "IHTMLElement_get_tagName failed: 0x%08x\n", hres); + ok(!strcmp_wa(str, "A"), "Got wrong tag: %s\n", wine_dbgstr_w(str)); + SysFreeString(str); There is generic test_elem_tag that is meant for this. + /* getElementById with node name attributes */ + hres = IHTMLDocument2_QueryInterface(doc, &IID_IHTMLDocument3, (void**)&doc3); + ok(hres == S_OK, "Unable to get IHTMLDocument3: 0x%08x\n", hres); + if(FAILED(hres)) + return; + bstr = a2bstr("nm1"); + hres = IHTMLDocument3_getElementById(doc3, bstr, &elem); + SysFreeString(bstr); + IHTMLDocument3_Release(doc3); + ok(hres == S_OK, "getElementById failed: 0x%08x\n", hres); + if(FAILED(hres)) + return; Same here for get_doc_elem_by_id. + + hres = IHTMLElement_get_id(elem, &bstr); + ok(hres == S_OK, "IHTMLElement_get_id failed: 0x%08x\n", hres); + ok(!strcmp_wa(bstr, "fr1"), "Found ID should have been \"fr1\", was: %s", wine_dbgstr_w(bstr)); + SysFreeString(bstr); Same here for test_elem_id. Thanks, Jacek

Nov. 20, 2009

Re: shell32/tests: Remove atime tests in ITEMIDLIST_format test.

by Austin Lund

2009/11/21 Paul Vriens <paul.vriens.wine(a)gmail.com>: > if (abs(date2 - date1) == 1) > skip("We dont't check access times on a FAT filesystem\n"); > "The date is always within 1 day (plus or minus)." It isn't quite that easy as the date field is a bitpacked struct holding the year, month and day. So you have to account for month and year boundaries. In the absence of any other ideas or tips to where I can find a function to do this for me, I implement the calendaring increments and send a patch which follows the above idea.

Nov. 20, 2009

winetest + pbuffer + nvidia 190.18 drivers = X crash

by Austin English

Been happening for a few days...not sure what triggered it, but when coming back from work I see my login screen, which explains the lack of 64-bit tests/appinstall results. I don't know if any of the D3D guys could take a look, but I'd appreciate it... -- -Austin

Nov. 20, 2009

Re: Running server applications under Wine?

by Sir Gallantmon

On Fri, Nov 20, 2009 at 12:11 PM, Dan Kegel <dank(a)kegel.com> wrote: > On Fri, Nov 20, 2009 at 9:57 AM, Sir Gallantmon <ngompa13(a)gmail.com> > wrote: > > On Fri, Nov 20, 2009 at 11:07 AM, Dan Kegel <dank(a)kegel.com> wrote: > >> > What do you think about implementing wineserver kernel module or > >> > handling only performance critical items in kernel? > >> > >> There has long been talk of doing that. Linus is > >> even willing to take patches to implement win32 APIs > >> in the linux kernel. > >> But it turns out to not be what most people need. > > > > What do you mean by that? Wouldn't it be a good idea to be able to > support > > some parts of Wine in the kernel level to be more efficient? > > Of course. It's just hard, and it isn't needed for the things > we tend to use Wine for at the moment. Somebody actually > had a shot at implementing this back in 2000, see > http://lwn.net/2000/0914/a/lt-wine.php3 > And that work lives on, it seems, as a part of > http://en.wikipedia.org/wiki/Linux_Unified_Kernel > So go try it out if you like (although I'm not sure > how safe it is for production). > > I think the Wine team doesn't need to worry about > that stuff; we have our hands full just making the > win32 userland work well. > - Dan > I would think that maybe the work Wine does for Direct3D could be moved into a state tracker for Gallium, that way it shouldn't be necessary to convert from Direct3D to OpenGL to make it work. I doubt Direct3D and OpenGL include equivalents for everything, so it might be a good idea to have for a SoC project to hook up Wine's D3D implementation into Gallium.

Nov. 20, 2009

Re: Running server applications under Wine?

by Dan Kegel

On Fri, Nov 20, 2009 at 9:57 AM, Sir Gallantmon <ngompa13(a)gmail.com> wrote: > On Fri, Nov 20, 2009 at 11:07 AM, Dan Kegel <dank(a)kegel.com> wrote: >> > What do you think about implementing wineserver kernel module or >> > handling only performance critical items in kernel? >> >> There has long been talk of doing that. Linus is >> even willing to take patches to implement win32 APIs >> in the linux kernel. >> But it turns out to not be what most people need. > > What do you mean by that? Wouldn't it be a good idea to be able to support > some parts of Wine in the kernel level to be more efficient? Of course. It's just hard, and it isn't needed for the things we tend to use Wine for at the moment. Somebody actually had a shot at implementing this back in 2000, see http://lwn.net/2000/0914/a/lt-wine.php3 And that work lives on, it seems, as a part of http://en.wikipedia.org/wiki/Linux_Unified_Kernel So go try it out if you like (although I'm not sure how safe it is for production). I think the Wine team doesn't need to worry about that stuff; we have our hands full just making the win32 userland work well. - Dan

Nov. 20, 2009

Re: Running server applications under Wine?

by Sir Gallantmon

On Fri, Nov 20, 2009 at 11:07 AM, Dan Kegel <dank(a)kegel.com> wrote: > 임은지 wrote: > > > What do you think about implementing wineserver kernel module or handling > only performance critical items in kernel? > > There has long been talk of doing that. Linus is > even willing to take patches to implement win32 APIs > in the linux kernel. > But it turns out to not be what most people need. > > If you want to do some server performance stress testing > and file bugs for problems you find, by all means, go ahead! > - Dan > > > What do you mean by that? Wouldn't it be a good idea to be able to support some parts of Wine in the kernel level to be more efficient?

Nov. 20, 2009

re: Running server applications under Wine?

by Dan Kegel

임은지 wrote: > Is there anyone who uses Wine for server applications (game server, web server, etc.)? It's been done. See e.g. http://www.fpsadmin.com/forum/showthread.php?t=16481 for how one fellow ran a game server in wine. > Performance is very important issue for such applications. A server should serve a large number of clients at reasonable speeds. Yes, it would be interesting to run ab or dkftpbench against an http or ftp server running on wine. > What do you think about implementing wineserver kernel module or handling only performance critical items in kernel? There has long been talk of doing that. Linus is even willing to take patches to implement win32 APIs in the linux kernel. But it turns out to not be what most people need. If you want to do some server performance stress testing and file bugs for problems you find, by all means, go ahead! - Dan

Nov. 20, 2009

Re: New valgrind results, this time with overrun checks and lots of new errors.

by Nikolay Sivov

Dan Kegel wrote: > http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/diff-comctl32_tab.txt > http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/vg-comctl32_tab.txt > show a more inscrutable error: > Invalid write of size 4 > at TAB_SetCurSel (tab.c:255) > by TAB_WindowProc (tab.c:3367) > by ??? (library.h:159) > by call_window_proc (winproc.c:469) > by WINPROC_CallProcAtoW (winproc.c:1023) > by CallWindowProcA (winproc.c:2299) > by tabSubclassProcess (tab.c:404) > by ??? (library.h:159) > by call_window_proc (winproc.c:469) > by WINPROC_call_window (winproc.c:2223) > by call_window_proc (message.c:1635) > by send_message (message.c:2482) > by SendMessageA (message.c:2627) > by test_getters_setters (tab.c:752) > by func_tab (tab.c:1174) > by run_test (test.h:535) > by main (test.h:585) > Address 0x7f044098 is not stack'd, malloc'd or (recently) free'd This shouldn't be a case for today git - see commit 3371ba9f73367572693589905ed57af87b747b54. And thanks a lot for these test results, I'm waiting for automated daily runs a lot...

Nov. 20, 2009

Re: New version of my test for bug 4543

by Paul Vriens

On 11/20/2009 04:25 PM, Charles Davis wrote: > Paul Vriens wrote: >> On 11/19/2009 11:17 PM, Charles Davis wrote: >>> Hi, >>> >>> This is a new version of my test for bug 4543. This time, I followed >>> Dmitry's suggestion of using the existing functions for comparing the >>> contents of EMFs. I can't build tests for Windows both due to bug 20763 >>> and due to the fact that I don't have any Windows boxes, so once again I >>> need people to run this test on Windows to make sure it's an accurate >>> representation of Windows' behavior. The test currently succeeds on Wine. >>> >>> Thanks in advance. >>> >>> Chip >>> >> >> Hi, >> >> I only ran your new tests and removed that "if(0)", please find the >> results attached. >> >> Win95/98/me have the same results (as expected) and have several >> failures (as expected). Fixing them would be a bonus but we currently >> are having several metafile failures for these platforms anyway. >> > Thanks, Paul! > > Based on these results, I modified my test (and Wine to pass), using the > WinXP results as the expected bits. I've submitted the patches to > wine-patches, so now we'll see what Alexandre thinks. > > The Win9x failures mystify me. Why would CreateEnhMetaFileA() fail? I > need to look into this. The last error is set to ERROR_FILE_NOT_FOUND. > > Chip > -- Cheers, Paul.

Nov. 20, 2009

Re: Add .cvsignore entries for .fake files

by Charles Davis

Paul Chitescu wrote: > On Monday 16 November 2009 04:11:25 pm Paul Chitescu wrote: >> Changelog: >> Add .cvsignore entries for .fake files. > > What's wrong with this? Applies cleanly to my pristine wine-CVS, tried with > patch taken from wine-patches bounce. > > Whoever rejected with "fails to apply" please reply with the output. > > > We don't use CVS anymore. Now we use git. You need to first upgrade to git, then modify the .gitignore file. Chip

Nov. 20, 2009

Re: [PATCH 1/3] gdi32/tests: Test BitBlt() to an enhanced metafile.

by Paul Vriens

On 11/20/2009 04:40 PM, Paul Vriens wrote: > On 11/20/2009 04:21 PM, Charles Davis wrote: >> + if(1 || compare_emf_bits(hMetafile, EMF_BITBLT, sizeof(EMF_BITBLT), >> + "emf_BitBlt", FALSE) != 0) > > Shouldn't you get rid of that '1 ||' ? > Just saw you did that in the last one. -- Cheers, Paul.

Nov. 20, 2009

Re: [PATCH 1/3] gdi32/tests: Test BitBlt() to an enhanced metafile.

by Paul Vriens

On 11/20/2009 04:21 PM, Charles Davis wrote: > + if(1 || compare_emf_bits(hMetafile, EMF_BITBLT, sizeof(EMF_BITBLT), > + "emf_BitBlt", FALSE) != 0) Shouldn't you get rid of that '1 ||' ? -- Cheers, Paul.

Nov. 20, 2009

Re: Add .cvsignore entries for .fake files

by Paul Chitescu

On Monday 16 November 2009 04:11:25 pm Paul Chitescu wrote: > Changelog: > Add .cvsignore entries for .fake files. What's wrong with this? Applies cleanly to my pristine wine-CVS, tried with patch taken from wine-patches bounce. Whoever rejected with "fails to apply" please reply with the output.

Nov. 20, 2009

Re: New version of my test for bug 4543

by Charles Davis

Paul Vriens wrote: > On 11/19/2009 11:17 PM, Charles Davis wrote: >> Hi, >> >> This is a new version of my test for bug 4543. This time, I followed >> Dmitry's suggestion of using the existing functions for comparing the >> contents of EMFs. I can't build tests for Windows both due to bug 20763 >> and due to the fact that I don't have any Windows boxes, so once again I >> need people to run this test on Windows to make sure it's an accurate >> representation of Windows' behavior. The test currently succeeds on Wine. >> >> Thanks in advance. >> >> Chip >> > > Hi, > > I only ran your new tests and removed that "if(0)", please find the > results attached. > > Win95/98/me have the same results (as expected) and have several > failures (as expected). Fixing them would be a bonus but we currently > are having several metafile failures for these platforms anyway. > Thanks, Paul! Based on these results, I modified my test (and Wine to pass), using the WinXP results as the expected bits. I've submitted the patches to wine-patches, so now we'll see what Alexandre thinks. The Win9x failures mystify me. Why would CreateEnhMetaFileA() fail? I need to look into this. Chip

Nov. 20, 2009

Re: shell32/tests: Remove atime tests in ITEMIDLIST_format test.

by Paul Vriens

On 11/19/2009 10:45 PM, Austin Lund wrote: > 2009/11/19 Paul Vriens<paul.vriens.wine(a)gmail.com>: >> On 11/19/2009 01:23 PM, Austin Lund wrote: >>> >>> - ok (pFileStructA->uFileDate == pFileStructW->uDate2&& >>> - pFileStructA->uFileTime == pFileStructW->uTime2, >>> - "Last write time should match last access time!\n"); >>> - >> >> Hi Austin, >> >> Is there no other way to get around this? I think it's a bit of a shame >> having tests removed for that odd system that has a FAT filesystem on a NT4+ >> box. >> > > The date is always within 1 day (plus or minus). I guess it would be > possible to implement a calendar addition and subtraction algorithm. > Is there one already available somewhere that could be used with this > bit packed structure in a test? > > The time could be anything, except perhaps the seconds. On my trials > with this, it always seems to have the seconds as zero. I'm not sure > if you can set a timezone that has a delta with non-zero seconds. > > On thinking about this, the way I'd do this is: > > if dates and times are equal then pass > else check the rough rules as outlined > > But is it ok (or even sensible to do): > > if (date1 == date2&& time1 == time2) ok(TRUE, "Blah"); > else { /* some other test */ } > > or would you leave out the ok()? Would this serve it's purpose? if (abs(date2 - date1) == 1) skip("We dont't check access times on a FAT filesystem\n"); else ok(..., "Last write time should match last access time!\n") The if() is according to your statement: "The date is always within 1 day (plus or minus)." -- Cheers, Paul.

Nov. 20, 2009

what should happen when selecting no audio in winecfg?

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

Hi, I've observed 2 seemingly opposed behaviours when no audio driver is selected in winecfg's audio tab (or when winecfg's audio tab had never been opened before in this .wine prefix): - On one hand, some tests and apps still manage to produce sound. - On the other hand (OTOH), some apps cease to produce sound -- this is a simple method worth trying when some apps hang with sound issues. So I'm left wondering what a) wine's default .wine creation behaviour or b) unselecting all audio drivers in the tab ought to do. Remember that when you first visit winecfg's audio tab, you get to see a note that a default driver was chosen, which lead me to believe that no driver at all is enabled until then. Thanks, Jörg Höhle.

Nov. 20, 2009

Running server applications under Wine?

by 임은지

Is there anyone who uses Wine for server applications (game server, web server, etc.)? Performance is very important issue for such applications. A server should serve a large number of clients at reasonable speeds. What do you think about implementing wineserver kernel module or handling only performance critical items in kernel?

Nov. 20, 2009

Re: New version of my test for bug 4543

by Paul Vriens

On 11/19/2009 11:17 PM, Charles Davis wrote: > Hi, > > This is a new version of my test for bug 4543. This time, I followed > Dmitry's suggestion of using the existing functions for comparing the > contents of EMFs. I can't build tests for Windows both due to bug 20763 > and due to the fact that I don't have any Windows boxes, so once again I > need people to run this test on Windows to make sure it's an accurate > representation of Windows' behavior. The test currently succeeds on Wine. > > Thanks in advance. > > Chip > Hi, I only ran your new tests and removed that "if(0)", please find the results attached. Win95/98/me have the same results (as expected) and have several failures (as expected). Fixing them would be a bonus but we currently are having several metafile failures for these platforms anyway. -- Cheers, Paul.

Nov. 20, 2009

Re: d3dx9_36: add a stub for D3DXCreateTextureFromFileInMemory

by Austin English

On Fri, Nov 20, 2009 at 1:38 AM, Jeff Zaroyko <jeffzaroyko(a)gmail.com> wrote: > On Fri, Nov 20, 2009 at 6:18 PM, Austin English <austinenglish(a)gmail.com> wrote: >> On Fri, Nov 20, 2009 at 12:05 AM, Jeff Zaroyko <jeffzaroyko(a)gmail.com> wrote: >>> On Fri, Nov 20, 2009 at 4:56 AM, Austin English <austinenglish(a)gmail.com> wrote: >>>> Should fix http://bugs.winehq.org/show_bug.cgi?id=13605 >>>> >>>> -- >>>> -Austin >>>> >>> >>> Does it really fix it, the function still remains unimplemented, crash >>> or no crash... a bug will probably just be filed after it to say the >>> function needs to be implemented if the app really uses it, so what is >>> gained? >> >> Same as with other stubs, it prevents a crash. Many applications check >> to see if a function works, and if not, crash. When given a stub, they >> run. >> >> -- >> -Austin >> > > Given the nature of the function and the game, I'd say it's unlikely > to be of much benefit, has it been tested? No. There is no download available. It was in my 'likely abandoned' bugs list. To be fair, many programs test functions for existence and don't depend on them...there are a ton of stubs in wine for that exact reason. -- -Austin

Nov. 20, 2009

Re: d3dx9_36: add a stub for D3DXCreateTextureFromFileInMemory

by Jeff Zaroyko

On Fri, Nov 20, 2009 at 6:18 PM, Austin English <austinenglish(a)gmail.com> wrote: > On Fri, Nov 20, 2009 at 12:05 AM, Jeff Zaroyko <jeffzaroyko(a)gmail.com> wrote: >> On Fri, Nov 20, 2009 at 4:56 AM, Austin English <austinenglish(a)gmail.com> wrote: >>> Should fix http://bugs.winehq.org/show_bug.cgi?id=13605 >>> >>> -- >>> -Austin >>> >> >> Does it really fix it, the function still remains unimplemented, crash >> or no crash... a bug will probably just be filed after it to say the >> function needs to be implemented if the app really uses it, so what is >> gained? > > Same as with other stubs, it prevents a crash. Many applications check > to see if a function works, and if not, crash. When given a stub, they > run. > > -- > -Austin > Given the nature of the function and the game, I'd say it's unlikely to be of much benefit, has it been tested?

Nov. 20, 2009

Re: d3dx9_36: add a stub for D3DXCreateTextureFromFileInMemory

by Austin English

On Fri, Nov 20, 2009 at 12:05 AM, Jeff Zaroyko <jeffzaroyko(a)gmail.com> wrote: > On Fri, Nov 20, 2009 at 4:56 AM, Austin English <austinenglish(a)gmail.com> wrote: >> Should fix http://bugs.winehq.org/show_bug.cgi?id=13605 >> >> -- >> -Austin >> > > Does it really fix it, the function still remains unimplemented, crash > or no crash... a bug will probably just be filed after it to say the > function needs to be implemented if the app really uses it, so what is > gained? Same as with other stubs, it prevents a crash. Many applications check to see if a function works, and if not, crash. When given a stub, they run. -- -Austin

Nov. 20, 2009

Re: New valgrind results, this time with overrun checks and lots of new errors.

by Austin English

On Thu, Nov 19, 2009 at 11:16 PM, Dan Kegel <dank(a)kegel.com> wrote: > On Thu, Nov 19, 2009 at 8:38 PM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: >>> I'm not sure about the user (i.e. developer) interface for turning the >>> heap >>> check on. Should it be automatic when one does warn+heap? >> >> If I got it right it makes sense to enable this only running under valgrind >> control? > > Nope. It's useful all on its lonesome. FWIW, I run with warn+heap daily when running winetest.exe for http://test.winehq.org (without valgrind), so if you want me to run with an extra environment variable to get more warnings/failures for people to fix, let me know :-). -- -Austin

Nov. 20, 2009

Re: d3dx9_36: add a stub for D3DXCreateTextureFromFileInMemory

by Jeff Zaroyko

On Fri, Nov 20, 2009 at 4:56 AM, Austin English <austinenglish(a)gmail.com> wrote: > Should fix http://bugs.winehq.org/show_bug.cgi?id=13605 > > -- > -Austin > Does it really fix it, the function still remains unimplemented, crash or no crash... a bug will probably just be filed after it to say the function needs to be implemented if the app really uses it, so what is gained?

Nov. 20, 2009

Re: New valgrind results, this time with overrun checks and lots of new errors.

by Dan Kegel

On Thu, Nov 19, 2009 at 8:38 PM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: >> I'm not sure about the user (i.e. developer) interface for turning the >> heap >> check on. Should it be automatic when one does warn+heap? > > If I got it right it makes sense to enable this only running under valgrind > control? Nope. It's useful all on its lonesome. > daily script could simply run twice or so with > different zone length, results could > be a diff to default run (16 bytes) results. I think one would want to use the biggest redzone one could without hurting performance... the bigger the redzone, the more bugs one finds. The right value will depend on the app. 16 is probably a good default, but conformance tests are tiny, they can probably tolerate huge ones. - Dan

Nov. 19, 2009

Re: New valgrind results, this time with overrun checks and lots of new errors.

by Nikolay Sivov

Dan Kegel wrote: > On Thu, Nov 19, 2009 at 7:37 AM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: > >>> http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/ >>> is the first full run with the heap tail check enabled. >>> >> So you use some private patches for that, why aren't they merged? >> > > 'Cause I just wrote it an hour before that message? > I already posted it to wine-devel for the curious. > Actually I didn't spot that, sorry, I just was interested :). > I'll try to post to wine-patches today or so. > > In the meantime I've updated > http://wiki.winehq.org/Valgrind > to link to the patch. > > I'm not sure about the user (i.e. developer) interface for turning the heap > check on. Should it be automatic when one does warn+heap? > Or should it need an environment variable or registry setting to > turn it on? How should the user control the size of the redzone > (a feature Microsoft doesn't seem to offer)? > If I got it right it makes sense to enable this only running under valgrind control? > For what it's worth, Windows seems to turn the debug heap on > by default when running apps under a debugger, and lets you disable it > by setting the environment variable _NO_DEBUG_HEAP=1. > That makes me think we should turn this feature on automatically > under warn+heap. > For finer control, setting _NO_DEBUG_HEAP=1 would disable it, > and setting WINE_HEAP_REDZONE would let you pick how big a redzone > to use. (Usually 16 bytes is enough, but I've seen bugs that misses > but 64 bytes catches.) > That's enough maybe, daily script could simply run twice or so with different zone length, results could be a diff to default run (16 bytes) results. > - Dan > >

Nov. 19, 2009