View mode: basic / threaded / horizontal-split · Log in · Help
May 05, 2004
std.c.windows stuff
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
Re: std.c.windows stuff
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
Re: std.c.windows stuff
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
Re: std.c.windows stuff
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
Re: std.c.windows stuff
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
Re: std.c.windows stuff
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
Re: std.c.windows stuff
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 06, 2004
Re: std.c.windows stuff
"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
Re: std.c.windows stuff
> > 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 06, 2004
Re: std.c.windows stuff
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/
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home