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. Charlie _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal