January 2011 - Wine-Devel - list.winehq.org

Re: [PATCH 2/4] wined3d: Add support for the NULL format.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 24.01.2011 um 18:41 schrieb Henri Verbeet: > - if (surface) > + if (surface && surface->resource.format->id != WINED3DFMT_NULL) Doesn't this cause GL errors? In my testing I had to set the draw buffer to GL_NONE to be able to draw without a color attachment. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJNPqNaAAoJEN0/YqbEcdMwWFwP/0KW7THyiplBKi6csC7b6qWi i7Bi3VG5UMRomIDUyWMTlH+mwLqP7+AchzVYEHAM/blhe5yqemDc2YAN2f2/aNtV cbWoaIilTNF3PKH11wVvtUowidrwHmr9eV+SmHplvhdpJCTGKqU0ZxmNgl2DDiSD iPVfCmL6RE1e5n9i11AH7aQIcZjwPTEQBQlLR5IB1zpcnXab0r7vyTU44f0HkcJ0 785ast6QuG7lawibe7PmRz41VcFCtSMZF3QGgEujAn+frtYhqjVLdP8LITWZ+1mL jPfCWEQX1vlgbdMogykfnKSfm5oxaDMsrU3vMskwUGWFZCX+M7ffHIfy7cpy8HUt YVz4kqeaLr1xeZEsEaAQqjNal1PXoJCJSVA6ckV7VhB0+OkXpcH4i8ifdCtRv1PJ 0V/vryBBQgM9AczBQI8lb1c7w7lQL9EzttpNwbbC3mBTsT3/7EHJRuxR8EStIgzC 8gyTXveyBGuJel8Bwx6M+tBSskCNKFzPN7MKkvIE2+X5NSYj5eI05GSQRMl/eush jZWe+ls9GYgl76bL8+By1RRTsXGizPdW8UnX6HhzMfBErU1Z7IZbbqEiTMgXFOJL 0v0UXfLecE/mHlgrauk7b0C51JMtTXq5uuSOQ8uxFz/t2KcElja6pY4/nkN3DoLe I/cZaSyeQ3B5lTVTeZt/ =UA0G -----END PGP SIGNATURE-----

Jan. 25, 2011

wine-patches

by Vincent Hardy

Hi, I sent this email on wine-patch but... nothing. Am I doing something wrong ? Am I blacklisted ? Vincent

Jan. 25, 2011

Re: ntdll/cdrom : implement CDROM_Verify to work on Mac OS X, with comment (try 3)

by Henri Verbeet

On 25 January 2011 01:06, Charles Davis <cdavis(a)mymail.mines.edu> wrote: > Uh, you mean git send-email, right? Right.

Jan. 25, 2011

Re: ntdll/cdrom : implement CDROM_Verify to work on Mac OS X, with comment (try 3)

by Charles Davis

On 1/24/11 4:51 PM, Henri Verbeet wrote: > On 25 January 2011 00:29, Ken Thomases <ken(a)codeweavers.com> wrote: >> Your mailer seems to have mangled your patch with line wrapping. There are some suggestions on Wine's SubmittingPatches wiki page for avoiding this. Primarily, you should attach the patch to your email. If you already did that, then you may need to use a different mailer. For example, Mail.app used to mess up even attached patches, although it doesn't for me anymore. (I don't know if that's because Mail.app changed or if git-format-patch changes.) When it used to be a problem, I had to use Thunderbird to send my Wine patches. >> > Just use git format-patch for sending patches, if possible. Uh, you mean git send-email, right? All git format-patch does is, well, format patches so they can be sent by a mail client. Chip

Jan. 25, 2011

Re: ntdll/cdrom : implement CDROM_Verify to work on Mac OS X, with comment (try 3)

by Henri Verbeet

On 25 January 2011 00:29, Ken Thomases <ken(a)codeweavers.com> wrote: > Your mailer seems to have mangled your patch with line wrapping. There are some suggestions on Wine's SubmittingPatches wiki page for avoiding this. Primarily, you should attach the patch to your email. If you already did that, then you may need to use a different mailer. For example, Mail.app used to mess up even attached patches, although it doesn't for me anymore. (I don't know if that's because Mail.app changed or if git-format-patch changes.) When it used to be a problem, I had to use Thunderbird to send my Wine patches. > Just use git format-patch for sending patches, if possible. Mail clients are just terrible, and using git format-patch avoids a lot of the common issues. If you send more than one or two patches it's usually faster too.

Jan. 24, 2011

Re: ntdll/cdrom : implement CDROM_Verify to work on Mac OS X, with comment (try 3)

by Ken Thomases

Loïc, Your mailer seems to have mangled your patch with line wrapping. There are some suggestions on Wine's SubmittingPatches wiki page for avoiding this. Primarily, you should attach the patch to your email. If you already did that, then you may need to use a different mailer. For example, Mail.app used to mess up even attached patches, although it doesn't for me anymore. (I don't know if that's because Mail.app changed or if git-format-patch changes.) When it used to be a problem, I had to use Thunderbird to send my Wine patches. Cheers, Ken On Jan 23, 2011, at 3:47 AM, Loïc Maury wrote: > --- > dlls/ntdll/cdrom.c | 4 ++++ > 1 files changed, 4 insertions(+), 0 deletions(-) > > diff --git a/dlls/ntdll/cdrom.c b/dlls/ntdll/cdrom.c > index 59f85a0..6a6d8e0 100644 > --- a/dlls/ntdll/cdrom.c > +++ b/dlls/ntdll/cdrom.c > @@ -1121,6 +1121,10 @@ static NTSTATUS CDROM_Verify(int dev, int fd) > return STATUS_SUCCESS; > else > return STATUS_NO_MEDIA_IN_DEVICE; > +#elif defined(__APPLE__) > + /* At this point, we know that we have media, because in Mac OS X, the > + * device file is only created when media is present. */ > + return STATUS_SUCCESS; > #else > FIXME("not supported on this O/S\n"); > return STATUS_NOT_SUPPORTED; > -- > 1.7.3.2 >

Jan. 24, 2011

Re: Static analysis scan

by Juan Lang

Hi Amine, > I've set up a static analysis scan using clang static analyzer. The results > are available at http://austinenglish.com/logs/clang_analyzer/index.html > thanks to Austin for the web space. > > Please feel free to fix the defects. I'll run future scans when the defects > get fixed progressively. That's nice, but there's no way to remove false positives, and not every "bug" listed is in fact a bug. This makes the results a bit unwieldy, IMO. --Juan

Jan. 24, 2011

Static analysis scan

by Amine Khaldi

Hello folks, I've set up a static analysis scan using clang static analyzer. The results are available at http://austinenglish.com/logs/clang_analyzer/index.html thanks to Austin for the web space. Please feel free to fix the defects. I'll run future scans when the defects get fixed progressively. Have fun ;) With best regards, Amine.

Jan. 24, 2011

Re: oleaut32/typelib2: Use implementation pointer to trace ICreateTypeInfo2

by Nikolay Sivov

On 1/24/2011 12:38, Michael Stefaniuc wrote: > Hello Nikolay, > > On 01/24/2011 01:01 AM, Nikolay Sivov wrote: >> Use implementation pointer to trace ICreateTypeInfo2 > >> diff --git a/dlls/oleaut32/typelib2.c b/dlls/oleaut32/typelib2.c >> index 8260ef2..5c843a1 100644 >> --- a/dlls/oleaut32/typelib2.c >> +++ b/dlls/oleaut32/typelib2.c > >> @@ -2322,6 +2321,7 @@ static HRESULT WINAPI >> ICreateTypeInfo2_fnAddVarDesc( >> >> /* increment the number of variable elements */ >> This->typeinfo->cElement += 0x10000; >> +ERR("count=%d\n", This->typeinfo->cElement); > this looks like some leftover debug line. Right, thanks.

Jan. 24, 2011

Re: [PATCH 2/4] shdocvw: Implement IWebBrowser_ExecWB.

by Erich Hoover

On Sun, Jan 23, 2011 at 11:32 AM, Jacek Caban <jacek(a)codeweavers.com> wrote: > On 1/20/11 6:40 PM, Erich Hoover wrote: >> On Thu, Jan 20, 2011 at 4:00 AM, Jacek Caban<jacek(a)codeweavers.com> wrote: >>> + ok(status& success_flag, "OLECMDID_STOP not enabled/supported: %08x\n", status); >>> You could test the exact value here: ok(status == ...) >> >> I was trying to avoid adding some conditional todo_wine calls > > Hiding differences between Wine and Windows in tests is the worst thing you can do. When one is trying to find a bug, tested parts of implementation are much less suspicious than not or poorly tested. If you know about more such things in the patch, please fix them. You don't write the test to pass on your implementation. You write it to know the right implementation. I would say that testing the mask is not about hiding differences, it makes it clear that this particular test is meant to demonstrate whether a specific feature is available. At some point you have to make a trade-off between making a particular test completely comprehensive or having it be clear exactly what is being tested. In this particular component there are a lot of things that are not yet implemented, so it's a little difficult to add a self-contained test for a feature without it ballooning into a bunch of unrelated issues. There are two other such "issues" I have become aware of with the current implementation that could be added as tests, but I would say that they both belong in separate patches (if you want them at all): 1) The IOleCommandTarget is cached when the WebBrowser is initialized (rather than being requested each time it is used) 2) The document is initialized much earlier on native than it is in Wine My goal here is to implement (as well as I can) a single feature that I've had sitting in my stack of unsubmitted patches, I'm not trying to implement everything in this component in one fell swoop. If that's really what it's going to take to get this feature implemented then I can take the time to implement more, but it'll take me a while and I'd really like to move this item off of my plate so I can clean up some of my other unsubmitted patches before they become too far out of sync. >> (for some reason native does not respond with "supported", even though it >> does in the mshtml tests), please see if you like the attached better. > Or it proves that it's not a simple forward to mshtml? It's possible that they masked the supported flag out, especially since all of the examples I've seen on MSDN check for the enabled flag rather than the supported flag. However, I doubt that they copy-pasted the mshtml code and then made changes to it. I'd say that even if they did it'd be better to forward to mshtml and discover if there are any differences (and where they are) as people test applications that use this functionality. > We still have them in separated functions you've called test_QueryStatusWB and test_ExecWB. We most likely will want more tests on WebBrowser instance without container's IOleCommandTarget, and it would be nice if we could reuse test_CommandTargetPassthru for that (well, the name would be better more generic as well). Sorry, for some reason I was a bit dense and didn't catch exactly what you were planning here. Please see if the attached is more to your liking, the test bot results are available here: https://testbot.winehq.org/JobDetails.pl?Key=8575 Erich Hoover ehoover(a)mines.edu

Jan. 24, 2011