问题
It seems that on 64-bit platforms it would be reasonable to have a 8-byte length prefix. If we can address more than 4Gb of mem why not allow, say, 5Gb strings? Is the answer just "by specification" or there is some interoperability/backwards compatibility reasons that I'm not aware of? Thanks.
回答1:
The BSTR data type is the standard COM string data type. Changing the length prefix would make it impossible to safely move strings between processes of different bitness (or at least make it significantly more complex). Since COM is the only relevant cross-bitness interop infrastructure it is necessary to have BSTRs behave the same way for 32-bit processes and 64-bit processes.
It is a tradeoff, imposing a 'limit' of 2GB in exchange for hassle-free marshaling of strings between processes of different bitness.
回答2:
One good reason is for compatibility with platform APIs like MultiByteToWideChar which accepts int lengths. There are many more string APIs that work with 32 bit lengths.
It's not actually a real limitation because I cannot conceive of a scenario where a BSTR of length >2GB would be the best solution to a problem.
回答3:
BSTR is a length-prefixed string, so the first property is length, not address. Therefore it need not be the same size as the pointer and can just be the size that's enough for the application
For all practical purposes, 4GB is more than enough for a string, and keeping the maximum string size the same allows you to pass strings between processes without problem. For example if the length is a 64-bit type on 64-bit Windows then what will happen when you pass an 8GB string from a 64-bit process to a 32-bit process? Should the string be truncated or should an error be reported? The same prefix size may also improve backward compatibility
来源：https://stackoverflow.com/questions/23098728/why-is-bstr-length-prefix-4-bytes-on-64-bit-platforms