Using a BSTR to Transport C++ Objects Across the DCOM Interface

One problem that has frustrated me is the difficulty of building a
large object on the SQL/MTS server and then using DCOM to deliver all
that stuff to the client. The objective was to submit a query to the
server which would then process through the database , build a complex
object, that is an object with nested maps, lists and arrays of other
objects, and return the whole result in usable form to the client.

The semantics of using a SAFEARRAY or a large set of COM properties is
daunting to me. Since I don’t need to make these complex objects
available to VB or Java applications I can keep all the code in C++.

This approach takes advantage of the simple design of a BSTR which, as
I understand it, is just a long pointer. What it points to is the
address between a long int and a block of memory, actually the first
byte of the memory block. The long int preceding the string memory
contains the byte length of the memory block. Usually the memory block
contains a null terminated array of 2 byte characters, but it can
actually contain anything. Since COM/DCOM know how to marshall BSTRs
across the network and process boundaries, anything that can be packed
into a BSTR can be marshalled across.

The first step is to get the arbitrarily complex object packed into the
BSTR. I used a CMemFile to receive the serialized object, then stuff
the CMemFile into the BSTR.

The code looks like this:

BSTR CMyView::FetchObject(long lParam) // pseudo-server function
MyComplexClass *p_mCC; // a serializable class
BSTR bstrHoldThis;
CMemFile mfFile; // works just like a real
// file

CArchive ar((CFile*)&mfFile, CArchive::store);

// Create the complex object. I include this stub here to indicate
// that what is being passed is really an an object and not a pointer.
// It could be a megabyte or more in size.

p_mCC = new MyComplexObject(lParam);

// A small, simple object could have been created on the stack.That’s
// not best place for a REALLY big object, although it
// guarantees that it will go away when the function returns.
// I generally put objects on the heap with ‘new’ and
// delete them after serialization.

// Serialize the object to the memory file

// You need to flush the archive and file buffers
ar.Flush(); // flush the archive first
mfFile.Flush(); // then the file

// The step that creates the BSTR needs the length of the file

ULONG lArchiveLength = mfFile.GetLength();

// Stuff the archive into the BSTR with SysAllocStringByteLen()
// CMemFile.Detach() returns a pointer to the memory block of the file
// which is used to create the BSTR.

bstrHoldThis = SysAllocStringByteLen((const char*)mfFile.Detach(),

// Free the object. The CMemFile will clean up after itself.

delete p_mCC;

// Return the BSTR result;

return bstrHoldThis; // send the whole thing into the aether

Now the caller needs to be able to unpack the BSTR and re-create the
object. This is just the reverse of the steps above and I’d leave it as
an exercise for the reader but I actually got it to work so here it is.

Void CMyView::OnButton1()
BSTR bstrA;
MyComplexClass mRC;
CMemFile mfFile;

// error checking omitted for clarity – but necessary

// go get the BSTR wrapped object from the pseudo-server
BstrA = FetchObject(m_lTestVal);

// here’s the ugly part. I back into the length of the BSTR.

ULONG *p_lLength = (ULONG*) bstrA; // points at the byte AFTER the
// BSTR length

–p_lLength; // now it points at the length of the
// BSTR. Like Foster’s – crude but
// effective.

// attach the memory part of the BSTR to the CMemFile memory block

mfFile.Attach((unsigned char*) bstrA, *p_lLength);

// now the object is in the memfile and it can be loaded
CArchive ar(&mfFile, CArchive::load);


// The object is now fully instantiated on the stack.
// In this sample code it would be destroyed when this
// function returned so you’d really want to build it with ‘new’
// on the heap and assign it to a member variable, or a
// Document data member.

// We still need to free the memory used by the BSTR and the
// CMemFile. They both point to the same memory. The CMemFile
// won’t automatically free the memory that was attached when it
// is destroyed, so freeing the BSTR memory takes care of that for us.


One could combine this method with others on a more general COM
interface and agree to limit its use to MFC C++ clients (more
non-portable ugliness). The challenge is to get all the serialization
parts right for the array, maps, lists etc.

More by Author

Must Read