On 2024-12-20 14:22, Michael Van Canneyt via fpc-pascal wrote:
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.
Could it be due to a change of compilation mode (DELPHIUNICODE etc.) by
the user?
Tomas
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
