This is all you'll be needing: _bstr_t b_dataBaseName = "C:\\Image.mdb"; _bstr_t b_strFile = "C:\\Trainer\\final1.txt"; _Class1Ptr ptr; ptr.CreateInstance(__uuidof(Class1)); ptr->MakeDB( b_strFile, b_dataBaseName); I have given the impression that it was SysAllocString takes a char* and converts it to a widestring. That is not true. Sorry for that. In the above code, the _bstr_t does all the work for you: - it converts the char* to wchar_t* - it makes calls to SysAllocString() and SysFreeString() when needed So there's no need to make calls to SysAllocString yourself when using a _bstr_t.

The short answer:place a call to SysAllocString around your char*. The longer one: Strings in COM are not 'char*' , but 'BSTR', which is a length-prefixed, wide-character string. Furthermore, allocation of these BSTR must be handled by the COM runtime, you are not allowed to do it yourself. SysAllocString() allocates a block of memory to hold the string you passed it, converted to a widestring and returns a pointer to this memory-block. You can use that pointer as an argument in your method-call. When your finished with the BSTR, you should call SysFreeString() on it. If you're going to use COM from C++, you will save yourself a lot of trouble by reading some initiating articles, like Beginner's Tutorial: Calling Visual Basic ActiveX DLLs from Visual C++ here at The Code Project.

I stand completely corrected. I was confused with the change from 'delete [n] array' to 'delete [] array'. And I was lucky in the example I gave, because the difference between 'delete [] array' and 'delete array' is that in the latter case no destructors are called while in the former they are. But in my example I was silly enough to use char's, who, obviously, have no destructors at all.

I've delved into my archive and found that the technique actually is called 'DISPID Encoding' and I first learned it from 'Professional ATL COM Programming' by Richard Grimes (Wrox Press, 1998). At http://www.codeguru.com/atl/dispidEncoding.html you can find it online.

Just being obnoxious: if I'm not mistaking the 'delete[]'-syntax is no longer needed when trying to delete an array. Following code does exactly the same thing twice: void main() { char* s = new char[10]; delete s; char* p = new char[10]; delete []p; }

Isn't it best to convert the single-byte to wide-format? If conversion from wide- to single-byte format looses information (because some widechars are not representable), the strings might match after conversion, even if they don't actually match... No?

You actually should be thankful for the user-breakpoint: it is called by the debug-version of your program, because an assert failed. RtlFreeHeap even tells you why it failed: you're trying to free a memory-block that either has been damaged or was never allocated. RtlFreeHeap knows this because it puts a signature before and after each allocated block and the signatures before the block you're trying to free don't match. Figure out which variable is being mishandled, and your program will stop acting weird. When you say it 'worked before', you're probably saying it worked in release-build: no assertions are being performed, and the RT will be happy to free anything you ask it to, even things that were never allocated.

As you stated, an interface must never change after initial publication. But you can support new interfaces from an existing component. Maybe your problem can be solved simply by adding a new interface everytime methods need to be added. Thus you can - use early binding, and have the convenience of intellisense. - update clients simply by distributing the typelib Of course, if clients want to use these new methods, they'd have to be aware of these new interfaces in order to request them. But they'd have to be adapted for the use of the new method anyway, so that doesn't seem to pose any problem. By the way, you can expose the methods of multiple interfaces through IDispatch, and there's a rather elegant solution to this using ATL and what I believe is called 'bitmap-id fields'.

Splitting of words happens between two syllables. e.g.: Split-ting, not Spl-itting :)

It looks like you want a system-wide singleton (accross process boundaries). You would indeed get funny results with this approach: - different processes (in your example: IIS and the C++-application) instanciating your component would get a singleton *per process*. - any static data you maintain dies when your dll goes out of memory: this happens if all interfaces are released: DLLCanUnload is called on a regular basis, and when it returns true (default ATL-implementation: when all reference counts are zero), the dll is unloaded. You can solve this problem by leaving the COM-singleton for what it is, designing your component as a multiply instantiatable component and using either static data in a persistent, out-of-process server (take a look at ATL-service) or simply persist your data in a database.

getnameinfo (WinSock2) returns the hostname for a given IP-address (gethostbyaddr is simpler in usage, but deprecated)

A first-change exception normally is not a problem: it's the debugger's opportunity to see an exception before it is being handled by an exception handler (or catch-block). If no exception is propagated to your code, that means the writer of the library has foreseen the possibility of this exception and written an appropriate catch-block. So don't worry about it.

Simply look in barstat.cpp at line 266. The expression within ASSERT() (or similar) at that line evaluates to false running under ME, not in Windows95. Or even easier: open in MS VC++, place somewhere before barstat.cpp 266, and trace the value of the expression.