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.

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/

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

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

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

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.

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/