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