View mode: basic / threaded / horizontal-split · Log in · Help
May 22, 2012
Let's schedule WinAPI ASCII functions for deprecation!
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.

P.S.
Let's finally solve encoding problems that should be solved 10 years 
ago! By the way, Git+TurtoiseGit still has encoding problems on Windows 
and it is awful (see its changelog).

-- 
Денис В. Шеломовский
Denis V. Shelomovskij
May 22, 2012
Re: Let's schedule WinAPI ASCII functions for deprecation!
On 22.05.2012 22:11, 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.
>

Yes, let them burn! Burn, burn, burn!
Seriously.

For those  that are bend on compatibility, *A functions also are:
- security disasters
- limited in more then just one way: 256 max path, and so on and so forth

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

Not to mention the OEM encoding were never supported properly by D.
> P.S.
> Let's finally solve encoding problems that should be solved 10 years
> ago! By the way, Git+TurtoiseGit still has encoding problems on Windows
> and it is awful (see its changelog).
>


-- 
Dmitry Olshansky
May 22, 2012
Re: Let's schedule WinAPI ASCII functions for deprecation!
>> P.S.
>> Let's finally solve encoding problems that should be solved 10 years
>> ago! By the way, Git+TurtoiseGit still has encoding problems on Windows
>> and it is awful (see its changelog).
>>


forgot to mention that my GSOC project has support for legacy encodings 
as it's secondary goal. Check out:

TODOs, synopsis & status:
https://github.com/blackwhale/phobos/wiki/GSOC-Unicode-support/tree/gsoc-uni

Original proposal:
http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/dolsh/20002#

-- 
Dmitry Olshansky
May 22, 2012
Re: Let's schedule WinAPI ASCII functions for deprecation!
On Tuesday, 22 May 2012 at 18:39:46 UTC, Dmitry Olshansky wrote:
>
>>> P.S.
>>> Let's finally solve encoding problems that should be solved 
>>> 10 years
>>> ago! By the way, Git+TurtoiseGit still has encoding problems 
>>> on Windows
>>> and it is awful (see its changelog).
>>>
>
>
> forgot to mention that my GSOC project has support for legacy 
> encodings as it's secondary goal. Check out:
>
> TODOs, synopsis & status:
> https://github.com/blackwhale/phobos/wiki/GSOC-Unicode-support/tree/gsoc-uni
>
> Original proposal:
> http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/dolsh/20002#

Dmitry, your project looks really cool.

As for the topic, I would vote for that, too, but don't have 
enough knowledge to understand all possible consequences...
May 22, 2012
Re: Let's schedule WinAPI ASCII functions for deprecation!
On Tuesday, 22 May 2012 at 18:43:58 UTC, Roman D. Boiko wrote:
> Dmitry, your project looks really cool.
>
> As for the topic, I would vote for that, too, but don't have 
> enough knowledge to understand all possible consequences...
Especially I liked "...policy based design, thus exposing all of 
relevant tradeoffs".
May 22, 2012
Re: Let's schedule WinAPI ASCII functions for deprecation!
LPTSTR issue (it aliases char*) is already filled by Martin Nowak:
Issue 8132 - LPTSTR always aliases to LPSTR
http://d.puremagic.com/issues/show_bug.cgi?id=8132


-- 
Денис В. Шеломовский
Denis V. Shelomovskij
May 22, 2012
Re: Let's schedule WinAPI ASCII functions for deprecation!
> * it performs worse because Windows has to convert ASCII string to  
> UTF-16 first
Is that a fact?

> P.S.
> Let's finally solve encoding problems that should be solved 10 years  
> ago! By the way, Git+TurtoiseGit still has encoding problems on Windows  
> and it is awful (see its changelog).
>

Given that it only requires a 'w' suffix for literals it's a good choice.
May 22, 2012
Re: Let's schedule WinAPI ASCII functions for deprecation!
On 22.05.2012 23:32, Martin Nowak wrote:
>> * it performs worse because Windows has to convert ASCII string to
>> UTF-16 first
> Is that a fact?
>
>> P.S.
>> Let's finally solve encoding problems that should be solved 10 years
>> ago! By the way, Git+TurtoiseGit still has encoding problems on
>> Windows and it is awful (see its changelog).
>>
>
> Given that it only requires a 'w' suffix for literals it's a good choice.

http://stackoverflow.com/questions/7950271/windows-uses-utf-16-as-its-internal-encoding-what-exactly-does-this-mean

Second answer sheds some light on the topic.

From what I know of Windows NT, the kernel even doesn't use Z-strings 
most of the time. All stuff that can be called syscalls use a variation 
of L-strings for 16-bit width chars.

-- 
Dmitry Olshansky
May 22, 2012
Re: Let's schedule WinAPI ASCII functions for deprecation!
Yeah let 'em burn!
May 22, 2012
Re: Let's schedule WinAPI ASCII functions for deprecation!
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.

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.
« First   ‹ Prev
1 2 3
Top | Discussion index | About this forum | D home