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

[Michael Van Canneyt]

On Thu, 19 Dec 2024, James Richters via fpc-pascal wrote:

> I am using ProgProcess to execute a program with data passed as parameters.
> I'm adding the parameters with this:
>
>         ProgProcess := TProcess.Create(nil);
>         ProgProcess.Executable := 'cmd.exe';
>         ProgProcess.Parameters.Add('/c');
>         ProgProcess.Parameters.Add('start');
>         ProgProcess.Parameters.Add('/wait');
>         ProgProcess.Parameters.Add('"Message"');
>         ProgProcess.Parameters.Add('CMD_Message.exe');
>         ProgProcess.Parameters.Add(MyAnsiString);      // This is the
> string I am sending
>         ProgProcess.Options := ProgProcess.Options + [poWaitOnExit];
>         ProgProcess.Execute;
>         ProgProcess.Free;
>
>
> If I compile it with:
> Free Pascal Compiler version 3.3.1-15425-gf77b9fa4ef-dirty [2024/03/18] for
> i386
> I get what I expected:
>    Sent: #$EE#$59#$20#$4D#$69#$6E#$20
> Received: #$EE#$59#$20#$4D#$69#$6E#$20
>
> 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?

For that we'd need to know what caused the change.

Since 2024/03/18 there have been no obvious changes in the TProcess code 
that could cause this behaviour. There have been many changes before that
date, but normally none that would explain the behaviour you see.

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.

Michael.