Is WSARecvMsg available in mingw?

classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Is WSARecvMsg available in mingw?

Jeroen Asselman
Hello,

Currently I am porting an existing Linux program to windows which is
heavily network oriented.
Almost all code is ported, however I also need a replacement for the
recvmsg method in linux. Searching the MSDN docs I found WSARecvMsg,
allthough it is included in mingws mswsock.h I can't succesfully compile
it because the reference to the method is missing:

undefined reference to `WSARecvMsg@20'

The libraries linked are:
  -lwsock32 -lregex -lz -liconv -lws2_32 -lmswsock

Is it at all possible to use WSARecvMsg? Or am I forgetting another
library I should link against.

- Jeroen


------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: Is WSARecvMsg available in mingw?

Dongsheng Song
On Fri, Nov 19, 2010 at 16:56, Jeroen Asselman <[hidden email]> wrote:

> Hello,
>
> Currently I am porting an existing Linux program to windows which is
> heavily network oriented.
> Almost all code is ported, however I also need a replacement for the
> recvmsg method in linux. Searching the MSDN docs I found WSARecvMsg,
> allthough it is included in mingws mswsock.h I can't succesfully compile
> it because the reference to the method is missing:
>
> undefined reference to `WSARecvMsg@20'
>
> The libraries linked are:
>  -lwsock32 -lregex -lz -liconv -lws2_32 -lmswsock
>
> Is it at all possible to use WSARecvMsg? Or am I forgetting another
> library I should link against.
>
> - Jeroen
>

According MSDN page:
  http://msdn.microsoft.com/en-us/library/ms741687%28VS.85%29.aspx

WSARecvMsg in mswsock since Windows Server 2003,
but It's very strange both mingw32 and mingw-w64 not include it.

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: Is WSARecvMsg available in mingw?

Keith Marshall
On 19 November 2010 09:27, Dongsheng Song <[hidden email]> wrote:
> WSARecvMsg in mswsock since Windows Server 2003,
> but It's very strange both mingw32 and mingw-w64 not include it.

Nothing strange about it.  The function prototype was added to mswsock.h
in March 2002, but no corresponding export declaration was added to
lib/mswsock.def.  A simple oversight, no more.  They happen.

What might be considered strange is that *you* have taken so long to
bring it to our attention.  It is trivially easy to fix.

--
Regards,
Keith.

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: Is WSARecvMsg available in mingw?

Charles Wilson-2
On 11/19/2010 7:40 AM, Keith Marshall wrote:
> On 19 November 2010 09:27, Dongsheng Song
>> WSARecvMsg in mswsock since Windows Server 2003,
>> but It's very strange both mingw32 and mingw-w64 not include it.
>
> Nothing strange about it.  The function prototype was added to mswsock.h
> in March 2002, but no corresponding export declaration was added to
> lib/mswsock.def.  A simple oversight, no more.  They happen.

Err...not according to Ozkan.  This function is special -- and
apparently is not actually exported by any DLL. It is only available by
calling a different function, and requesting a POINTER to the function.
 The bug is apparently that we (mingwrt) prototype the function itself:

int PASCAL
WSARecvMsg(SOCKET,LPWSAMSG,LPDWORD,LPWSAOVERLAPPED,LPWSAOVERLAPPED_COMPLETION_ROUTINE);

rather than providing a typedef for the function pointer, like mingw64
and MS(? dunno, haven't looked) do:

typedef int (PASCAL *LPFN_WSARECVMSG)(SOCKET, LPWSAMSG, LPDWORD,
   LPWSAOVERLAPPED,LPWSAOVERLAPPED_COMPLETION_ROUTINE);

Apparently we also need the defn of WSAID_WSARECVMSG but I'm not sure
that's documented at MSDN.

> What might be considered strange is that *you* have taken so long to
> bring it to our attention.  It is trivially easy to fix.

Not really so trivial, actually.

--
Chuck

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: Is WSARecvMsg available in mingw?

Keith Marshall
On 19 November 2010 12:56, Charles Wilson wrote:

> On 11/19/2010 7:40 AM, Keith Marshall wrote:
>> On 19 November 2010 09:27, Dongsheng Song
>>> WSARecvMsg in mswsock since Windows Server 2003,
>>> but It's very strange both mingw32 and mingw-w64 not include it.
>>
>> Nothing strange about it.  The function prototype was added to mswsock.h
>> in March 2002, but no corresponding export declaration was added to
>> lib/mswsock.def.  A simple oversight, no more.  They happen.
>
> Err...not according to Ozkan.  This function is special -- and
> apparently is not actually exported by any DLL. It is only available by
> calling a different function, and requesting a POINTER to the function.

Ah!  Indeed, I overlooked:
|Note  The function pointer for the WSARecvMsg function must be obtained
|at run time by making a call to the WSAIoctl function with the
|SIO_GET_EXTENSION_FUNCTION_POINTER opcode specified. The input buffer
|passed to the WSAIoctl function must contain WSAID_WSARECVMSG, a
|globally unique identifier (GUID) whose value identifies the WSARecvMsg
|extension function. On success, the output returned by the WSAIoctl
|function contains a pointer to the WSARecvMsg function. The
|WSAID_WSARECVMSG GUID is defined in the Mswsock.h header file.

>  The bug is apparently that we (mingwrt) prototype the function itself:
>
> int PASCAL
> WSARecvMsg(SOCKET,LPWSAMSG,LPDWORD,LPWSAOVERLAPPED,LPWSAOVERLAPPED_COMPLETION_ROUTINE);
>
> rather than providing a typedef for the function pointer, like mingw64
> and MS(? dunno, haven't looked) do:
>
> typedef int (PASCAL *LPFN_WSARECVMSG)(SOCKET, LPWSAMSG, LPDWORD,
>   LPWSAOVERLAPPED,LPWSAOVERLAPPED_COMPLETION_ROUTINE);

Dunno.  We prototype it (in w32api, rather than mingwrt) as shown on
MSDN, but apparently it cannot be used directly as prototyped.

> Apparently we also need the defn of WSAID_WSARECVMSG but I'm not sure
> that's documented at MSDN.

Can't find anything appropriate; three references to it, but none which
specify the requisite value of the GUID.

>> What might be considered strange is that *you* have taken so long to
>> bring it to our attention.  It is trivially easy to fix.
>
> Not really so trivial, actually.

Indeed; likely impossible without public documentation of the requisite
GUID.

--
Regards,
Keith.

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: Is WSARecvMsg available in mingw?

Martin Mocko
On Fri, Nov 19, 2010 at 2:31 PM, Keith Marshall <[hidden email]> wrote:

>> What might be considered strange is that *you* have taken so long to
>> bring it to our attention.  It is trivially easy to fix.
>
> Not really so trivial, actually.

Indeed; likely impossible without public documentation of the requisite
GUID.

Is there any problem with simply taking value from MSWSock.h from MS Windows SDK?

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: Is WSARecvMsg available in mingw?

Peter Rosin
In reply to this post by Keith Marshall
Den 2010-11-19 14:31 skrev Keith Marshall:
> Indeed; likely impossible without public documentation of the requisite
> GUID.

Would the output of the below program compiled with MSVC qualify?

Cheers,
Peter


#include <stdio.h>
#include <winsock2.h>
#include <windows.h>
#include <mswsock.h>

typedef struct guid {
  unsigned long a;
  unsigned short b;
  unsigned short c;
  unsigned char d[8];
} guid;

int main(void)
{
        guid g = WSAID_WSARECVMSG;

        printf("%08x-%04x-%04x-%02x%02x-%02x%02x%02x%02x%02x%02x\n",
                g.a, g.b, g.c, g.d[0], g.d[1],
                g.d[2], g.d[3], g.d[4], g.d[5], g.d[6], g.d[7]);

        return 0;
}

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: Is WSARecvMsg available in mingw?

Charles Wilson-2
In reply to this post by Martin Mocko
On 11/19/2010 8:56 AM, Martin Mocko wrote:
> On Fri, Nov 19, 2010 at 2:31 PM, Keith Marshall wrote:
>> Indeed; likely impossible without public documentation of the requisite
>> GUID.
>>
>
> Is there any problem with simply taking value from MSWSock.h from MS Windows
> SDK?

The current position of this list is that doing so would violate the
Windows SDK EULA and copyright.

There is an argument to be made ("you can't copyright facts or ideas,
only their particular expression") that

a) given the DOJ Consent Decree where MS is obliged to provide equal
access to their public APIs, and

b) there is no 'expressiveness' in the actual form of a function
declaration or type definition: the language is so tightly constrained
that to match the API there is only one way to express it -- and
therefore a copyright can't be enforced.

However, IANAL and mingw.org doesn't HAVE lawyers...so we're not really
willing to wade into those waters.  Hence, the list position that "if it
isn't documented in TEXT form (e.g. not a .h) by Microsoft or perhaps a
book author, then we won't add it to our source code for fear of
upsetting the Lawyers Of Microsoft.

One reason mingw64 has more complete coverage of the w32api is that they
ARE supported by a company that HAS lawyers.  Plus, they've actually
gone thru the effort of doing a clean-room chinese-firewall (*)
development of the API (the things you can do given enough manpower...)

(*) That is, person X looks at the MS headers, and documents the APIs
and values.  He then sends that documentation to person Y, who
implements the API solely from the documentation, without ever looking
at the MS headers.  This is a long-established, perfectly legal
mechanism, and avoids the copyright infringement issues above.  But it
takes a lot of effort -- more than twice as much effort -- which mingw64
was able to do with corporate support.

FWIW, and contrary to my earlier claims, *nothing* in mingw64's runtime
or w32api derives in any way from our mingwrt or w32api, from what I can
tell. As far as I can see, it is a completely clean reimplementation.
AND, even tho we at mingw.org have long thought that "they" at mingw64
simply accepted any w32api patch from any contributor without asking
hard questions about provenance like we do ("Is this documented at
msdn.com? How did you develop this patch?") -- I'm told this is NOT
true.  Every contribution goes thru the same chinese firewall...

--
Chuck

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: Is WSARecvMsg available in mingw?

Charles Wilson-2
In reply to this post by Peter Rosin
On 11/19/2010 9:11 AM, Peter Rosin wrote:
> Den 2010-11-19 14:31 skrev Keith Marshall:
>> Indeed; likely impossible without public documentation of the requisite
>> GUID.
>
> Would the output of the below program compiled with MSVC qualify?

See this monster of a thread:
http://thread.gmane.org/gmane.comp.gnu.mingw.devel/1718/focus=1763
...which changed names here...
http://thread.gmane.org/gmane.comp.gnu.mingw.devel/1718/focus=1763

And, in particular, this one:
http://thread.gmane.org/gmane.comp.gnu.mingw.devel/1718/focus=1763

The key argument seems to be the following: reverse engineering to
achieve interoperability is ok...but supplying a replacement libuuid.a
to our users may not, actually, be "interoperability".

libuuid.a is not part of the OS -- it's part of the SDK; worse, we're
not "interoperating" with it -- we're replacing it.

Now, I think (IANAL) that we're trying to achieve interoperability with
the **OS** and doing that requires fully specifing the OS interfaces.
Reverse engineering to determine these interfaces is a well-established
and legal technique.  IM-not-a-lawyer-O, the CSLID and various other
IIDs *ARE* part of that interface, just as the values of enums are or
the signature of functions are.

IM-not-a-lawyer-O, reverse engineering to get the names AND values of
compiler constants, enums, and IIDs is perfectly legal -- since the goal
is to achieve interoperability with the Operating System.  Just because
we implement this interoperability using the C language and static
libraries -- and that our choice of name, "libuuid.a" is the same as an
SDK library that serves a similar purpose -- doesn't invalidate the
legality of our (proposed) reverse engineering.  IOW, "replacing" vs
"interoperating" is a red herring, because it's linking apples and
oranges: sure, we're "replacing" libuuid.a (the apple) but that doesn't
matter, because we're trying to achieve interoperability with the
Windows OS as a whole (the orange).

Now, here's the rub: you can only reverse engineer something that you
have a legal right to use in the first place.  So, you have to agree to
the Windows SDK EULA...which, if I recall correctly, explicitly
disallows reverse engineering (unless allowed by local law).  I can't
find the text of the Windows SDK EULA online, but here's the relevant
clause from the DirectX EULA:

a.  Limitations on Reverse Engineering, Decompilation and Disassembly.
You may not reverse engineer, decompile, or disassemble the SOFTWARE
PRODUCT, except and only to the extent that such activity is expressly
permitted by applicable law notwithstanding this limitation.

...and the applicable law expressly allows reverse engineering only to
achieve interoperability.

So the whole question boils down to "interoperability with what"?  The
rest of the SDK?  Between MinGW's gcc and the SDK's libuuid.a?  Or the
generic "with the windows OS"?  I have my opinion -- but I'm not a
lawyer, and don't relish the idea of gambling on not being sued by
Microsoft...

--
Chuck

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: Is WSARecvMsg available in mingw?

Peter Rosin
Den 2010-11-19 15:59 skrev Charles Wilson:

> On 11/19/2010 9:11 AM, Peter Rosin wrote:
>> Den 2010-11-19 14:31 skrev Keith Marshall:
>>> Indeed; likely impossible without public documentation of the requisite
>>> GUID.
>>
>> Would the output of the below program compiled with MSVC qualify?
>
> See this monster of a thread:
> http://thread.gmane.org/gmane.comp.gnu.mingw.devel/1718/focus=1763
> ...which changed names here...
> http://thread.gmane.org/gmane.comp.gnu.mingw.devel/1718/focus=1763
>
> And, in particular, this one:
> http://thread.gmane.org/gmane.comp.gnu.mingw.devel/1718/focus=1763

*snip nice summary of the above, same link three times BTW*

Right.  Who do I think I am?  Like noone would have suggested that before
me?  So, sorry for the noise.

Cheers,
Peter

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: Is WSARecvMsg available in mingw?

Cesar Strauss
In reply to this post by Charles Wilson-2
On 11/19/2010 12:24 PM, Charles Wilson wrote:
> FWIW, and contrary to my earlier claims, *nothing* in mingw64's runtime
> or w32api derives in any way from our mingwrt or w32api, from what I can
> tell. As far as I can see, it is a completely clean reimplementation.
> AND, even tho we at mingw.org have long thought that "they" at mingw64
> simply accepted any w32api patch from any contributor without asking
> hard questions about provenance like we do ("Is this documented at
> msdn.com? How did you develop this patch?") -- I'm told this is NOT
> true.  Every contribution goes thru the same chinese firewall...

In that light, would mingw64's files be an acceptable source for
mingw.org patches (provided the license is compatible)?

Cesar


------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: Is WSARecvMsg available in mingw?

Ehsan Azarnasab
In reply to this post by Charles Wilson-2
On Fri, Nov 19, 2010 at 7:24 AM, Charles Wilson
<[hidden email]> wrote:

> On 11/19/2010 8:56 AM, Martin Mocko wrote:
>> On Fri, Nov 19, 2010 at 2:31 PM, Keith Marshall wrote:
>>> Indeed; likely impossible without public documentation of the requisite
>>> GUID.
>>>
>>
>> Is there any problem with simply taking value from MSWSock.h from MS Windows
>> SDK?
>
> The current position of this list is that doing so would violate the
> Windows SDK EULA and copyright.
>
> There is an argument to be made ("you can't copyright facts or ideas,
> only their particular expression") that
>
> a) given the DOJ Consent Decree where MS is obliged to provide equal
> access to their public APIs, and
>
> b) there is no 'expressiveness' in the actual form of a function
> declaration or type definition: the language is so tightly constrained
> that to match the API there is only one way to express it -- and
> therefore a copyright can't be enforced.
>
> However, IANAL and mingw.org doesn't HAVE lawyers...so we're not really
> willing to wade into those waters.  Hence, the list position that "if it
> isn't documented in TEXT form (e.g. not a .h) by Microsoft or perhaps a
> book author, then we won't add it to our source code for fear of
> upsetting the Lawyers Of Microsoft.
>
> One reason mingw64 has more complete coverage of the w32api is that they
> ARE supported by a company that HAS lawyers.  Plus, they've actually
> gone thru the effort of doing a clean-room chinese-firewall (*)
> development of the API (the things you can do given enough manpower...)
>
> (*) That is, person X looks at the MS headers, and documents the APIs
> and values.  He then sends that documentation to person Y, who
> implements the API solely from the documentation, without ever looking
> at the MS headers.  This is a long-established, perfectly legal
> mechanism, and avoids the copyright infringement issues above.  But it
> takes a lot of effort -- more than twice as much effort -- which mingw64
> was able to do with corporate support.
>
> FWIW, and contrary to my earlier claims, *nothing* in mingw64's runtime
> or w32api derives in any way from our mingwrt or w32api, from what I can
> tell. As far as I can see, it is a completely clean reimplementation.
> AND, even tho we at mingw.org have long thought that "they" at mingw64
> simply accepted any w32api patch from any contributor without asking
> hard questions about provenance like we do ("Is this documented at
> msdn.com? How did you develop this patch?") -- I'm told this is NOT
> true.  Every contribution goes thru the same chinese firewall...
>

Wow this was a very nice explanation! I was always confused by the legal terms.

> --
> Chuck
>
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today
> http://p.sf.net/sfu/msIE9-sfdev2dev
> _______________________________________________
> MinGW-users mailing list
> [hidden email]
>
> This list observes the Etiquette found at
> http://www.mingw.org/Mailing_Lists.
> We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.
>
> _______________________________________________
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
>

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: Is WSARecvMsg available in mingw?

Charles Wilson-2
In reply to this post by Cesar Strauss
On 11/19/2010 6:33 PM, Cesar Strauss wrote:

> On 11/19/2010 12:24 PM, Charles Wilson wrote:
>> FWIW, and contrary to my earlier claims, *nothing* in mingw64's runtime
>> or w32api derives in any way from our mingwrt or w32api, from what I can
>> tell. As far as I can see, it is a completely clean reimplementation.
>> AND, even tho we at mingw.org have long thought that "they" at mingw64
>> simply accepted any w32api patch from any contributor without asking
>> hard questions about provenance like we do ("Is this documented at
>> msdn.com? How did you develop this patch?") -- I'm told this is NOT
>> true.  Every contribution goes thru the same chinese firewall...
>
> In that light, would mingw64's files be an acceptable source for
> mingw.org patches (provided the license is compatible)?

Well, see, that's the problem.  There are actually two questions:

#1 are we (mingw.org) satisfied with what *I* have been told about the
development process of mingw64?  *IF* what I have been told is true --
in each and every instance, not just 'most' or 'often' or 'nominally but
exceptions abound' (and we have to take their word for it; it's not like
we have any third-party inspector saying "Yep, mingw64 is actually doing
what they told Chuck they are doing") -- then it would probably be ok,
subject to licensing concerns.  But that's quite a big "if".

#2, of course: those licensing concerns.  We want to continue to release
under public domain -- which really means we can only use contributions
that are ALSO released under the public domain.  SOME of  mingw64's
stuff is not, _exactly_, PD: there is some LGPL and some ZPL (Zope
Public License) stuff in there, although most of it is PD.

--
Chuck

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: Is WSARecvMsg available in mingw?

d3x0r
On Fri, Nov 19, 2010 at 11:33 PM, Charles Wilson
<[hidden email]> wrote:

> On 11/19/2010 6:33 PM, Cesar Strauss wrote:
>> On 11/19/2010 12:24 PM, Charles Wilson wrote:
>>> FWIW, and contrary to my earlier claims, *nothing* in mingw64's runtime
>>> or w32api derives in any way from our mingwrt or w32api, from what I can
>>> tell. As far as I can see, it is a completely clean reimplementation.
>>> AND, even tho we at mingw.org have long thought that "they" at mingw64
>>> simply accepted any w32api patch from any contributor without asking
>>> hard questions about provenance like we do ("Is this documented at
>>> msdn.com? How did you develop this patch?") -- I'm told this is NOT
>>> true.  Every contribution goes thru the same chinese firewall...
>>
>> In that light, would mingw64's files be an acceptable source for
>> mingw.org patches (provided the license is compatible)?
>
> Well, see, that's the problem.  There are actually two questions:
>
> #1 are we (mingw.org) satisfied with what *I* have been told about the
> development process of mingw64?  *IF* what I have been told is true --
> in each and every instance, not just 'most' or 'often' or 'nominally but
> exceptions abound' (and we have to take their word for it; it's not like
> we have any third-party inspector saying "Yep, mingw64 is actually doing
> what they told Chuck they are doing") -- then it would probably be ok,
> subject to licensing concerns.  But that's quite a big "if".

And the harm from accepting arbitrary patches?  the function doesn't
actually exist in the windows system?  You're just providing a linkage
(a function definition and a way to register the correct names in a
DLL).   It's not like you're providing the documentation and have to
worry about what? plagiarism?  EIther the interface works or it
doesn't... Someone's gonna submit arbitrarily wrong function
definitions just for the hell of it?  I dunno maybe I'm just distrubed
by a 'we' and 'they' attitude... such animosity over... supporting
definitions for linking to code that isn't even yours?

>
> #2, of course: those licensing concerns.  We want to continue to release
> under public domain -- which really means we can only use contributions
> that are ALSO released under the public domain.  SOME of  mingw64's
> stuff is not, _exactly_, PD: there is some LGPL and some ZPL (Zope
> Public License) stuff in there, although most of it is PD.
>
> --
> Chuck
>
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today
> http://p.sf.net/sfu/msIE9-sfdev2dev
> _______________________________________________
> MinGW-users mailing list
> [hidden email]
>
> This list observes the Etiquette found at
> http://www.mingw.org/Mailing_Lists.
> We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.
>
> _______________________________________________
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
>

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: Is WSARecvMsg available in mingw?

Peter Rosin
In reply to this post by Charles Wilson-2
Den 2010-11-20 08:33 skrev Charles Wilson:

> On 11/19/2010 6:33 PM, Cesar Strauss wrote:
>> On 11/19/2010 12:24 PM, Charles Wilson wrote:
>>> FWIW, and contrary to my earlier claims, *nothing* in mingw64's runtime
>>> or w32api derives in any way from our mingwrt or w32api, from what I can
>>> tell. As far as I can see, it is a completely clean reimplementation.
>>> AND, even tho we at mingw.org have long thought that "they" at mingw64
>>> simply accepted any w32api patch from any contributor without asking
>>> hard questions about provenance like we do ("Is this documented at
>>> msdn.com? How did you develop this patch?") -- I'm told this is NOT
>>> true.  Every contribution goes thru the same chinese firewall...
>>
>> In that light, would mingw64's files be an acceptable source for
>> mingw.org patches (provided the license is compatible)?
>
> Well, see, that's the problem.  There are actually two questions:
>
> #1 are we (mingw.org) satisfied with what *I* have been told about the
> development process of mingw64?  *IF* what I have been told is true --
> in each and every instance, not just 'most' or 'often' or 'nominally but
> exceptions abound' (and we have to take their word for it; it's not like
> we have any third-party inspector saying "Yep, mingw64 is actually doing
> what they told Chuck they are doing") -- then it would probably be ok,
> subject to licensing concerns.  But that's quite a big "if".
>
> #2, of course: those licensing concerns.  We want to continue to release
> under public domain -- which really means we can only use contributions
> that are ALSO released under the public domain.  SOME of  mingw64's
> stuff is not, _exactly_, PD: there is some LGPL and some ZPL (Zope
> Public License) stuff in there, although most of it is PD.

IF mingw is ok with #1, and is only concerned about #2, then programs
like mine would come in handy but built with mingw64 instead of msvc.
Assuming there's no non-reverse-engineering clause in the mingw64
license, of course.  But mingw64 lawyers are perhaps not as scary
either...

Cheers,
Peter

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Yet another mingwrt/w32api provenance discussion [Was: Re: Is WSARecvMsg available in mingw?]

Charles Wilson-2
In reply to this post by d3x0r
On 11/20/2010 4:04 AM, J Decker wrote:

> On Fri, Nov 19, 2010 at 11:33 PM, Charles Wilson wrote:
>> Well, see, that's the problem.  There are actually two questions:
>>
>> #1 are we (mingw.org) satisfied with what *I* have been told about the
>> development process of mingw64?  *IF* what I have been told is true --
>> in each and every instance, not just 'most' or 'often' or 'nominally but
>> exceptions abound' (and we have to take their word for it; it's not like
>> we have any third-party inspector saying "Yep, mingw64 is actually doing
>> what they told Chuck they are doing") -- then it would probably be ok,
>> subject to licensing concerns.  But that's quite a big "if".
>
> And the harm from accepting arbitrary patches?  the function doesn't
> actually exist in the windows system?  You're just providing a linkage
> (a function definition and a way to register the correct names in a
> DLL).   It's not like you're providing the documentation and have to
> worry about what? plagiarism?

Exactly.  Another word for "plagiarism" (without due consideration of
licensing issues, such as EULAs, restrictions on reverse engineering,
and re-distribution rules) is "copyright infringement", which subjects
us to legal liability.  Worse, however, is that it could put our *users*
in danger.

Suppose we "copied" some code that is GPL into the mingw runtime
library, but didn't tell anybody, or didn't notice, or didn't care.  Our
users might then compile highly valuable proprietary programs using our
compiler -- and then sell their products to somebody else.  Then,
suppose that somebody else looked at the mingw.org runtime code, and
discovered the "GPL" inclusion.

They could then plausibly assert that (a) the mingw runtime code is
actually GPL, since it "plagiarized" code that was originally GPL.
Because of the viral nature of the GPL, they could then assert that (b)
any program linked using mingw was ALSO GPL -- and then go to our user
and demand the source code of their proprietary product.  And a court
would most likely agree...if mingw.org's infringement was a blatant case
of negligence or deliberate offense, and our user's due diligence ought
to have detected.

For instance, if somebody said on our mailing lists that we shouldn't
worry about "plagiarism" and nobody contradicted them...

So, yes, we DO have to be VERY careful about licensing issues.

A similar argument could be made with respect to MS's EULA and reverse
engineering prohibitions, but at least those wouldn't be "viral"; our
users wouldn't be affected.  Just us.  Personally.  By being sued.
Personally.  By a team of microsoft lawyers with a practically unlimited
budget.

No thanks.

> EIther the interface works or it
> doesn't... Someone's gonna submit arbitrarily wrong function
> definitions just for the hell of it?  I dunno maybe I'm just distrubed
> by a 'we' and 'they' attitude... such animosity over... supporting
> definitions for linking to code that isn't even yours?

No, it's not "animosity" -- although in the past there was some of that
between the two forks.  Right now we are all just kinda slowly feeling
our way back to a rapproachment (but not a merger, for some pretty
decent technical reasons).

However, I'm going to make a radical suggestion: PROVIDED mingw.org can
convince themselves of the "goodness" of mingw64's stuff (technically,
legally, license-wise, etc etc etc, according to the standards of our
project)...I assert that if we EVER get to the point that we would
accept patches derived from mingw64's runtime and headers:

Then we should work with cygwin to drop w32api and mingwrt completely --
even removing them from the src repo -- and adopt mingw64's runtime and
headers wholesale.  They are just that much more complete than ours.

There'd still be many reasons for mingw.org's compiler to exist apart
from mingw64 for certain other technical reasons (mingw64 uses sjlj
which IMO means their java is basically unusably slow; mingw.org uses
the much faster dw2: this ABI difference is reason enough on its own).

--
Chuck

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: Yet another mingwrt/w32api provenance discussion [Was: Re: Is WSARecvMsg available in mingw?]

Tor Lillqvist
(Click below only if you have accepted the EULA for the Windows SDK,
or if you are not planning to contribute to MinGW)

For an insight into the carefulness in mingw-w64, have a look at for instance

http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/trunk/mingw-w64-crt/libsrc/wspiapi/WspiapiLegacyGetAddrInfo.c?revision=2262&view=markup

and then wspiapi.h in your copy of the Windows SDK, or if you don't
have that, google for it, which will point you for instance to this
copy:

http://pacparser.googlecode.com/hg/spidermonkey/win32/WSPiApi.h?r=02494612286a2a159f38523325588437e202d903

--tml

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: Is WSARecvMsg available in mingw?

d3x0r
In reply to this post by d3x0r
Are there functions that are actually exported in windows that aren't
documented?  Or did people just not know where to look at the
documentation; or... did the documentation just take a while to get
written?

Windows isn't like linux - every function that is meant to be exposed
is exposed... not every function that's not static to a single source
module; or marked with hidden (in recent years).

So it's not very likely that there will exist an entry into a DLL that
doesn't have some definition; too bad mingw doesn't just use platform
sdk headers and libraries (the format of which is publicly avaiable).
(other than in recent years MS has started adding in, out, etc
attributes which make the sdk's harder to use with non MS compilers,
it was often useful to just use proper SDK headers that are avialable
for public consumption.)

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: Yet another mingwrt/w32api provenance discussion [Was: Re: Is WSARecvMsg available in mingw?]

d3x0r
In reply to this post by Charles Wilson-2
On Sat, Nov 20, 2010 at 8:12 AM, Charles Wilson
<[hidden email]> wrote:

> On 11/20/2010 4:04 AM, J Decker wrote:
>> On Fri, Nov 19, 2010 at 11:33 PM, Charles Wilson wrote:
>>> Well, see, that's the problem.  There are actually two questions:
>>>
>>> #1 are we (mingw.org) satisfied with what *I* have been told about the
>>> development process of mingw64?  *IF* what I have been told is true --
>>> in each and every instance, not just 'most' or 'often' or 'nominally but
>>> exceptions abound' (and we have to take their word for it; it's not like
>>> we have any third-party inspector saying "Yep, mingw64 is actually doing
>>> what they told Chuck they are doing") -- then it would probably be ok,
>>> subject to licensing concerns.  But that's quite a big "if".
>>
>> And the harm from accepting arbitrary patches?  the function doesn't
>> actually exist in the windows system?  You're just providing a linkage
>> (a function definition and a way to register the correct names in a
>> DLL).   It's not like you're providing the documentation and have to
>> worry about what? plagiarism?
>
> Exactly.  Another word for "plagiarism" (without due consideration of
> licensing issues, such as EULAs, restrictions on reverse engineering,
> and re-distribution rules) is "copyright infringement", which subjects
> us to legal liability.  Worse, however, is that it could put our *users*
> in danger.

Okay so I downloaded, installed the latest sdk and stopped to read the
EULA.  I'm not sure any sort of reverse engineering science is needed
to read header files.  The libray format (COFF) is publicly available
for people to be able to consume them without having to reverse
engineer them.

"You may not
·         work around any technical limitations in the software;"

I find this humerous for numerous reasons :)

But in the docs - you can make as many copies as you want, you can
even post and distrubute them with or independantly of the program
using the redist parts... you just can never charge or modify the
original; nor can you change the copyright information on this... (so?
who'd want to? it's microsofts, no use in claiming it's mine)

There is no clause about 'do not plagiarize' .


This is the first clause

.      INSTALLATION AND USE RIGHTS.
a.      Installation and Use.  You may install and use any number of
copies of the software on your devices to design, develop and test
your programs that run on a Microsoft Windows operating system.
Further, you may install, use and/or deploy via a network management
system or as part of a desktop image, any number of copies of the
software on computer devices within your internal corporate network to
design, develop and test your programs that run on a Microsoft Windows
operating system.  Each copy must be complete, including all copyright
and trademark notices.  You must require end users to agree to the
terms that protect the software as much as these License terms.


You're actuall not in compliance by not maintaining a fully compliant
copy.  YOu're not supposed to distribute copies of this information
that are not complete in their entirety.

>
> Suppose we "copied" some code that is GPL into the mingw runtime
> library, but didn't tell anybody, or didn't notice, or didn't care.  Our
> users might then compile highly valuable proprietary programs using our
> compiler -- and then sell their products to somebody else.  Then,
> suppose that somebody else looked at the mingw.org runtime code, and
> discovered the "GPL" inclusion.
>
> They could then plausibly assert that (a) the mingw runtime code is
> actually GPL, since it "plagiarized" code that was originally GPL.
> Because of the viral nature of the GPL, they could then assert that (b)
> any program linked using mingw was ALSO GPL -- and then go to our user
> and demand the source code of their proprietary product.  And a court
> would most likely agree...if mingw.org's infringement was a blatant case
> of negligence or deliberate offense, and our user's due diligence ought
> to have detected.
>
> For instance, if somebody said on our mailing lists that we shouldn't
> worry about "plagiarism" and nobody contradicted them...
>
> So, yes, we DO have to be VERY careful about licensing issues.
>
> A similar argument could be made with respect to MS's EULA and reverse
> engineering prohibitions, but at least those wouldn't be "viral"; our
> users wouldn't be affected.  Just us.  Personally.  By being sued.
> Personally.  By a team of microsoft lawyers with a practically unlimited
> budget.
>
> No thanks.
>
>> EIther the interface works or it
>> doesn't... Someone's gonna submit arbitrarily wrong function
>> definitions just for the hell of it?  I dunno maybe I'm just distrubed
>> by a 'we' and 'they' attitude... such animosity over... supporting
>> definitions for linking to code that isn't even yours?
>
> No, it's not "animosity" -- although in the past there was some of that
> between the two forks.  Right now we are all just kinda slowly feeling
> our way back to a rapproachment (but not a merger, for some pretty
> decent technical reasons).
>
> However, I'm going to make a radical suggestion: PROVIDED mingw.org can
> convince themselves of the "goodness" of mingw64's stuff (technically,
> legally, license-wise, etc etc etc, according to the standards of our
> project)...I assert that if we EVER get to the point that we would
> accept patches derived from mingw64's runtime and headers:
>
> Then we should work with cygwin to drop w32api and mingwrt completely --
> even removing them from the src repo -- and adopt mingw64's runtime and
> headers wholesale.  They are just that much more complete than ours.
>
> There'd still be many reasons for mingw.org's compiler to exist apart
> from mingw64 for certain other technical reasons (mingw64 uses sjlj
> which IMO means their java is basically unusably slow; mingw.org uses
> the much faster dw2: this ABI difference is reason enough on its own).
>
> --
> Chuck
>
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today
> http://p.sf.net/sfu/msIE9-sfdev2dev
> _______________________________________________
> MinGW-users mailing list
> [hidden email]
>
> This list observes the Etiquette found at
> http://www.mingw.org/Mailing_Lists.
> We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.
>
> _______________________________________________
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
>

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: Yet another mingwrt/w32api provenance discussion [Was: Re: Is WSARecvMsg available in mingw?]

d3x0r
Sorry I don't mean 'complete copy' I mean 'complete functionality'

There's also nothing that says 'you shall not extend the compile chain
to include a c-preprocessor-preprocessor' which could just do a quick
transform of the headers, then pass them to the appropraite tool.

On Sat, Nov 20, 2010 at 4:23 PM, J Decker <[hidden email]> wrote:

> On Sat, Nov 20, 2010 at 8:12 AM, Charles Wilson
> <[hidden email]> wrote:
>> On 11/20/2010 4:04 AM, J Decker wrote:
>>> On Fri, Nov 19, 2010 at 11:33 PM, Charles Wilson wrote:
>>>> Well, see, that's the problem.  There are actually two questions:
>>>>
>>>> #1 are we (mingw.org) satisfied with what *I* have been told about the
>>>> development process of mingw64?  *IF* what I have been told is true --
>>>> in each and every instance, not just 'most' or 'often' or 'nominally but
>>>> exceptions abound' (and we have to take their word for it; it's not like
>>>> we have any third-party inspector saying "Yep, mingw64 is actually doing
>>>> what they told Chuck they are doing") -- then it would probably be ok,
>>>> subject to licensing concerns.  But that's quite a big "if".
>>>
>>> And the harm from accepting arbitrary patches?  the function doesn't
>>> actually exist in the windows system?  You're just providing a linkage
>>> (a function definition and a way to register the correct names in a
>>> DLL).   It's not like you're providing the documentation and have to
>>> worry about what? plagiarism?
>>
>> Exactly.  Another word for "plagiarism" (without due consideration of
>> licensing issues, such as EULAs, restrictions on reverse engineering,
>> and re-distribution rules) is "copyright infringement", which subjects
>> us to legal liability.  Worse, however, is that it could put our *users*
>> in danger.
>
> Okay so I downloaded, installed the latest sdk and stopped to read the
> EULA.  I'm not sure any sort of reverse engineering science is needed
> to read header files.  The libray format (COFF) is publicly available
> for people to be able to consume them without having to reverse
> engineer them.
>
> "You may not
> ·         work around any technical limitations in the software;"
>
> I find this humerous for numerous reasons :)
>
> But in the docs - you can make as many copies as you want, you can
> even post and distrubute them with or independantly of the program
> using the redist parts... you just can never charge or modify the
> original; nor can you change the copyright information on this... (so?
> who'd want to? it's microsofts, no use in claiming it's mine)
>
> There is no clause about 'do not plagiarize' .
>
>
> This is the first clause
>
> .      INSTALLATION AND USE RIGHTS.
> a.      Installation and Use.  You may install and use any number of
> copies of the software on your devices to design, develop and test
> your programs that run on a Microsoft Windows operating system.
> Further, you may install, use and/or deploy via a network management
> system or as part of a desktop image, any number of copies of the
> software on computer devices within your internal corporate network to
> design, develop and test your programs that run on a Microsoft Windows
> operating system.  Each copy must be complete, including all copyright
> and trademark notices.  You must require end users to agree to the
> terms that protect the software as much as these License terms.
>
>
> You're actuall not in compliance by not maintaining a fully compliant
> copy.  YOu're not supposed to distribute copies of this information
> that are not complete in their entirety.
>
>>
>> Suppose we "copied" some code that is GPL into the mingw runtime
>> library, but didn't tell anybody, or didn't notice, or didn't care.  Our
>> users might then compile highly valuable proprietary programs using our
>> compiler -- and then sell their products to somebody else.  Then,
>> suppose that somebody else looked at the mingw.org runtime code, and
>> discovered the "GPL" inclusion.
>>
>> They could then plausibly assert that (a) the mingw runtime code is
>> actually GPL, since it "plagiarized" code that was originally GPL.
>> Because of the viral nature of the GPL, they could then assert that (b)
>> any program linked using mingw was ALSO GPL -- and then go to our user
>> and demand the source code of their proprietary product.  And a court
>> would most likely agree...if mingw.org's infringement was a blatant case
>> of negligence or deliberate offense, and our user's due diligence ought
>> to have detected.
>>
>> For instance, if somebody said on our mailing lists that we shouldn't
>> worry about "plagiarism" and nobody contradicted them...
>>
>> So, yes, we DO have to be VERY careful about licensing issues.
>>
>> A similar argument could be made with respect to MS's EULA and reverse
>> engineering prohibitions, but at least those wouldn't be "viral"; our
>> users wouldn't be affected.  Just us.  Personally.  By being sued.
>> Personally.  By a team of microsoft lawyers with a practically unlimited
>> budget.
>>
>> No thanks.
>>
>>> EIther the interface works or it
>>> doesn't... Someone's gonna submit arbitrarily wrong function
>>> definitions just for the hell of it?  I dunno maybe I'm just distrubed
>>> by a 'we' and 'they' attitude... such animosity over... supporting
>>> definitions for linking to code that isn't even yours?
>>
>> No, it's not "animosity" -- although in the past there was some of that
>> between the two forks.  Right now we are all just kinda slowly feeling
>> our way back to a rapproachment (but not a merger, for some pretty
>> decent technical reasons).
>>
>> However, I'm going to make a radical suggestion: PROVIDED mingw.org can
>> convince themselves of the "goodness" of mingw64's stuff (technically,
>> legally, license-wise, etc etc etc, according to the standards of our
>> project)...I assert that if we EVER get to the point that we would
>> accept patches derived from mingw64's runtime and headers:
>>
>> Then we should work with cygwin to drop w32api and mingwrt completely --
>> even removing them from the src repo -- and adopt mingw64's runtime and
>> headers wholesale.  They are just that much more complete than ours.
>>
>> There'd still be many reasons for mingw.org's compiler to exist apart
>> from mingw64 for certain other technical reasons (mingw64 uses sjlj
>> which IMO means their java is basically unusably slow; mingw.org uses
>> the much faster dw2: this ABI difference is reason enough on its own).
>>
>> --
>> Chuck
>>
>> ------------------------------------------------------------------------------
>> Beautiful is writing same markup. Internet Explorer 9 supports
>> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
>> Spend less time writing and  rewriting code and more time creating great
>> experiences on the web. Be a part of the beta today
>> http://p.sf.net/sfu/msIE9-sfdev2dev
>> _______________________________________________
>> MinGW-users mailing list
>> [hidden email]
>>
>> This list observes the Etiquette found at
>> http://www.mingw.org/Mailing_Lists.
>> We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.
>>
>> _______________________________________________
>> You may change your MinGW Account Options or unsubscribe at:
>> https://lists.sourceforge.net/lists/listinfo/mingw-users
>>
>

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
12