Ok.. I have Ernie's BSTR lib. And I've scoured the MSDN (briefly), but i can't seem to find just how a BSTR is formatted, just the API's to use with BSTR's.

IE) I *think* unicode strings are just words instead of Ascii.

"HI" == db 'H','I' ==> dw 'H' , 'I' == db 'H', 00, 'I', 00

but how *different* is Binary Strings? What is its model? (I had an idea for a tool, but i need to know how this works properly)

NaN
Posted on 2001-09-27 13:11:23 by NaN
I just did some initial research... (trial and error with softice)..

And discovered that there is no difference. Well except that the data offset is different.

Normal data (.data and .data?), is complied into memory offset: 00402000.

MultiByteToWideChar -> does exacly what i expected.

SysReAllocString -> Copies the "WIDE CHAR" string to heap memory (from experience with heap objects) offfset : 005101D0, where it then calls it a "BINARY STRING"...

I dont get it.. Why Do i need these API's... ? :confused:
NaN
Posted on 2001-09-27 13:40:09 by NaN
Those API's create an abstraction layer to protect HLL programmers from changes that could take place. We don't want those guys thinking about LL stuff - they might start thinking for themselves. :)
Posted on 2001-09-27 18:13:32 by bitRAKE
You're missing something, I think. In non-unicode strings, under some
locales, it is possible for a single char to take up multiple bytes (hence MultiByteToWideChar). I've never seen such strings
myself, so I suppose only countries with fubar character sets have
them.

I might of course be totally wrong, but I don't think I am :).
Posted on 2001-09-27 19:44:35 by f0dder
In docs for type BSTR you may find :



A length-prefixed string used by Automation data manipulation functions.

typedef OLECHAR *BSTR;

BSTRs are wide, double-byte (Unicode) strings on 32-bit Windows platforms and narrow, single-byte strings on the Apple? PowerMac?.

For details on the BSTR data type, see Chapter 7, "Conversion and Manipulation Functions."



Strangely enough on Win32 systems there is definitely no "length prefix", its just as NaN says: BSTRs are wide char strings.

japheth
Posted on 2001-09-28 04:48:39 by japheth
Thanx japheth, I guess that clears that up :)


PS: After talking it over with Thomas, we decided we will modify a new version of Objects.inc to suport your LOCAL idea, as well, as the HEAP. Our plan is to provide an equate that if defined it do HEAP alloc's and if not, it will do LOCAL alloc's.

Thanx for you sugestion. The best part is it wont affect any existing classes at all.

NaN
Posted on 2001-09-28 22:43:20 by NaN
BSTR's a just damn confusing. To start with, no one is really quite sure what B S T R itself stands for.

But anyway....

BSTR's are defined for COM, and at base, COM is a contract, an agreement between programmers to always do things in a standard way so "A" will work with "X". The rule for BSTR's is "thou shall always manipulate BSTR's thru the API."

Sure, you can fiddle about, create your own "optomized" versions of these API's, and your code may even work. Work for today anyway. There is no guarntee it will work tomorrow when MS chooses to change the definition of BSTR's in some way your code doesn't track.

And for those who swear the BSTR doesn't point at any length prefix, well, it never was supposed to. Actually, the length prefix preceedes the character string, and the prefix counts bytes, not characters.

Or so I've read. Now it just might be possible that prefix isn't really there, I've never checked. Nor is it worth while to check... because the rule is if one wants the length of a BSTR, one uses the API for that. And that is guarnteed to work, so why would I muck around with a maybe?

HOW a BSTR works internally is for the OS to deceide. Heck, it may have a internal list of lengths quite seperate from the strings, and that is fine. As long as the API works.

COM is a comunications protocol (really!), and what works in a simple in process DLL object server may explode when running across threads or processes or over machine boundaries, all of which COM has been well-polished to work across all such boundaries.

Remember: It's all fun and games until somebody gets hurt!
Posted on 2001-09-28 22:48:57 by Ernie
Well, Ernie,

changing such an elementary type like BStR in a BINARY standard like COM wouldn't be wise, even if you call yourself MS. To get the length of a BSTR there exist SysStringLen, but to convert such a string to a normal string its not bad if you know that BSTRs are wide char strings and therefore you can use MultiByteTo...

Regards,

japheth
Posted on 2001-09-30 07:41:53 by japheth
Well japheth,

The rule for BSTR's is "thou shall always manipulate BSTR's thru the API."


That's my own quote.

Here are some hints:

1) SysStringLen is an API function.

2) MultiByteToWideChar is an API function.


Here's a conclusion: I said just what you said.


"changing such an elementary type ... wouldn't be wise"


That implies Microsoft is wise. BIG hint here for ya: they aren't.
Posted on 2001-09-30 20:46:59 by Ernie