www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Windows API headers again

reply Stewart Gordon <smjg_1998 yahoo.com> writes:
We've talked about it quite a bit, but not got far.  Has anyone actually 
undertaken the task of translating the Windows API headers into D?

If not, I hereby propose we get started on it now!  We can do this as a 
team effort, with each member translating one or more of the Windows .h 
files.  I suggest we proceed as follows:

1. Decide on some rules.  I have some ideas for rules, as well as a few 
open issues in this respect, which I'll post a bit later (assuming I'm 
going to get some interest in this project).

2. Set up a page on Wiki4D for the project, which would enable 
individuals to 'take' individual modules that they're going to work on.

3. Find somewhere to keep the translated modules for the time being. 
Maybe dsource?

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Jan 28 2005
next sibling parent reply zwang <nehzgnaw gmail.com> writes:
Stewart Gordon wrote:

 We've talked about it quite a bit, but not got far.  Has anyone actually 
 undertaken the task of translating the Windows API headers into D?
 
 If not, I hereby propose we get started on it now!  We can do this as a 
 team effort, with each member translating one or more of the Windows .h 
 files.  I suggest we proceed as follows:
 
 1. Decide on some rules.  I have some ideas for rules, as well as a few 
 open issues in this respect, which I'll post a bit later (assuming I'm 
 going to get some interest in this project).
 
 2. Set up a page on Wiki4D for the project, which would enable 
 individuals to 'take' individual modules that they're going to work on.
 
 3. Find somewhere to keep the translated modules for the time being. 
 Maybe dsource?
 
 Stewart.
 


Can't we just resort to a tool like h2d?
Jan 28 2005
next sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
zwang wrote:
<snip excessive quote>

 Can't we just resort to a tool like h2d?


Oh, I hadn't realised that someone had actually undertaken to write h2d. 
  It must've slipped through my reading.

In any case, I doubt we can *just* resort to it.  We'd need to deal with 
the FIXME comments, and the output could probably do with some tidying 
anyway.  That's before you consider the other possible inadequacies of 
such a tool....

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Jan 28 2005
prev sibling parent reply Vathix <vathix dprogramming.com> writes:
 Can't we just resort to a tool like h2d?


But wouldn't the output be owned by Microsoft still and we'd need their  
permission to distribute it?
Jan 28 2005
next sibling parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Vathix" <vathix dprogramming.com> wrote in message 
news:opslbh4lsfkcck4r esi...

 Can't we just resort to a tool like h2d?


 But wouldn't the output be owned by Microsoft still and we'd need their 
 permission to distribute it?


I've been wondering about that, too. The header file for winuser.h says "all 
rights reserved". So does that mean we can or can't run it through a 
translator and distribute the result? I don't know. IANAL but by reserving 
all rights and not saying we can do anything I take it that means we can't 
do anything without their permission.
I've never liked putting restrictions on header files - it seems 
counter-productive.

-Ben
Jan 28 2005
parent bobef <bobef_member pathlink.com> writes:
What about mingw headers?

In article <ctdkid$2p5o$1 digitaldaemon.com>, Ben Hinkle says...

"Vathix" <vathix dprogramming.com> wrote in message 
news:opslbh4lsfkcck4r esi...

 Can't we just resort to a tool like h2d?


 But wouldn't the output be owned by Microsoft still and we'd need their 
 permission to distribute it?


I've been wondering about that, too. The header file for winuser.h says "all 
rights reserved". So does that mean we can or can't run it through a 
translator and distribute the result? I don't know. IANAL but by reserving 
all rights and not saying we can do anything I take it that means we can't 
do anything without their permission.
I've never liked putting restrictions on header files - it seems 
counter-productive.

-Ben
Jan 28 2005
prev sibling parent J C Calvarese <jcc7 cox.net> writes:
In article <opslbh4lsfkcck4r esi>, Vathix says...

 Can't we just resort to a tool like h2d?


But wouldn't the output be owned by Microsoft still and we'd need their  
permission to distribute it?


I think you're right, but we should be able to get around that by using MinGW's
(http://www.mingw.org/) public domain headers for Windows.

We've discussed this earlier at dsource, but I haven't gotten around to doing


jcc7
Jan 28 2005
prev sibling next sibling parent reply J C Calvarese <jcc7 cox.net> writes:
In article <ctdc6n$2e4l$1 digitaldaemon.com>, Stewart Gordon says...

We've talked about it quite a bit, but not got far.  Has anyone actually 
undertaken the task of translating the Windows API headers into D?


Yes. More than one person, in fact.

For example:
http://hp.vector.co.jp/authors/VA028375/d/windows.h.html


If not, I hereby propose we get started on it now!  We can do this as a 
team effort, with each member translating one or more of the Windows .h 
files.  I suggest we proceed as follows:

1. Decide on some rules.  I have some ideas for rules, as well as a few 
open issues in this respect, which I'll post a bit later (assuming I'm 
going to get some interest in this project).


I've heard there's some header-to-D programs out there. We should probably make
use of some of those.



2. Set up a page on Wiki4D for the project, which would enable 
individuals to 'take' individual modules that they're going to work on.

3. Find somewhere to keep the translated modules for the time being. 
Maybe dsource?


Kind of like http://www.dsource.org/projects/core32/?


Stewart.


jcc7
Jan 28 2005
next sibling parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
3. Find somewhere to keep the translated modules for the time being.
Maybe dsource?


 Kind of like http://www.dsource.org/projects/core32/?


What's the state of that project? I think it makes sense to try to make that 
one the "standard".

-Ben
Jan 28 2005
parent J C Calvarese <jcc7 cox.net> writes:
In article <ctdhkt$2lf3$1 digitaldaemon.com>, Ben Hinkle says...

3. Find somewhere to keep the translated modules for the time being.
Maybe dsource?


 Kind of like http://www.dsource.org/projects/core32/?


What's the state of that project? I think it makes sense to try to make that 
one the "standard".

-Ben 


Last time that I checked, everything compiles, and it works as far as I know.
Mike Wynn (ak/a One_mad_alien, a/k/a l8night) started the project and has done
the vast majority of the work. I haven't heard from in the a while. It's
possible he's lost interest in D or just doesn't have the time to play with it.

I've become the maintainer of the Core32 and L8night (GUI library) projects, so
I can fix what's easy to fix. I haven't done much. A little change to get it to
compile here, a little change to prevent a conflict with Phobos's Windows
headers here. Not much. Not all of the headers have been converted, but I think
the most popular ones are there.

There might be a problem with copyright issues though. I suspect the files were
directly converted from Microsoft's headers. The only way to eliminate this
problem for sure would be to start over from scratch. (What fun!) We might be
able get pretty far by running MinGW's (http://www.mingw.org/) public domain
headers through H2D-type program. I might be able to help out someone else a
little, but I don't really have time to redo the whole project presently.

jcc7
Jan 28 2005
prev sibling next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
J C Calvarese wrote:

 In article <ctdc6n$2e4l$1 digitaldaemon.com>, Stewart Gordon says...
 

 We've talked about it quite a bit, but not got far.  Has anyone actually 
 undertaken the task of translating the Windows API headers into D?


 
 Yes. More than one person, in fact.
 
 For example:
 http://hp.vector.co.jp/authors/VA028375/d/windows.h.html


Just looking at it (with the aid of Google's translator):

1. It's been compressed in an obscure format I'll have to investigate. 
And then evaluate it once that's done.

2. Does anyone have any guesses of what the W and A columns mean?

3. What's with some of them being labelled as "Never"?  Are they beyond 
the scope of this particular project just because they're not in the 
include tree from windows.h?

<snip>

 Kind of like http://www.dsource.org/projects/core32/?


Just looked at this one.  Not bad, but I guess it could be cleaned up a 
bit.  And why is the WNDPROC definition commented out?  And what is 
version(STANDALONE) about?

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Jan 28 2005
next sibling parent J C Calvarese <jcc7 cox.net> writes:
In article <ctdk6d$2ols$1 digitaldaemon.com>, Stewart Gordon says...

J C Calvarese wrote:

 In article <ctdc6n$2e4l$1 digitaldaemon.com>, Stewart Gordon says...
 

 We've talked about it quite a bit, but not got far.  Has anyone actually 
 undertaken the task of translating the Windows API headers into D?


 
 Yes. More than one person, in fact.
 
 For example:
 http://hp.vector.co.jp/authors/VA028375/d/windows.h.html


Just looking at it (with the aid of Google's translator):

1. It's been compressed in an obscure format I'll have to investigate. 
And then evaluate it once that's done.


I guess he's still using 7-Zip (http://www.7-zip.org/) for archiving. I use it
all the time (they compress pretty well), but I usually don't upload it to
websites. 


2. Does anyone have any guesses of what the W and A columns mean?


I think it's something like Wide (2-byte UNICODE) and ANSI (or ASCII?). I've
never quite understood that convention.


3. What's with some of them being labelled as "Never"?  Are they beyond 
the scope of this particular project just because they're not in the 
include tree from windows.h?


I don't think he plans on converting everything. "Never" would be a file he
doesn't want to convert.


<snip>

 Kind of like http://www.dsource.org/projects/core32/?


Just looked at this one.  Not bad, but I guess it could be cleaned up a 
bit.  And why is the WNDPROC definition commented out?  And what is 
version(STANDALONE) about?


These are some very tedious files. They can always be cleaned up a bit. Ad
infinitum.

I don't know about the WNDPROC issue. It was probably commented out for a
reason. I'm sure it can be commented back in (but it should probably be
versioned out then).

Someone would compile with version(STANDALONE) if they don't want to import
std.c.windows.windows.

The default (compiling without STANDALONE set) has many of the conflicts with
Phobos versioned out. (When I find a conflict, I go into the code and add a
version(STANDALONE).)


Stewart.


jcc7
Jan 28 2005
prev sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
 http://hp.vector.co.jp/authors/VA028375/d/windows.h.html




I use these headers all the time with very few problems.  They're far more 
complete than the windows header that comes with D, and at the most, they 
only need to be updated to add in some casts where needed and whatnot.
Jan 28 2005
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
J C Calvarese wrote:
<snip>

 For example:
 http://hp.vector.co.jp/authors/VA028375/d/windows.h.html


<snip>

I finally got around to checking this out over the weekend.  It seems a 
decent effort, but I noticed a few quirks:

1. It's far from complete, if the DMC collection of Windows headers is 
anything to go by.

2. There are many enum blocks defining just a single constant.  How 
about grouping these by what set of constants they belong to?

3. State-of-the-art as the compression algorithm may be, the download 
could've been made even smaller if it weren't for the amount of 
commented-out C code and the complete duplication for ANSI and Unicode 
versions (was there any problem with using a version block for this?)

4. String constants are defined twice, in direct mimic of the C headers. 
  Where we have

     const char[] WC_TREEVIEWA = "SysTreeView32";
     const wchar[] WC_TREEVIEWW = "SysTreeView32";
     alias WC_TREEVIEWA WC_TREEVIEW;

it can be reduced to

     const TCHAR[] WC_TREEVIEW = "SysTreeView32";

Strangely, this shorter form has been used one-off for DRAGLISTMSGSTRING.

All this duplication does is enables both forms of CreateWindow(Ex) to 
be called in the course of a program using these constants.  But is 
there any real point in doing this?  And even if you do want to mix the 
forms, can't you just use the string literals directly?  (On second 
thoughts, would this be portable to Win64?)

OTOH, I can't see any point in mixing the A and W forms of 
RegisterWindowMessage, and so constants of this sort (of which there are 
several in commdlg) certainly might as well be defined just once.

5. Many structs have their own size as the first member.  How about 
using member initialisers here?  The only limitation is that one'll have 
to be careful if switching between Windows header translations.  But 
once we have a translation incorporated into Phobos, this'll pretty much 
become irrelevant.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Feb 28 2005
next sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Stewart Gordon wrote:
<snip>

 I finally got around to checking this out over the weekend.  It seems a 
 decent effort, but I noticed a few quirks:


<snip>

6. I noticed a function IsEqualGUID.  This didn't seem to exist in the 
standard Windows API when I looked at the files on my machine, but the 
MSDN site claims it exists.  The translation implements this function 
from scratch, effectively viewing the structure as a uint[4] and 
comparing the uints one by one.  If we really need to reimplement a 
function that's redundant with D's built in == on structs, why not 
implement it in terms of this?

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Feb 28 2005
prev sibling parent reply "John C" <johnch_atms hotmail.com> writes:
One thing I don't like with these ports of the Windows SDK headers is the 
many aliases for basic types - eg, typedef long LONG, typedef LONG LONG_PTR, 
typedef LONG_PTR LRESULT. Not only does it look ugly (all those caps 
screaming off the screen), it's also confusing and misleading in D. It may 
be fine in C/C++ -- many of these are a hangover from the 16-bit days when 
WPARAM was an unsigned short (I think) or WORD, so the "W" made sense, but 
it's an unsigned int now. Even worse, LRESULT is a 32-bit long in C (hence 
the "L" prefix) but a long is 64 bits in D.

There are already plenty of basic types in D to remember, so why add this 
layer of obfuscation? I also note that the D style guide 
(http://www.digitalmars.com/d/dstyle.html) discourages the practice; that 
said, the header translations in Phobos ignore the guideline.

Which is more readable/understandable?

    extern (Windows) LRESULT windowCallback(HWND hWnd, UINT uMsg, WPARAM 
wParam, LPARAM lParam)

or

    typedef void* Handle = (void*)0; // a typedef, but a useful one
    extern (Windows) int windowCallback(Handle handle, uint message, uint 
param1, int param2)

(Another thing: how I wish we could wrap callbacks in delegates without 
proxy classes.)

John.

"Stewart Gordon" <smjg_1998 yahoo.com> wrote in message 
news:cvv081$2gpf$1 digitaldaemon.com...

J C Calvarese wrote:
 <snip>

 For example:
 http://hp.vector.co.jp/authors/VA028375/d/windows.h.html


 <snip>

 I finally got around to checking this out over the weekend.  It seems a 
 decent effort, but I noticed a few quirks:

 1. It's far from complete, if the DMC collection of Windows headers is 
 anything to go by.

 2. There are many enum blocks defining just a single constant.  How about 
 grouping these by what set of constants they belong to?

 3. State-of-the-art as the compression algorithm may be, the download 
 could've been made even smaller if it weren't for the amount of 
 commented-out C code and the complete duplication for ANSI and Unicode 
 versions (was there any problem with using a version block for this?)

 4. String constants are defined twice, in direct mimic of the C headers. 
 Where we have

     const char[] WC_TREEVIEWA = "SysTreeView32";
     const wchar[] WC_TREEVIEWW = "SysTreeView32";
     alias WC_TREEVIEWA WC_TREEVIEW;

 it can be reduced to

     const TCHAR[] WC_TREEVIEW = "SysTreeView32";

 Strangely, this shorter form has been used one-off for DRAGLISTMSGSTRING.

 All this duplication does is enables both forms of CreateWindow(Ex) to be 
 called in the course of a program using these constants.  But is there any 
 real point in doing this?  And even if you do want to mix the forms, can't 
 you just use the string literals directly?  (On second thoughts, would 
 this be portable to Win64?)

 OTOH, I can't see any point in mixing the A and W forms of 
 RegisterWindowMessage, and so constants of this sort (of which there are 
 several in commdlg) certainly might as well be defined just once.

 5. Many structs have their own size as the first member.  How about using 
 member initialisers here?  The only limitation is that one'll have to be 
 careful if switching between Windows header translations.  But once we 
 have a translation incorporated into Phobos, this'll pretty much become 
 irrelevant.

 Stewart.

 -- 
 My e-mail is valid but not my primary mailbox.  Please keep replies on the 
 'group where everyone may benefit.
Feb 28 2005
next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
John C wrote:

 One thing I don't like with these ports of the Windows SDK headers is the 
 many aliases for basic types - eg, typedef long LONG, typedef LONG LONG_PTR, 
 typedef LONG_PTR LRESULT. Not only does it look ugly (all those caps 
 screaming off the screen), it's also confusing and misleading in D. It may 
 be fine in C/C++ -- many of these are a hangover from the 16-bit days when 
 WPARAM was an unsigned short (I think) or WORD, so the "W" made sense, but 
 it's an unsigned int now. Even worse, LRESULT is a 32-bit long in C (hence 
 the "L" prefix) but a long is 64 bits in D.


Yes, I'm made to wonder why the Windows API needs so many meaningless 
type aliases.  My guess is that M$ was trying to come up with a 
cross-language set of type names.


 There are already plenty of basic types in D to remember, so why add this 
 layer of obfuscation? I also note that the D style guide 
 (http://www.digitalmars.com/d/dstyle.html) discourages the practice; that 
 said, the header translations in Phobos ignore the guideline.


Indeed.  I did mention this briefly (see my reply to Mark T on this 
thread), but there was no comment.  I'm inclined to agree - we D 
programmers are comfortable with D type names, so we should use them.  I 
use D type names rather than these aliases throughout SDWF.


 Which is more readable/understandable?
 
     extern (Windows) LRESULT windowCallback(HWND hWnd, UINT uMsg, WPARAM 
 wParam, LPARAM lParam)
 
 or
 
     typedef void* Handle = (void*)0; // a typedef, but a useful one
     extern (Windows) int windowCallback(Handle handle, uint message, uint 
 param1, int param2)


I think we both agree on this.


 (Another thing: how I wish we could wrap callbacks in delegates without 
 proxy classes.)


<snip top of upside-down reply>

What do you mean by this?

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Feb 28 2005
next sibling parent reply "John C" <johnch_atms hotmail.com> writes:
"Stewart Gordon" <smjg_1998 yahoo.com> wrote in message 
news:cvvl9a$776$1 digitaldaemon.com...

 John C wrote:

 One thing I don't like with these ports of the Windows SDK headers is the 
 many aliases for basic types - eg, typedef long LONG, typedef LONG 
 LONG_PTR, typedef LONG_PTR LRESULT. Not only does it look ugly (all those 
 caps screaming off the screen), it's also confusing and misleading in D. 
 It may be fine in C/C++ -- many of these are a hangover from the 16-bit 
 days when WPARAM was an unsigned short (I think) or WORD, so the "W" made 
 sense, but it's an unsigned int now. Even worse, LRESULT is a 32-bit long 
 in C (hence the "L" prefix) but a long is 64 bits in D.


 Yes, I'm made to wonder why the Windows API needs so many meaningless type 
 aliases.  My guess is that M$ was trying to come up with a cross-language 
 set of type names.


 There are already plenty of basic types in D to remember, so why add this 
 layer of obfuscation? I also note that the D style guide 
 (http://www.digitalmars.com/d/dstyle.html) discourages the practice; that 
 said, the header translations in Phobos ignore the guideline.


 Indeed.  I did mention this briefly (see my reply to Mark T on this 
 thread), but there was no comment.  I'm inclined to agree - we D 
 programmers are comfortable with D type names, so we should use them.  I 
 use D type names rather than these aliases throughout SDWF.


 Which is more readable/understandable?

     extern (Windows) LRESULT windowCallback(HWND hWnd, UINT uMsg, WPARAM 
 wParam, LPARAM lParam)

 or

     typedef void* Handle = (void*)0; // a typedef, but a useful one
     extern (Windows) int windowCallback(Handle handle, uint message, uint 
 param1, int param2)


 I think we both agree on this.


 (Another thing: how I wish we could wrap callbacks in delegates without 
 proxy classes.)


 <snip top of upside-down reply>

 What do you mean by this?


Simply that there were some way for function pointers (including those 
requiring an extern attribute, such as callbacks) and delegates to be used 
interchangably. The workaround I've adopted is to encapsulate both the 
callback and the delegate in a template class. I'm not sure it's a good 
design, since the delegate needs to be static, so perhaps it can be improved 
upon:

class Callback(R, T1, T2, T3, T4) {

  private alias R delegate(T1, T2, T3, T4) Method;
  private extern (Windows) alias R function(T1, T2, T3, T4) Function;

  public this(Method method) {
    method_ = method;
  }

  public Function opCast() {
    return &callback;
  }

  public static extern (Windows) R callback(T1 arg1, T2 arg2, T3 arg3, T4 
arg4) {
    return method_(arg1, arg2, arg3, arg4);
  }

  private static Method method_;

};

alias Callback!(int, Handle, uint, uint, int) WndProc;

class Control {

  void registerClass() {
    WNDCLASS wc;
    wc.lpfnWndProc = (WNDPROC)(new WndProc(&windowProc));
  }

  private int windowProc(Handle handle, uint message, uint param1, int 
param2) {
    // Now I have access to the class's non-static members. Hurrah.
    ...
  }
}
Feb 28 2005
next sibling parent "John C" <johnch_atms hotmail.com> writes:
"John C" <johnch_atms hotmail.com> wrote in message 
news:cvvnj1$9ic$1 digitaldaemon.com...

 "Stewart Gordon" <smjg_1998 yahoo.com> wrote in message 
 news:cvvl9a$776$1 digitaldaemon.com...

 John C wrote:

 One thing I don't like with these ports of the Windows SDK headers is 
 the many aliases for basic types - eg, typedef long LONG, typedef LONG 
 LONG_PTR, typedef LONG_PTR LRESULT. Not only does it look ugly (all 
 those caps screaming off the screen), it's also confusing and misleading 
 in D. It may be fine in C/C++ -- many of these are a hangover from the 
 16-bit days when WPARAM was an unsigned short (I think) or WORD, so the 
 "W" made sense, but it's an unsigned int now. Even worse, LRESULT is a 
 32-bit long in C (hence the "L" prefix) but a long is 64 bits in D.


 Yes, I'm made to wonder why the Windows API needs so many meaningless 
 type aliases.  My guess is that M$ was trying to come up with a 
 cross-language set of type names.


 There are already plenty of basic types in D to remember, so why add 
 this layer of obfuscation? I also note that the D style guide 
 (http://www.digitalmars.com/d/dstyle.html) discourages the practice; 
 that said, the header translations in Phobos ignore the guideline.


 Indeed.  I did mention this briefly (see my reply to Mark T on this 
 thread), but there was no comment.  I'm inclined to agree - we D 
 programmers are comfortable with D type names, so we should use them.  I 
 use D type names rather than these aliases throughout SDWF.


 Which is more readable/understandable?

     extern (Windows) LRESULT windowCallback(HWND hWnd, UINT uMsg, WPARAM 
 wParam, LPARAM lParam)

 or

     typedef void* Handle = (void*)0; // a typedef, but a useful one
     extern (Windows) int windowCallback(Handle handle, uint message, 
 uint param1, int param2)


 I think we both agree on this.


 (Another thing: how I wish we could wrap callbacks in delegates without 
 proxy classes.)


 <snip top of upside-down reply>

 What do you mean by this?


 Simply that there were some way for function pointers (including those 
 requiring an extern attribute, such as callbacks) and delegates to be used 
 interchangably. The workaround I've adopted is to encapsulate both the 
 callback and the delegate in a template class. I'm not sure it's a good 
 design, since the delegate needs to be static, so perhaps it can be 
 improved upon:

 class Callback(R, T1, T2, T3, T4) {

  private alias R delegate(T1, T2, T3, T4) Method;
  private extern (Windows) alias R function(T1, T2, T3, T4) Function;

  public this(Method method) {
    method_ = method;
  }

  public Function opCast() {
    return &callback;
  }

  public static extern (Windows) R callback(T1 arg1, T2 arg2, T3 arg3, T4 
 arg4) {
    return method_(arg1, arg2, arg3, arg4);
  }

  private static Method method_;

 };

 alias Callback!(int, Handle, uint, uint, int) WndProc;

 class Control {

  void registerClass() {
    WNDCLASS wc;
    wc.lpfnWndProc = (WNDPROC)(new WndProc(&windowProc));
  }

  private int windowProc(Handle handle, uint message, uint param1, int 
 param2) {
    // Now I have access to the class's non-static members. Hurrah.
    ...
  }
 }


Talking of templates, I'd love to be able to use an alternative syntax for 
specifying arguments:

  // C++ version, separates out return type and function arguments
  typedef Callback<int (Handle, uint, uint, int)> WndProc;

  // possible D version, although looks unweildy
  alias Callback!(int (Handle, uint, uint, int)) WndProc;
Feb 28 2005
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
John C wrote:
<snip>

 (Another thing: how I wish we could wrap callbacks in delegates without 
 proxy classes.)


 
 <snip top of upside-down reply>
 
 What do you mean by this?


 
 Simply that there were some way for function pointers (including those 
 requiring an extern attribute, such as callbacks) and delegates to be used 
 interchangably. The workaround I've adopted is to encapsulate both the 
 callback and the delegate in a template class. I'm not sure it's a good 
 design, since the delegate needs to be static, so perhaps it can be improved 
 upon:


<snip>

The problem is that a delegate consists of two pieces of information: 
the function pointer and the 'this' pointer.  C-based APIs such as the 
Windows API cannot use delegates, at least directly.  To pass in a 
delegate where a function pointer is expected would mean losing the 
'this' pointer, and consequently the external API cannot call the function.

Your hack would work only if throughout your program, you use only one 
delegate per function signature as a callback.  But if that's so, 
there's a simpler hack still: have a global variable referencing the 
object on which it is called, and define a function that simply calls 
that method of this object.  This approach also makes it possible to do 
a small, defined number of delegates with the same signature.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Mar 01 2005
prev sibling parent reply "Rob Grainger" <nospam nospam.com> writes:
Hi folks,

As a D newbie, but experience Windows developer, I though these comments may 
be worth considering...


 One thing I don't like with these ports of the Windows SDK headers is the 
 many aliases for basic types - eg, typedef long LONG, typedef LONG 
 LONG_PTR, typedef LONG_PTR LRESULT. Not only does it look ugly (all those 
 caps screaming off the screen), it's also confusing and misleading in D. 
 It may be fine in C/C++ -- many of these are a hangover from the 16-bit 
 days when WPARAM was an unsigned short (I think) or WORD, so the "W" made 
 sense, but it's an unsigned int now. Even worse, LRESULT is a 32-bit long 
 in C (hence the "L" prefix) but a long is 64 bits in D.




Here, there is actually a semantic difference. A LONG is a 32-bit value, 
easy enough.
LONG_PTR however was introduced with Win64 and varies to be a 32-bit or 
64-bit
number depending on platform, basically a LONG that is guaranteed big enough 
to hold
a pointer. Allowing for the fact that API styles frequently require you to 
pass a pointer as
a LPARAM-type value (also pointer-sized), this makes a lot of sense actually


 Yes, I'm made to wonder why the Windows API needs so many meaningless type 
 aliases.  My guess is that M$ was trying to come up with a cross-language 
 set of type names.


Again, the purpose here is not to be cross-language (these kind of names 
never made an
appearance in VB), but to support C compilers where the basic types have 
different sizes
(a rare occurence on Windows, but theoretically possible) - all such a 
compiler-vendor
would need to do is define a few thousand typedef's appropiately (that was 
sarcasm).


 There are already plenty of basic types in D to remember, so why add this 
 layer of obfuscation? I also note that the D style guide 
 (http://www.digitalmars.com/d/dstyle.html) discourages the practice; that 
 said, the header translations in Phobos ignore the guideline.


 Indeed.  I did mention this briefly (see my reply to Mark T on this 
 thread), but there was no comment.  I'm inclined to agree - we D 
 programmers are comfortable with D type names, so we should use them.  I 
 use D type names rather than these aliases throughout SDWF.


Must confess, I'm new to D, and so far impressed with what I see. However, I 
am definintely
not new to Windows API programming, been doing that since Windows 2.0, and 
from that
perspective having the Windows typenames available makes a lot of sense - 
otherwise you end
in the VB scenario of looking up something in the platform API, working what 
'D' type to use for
the appropriate function - I'd much prefer a predictable mapping.


 Which is more readable/understandable?

     extern (Windows) LRESULT windowCallback(HWND hWnd, UINT uMsg, WPARAM 
 wParam, LPARAM lParam)

 or

     typedef void* Handle = (void*)0; // a typedef, but a useful one
     extern (Windows) int windowCallback(Handle handle, uint message, uint 
 param1, int param2)


 I think we both agree on this.


Me too, but think it would slow down a lot of Windows developers (myself 
included).

Hope these comments are useful - at least worth a moments consideration.

Rob
Mar 01 2005
next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Wed, 2 Mar 2005 02:21:51 -0000, Rob Grainger <nospam nospam.com> wrote:

 Again, the purpose here is not to be cross-language (these kind of names
 never made an
 appearance in VB), but to support C compilers where the basic types have
 different sizes
 (a rare occurence on Windows, but theoretically possible) - all such a
 compiler-vendor
 would need to do is define a few thousand typedef's appropiately (that  
 was
 sarcasm).


Ok, so given that D does not have different sized basic types, but fixed  
sized basic types, what do you recommend we do here?

I believe the point you were making is that on some systems pointers are  
32bit, and others 64bit, and you need a type that will definately hold a  
pointer.

D can do this with typedef, or alias, eg.

version(32bit) {
   typedef ptr_t uint
}
version(64bit) {
   typedef ptr_t ulong
}

or similar. What do you think?

Regan
Mar 01 2005
next sibling parent reply "Rob Grainger" <nospam nospam.com> writes:
Regan,

Yes, that's exactly the approach I'd recommend. Closest in concept to the 
Win32 approach, so
more familiar to Win API programmers.

Rob

"Regan Heath" <regan netwin.co.nz> wrote in message 
news:opsmzpakfh23k2f5 ally...

 On Wed, 2 Mar 2005 02:21:51 -0000, Rob Grainger <nospam nospam.com> wrote:

 Again, the purpose here is not to be cross-language (these kind of names
 never made an
 appearance in VB), but to support C compilers where the basic types have
 different sizes
 (a rare occurence on Windows, but theoretically possible) - all such a
 compiler-vendor
 would need to do is define a few thousand typedef's appropiately (that 
 was
 sarcasm).


 Ok, so given that D does not have different sized basic types, but fixed 
 sized basic types, what do you recommend we do here?

 I believe the point you were making is that on some systems pointers are 
 32bit, and others 64bit, and you need a type that will definately hold a 
 pointer.

 D can do this with typedef, or alias, eg.

 version(32bit) {
   typedef ptr_t uint
 }
 version(64bit) {
   typedef ptr_t ulong
 }

 or similar. What do you think?

 Regan
Mar 01 2005
parent reply "Rob Grainger" <nospam nospam.com> writes:
Regan,

As a brief postscript, I do like the increased type safety typedef gives - 
its
always annoyed me in C++ not being able to overload on different typedef's.

As long as there no interactions at ABI level to prevent this, making alias
a better choice.

Rob

"Rob Grainger" <nospam nospam.com> wrote in message 
news:d03ah5$1jl1$1 digitaldaemon.com...

 Regan,

 Yes, that's exactly the approach I'd recommend. Closest in concept to the 
 Win32 approach, so
 more familiar to Win API programmers.

 Rob

 "Regan Heath" <regan netwin.co.nz> wrote in message 
 news:opsmzpakfh23k2f5 ally...

 On Wed, 2 Mar 2005 02:21:51 -0000, Rob Grainger <nospam nospam.com> 
 wrote:

 Again, the purpose here is not to be cross-language (these kind of names
 never made an
 appearance in VB), but to support C compilers where the basic types have
 different sizes
 (a rare occurence on Windows, but theoretically possible) - all such a
 compiler-vendor
 would need to do is define a few thousand typedef's appropiately (that 
 was
 sarcasm).


 Ok, so given that D does not have different sized basic types, but fixed 
 sized basic types, what do you recommend we do here?

 I believe the point you were making is that on some systems pointers are 
 32bit, and others 64bit, and you need a type that will definately hold a 
 pointer.

 D can do this with typedef, or alias, eg.

 version(32bit) {
   typedef ptr_t uint
 }
 version(64bit) {
   typedef ptr_t ulong
 }

 or similar. What do you think?

 Regan
Mar 01 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Rob Grainger" <nospam nospam.com> wrote in message 
news:d03bmk$1khd$1 digitaldaemon.com...

 Regan,

 As a brief postscript, I do like the increased type safety typedef 
 gives - its
 always annoyed me in C++ not being able to overload on different 
 typedef's.


You can, with True Typedefs. (Chapter 14 of Imperfect C++). <g>



 As long as there no interactions at ABI level to prevent this, making 
 alias
 a better choice.


Walter's said many times in the last few years that this approach is 
unmanageable, yet it's brought me nothing but goodness. Go figure!
Mar 01 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Matthew wrote:


As a brief postscript, I do like the increased type safety typedef 
gives - its
always annoyed me in C++ not being able to overload on different 
typedef's.


 
 You can, with True Typedefs. (Chapter 14 of Imperfect C++). <g>


That does it! ;-)

Now it seems like there is *no* alternative but to fork out
the $60 that the local bookstore wants for it, or this will
just never stop... (Might as well get DDJ for $20, as well,
so that I can read Walter's and Matthew's articles in it ?)

http://isbn.nu/0321228774

--anders
Mar 02 2005
next sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
Anders F Björklund wrote:

 Matthew wrote:
 

 As a brief postscript, I do like the increased type safety typedef 
 gives - its
 always annoyed me in C++ not being able to overload on different 
 typedef's.



 You can, with True Typedefs. (Chapter 14 of Imperfect C++). <g>


 
 
 That does it! ;-)
 
 Now it seems like there is *no* alternative but to fork out
 the $60 that the local bookstore wants for it, or this will
 just never stop... (Might as well get DDJ for $20, as well,
 so that I can read Walter's and Matthew's articles in it ?)
 
 http://isbn.nu/0321228774


If you only had money for a single magazine subscription, then I'd say 
DDJ is it!
Mar 02 2005
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Georg Wrede wrote:


 If you only had money for a single magazine subscription, then I'd say 
 DDJ is it!


I got it... So far DDJ is $10 per article read, but that's about
the usual rate from when I used to buy it on the magazine stand. :-)

Shipping paper to us europeans just isn't very cost-effective...
I actually got all of DDJ, Software Development mag and CUJ now!


"The D Programming Language"
http://www.ddj.com/documents/ddj0202c/

"printf Revisited"
http://www.ddj.com/documents/ddj0501e/


So now I know some more about Walter's decisions behind D and writef.
Too bad I can't share or discuss with the rest of you, due to ©...

I guess the upcoming book will have a similar problem, unless we all
sign up for it in advance and get a private chatroom or something ?

--anders
Mar 02 2005
prev sibling parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Anders F Björklund" <afb algonet.se> wrote in message 
news:d0419i$2aeg$1 digitaldaemon.com...

 Matthew wrote:


As a brief postscript, I do like the increased type safety typedef 
gives - its
always annoyed me in C++ not being able to overload on different 
typedef's.


 You can, with True Typedefs. (Chapter 14 of Imperfect C++). <g>


 That does it! ;-)

 Now it seems like there is *no* alternative but to fork out
 the $60 that the local bookstore wants for it, or this will
 just never stop... (Might as well get DDJ for $20, as well,
 so that I can read Walter's and Matthew's articles in it ?)

 http://isbn.nu/0321228774


What an excellent idea. May I recommend that everyone goes out and buy 
it? <CG>
Mar 02 2005
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Wed, 02 Mar 2005 16:00:10 +1300, Regan Heath wrote:


 On Wed, 2 Mar 2005 02:21:51 -0000, Rob Grainger <nospam nospam.com> wrote:

 Again, the purpose here is not to be cross-language (these kind of names
 never made an
 appearance in VB), but to support C compilers where the basic types have
 different sizes
 (a rare occurence on Windows, but theoretically possible) - all such a
 compiler-vendor
 would need to do is define a few thousand typedef's appropiately (that  
 was
 sarcasm).


 
 Ok, so given that D does not have different sized basic types, but fixed  
 sized basic types, what do you recommend we do here?
 
 I believe the point you were making is that on some systems pointers are  
 32bit, and others 64bit, and you need a type that will definately hold a  
 pointer.
 
 D can do this with typedef, or alias, eg.
 
 version(32bit) {
    typedef ptr_t uint
 }
 version(64bit) {
    typedef ptr_t ulong
 }
 
 or similar. What do you think?
 
 Regan


Just letting you know that in object.d we already have ...

version (AMD64)
{
    alias ulong size_t;
    alias long ptrdiff_t;
}
else version (X86)
{
    alias uint size_t;
    alias int ptrdiff_t;
}

Which probably means all you need to do is ...

  alias size_t ptr_t;

-- 
Derek
Melbourne, Australia
2/03/2005 2:26:46 PM
Mar 01 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Wed, 2 Mar 2005 14:28:34 +1100, Derek Parnell <derek psych.ward> wrote:

 On Wed, 02 Mar 2005 16:00:10 +1300, Regan Heath wrote:


 On Wed, 2 Mar 2005 02:21:51 -0000, Rob Grainger <nospam nospam.com>  
 wrote:

 Again, the purpose here is not to be cross-language (these kind of  
 names
 never made an
 appearance in VB), but to support C compilers where the basic types  
 have
 different sizes
 (a rare occurence on Windows, but theoretically possible) - all such a
 compiler-vendor
 would need to do is define a few thousand typedef's appropiately (that
 was
 sarcasm).


 Ok, so given that D does not have different sized basic types, but fixed
 sized basic types, what do you recommend we do here?

 I believe the point you were making is that on some systems pointers are
 32bit, and others 64bit, and you need a type that will definately hold a
 pointer.

 D can do this with typedef, or alias, eg.

 version(32bit) {
    typedef ptr_t uint
 }
 version(64bit) {
    typedef ptr_t ulong
 }

 or similar. What do you think?

 Regan


 Just letting you know that in object.d we already have ...


Thanks Derek, I had forgotten where this was.


 version (AMD64)
 {
     alias ulong size_t;
     alias long ptrdiff_t;
 }
 else version (X86)
 {
     alias uint size_t;
     alias int ptrdiff_t;
 }

 Which probably means all you need to do is ...

   alias size_t ptr_t;


Or perhaps we want/need to add ptrsize_t to object.d?

Regan
Mar 01 2005
parent =?ISO-8859-15?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Regan Heath wrote:


 Just letting you know that in object.d we already have ...


 

 version (AMD64)
 {
     alias ulong size_t;
     alias long ptrdiff_t;
 }
 else version (X86)
 {
     alias uint size_t;
     alias int ptrdiff_t;
 }


 Thanks Derek, I had forgotten where this was.
 


Side Note:
In the portable version of Phobos, this passage reads:

version (GNU)
{
     version (GNU_BitsPerPointer32)
     {
         alias uint size_t;
         alias int ptrdiff_t;
     }
     else version (GNU_BitsPerPointer64)
     {
         alias ulong size_t;
         alias long ptrdiff_t;
     }
     else
     {
         static assert(0);
     }
}
else version (AMD64)
{
     alias ulong size_t;
     alias long ptrdiff_t;
}
else version (X86)
{
     alias uint size_t;
     alias int ptrdiff_t;
}
else
{
     static assert(0);
}

Where GNU_BitsPerPointer is set automagically by GDC:


 #if UNITS_PER_WORD == 4
     VersionCondition::addPredefinedGlobalIdent("GNU_BitsPerWord32");
 #elif UNITS_PER_WORD == 8
     VersionCondition::addPredefinedGlobalIdent("GNU_BitsPerWord64");
 #endif
 #if POINTER_SIZE == 32
     VersionCondition::addPredefinedGlobalIdent("GNU_BitsPerPointer32");
 #elif POINTER_SIZE == 64
     VersionCondition::addPredefinedGlobalIdent("GNU_BitsPerPointer64");
 #endif


And those C macros are in turn set by GCC's configure.

--anders


PS.
You still need Wine for the Win32 API's, though... :-)
http://www.winehq.com/
Mar 02 2005
prev sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Rob Grainger wrote:


Which is more readable/understandable?

    extern (Windows) LRESULT windowCallback(HWND hWnd, UINT uMsg, WPARAM 
wParam, LPARAM lParam)

or

    typedef void* Handle = (void*)0; // a typedef, but a useful one
    extern (Windows) int windowCallback(Handle handle, uint message, uint 
param1, int param2)


I think we both agree on this.




Hope you mean the first version, because even I recognize that one...
And when reading Win32 API documentation, it would be the one I'd find.


Here is one article, which you might find interesting:
(it's about interfacing OS APIs with Java, but anyway)

http://www.eclipse.org/articles/Article-SWT-Design-1/SWT-Design-1.html

Maintaining the one-to-one mapping is important, and
I would say this also includes the types being used ?



 Me too, but think it would slow down a lot of Windows developers (myself 
 included).
 
 Hope these comments are useful - at least worth a moments consideration.


Many other libraries also add their own types, which are D aliases.
Some examples are: OpenGL, libSDL, and Mac OS X's Carbon API...

It's easier to add a dozen aliases, than to change all the functions...

EXAMPLES
========

OpenGL: (gl.gl)

 alias ubyte GLboolean;
 alias byte GLbyte;
 alias short GLshort;
 alias int GLint;
 alias int GLsizei;
 alias ubyte GLubyte;
 alias ushort GLushort;
 alias uint GLuint;


libSDL: (sdl.types)

 enum SDL_bool : int {
         SDL_FALSE = 0,
         SDL_TRUE  = 1
 }
 alias ubyte     Uint8;
 alias byte      Sint8;
 alias ushort    Uint16;
 alias short     Sint16;
 alias uint      Uint32;
 alias int       Sint32;
 alias ulong     Uint64;
 alias long      Sint64;


Carbon: (macosx.carbon)

 alias ubyte Boolean;
 alias  ubyte UInt8;
 alias   byte SInt8;
 alias ushort UInt16;
 alias  short SInt16;
 alias   uint UInt32;
 alias    int SInt32;
 alias  ulong UInt64;
 alias   long SInt64;


Even for "pure" D code, some aliases are good. Like bool and str :-)

But interfacing with C libraries is different, and has way more legacy.

--anders
Mar 02 2005
parent reply "John C" <johnch_atms hotmail.com> writes:
"Anders F Björklund" <afb algonet.se> wrote in message 
news:d040oi$2a02$1 digitaldaemon.com...

 Rob Grainger wrote:


Which is more readable/understandable?

    extern (Windows) LRESULT windowCallback(HWND hWnd, UINT uMsg, WPARAM 
 wParam, LPARAM lParam)

or

    typedef void* Handle = (void*)0; // a typedef, but a useful one
    extern (Windows) int windowCallback(Handle handle, uint message, 
 uint param1, int param2)


I think we both agree on this.




 Hope you mean the first version, because even I recognize that one...
 And when reading Win32 API documentation, it would be the one I'd find.


You recognise it because you're familiar with reading the C API, as am I. 
But we can't assume all users of our libraries will share that experience. 
And they won't be looking up things on MSDN - they'll (hopefully) be reading 
the library's documentation. I think it's more important to make life easier 
for them than for ourselves. It might also turn off people coming from Java 


An alternative is to put the SDK version of a declaration in the library's 
documentation, or in comments in your code, thereby keeping both camps 
happy.


 Here is one article, which you might find interesting:
 (it's about interfacing OS APIs with Java, but anyway)

 http://www.eclipse.org/articles/Article-SWT-Design-1/SWT-Design-1.html

 Maintaining the one-to-one mapping is important, and
 I would say this also includes the types being used ?



 Me too, but think it would slow down a lot of Windows developers (myself 
 included).

 Hope these comments are useful - at least worth a moments consideration.


 Many other libraries also add their own types, which are D aliases.
 Some examples are: OpenGL, libSDL, and Mac OS X's Carbon API...

 It's easier to add a dozen aliases, than to change all the functions...

 EXAMPLES
 ========

 OpenGL: (gl.gl)

 alias ubyte GLboolean;
 alias byte GLbyte;
 alias short GLshort;
 alias int GLint;
 alias int GLsizei;
 alias ubyte GLubyte;
 alias ushort GLushort;
 alias uint GLuint;


 libSDL: (sdl.types)

 enum SDL_bool : int {
         SDL_FALSE = 0,
         SDL_TRUE  = 1
 }
 alias ubyte     Uint8;
 alias byte      Sint8;
 alias ushort    Uint16;
 alias short     Sint16;
 alias uint      Uint32;
 alias int       Sint32;
 alias ulong     Uint64;
 alias long      Sint64;


 Carbon: (macosx.carbon)

 alias ubyte Boolean;
 alias  ubyte UInt8;
 alias   byte SInt8;
 alias ushort UInt16;
 alias  short SInt16;
 alias   uint UInt32;
 alias    int SInt32;
 alias  ulong UInt64;
 alias   long SInt64;


 Even for "pure" D code, some aliases are good. Like bool and str :-)

 But interfacing with C libraries is different, and has way more legacy.

 --anders
Mar 02 2005
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
John C wrote:


Hope you mean the first version, because even I recognize that one...
And when reading Win32 API documentation, it would be the one I'd find.


 
 You recognise it because you're familiar with reading the C API, as am I. 


And I suppose all the rest trying to use the API in question, as well ?
Like in all sample code and in all printed books that can be found...


 But we can't assume all users of our libraries will share that experience. 
 And they won't be looking up things on MSDN - they'll (hopefully) be reading 
 the library's documentation.


Porting the C/C++ headers into a D import module is enough work
*without* having to translate all types and documentation, IMHO.


 I think it's more important to make life easier 
 for them than for ourselves. It might also turn off people coming from Java 



That's too bad for them, isn't it... ? It's a good thing D has it.


 An alternative is to put the SDK version of a declaration in the library's 
 documentation, or in comments in your code, thereby keeping both camps 
 happy.


Duplicating each function, as if people read documentation ? :-)
As long as it can be fully automated, I guess that *could* work...


My thoughts:
The more copy-and-paste the H2D process of translating is, the better.
As it is now, it's pretty straightforward - with a few minor caveats.

And if it's easy to use C libraries, it makes D all that more useful.
(even if those libs are not using Exceptions or GC or OOP or anything)

Like Walter says: (in http://www.digitalmars.com/d/phobos.html)

 D provides direct access to C runtime library functions and operating  system
 API functions. Pointless D wrappers around those functions just adds
 blather, bloat, baggage and bugs. 


With the aliases, I've found porting at least three major APIs and
a few smaller ones to be a doable task (at least with some Perl help)


That doesn't stop the D programs and libraries from being high-level,
of course. Here I was just talking about the actual low-level C APIs.

--anders
Mar 02 2005
prev sibling parent Georg Wrede <georg.wrede nospam.org> writes:
John C wrote:

 Which is more readable/understandable?
 
     extern (Windows) LRESULT windowCallback(HWND hWnd, UINT uMsg, WPARAM 
 wParam, LPARAM lParam)
 
 or
 
     typedef void* Handle = (void*)0; // a typedef, but a useful one
     extern (Windows) int windowCallback(Handle handle, uint message, uint 
 param1, int param2)


It is extremely important to _never_ try to rename things like LRESULT, 
HWND, UINT, WPARAM, LPARAM  to anything else. Most especially HWND, 
LPARAM and WPARAM.

Were these renamed, then their users could never ask any Windows savvy 
programmers for advice. These words are _cornerstone_ words in Windows 
programming.

They also bring a certain level of independence of architecture. Ideally 
one's own programs should work on any hardware platform that Windows 
supports now or in the future, and only by using these words as such is 
there hope for it.

I'm not too happy either with the first example above, and I admit that 
the second is more readable. But this is only at the beginning. Using 
the second version will keep people from getting familiar with the 
standard way of Windows programming, and thus just move the same barrier 
down the road, where it's waiting for you with a vengeance. :-)

So the suggestion is as useful as converting all keywords of the D 
language to Finnish, for Finnish programmers.
Mar 02 2005
prev sibling next sibling parent reply Mark T <Mark_member pathlink.com> writes:
In article <ctdc6n$2e4l$1 digitaldaemon.com>, Stewart Gordon says...

We've talked about it quite a bit, but not got far.  Has anyone actually 
undertaken the task of translating the Windows API headers into D?

If not, I hereby propose we get started on it now!  We can do this as a 
team effort, with each member translating one or more of the Windows .h 
files.  I suggest we proceed as follows:

1. Decide on some rules.  I have some ideas for rules, as well as a few 
open issues in this respect, which I'll post a bit later (assuming I'm 
going to get some interest in this project).


style rules?  I would suggest all files be public domain or without any claims
of copyright etc, KISS 


2. Set up a page on Wiki4D for the project, which would enable 
individuals to 'take' individual modules that they're going to work on.


good idea  what needs to be done? 


3. Find somewhere to keep the translated modules for the time being. 
Maybe dsource?


a good place to put them - I wish we could get more people to use it
(someone started a Java to D translator and then disappeared and of course there
is no source code anywhere)

maybe someone could start with:
http://hp.vector.co.jp/authors/VA028375/d/windows.h.html

or is Core32 the way to go?

a standard .zip package is always best for source code which compresses very
nicely
Jan 29 2005
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Mark T wrote:

 In article <ctdc6n$2e4l$1 digitaldaemon.com>, Stewart Gordon says...


<snip>

 1. Decide on some rules.  I have some ideas for rules, as well as a 
 few open issues in this respect, which I'll post a bit later 
 (assuming I'm going to get some interest in this project).


 
 style rules?


Rules, guidelines, whatever it would make sense to call them.  Basically 
so that the modules look reasonably tidy and consistent and, more 
importantly, use module names and versioning consistently.


 I would suggest all files be public domain or without any claims of 
 copyright etc, KISS


You're probably right.  But what is the copyright of the standard 
Windows C headers?  I guess this would count as a derivative work - so 
what are the implications?

<snip>

 maybe someone could start with: 
 http://hp.vector.co.jp/authors/VA028375/d/windows.h.html


That sounds as though it's a single module encompassing the whole of the 
windows.h include tree.  (I meant to investigate, but didn't quite get 
that far.)  I was thinking of something whereby .h files are converted 
1:1 to .d files.


 or is Core32 the way to go?


<snip>

Maybe.  Maybe we don't need to reinvent the wheel, but merely refine it.

BTW here are the rules/guidelines I had in mind (if we're merely going 
to refine the wheel, maybe it would be overkill to try applying them all 
to what's already done):

Name your module as etc.c.windows.xyz, where xyz.h is the C header of 
which it is a translation.  (The hope is that Walter will eventually 
replace "etc" with "std" in what we end up with....)

Use D notations in preference to legacy C ones (e.g. array and pointer 
notations attached to the type, function pointers).

Get rid of STRICT (treat as always defined), and assume WINVER >= 0x400. 
  Otherwise, replace #ifdefs with version blocks.

Use anonymous enums for sets of constants, with an appropriate base 
type.  (For those constants that are outside the arbitrary restrictions 
on enum base types, use consts.)

Use aliases, not typedefs (except for HANDLE, since handles aren't 
interchangeable with pointers).

Get rid of the C struct tags, and instead use the 'normal' name of the 
struct as the struct name.

Mark functions as deprecated as indicated in the API documentation.

Indent by one tab character within {...} blocks.  Use spaces to align 
values of enum constants and names of struct members in a column.

Open questions:

Should we use the many meaningless type aliases, or just declare 
everything with the real types hiding behind them?  There are three options:
- declare and use
- declare but don't use
- don't declare or use

The answer could be considered separately for each kind of type:
- generic primitive type aliases (e.g. UINT, DWORD)
- specific or semi-specific primitive type aliases (e.g. WPARAM, LRESULT)
- primitive-derived pointer types (e.g. PINT, LPSTR)
- struct pointer types (e.g. LPRECT)
- moreover, we can consider P/PC/LP/LPC separately for pointer types, 
considering that D doesn't have near/far or const pointers
- function pointer types (e.g. WNDPROC) - I'd say we should definitely 
use these

Should we dot version(UNICODE) blocks all over the place as done in the 
C headers?  Or just move them all to one block at the end of each module?

Does HANDLE really need to be defined as void*?  Or would it make more 
sense to define it as int, uint or something?  (Does the Windows 
mangling/calling convention allow this?)  This would be one step towards 
dealing with potential copying GC troubles.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Jan 31 2005
next sibling parent Mark T <Mark_member pathlink.com> writes:
 I would suggest all files be public domain or without any claims of 
 copyright etc, KISS


You're probably right.  But what is the copyright of the standard 
Windows C headers?  I guess this would count as a derivative work - so 
what are the implications?


start with mingw headers and use their copyright 


- struct pointer types (e.g. LPRECT)
- moreover, we can consider P/PC/LP/LPC separately for pointer types, 
considering that D doesn't have near/far or const pointers


near/far is obsolete for Win32 just ignore it
Jan 31 2005
prev sibling parent Mark T <Mark_member pathlink.com> writes:
<snip>
 maybe someone could start with: 
 http://hp.vector.co.jp/authors/VA028375/d/windows.h.html


That sounds as though it's a single module encompassing the whole of the 
windows.h include tree.  (I meant to investigate, but didn't quite get 
that far.)  I was thinking of something whereby .h files are converted 
1:1 to .d files.


I prefer his simple win32 folder vs etc.stuff

it's 1:1
win32

ansi           <DIR>        01-31-05  7:36p ansi
commctrl d         210,057  05-07-04 11:30a commctrl.d
commdlg  d          28,951  10-08-03 11:56p commdlg.d
dde      d           2,653  10-09-03 12:14a dde.d
ddeml    d          13,549  10-09-03 12:14a ddeml.d
dlgs     d           6,001  10-09-03 12:14a dlgs.d
guiddef  d             606  05-07-04 11:01a guiddef.d
imm      d          23,070  10-08-03 11:54p imm.d
mmsystem d         112,046  05-07-04 11:34a mmsystem.d
shellapi d          23,237  10-08-03 11:57p shellapi.d
winbase  d         171,588  05-07-04 11:50a winbase.d
wincon   d          16,210  10-09-03 12:15a wincon.d
windef   d           7,534  01-23-04  5:28a windef.d
windows  d           3,835  10-27-03 11:23a windows.d
winerror d         178,637  05-07-04  1:07p winerror.d
wingdi   d         144,163  05-07-04 12:39p wingdi.d
winnls   d          36,356  10-09-03 12:13a winnls.d
winnt    d         168,115  07-08-04  1:39p winnt.d
winreg   d          17,106  05-07-04  1:11p winreg.d
winsock  d          19,903  03-13-04 10:34p winsock.d
winspool d          69,654  10-09-03 12:06a winspool.d
winuser  d         227,269  07-08-04  1:38p winuser.d
winver   d           7,250  10-09-03 12:07a winver.d
Jan 31 2005
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Stewart Gordon, all the older Blaze demos have worked for me, but this time it
gives me:

...
Registering widget: Angle
Registering widget: SceneView
derelict.util.exception.SharedLibLoadException: Failed to load shared library
devil.dll

And stops.
The DevIL.dll is present beside the exe.

Bye,
bearophile
Mar 16 2009
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
bearophile wrote:

 Stewart Gordon, all the older Blaze demos have worked for me, but this time it
gives me:
 
 ...
 Registering widget: Angle
 Registering widget: SceneView
 derelict.util.exception.SharedLibLoadException: Failed to load shared library
devil.dll


<snip>

I'm not sure what this has to do with the Windows API bindings project. 
  I also don't know anything about Blaze, but maybe someone else on the 
'group knows and may be able to help, or you could have a look around 
yourself for the code that throws that exception.

Stewart.
Mar 16 2009
parent bearophile <bearophileHUGS lycos.com> writes:
Stewart Gordon:

 I'm not sure what this has to do with the Windows API bindings project. 
   I also don't know anything about Blaze, but maybe someone else on the 
 'group knows and may be able to help, or you could have a look around 
 yourself for the code that throws that exception.


I am sorry, it's a mistake of mine caused by the online forum. Ignore that post
of mine please.

Bye,
bearophile
Mar 16 2009