From: SourceForge.net <no...@so...> - 2005-11-03 03:19:39
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=3410740 By: xeee I've been working on something that required comsupp.lib(this is the library whose header is comutil.h), and I'm using MS VC Toolkit, this comsupp.lib comes only with MSVC 6 or MSVC .NET... so I decided to make a library that implements all the functions that exist in comsupp.lib. I started doing that, but I found that I needed only 3 functions, so I stopped there. here's the implementation, it includes functions to convert between ordinary char * and BSTR. use this code however you like, but don't remove the comment at the beginning, this could should work on MinGW as it relies on basic functionality found in windows. // Written by: Diaa Sami #include <Windows.h> #include <stdlib.h> #include <StrSafe.h> void __stdcall _com_issue_error(HRESULT hr) { #define MESSAGE_LENGTH_MAX 128 char message[MESSAGE_LENGTH_MAX]; StringCbPrintfA(message, MESSAGE_LENGTH_MAX, "_com_issue_error() called with parameter HRESULT = %lu", hr); MessageBox(NULL, message, "Error", MB_OK | MB_ICONERROR); } namespace _com_util { char * __stdcall ConvertBSTRToString(BSTR bstr) { const unsigned int stringLength = lstrlenW(bstr); char *const ascii = new char [stringLength + 1]; wcstombs(ascii, bstr, stringLength + 1); return ascii; } BSTR __stdcall ConvertStringToBSTR(const char *const ascii) { const unsigned int stringLength = lstrlenA(ascii); BSTR bstr = SysAllocStringLen(NULL, stringLength); wcstombs(bstr, ascii, stringLength + 1); return bstr; } } ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=286529 |
From: SourceForge.net <no...@so...> - 2005-11-03 07:08:21
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=3410876 By: tml1024 Sigh. I have never used BSTRs, but I have some idea what they are. This code is full of problems. Where should I start? > use this code however you like, but don't > remove the comment at the beginning, Considering that the relevant snippet in your code is only three lines, even if those were correct and bug-free, I think you are overestimating the difficulty of the posted problem, and the value and cleverness of your solution. > #include <Windows.h> The convention is to use <windows.h>. Not even Microsoft recommends using MixedCase names for the header files in #include statements, as far as I know. Using Windows.h will break cross-compilation from Unix. > const unsigned int stringLength = lstrlenW(bstr); Isn't the point of BSTRs that they are *counted* wide-char strings, that can contain embedded zero wide characters. Using lstrlenW is wrong. Instead, get the real length of the BSTR using SysStringLen(bstr). lstrlenW only counts how many non-zero initial wide characters the BSTR points to. It might return too low a value (if the BSTR has embedded zero wide characters) or might very well overrun the BSTR and return too high a value (if there doesn't happen to be a zero wide character (i.e. two zero bytes) after the last wide character of the BSTR). This might even cause a crash if lstrlenA happens to wander into an unallocated or read-protected page. > char *const ascii = new char [stringLength + 1]; From a stylistic point of view using the identifier "ascii" is highly confusing, as BSTRs are in Unicode, not at all restricted to ASCII, or even "ANSI". The real problem is that in general you might need twice as many bytes (C chars) as the length of the BSTR when you represent it as a Windows multi.-byte char string. (Remember double-byte code pages.) And if you use a new Microsoft C runtime, I think the codepage used in the C runtime's locale might even be 65001 (UTF-8), where each wide char in the BSTR might take up to four chars when converted to a multi-byte string. > const unsigned int stringLength = lstrlenA(ascii); Again you use the name "ascii" even though "char *" strings in C and C++ aren't just ASCII, but in general multi-byte strings in the current locale's codepage. lstrlenA will count the bytes, not characters, so for strings with multi-byte characters the allocated MBSTR will be too long, as each multi-byte character takes only one wide character. (OK, or two, for Unicode code points outside the BMP, that need two wide characters, i.e. a surrogate pair.) > wcstombs(bstr, ascii, stringLength + 1); Surely you mean mbstowcs and not wcstombs. But even then it is still wrong. Why are you using stringLength+1, when you allocated the BSTR to contain only stringLength worth of wide characters? This will overwrite what happens to be in memory after the BSTR. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=286529 |
From: Jeremy B. <je...@de...> - 2005-11-04 14:49:20
|
>> #include <Windows.h> > > The convention is to use <windows.h>. Not even Microsoft recommends using > MixedCase > names for the header files in #include statements, as far as I know. Using > Windows.h > will break cross-compilation from Unix. Sorry, I can't let that pass. Every single reference in MSDN to headers shows them in mixed case. Here is an example: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/getcommandline.asp Quote: "Declared in Winbase.h; include Windows.h." Headers for cross-compiling from unix should use the proper mixed case names. And code which does the include in lowercase is the sloppy code. |
From: Duncan M. <mi...@mu...> - 2005-11-04 15:17:24
|
On 11/3/2005 8:54 AM, Jeremy Bettis wrote: >>> #include <Windows.h> >> >> The convention is to use <windows.h>. Not even Microsoft recommends using >> MixedCase >> names for the header files in #include statements, as far as I know. Using >> Windows.h >> will break cross-compilation from Unix. > > Sorry, I can't let that pass. Every single reference in MSDN to headers > shows them in mixed case. Here is an example: > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/getcommandline.asp > > Quote: "Declared in Winbase.h; include Windows.h." > > Headers for cross-compiling from unix should use the proper mixed case > names. And code which does the include in lowercase is the sloppy code. "Every single"? I can't find any sample code that uses mixed case in the include statements. Not to claim that they uniformly use lowercase, but several examples I looked for do use it. For example, <http://msdn.microsoft.com/library/en-us/dllproc/base/using_the_high_level_input_and_output_functions.asp> The ref you give isn't to code, it's to text, where English lets us be sloppy. Duncan Murdoch |
From: Tor L. <tm...@ik...> - 2005-11-04 16:43:58
|
Jeremy Bettis writes: > Sorry, I can't let that pass. Every single reference in MSDN to headers > shows them in mixed case. > Quote: "Declared in Winbase.h; include Windows.h." That's in the *text* of an article. Can you find any *code* samples by Microsoft that uses '#include <Windows.h>'? I am not saying such samples don't exist, but the overwhelming majority of code samples uses <windows.h>. I googled for: windows.h stdio.h site:msdn.microsoft.com and the first dozen pagefuls of matches all had <windows.h> in lowercase. > Headers for cross-compiling from unix should use the proper mixed case > names. And code which does the include in lowercase is the sloppy code. Well, cross-mingw (which I guess is the most common cross-compiling environment?) definitely has the Win32 headers in all lower case. --tml |
From: SourceForge.net <no...@so...> - 2005-11-03 17:21:40
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=3411714 By: xeee well, thanks Tor for pointing out such mistakes in my code. I admit.... my code contains severe mistakes. well, I'm new to COM and OLE, in addition to some other reasons beyond this context. but please let me ask why your response was so offensive, I felt you were critisizing me.... I'm sorry for sending such buggy code, and I'll never try to participate again. my only purpose was to help the poor guy asking for assistance, no body replied him in 7 days, and then after I tried to help, you showed up with a reply full of destructive critisizm 3 hours after my post. Diaa Sami ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=286529 |
From: SourceForge.net <no...@so...> - 2005-11-03 17:27:48
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=3411728 By: tml1024 I'm sorry if my reply seemed offensive, that was not the intention. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=286529 |
From: SourceForge.net <no...@so...> - 2005-11-03 18:03:49
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=3411793 By: ross_ridge >but please let me ask why your response was >so offensive, I felt you were critisizing me. He only made constructive criticisms of your code. >I'm sorry for sending such buggy code, and I'll >never try to participate again. That would probably be for the best. Ross Ridge ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=286529 |
From: SourceForge.net <no...@so...> - 2005-11-06 14:51:50
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=3415283 By: kiklop74 If already have developed partial implementation of functions inside comsupp.lib for Borland compiler. With this implementation you can use all COM classes MS provided. (_bstr_t, _variant_t etc.) Code can be downloaded from here: http://cablemodem.fibertel.com.ar/mega/missing_libs/comsupp/comsupp.zip For any further info contact me. Darko ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=286529 |