[Lazarus] TProcess, UTF8, Windows

[Marcos Douglas]

On Fri, Apr 13, 2012 at 12:18 PM, Jürgen Hestermann
<juergen.hestermann at gmx.de> wrote:
> Lukasz Sokol schrieb:
>
>>> IMO it must be possible to predict the encoding of strings
>>> when writing the code (without running the program).
>> No one prohibits you to use an identifier name to reflect encoding ;)
>
> That's true and that's what I am doing of course.
>
> But if you use a function from a (Free Pascal or Lazarus) library it is not
> clear which kind of encoding this function expects. As I already mentioned,
> for example CopyFile (from LCL) and FindFirst (from SysUtils) have no hint
> in their documentation on what encoding is expected. I know, somewhere it
> says that library x has enconding y but why wasn't this information written
> to the documentation for the indiviudal functions? I don't get it. It's a
> very important information. I think that many Free Pascal (and Lazarus)
> users come from other platforms like Delphi, Virtual Pascal, Turbo Pascal
> etc. and many want to use parts of their old code. These people do not sit
> down for months to find all the spread information that *may* be important
> for FindFirst, CopyFile, etc. They expect all releveant information at the
> docu for the functions.

+1

>> Also : how do you think you'd guess encoding of a text file on disk
>> before reading it ? Some people don't like to have the decision taken
>> by the compiler for themselves...
>
> That's not what we are talking about here. If I understood Marcos problem
> correctly the topic was the output of another function where the encoding
> was unclear.

That was one of problems.

>> Other area where this may be important: web applications.
>> Database fields may (each) have different encoding (and we would be able
>> to know it),
>> internals of the app would work on their own encoding (and we would know
>> it)
>> the web frontend may run on different encoding every time (and we would be
>> able to know it )
>> (imagine somebody forces a certain encoding on their web browser and tells
>> the web app developer to support THAT)
>
> As long as you *know* about each encoding you can manage it. But if you have
> to guess the encoding then it will fail in general.

The major problem is work with FPC (Ansi), LCL (UTF8) and Console on
Windows (UTF16)!

>> I for one /like/ that The New Pascal has become highly customizable even
>> if
>> some things have to be more explicit than in Ye Olden Days...
>> It's still way more 'high level' than plain c that some people dub
>> 'assembler on drugs'....
>
> I only see that everything that has been added since Delphi (mainly by
> Borland) is more C style than Pascal (pchar, operator overloading, context
> dependend meaning of indentifiers, poor documentation, etc.). The focus is
> more on a "me too" attitude (assimilation of all all other programming
> languages) and not on clear, easy and readable program code.


Marcos Douglas