Thread overview | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Scott Egan | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to J C Calvarese | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Scott Egan | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Scott Egan | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Scott Egan | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Julio César Carrascal Urquijo | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Scott Egan | "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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Julio César Carrascal Urquijo | > > 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Matthew | 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/ |
Copyright © 1999-2021 by the D Language Foundation