Re: HRESULT
* Joseph M. Newcomer:
See below...
On Sat, 29 Mar 2008 23:15:30 +0100, "Alf P. Steinbach" <alfps@start.no> wrote:
* Joseph M. Newcomer:
See below...
On Sat, 29 Mar 2008 14:30:13 +0100, "Alf P. Steinbach" <alfps@start.no> wrote:
* Joseph M. Newcomer:
See below...
On Fri, 28 Mar 2008 19:31:17 +0100, "Alf P. Steinbach" <alfps@start.no> wrote:
* Giovanni Dicanio:
Maybe FormatMessage with HRESULT works only for some APIs (like when you
successfully used it) but not for all...
FormatMessage is a general message formatting and retrieval facility, supporting
internationalization, in a crude form, as well as message parameters.
It works with plain error codes, too (choosing error code interpretation
ERROR_SUCCESS for numerical value 0).
It retrieves messages from message modules. When you specify "system" flag it
uses modules that contain the [winerror.h] error messages, plus some. For some
APIs, e.g. like RAS, where the "system" flag isn't sufficient, message module
DLLs are (still undocumented, AFAIK) available (quirk, don't know if it's still
that way in XP and Vista: the documententation used to say you could specify
"system" plus a module, but that didn't use to work, you could use one or other
but not both).
*****
I have not used a version of Windows in which it did not work. You must have been doing
something wrong.
****&
The code was correct. And your inference is not logically sound.
****
I have used FormatMessage using a module handle since NT 3.51 without problems; I even
wrote about this in 1996 or so. So I don't know why you say it doesn't work. It even
states that when both flags are specified, it selectively tries the system first
beforetrying the HMODULE. I also wrote an essay on how to use FormatMessage to locate
error codes for WinSock in the winsock DLL, and that has worked for years. So why do you
claim it doesn't work?
****
That is a misrepresententation.
As you can see from the text you quoted, I didn't "claim it doesn't work" as you
write, I related experience that "the documententation used to say you could
specify system" plus a module, but that didn't use to work, you could use one or
other but not both".
****
I presumed that by 'that', you were referring to that fact that <"system" plus a module>
didn't work; in fact, you could always use both, not just one or [the] other. So your
statement seems very clear, and as such, is wrong.
****
Hm, I don't understand what you mean here, but no matter.
Now I've invested some time (I wonder whether it's worth it, because the rest of
your reply here is in the same vein as above, argumentative and rhetoric instead
of seeking clarification on the technical) checking old files, and the problem
then, late 90's, manifested with error codes wrapped as HRESULTs via
HRESULT_FROM_WIN32. For example, error code 0x3F should yield the same result
as 0x8007003F. But with both "system" and a HMODULE specified, FormatMessage
didn't grok the latter, and as it happens, still doesn't under Windows XP (I
think it's SP2).
****
This is a different statement from what you said. You said that it would not work if you
specified both system ahd from-a-module. Now you are saying something different, that
0x3F and 0x8007003F should give the same message. These are different codes, clearly, and
I'm not sure why FormatMessage would be expected to resolve a code that was the result of
HRESULT_FROM_WIN32.
They're the same code, represented as 16-bit error code and as HRESULT,
respectively. FormatMessage deals successfully with both when only using
"system". Add HMODULE and it fails for the HRESULT (on XP).
The FormatMessage description does not suggest that it supports this.
But that is not what you stated originally.
Grumble. I used some time on finding the exact failure mode from old files.
Please don't expect me to remember such details off-hand, for a usenet posting
fifteen years on (so initially I just gave the general description)...
****
It is relatively easy to fix.
The fix is as described in what I actually wrote. :-)
The MFC *libraries* allow you to use it,
but it has nothing to do with the compiler. Except for the .tlb support provided by
#import, the compiler doesn't even know COM exists.
That, Mr. Newcomer, is fortunately /also/ incorrect. :-)
****
OK, what part of the compiler knows about COM? Please identify. Those "COM-specific"
keywords are what, exactly?
Well, you have either misleadingly snipped a lot of context here, or are
referring to something discussed later in a different context.
A positive interpretation would be the latter.
Just to be clear on that, since I think anyone reading your statements could
easily be misled, the COM specific or strongly COM-related keywords have to do
with general COM support, not with error message retrieval.
****
What COM-specific or strongly COM-related keywords? The terms I am familiar with are NOT
keywords in the C language, they are merely macro definitions from some header file. As
such, they are not "COM-specific keywords" any more than "printf" is an "I/O-specific
keyword" or ULONG is a "scalar-specific keyword". These are not keywords in the C or C++
languages, they are just #defines, or typedefs, or classes, or whatever, but that does not
elevate them to being an intrinsic part of the compiler, any more than 'cos' is a
"math-specific keyword".
****
I have never seen one.
That seems to be inconsistent with you mentioning "import" above. Although it's
open to debate whether a preprocessor directive counts as a keyword. I suppose
that in an adversarial debate, which this seems to be from your point of view,
it technically isn't, and so does not count, narrowly focusing it down to a
formal meaning of "keyword" rather than what COM support there is. :-)
****
Remember, I said the ONLY COM-specific support I was aware of in the compiler was #import,
yet you are making the claim that there are tons of COM-specific keywords. The only one I
know of that is supported by the compiler is #import; everything else is outside the
compiler, in header files
****
But anyway, I'm happy to help.
Here's one example, from the docs: "The keyword __uuidof can be applied to
retrieve the constant GUID attached to a user-defined type."
****
OK, I agree. That's ONE reserved word. So now we have two.
And more below.
The guid is a keyword for __declspec, which is outside the scope of the language
definition.
"__uuidof" retrieves GUID, while keyword "uuid" (yes, it's listed as a keyword)
defines the GUID.
At this point, we have 2+1 = three keywords.
Just in case you don't know, GUIDs are 128 bit identifiers used to dynamically
identify COM interfaces and other COM things. I'm relatively sure that if I
didn't say it you would mention that they can also be used for other things, not
just COM. The compiler's support for them, however, is in support of COM.
****
You've obviously been reading my essays on the use of GUIDs
:-) No, sorry. Perhaps I'll do that.
****
From a pure C++ point of view this COM-support language extension is plain
silly, since the same can easily be achieved via templates, within the standard
language, but that same compiler also compiles C. I wish Microsoft could have
limited that particular extension to just C. On the other hand, it allows C +
C++ programmers to only familiarize themselves with a single mechanism.
Then we have the "__interface" keyword. AFAIK it was introduced to handle COM
interfaces. But was general enough that it served also for .NET.
Well, then, at this point we have 3+1 = four keywords, as I count.
And we have "__event", "__hook", "__unhook" and "__raise", which are not purely
COM specific but work for COM (and also general C++ classes and managed .NET).
****
Yes, it said explicitly that these extensions are to support non-COM communication and to
provide a mechanism for inter-module signaling
And at this point we have 4+4 = eight keywords, as I count.
*****
Attribute programming, yet another language extension, introduced a host of
different special words in support of COM, but since they are used within
attribute definitions (lots of square brackets) they're not exactly language
keywords, and I'm not familiar with them. Don't know whether it helps you. But
as you can see, contrary to your claims, the Visual C++ compiler does include
quite a lot of COM support via /language extensions/.
_bstr_t is not a keyword, for
example. It is just a data type defined in comutil.h.
Right you are.
That does not make it "intrinsic"
to the compiler, no matter what the documentation wants to call it.
But here you're wrong. What's intrinsic in a formal sense is whatever the
documentation says is intrinsic, belonging to the compiler: not necessarily
physically built-in. And what's intrinsic in a practical (non-adversial) sense
is a bit more.
****
So cos, sin, printf, etc. are "intrinsic" by that definition. I'm not sure anyone else
would agree with this as being "intrinsic" to the compiler. They;re just libraries.
****
For example, early versions of Visual C++ didn't support wchar_t directly, you
had to include some header file. And as far as I know, you can check this out
rather than me, 7.1 uses the same scheme with respect to standard C++ keywords
such as "and" (synonym for &&), and I suspect it's still so with later versions.
****
It was a hack in VS5 or something like that, they used 'short' because the ANSI/ISO
standard did not have a type defined for wide characters. So they took the proposed name,
wchar_t, and made it a typedef of 'short'. But we're talking the C++ compiler now, and it
*is* an intrinsic data type.
****
Since "and" is required by the C++ standard as keyword, in the standard without
having to #include anything, the support must be regarded as intrinsic in a
compiler that's meant to implement the standard, in the sense that that support
is part and parcel of the compiler.
****
'and' and 'or' are required as keywords because in some languages, the symbols & and |
(among others) are considered alpha characters (see, for example, Stroustrup, "The C++
Programming Language, Third Edition" p.829. What does this have to do with the
discussion?
****
Not very much. It pertains to use of word "intrinsic", which I don't agree is
very important at all. :-)
_com_raise_error is
just a function call. According to its documention, it is found in comsupp.lib, which
means it is no more an compiler intrisic function than cos() or sqrt().
A COM Support Class is just a class, and does not require specific knowledge of the
compiler to make it work.
Perhaps you are confusing marketing hype with language definition.
For example, look at comdef.h, there _com_raise_err and _com_error class are defined. They
don't require compiler enhancements, they're just classes defined like any other class.
Your example, _bstr_t, is just a class, defined in comutil.h, just another header file!
The support is not "intrinsic"; you contradict yourself because you show below you are
clearly including a header file to get it!
It seems you're hung up on a word definition, having been shown to be wrong on
the main points.
****
The main point was an issue of the C++ compiler having tons of keywords to support COM. So
far, we've identified two (#import and __uuidof) and one which is part of __declspec.
Eight -- see above.
The
other keywords are extensions that *happen* to work well for COM, but __event, __hook, and
__raise are clearly COM-independent (the documentation even says so).
Since they can generate COM code there is some connection to COM, don't you
think? :-)
You said
The Visual C++ compiler's support for COM is very extensive, involving both
syntactical structures with COM-specific keywords, and library components
documented as "Compiler COM Support Classes".
****
There are really only two syntactic structures, __uuidof and __declspec(uuid, ...). But
the library components are not any more intrinsic to the compiler than 'cos' or 'sin'. You
could state
"The Visual C++ compilers support for math is very extensive, involving both syntactical
structures with math-specific keywords and library components documented as "Mathematical
functions" "
But the only syntactic structures for math are the declarations double and float, and the
way to write double and floating constants. The support for math is actually far more
entensive, because it involves the semantics of code generation for operators like +, -,
*, /, %. But functions such as floor(), ceil(), sin(), cos(), etc. are not part of the
compiler. They are part of the runtime support, and as such have no special consideration
any more than any other function a user might write. but a serious mathemetician would
laugh at this "support", since there is no support for Bessel functions, Jacobeans, matrix
operations, matrix inversion, determinants, etc.
A library which is part of the operating environment doesn't make it an intrinsic part of
the compiler.
****
Sorry, I can't help you with that, other than point you to google with search
string "define: intrinsic".
Or e.g. <url: http://www.thefreedictionary.com/intrinsic>.
***
By that definition, __uuidof and #import are intrinsic. _bstr_t is not. Which was my
point. I was off by one keyword, __uuidof.
****
Please identify the COM-specific keywords that the compiler defines.
See above. I can't guarantee that that's a complete list. :-)
These would be
reserved words in the C/C++ language, not something found as a #define, class, or template
in a header file.
No, that's incorrect. Neither the C nor the C++ language defines anything
COM-related. However, Visual C++ does, as language extensions (again, see above).
****
We're up to two keywords in the language extensions. Or three, counting #import.
****
The count seems to be rising. :-) Let's settle on eight, and ignore attribute
programming for discussion of keywords (as opposed to more general COM support).
****
The Visual C++ compiler's support for COM is very extensive, involving both
syntactical structures with COM-specific keywords, and library components
documented as "Compiler COM Support Classes".
****
And is printf part of the C language? I think not. printf is part of the C library
support. It is not intrinsic to the C compiler. As soon as you have to say #include, it
is no longer "intrinsic" to the compiler.
****
I would tend to agree there, regarding the Visual C++ implementation of the C++
language, but for a very different reason (conclusion OK, reasoning invalid).
Namely, that to qualify as a conforming C++ compiler for GUI subsystem programs,
with otherwise default options, Visual C++ must be regarded as a so called "free
standing implementation" instead of a "hosted implementation".
And IIRC a free-standing implementation doesn't need to provide printf, hence
it's not an essential part of the compiler (whether it's provided via a library
or by direct code generation by the compiler is an irrelevant implementation
issue, except in the context of discussing physical packaging of compiler).
****
I agree. printf is just a subroutine library. We never needed it for writing embedded
systems.
*****
The intrinsic COM support is essentially the COM support you have when you
subtract MFC and ATL from a basic Visual C++ installation.
So instead of a trivial API, I have to use all of COM to decode an error message? What
part of "simplicity" did I miss here?
<code>
#include <iostream>
#include <ostream>
#include <comdef.h> // Intrinsic COM support lib components.
#include <winerror.h>
int main()
{
using namespace std;
long const e = ERROR_CLASS_ALREADY_EXISTS;
cout << _com_error( e ).ErrorMessage() << endl;
****
What good is cout() in a WIndows app? There's no cout.
I think you mean a GUI subsystem application, for which that statement is incorrect.
****
Yes, I was sloppy in my terminology. Exactly: a GUI subsystem application.
****
In a GUI subsystem application there is a standard output stream, although not
necessarily connected to anything, which you can access via std::cout in C++.
****
The bits appear to be thrown away.
See the usage example I provided right below.
****
And if you want that GUI subsystem standard output displayed in a console
window, simply pipe the output to a cat program, or e.g. (ugh) Windows' more:
C:> myGuiApp | more
Here ^^^^^^^^^^^^^^^.
And how does this differ in any
significant way from what I would write
DWORD err = ::GetLastError();
CString s;
s = ErrorString(err);
It's simpler in many contexts. For example, when not using MFC or ATL.
****
Other than discarding the string, which is handled automatically by the destructor, it
appears to be no different
****
So you are saying YOUR function is Good, but MY function is bad?
No, (getting repetitive, this) that's incorrect. :-)
At least my function has
a specification of how it behaves; _com_error::ErrorMessage is not well-defined.
Yes, that's a general problem with Microsoft's software.
****
No disagreement there. I find the documentation to be full of holes
****
If you have a well-documented error message retrieval function it is probably in
many respects better than any such provided by Microsoft.
But not necessarily available to whomeever, wherever, whenever.
[snip]
Since I was not asking for help, I have no need to goad anyone into giving it to me. You
made a gross mis-statement of fact, that there was "intrinsic" COM support in the
compiler, and there is no such support.
No, that's incorrect -- see above.
****
Yes, and I stand corrected. There are two intrinsics: __declspec(uuid, ) and __uuidof. My
error.
Well, I also count __interface, as well as the four event handler code
generation keywords, for a total of eight. And there's #import, a preprocessor
directive. Plus, in the area of non-keyword-based COM support, requiring deep
knowledge of COM embedded in the compiler, attribute based programming.
Cheers, & hth.,
- Alf
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?