Walter, some few days a go I asked about typedefing the std.c.windows.windows module.

One of the comments you made in responce to it was about not wishing to change the definitions WRT the doco.

Unfortunately, the ANSI and Wide versions of the various windows functions need to be accounted for.  Now I note that in the windows module functions are declared as ANSI more than Wide.

Having to know when you need to distinguish between the two is a pain.  It is truely a pity that we can't just let overloading work or have the linker search for A or W versions as necessary.

Has anyone put any thought into this?

Scott Egan wrote:
> Walter, some few days a go I asked about typedefing the
> std.c.windows.windows module.
> 
> One of the comments you made in responce to it was about not wishing to
> change the definitions WRT the doco.
> 
> Unfortunately, the ANSI and Wide versions of the various windows functions
> need to be accounted for.  Now I note that in the windows module functions
> are declared as ANSI more than Wide.
> 
> Having to know when you need to distinguish between the two is a pain.  It
> is truely a pity that we can't just let overloading work or have the linker
> search for A or W versions as necessary.
> 
> Has anyone put any thought into this?
> 
> 

This site (Japanese): http://hp.vector.co.jp/authors/VA028375/d/ has nicely packed import modules for the Win32 API functions and translation of it's macros to d inline functions. There are ANSI and Unicode versions. You should take a look.

Maybe we could convince Walter to bundle the package with the official DMD distribution.


-- 
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------

On Mon, 03 May 2004 16:40:38 -0500, Julio César Carrascal Urquijo <adnoctum@phreaker.net> wrote:

>Scott Egan wrote:
>> Walter, some few days a go I asked about typedefing the std.c.windows.windows module.
>> 
>> One of the comments you made in responce to it was about not wishing to change the definitions WRT the doco.
>> 
>> Unfortunately, the ANSI and Wide versions of the various windows functions need to be accounted for.  Now I note that in the windows module functions are declared as ANSI more than Wide.
>> 
>> Having to know when you need to distinguish between the two is a pain.  It is truely a pity that we can't just let overloading work or have the linker search for A or W versions as necessary.
>> 
>> Has anyone put any thought into this?
>> 
>> 
>
>This site (Japanese): http://hp.vector.co.jp/authors/VA028375/d/ has nicely packed import modules for the Win32 API functions and translation of it's macros to d inline functions. There are ANSI and Unicode versions. You should take a look.
>
>Maybe we could convince Walter to bundle the package with the official DMD distribution.

there is now a place where you can contribte ...
http://www.dsource.org/projects/core32/
the files can be download from
http://www.geocities.com/one_mad_alien/dcode/ if you don't have
subversion.
over the next few weeks I will be contacting the Japanese developer to
see if we can't merge our effort and get more headers ported.
currently (and until there is full win32 support in phobos) the libs
on dsource have a build version(STANDALONE) if you don't want to
include std.c.wndows.*;
and version(UNICODE) for to make the undecorated functions W not A.
I have also considered a templated struct (as a templated namespace)
wrapper i.e.
struct win32( T: char ) {
	func( char* foo ) { funcA( foo ); }
	... etc ...
}
struct win32( T: wchar ) {
	func( wchar* foo ) { funcW( foo ); }
	... etc ...
}
struct win32( T: dchar ) {
	func( dchar* foo ) { funcW( utf.32to16z(foo) ); }
	... etc ...
}
then use alias win32.core.win32!(wchar) win32; // or similar

but personally I feel a better solution would be via compiler alias
and having a true String class (conceptual class not nec. a real one)
so you could write
func( char * foo ) = alias funcA( foo );
func( wchar * foo ) = alias funcW( foo );
func( String foo ) = alias funcW( foo ); // called if "" is used will
call uft.8to16 if the string is utf8/ansi not wchar[] etc.

as the current "..."->char/wchar is a pain (either that or make "..." wchar like Java, forget the days when you could not have non latin chars in strings and put the 'u' back in colour :)

there is a forum on dsource if you have feelings about how we should continue with the current D compiler :)

Mike.

> forget the days when you could not have non latin
> chars in strings and put the 'u' back in colour :)

let's go easy on us yankees - we meant well.  I think.

Mike Wynn wrote:
> there is now a place where you can contribte ...
> http://www.dsource.org/projects/core32/
> the files can be download from
> http://www.geocities.com/one_mad_alien/dcode/ if you don't have
> subversion.

Nice.

> over the next few weeks I will be contacting the Japanese developer to
> see if we can't merge our effort and get more headers ported.
> currently (and until there is full win32 support in phobos) the libs
> on dsource have a build version(STANDALONE) if you don't want to
> include std.c.wndows.*;

IIRC you can't import both packages (Name collitions).

> and version(UNICODE) for to make the undecorated functions W not A.

Yes, this is needed.

> I have also considered a templated struct (as a templated namespace)
> wrapper i.e.
> struct win32( T: char ) {
> 	func( char* foo ) { funcA( foo ); }
> 	... etc ...
> }
> struct win32( T: wchar ) {
> 	func( wchar* foo ) { funcW( foo ); }
> 	... etc ...
> }
> struct win32( T: dchar ) {
> 	func( dchar* foo ) { funcW( utf.32to16z(foo) ); }
> 	... etc ...
> }
> then use alias win32.core.win32!(wchar) win32; // or similar
> 
> but personally I feel a better solution would be via compiler alias
> and having a true String class (conceptual class not nec. a real one)
> so you could write
> func( char * foo ) = alias funcA( foo );
> func( wchar * foo ) = alias funcW( foo );
> func( String foo ) = alias funcW( foo ); // called if "" is used will
> call uft.8to16 if the string is utf8/ansi not wchar[] etc.
> 
> as the current "..."->char/wchar is a pain (either that or make "..."
> wchar like Java, forget the days when you could not have non latin
> chars in strings and put the 'u' back in colour :)
> 
> there is a forum on dsource if you have feelings about how we should
> continue with the current D compiler :)
> 
> Mike.

For the string handling there's a TCHAR alias that is a wchar* or char* depending on the version.

About using a string class, my opinion is to have a set of import modules as close to the Win32 API headers as posible, and add separate lightweight layers on top with facilities like string conversions and errors codes translated to exceptions, etc...

What do you think about it?

-- 
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------

On Fri, 07 May 2004 10:24:52 -0500, Julio César Carrascal Urquijo <adnoctum@phreaker.net> wrote:

>Mike Wynn wrote:
>> there is now a place where you can contribte ...
>> http://www.dsource.org/projects/core32/
>> the files can be download from
>> http://www.geocities.com/one_mad_alien/dcode/ if you don't have
>> subversion.
>
>Nice.

cheers.

>
>> over the next few weeks I will be contacting the Japanese developer to see if we can't merge our effort and get more headers ported. currently (and until there is full win32 support in phobos) the libs on dsource have a build version(STANDALONE) if you don't want to include std.c.wndows.*;
>
>IIRC you can't import both packages (Name collitions).

do you means std.c.windows and win32.api ? if so then there is a new
snap shot that is 0.88 aware.
(http://svn.dsource.org/svn/projects/l8night/downloads/)
its in the l8night project area for the moment.
is you set version(STANDALONE) you should not import std.c.window.*,
or any of phobos (such as std.file) that does, you'll just have to
hack your local phobos.


if you mean win32.api and
http://hp.vector.co.jp/authors/VA028375/d/windows.h.html
then yes they are do colide, I am in the progress of sorting out a
merge (either take the bits I need, or join the two projects).

>
>> and version(UNICODE) for to make the undecorated functions W not A.
>
>Yes, this is needed.
>
>> I have also considered a templated struct (as a templated namespace)
>> wrapper i.e.
>> struct win32( T: char ) {
>> 	func( char* foo ) { funcA( foo ); }
>> 	... etc ...
>> }
>> struct win32( T: wchar ) {
>> 	func( wchar* foo ) { funcW( foo ); }
>> 	... etc ...
>> }
>> struct win32( T: dchar ) {
>> 	func( dchar* foo ) { funcW( utf.32to16z(foo) ); }
>> 	... etc ...
>> }
>> then use alias win32.core.win32!(wchar) win32; // or similar
>> 
>> but personally I feel a better solution would be via compiler alias
>> and having a true String class (conceptual class not nec. a real one)
>> so you could write
>> func( char * foo ) = alias funcA( foo );
>> func( wchar * foo ) = alias funcW( foo );
>> func( String foo ) = alias funcW( foo ); // called if "" is used will
>> call uft.8to16 if the string is utf8/ansi not wchar[] etc.
>> 
>> as the current "..."->char/wchar is a pain (either that or make "..." wchar like Java, forget the days when you could not have non latin chars in strings and put the 'u' back in colour :)
>> 
>> there is a forum on dsource if you have feelings about how we should continue with the current D compiler :)
>> 
>> Mike.
>
>For the string handling there's a TCHAR alias that is a wchar* or char* depending on the version.

good point, did I get that right?

>
>About using a string class, my opinion is to have a set of import modules as close to the Win32 API headers as posible, and add separate lightweight layers on top with facilities like string conversions and errors codes translated to exceptions, etc...
>
>What do you think about it?

that would become part of my DFC, which is rather scrappy at present I only wrote enough for my own uses [you can write windows app with it] my plan was/is to have the win32.* modules as close to the windows header as is humanly possible, and D-isms would be put into suplementry libs (for now my DFC)

but the more I use it (and get frustrated with "..." being char/wchar depending on context) I'm becoming very must of the opinion that it should all be wchar, if D gets ported to VxWorks or ECos, well that don't effect the Windows API, hands up who's got less than 64Mb on their PC and wants 1Mb ansi strings?

Mike.

"Brad Anderson" <brad@dsource.dot.org> wrote in message news:c7f2u3$1lss$1@digitaldaemon.com...
> > forget the days when you could not have non latin
> > chars in strings and put the 'u' back in colour :)
>
> let's go easy on us yankees - we meant well.  I think.

I'm totally confused. One of my US friends nearly reaches through the T1 and grabs me by the throat if I call him a Yankee.

Can someone explain the rules? (We're thinking of moving US-ward next year, and it would be good to know what not to say to whom.)

Matthew wrote:
> I'm totally confused. One of my US friends nearly reaches through the T1 and
> grabs me by the throat if I call him a Yankee.
> 
> Can someone explain the rules? (We're thinking of moving US-ward next year, and
> it would be good to know what not to say to whom.)
> 

Yankee can be a good thing but it depends on who you're saying it too. Some people take it as a sort of silly way of saying patriotic, others take it as hick, and yet others take it as a slur against Americans.

I guess the most politically correct way is to not use it at all, but most people don't care... I think it's regional, but I couldn't name the regions for you.  (might be southerners, but then again might be touchy northerners.)

http://www.urbandictionary.com/define.php?term=Yankee (not there but look at the suggestions.)
http://www.google.com/search?q=define%3Ayankee

-[Unknown]

Mike Wynn wrote:
>>IIRC you can't import both packages (Name collitions).
> 
> 
> do you means std.c.windows and win32.api ? if so then there is a new
> snap shot that is 0.88 aware.
> (http://svn.dsource.org/svn/projects/l8night/downloads/)
> its in the l8night project area for the moment.
> is you set version(STANDALONE) you should not import std.c.window.*,
> or any of phobos (such as std.file) that does, you'll just have to
> hack your local phobos.
> 
> 
> if you mean win32.api and
> http://hp.vector.co.jp/authors/VA028375/d/windows.h.html
> then yes they are do colide, I am in the progress of sorting out a
> merge (either take the bits I need, or join the two projects).

Yes, I meant importing std.c.windows.windows and the one at hp.vector.co.jp.

Why use STANDALONE? If we make a good job, Great Walter will replace std.c.windows.windows with ours by 0.89 ;)

Now seriously, do we really need to be compatible with Phobos' windows module? I don't see any benefit in that.

Anyway, if you don't mind, I'll start working with "commdlg.d" during this weekend and send you a patch by monday.

See you.


-- 
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------

On Fri, 07 May 2004 17:41:52 -0500, Julio César Carrascal Urquijo <adnoctum@phreaker.net> wrote:

>
>Yes, I meant importing std.c.windows.windows and the one at hp.vector.co.jp.

well thats to be expected, they are the same work done by two different ppl!

>
>Why use STANDALONE? If we make a good job, Great Walter will replace std.c.windows.windows with ours by 0.89 ;)
>
>Now seriously, do we really need to be compatible with Phobos' windows module? I don't see any benefit in that.
>

because until it is part of phobos ppl have a choise to use win32.api with phobos std.c.windows.windows; or not.

my windows port was done a long time ago, I gave up extending it for
two reasons
A) Walter kept adding bits to phobos that clashed
B) no one else seemed to be using it (and it did all I needed).

>Anyway, if you don't mind, I'll start working with "commdlg.d" during this weekend and send you a patch by monday.
>
plz make sure you get the latest version from either http://www.geocities.com/one_mad_alien/dcode/index.html http://svn.dsource.org/svn/projects/l8night/downloads/

core32_2004.05.07.src.zip
(updated for dmd 0.88)

what needs changing ? plz put any comments onto the dsource forum, if you are intending on merging code from hp.vector.co.jp plz wait as I have not had a reply from the owner of that source allowing us the rights to use that in my/our win32 lib.

other wise, best of luck, check with Brad and get a svn login so the rest of us get your changes.

>See you.