<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"><channel><category>pcsoft.us.windev</category><copyright>Copyright 2026, PC SOFT</copyright><lastBuildDate>25 Sep 2015 11:34:00 Z</lastBuildDate><pubDate>24 Sep 2015 17:52:00 Z</pubDate><description>Hi Everybody,&#13;
&#13;
I thought I would let you know of a potential pitfall I just identified when working on IOS applications. It's kind of involved, so bear with me.&#13;
&#13;
Lets consider a string containing ABC&#13;
In an ANSI String, it's binary content would be 41 42 43&#13;
in an UNICODE string, it would be 41 00 42 00 43 00&#13;
&#13;
Now, in a project that has to send data from an iphone to the web, and want to encrypt it beforehand (ys, it's WXReplication), we HAVE TO use the new function cryptstandard (and the reverse one, of course).&#13;
&#13;
As these two function accept only BUFFER as arguments, we need to transfer our ABC string into a buffer before encryption, and that is where the problem lays:&#13;
&#13;
As I was using unicode strings, I was expecting the content of my buffer to be identical to the content of the unicode string (41 00 42 00 43 00), and it's length 6 bytes&#13;
&#13;
This is true (as tested by me and the customer I was working with):&#13;
- in windev/windows, GO and EXE mode&#13;
- in webdev/window, GO and DEPLOYMENT mode&#13;
- In Mobile/Android, GO and Hardware mode&#13;
- in IOS, GO MODE ONLY.&#13;
&#13;
If you do the same thing on the XCODE simulator or on a physical iPhone/iPad, the content of the buffer becomes: 41 00 00 00 42 00 00 00 43 00 00 00 and it's length 12.&#13;
&#13;
As long as you work inside the iphone, that doesn't create any specific problem as the affectation from buffer to unicode recreate the unicode string correctly.&#13;
&#13;
However, as soon as you try to communicate with webdev (by example), you get:&#13;
- a buffer twice as big&#13;
- it's encrypted by cryptstandard with all the extra 0&#13;
- it's then transmitted to the web part (after a bufferothexa)&#13;
- on the web side, it's put into a buffer again (hexatobuffer)&#13;
- it's decoded, and the result is STILL 12 bytes long (41 00 00 00 42 00 00 00 43 00 00 00)&#13;
- and when the result is set in the unicode string waiting for it, we get : A (ie 41 00) instead of ABC, as the first 00 00 found is the End Of String.&#13;
&#13;
This means that it's impossible to use the cryptStandard function as it was intended, ie accross platform, as soon as you work with iphones/iPad&#13;
&#13;
Reproduction protocol:&#13;
usMyString is unicode string="ABC"&#13;
bufMyBuffer is buffer=usMyString&#13;
info(length(usMyString), length(bufMyBuffer),buffertohexa(bufmybuffer))&#13;
&#13;
the info will display 3,6 everywhere but on the xcode simulator or the physical iPhone/ipad where you will get 3,12, 41 00 00 00 42 00 00 00 43 00 00 00&#13;
&#13;
And this of course, is a BIG problem.&#13;
&#13;
I found a workaround by massaging the content of the buffer before setting it into a unicode string, but it still means that the data sent is twice as big as it should be (slower) -AND- has to be extra processed when received from an iPhone (slower again).&#13;
&#13;
So, before you waste your time on that one , I though I would share.&#13;
&#13;
This problem has been sent to PCSoft support a few minutes ago. I'll keep you posted.&#13;
&#13;
Best regards</description><ttl>30</ttl><generator>WEBDEV</generator><language>en_US</language><link>https://forum.pcsoft.fr/es-ES/pcsoft.us.windev/54129-problem-between-unicode-string-buffer-and-cryptstandard/read.awp</link><title>Problem between Unicode string, buffer and CryptStandard</title><managingEditor>moderateur@pcsoft.fr (El moderador)</managingEditor><webMaster>webmaster@pcsoft.fr (El webmaster)</webMaster><item><author>guest</author><category>pcsoft.us.windev</category><comments>https://forum.pcsoft.fr/es-ES/pcsoft.us.windev/54129-problem-between-unicode-string-buffer-and-cryptstandard-54144/read.awp</comments><pubDate>25 Sep 2015 11:34:00 Z</pubDate><description>Hello Peter,&#13;
&#13;
no, I did NOT find that information. Thank you!&#13;
&#13;
So that's the cause of the problem. I guess that's one more a…</description><guid isPermaLink="true">https://forum.pcsoft.fr/es-ES/pcsoft.us.windev/54129-problem-between-unicode-string-buffer-and-cryptstandard-54144/read.awp</guid><link>https://forum.pcsoft.fr/es-ES/pcsoft.us.windev/54129-problem-between-unicode-string-buffer-and-cryptstandard-54144/read.awp</link><source url="https://forum.pcsoft.fr/es-ES/pcsoft.us.windev/54129-problem-between-unicode-string-buffer-and-cryptstandard/read.awp">Problem between Unicode string, buffer and CryptStandard</source><title>Re: Problem between Unicode string, buffer and CryptStandard</title></item><item><author>guest</author><category>pcsoft.us.windev</category><comments>https://forum.pcsoft.fr/es-ES/pcsoft.us.windev/54129-problem-between-unicode-string-buffer-and-cryptstandard-54137/read.awp</comments><pubDate>25 Sep 2015 10:26:00 Z</pubDate><description>Hey Fabrice,&#13;
&#13;
Did you read this in the help which would explain what you ar experiencing:&#13;
http://doc.windev.com/en-US/?302403…</description><guid isPermaLink="true">https://forum.pcsoft.fr/es-ES/pcsoft.us.windev/54129-problem-between-unicode-string-buffer-and-cryptstandard-54137/read.awp</guid><link>https://forum.pcsoft.fr/es-ES/pcsoft.us.windev/54129-problem-between-unicode-string-buffer-and-cryptstandard-54137/read.awp</link><source url="https://forum.pcsoft.fr/es-ES/pcsoft.us.windev/54129-problem-between-unicode-string-buffer-and-cryptstandard/read.awp">Problem between Unicode string, buffer and CryptStandard</source><title>Re: Problem between Unicode string, buffer and CryptStandard</title></item></channel></rss>
