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?

James

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.

Hi,

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.

Charlie

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

Michael.

Could it be due to a change of compilation mode (DELPHIUNICODE etc.) by the user?

Tomas

Op 20-12-2024 om 14:44 schreef Tomas Hajny via fpc-pascal:

I assume that it is exactly the same source on exactly the same system with exactly the same compiler configuration.

Otherwise it any system wide changes might influence both the parent and the child system, and other FPC (and Lazarus) configuration might also cause differences.

E.g. a change in lazarus generated manifest.

It does seem that '?' is being substituted in, but I don't know why, the ascii codes I am using are valid character they are: #$D0 - #$EF which are these: Þßàáâãäåæçèéêëìíîïï It's not like they are non-characters like escape or something.
They are valid ascii characters. I went to the character map to see what they were.
I don't need those so I used them as color codes so I could specify what color things should be by prefixing color changes with one of those.

I'm on Windows 10 Professional, I'm not changing anything other than re-compiling the main program that has the TProcess call in it.

James

I assume that it is exactly the same source on exactly the same system with

exactly the same compiler configuration.

Well... you would think I would be compiling it the same way, but I'm not... I thought I was be when I went to verify that I found that I did make a change.

I was compiling with:
"..\..\FPC\W32_Trunk_2024_3\bin\i386-win32\fpc" -TWin32 -Mfpc -vw -vn -vh -Sg -Si -Sa -Sc -Cr -Ct -Ci -Co -CR -Os -Ooregvar -O1 -Cp80386 -Op80386 -Rintel -Fu..\..\FPC\W32_Trunk_2024_3\units\$fpctarget\* -gl -p- -b- -CF64 Promill.pas

I am compiling with:
"..\..\FPC\W32_Trunk_2024_11\bin\i386-win32\fpc" -TWin32 -Mfpc -vw -vn -vh -Sg -Si -Sa -Sc -Cr -Ct -Ci -Co -CR -Os -Ooregvar -O1 -CpCOREI -OpCOREI -CfAVX2 -dMT -Fu..\..\FPC\W32_Trunk_2024_11\units\$fpctarget\* -gl -p- -b- -CF64 Promill.pas

I tried to compile with the Cp80386 -Op80386 -Rintel parameters and then I instantly remembered why I changed it...
It's because I am using Min/Max for example:

     MaxScrollPos := Max(0, ScrollInfo.nMax - ScrollInfo.nPage + 1);

For some reason this was fine when I compiled it with -Cp80386 -Op80386 -Rintel in March, but now I get:
Promill.pas(1620,25) Error: The function used, is not supported by the selected instruction set: MIN/MAX

So I changed it to

-CpCOREI -OpCOREI -CfAVX2 -dMT

Which is more accurate because I'm using Core-I processors... and that fixes the MIN/MAX issue but could this cause the issue with TProcess?? I'm also not sure whey MIN/MAX doesn't work anymore on 80386 but it used to.

James

I just tried compiling with the march version with -CpCOREI -OpCOREI -CfAVX2 -dMT and it worked as expected... so it's not the processor change that caused the issue.

James

Could it be due to a change of compilation mode (DELPHIUNICODE etc.) by the

user?

I haven't change any code at all but the unit that does the TProcess call is
being compiled with:
{$Mode TP}{$I-}
{$modeswitch exceptions}
{$R+}

James

James Richters via fpc-pascal schrieb am
Fr., 20. Dez. 2024, 15:16:

They are in fact *not* valid ASCII characters. ASCII is defined from #00 till #7F. Anything above is handled by some ANSI codepage (which is also what the character map shows, based on the currently active code page). So it is indeed very likely that some conversion is happening here that did not happen with an older version.

Regards,
Sven

Op 20-12-2024 om 15:36 schreef James Richters:

> I assume that it is exactly the same source on exactly the same system with exactly the same compiler configuration.

And the same machine otherwise ?

And the same machine otherwise ?

Yes everything is the same other than the version I am trying to compile with, and being run on the same system.