Can we change this to alias wchar instead of char? While this would be a breaking change, the ASCII Windows functions are arguably always wrong to use with D since a D char* is NOT an ascii nor Windows encoded string, so any code it "breaks" was already (perhaps) broken and should be changed anyway.

I know there's other win32 bindings we can download, but for just the common types, I like to use the built in aliases, and TCHAR, TSTR, etc., are common in copy/pasted MSDN code and can easily be subtly wrong with this.

A compromise I'd accept is putting the wchar aliases under a version(Unicode) so it is opt-in.


Any objections to me making this change? If no I'll do a pull request.

On Fri, 10 Jan 2014 00:37:06 -0000, Adam D. Ruppe <destructionator@gmail.com> wrote:

> Can we change this to alias wchar instead of char? While this would be a breaking change, the ASCII Windows functions are arguably always wrong to use with D since a D char* is NOT an ascii nor Windows encoded string, so any code it "breaks" was already (perhaps) broken and should be changed anyway.

IIRC wchar_t is actually UCS-2 (called Multibyte by devenv and various functions) which is a sub-set of UTF-16.  So, calling a windows W function with wchar[] could also break.. just in far fewer cases than char[] with A functions.

> I know there's other win32 bindings we can download, but for just the common types, I like to use the built in aliases, and TCHAR, TSTR, etc., are common in copy/pasted MSDN code and can easily be subtly wrong with this.
>
> A compromise I'd accept is putting the wchar aliases under a version(Unicode) so it is opt-in.

As far as I am aware there is no good reason to prefer the ascii functions over the multibyte ones.  So, I think defaulting to multibyte is a reasonable decision.

Having a way to opt back into ascii would be desirable in some cases though.  So, I think we want both sets of aliases in version blocks (Ascii and Multibyte) and we actually want the compiler to define the default of Multibyte which would be overridden by version=Ascii on the command line.

Remind me, cos I haven't looked in ages.  Do we define prototypes for both the A and W versions of functions outside of version() blocks?

Then use version blocks to alias either the W or A to a name without either? (in the same way the windows headers do)

Regan

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On Friday, 10 January 2014 at 14:02:13 UTC, Regan Heath wrote:
> IIRC wchar_t is actually UCS-2

eeek, I think you're right. I thought that changed a while ago but doesn't look like it. Megannoying... but still better than ascii at least.

> Having a way to opt back into ascii would be desirable in some cases though.  So, I think we want both sets of aliases in version blocks (Ascii and Multibyte) and we actually want the compiler to define the default of Multibyte which would be overridden by version=Ascii on the command line.

That would work for me.

> Remind me, cos I haven't looked in ages.  Do we define prototypes for both the A and W versions of functions outside of version() blocks?

There's very few definitions of the W functions in druntime at all; it uses only the A versions for the most part.

> Then use version blocks to alias either the W or A to a name without either? (in the same way the windows headers do)

The Win32 headers on dsource do this, but druntime doesn't. Since druntime is so woefully incomplete, to do real work you're almost always doing your own declarations or using a downloaded binding anyway, but still, i'd like at least the basic types in core.sys.windows.windows to be sane. (BTW, mixing these is a pain: I was doing a COM server and started with druntime's definition. But I had to add automation and druntime doesn't have IDispatch, so I moved to the dsource.org bindings.... and then there were conflicts between its IUnknown and druntime's IUnknown. So the little bit of code I imported from the druntime lib had to be worked around somehow. Soooo annoying.

I'd love for dmd to come with complete bindings and library files, and most the Windows D devs seem to agree, but it is apparently easier said than realized. But doing these basic types is a step forward too and shouldn't be as hard.)

On Friday, 10 January 2014 at 00:37:07 UTC, Adam D. Ruppe wrote:
> Can we change this to alias wchar instead of char? While this would be a breaking change, the ASCII Windows functions are arguably always wrong to use with D since a D char* is NOT an ascii nor Windows encoded string, so any code it "breaks" was already (perhaps) broken and should be changed anyway.

It may opreate in a controlled environment, where all characters are ascii. I hate such assumptions though.

> I know there's other win32 bindings we can download, but for just the common types, I like to use the built in aliases, and TCHAR, TSTR, etc., are common in copy/pasted MSDN code and can easily be subtly wrong with this.
>
> A compromise I'd accept is putting the wchar aliases under a version(Unicode) so it is opt-in.

version(Unicode) is a bug in itself. I'd say, drop ansi bindings entirely, they exist only for source-compatibility with C code written for win9x.

On Sat, 11 Jan 2014 10:04:44 -0000, Kagamin <spam@here.lot> wrote:
> On Friday, 10 January 2014 at 00:37:07 UTC, Adam D. Ruppe wrote:
>> I know there's other win32 bindings we can download, but for just the common types, I like to use the built in aliases, and TCHAR, TSTR, etc., are common in copy/pasted MSDN code and can easily be subtly wrong with this.
>>
>> A compromise I'd accept is putting the wchar aliases under a version(Unicode) so it is opt-in.
>
> version(Unicode) is a bug in itself. I'd say, drop ansi bindings entirely, they exist only for source-compatibility with C code written for win9x.

Unfortunately there are still loads of apps using the ANSI bindings and if someone were to attempt to port these to D having the ANSI bindings available (even if they have to say Version=ANSI on the command line) would be beneficial.  Porting is one thing, having to ANSI->unicode correct at the same time is a nightmare.  Better to allow them a two-step port :)

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On Friday, 10 January 2014 at 14:02:13 UTC, Regan Heath wrote:
>
> IIRC wchar_t is actually UCS-2 (called Multibyte by devenv and various functions) which is a sub-set of UTF-16.  So, calling a windows W function with wchar[] could also break.. just in far fewer cases than char[] with A functions.
>
IIRC Microsoft did change from UCS-2 to UTF-16 with Windows 2000
(maybe XP).

On Mon, 13 Jan 2014 13:37:54 -0000, Olivier Pisano
<olivier.pisano@laposte.net> wrote:

> On Friday, 10 January 2014 at 14:02:13 UTC, Regan Heath wrote:
>>
>> IIRC wchar_t is actually UCS-2 (called Multibyte by devenv and various functions) which is a sub-set of UTF-16.  So, calling a windows W function with wchar[] could also break.. just in far fewer cases than char[] with A functions.
>>
> IIRC Microsoft did change from UCS-2 to UTF-16 with Windows 2000
> (maybe XP).

Interesting.  I think XP SP3 came out about the same time, so perhaps it has support - or it can be installed separately.  Google tells me windows server 2000 is perhaps correct, except there may still be some "issues":

http://stackoverflow.com/questions/7870014/how-does-windows-wchar-t-handle-unicode-characters-outside-the-basic-multilingua

In short, you can put UTF-16 in wchar_t, but not all /applications/ will deal with it perfectly.  I expect the API to deal with it however, and that's all we really care about.

In any case, I think we all agree that the W functions should be the default.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/