OpenEuphoria

Re: EuCOM : Attn Matt : String Return Value

• Posted by Bernie Ryan <xotron at blu?f?og.com> Oct 04, 2007
• 667 views

Rad wrote:
> 
> 
> I tried out other string returning methods in the ocx which are:
> 
> }}}
<eucode>
> -- file checksum
> OCString = invoke( OC6, {OneCryptA_m_FileChecksum},
> 			  {pBstrPathIn},
> 			  {VT_BSTR}, DISPATCH_METHOD )
> void = message_box("Input File Checksum : " & OCString, "msg",
> MB_ICONINFORMATION)
> 
> -- string checksum
> OCString = invoke( OC6, {OneCryptA_m_StringChecksum},
> 			  {pBstrAppId},
> 			  {VT_BSTR}, DISPATCH_METHOD )
> void = message_box("AppID Checksum : " & OCString, "msg", MB_ICONINFORMATION)
> </eucode>
{{{

> 
> and they worked fine returning string values as expected.
> 
> The difference being these methods have only one parameter where as Encrypt
> method has 2 parameters.
> 
> }}}
<eucode>
> -- encrypt string
> OCString = invoke( OC6, {OneCryptA_m_EncryptString},
> 			  {pBstrAppId, pBstr},
> 			  {VT_BSTR, VT_BSTR}, DISPATCH_METHOD )
> </eucode>
{{{

> 
> 
> Could this difference in number of parameters causing the error?
> 
> 
> Following is the discussion with the developer of 1Crypt ocx:
> =============================================================
> Hi Rad,
> 
> 1Crypt uses only VT_BSTR strings. These are Unicode strings with a maximum
> length
> of 2GB.
> 
> 2147614729 decimal = 80020009 hex
> 
> I'm wondering if this value could be a pointer to a string rather the string
> itself.
> 
> I checked whether there is any difference between the strings returned by
> FileChecksum
> and StringChecksum, and those returned by EncryptString and DecryptString.
> They
> all return exactly the same kind of string, but it's possible that the
> compiler
> is handling the last two differently. 
> 
> I have an idea that in the first two cases, the string pointer returned is
> pointing
> to a string created in the virtual address space of the calling application,
> and in the other two cases it is in the virtual address space of the ocx. This
> is a pretty low-level difference, and I'm not certain that this is the case,
> but I've made a minor change to the code and recompiled, and I hope it will
> make a difference when calling it from Euphoria. 
> 
> The new ocx is attached. Please let me know how it goes.
> =======================================================
> 
> 
> Unfortunately the revised ocx is giving the same result as previous one. 
> 
> 

Rad:

If they are returning the pointer to a BSTR the first four bytes will
be the length of the unicode array terminated by two nulls.

So try peeking at pointer+4 for that number of bytes.

Bernie

My files in archive:
WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API 

Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan