OutputDebugStr() - how to see if it is going anywhere?
Bill Davy
How can I find out about my program's runtime environment in this respect?
TIA
Bill
Victor Bazarov
> Because if not,
Because if not what? Your question is "how", and the answer is "run
your program under a debugger, it will capture the output".
> I'd like to capture the output and append to a log file.
You can't do that unless you write a debugger (and use the debug API
available, see MSDN) and run your program under it.
> How can I find out about my program's runtime environment in this respect?
In what respect? If you need a non debugger driven program to output
some information only in debug mode, use
#ifdef _DEBUG
myDebugLog << "blah";
#endif
in your code.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Bill Davy
news:g8mkl3$a47$1...@news.datemas.de...
> Bill Davy wrote:
>> Because if not,
>
> Because if not what? Your question is "how", and the answer is "run your
> program under a debugger, it will capture the output".
>
> > I'd like to capture the output and append to a log file.
>
> You can't do that unless you write a debugger (and use the debug API
> available, see MSDN) and run your program under it.
>
>> How can I find out about my program's runtime environment in this
>> respect?
RUNTIME
>
> In what respect? If you need a non debugger driven program to output some
> information only in debug mode, use
>
> #ifdef _DEBUG
> myDebugLog << "blah";
> #endif
COMPILE TIME
Victor Bazarov
> "Victor Bazarov" <v.Aba...@comAcast.net> wrote in message
> news:g8mkl3$a47$1...@news.datemas.de...
>> Bill Davy wrote:
>>> Because if not,
>> Because if not what? Your question is "how", and the answer is "run your
>> program under a debugger, it will capture the output".
>>
>>> I'd like to capture the output and append to a log file.
>> You can't do that unless you write a debugger (and use the debug API
>> available, see MSDN) and run your program under it.
>>
>>> How can I find out about my program's runtime environment in this
>>> respect?
>
> RUNTIME
>
>> In what respect? If you need a non debugger driven program to output some
>> information only in debug mode, use
>>
>> #ifdef _DEBUG
>> myDebugLog << "blah";
>> #endif
>
> COMPILE TIME
>
>> in your code.
<shrug> You might consider being a bit more verbose. Do you want your
program to know whether it's running under a debugger and behave
differently if it is?
Bill Davy
Yes.
Or, if you prefer, that's an affirmative response.
Bill
Victor Bazarov
Then I do not know the answer. Ask in 'microsoft.public.vc.language',
but don't hold your breath. If I had to guess, you probably could try
enumerating all processes in the system and find out which one is the
parent process of yours. But then it's questionable what would happen
if you 'attach' the debugger instead of starting your process in one...
My next question is, *why* do you think you *need* that? Protection
from cracking? Perhaps other ways to accomplish what you need without
finding out whether you're running under a debugger...
Pavel A.
> Because if not, I'd like to capture the output and append to a log file.
> How can I find out about my program's runtime environment in this respect?
>
Get this little wonderful program, it will show all the ODS()
spew of your app, and log to a file, too.
http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx
--PA
Alex Blekhman
> How can I find out about my program's runtime environment in
> this respect?
In addition to Pavel's answer. You can detect whether the process
is under a debugger with `IsDebuggerPresent' API function.
HTH
Alex
Pavel A.
Ah. Now I understand what the OP wants.
Then, IsDebuggerPresent gives exactly that: tells you whether a debugger
is attached to your app. But even if not, debug spew can still show up
elsewhere: DebugView is not a debugger, nevertheless, it will show the
spew. OTOH, a real debugger may ignore the spew.
So if the OP really needs to know if somebody is listening, in runtime,
he has to roll his own...
or, maybe, look at EWT (aka "WMI trace"), it comes with it's own
control interface.
Regards,
--PA
Bill Davy
news:OQStMIIB...@TK2MSFTNGP03.phx.gbl...
Many thanks to all for their comments.
I think I have enough to be getting on with.
FWIW, I share the view of someone who said turning off ASSERT in the release
version is like taking off the lifebelt when you go out to sea. I feel much
the same about log output, at least during initial deployment.
Rgds,
Bill
Pavel A.
..........
> FWIW, I share the view of someone who said turning off ASSERT in the release
> version is like taking off the lifebelt when you go out to sea. I feel much
> the same about log output, at least during initial deployment.
Nevertheless, the assert/ASSERT macro is documented to take action
only in debug build.
Usually people define another set of checks and prints/traces
to stay in release builds.
Also, debug APIs like ODS() have some security and stability issues,
so make sure these are disabled by default.
--PA