Re: 2 bytes per character
"Igor Tandetnik" wrote:
I don't think there are any assumptions about contents of
BSTRs in COM runtime - witness SysAllocStringByteLen et
al.
I agree with you in general. I don't believe either that any
assumptions about BSTR content were made willingly. What I'm
concerned about is that support of surrogate pairs is kind
of gray area. Platform SDK itself has reservations when
speaks about surrogate pairs:
"Surrogates and Supplementary Characters"
http://windowssdk.msdn.microsoft.com/en-us/library/ms776414.aspx
<quote>
Windows 2000 introduced support for basic input, output, and
simple sorting of supplementary characters. However, not all
system components are compatible with supplementary
characters.
</quote>
I can bring an example of such assumptions. One day we
tried
to transmit binary data via BSTR. Such usage is allowed
by
OLE Automation and described in SysAllocStringByteLen
documentation. So, embedded zeros should be "suppored" by
BSTR. However, it was proven with simplest example that
DCOM
marshalling code (or whatever else) assumed that BSTR
won't
contain zero in the middle.
Can you show a repro? I've dealt with BSTRs containing
embedded NULs on a few occasions, and I believe COM
runtime handles these just fine. Is it possible you were
using some library on top of raw COM that choked on these?
E.g. most methods of ATL's CComBSTR would trunctate a
string with embedded NULs.
Yes, all popular BSTR wrappers fail to recognize embedded
NUL. So, no wrappers were used. I can't vouch that the
problem was inside COM runtime, DCOM, network driver or
something else. It was enough to discover that data doesn't
come through in its entirety.
I'll try to reproduce it with Windows XP; just don't have
Windows 2000 box available anymore. The origonal system was
running under Win2K as workstation and some version of
Novell as domain server.