On Wed, 23 May 2012 20:54:44 +0100, Jacob Carlborg d...@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
On Wed, 23 May 2012 21:13:47 +0100, Michael p...@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:
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
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.
On Wednesday, 23 May 2012 at 04:01:05 UTC, Mehrdad wrote:
I hope this includes SNN.lib, which also uses ANSI functions...
Well, you can't fix C because C explicitly ignores string
encoding and thoughtlessly passes strings around without any
transcoding. Though, D bindings suggest that C
On 23/05/2012 15:16, Kagamin wrote:
snip
Well, you can't fix C because C explicitly ignores string encoding and
thoughtlessly
passes strings around without any transcoding. Though, D bindings suggest that
C functions
accept utf-8 strings
A lot of C functions do. Indeed, this is one of the
On 22/05/2012 19:24, Dmitry Olshansky wrote:
snip
* in D it's too easy to make a mistake by passing UTF-8 string pointer
to such function
That's just as easy in almost any language. It's part of why so many websites have
character encoding bugs.
snip
And last but not least:
- *W were
In WinAPI we have: LoadLibraryA/W, but not GetProcAddressA/W
because PE COFF limitations exists.
Walter Bright
The user can decide what to use or not use from it.
+1. For me LoadLibraryA works well.
256 max path
It's FS limitation.
On 23.05.2012 23:29, Michael wrote:
In WinAPI we have: LoadLibraryA/W, but not GetProcAddressA/W because PE
COFF limitations exists.
Walter Bright
The user can decide what to use or not use from it.
+1. For me LoadLibraryA works well.
256 max path
It's FS limitation.
Nope. Quoting random
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.
--
/Jacob Carlborg
approximately 32,000 characters...
I know it ;) But it's platform specific kung-fu.
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
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
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
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:
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
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
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
* 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
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
Yeah let 'em burn!
On 5/22/2012 12:32 PM, Martin Nowak wrote:
* it performs worse because Windows has to convert ASCII string to UTF-16 first
Is that a fact?
Yes. Windows internally is all 16 bit Unicode.
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
On Wed, May 23, 2012 at 12:31 AM, Trass3r u...@known.com wrote:
Yeah let 'em burn!
Kill it! Kill it with fire!!!
+1
--
Bye,
Gor Gyolchanyan.
On 23.05.2012 0:41, Walter Bright wrote:
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
I hope this includes SNN.lib, which also uses ANSI functions...
26 matches
Mail list logo
