May 22, 2012
On 5/22/2012 12:32 PM, Martin Nowak wrote:
>> * it performs worse because Windows has to convert ASCII string to UTF-16 first
> Is that a fact?

Yes. Windows internally is all 16 bit Unicode.
May 22, 2012
On Wed, May 23, 2012 at 12:31 AM, Trass3r <un@known.com> wrote:

> Yeah let 'em burn!
>

Kill it! Kill it with fire!!!
+1

-- 
Bye,
Gor Gyolchanyan.


May 22, 2012
On 23.05.2012 0:41, Walter Bright wrote:
> On 5/22/2012 11:11 AM, Denis Shelomovskij wrote:
>> Since Win9x isn't supported any more why do we have ASCII WinAPI
>> functions in
>> druntime's core.sys.windows.windows (and, possibly, other places)?
>>
>> Reasons against *A functions:
>> * using of every such function is unsafe (with really seldom
>> exceptions like
>> LoadLibraryA("ntdll")) because inability to encode non-ASCII
>> characters to OEM
>> encoding will almost always give unpredictable results for programmer
>> (simple
>> test: you, reader, what will happen?);
>> * in D it's too easy to make a mistake by passing UTF-8 string pointer
>> to such
>> function because D has no string types other than UTF and elimination
>> of such
>> function is the only solution unless ASCII string type is created
>> * it performs worse because Windows has to convert ASCII string to
>> UTF-16 first
>>
>> And yes, druntime already has encoding bugs because of using such
>> functions.
>
> First off, I agree that druntime and phobos must not use the A functions
> without a very, very good reason.
>

Right.

> Secondly, as a matter of principle, we are not going to fix, improve,
> refactor, or re-engineer the Windows API, nor any other operating system
> API, nor the C Standard Library, no matter how tempting that may be. The
> job of the D interface modules is to simply provide an interface to
> them, as thin and direct as possible, without editorial comment. The
> user can decide what to use or not use from it.
>

Again correct. The trick is that the way *A functions are provided is in fact wrong edit! It signatres are basically saying "hello I'm explicit Win32 API multi-byte string binding and I accept UTF-8 string " ... WTF?!

The fact that they are horribly outdated is the perfect moment to both fix the issue and get rid of junk.

-- 
Dmitry Olshansky
May 23, 2012
I hope this includes SNN.lib, which also uses ANSI functions...
May 23, 2012
On Wednesday, 23 May 2012 at 04:01:05 UTC, Mehrdad wrote:
> I hope this includes SNN.lib, which also uses ANSI functions...

Well, you can't fix C because C explicitly ignores string encoding and thoughtlessly passes strings around without any transcoding. Though, D bindings suggest that C functions accept utf-8 strings which leads to assumption that those functions will act properly on utf-8 strings. I'd say that's a bug in bindings: C strings are specified to be in C encoding, not utf-8 encoding. I think, conversion from D string to C string should require at least a cast.
May 23, 2012
On 23/05/2012 15:16, Kagamin wrote:
<snip>
> Well, you can't fix C because C explicitly ignores string encoding and thoughtlessly
> passes strings around without any transcoding. Though, D bindings suggest that C functions
> accept utf-8 strings

A lot of C functions do.  Indeed, this is one of the considerations made in the design of UTF-8.

> which leads to assumption that those functions will act properly on
> utf-8 strings. I'd say that's a bug in bindings: C strings are specified to be in C
> encoding,

What is "C encoding"?

> not utf-8 encoding. I think, conversion from D string to C string should require
> at least a cast.

Several people have dealt with this by using byte or ubyte as D's equivalent of the C char type.

Stewart.
May 23, 2012
On 22/05/2012 19:24, Dmitry Olshansky wrote:
<snip>
>> * in D it's too easy to make a mistake by passing UTF-8 string pointer
>> to such function

That's just as easy in almost any language.  It's part of why so many websites have character encoding bugs.

<snip>
> And last but not least:
> - *W were supported on Win98+ Second Edition with official addon - Unicode Layer for
> Windows ;)
<snip>

I've heard of MS Layer for Unicode - don't know if that's what you meant or you're talking about something else.  From what I recall reading, MSLU had the problem that EXEs have to be explicitly built to depend on it.  So a typical app targeted at Win2000 and above wouldn't work with it, and you can't (at least easily) make an app detect whether Unicode is available and use it if it's there.

Stewart.
May 23, 2012
In WinAPI we have: LoadLibraryA/W, but not GetProcAddressA/W because  PE COFF limitations exists.

>Walter Bright
>The user can decide what to use or not use from it.
+1. For me LoadLibraryA works well.

> 256 max path
It's FS limitation.
May 23, 2012
On 23.05.2012 23:29, Michael wrote:
> In WinAPI we have: LoadLibraryA/W, but not GetProcAddressA/W because PE
> COFF limitations exists.
>
>> Walter Bright
>> The user can decide what to use or not use from it.
> +1. For me LoadLibraryA works well.
>
>> 256 max path
> It's FS limitation.

Nope. Quoting random top hit from google:

Individual components of a filename (i.e. each subdirectory along the path, and the final filename) are limited to 255 characters, and the total path length is limited to approximately 32,000 characters. However, you should generally try to limit path lengths to below 260 characters (MAX_PATH) when possible. See http://msdn.microsoft.com/en-us/library/aa365247.aspx for full details.

-- 
Dmitry Olshansky
May 23, 2012
On 2012-05-23 20:34, Stewart Gordon wrote:

> What is "C encoding"?

Since C doesn't really have a concept of encodings it would be whatever a given application/library decides it is.

-- 
/Jacob Carlborg