Zvone wrote:
>> TBytes was the datatype to be used. However that would break
>> backwards compatibility since historically "string" was used
>> everywhere. That all was no problem, however the rule is: "DO NOT
>> BREAK BACKWARDS COMPATIBILITY" and that is where the problems begin.
>
> Well you've
> TBytes was the datatype to be used. However that would break
> backwards compatibility since historically "string" was used everywhere.
> That all was no problem, however the rule is: "DO NOT BREAK BACKWARDS
> COMPATIBILITY" and that is where the problems begin.
Well you've already broken this r
Zvone wrote:
>> However, as long as this codepage was one of the windows-xyz,
>> single byte character sets converting back to Ansi with the
>> same codepage should work without data loss and give you back
>> the raw bytes (hopefully). This won't work, for example, with
>> Japanese locale settings.
> However, as long as this codepage was one of the windows-xyz,
> single byte character sets converting back to Ansi with the
> same codepage should work without data loss and give you back
> the raw bytes (hopefully). This won't work, for example, with
> Japanese locale settings.
But there is a s
Hello Zvone,
Yes, the Unicode implementation of the POP3 client is weak.
It converts the bytes received to Unicode with current Ansi
system codepage. This is direct result of ICS rule #1 to not
break backwards compatibility.
However, as long as this codepage was one of the windows-xyz,
single byt
After further investigation I made a small pop3 server emulator that sends
all character codes except 0x00, 0x0A and 0x0D which should not be in
message anyway.
Even though the LastResponse unicode looks a bit odd in debugger, after
doing a SslPop3Cli->LastResponse.c_str(); and
SslPop3Cli->LastRes
