Re: Suggested Alternative Unicode Implementation (for Rudy+ miscothers)

In article <xn0fnn74c2d5ba200fnewsgroups@xxxxxxxxxxxx>,
newsgroups@xxxxxxxxxxxx says...

[*] Not quite sure, but I think this should be enough to make the code
fully Ansi. Did I forget something? If this is really all that is
needed, it could be a batch process.

No, not quite, because the VCL is still Unicode so your application will
now accept input that it previously did not.


There are two aspects to the problem:

1) The need to "Run To Stand Still" - i.e. for existing ANSI based code
to continue to safely run in an "ANSI world"

2) The idea that "supporting Unicode" is a simple case of changing from
ANSI strings (and APIs) to Unicode ones.


The obsession with propogating the myth of (2) is what has created (1).


Given that whatever the implementation details, CodeGear seem intent to
try to keep some compatability with existing applications I consider it
behoven on them to give priority to the needs and concerns of the
developers and users of those applications, rather than taking a route
which may make it easier for them.

(For sure, if it's easier for them then the users get SOME benefit
(faster delivery etc) but the question is whether that benefit is worth
the COST)



And every API call should explicitly call the -A version,

Why?

Why can we not have overloaded WinAPI declarations that bind to specific
A/W imports?

procedure Foo(aStr: PANSIChar); overload; external DLL name 'FooA';
procedure Foo(aStr: PWideChar); overload; external DLL name 'FooW';

This compiles perfectly fine, but maybe it doesn't work correctly for
some reason (have not got as far as a compiling and running test case.


And look at that! You don't even need a switch based directive to
"choose" the A/W API, you get the API appropriate to the sype of the
parameters you pass.

So if you DO have a switch that would enable "String" to mean
"ANSIString" in one unit and "UnicodeString" in another unit, each of
those units might contain code that references some API for which A and
W variants exist, and each will bind to the correct import at compile
time.

I thought this stuff was impossibly hard?

;)
.

Relevant Pages

  • Re: A (mild-mannered) defense of RosAsm Rocks !!!
    ... All functions that have a Unicode ... and ANSI implementation are Unicode first, ... this API is not available in Win9x without the ... Oh by the way the Coward is the asshole that wrote the peice of garbage ...
    (alt.lang.asm)
  • Re: Delphi 2009 - CG tip everything on ( only ) Unicode ?
    ... The Unicode versions of the Win32 API calls are faster then the ANSI ... file and folder names are in Unicode. ...
    (borland.public.delphi.non-technical)
  • Re: Another unicode problem
    ... coerces text from Unicode to ANSI, it is often a destructive process. ... ANSI API call trys to call a 'W' function, it will not be receiving the ... Pass the string using StrPtr. ...
    (microsoft.public.vb.general.discussion)
  • Re: Code Page problem in SetWindowText
    ... I've had lots of people insist that it is faster to use ANSI apps because "the strings are ... They don't realize that since all of WIndows is written in Unicode, every ANSI ... API, so ANSI would be inherently slower. ...
    (microsoft.public.vc.mfc)
  • Re: Call C DLL from VB.net-problem..array gains 4 bytes!
    ... No, Unicode strings don't, by definition, have a header with the size. ... you're writing code in C++, for example, the only difference between an ANSI ... which take an array of bytes. ... > Remember the DLL declaration... ...
    (microsoft.public.windowsce.app.development)
Loading