Ok, I've been looking around and I've decided that the the std.c.windows.windows just does not cut it.  I know from reading the NG that I'm not the only one.

I've been thinking we need to do better, I don't think anyone's quite does the trick.  Automatic conversion is not the answer.

And its not something one should do on one's own.

I think I'll try and host some sort of site so that we can collaborate - proberly a DB that we can use intelligently.

The rules would be:
    -typedefs not aliases (except if it can be shown that two types are
meant to be the same thing)
    -multiple definitions for functions that take two overloaded arguments
    -use of version to map aliases for A and W versions
    -all types tydefed from basic D types
    -all const associated with an activity changed to named enums
    -all enums named
    -all functions use enum types as necessary

Questions:
    -should the files (and modules) be structured (see below from MS SDK; I
don't expect this much detail)
    -how could we split up the work
    -could we provide peer review of each submitted part


Thoughts?

----------------------------------------------------------
Win32 API Categories:

      Base Services
     Communication
     Console
     Debugging
     Device Management
     Dynamic-Link Library
     Error Handling
     Event Logging
     Handle and Object
     Mailslot
     Memory Management
     Network DDE
     Pipe
     Performance Monitoring
     Power Management
     Process and Thread
     PSAPI
     Registry
     Service
     Structured Exception Handling
     Synchronization
     System Information
     System Shutdown
     Terminal Services
     Time
     Time Provider
     Tool Help
     Volume Management

      Control Button
     Combo Box
     Edit Control
     List Box
     Rich Edit Control
     Scroll Bar
     Static Control
     Text Object Model
     Windowless Rich Edit Control

      Data Exchange Atom
     Clipboard
     Dynamic Data Exchange
     Dynamic Data Exchange Management

      GDI Bitmap
     Brush
     Clipping
     Color
     Coordinate Space and Transformation
     Device Context
     Filled Shape
     Font and Text
     Line and Curve
     Metafile
     Multiple Display Monitors
     Painting and Drawing
     Path
     Pen
     Printing and Print Spooler
     Rectangle
     Region

      Internationalisation
     Input Method Editor
     National Language Support
     Unicode and Character Set
     Uniscribe
      Networking & DS
     Network Management
     Windows Networking
      Resource
     Caret
     Cursor
     Icon
     Menu
     Resource
     String
     Version Information
      Storage
     Backup
     Directory Management
     Disk Management
     File Management
      System Adminitration
     User Profile
      User Input
     Common Dialog Box
     Keyboard Accelerator
     Keyboard Input
     Mouse Input
     Raw Input
      Windowing
     Dialog Box
     Hook
     Message and Message Queue
     Multiple Document Interface
     Timer
     Window
     Window Class
     Window Procedure
     Window Property

In article <c7arel$15mg$1@digitaldaemon.com>, Scott Egan says...
>
>Ok, I've been looking around and I've decided that the the std.c.windows.windows just does not cut it.  I know from reading the NG that I'm not the only one.

You're certainly right about that.

>
>I've been thinking we need to do better, I don't think anyone's quite does the trick.  Automatic conversion is not the answer.

Why not? No automatic conversion at all? Is this because of your typedef requirement below?

>
>And its not something one should do on one's own.

Right. It's a big job.

>
>I think I'll try and host some sort of site so that we can collaborate - proberly a DB that we can use intelligently.
>
>The rules would be:

Are these rules negotiable?

>    -typedefs not aliases (except if it can be shown that two types are
>meant to be the same thing)
>    -multiple definitions for functions that take two overloaded arguments
>    -use of version to map aliases for A and W versions
>    -all types tydefed from basic D types
>    -all const associated with an activity changed to named enums
>    -all enums named
>    -all functions use enum types as necessary
>
>Questions:
>    -should the files (and modules) be structured (see below from MS SDK; I
>don't expect this much detail)

Yes. I think that's a good idea.

>    -how could we split up the work

The project could start by reviewing existing efforts by Mike Wynn, Y. Tomino, Walter's headers, etc. No need to start from scratch.

>    -could we provide peer review of each submitted part
>
>
>Thoughts?
>
snip...

JC

Mike Wynn is back hanging around these parts again, and has set up shop for his core32 libraries (of which you're talking about, Scott) at http://www.dsource.org

I have yet to post the libs, but the forums are open.

BA

J C Calvarese wrote:
> In article <c7arel$15mg$1@digitaldaemon.com>, Scott Egan says...
> 
>>Ok, I've been looking around and I've decided that the the
>>std.c.windows.windows just does not cut it.  I know from reading the NG that
>>I'm not the only one.
> 
> 
> You're certainly right about that.
> 
> 
>>I've been thinking we need to do better, I don't think anyone's quite does
>>the trick.  Automatic conversion is not the answer.
> 
> 
> Why not? No automatic conversion at all? Is this because of your typedef
> requirement below?
> 
> 
>>And its not something one should do on one's own.
> 
> 
> Right. It's a big job.
> 
> 
>>I think I'll try and host some sort of site so that we can collaborate -
>>proberly a DB that we can use intelligently.
>>
>>The rules would be:
> 
> 
> Are these rules negotiable?
> 
> 
>>   -typedefs not aliases (except if it can be shown that two types are
>>meant to be the same thing)
>>   -multiple definitions for functions that take two overloaded arguments
>>   -use of version to map aliases for A and W versions
>>   -all types tydefed from basic D types
>>   -all const associated with an activity changed to named enums
>>   -all enums named
>>   -all functions use enum types as necessary
>>
>>Questions:
>>   -should the files (and modules) be structured (see below from MS SDK; I
>>don't expect this much detail)
> 
> 
> Yes. I think that's a good idea.
> 
> 
>>   -how could we split up the work
> 
> 
> The project could start by reviewing existing efforts by Mike Wynn, Y. Tomino,
> Walter's headers, etc. No need to start from scratch.
> 
> 
>>   -could we provide peer review of each submitted part
>>
>>
>>Thoughts?
>>
> 
> snip...
> 
> JC

Scott Egan wrote:

> Ok, I've been looking around and I've decided that the the
> std.c.windows.windows just does not cut it.  I know from reading the NG that
> I'm not the only one.
<snip>

Maybe it'll cut it when it's finished!

> The rules would be:
>     -typedefs not aliases (except if it can be shown that two types are
> meant to be the same thing)

This issue has been raised plenty of times already.  I can only agree with Walter on this:

"One of my early thoughts was also to clean up the win32 type system. Unfortunately, most code plays fast and loose with using C typedefs mixed in with the underlying types. Microsoft's own sample code is woefully inconsistent about it. It's so much easier to just use alias for them and not worry about it. Save the clean designs for doing something new, not legacy API's."
http://www.digitalmars.com/drn-bin/wwwnews?D/15278

I also agree that some of the API type aliases are pointless and potentially confusing.  (My guess is that it was M$'s attempt to develop a cross-language set of type names.)  While it's OK to keep them in the API function declarations, we shouldn't be forced to concern ourselves with them when writing code.

>     -multiple definitions for functions that take two overloaded arguments

What do you mean by this?

>     -use of version to map aliases for A and W versions

Exactly what I was thinking.

>     -all types tydefed from basic D types
>     -all const associated with an activity changed to named enums
>     -all enums named

What would we call them?  Would we keep the names of the constants the same?

I've actually started to do this in forthcoming SDWF 0.2.  In most cases, the first underscore effectively just turns into a dot, but there are also places where I have had to rearrange the words a bit.  But even in the simplest cases, such identifiers aren't part of the Windows API, so as much as they're a neat idea, I'm not sure that they really belong in a Windows API module.

>     -all functions use enum types as necessary

Since enums convert implicitly to their underlying types, it won't be *necessary* to declare functions to use enums.  But I suppose Walter's comment applies here too.

> Questions:
>     -should the files (and modules) be structured (see below from MS SDK; I
> don't expect this much detail)
<snip>

My thought was to translate each of the .h files into a D module.  But maybe they could be eventually be sorted into categories like the ones you've listed.

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

I'm interested. I could help you if you setup a SVN or CVS repository somewhere.

I don't know the author's name but you should take a look at the port of the windows headers in this page:
http://hp.vector.co.jp/authors/VA028375/d/windows.h.html

There's pretty much the whole Win32 API translated to D.

Scott Egan wrote:
> Ok, I've been looking around and I've decided that the the
> std.c.windows.windows just does not cut it.  I know from reading the NG that
> I'm not the only one.
> 
> I've been thinking we need to do better, I don't think anyone's quite does
> the trick.  Automatic conversion is not the answer.

Automatic conversion + Some manual editing, maybe.

> And its not something one should do on one's own.
> 
> I think I'll try and host some sort of site so that we can collaborate -
> proberly a DB that we can use intelligently.
> 
> The rules would be:
>     -typedefs not aliases (except if it can be shown that two types are
> meant to be the same thing)

Not convinced. Win32 API is too much inconsistent.

>     -multiple definitions for functions that take two overloaded arguments
>     -use of version to map aliases for A and W versions

Yes please.

>     -all types tydefed from basic D types

Do you mean changing HANDLE to void* and such?

>     -all const associated with an activity changed to named enums
>     -all enums named
>     -all functions use enum types as necessary

The Mono project did this with their WINELIB namespace and it's pretty confusing. You usually have to guess what name did they gave to the enum where the constant is defined.

> Questions:
>     -should the files (and modules) be structured (see below from MS SDK; I
> don't expect this much detail)
>     -how could we split up the work
>     -could we provide peer review of each submitted part

I think staying close to the Microsoft headers is better. I really don't  want to read the API documentation and go find the module and enum where the constant/function is defined. If the docs say it's in "winuser.h" it should be in "winuser.d".

> 
> Thoughts?
> 
> ----------------------------------------------------------
> Win32 API Categories:
> 
>       Base Services
>      Communication
>      Console
>      Debugging
>      Device Management
>      Dynamic-Link Library
>      Error Handling
>      Event Logging
>      Handle and Object
>      Mailslot
>      Memory Management
>      Network DDE
>      Pipe
>      Performance Monitoring
>      Power Management
>      Process and Thread
>      PSAPI
>      Registry
>      Service
>      Structured Exception Handling
>      Synchronization
>      System Information
>      System Shutdown
>      Terminal Services
>      Time
>      Time Provider
>      Tool Help
>      Volume Management
> 
>       Control Button
>      Combo Box
>      Edit Control
>      List Box
>      Rich Edit Control
>      Scroll Bar
>      Static Control
>      Text Object Model
>      Windowless Rich Edit Control
> 
>       Data Exchange Atom
>      Clipboard
>      Dynamic Data Exchange
>      Dynamic Data Exchange Management
> 
>       GDI Bitmap
>      Brush
>      Clipping
>      Color
>      Coordinate Space and Transformation
>      Device Context
>      Filled Shape
>      Font and Text
>      Line and Curve
>      Metafile
>      Multiple Display Monitors
>      Painting and Drawing
>      Path
>      Pen
>      Printing and Print Spooler
>      Rectangle
>      Region
> 
>       Internationalisation
>      Input Method Editor
>      National Language Support
>      Unicode and Character Set
>      Uniscribe
>       Networking & DS
>      Network Management
>      Windows Networking
>       Resource
>      Caret
>      Cursor
>      Icon
>      Menu
>      Resource
>      String
>      Version Information
>       Storage
>      Backup
>      Directory Management
>      Disk Management
>      File Management
>       System Adminitration
>      User Profile
>       User Input
>      Common Dialog Box
>      Keyboard Accelerator
>      Keyboard Input
>      Mouse Input
>      Raw Input
>       Windowing
>      Dialog Box
>      Hook
>      Message and Message Queue
>      Multiple Document Interface
>      Timer
>      Window
>      Window Class
>      Window Procedure
>      Window Property
> 
> 
> 


-- 
Julio César Carrascal Urquijo
http://jcesar.f2o.org/
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS$ d- s+:+ a-- C++> ULS++ P++ L+> !E W+++ N+ o? K? w++>
O---@ M V? PS+ PE Y+ PGP t+ 5- X+++@ R- tv+(++) b++> DI!
D++> G e+> h-- r- y+
------END GEEK CODE BLOCK------

Ive used Y.Tominos headers for a long time, and I have never had any problems with them.

> Automatic conversion is not the answer.

Why not ?  Easier to update and maintain.  Have you looked a YT's stuff ?
http://hp.vector.co.jp/authors/VA028375/d/windows.h.html

When writing Windy and dig-dug i used alot of esoteric windows functions, and win32.lib never missed a beat.  I think you'd be hard pressed to do a better job, but Im all for you trying :) !

C



On Wed, 5 May 2004 23:50:12 +1000, Scott Egan <scotte@tpg.com.aux> wrote:

> Ok, I've been looking around and I've decided that the the
> std.c.windows.windows just does not cut it.  I know from reading the NG that
> I'm not the only one.
>
> I've been thinking we need to do better, I don't think anyone's quite does
> the trick.  Automatic conversion is not the answer.
>
> And its not something one should do on one's own.
>
> I think I'll try and host some sort of site so that we can collaborate -
> proberly a DB that we can use intelligently.
>
> The rules would be:
>     -typedefs not aliases (except if it can be shown that two types are
> meant to be the same thing)
>     -multiple definitions for functions that take two overloaded arguments
>     -use of version to map aliases for A and W versions
>     -all types tydefed from basic D types
>     -all const associated with an activity changed to named enums
>     -all enums named
>     -all functions use enum types as necessary
>
> Questions:
>     -should the files (and modules) be structured (see below from MS SDK; I
> don't expect this much detail)
>     -how could we split up the work
>     -could we provide peer review of each submitted part
>
>
> Thoughts?
>
> ----------------------------------------------------------
> Win32 API Categories:
>
>       Base Services
>      Communication
>      Console
>      Debugging
>      Device Management
>      Dynamic-Link Library
>      Error Handling
>      Event Logging
>      Handle and Object
>      Mailslot
>      Memory Management
>      Network DDE
>      Pipe
>      Performance Monitoring
>      Power Management
>      Process and Thread
>      PSAPI
>      Registry
>      Service
>      Structured Exception Handling
>      Synchronization
>      System Information
>      System Shutdown
>      Terminal Services
>      Time
>      Time Provider
>      Tool Help
>      Volume Management
>
>       Control Button
>      Combo Box
>      Edit Control
>      List Box
>      Rich Edit Control
>      Scroll Bar
>      Static Control
>      Text Object Model
>      Windowless Rich Edit Control
>
>       Data Exchange Atom
>      Clipboard
>      Dynamic Data Exchange
>      Dynamic Data Exchange Management
>
>       GDI Bitmap
>      Brush
>      Clipping
>      Color
>      Coordinate Space and Transformation
>      Device Context
>      Filled Shape
>      Font and Text
>      Line and Curve
>      Metafile
>      Multiple Display Monitors
>      Painting and Drawing
>      Path
>      Pen
>      Printing and Print Spooler
>      Rectangle
>      Region
>
>       Internationalisation
>      Input Method Editor
>      National Language Support
>      Unicode and Character Set
>      Uniscribe
>       Networking & DS
>      Network Management
>      Windows Networking
>       Resource
>      Caret
>      Cursor
>      Icon
>      Menu
>      Resource
>      String
>      Version Information
>       Storage
>      Backup
>      Directory Management
>      Disk Management
>      File Management
>       System Adminitration
>      User Profile
>       User Input
>      Common Dialog Box
>      Keyboard Accelerator
>      Keyboard Input
>      Mouse Input
>      Raw Input
>       Windowing
>      Dialog Box
>      Hook
>      Message and Message Queue
>      Multiple Document Interface
>      Timer
>      Window
>      Window Class
>      Window Procedure
>      Window Property
>
>
>



-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

In article <c7b7br$1of0$1@digitaldaemon.com>, =?ISO-8859-1?Q?Julio_C=E9sar_Carrascal_Urquijo?= says...
>
>I'm interested. I could help you if you setup a SVN or CVS repository somewhere.

Actually, Mike Wynn (l8night) has stepped forward to lead an effort for Win32
headers in the last couple of days, and Brad already created him a forum at
dsource.org:
http://www.dsource.org/forums/viewforum.php?f=16

Since dsource.org has SVN, this would probably be a good place for a team effort.

>
>I don't know the author's name but you should take a look at the port of the windows headers in this page: http://hp.vector.co.jp/authors/VA028375/d/windows.h.html

I think his name is Y. Tomino. If not, I've been putting my foot in my mouth a lot lately.

>
>There's pretty much the whole Win32 API translated to D.
>
>Scott Egan wrote:
>> Ok, I've been looking around and I've decided that the the std.c.windows.windows just does not cut it.  I know from reading the NG that I'm not the only one.
>> 
>> I've been thinking we need to do better, I don't think anyone's quite does the trick.  Automatic conversion is not the answer.
>
>Automatic conversion + Some manual editing, maybe.

Okay.

>
>> And its not something one should do on one's own.
>> 
>> I think I'll try and host some sort of site so that we can collaborate - proberly a DB that we can use intelligently.
>> 
>> The rules would be:
>>     -typedefs not aliases (except if it can be shown that two types are
>> meant to be the same thing)
>
>Not convinced. Win32 API is too much inconsistent.

Me neither. It's nice that Matthew Wilson actually has real experience using these as typedefs; I just don't see what the effort would buy for us.

>
>>     -multiple definitions for functions that take two overloaded arguments
>>     -use of version to map aliases for A and W versions
>
>Yes please.
>
>>     -all types tydefed from basic D types
>
>Do you mean changing HANDLE to void* and such?
>
>>     -all const associated with an activity changed to named enums
>>     -all enums named
> >     -all functions use enum types as necessary
>
>The Mono project did this with their WINELIB namespace and it's pretty confusing. You usually have to guess what name did they gave to the enum where the constant is defined.
>
>> Questions:
>>     -should the files (and modules) be structured (see below from MS SDK; I
>> don't expect this much detail)
>>     -how could we split up the work
>>     -could we provide peer review of each submitted part
>
>I think staying close to the Microsoft headers is better. I really don't
>  want to read the API documentation and go find the module and enum
>where the constant/function is defined. If the docs say it's in "winuser.h" it should be in "winuser.d".

Definitely. The more we change arbitrarily this stuff the harder it will be to synch up with new releases from Microsoft.

>
>> 
>> Thoughts?
>> 
>> ----------------------------------------------------------
>> Win32 API Categories:
>> 
>>       Base Services
>>      Communication
>>      Console
>>      Debugging
>>      Device Management
>>      Dynamic-Link Library
>>      Error Handling
>>      Event Logging
>>      Handle and Object
>>      Mailslot
>>      Memory Management
>>      Network DDE
>>      Pipe
>>      Performance Monitoring
>>      Power Management
>>      Process and Thread
>>      PSAPI
>>      Registry
>>      Service
>>      Structured Exception Handling
>>      Synchronization
>>      System Information
>>      System Shutdown
>>      Terminal Services
>>      Time
>>      Time Provider
>>      Tool Help
>>      Volume Management
>> 
>>       Control Button
>>      Combo Box
>>      Edit Control
>>      List Box
>>      Rich Edit Control
>>      Scroll Bar
>>      Static Control
>>      Text Object Model
>>      Windowless Rich Edit Control
>> 
>>       Data Exchange Atom
>>      Clipboard
>>      Dynamic Data Exchange
>>      Dynamic Data Exchange Management
>> 
>>       GDI Bitmap
>>      Brush
>>      Clipping
>>      Color
>>      Coordinate Space and Transformation
>>      Device Context
>>      Filled Shape
>>      Font and Text
>>      Line and Curve
>>      Metafile
>>      Multiple Display Monitors
>>      Painting and Drawing
>>      Path
>>      Pen
>>      Printing and Print Spooler
>>      Rectangle
>>      Region
>> 
>>       Internationalisation
>>      Input Method Editor
>>      National Language Support
>>      Unicode and Character Set
>>      Uniscribe
>>       Networking & DS
>>      Network Management
>>      Windows Networking
>>       Resource
>>      Caret
>>      Cursor
>>      Icon
>>      Menu
>>      Resource
>>      String
>>      Version Information
>>       Storage
>>      Backup
>>      Directory Management
>>      Disk Management
>>      File Management
>>       System Adminitration
>>      User Profile
>>       User Input
>>      Common Dialog Box
>>      Keyboard Accelerator
>>      Keyboard Input
>>      Mouse Input
>>      Raw Input
>>       Windowing
>>      Dialog Box
>>      Hook
>>      Message and Message Queue
>>      Multiple Document Interface
>>      Timer
>>      Window
>>      Window Class
>>      Window Procedure
>>      Window Property
>> 
>> 
>> 
>
>
>-- 
>Julio César Carrascal Urquijo
>http://jcesar.f2o.org/
>-----BEGIN GEEK CODE BLOCK-----
>Version: 3.12
>GCS$ d- s+:+ a-- C++> ULS++ P++ L+> !E W+++ N+ o? K? w++>
>O---@ M V? PS+ PE Y+ PGP t+ 5- X+++@ R- tv+(++) b++> DI!
>D++> G e+> h-- r- y+
>------END GEEK CODE BLOCK------

jcc7

"Scott Egan" <scotte@tpg.com.aux> wrote in message news:c7arel$15mg$1@digitaldaemon.com...
> Ok, I've been looking around and I've decided that the the std.c.windows.windows just does not cut it.

You don't say. ;)

>  I know from reading the NG that
> I'm not the only one.

Indeed. I hope this post will be announcing that you are volunteering to fix it all up ...

> I've been thinking we need to do better, I don't think anyone's quite does the trick.  Automatic conversion is not the answer.
>
> And its not something one should do on one's own.
>
> I think I'll try and host some sort of site so that we can collaborate - proberly a DB that we can use intelligently.
>
> The rules would be:
>     -typedefs not aliases (except if it can be shown that two types are
> meant to be the same thing)

Hurrah! You have become my new best friend.

>     -multiple definitions for functions that take two overloaded arguments

Hmm. Not sure about this one. It needs some debate, methinks, or at least a justification from you as to why this is preferred.

>     -use of version to map aliases for A and W versions

Again, this is an issue fraught with problems. Do we really want to have to ship different versions of exes for NT vs 9x. It's a nasty issue - thanks MS - and despite all the debates of the past two years, it's still not solved.

>     -all types tydefed from basic D types

How else could it be done?

Or do you mean that LPBYTE will be from byte* and not BYTE*? I don't agree with that.

>     -all const associated with an activity changed to named enums
>     -all enums named
>     -all functions use enum types as necessary

> Questions:
>     -should the files (and modules) be structured (see below from MS SDK; I
> don't expect this much detail)

Perhaps eventually. For the moment I'd like to see it done on an as-needed basis.

I would like to see std.c.windows.windows.d perform a similar function to windows.h, i.e. it is a central point at which things from a great many APIs (and their headers) are collected together. .h does it via include. .d could do it via import, or via aliasing.

>     -how could we split up the work

Anything that involves a lot of work from Walter will fail, through time starvation. It needs to be organised clearly, both for working on individual parts, and for ease of integration back into Phobos (by big-W, until such time as phobos comes under DSLG or some such.)

>     -could we provide peer review of each submitted part

I would be happy to beligerently opine over such work.

> Thoughts?
>
> ----------------------------------------------------------
> Win32 API Categories:
>
>       Base Services
>      Communication
>      Console
>      Debugging
>      Device Management
>      Dynamic-Link Library
>      Error Handling
>      Event Logging
>      Handle and Object
>      Mailslot
>      Memory Management
>      Network DDE
>      Pipe
>      Performance Monitoring
>      Power Management
>      Process and Thread
>      PSAPI
>      Registry
>      Service
>      Structured Exception Handling
>      Synchronization
>      System Information
>      System Shutdown
>      Terminal Services
>      Time
>      Time Provider
>      Tool Help
>      Volume Management
>
>       Control Button
>      Combo Box
>      Edit Control
>      List Box
>      Rich Edit Control
>      Scroll Bar
>      Static Control
>      Text Object Model
>      Windowless Rich Edit Control
>
>       Data Exchange Atom
>      Clipboard
>      Dynamic Data Exchange
>      Dynamic Data Exchange Management
>
>       GDI Bitmap
>      Brush
>      Clipping
>      Color
>      Coordinate Space and Transformation
>      Device Context
>      Filled Shape
>      Font and Text
>      Line and Curve
>      Metafile
>      Multiple Display Monitors
>      Painting and Drawing
>      Path
>      Pen
>      Printing and Print Spooler
>      Rectangle
>      Region
>
>       Internationalisation
>      Input Method Editor
>      National Language Support
>      Unicode and Character Set
>      Uniscribe
>       Networking & DS
>      Network Management
>      Windows Networking
>       Resource
>      Caret
>      Cursor
>      Icon
>      Menu
>      Resource
>      String
>      Version Information
>       Storage
>      Backup
>      Directory Management
>      Disk Management
>      File Management
>       System Adminitration
>      User Profile
>       User Input
>      Common Dialog Box
>      Keyboard Accelerator
>      Keyboard Input
>      Mouse Input
>      Raw Input
>       Windowing
>      Dialog Box
>      Hook
>      Message and Message Queue
>      Multiple Document Interface
>      Timer
>      Window
>      Window Class
>      Window Procedure
>      Window Property
>
>
>

> > The rules would be:
> >     -typedefs not aliases (except if it can be shown that two types are
> > meant to be the same thing)
>
> Not convinced. Win32 API is too much inconsistent.

Everybody says that this is a problem, but no-one provides any examples of it. Every time I've done Win32 work in D I've used typedefs, and I have had ZERO problems. Until someone provides some genuine examples of problems I'm going to remain convinced that it's a no-brainer, and continue to espouse such to the NG.

> >     -all const associated with an activity changed to named enums
> >     -all enums named
>  >     -all functions use enum types as necessary
>
> The Mono project did this with their WINELIB namespace and it's pretty confusing. You usually have to guess what name did they gave to the enum where the constant is defined.

Agreed. That would be a terrible idea. If it's REG_SZ in .h, then it's REG_SZ in D.

> I think staying close to the Microsoft headers is better. I really don't
>   want to read the API documentation and go find the module and enum
> where the constant/function is defined. If the docs say it's in
> "winuser.h" it should be in "winuser.d".

Very good point.

Matthew wrote:
> "Scott Egan" <scotte@tpg.com.aux> wrote in message
> news:c7arel$15mg$1@digitaldaemon.com...
[snip]

>>The rules would be:
[snip]

>>    -all types tydefed from basic D types
> 
> 
> How else could it be done?
> 
> Or do you mean that LPBYTE will be from byte* and not BYTE*? I don't agree with
> that.

But I thought you never met a typedef you didn't like? ;)

We could do an alias, and you might not know the difference.

[snip]

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/