www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What on earth is std.windows.d?

reply Don Clugston <dac nospam.com.au> writes:
std.windows.d is really bizarre. It has many missing APIs, even some 
from the early days of Windows.
For example, it has GlobalUnlock(), but not GlobalLock().
I found I had to add some function prototypes just so I could copy text 
to the clipboard!
eg, EmptyClipboard(), CloseClipboard() which I suspect date from Windows 
1.0.

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

I realise that anyone doing serious Windows programming is going to want 
the lastest SDK; but unsophisticated users should be able to use D 
out-of-the-box.

Bit of a 1.0 showstopper, I think. There doesn't seem to be much point 
in including a windows.d that is so incomplete. Where did it come from?
It should at least have all the APIs that are over ten years old <g>.
Mar 02 2006
next sibling parent reply Sean Kelly <sean f4.ca> writes:
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
Mar 02 2006
next sibling parent reply Charles <noone nowhere.com> writes:
 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.



Y.Tomino has had automated translation for win32 SDK for some time so 
its probably mature :

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 .





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
Mar 02 2006
next sibling parent reply Don Clugston <dac nospam.com.au> writes:
Charles wrote:

  > 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.
 
 
 Y.Tomino has had automated translation for win32 SDK for some time so 
 its probably mature :
 
 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 .


I've just found that core32 on dsource.org seems to be reawakening; the 
problem with Tomino's code (and also the one used in DWT) is that they 
are using the Windows SDK. That is not legal, AFAIK, so we'll have to 
use the mingw ones instead (at least for anything that's in a standard 
library.

Had a look at the converter -- written in Perl, with comments in 
Japanese. My worst nightmare. <g>

If we're to have D regexps that are good enough to replace scripting 
languages, this is something that has to be done in D...
Mar 02 2006
parent reply bobef <bobef lessequal.com> writes:
Don Clugston wrote:

 Charles wrote:

  > 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.


 Y.Tomino has had automated translation for win32 SDK for some time so 
 its probably mature :

 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 .


 
 I've just found that core32 on dsource.org seems to be reawakening; the 
 problem with Tomino's code (and also the one used in DWT) is that they 
 are using the Windows SDK. That is not legal, AFAIK, so we'll have to 
 use the mingw ones instead (at least for anything that's in a standard 
 library.
 
 Had a look at the converter -- written in Perl, with comments in 
 Japanese. My worst nightmare. <g>
 
 If we're to have D regexps that are good enough to replace scripting 
 languages, this is something that has to be done in D...


What about this - http://int19h.tamb.ru/ ? Is it illegal too?
Mar 02 2006
parent reply jcc7 <jcc7_member pathlink.com> writes:
In article <du77vk$1lcu$1 digitaldaemon.com>, bobef says...

Don Clugston wrote:

 Charles wrote:

  > 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.


 Y.Tomino has had automated translation for win32 SDK for some time so 
 its probably mature :

 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 .


 
 I've just found that core32 on dsource.org seems to be reawakening; the 
 problem with Tomino's code (and also the one used in DWT) is that they 
 are using the Windows SDK. That is not legal, AFAIK, so we'll have to 
 use the mingw ones instead (at least for anything that's in a standard 
 library.
 
 Had a look at the converter -- written in Perl, with comments in 
 Japanese. My worst nightmare. <g>
 
 If we're to have D regexps that are good enough to replace scripting 
 languages, this is something that has to be done in D...


What about this - http://int19h.tamb.ru/ ? Is it illegal too?


I don't think there are any legal problems with DedicateD's headers but Pavel
hasn't updated them since several years ago. And they do need some updating.
Pavel isn't going to do it since he's lost interest in D. Also, Tomino's
project and Core32 have a lot more of the headers covered, but (as has been
pointed out) those projects have legal issues.
Mar 02 2006
parent bobef <bobef lessequal.com> writes:
jcc7 wrote:

 In article <du77vk$1lcu$1 digitaldaemon.com>, bobef says...

 Don Clugston wrote:

 Charles wrote:

  > 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.


 Y.Tomino has had automated translation for win32 SDK for some time so 
 its probably mature :

 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 .


 I've just found that core32 on dsource.org seems to be reawakening; the 
 problem with Tomino's code (and also the one used in DWT) is that they 
 are using the Windows SDK. That is not legal, AFAIK, so we'll have to 
 use the mingw ones instead (at least for anything that's in a standard 
 library.

 Had a look at the converter -- written in Perl, with comments in 
 Japanese. My worst nightmare. <g>

 If we're to have D regexps that are good enough to replace scripting 
 languages, this is something that has to be done in D...


 What about this - http://int19h.tamb.ru/ ? Is it illegal too?


 
 I don't think there are any legal problems with DedicateD's headers but Pavel
hasn't updated them since several years ago. And they do need some updating.
Pavel isn't going to do it since he's lost interest in D. Also, Tomino's
project and Core32 have a lot more of the headers covered, but (as has been
pointed out) those projects have legal issues.


At least they are much more complete that ones that ship with dmd...
Mar 02 2006
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Mar 03 2006
prev sibling parent reply Don Clugston <dac nospam.com.au> writes:
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.
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.

Also being able to write
extern(C) :

instead of extern(C) { ....}
is another huge help.
Mar 03 2006
parent reply jcc7 <jcc7_member pathlink.com> writes:
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
Mar 03 2006
parent reply Don Clugston <dac nospam.com.au> writes:
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.
Mar 04 2006
next sibling parent reply Sean Kelly <sean f4.ca> writes:
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
Mar 04 2006
parent reply Don Clugston <dac nospam.com.au> writes:
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.
Mar 05 2006
parent Georg Wrede <georg.wrede nospam.org> writes:
Don Clugston wrote:

 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.


80-20 is good. 95-5 would be excellent. 99-1 is more than anyone should 
reasonably ask for. 100-0 is just not worth the effort.

But at 95-5, the remaining 5% may often be quite obvious to the astute 
human reader, I hope.

Just as long as the 95% is a correct (but not necessarily the same as a 
human would do) translation, and the remaining 5% is clearly marked.
Mar 07 2006
prev sibling parent jcc7 <jcc7_member pathlink.com> writes:
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
Mar 06 2006
prev sibling next sibling parent AgentOrange <AgentOrange_member pathlink.com> writes:
In article <du6s62$14pi$1 digitaldaemon.com>, Don Clugston says...

std.windows.d is really bizarre. It has many missing APIs, even some 
from the early days of Windows.
For example, it has GlobalUnlock(), but not GlobalLock().
I found I had to add some function prototypes just so I could copy text 
to the clipboard!
eg, EmptyClipboard(), CloseClipboard() which I suspect date from Windows 
1.0.

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

I realise that anyone doing serious Windows programming is going to want 
the lastest SDK; but unsophisticated users should be able to use D 
out-of-the-box.

Bit of a 1.0 showstopper, I think. There doesn't seem to be much point 
in including a windows.d that is so incomplete. Where did it come from?
It should at least have all the APIs that are over ten years old <g>.



Yeah its absolutely horrendous. I would almost prefer NOT to have a win32 api in
phobos than this broken inconsistent crap that doesnt play well with others....
Mar 02 2006
prev sibling next sibling parent jcc7 <jcc7_member pathlink.com> writes:
In article <du6s62$14pi$1 digitaldaemon.com>, Don Clugston says...

std.windows.d is really bizarre. It has many missing APIs, even some 
from the early days of Windows.
For example, it has GlobalUnlock(), but not GlobalLock().
I found I had to add some function prototypes just so I could copy text 
to the clipboard!
eg, EmptyClipboard(), CloseClipboard() which I suspect date from Windows 
1.0.


If Walter's Empire game used these function, I'd bet that Walter would have
included them in std.windows. ;)


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


We should be able to use those. We'd still have to convert them to D, but we
could use them legally. I've thought about working on this, but it'd take a lot
of work. And I haven't been in the mood to start such a large project.


I realise that anyone doing serious Windows programming is going to want 
the lastest SDK; but unsophisticated users should be able to use D 
out-of-the-box.


I agree. We want to make everything as easy as possible for new D users. I don't
even think that an on-going project to add new headers would be as bad as the
first port. But the first "clean" port of the headers is a huge project.


Bit of a 1.0 showstopper, I think. There doesn't seem to be much point 
in including a windows.d that is so incomplete. Where did it come from?
It should at least have all the APIs that are over ten years old <g>.


I'm pretty sure the "randomness" of it comes from Walter adding things that he
wanted to use in examples that he's ported to D. And he has purposely avoided
using automatic translation on Microsoft's headers so that he doesn't violate
MS's copyright.

jcc7
Mar 02 2006
prev sibling next sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
[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.
Mar 03 2006
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Mar 03 2006
next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
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.
Mar 03 2006
prev sibling parent jcc7 <jcc7_member pathlink.com> writes:
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
Mar 03 2006