Jump to page: 1 2 3
Thread overview
Let's schedule WinAPI ASCII functions for deprecation!
May 22, 2012
Denis Shelomovskij
May 22, 2012
Dmitry Olshansky
May 22, 2012
Dmitry Olshansky
May 22, 2012
Roman D. Boiko
May 22, 2012
Roman D. Boiko
May 23, 2012
Stewart Gordon
May 22, 2012
Denis Shelomovskij
May 22, 2012
Martin Nowak
May 22, 2012
Dmitry Olshansky
May 22, 2012
Walter Bright
May 22, 2012
Trass3r
May 22, 2012
Gor Gyolchanyan
May 22, 2012
Walter Bright
May 22, 2012
Dmitry Olshansky
May 24, 2012
Denis Shelomovskij
May 23, 2012
Mehrdad
May 23, 2012
Kagamin
May 23, 2012
Stewart Gordon
May 23, 2012
Jacob Carlborg
May 24, 2012
Regan Heath
May 23, 2012
Michael
May 23, 2012
Dmitry Olshansky
May 23, 2012
Michael
May 23, 2012
Dmitry Olshansky
May 24, 2012
Regan Heath
May 24, 2012
Michael
May 22, 2012
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
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
>> 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
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
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
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
> * 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
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
Yeah let 'em burn!
May 22, 2012
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