Re: [MinGW-dvlpr] w32api patches

[Keith M. <kei...@us...>]

On Tuesday 17 November 2009 03:22:04 Greg Chicares wrote:
> On 2009-11-16 14:55Z, Chris Sutcliffe wrote:
> > I'm in the process of catching up on w32api patches / bug
> > reports / etc. so that I can hopefully roll a new release
> > shortly.  As such there are a couple of reports (such as this
> > one:
> > https://sourceforge.net/tracker/?func=detail&atid=302435&aid=287
> >7129&group_id=2435) and one regarding the correcting the
> > definition of some constants (which can be found quite easily
> > doing a Google search), which cannot be found on MSDN (at least
> > with the searching I've done).
>
> That tracker item includes a C program that ascertains the GUIDs
> corresponding to 'IActiveDesktop'. It uses a "clean room design".

Sorry, but I don't believe that it does.  The originator of that item 
openly admits that he used VS as a "spyglass" to scrutinise its own 
headers.  I'm still not convinced that such practice is strictly 
legitimate as a clean room technique, but even if it is, what the 
originator of the ticket then did is a clear violation of the clean 
room ethic -- he generated the *patch* himself, in spite of having 
disqualified himself by his participation in the questionable use of 
VS headers to obtain the information.

For this poster's contribution to be acceptable, in terms of the 
clean room ethic, he must *document* his findings -- not in the form 
of code, nor on our tracker, but publicly elsewhere.  Then, *we* may 
use his documentation as a resource for improving MinGW, *without* 
his direct participation.

IMO, we must reject this patch, and delete the patch file itself from 
the ticket, for to scrutinise it would taint any other developer who 
might consider pursuing this on our behalf; (hence, I disqualify 
myself from further contribution in respect of this issue).

> I'm not sure we ever got comfortable with that technique--see,
> e.g.:
http://article.gmane.org/gmane.comp.gnu.mingw.devel/2619/match=clean+room
>
> > As was raised in the patch tracker, these definitions /
> > interface implementations, can be found in many different
> > "Windows API" implementations, so my question is, do we consider
> > doing a Google search "publicly available information" or are we
> > going to stick with MSDN being the only appropriate source of
> > information?
>
> I googled for
>   IID_IActiveDesktop +0xF490EB00L
> and the first result begins:
>   // Copyright (c) Microsoft Corporation 1995-1997
> so putting it on the web was apparently a copyright violation,
> which would prevent us from using it.

I searched just for "IID_IActiveDesktop", and nothing else; the first 
hit was an MSDN reference page for VS.85, which didn't provide the 
necessary value; the second was:
http://www.asmcommunity.net/board/index.php?topic=24826.0

This does give the required value, and it isn't in the code format we 
require, (although it is still an alternative form of code rather 
than documentation).  Does that alternative form of expression 
satisfy our criteria for a clean-room derived resource?  I'm not 
sure.

> OTOH, when a 'bing' query

I tried this...

> http://social.msdn.microsoft.com/Search/en-US?query=F490EB00&ac=8
> finds the information in moderated msdn fora at microsoft.com:

For me, it turned up this...

> http://social.msdn.microsoft.com/Forums/en-US/csharpgeneral/thread
>/450d7a4f-0a1a-43bc-acad-7030b6f34267

...but not this...

> http://social.msdn.microsoft.com/Forums/en-US/csharpgeneral/thread
>/00349e46-b8da-4f23-b3f2-1a81c8a2933f

> (search for 'F490EB00' in those pages), then I suppose we'd be on 
> firmer ground. 

Perhaps, but the problem I see with this is that you already have to 
know at least a part of the GUID in question, to perform the initial 
search -- how do we determine that, in a legitimate manner?  Also, 
in the one hit I did get, I see no definitive confirmation that the 
GUID value apparent is, in fact, the particular one of interest, 
(although perhaps a C# coder could deduce it; I don't know).

Furthermore, going back to the original tracker item, the follow up 
suggests that IID_IActiveDesktop is the only questionable value, yet 
in the patch itself I see many other #defines, for which I can find 
no documentary support on MSDN, or indeed even easily elsewhere.

-- 

Regards,
Keith.