Improve company productivity with a Business Account.Sign Up

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1189
  • Last Modified:

What i really don't understand about Unicode (Delphi 2k9, 2k10, XE)

Hello Everybody!

Hey, sometime ago i asked about UNICODE and at that moment i really didnt need switch to UNICODE... i was using Delphi 2007 and skip the use of Delphi 2009/2010 since its UNICODE by default, make the app size greater and a little hard to convert all my codes...

But, there are things that i really don't understand... for example

Well, String become UnicodeString by the compiler... (UnicodeString is reference counted by Delphi instead of WideString... so UnicodeString has more performance) Char -> WideChar, PChar -> PWideChar and more

But, a lot of Windows functions/procedures still use "PAnsiChar" and others "PWideChar"... but why not use PWideChar them? And still using PAnsiChar?

Example WinExec uses PAnsiChar, its because in a PATH there is no Unicode Strings? (C:\Windows\Some Folder)
If true, then all my functions/procedures that will not support unicode characteres i must use "PAnsiChar" instead of PChar?

example, a DLL that return the instalattion path of my program

function GetInstallPath(lpBuffer: PAnsiChar): Integer; StdCall;

My doubt is, when to use or not UNICODE in the code!
and Windows will drop the support for ANSI futurelly?

Best Regards,
  • 4
  • 3
  • 3
  • +1
3 Solutions
Some of Win32 API functions have two version A (Ansi) and W (Unicode). But some of Win32 API functions have only one version A or W. You always can check MSDN site and see if function has Ansi or/and Unicode version.

WinExec is old function and it hasn't Unicode version.

But if you check CreateProcess you'll find that it has:
Unicode and ANSI names      CreateProcessW (Unicode) and CreateProcessA (ANSI)

>> My doubt is, when to use or not UNICODE in the code!

If you use your Delphi version >= 2009, I think it'll be easier to use Unicode than Ansi.

But if you develop dll and it will be use from non-Unicode program - you have to use Ansi

>> Windows will drop the support for ANSI futurelly?

Probably, by I don't think it will be soon
One general advice :
* You use String, Char & PChar in all general use, in your application core.
Depending on Delphi version, it will be the ANSI or Wide (Unicode) flavour that will be used at compile time, throughout all your VCL code. All managed as it should be, no unnecessary conversions.

* You use PANSIChar explicitly for all your dll interfaces, or the few places where you can't do otherwise because some API NEED it

* You probably won't need to use Unicode or PWideChar explicitly, except if you use some 3rd party components that fix it (and you still want to compile with Delphi <2009)

Same goes for the windows API : use the functions without A or W suffix, and let Delphi choose the one that will be used. That will work nicely if you didn't fixed in your code pANSIChar type for example, but only use pChar as I explained before.

If you follow these strict rules, you won't have many problems to compile your code in different Delphi versions, and will also reduce your future problems if something irremediably change in next Windows (but as aflarin said, I very much doubt that this will occur in the next decade)
Geert GOracle dbaCommented:
Don't forget  you can code in native Chinese or Japanese in the IDE !
That's if you know the language ... :)
Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

How do you code in Chinese ?? You mean insert Chinese text properties & constant, not writing code in Chinese ? translated keywords ? or only identifiers ?
I hope I will never cross some Chinese code with chinese identifiers. I already had to work with IPX unit in german, that was hard enough for me
Geert GOracle dbaCommented:
i got some text of al jazeera and created a new type and execute method:

it'll be a bit harder reading delphi code in the future

but that shows what you can do with unicode in the ide
Geert GOracle dbaCommented:
and don't ask what the translation is
it's in hebrew
cebassoAuthor Commented:
Heyy thank you all for reply!
For my DLLs, as its shared to others developers... i'll make like Windows does, an A and W version for each shared function/procedure and for structs something like
TMyStructA and TMyStructW using cbSize to check what kind of struct the addon is using...
In A struct, of course i will keep as AnsiChar and for W Char...
TMyStructA = record
  cbSize: DWORD;
  chSomething: array [0..10] of AnsiChar;

TMyStructW = record
  cbSize: DWORD;
  chSomething: array [0..10] of Char; //will be widechar Delphi >= 2009
the compiler probably will be Delphi XE so buying the licence i can use any Delphi version from 2007 as i read in embarcadero website

Cool... so for each func/proc i'll release a A and W way too

function GetInstallPathA(lpBuffer: PAnsiChar; var nBuffSize: DWORD): Integer; StdCall;
function GetInstallPathW(lpBuffer: PChar; var nBuffSize: DWORD); Integer; StdCall;
not tested yet, i downloaded Delphi XE to test everything of this... since many things will change... wait, more answers will come hahaha
Fantastic!! and i think that it will be more dificulty to crackers?
instead of "isTrial" now i can use something like "¿¿¿¿¿¿¿"

function ¿¿¿¿¿¿¿: Boolean;
Haha, it was just an example, not necessary "isTrial" that i use =)

Is that true that making things in Arabic, except if the cracker know the language of course, will be more dificulty?

sorry if it's bullshit =X

I really don't know exactly how to crack a program, so reading articles over the web, many times i saw to not make stupid functions like "isTrial', "isActivated", etc

cebassoAuthor Commented:
ops... imagine that "¿¿¿¿¿¿¿" is something in Arabic language since it'snt displayed here (content="text/html; charset=UTF-8" Encoding) ;)
> Is that true that making things in Arabic, except if the cracker know the language of course, will be more dificulty?

No, not with compiled code that don't include debug information. Your arabic names would be removed and impossible to recover, so not much better than function ThisIsTheRegisterCheck:Boolean .

So no problems with Delphi, you can - and must - use significant names and will work better with no loss of security. Except if your source code is robbed, but that is another issue.

With C#, on the other hand, I think it most of the time include all the identifier names somewhere, except if you run some special tools to remove or obfuscate.
Geert GOracle dbaCommented:
cebasso, i had to use a image to be able to show the arabic chars
doesn't work on this site to show other language chars

forgive me, but in america, they only need spanish, portugese, english, french and a little dutch
(those are all eu and ex colonies chars )
this post may already be scanned by the fbi or cia, just because i put al jazeera
i already took a holiday for 2 days, just in case the feds show up at work ... but don't tell them

and don't say there isn't americans in belgium
they are even storing nuclear weapons here in kleine brogel
cebassoAuthor Commented:
Ahh ok! Then i really prefer to use normal names :D
If you had said yes, probably now i would be changing my codes to arabic or at least put in my TODO list haha

HAHA LOL! talking about a holiday... who need a holiday is me... i'm being crazy about unicode and 70% of components that i use isn't working on Delphi XE :(
Thank you all guys :D
See you in the next question haha

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

  • 4
  • 3
  • 3
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now