www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - core.sys.windows.windows and TCHAR

reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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.
Jan 09 2014
next sibling parent reply "Regan Heath" <regan netmail.co.nz> writes:
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/
Jan 10 2014
next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
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.)
Jan 10 2014
prev sibling parent reply "Olivier Pisano" <olivier.pisano laposte.net> writes:
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).
Jan 13 2014
parent "Regan Heath" <regan netmail.co.nz> writes:
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/
Jan 13 2014
prev sibling parent reply "Kagamin" <spam here.lot> writes:
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.
Jan 11 2014
parent "Regan Heath" <regan netmail.co.nz> writes:
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/
Jan 13 2014