Jesus Reyes wroteSomething related to Lasutils, it seems that all windows snaphots that use 0.9.31 and fpc 2.5.1 are broken since r33116 or
r32982, this problem it seems, not fixed by r33538 (bug report
http://bugs.freepascal.org/view.php?id=20668).
oh, I just inspected my IDE with "nm lazarus > lazarustable.txt" and the IDE is using paswstring.pas, but I inspected applications written using the LCL and they are not automatically linked against paswstring.
I just checked and I found the problem:
lazarus/packager/packagesystem.pas uses the unit LazUtils
So in rev 33553 I commited removing the LazUtils unit usage from this unit and I verified with nm that now paswstring is no longer added to the IDE.
It should be fixed now.
The problem is that Wide2AnsiMove should convert from widestring to ansi, but the conversion is conditionated by
PASWSTRING_SUPPORT_NONUTF8_ANSISTRING which is undefined by default, as result, in UTF8ToAnsi that does a
UTF8->UTF16->UTF8->Ansi doesn't work as the last step is not done :D.
paswstring was not written to be used in Windows, although it theorically can be. It was written to substitute cwstring in UNIXes, most importantly Android.
I added the ifdef to improve Android support. If you activate PASWSTRING_SUPPORT_NONUTF8_ANSISTRING then 1 MB will be added to your executable, and totally unnecessarely because in Android the system uses only UTF-8
paswstring is used inside the LCL when the define ANDROID is activated.
BTW, what strange conversion UTF8->UTF16->UTF8->Ansi too many steps.
The last step does not occur in the cases where paswstring was supposed to be used, like modern UNIXes.
Felipe Monteiro de Carvalho