MinGW - Minimalist GNU for Windows

>    ./lmgr_md.lib(lm_set_attr.obj):lm_set_attr.c:(.text+0x1a4b): undefined reference to `_chkstk'

http://www.mail-archive.com/cygwin@...>
might help.
=r

On Wednesday 22 July 2009 23:24:48 Ronald Pijnacker wrote:
> While linking my application with gcc under mingw, I am getting
> unresolved symbols, that are available in the Microsoft
> counterparts. E.g.:
>
>     ./ISRInterfaceWrapper.c:1048: undefined reference to
>          `IID_IGlobalInterfaceTable'
>     ./ISRInterfaceWrapper.c:1048: undefined reference to
>          `CLSID_StdGlobalInterfaceTable' 

Maybe there's just no reliably documented source, from which we can 
obtain the appropriate values.

> Also, I had to add some macros to the w32api header files.
> What do I do to contribute these changes?

If your changes are based *exclusively* on publicly visible 
documentation, (such as documented on MSDN), then you can post 
patches on our patch-tracker; for instructions, see: 
http://mingw.org/wiki/SubmitPatches

However, please bear in mind that we never plagiarise Microsoft SDK 
headers, nor do we accept patches abstracted from the code of other 
projects who may do this.  If you have developed your additions by 
inspection of the SDK headers, then we don't want to see them.

-- 

Regards,
Keith.

> On Wednesday 22 July 2009 23:24:48 Ronald Pijnacker wrote:
> > While linking my application with gcc under mingw, I am getting
> > unresolved symbols, that are available in the Microsoft
> > counterparts. E.g.:
> >
> >     ./ISRInterfaceWrapper.c:1048: undefined reference to
> >          `IID_IGlobalInterfaceTable'
> >     ./ISRInterfaceWrapper.c:1048: undefined reference to
> >          `CLSID_StdGlobalInterfaceTable' 
> 
> Maybe there's just no reliably documented source, from which we can 
> obtain the appropriate values.
 
http://msdn.microsoft.com/en-us/library/ms680695(VS.85).aspx
http://source.winehq.org/source/dlls/uuid/uuid.c?v=wine-1.1.5#L105

> > Also, I had to add some macros to the w32api header files.
> > What do I do to contribute these changes?
> 
> If your changes are based *exclusively* on publicly visible 
> documentation, (such as documented on MSDN), then you can post 
> patches on our patch-tracker; for instructions, see: 
> http://mingw.org/wiki/SubmitPatches
> 
> However, please bear in mind that we never plagiarise Microsoft SDK 
> headers, nor do we accept patches abstracted from the code of other 
> projects who may do this.  If you have developed your additions by 
> inspection of the SDK headers, then we don't want to see them.

ok, clear enough.
I will post the msdn reference along with the patch as proof of the public
source. I suppose that is sufficient?

Ronald

On Thursday 23 July 2009 18:53:54 Ronald Pijnacker wrote:
> > >     ./ISRInterfaceWrapper.c:1048: undefined reference to
> > >          `IID_IGlobalInterfaceTable'
> > >     ./ISRInterfaceWrapper.c:1048: undefined reference to
> > >          `CLSID_StdGlobalInterfaceTable'
> >
> > Maybe there's just no reliably documented source, from which we
> > can obtain the appropriate values.
>
>  
> http://msdn.microsoft.com/en-us/library/ms680695(VS.85).aspx

Okay, thanks.  That's a good reference source for the first of the 
above, but doesn't mention the second.  At one time, those Microsoft 
references didn't include the manifest *values*.

> http://source.winehq.org/source/dlls/uuid/uuid.c?v=wine-1.1.5#L105

Sorry, but this is *not* and acceptable source.  Not only do the wine 
folks freely admit plagiarism of the Microsoft headers, they then 
reproduce the info under the GPL, which isn't compatible with our 
licence.

> ok, clear enough.
> I will post the msdn reference along with the patch as proof of
> the public source. I suppose that is sufficient?

Yes.

-- 

Regards,
Keith.

On Thu, Jul 23, 2009 at 1:16 PM, Keith
Marshall<keithmarshall@...>
>> http://source.winehq.org/source/dlls/uuid/uuid.c?v=wine-1.1.5#L105
>
> Sorry, but this is *not* and acceptable source.  Not only do the wine
> folks freely admit plagiarism of the Microsoft headers, they then
> reproduce the info under the GPL, which isn't compatible with our
> licence.
>

I guess I object to the term plagiarism.  Not any more plagiarized
than taking the information from MSDN and writing it up in your own
way (it's still the same info no?).  I know we've been through this
before and I'm not here to reopen the discussion.

Let's just summarize and say that MinGW and Wine differ in their
interpretation of fair use and how an EULA can apply to such use in
regards to code header files.

Wine's headers are LGPL(as is all of Wine), but quite right that it's
not compatible with the MinGW w32api headers public domain license
(please pardon me if I'm using the wrong term for that).

All that said I appreciate and make use of all the hard work that
MinGW represents when I work on Wine and cross compile test binaries
for windows.  So thanks! and hopefully we can coexist a little less
feist-ily in the future.

Cheers,
--John Klehm

Hi Keith,

> > > Maybe there's just no reliably documented source, from which we
> > > can obtain the appropriate values.
> > http://msdn.microsoft.com/en-us/library/ms680695(VS.85).aspx
> Okay, thanks.  That's a good reference source for the first of the 
> above, but doesn't mention the second.  At one time, those Microsoft 
> references didn't include the manifest *values*.

Not that I want to start a discussion here, but I do not really see the legal
difference between taking the information from the mentioned webpage or 
include file.

Both have the frase "(c) Microsoft Corporation. All rights reserved." on them.
Nevertheless, I will try to find references you find acceptable to get them
included.
So, what is the next step? Wait for the next w32api version to be released?

Thanks,

Ronald

Hi all,

On Thu, 23 Jul 2009, Keith Marshall wrote:

>> http://source.winehq.org/source/dlls/uuid/uuid.c?v=wine-1.1.5#L105
>
> Sorry, but this is *not* and acceptable source.  Not only do the wine 
> folks freely admit plagiarism of the Microsoft headers, they then 
> reproduce the info under the GPL, which isn't compatible with our 
> licence.

It's been mentioned before that, as far as I understand it, it's 
sufficient for anyone not connected with MinGW to publish information 
under a compatible license, for MinGW to be able to use that information 
to develop headers, even if the original source was breaching copyright 
rules. Their publishing of the information, which might have been a trade 
secret before, places the information in the public domain, and gives them 
and not us the responsibility for doing so. Is that a correct 
understanding?

If so, then perhaps rather than calling the Wine people plagiarists, we 
might persuade them to release their headers under a less restrictive 
license that would allow us to use them as a source? In that way, they 
could do an even greater service to the free software community than they 
already do.

Does that make sense?

Cheers, Chris.
-- 
_____ __     _
\  __/ / ,__(_)_  | Chris Wilson <0000 at qwirx.com> - Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Ruby/Perl/SQL Developer |
\__/_/_/_//_/___/ | We are GNU : free your mind & your software |

On Thursday 23 July 2009 19:49:17 John Klehm wrote:
> I guess I object to the term plagiarism.

Granted, it may be a bit strong.  No offense intended.  Sorry.

> Not any more plagiarized 
> than taking the information from MSDN and writing it up in your
> own way (it's still the same info no?).

Subtly different, in terms of how clean room techniques are 
legitimised, as I understand it.

> Let's just summarize and say that MinGW and Wine differ in their
> interpretation of fair use and how an EULA can apply to such use
> in regards to code header files.

Yes, that's a fair summary.

> I appreciate and make use of all the hard work that
> MinGW represents when I work on Wine and cross compile test
> binaries for windows.

As I rely on Wine, for testing my cross-compiled contributions to 
MinGW.

> So thanks! and hopefully we can coexist a 
> little less feist-ily in the future.

I'll second that.

-- 

Regards,
Keith.

On Thu, Jul 23, 2009 at 2:20 PM, Chris Wilson<chris@...> wrote:
> If so, then perhaps rather than calling the Wine people plagiarists, we
> might persuade them to release their headers under a less restrictive
> license that would allow us to use them as a source? In that way, they
> could do an even greater service to the free software community than they
> already do.
>

We've talked about this before:

http://74.125.47.132/search?q=cache:lixwFvJBWNsJ:news.gmane.org/group/gmane.comp.gnu.mingw.user/last%3D0/force_load%3Dvery/%3Fpage%3D54%26action%3D--Action--+gmane+acceptable+sources+other+than+msdn&cd=1&hl=en&ct=clnk&gl=us&client=firefox-a

I couldnt find a better link maybe someone can help me out.

--John Klehm

On Thursday 23 July 2009 20:20:45 Chris Wilson wrote:
> It's been mentioned before that, as far as I understand it, it's
> sufficient for anyone not connected with MinGW to publish
> information under a compatible license, for MinGW to be able to
> use that information to develop headers, even if the original
> source was breaching copyright rules. Their publishing of the
> information, which might have been a trade secret before, places
> the information in the public domain, and gives them and not us
> the responsibility for doing so. Is that a correct understanding?


My understanding is, that to be acceptable, the information has to 
pass through a *different* form of expression.  Thus, if the 
Microsoft headers says:

  #define FOO_MANIFEST  12345

and the Wine header also says:

  #define FOO_MANIFEST  12345

then there is no change in the form of expression, so, while we may 
not wish to accuse the Wine folks of wilful plagiarism, this *might* 
be construed as such, in a court of law.

> If so, then perhaps rather than calling the Wine people
> plagiarists,

Yes, I've already acknowledged that that may have been stronger than 
I really intended.

> we might persuade them to release their headers under 
> a less restrictive license that would allow us to use them as a
> source?

No.  It would need someone, unassociated with either project, to 
publish the data in a different format, say as a reference table, so 
as to release it into the public domain; then we can reproduce it,
transformed into the natural form required for a header definition, 
without us ever referring to the original Microsoft copyrighted (and 
possibly identical) form of expression.

-- 

Regards,
Keith

On Thursday 23 July 2009 20:40:58 Ronald Pijnacker wrote:
> Not that I want to start a discussion here, but I do not really
> see the legal difference between taking the information from the
> mentioned webpage or include file.
>
> Both have the frase "(c) Microsoft Corporation. All rights
> reserved." on them.

The copyright on MSDN applies to the *form* of expression of the 
information contained therein.  It does *not* apply to the actual 
factual data encapsulated *within* that form of expression, because 
such factual data is not copyrightable.  When we interpret the data 
from MSDN, and transform it into a #define in our header, we are not 
transcribing the form of expression appearing in Microsoft's header 
files, even if we achieve a result which looks similar, so we are 
not infringing their copyright.

Yes, I know this seems crazy, but it is, as I understand it, a 
recognised and legitimate legal loophole.

OTOH, if we do copy from their header, we *are* simply transcribing 
from a copyrighted source, and hence infringing that copyright.  If 
we transcribe from another project's header, where we suspect that 
they may have infringed in this manner, then we believe that would 
make us complicit in their infringement; hence we will not do it.

> Nevertheless, I will try to find references you find acceptable to
> get them included. 

Thanks.

> So, what is the next step?  Wait for the next w32api version to be
> released?

Submit your patches as soon as you are ready.  If we accept them, 
they will be committed  to CVS.  Thereafter, they will be available 
immediately, to anyone who wishes to download and compile a CVS 
snapshot.  For those who prefer to wait for formal releases, they 
will be available in the next release, *after* you get them accepted 
into CVS.

-- 

Regards,
Keith.

> On Thursday 23 July 2009 18:53:54 Ronald Pijnacker wrote:
> > > > ./ISRInterfaceWrapper.c:1048: undefined reference to
> > > > `IID_IGlobalInterfaceTable'
> > > > ./ISRInterfaceWrapper.c:1048: undefined reference to
> > > > `CLSID_StdGlobalInterfaceTable'
> > >
> > > Maybe there's just no reliably documented source, from which we
> > > can obtain the appropriate values.
> >
> > http://msdn.microsoft.com/en-us/library/ms680695(VS.85).aspx
> 
> Okay, thanks.  That's a good reference source for the first of the 
> above, but doesn't mention the second.  At one time, those Microsoft 
> references didn't include the manifest *values*.
> 
> > http://source.winehq.org/source/dlls/uuid/uuid.c?v=wine-1.1.5#L105
> 
> Sorry, but this is *not* and acceptable source.  Not only do the wine 
> folks freely admit plagiarism of the Microsoft headers, they then 
> reproduce the info under the GPL, which isn't compatible with our 
> licence.
> 
> > ok, clear enough.
> > I will post the msdn reference along with the patch as proof of
> > the public source. I suppose that is sufficient?

It seems as though CLSID_StdGlobalInterfaceTable is nowwhere to be
found in any publicly available Microsoft website.
However, would it be acceptable to create a simple c-program that
prints the values of CLSID_StdGlobalInterfaceTable to stdout?
In that way, no plagiarism is applied, but still the values are available
to be used.

Thanks,

Ronald

On Thursday 20 August 2009 09:53:06 Ronald Pijnacker wrote:
> It seems as though CLSID_StdGlobalInterfaceTable is nowwhere to be
> found in any publicly available Microsoft website.

Which means you have a really difficult job ahead, if you need to 
find the appropriate value, without scrutinising Microsoft's code.

> However, would it be acceptable to create a simple c-program that
> prints the values of CLSID_StdGlobalInterfaceTable to stdout?

What?  Use the compiler as a spyglass, to facilitate such scrutiny?  
(If you haven't used Microsoft's header in the compilation, how can 
your simple C program know what value to print?)  Absolutely not!

> In that way, no plagiarism is applied, but still the values are
> available to be used.

Not so.  It is plagiarism, in exactly the same way as if you had read 
the Microsoft header directly.

-- 

Regards,
Keith.

> On Thursday 20 August 2009 09:53:06 Ronald Pijnacker wrote:
> > It seems as though CLSID_StdGlobalInterfaceTable is nowwhere to be
> > found in any publicly available Microsoft website.
> 
> Which means you have a really difficult job ahead, if you need to 
> find the appropriate value, without scrutinising Microsoft's code.
> 
> > However, would it be acceptable to create a simple c-program that
> > prints the values of CLSID_StdGlobalInterfaceTable to stdout?
> 
> What?  Use the compiler as a spyglass, to facilitate such scrutiny?  
> (If you haven't used Microsoft's header in the compilation, how can 
> your simple C program know what value to print?)  Absolutely not!
 
The format of GUIDs is documented clearly on MSDN.
The c-program would make use of that format to print the values of the constant provided by Microsoft.
No actual looking in header files was done, which satisfies your 'do not copy from the header files' criterion.

> > In that way, no plagiarism is applied, but still the values are
> > available to be used.
> 
> Not so.  It is plagiarism, in exactly the same way as if you had read 
> the Microsoft header directly.

Why so? I beleive it to be very different.

Ronald

On Monday 24 August 2009 14:37:27 Ronald Pijnacker wrote:
> The format of GUIDs is documented clearly on MSDN.

The format, maybe, but not the required value, in every case.

> The c-program would make use of that format to print the values of
> the constant provided by Microsoft.

Provided by Microsoft, where?  If it's in a component provided as a 
STANDARD PART OF THE OPERATING SYSTEM, and you can read it with a 
MinGW program, WITHOUT recourse to any Microsoft restricted SDK, 
then okay; if you are extracting it from a Microsoft SDK, then you 
are bound by the non-disclosure terms of the applicable EULA.

> No actual looking in header 
> files was done, which satisfies your 'do not copy from the header
> files' criterion.

If you need the Microsoft header files, to compile your simple C 
program, then you are using it to look in the header files; it may 
be indirect look-up, but the effect is the same.

> > > In that way, no plagiarism is applied, but still the values
> > > are available to be used.
> >
> > Not so.  It is plagiarism, in exactly the same way as if you had
> > read the Microsoft header directly.
>
> Why so? I beleive it to be very different.

See above.

-- 

Regards,
Keith.