[Bug 5469] VB6.0 string compare gives wrong result

Wine Bugs wine-bugs at winehq.org
Thu Jul 13 09:58:25 CDT 2006


http://bugs.winehq.org/show_bug.cgi?id=5469





------- Additional Comments From charles at diagnos.co.uk  2006-13-07 09:58 -------
Hmm, I've been playing some more with this now.

I've been calling this under Windows XP (using the PowerBASIC compiler):

  result = varbstrcmp(chr$(1), chr$(2), lcid, flags)

and varying the lcid.  With a for...next loop, there were three different
results depending on LCID:
  0 (VARCMP_LT) only occured when LCID = 0;
  1 (VARCMP_EQ) or 0x80070057 (which I'm assuming was because the LCID wasn't
valid).


Using a character string (in PowerBASIC) of something like:
  a = chr$(1, 2, 3, 4)
and PEEKing the memory location showed that the characters are stored in
adjacent 8 bit blocks, with the length stored as the number of bytes of data. 
They show up in the Wine debug log as L"\0201\0403" but the length that is being
passed between functions seems to be wrong (is this because SysStringLen is
assuming 16 bit WChar sizes and dividing the length by 2?), so I needed to
fiddle with the passed lengths to get this to display.

The MSDN page for comparestring seems to refer to parameters such as cchCount1
refering to either "bytes for ANSI versions or WCHARs for Unicode versions".

Could this all mean that for varbstrcmp, if you set the LCID to 0, the function
assumes it is ANSI data rather than Unicode and does a straightforward memcmp
type compare?  Also, seeing as for different values of the LCID, Windows thinks
that chr$(1) == chr$(2), then maybe there is no tiebreak function in the Unicode
compare.

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.



More information about the wine-bugs mailing list