www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Round-up of the recent WindowsAPI discussions from when I wasn't looking

reply "Stewart Gordon" <smjg_1998 yahoo.com> writes:
I was away for a week or two recently, so it's no wonder I didn't catch some 
of the discussion while it was actually happening.  Some of it was also 
where I don't tend to look: the Dsource forums.

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=56630

This started as a discussion on how COM interfaces are handled, though it 
isn't clear whether the claim that something was wrong was done by actual 
testing or mere manual reading of the code.  But some more general 
discussion on the WindowsAPI project then began.  I've just posted a few 
responses there; I'll just round it up here.

At the moment, the Wiki4D page

http://www.prowiki.org/wiki4d/wiki.cgi?WindowsAPI

is the official one.  There have been suggestions to migrate it to the 
Dsource Bindings wiki; I'll probably have a go at doing this over the next 
few days.  This would also be a good time to split it up as has also been 
suggested.  The wiki would become the sole home of the translation 
instructions, rather than having it duplicated in the readme.txt file.

One question remains: What should we do with all the old discussion from the 
current wiki page?


These threads have appeared on the dsource forum:

http://www.dsource.org/forums/viewtopic.php?t=2253
http://www.dsource.org/forums/viewtopic.php?t=2538
http://www.dsource.org/forums/viewtopic.php?t=2937
http://www.dsource.org/forums/viewtopic.php?t=2991

but there isn't much that needs to be said to round up these discussions. 
Though there's something about the makefile in there, which is included in 
what follows.


There are a few issues with recent changes to the WindowsAPI modules.

For some reason I can't imagine, WeirdCat decided to rewrite vfw.d from 
scratch.  He/she/it didn't even indicate what it's a translation of, but 
replaced the line "Translated from MinGW Windows headers" with "written in 
the D programming language".  It may be true that the MinGW header is a 
disaster area, but in the same discussion it was pointed out that vfw ought 
to be deleted as it's an obsolete API.

Another contribution by WeirdCat is a makefile that doesn't work.  One of 
the threads on the Dsource forum revealed the problem: it uses GNU-specific 
syntax.  There seems to be no reason for this.  This being a D project, it 
should be fully compatible with the Digital Mars tools among others.

Clw has retranslated the D3D9 stuff from Microsoft's own headers.  The 
commit message was: "Updated d3d9 headers to D3D9Ex and corrected some 
errors".  Somebody or other took the words out of my mouth by stating that 
it was wrong to put in something that's derived from Microsoft's copyrighted 
headers.  This project is meant to be public domain.


When this project was started, MinGW 3.6 was current.  Now the current 
version of MinGW is 3.9.  But at the moment there's no marking of what's 
been updated to the new stuff.  We need to make it our policy to include the 
MinGW version number in each file's heading comment.

And to simplify the process of updating the modules, we could do with a set 
of diffs between MinGW 3.6 and 3.9....


Comments?

Stewart.
Aug 27 2007
next sibling parent jcc7 <technocrat7 gmail.com> writes:
Sorry, I would have replied to this "Round-up" instead of in the old "Problem
with
COM ..." thread, but I saw the older message first (and I didn't realize that a
"Round-up" thread was available).

My reply in the old thread:
http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=57488

I've also embedded a few more comments below...


== Quote from Stewart Gordon (smjg_1998 yahoo.com)'s article

 I was away for a week or two recently, so it's no wonder I didn't catch some
 of the discussion while it was actually happening.  Some of it was also
 where I don't tend to look: the Dsource forums.


<...snip...>


 At the moment, the Wiki4D page
 http://www.prowiki.org/wiki4d/wiki.cgi?WindowsAPI
 is the official one.  There have been suggestions to migrate it to the
 Dsource Bindings wiki; I'll probably have a go at doing this over the next
 few days.


I think that's a good idea. In fact, I already replied to one of your earlier
messages recommended this. ;)




 This would also be a good time to split it up as has also been
 suggested.  The wiki would become the sole home of the translation
 instructions, rather than having it duplicated in the readme.txt file.
 One question remains: What should we do with all the old discussion from the
 current wiki page?


You could just cram it into a "Discussion" page in the dsource Trac wiki. And
then
you could delete the least relevant parts of the discussion over time.

<...snip...>
Aug 28 2007
prev sibling next sibling parent "Anders Bergh" <anders1 gmail.com> writes:
OT: some say headers / interfaces can't be copyrighted, is that false?
I wrote this reply with my phone so I apologize if it sends as html or so...

On 8/28/07, Stewart Gordon <smjg_1998 yahoo.com> wrote:

 I was away for a week or two recently, so it's no wonder I didn't catch some
 of the discussion while it was actually happening.  Some of it was also
 where I don't tend to look: the Dsource forums.

 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=56630

 This started as a discussion on how COM interfaces are handled, though it
 isn't clear whether the claim that something was wrong was done by actual
 testing or mere manual reading of the code.  But some more general
 discussion on the WindowsAPI project then began.  I've just posted a few
 responses there; I'll just round it up here.

 At the moment, the Wiki4D page

 http://www.prowiki.org/wiki4d/wiki.cgi?WindowsAPI

 is the official one.  There have been suggestions to migrate it to the
 Dsource Bindings wiki; I'll probably have a go at doing this over the next
 few days.  This would also be a good time to split it up as has also been
 suggested.  The wiki would become the sole home of the translation
 instructions, rather than having it duplicated in the readme.txt file.

 One question remains: What should we do with all the old discussion from the
 current wiki page?


 These threads have appeared on the dsource forum:

 http://www.dsource.org/forums/viewtopic.php?t=2253
 http://www.dsource.org/forums/viewtopic.php?t=2538
 http://www.dsource.org/forums/viewtopic.php?t=2937
 http://www.dsource.org/forums/viewtopic.php?t=2991

 but there isn't much that needs to be said to round up these discussions.
 Though there's something about the makefile in there, which is included in
 what follows.


 There are a few issues with recent changes to the WindowsAPI modules.

 For some reason I can't imagine, WeirdCat decided to rewrite vfw.d from
 scratch.  He/she/it didn't even indicate what it's a translation of, but
 replaced the line "Translated from MinGW Windows headers" with "written in
 the D programming language".  It may be true that the MinGW header is a
 disaster area, but in the same discussion it was pointed out that vfw ought
 to be deleted as it's an obsolete API.

 Another contribution by WeirdCat is a makefile that doesn't work.  One of
 the threads on the Dsource forum revealed the problem: it uses GNU-specific
 syntax.  There seems to be no reason for this.  This being a D project, it
 should be fully compatible with the Digital Mars tools among others.

 Clw has retranslated the D3D9 stuff from Microsoft's own headers.  The
 commit message was: "Updated d3d9 headers to D3D9Ex and corrected some
 errors".  Somebody or other took the words out of my mouth by stating that
 it was wrong to put in something that's derived from Microsoft's copyrighted
 headers.  This project is meant to be public domain.


 When this project was started, MinGW 3.6 was current.  Now the current
 version of MinGW is 3.9.  But at the moment there's no marking of what's
 been updated to the new stuff.  We need to make it our policy to include the
 MinGW version number in each file's heading comment.

 And to simplify the process of updating the modules, we could do with a set
 of diffs between MinGW 3.6 and 3.9....


 Comments?

 Stewart.
Aug 28 2007
prev sibling next sibling parent reply "Stewart Gordon" <smjg_1998 yahoo.com> writes:
"Stewart Gordon" <smjg_1998 yahoo.com> wrote in message 
news:favq79$n05$1 digitalmars.com...
<snip>

 When this project was started, MinGW 3.6 was current.  Now the current 
 version of MinGW is 3.9.  But at the moment there's no marking of what's 
 been updated to the new stuff.  We need to make it our policy to include 
 the MinGW version number in each file's heading comment.

 And to simplify the process of updating the modules, we could do with a 
 set of diffs between MinGW 3.6 and 3.9....


Since I wrote this, I noticed that MinGW 3.10 is now out.

http://sourceforge.net/project/showfiles.php?group_id=2435

The site still offers version 3.9 as well, but by the looks of it nothing 
older.  Still, I might be able to dig up 3.6 in order to make diffs to aid 
updating.  Or maybe someone else still has 3.6 to hand....

Stewart.
Aug 30 2007
parent jcc7 <technocrat7 gmail.com> writes:
== Quote from Stewart Gordon (smjg_1998 yahoo.com)'s article

 "Stewart Gordon" <smjg_1998 yahoo.com> wrote in message
 news:favq79$n05$1 digitalmars.com...
 <snip>

 When this project was started, MinGW 3.6 was current.  Now the current
 version of MinGW is 3.9.  But at the moment there's no marking of what's
 been updated to the new stuff.  We need to make it our policy to include
 the MinGW version number in each file's heading comment.

 And to simplify the process of updating the modules, we could do with a
 set of diffs between MinGW 3.6 and 3.9....


 Since I wrote this, I noticed that MinGW 3.10 is now out.
 http://sourceforge.net/project/showfiles.php?group_id=2435
 The site still offers version 3.9 as well, but by the looks of it
 nothing older.  Still, I might be able to dig up 3.6 in order to
 make diffs to aid updating.  Or maybe someone else still has 3.6 to
 hand....
 Stewart.


It's not the "official" site, but I found a file called w32api-3.6-src.tar.gz
at:
ftp://gd.tuwien.ac.at/gnu/mingw/

(I found the link from the list of "mirror sites" at
http://www.mingw.org/download.shtml#hdr2)
Aug 31 2007
prev sibling parent reply Sascha Katzner (aka WeirdCat) <sorry.no spam.org> writes:
Stewart Gordon Wrote:

 For some reason I can't imagine, WeirdCat decided to rewrite vfw.d
 from scratch.  He/she/it didn't even indicate what it's a translation
 of, but replaced the line "Translated from MinGW Windows headers"
 with "written in the D programming language".  It may be true that
 the MinGW header is a disaster area, but in the same discussion it
 was pointed out that vfw ought to be deleted as it's an obsolete API.


I (*He*) did translate vfw because I needed it for a project and the old file
was indeed a disaster. I don't think the file is obsolete, all the cap*
functions are defined there, which you need for Webcams for example. The
translation was based on the windows header files from m$ (see below).


 Another contribution by WeirdCat is a makefile that doesn't work.
 One of the threads on the Dsource forum revealed the problem: it uses
 GNU-specific syntax.  There seems to be no reason for this.  This
 being a D project, it should be fully compatible with the Digital
 Mars tools among others.


The makefile works. I used GNU specific syntax to use wildcards, otherwise you
have to maintain a list of every single file of the project in the makefile. I
think this is circumstantially in a project with so many contributors. It is
much easier to use wildcards.

(see http://www.dsource.org/forums/viewtopic.php?t=2538 for my original reply)


 Somebody or other took the words out of my mouth by stating that it
 was wrong to put in something that's derived from Microsoft's
 copyrighted headers.  This project is meant to be public domain.


I think you should differentiate here if someone used the original windows
header files only as documentation of windows functions and interfaces (like me
or the MinGW Team), or if someone automatically translated the files via a tool.

If you use them only as documentation and "translate" (a better word would be
'rewrite') everything by hand (you have to write your own comments!), no
intellectual property from m$ should be harmed (*warning* I am no lawyer!).

Because this was the way, the MinGW Team created their header files, I realy
see no reason that we couldn't go that way.

LLAP,
Sascha
Sep 05 2007
parent reply "Stewart Gordon" <smjg_1998 yahoo.com> writes:
"Sascha Katzner (aka WeirdCat)" <sorry.no spam.org> wrote in message 
news:fbmrb5$k6m$1 digitalmars.com...
<snip>

 I (*He*) did translate vfw because I needed it for a project and
 the old file was indeed a disaster.  I don't think the file is
 obsolete, all the cap* functions are defined there, which you need
 for Webcams for example.  The translation was based on the windows
 header files from m$ (see below).


I've just found the message I was thinking of:

http://tinyurl.com/32fwus

But if no replacement API has been provided, it can't be obsolete. 
Moreover, I've just looked on MSDN, which still gives vfw as being the way 
to do video capture.  So Don must've been wrong.  You have a point there....

<snip>

 I think you should differentiate here if someone used the original
 windows header files only as documentation of windows functions and
 interfaces (like me or the MinGW Team), or if someone automatically
 translated the files via a tool.

 If you use them only as documentation and "translate" (a better
 word would be 'rewrite') everything by hand (you have to write your
 own comments!), no intellectual property from m$ should be harmed
 (*warning* I am no lawyer!).


I'm not sure I know what you mean.  Are you basically talking about 
extracting the structure definitions and function prototypes from the 
headers, and then putting them into new headers created from scratch?

Where does hand-tweaking someone else's headers fall into your argument? 
This is the approach I'm using.  I think there are also a few people running 
the headers through an automated tool and then hand-tweaking the output.


 Because this was the way, the MinGW Team created their header
 files, I realy see no reason that we couldn't go that way.


What is your source for this statement?

Stewart.
Sep 05 2007
parent reply Sascha Katzner <sorry.no spam.invalid> writes:
Stewart Gordon wrote:

 I'm not sure I know what you mean.  Are you basically talking about 
 extracting the structure definitions and function prototypes from the
  headers, and then putting them into new headers created from 
 scratch?


Yes.


 Where does hand-tweaking someone else's headers fall into your 
 argument? This is the approach I'm using.  I think there are also a 
 few people running the headers through an automated tool and then 
 hand-tweaking the output.


I think it depends on the source of the headers and how far you define 
hand-tweaking. If you use an automated tool you shouldn't use the 
original m$ headers in any case, because this could violate the 
intellectual property of m$. It's safer in this case to use the public 
domain MinGW headers.

On the other hand if someone would (pure hypothetical) use an automated 
tool on original m$ headers and hand-tweak the result (delete the 
comments and reformat it, perhaps also rename parameter names), no one 
could distinguish the result from a pure rewrite from scratch via hand. 
...I think this would be in a gray zone.


 Because this was the way, the MinGW Team created their header 
 files, I realy see no reason that we couldn't go that way.


 
 What is your source for this statement?


I really see no other way they could have created their files, if
reverse engineering is off-limits.

LLAP,
Sascha
Sep 05 2007
parent reply Don Clugston <dac nospam.com.au> writes:
Sascha Katzner wrote:

 Stewart Gordon wrote:

 I'm not sure I know what you mean.  Are you basically talking about 
 extracting the structure definitions and function prototypes from the
  headers, and then putting them into new headers created from scratch?


 
 Yes.

 Where does hand-tweaking someone else's headers fall into your 
 argument? This is the approach I'm using.  I think there are also a 
 few people running the headers through an automated tool and then 
 hand-tweaking the output.


 
 I think it depends on the source of the headers and how far you define 
 hand-tweaking. If you use an automated tool you shouldn't use the 
 original m$ headers in any case, because this could violate the 
 intellectual property of m$. It's safer in this case to use the public 
 domain MinGW headers.
 
 On the other hand if someone would (pure hypothetical) use an automated 
 tool on original m$ headers and hand-tweak the result (delete the 
 comments and reformat it, perhaps also rename parameter names), no one 
 could distinguish the result from a pure rewrite from scratch via hand. 
 ...I think this would be in a gray zone.
 

 Because this was the way, the MinGW Team created their header files, 
 I realy see no reason that we couldn't go that way.


 What is your source for this statement?


 
 I really see no other way they could have created their files, if
 reverse engineering is off-limits.


No. They read descriptions of the functions, and used that to work out what
must 
be in the headers. They did not look at the headers.
Sometimes, the documentation they used was wrong, and so there are functions 
which are in different MinGW headers compared to where they are in the MS
headers.

If you have looked at the headers, the new ones could be a derivative work.

MinGW's legal position would be much stronger if they had documented their 
sources. In fact, in general, the quality of the MinGW headers is vastly 
inferior to what Stewart's done with them. Thanks, Stewart.

BTW - about vfw.h, I could be wrong. I just read something about it in the 
Platform API docs. It seems most likely that not all uses of vfw are deprecated.

- Don.
Sep 20 2007
parent reply Sascha Katzner <sorry.no spam.invalid> writes:
Don Clugston wrote:

 Sascha Katzner wrote:

 I really see no other way they could have created their files, if 
 reverse engineering is off-limits.


 
 No. They read descriptions of the functions, and used that to work
 out what must be in the headers. They did not look at the headers. 
 Sometimes, the documentation they used was wrong, and so there are 
 functions which are in different MinGW headers compared to where they
  are in the MS headers.


But header files are only another kind of documentation. IMO there is no 
real difference if someone uses one or the other. The documentation on 
MSDN is also copyrighted AFAIK.

LLAP,
Sascha
Oct 02 2007
parent Don Clugston <dac nospam.com.au> writes:
Sascha Katzner wrote:

 Don Clugston wrote:

 Sascha Katzner wrote:

 I really see no other way they could have created their files, if 
 reverse engineering is off-limits.


 No. They read descriptions of the functions, and used that to work
 out what must be in the headers. They did not look at the headers. 
 Sometimes, the documentation they used was wrong, and so there are 
 functions which are in different MinGW headers compared to where they
  are in the MS headers.


 
 But header files are only another kind of documentation. IMO there is no 
 real difference if someone uses one or the other. 


But the headers are what you are creating!

The documentation on

 MSDN is also copyrighted AFAIK.


Yes, but there are other sources. You can deduce the contents of the headers by 
looking at code which uses it. For example, by looking at the examples in books 
about Windows programming, and knowing that they compile, you can work out what 
the contents of the headers must be.
Somehow, you need to make the new headers an "original work".

BTW, Walter has a license to redistribute the Microsoft headers anyway. So
legal 
issues are probably not a drama in practice.
Oct 04 2007