Let's schedule WinAPI ASCII functions for deprecation!
Dmitry Olshansky
dmitry.olsh at gmail.com
Tue May 22 11:24:09 PDT 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
More information about the Digitalmars-d
mailing list