www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - win32 from master: unicode functions by default?

reply Andre <andre s-e-a-p.de> writes:
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é
Nov 11 2015
parent reply Mike Parker <aldacron gmail.com> writes:
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.
Nov 11 2015
next sibling parent Andre <andre s-e-a-p.de> writes:
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é
Nov 11 2015
prev sibling parent reply Jonathan M Davis via Digitalmars-d-learn writes:
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
Nov 12 2015
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
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
Nov 12 2015
parent Kagamin <spam here.lot> writes:
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.
Nov 13 2015
prev sibling parent reply Kagamin <spam here.lot> writes:
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.
Nov 13 2015
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
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.
Nov 13 2015
parent Kagamin <spam here.lot> writes:
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.
Nov 13 2015