Ansi vs Unicode API

Walter Bright newshound1 at digitalmars.com
Mon Nov 16 01:36:30 PST 2009


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.



More information about the Digitalmars-d mailing list