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