June 2012 - Wine-Devel - list.winehq.org

Re: http://winetricks.googlecode.com/svn/trunk/src/install-gecko.sh also installs mono

by Matijn Woudt

On Wed, Jun 6, 2012 at 3:36 PM, Vincent Povirk <madewokherd(a)gmail.com> wrote: >> It is not so much the technical details that are the problem. >> >> It is the LEGAL problems and potential legal problems that are at the root >> of my complaint. >> >> Telling me that I have the technical details wrong does not help. I have >> very carefully tried to move the discussion away from secondary technical >> points and onto the strategic issues that are not being addressed. > > Well, it didn't seem like you were interested in diving into > specifics. I don't know the details of Microsoft's patents relating to > .NET or any promises they've made regarding those patents. Even if I > did, I'm probably not qualified to evaluate them. I simply assumed > that because so many mainstream distros and open source projects > seemed to think that use of Mono didn't pose a significant legal risk, > it wasn't a problem to include it in Wine. > > If there's some specific action we could take to reduce our legal risk > without impairing Wine's compatibility with Windows, we should > probably do that and/or ask Mono to do it. However, it seems unlikely > to me that there is something Wine could do in this area that Mono > cannot, and I am not in a position to go looking for patents that > might be relevant to our use case. > > This may be naive, but it seems obvious to me that the technical > details are what ultimately determine the legal situation, and > appearances have a much smaller effect. You also have to understand > that this is a development mailing list, and it's full of programmers, > not lawyers. So there's far more knowledge here of technical details > (personally, I consider those details my responsibility) than legal > strategy. > > The core of mono is safe. It is covered under ECMA-334 (C# language) and ECMA-335 (CLIR vm). The mono MS Compatibility Stack, which includes: - XML - ASP.NET - Windows.Forms - ADO.NET - Core cryptography - Transactions is a grey area now since the project is not part of Novell anymore. Novell and Microsoft had joint patent agreement, so there were no problems. So the question is, does wine-mono include the compatibility stack? - Matijn

June 6, 2012

Re: windowscodecs: Add a stubbed out IWICMetadataBlockReader to TIFF decoder.

by Vincent Povirk

Looks good. Here are some notes in case you get around to implementing this before I do: I found it very surprising that no metadata handlers seem to implement IWICMetadataBlockReader, while many of them advertise that they can be found in other metadata formats. I'm guessing that metadata handlers return child IWICMetadataReader objects from the IWICMetadataReader interface, but I haven't tested this. It probably doesn't make sense to reimplement GetEnumerator for each decoder, and we should be able to make a common implementation based on the other methods. We should probably implement GetReaderByIndex based on CreateMetadataReaderFromContainer, which I'm guessing expects a copy of the image stream (using IWICStream because we can't use IStream::Clone) seeked to the beginning of some metadata, or a region of the image stream, maybe depending on the container format.

June 6, 2012

Re: http://winetricks.googlecode.com/svn/trunk/src/install-gecko.sh also installs mono

by Vincent Povirk

> It is not so much the technical details that are the problem. > > It is the LEGAL problems and potential legal problems that are at the root > of my complaint. > > Telling me that I have the technical details wrong does not help. I have > very carefully tried to move the discussion away from secondary technical > points and onto the strategic issues that are not being addressed. Well, it didn't seem like you were interested in diving into specifics. I don't know the details of Microsoft's patents relating to .NET or any promises they've made regarding those patents. Even if I did, I'm probably not qualified to evaluate them. I simply assumed that because so many mainstream distros and open source projects seemed to think that use of Mono didn't pose a significant legal risk, it wasn't a problem to include it in Wine. If there's some specific action we could take to reduce our legal risk without impairing Wine's compatibility with Windows, we should probably do that and/or ask Mono to do it. However, it seems unlikely to me that there is something Wine could do in this area that Mono cannot, and I am not in a position to go looking for patents that might be relevant to our use case. This may be naive, but it seems obvious to me that the technical details are what ultimately determine the legal situation, and appearances have a much smaller effect. You also have to understand that this is a development mailing list, and it's full of programmers, not lawyers. So there's far more knowledge here of technical details (personally, I consider those details my responsibility) than legal strategy.

June 6, 2012

Re: Wine's support for reporting calling conventions

by Roger Cruz

A previous google search did show up someone modifying GCC to add that level of CC info for another architecture so I'm sure it is something that we can do for x86. I don't know how complex it would be either. I was hoping it was already done and it was just a matter of a compiler flag. I guess one more research task for me :-) Regards, Roger ________________________________ From: Eric Pouech <eric.pouech(a)orange.fr> To: Roger Cruz <roger_r_cruz(a)yahoo.com> Cc: Wine Devel <wine-devel(a)winehq.org> Sent: Wednesday, June 6, 2012 8:12 AM Subject: Re: Wine's support for reporting calling conventions dwarf4 allows each compiler vendor to add its own range of CC values in the DW_AT_calling_convention field. this means that the vendor must create its own table for mapping each used CC to a given value. from a wine standpoint, the list should be rather small (stdcall, fastcall...) (on top of cdecl of course) (assuming old 16bit code is out of the game) AFAIK, gcc only uses those extensions for very dedicated usage (pascal compiler...). I don't see any reason why one couldn't extend gcc to do it, but I cannot tell how complex it will be (and if plugins provide the relevant interface to do so). HTH A+ 2012/6/6, Roger Cruz <roger_r_cruz(a)yahoo.com>: > Hi Eric, > > Thanks for replying. I saw that in the DWARF spec and I was afraid that > DWARF may not provide detailed Info. But I also read in the spec that the > compilers use a DWARF extension feature to convey additional info such as > calling convention for each routine. Is there a way to coax GCC to output > that information? Maybe thru a target plugin? -- Eric Pouech

June 6, 2012

Re: urlmon: Use file content to verify MIME type reported by file protocol handler

by Jacek Caban

On 06/06/12 13:58, Marvin wrote: > Hi, > > While running your changed tests on Windows, I think I found new failures. > Being a bot and all I'm not very good at pattern recognition, so I might be > wrong, but could you please double-check? > Full results can be found at > http://testbot.winehq.org/JobDetails.pl?Key=18815 > > Your paranoid android. > > > === WXPPROSP3 (32 bit protocol) === > protocol.c:1046: Test failed: unexpected call ReportResult > protocol.c:1051: Test failed: hrResult = 00000000, expected: 80004004 > protocol.c:2838: Test failed: Read failed: 00000001 This is unrelated to my patch. Jacek

June 6, 2012

Re: Wine's support for reporting calling conventions

by Eric Pouech

dwarf4 allows each compiler vendor to add its own range of CC values in the DW_AT_calling_convention field. this means that the vendor must create its own table for mapping each used CC to a given value. from a wine standpoint, the list should be rather small (stdcall, fastcall...) (on top of cdecl of course) (assuming old 16bit code is out of the game) AFAIK, gcc only uses those extensions for very dedicated usage (pascal compiler...). I don't see any reason why one couldn't extend gcc to do it, but I cannot tell how complex it will be (and if plugins provide the relevant interface to do so). HTH A+ 2012/6/6, Roger Cruz <roger_r_cruz(a)yahoo.com>: > Hi Eric, > > Thanks for replying. I saw that in the DWARF spec and I was afraid that > DWARF may not provide detailed Info. But I also read in the spec that the > compilers use a DWARF extension feature to convey additional info such as > calling convention for each routine. Is there a way to coax GCC to output > that information? Maybe thru a target plugin? -- Eric Pouech

June 6, 2012

Re: urlmon: Use file content to verify MIME type reported by file protocol handler

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=18815 Your paranoid android. === WXPPROSP3 (32 bit protocol) === protocol.c:1046: Test failed: unexpected call ReportResult protocol.c:1051: Test failed: hrResult = 00000000, expected: 80004004 protocol.c:2838: Test failed: Read failed: 00000001

June 6, 2012

Re: [PATCH 2/3] server: STATUS_MORE_PROCESSING_REQUIRED does not indicate that an async operation is complete (try 4).

by Alexandre Julliard

"Erich E. Hoover" <compholio(a)gmail.com> writes: > @@ -285,7 +285,9 @@ void async_set_result( struct object *obj, unsigned int status, unsigned int tot > if (async->timeout) remove_timeout_user( async->timeout ); > async->timeout = NULL; > async->status = status; > - if (async->data.cvalue) > + if (status == STATUS_MORE_PROCESSING_REQUIRED) > + async->status = STATUS_PENDING; > + else if (async->data.cvalue) Why are you marking the async pending? That doesn't seem right, it's terminated at that point. -- Alexandre Julliard julliard(a)winehq.org

June 6, 2012

Re: [2/2] user32: Add a test to demonstrate the z-order problem for a top level window with a region. Take 2.

by Dmitry Timoshkov

Alexandre Julliard <julliard(a)winehq.org> wrote: > > This version of the test tries harder to avoid races that could cause > > the test failures. > > It's not races, it's failing consistently here, even with your latest > version. I don't think you can reliably test expose events processing > from a Windows app. It was mainly a showcase to demonsrate the problem to you, if it's not reliable enough, dropping it is ok, let's hope that the fix is ok this time. -- Dmitry.

June 6, 2012

Re: [2/2] user32: Add a test to demonstrate the z-order problem for a top level window with a region. Take 2.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > This version of the test tries harder to avoid races that could cause > the test failures. It's not races, it's failing consistently here, even with your latest version. I don't think you can reliably test expose events processing from a Windows app. -- Alexandre Julliard julliard(a)winehq.org

June 6, 2012