Thread overview | ||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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! | ||||
---|---|---|---|---|
| ||||
Posted in reply to Denis Shelomovskij | 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! | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dmitry Olshansky | >> 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! | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dmitry Olshansky | 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! | ||||
---|---|---|---|---|
| ||||
Posted in reply to Roman D. Boiko | 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! | ||||
---|---|---|---|---|
| ||||
Posted in reply to Denis Shelomovskij | 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! | ||||
---|---|---|---|---|
| ||||
Posted in reply to Denis Shelomovskij | > * 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! | ||||
---|---|---|---|---|
| ||||
Posted in reply to Martin Nowak | 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! | ||||
---|---|---|---|---|
| ||||
Posted in reply to Denis Shelomovskij | Yeah let 'em burn! |
May 22, 2012 Re: Let's schedule WinAPI ASCII functions for deprecation! | ||||
---|---|---|---|---|
| ||||
Posted in reply to Denis Shelomovskij | 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.
|
Copyright © 1999-2021 by the D Language Foundation