The use of individual enums in YT's library doesn't add any value.
Named enums would help intelsense (I'm getting too old to be bothered
remembering everything, so if I can leverage off intelsense it would be
good).
Typedefs are not an issue, I've been programming windows since....forever.
The overloeading of definitions with the differenct types would be good.
I meant to use the correct MS names eg handle, but instead of do this:
    typedef VOID void;
    typedef HANDLE VOID*;

We would do this:
    typedef HANDLE void*;

This is just an example.

Happy to stick with the header names, so how do we name them as D modules?




"Julio César Carrascal Urquijo" <adnoctum@phreaker.net> wrote in message news:c7b7br$1of0$1@digitaldaemon.com...
> 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------

All rule are negotiable, that's what rules are for ;)



"J C Calvarese" <jcc7@cox.net> wrote in message news:c7avbn$1c0j$1@digitaldaemon.com...
> 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

Matt you better check the meaning of opine, while I violently rant about your response.  Well actually meekly comment:

The multiple definition thing simply means that:
(scratching head trying to think of API example)

we define:
foo(HWND hWnd, DWORD flag);  and
foo(HWND hWnd, LPCWSTR Text);

What would be the drama here, it positively sucks that MS do things like pass special integer values instead of pointers.

(Just thought of an example: LoadIcon, in loadicon's case we could use an enum instead and show the icon types when intelsense is used)

Also - I don't know that we should support the A versions of the functions
(ducking now).  98's dead.





"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:c7bvdc$2uko$1@digitaldaemon.com...
>
> "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
> >
> >
> >
>
>

"Scott Egan" <scotte@tpg.com.aux> wrote in message news:c7d1uj$1hau$1@digitaldaemon.com...
> Matt you better check the meaning of opine, while I violently rant about your response.  Well actually meekly comment:
>
> The multiple definition thing simply means that:
> (scratching head trying to think of API example)
>
> we define:
> foo(HWND hWnd, DWORD flag);  and
> foo(HWND hWnd, LPCWSTR Text);
>
> What would be the drama here, it positively sucks that MS do things like pass special integer values instead of pointers.
>
> (Just thought of an example: LoadIcon, in loadicon's case we could use an enum instead and show the icon types when intelsense is used)
>
> Also - I don't know that we should support the A versions of the functions
> (ducking now).  98's dead.
>

Should be dead, but maybe not quite.

> Matt you better check the meaning of opine, while I violently rant about your response.  Well actually meekly comment:

Why? opine means to give opinion. That's exactly what I meant.

> The multiple definition thing simply means that:
> (scratching head trying to think of API example)
>
> we define:
> foo(HWND hWnd, DWORD flag);  and
> foo(HWND hWnd, LPCWSTR Text);
>
> What would be the drama here, it positively sucks that MS do things like pass special integer values instead of pointers.

No, I like that example (or rather the real-world issue that that example conjours). My fear is that stepping too far from the API will lead to confusion.

I'd rather use some prefix convention for things that are non trivial mutations over the Windows API, e.g. an overload of CreateWindow() where several parameters are elided

> (Just thought of an example: LoadIcon, in loadicon's case we could use an enum instead and show the icon types when intelsense is used)
>
> Also - I don't know that we should support the A versions of the functions
> (ducking now).  98's dead.

In which world? The idealist programmer's, or the real one.

This debate is stale, as I think it was done to death some month's ago. I don't think anyone's not in agreement that not having to care about 9x would be nice. It's just the case that idealism vs realism are not in agreement on this issue.

> "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:c7bvdc$2uko$1@digitaldaemon.com...
> >
> > "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
> > >
> > >
> > >
> >
> >
>
>

On Thu, 6 May 2004 19:40:45 +1000, "Scott Egan" <scotte@tpg.com.aux> wrote:

>The use of individual enums in YT's library doesn't add any value.
>Named enums would help intelsense (I'm getting too old to be bothered
>remembering everything, so if I can leverage off intelsense it would be
>good).
>Typedefs are not an issue, I've been programming windows since....forever.
>The overloeading of definitions with the differenct types would be good.
>I meant to use the correct MS names eg handle, but instead of do this:
>    typedef VOID void;
>    typedef HANDLE VOID*;
>
>We would do this:
>    typedef HANDLE void*;
>
>This is just an example.
>
and back to front!
remeber typedef in C is alias in D.
also D named enums require the name i.e.
enum MyTags { ONE, TWO, THREE }
to use is MyTag.ONE not ONE as it would be in C
there is an option to use alias MyTags.ONE ONE; to promote the name
into the global namespace for programmers who want to use the same
name as they would from C)
I agree in principle that typesafety and enum safetly improve
robustness, but I'm not convinced that the cost (change in the way
windows programmer program) will be an overnight sucess, I think you
have a long road to travel to convince programmers that this is
benifical

you can start your path by adding the typedefs to the win32 headers
I've ported that are on www.dsource.org (as long as your changes are
marked version(TYPESAFE) { ... } and see how things go once you start
using the GDI calls etc
without implicit templates SelectObject (as the only thing that comes
to mind at this hour)  requires a cast (MFC programmers are used to
this) but its a static_cast so no benifit over having an alias.

Mike.