[Lazarus] TProcess, UTF8, Windows

[Jürgen Hestermann]

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.


 > 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.


 > 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.


 > 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.