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 -----Original Message----- From: fpc-pascal <fpc-pascal-boun...@lists.freepascal.org> On Behalf Of Michael Van Canneyt via fpc-pascal Sent: Friday, December 20, 2024 8:23 AM To: Karoly Balogh via fpc-pascal <fpc-pascal@lists.freepascal.org> Cc: Michael Van Canneyt <mich...@freepascal.org> Subject: Re: [fpc-pascal] Is there a recent change to TProcess? 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. _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
