View mode: basic / threaded / horizontal-split · Log in · Help
May 22, 2012
Re: Let's schedule WinAPI ASCII functions for deprecation!
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
Re: Let's schedule WinAPI ASCII functions for deprecation!
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
Re: Let's schedule WinAPI ASCII functions for deprecation!
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
Re: Let's schedule WinAPI ASCII functions for deprecation!
I hope this includes SNN.lib, which also uses ANSI functions...
May 23, 2012
Re: Let's schedule WinAPI ASCII functions for deprecation!
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
Re: Let's schedule WinAPI ASCII functions for deprecation!
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
Re: Let's schedule WinAPI ASCII functions for deprecation!
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
Re: Let's schedule WinAPI ASCII functions for deprecation!
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
Re: Let's schedule WinAPI ASCII functions for deprecation!
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
Re: Let's schedule WinAPI ASCII functions for deprecation!
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
1 2 3
Top | Discussion index | About this forum | D home