Denis Koroskin wrote:
I'd like to raise 2 issues for a discussion.
First, Phobos makes calls to different functions, based on the OS we are
running on (e.g. CreateFileA vs. CreateFileW) and I wonder if it's
*really* necessary, since Microsoft has a Unicode Layer for those
Operating Systems.
All an application needs to do to call W API on those OS'es is link with
unicows.lib (which could be a part of Phobos). It does nothing on Win2k+
and only triggers on 9x OS family.
A very good overview of it is written here:
http://msdn.microsoft.com/en-us/goglobal/bb688166.aspx
The unicows doesn't do anything more than what Phobos does in attempting
to translate unicode into the local code page. All that using unicows
would do is cause confusion and installation problems as the user would
have to get a copy of unicows and install it. unicows doesn't exist on
default Windows 9x installations.
There is simply no advantage to unicows.
Second, "A" API accepts ansi strings as parameters, not UTF-8 strings. I
think this should be reflected in the function signatures, since D
encourages distinguishing between UTF-8 and ANSI strings and not store
the latter as char[].
LPCSTR currently resolves to char*/const(char)*, but it could be better
for it to be an alias to ubyte*/const(ubyte)* so that user couldn't pass
unicode string to an API that doesn't expect one. The same is applicable
to other APIs, too, for example, how does C stdlib co-operate with
Unicode? I.e. is core.stdc.stdio.fopen() unicode-aware?
Calling C functions means one needs to pass them what the host C system
expects. C itself doesn't define what character set char* is. If you use
the Phobos functions, those are required to work with unicode.
