[Responding to the subject]

I've no idea.  Where did you see that phrase?

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

Charles wrote:
<snip>
> http://hp.vector.co.jp/authors/VA028375/d/windows.h.html
> 
> He seems to have stopped at DMD .95 , probably wouldnt take a whole lot to bring it up to date though .
<snip>

Comprehensive but badly done.

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/17639

I'm still in the process of cleaning it up.  I'll try to post something soon.

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

Don Clugston wrote:
<snip>
> I believe that legal issues prevent redistribution of the Windows SDK, but at least we could use the public domain files from the w32api project?
> 
> http://cvs.sourceforge.net/viewcvs.py/mingw/w32api/#dirlist
<snip>

I'm a little puzzled over the whole licensing issue.  What are these third-party editions of the Windows headers if they're not derivative works of the original?  What are the Windows headers that come with DMC, for that matter?

And how much can we do that counts as fair use, anyway?

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

Stewart Gordon wrote:

> Don Clugston wrote:
> <snip>
>> I believe that legal issues prevent redistribution of the Windows SDK, but at least we could use the public domain files from the w32api project?
>> 
>> http://cvs.sourceforge.net/viewcvs.py/mingw/w32api/#dirlist
> <snip>
> 
> I'm a little puzzled over the whole licensing issue.  What are these third-party editions of the Windows headers if they're not derivative works of the original?  What are the Windows headers that come with DMC, for that matter?
> 
> And how much can we do that counts as fair use, anyway?
> 
> Stewart.
> 

I used to follow the mingw mailinglists once upon a time, and then there was some questions about adding a certain header to the package. It turned out it was just a copy of the MS one, and it was then said that all headers added to the mingw package should be created the black box way or reverseengineered. So in theory, all headers there has been created without looking at the originals, but instead using documentation and test/trials. Thus they don't infringe on the original headers.

In article <du9s34$egk$1@digitaldaemon.com>, Stewart Gordon says...
>
>Don Clugston wrote:
><snip>
>> I believe that legal issues prevent redistribution of the Windows SDK, but at least we could use the public domain files from the w32api project?
>> 
>> http://cvs.sourceforge.net/viewcvs.py/mingw/w32api/#dirlist
><snip>
>
>I'm a little puzzled over the whole licensing issue.

Me, too.

>What are the Windows headers that come with DMC, for that matter?

I think that Walter asked for special permission from Microsoft to do that. For our D ports, I'd rather use a free version that was developed by a black-box method (i.e. mingw) than officially ask for permission from Microsoft to use theirs.

>And how much can we do that counts as fair use, anyway?

I'm not a lawyer, but I think "fair use" requires that we only use a small excerpt (and we basically use all of it even if it's converted by automation). So I don't think we should be using Microsoft's header (even though that's what many of us have been doing. But the legal issues aren't clear to me, so I'm not sure.

jcc7

In article <du9po0$82u$1@digitaldaemon.com>, Don Clugston says...
>
>Sean Kelly wrote:
>> Don Clugston wrote:
>>>
>>> I believe that legal issues prevent redistribution of the Windows SDK, but at least we could use the public domain files from the w32api project?
>>>
>>> http://cvs.sourceforge.net/viewcvs.py/mingw/w32api/#dirlist
>> 
>> Definately.  I don't suppose someone wants to attempt a port? :-) Automation is on my to-do list, but it's pretty low at the moment.
>> 
>> 
>> Sean
>
>I've been inspired to have a go at making a C2D header converter. I know that's been done before, but this one's in D.

Great news!

>Turns out to be _much_ easier to do than it used to be, because now you
>can often change things like
>#define abc 3 + 7 * def
>#define foo "sfbsdd"
>into
>const abc = 3 + 7 * def;
>const foo = "sfbsdd";
>taking advantage of autotyping.

Even better news!

>Also being able to write
>extern(C) :
>
>instead of extern(C) { ....}
>is another huge help.

Please keep us updated on this. I think the D community is really hungry for a C2D program written in D. I know I'd like to have such a tool in my toolbelt.

(I'm sure some things will always need to be converted manually, but whatever can be converted automatically lets the humans save their time for more interesting pursuits.)

jcc7

jcc7 wrote:
>>> Don Clugston wrote:
>> I've been inspired to have a go at making a C2D header converter. I know that's been done before, but this one's in D.

> Please keep us updated on this. I think the D community is really hungry for a
> C2D program written in D. I know I'd like to have such a tool in my toolbelt.

I think this is crucial. We can't possibly maintain D bindings for all the zillions of C libraries out there, if it's being done manually.

> (I'm sure some things will always need to be converted manually, but whatever
> can be converted automatically lets the humans save their time for more
> interesting pursuits.)

I think a 100% automatic conversion is practically impossible, basically because #define is such an ambiguous language construct. eg is
#define FOO 1
defining a constant int? Or is it a flag for a later #ifdef in this file? Or in another file?

My idea is to have a tool that takes a header file and a very short "hints" file, specific to that SDK, which, in an organised format, lists *all* the "manual" changes that need to be made, so that they can be done automatically.
Provided the header file doesn't change radically between releases, it should be possible to use the same hints file to keep D headers up to date with C ones, without any extra work.

It also means that we'd only need to distribute the hints files. Eg, get your copy of the Windows SDK by any legitimate means (eg from your C++ compiler or MSDN subscription). Run c2d on it, with this hint file. Then everyone gets the same files, but without violating licenses.

Don Clugston wrote:
> jcc7 wrote:
>>>> Don Clugston wrote:
>>> I've been inspired to have a go at making a C2D header converter. I know that's been done before, but this one's in D.
> 
>> Please keep us updated on this. I think the D community is really hungry for a
>> C2D program written in D. I know I'd like to have such a tool in my toolbelt.
> 
> I think this is crucial. We can't possibly maintain D bindings for all the zillions of C libraries out there, if it's being done manually.
> 
>> (I'm sure some things will always need to be converted manually, but whatever
>> can be converted automatically lets the humans save their time for more
>> interesting pursuits.)
> 
> I think a 100% automatic conversion is practically impossible, basically because #define is such an ambiguous language construct. eg is
> #define FOO 1
> defining a constant int? Or is it a flag for a later #ifdef in this file? Or in another file?

The most reliable automatic conversion would probably be to feed everything through a C preprocessor and do macro replacement but for #if (which would be converted to static if).  The downside would be numeric literals littered throughout the headers instead of potentially invalid auto declarations.  I suppose there's no perfect solution :-/

> My idea is to have a tool that takes a header file and a very short "hints" file, specific to that SDK, which, in an organised format, lists *all* the "manual" changes that need to be made, so that they can be done automatically.
> Provided the header file doesn't change radically between releases, it should be possible to use the same hints file to keep D headers up to date with C ones, without any extra work.

This sounds like a good idea.  And really, it's not common for headers to change much between releases anyway.


Sean

Sean Kelly wrote:
> Don Clugston wrote:
>> jcc7 wrote:
>>>>> Don Clugston wrote:
>>>> I've been inspired to have a go at making a C2D header converter. I know that's been done before, but this one's in D.
>>
>>> Please keep us updated on this. I think the D community is really hungry for a
>>> C2D program written in D. I know I'd like to have such a tool in my toolbelt.
>>
>> I think this is crucial. We can't possibly maintain D bindings for all the zillions of C libraries out there, if it's being done manually.
>>
>>> (I'm sure some things will always need to be converted manually, but whatever
>>> can be converted automatically lets the humans save their time for more
>>> interesting pursuits.)
>>
>> I think a 100% automatic conversion is practically impossible, basically because #define is such an ambiguous language construct. eg is
>> #define FOO 1
>> defining a constant int? Or is it a flag for a later #ifdef in this file? Or in another file?
> 
> The most reliable automatic conversion would probably be to feed everything through a C preprocessor and do macro replacement but for #if (which would be converted to static if).  The downside would be numeric literals littered throughout the headers instead of potentially invalid auto declarations.  I suppose there's no perfect solution :-/

Unfortunately, the preprocessor solution doesn't always work. Some macros must be expanded, some must not be.
For example, one file I've converted is littered with things like:

#define DAQmx_Val_Rising                      10280

It's never referenced elsewhere in the file. So, if you run it through a preprocessor, it just disappears.
It needs to be converted to:
const DAQmx_Val_Rising = 10280;
(Actually this one really should have been an enum).

Null defines are easy:
#define ABC
this always means ABC will only ever be used in a #ifdef statement, so it should never appear in the file. Unfortunately, sometimes you find
#define ABC 1
even though the value of ABC is never used.
It might be possible to do an initial pass through all header files, trying to work out the purpose of each #define.
It seems to be very easy to deal with the first 95% of cases; probably the last 1% of pathological cases are ten times as difficult as everything else combined.

In article <ducrng$6rc$1@digitaldaemon.com>, Don Clugston says... ..snip...
>I think a 100% automatic conversion is practically impossible, basically
>because #define is such an ambiguous language construct. eg is
>#define FOO 1
>defining a constant int? Or is it a flag for a later #ifdef in this
>file? Or in another file?
>
>My idea is to have a tool that takes a header file and a very short
>"hints" file, specific to that SDK, which, in an organised format, lists
>*all* the "manual" changes that need to be made, so that they can be
>done automatically.
>Provided the header file doesn't change radically between releases, it
>should be possible to use the same hints file to keep D headers up to
>date with C ones, without any extra work.
>
>It also means that we'd only need to distribute the hints files. Eg, get your copy of the Windows SDK by any legitimate means (eg from your C++ compiler or MSDN subscription). Run c2d on it, with this hint file. Then everyone gets the same files, but without violating licenses.

I can see how that'd work. Cool!

jcc7