That's the nature of incorrect code. Consider the following code:
abc = 'z';
On some compilers with some programs this code will crash, while on
others this code will "work". The fact that code may "work" on one
compiler or another does not make it correct. Your code is incorrect.
I can offer some conjecture on why your incorrect code seems to "work"
with Pelles-C but not with LCC-WIN32. A BSTR is a counted string. This
enables BSTRs to be used to pass binary data. The length is stored in
a DWORD that is placed immediately before the start of the string. A
wide string literal is not preceded by a DWORD length. I would guess,
that by chance, you are getting a "small" value for the length in
Pelles-C while, by chance, getting a "large" value in LCC-WIN32. Thus,
when this garbage value is used, say by the COM framework to marshal a
string across processes, the small value of Pelles-C does not cause a
trip into uncommited memory while the large value of LCC-WIN32 does.
Similarly, with malloc, you are likely getting a "reasonable" value
preceding your string.
This is certainly not the fault of LCC-WIN32. In fact, it is
preferable that incorrect code crashes immediately, rather than
receiving a call from your customer in six months time when they
install the latest OS update and your program starts crashing.
An OLESTR (which is a wide unicode string in Win32/64) is NOT a BSTR.
A BSTR MUST be allocated with one of the SysAlloc* functions. These
are the rules, break them at your own risk.
All this is covered in more detail in the BSTR link I posted above.
Note: Reply address is invalid.