Hi,

by using the win32 library from master, the functions aliases
to the ansi windows functions (...A) instead of the unicode functions (...W).
Is there a way to control this behavior beside using the explicit function
names (A/W)?

Kind regards
André

On Thursday, 12 November 2015 at 04:58:42 UTC, Andre wrote:
> Hi,
>
> by using the win32 library from master, the functions aliases
> to the ansi windows functions (...A) instead of the unicode functions (...W).
> Is there a way to control this behavior beside using the explicit function
> names (A/W)?
>
> Kind regards
> André

version=Unicode on the compiler command line.

On Thursday, 12 November 2015 at 05:08:25 UTC, Mike Parker wrote:
> On Thursday, 12 November 2015 at 04:58:42 UTC, Andre wrote:
>> Hi,
>>
>> by using the win32 library from master, the functions aliases
>> to the ansi windows functions (...A) instead of the unicode functions (...W).
>> Is there a way to control this behavior beside using the explicit function
>> names (A/W)?
>>
>> Kind regards
>> André
>
> version=Unicode on the compiler command line.

perfect. Thanks a lot.

Kind regards
André

On Thursday, November 12, 2015 05:08:24 Mike Parker via Digitalmars-d-learn wrote:
> On Thursday, 12 November 2015 at 04:58:42 UTC, Andre wrote:
> > Hi,
> >
> > by using the win32 library from master, the functions aliases
> > to the ansi windows functions (...A) instead of the unicode
> > functions (...W).
> > Is there a way to control this behavior beside using the
> > explicit function
> > names (A/W)?
> >
> > Kind regards
> > André
>
> version=Unicode on the compiler command line.

It seems pretty wrong for the A versions to be the default though...

Still, even in C++ code, I've generally taken the approach of using the W functions explicitly in order to avoid any potential problems with A functions being called accidentally. Regardless, the whole A vs W thing with Win32 is not exactly one of its nicer features. :|

- Jonathan M Davis

On Thursday, 12 November 2015 at 15:58:53 UTC, Jonathan M Davis wrote:
> On Thursday, November 12, 2015 05:08:24 Mike Parker via

>> version=Unicode on the compiler command line.
>
> It seems pretty wrong for the A versions to be the default though...
>
> Still, even in C++ code, I've generally taken the approach of using the W functions explicitly in order to avoid any potential problems with A functions being called accidentally. Regardless, the whole A vs W thing with Win32 is not exactly one of its nicer features. :|
>
> - Jonathan M Davis

I've gotten into the same habit. But it appears the switch to dynamic loading has made it so that only the A versions or only the W versions are available. You no longer get both.

https://github.com/D-Programming-Language/druntime/blob/master/src/core/sys/windows/w32api.d#L85

On Thursday, 12 November 2015 at 15:58:53 UTC, Jonathan M Davis wrote:
> It seems pretty wrong for the A versions to be the default though...

For my money it's a plain bug in bindings :)

> Still, even in C++ code, I've generally taken the approach of using the W functions explicitly in order to avoid any potential problems with A functions being called accidentally. Regardless, the whole A vs W thing with Win32 is not exactly one of its nicer features. :|

In C headers it's a backward compatibility for code written for win9x. As such it doesn't make much sense for new code and especially for D code. The mess is a price for thoughtless copying.

On Friday, 13 November 2015 at 05:09:12 UTC, Mike Parker wrote:
> I've gotten into the same habit. But it appears the switch to dynamic loading has made it so that only the A versions or only the W versions are available. You no longer get both.
>
> https://github.com/D-Programming-Language/druntime/blob/master/src/core/sys/windows/w32api.d#L85

That only declares aliases without postfix, actual declarations are available unconditionally barring a few bugs.

On Friday, 13 November 2015 at 08:10:12 UTC, Kagamin wrote:
> On Thursday, 12 November 2015 at 15:58:53 UTC, Jonathan M Davis wrote:
>> It seems pretty wrong for the A versions to be the default though...
>
> For my money it's a plain bug in bindings :)

Yep, we don't support non-Unicode Windows versions anyway so there's no reason for this. It's not as important as in C though, since TCHAR does not have a big role in D - you will need to be explicit to which character type you convert to when converting from D strings anyway.

If only Microsoft would have adopted UTF-8 as an 8-bit locale... if only.

On Friday, 13 November 2015 at 08:44:33 UTC, Vladimir Panteleev wrote:
> If only Microsoft would have adopted UTF-8 as an 8-bit locale... if only.

Then you would need to do all TCHAR stuff from windows headers in order to conditionally compile for utf-8 for say Windows 20 and for utf-16 for previous versions.