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.

"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/