[fpc-pascal] Is there a recent change to TProcess?

[Michael Van Canneyt]

On Fri, 20 Dec 2024, Karoly Balogh via fpc-pascal wrote:

> Hi,
>
> On Fri, 20 Dec 2024, Michael Van Canneyt via fpc-pascal wrote:
>
>>> If I compile it with:
>>> Free Pascal Compiler version 3.3.1-16969-g798f2ba632-dirty [2024/11/28] for
>>> i386
>>> I get almost what I expected, but my #$EE is now been changed to #$3F   (and
>>> all similar codes in the range of #$D0 - #$EF have been changed to #$3F as
>>> well)
>>>    Sent: #$EE#$59#$20#$4D#$69#$6E#$20
>>> Received: #$3F#$59#$20#$4D#$69#$6E#$20
>>>
>>> Does anyone know why this is?  I have tried it several times, if I compile
>>> it with the trunk from 2024/03/18 it's fine, if I use the current trunk my
>>> other program is receiving the wrong data. noted that I never re-compiled
>>> CMD_Message.exe so it must be that my TProcess is now sending modified
>>> parameters to my program.
>>>
>>> Is there any way to get TProcess in the current trunk to work the way it
>>> used to?
>>
>> Note that sending a non-ascii string on the command-line is a bad idea.
>> It's susceptible to codepage issues, and will most likely behave differently
>> depending on whether the ANSI or WideString version of the underlying
>> windows API is used.
>
> Which is what probably happens here. "3F" is the ASCII code for the "?"
> character, which is used as a joker character for codepage conversions,
> when the mapping cannot be determined...
>
> I was also wondering if some basic behavior changes regarding string types
> have been introducted into the RTL, that somehow leaks into TProcess, by
> introducing a conversion somehow along the way.

I am not aware of any such changes, but given your remark about the meaning
of 3F, the latter seems a likely explanation.

Michael.