www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - std.c.windows stuff

reply "Scott Egan" <scotte tpg.com.aux> writes:
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
May 05 2004
next sibling parent reply J C Calvarese <jcc7 cox.net> writes:
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
May 05 2004
next sibling parent Brad Anderson <brad sankaty.dot.com> writes:
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
May 05 2004
prev sibling parent "Scott Egan" <scotte tpg.com.aux> writes:
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
May 06 2004
prev sibling next sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
May 05 2004
prev sibling next sibling parent reply =?ISO-8859-1?Q?Julio_C=E9sar_Carrascal_Urquijo?= writes:
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------
May 05 2004
next sibling parent jcc7 cox.net writes:
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
May 05 2004
prev sibling next sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
 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.
May 05 2004
prev sibling parent reply "Scott Egan" <scotte tpg.com.aux> writes:
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------
May 06 2004
parent Mike Wynn <one_mad_alien hotmail.com> writes:
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.
May 06 2004
prev sibling next sibling parent C <qbert atari-soldiers.com> writes:
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/
May 05 2004
prev sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"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
May 05 2004
next sibling parent J C Calvarese <jcc7 cox.net> writes:
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/
May 05 2004
prev sibling parent reply "Scott Egan" <scotte tpg.com.aux> writes:
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
May 06 2004
next sibling parent "Phill" <phill pacific.net.au> writes:
"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.
May 06 2004
prev sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
 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
May 06 2004