May 23, 2012 Re: Let's schedule WinAPI ASCII functions for deprecation! | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dmitry Olshansky | > approximately 32,000 characters...
I know it ;) But it's platform specific kung-fu.
|
May 23, 2012 Re: Let's schedule WinAPI ASCII functions for deprecation! | ||||
---|---|---|---|---|
| ||||
Posted in reply to Michael | On 24.05.2012 0:13, Michael wrote: >> approximately 32,000 characters... > > I know it ;) But it's platform specific kung-fu. > It's the only game in M$ town ;) -- Dmitry Olshansky |
May 24, 2012 Re: Let's schedule WinAPI ASCII functions for deprecation! | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | On Wed, 23 May 2012 20:54:44 +0100, Jacob Carlborg <doob@me.com> wrote: > On 2012-05-23 20:34, Stewart Gordon wrote: > >> What is "C encoding"? > > Since C doesn't really have a concept of encodings it would be whatever a given application/library decides it is. All the more reason to use byte/ubyte as D's equivalent to C's char. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/ |
May 24, 2012 Re: Let's schedule WinAPI ASCII functions for deprecation! | ||||
---|---|---|---|---|
| ||||
Posted in reply to Michael | On Wed, 23 May 2012 21:13:47 +0100, Michael <pr@m1xa.com> wrote: >> approximately 32,000 characters... > > I know it ;) But it's platform specific kung-fu. And, if you start to dig a bit things can get a bit hairy in places: http://blogs.msdn.com/b/bclteam/archive/2007/02/13/long-paths-in-net-part-1-of-3-kim-hamilton.aspx http://blogs.msdn.com/b/bclteam/archive/2007/03/26/long-paths-in-net-part-2-of-3-long-path-workarounds-kim-hamilton.aspx http://blogs.msdn.com/b/bclteam/archive/2008/07/07/long-paths-in-net-part-3-of-3-redux-kim-hamilton.aspx R -- Using Opera's revolutionary email client: http://www.opera.com/mail/ |
May 24, 2012 Re: Let's schedule WinAPI ASCII functions for deprecation! | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 23.05.2012 0:41, Walter Bright написал: > 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. > The key point is what does it mean "interface"? An ability to load DLL and get symbols from it is enough to use every function. Is it an interface? You say "no". It's common in C/C++ to use WinAPI functions without A/W postfixes because preprocessor defines it according to your preferences. Is it an interface? You say "no". Functions like C's memmove are deprecated in VC headers on Windows because they are unsafe. Is it an interface? You say "no". WinAPI functions are more than just C definitions, they have IDL to allow user to avoid pointers and exit code checking. Is it an interface? You say "no". There is no such macros in Windows headers even for dmc and there is no talks at all to generate good D wrappers for WinAPI functions based on its IDL. *A functions are in WinAPI headers obviously for backward compatibility only. Are they definitions an interface? You say "yes". And I completely disagree with the last 2 points. I just want to show that this "principle" isn't as well-shaped as it can look at first sight. -- Денис В. Шеломовский Denis V. Shelomovskij |
May 24, 2012 Re: Let's schedule WinAPI ASCII functions for deprecation! | ||||
---|---|---|---|---|
| ||||
Posted in reply to Regan Heath | I knew it till an .net era. Main line is even Windows may handle it in a wrong way. WinAPi - interface "as is". So let user decides to use or not. |
Copyright © 1999-2021 by the D Language Foundation