OutputDebugString vs TRACE?? 
Author Message
 OutputDebugString vs TRACE??

Just to augment Joe's augmentation of Rowland's post...

OutputDebugString also has a fixed sized buffer, of 1024
characters I believe, so if you try and print more than that at
one go it will get truncated.

For some reason the fixed size buffer used by TRACE is
smaller - just 512 characters. Odd...

Also, TRACE lets you redirect the output to an arbitrary
CDumpContext, so you can redirect it to a file if you want.

OutputDebugString - using this means you can't use printf
style formatting, means you need to include <windows.h>,
and it means you're putting in gratuitious Windows
dependencies in your code.

TRACE() - this offers a lot of advantages over
OutputDebugString. It sort of means you're putting in
gratuitious MFC dependencies, but you can always implement
TRACE yourself for non-MFC projects.

Alternately, many people implement dprintf() or some
equivalent, which is just a different name for TRACE() and
can also use OutputDebugString or write to a file, and may
offer extra options.

It's also worth noting that you can use OutputDebugString
in release builds as well - not just debug builds. However
you should avoid shipping products that still use
OutputDebugString. TRACE gets removed in release builds
automatically, which is usually what you want. It's also
convenient to have a variant macro that is retained in
release builds, to aid in debugging them.

.Bruce Dawson.

P.S. I hate developers who leave calls to OutputDebugString
in their release code. When I'm running DBWin32 or other
OutputDebugString trappers I get occasional debug spews
from shipped applications running on my machine. For some
reason it's mostly sound drivers, which clutter up my debug
output window whenever I'm debugging a multi-media app.
Creative Labs - are you listening?

Quote:

> Greets,

>     Just to augment Rowland's post.... TRACE uses OutputDebugString()
> internally, yet with a fixed size buffer.  You may consider your own macros,
> functions or templates that do same yet offer more flexibility.

> Regards,

> Joe



> > OutputDebugString() is a Win32 function (part of the API), and TRACE is a
> > macro which, I believe, is part of MFC which in turn calls
> > OutputDebugString() (AFAIK)

> > OutputDebugString() can be used without a de{*filter*}; use a tool like
> > debugview from www.sysinternals.com to view the output though...


> > > Whats the difference between OutputDebugString and TRACE?

> > > Which one is the best??

> > > Also can I use these without starting the de{*filter*}?

> > > I mean if I set the Active Configuration to Win32 Debug, but not start
> the
> > > de{*filter*} can I still use these methods to output to Visual Studios
> output
> > > window??
> > > Are there any other methods that can write to the output window in
> Visual
> > > Studio without starting the de{*filter*}?

--
.Bruce Dawson, Humongous Entertainment (we're hiring).
http://www.*-*-*.com/
Send job applications by e-mail, post technical questions
to the newsgroups please. Thanks.


Tue, 22 Apr 2003 03:00:00 GMT  
 OutputDebugString vs TRACE??

Whats the difference between OutputDebugString and TRACE?

Which one is the best??

Also can I use these without starting the de{*filter*}?

I mean if I set the Active Configuration to Win32 Debug, but not start the
de{*filter*} can I still use these methods to output to Visual Studios output
window??
Are there any other methods that can write to the output window in Visual
Studio without starting the de{*filter*}?



Tue, 22 Apr 2003 22:03:24 GMT  
 OutputDebugString vs TRACE??
OutputDebugString() is a Win32 function (part of the API), and TRACE is a
macro which, I believe, is part of MFC which in turn calls
OutputDebugString() (AFAIK)

OutputDebugString() can be used without a de{*filter*}; use a tool like
debugview from www.sysinternals.com to view the output though...

Quote:

> Whats the difference between OutputDebugString and TRACE?

> Which one is the best??

> Also can I use these without starting the de{*filter*}?

> I mean if I set the Active Configuration to Win32 Debug, but not start the
> de{*filter*} can I still use these methods to output to Visual Studios output
> window??
> Are there any other methods that can write to the output window in Visual
> Studio without starting the de{*filter*}?



Tue, 22 Apr 2003 22:14:13 GMT  
 OutputDebugString vs TRACE??
Greets,

    Just to augment Rowland's post.... TRACE uses OutputDebugString()
internally, yet with a fixed size buffer.  You may consider your own macros,
functions or templates that do same yet offer more flexibility.

Regards,

Joe


Quote:
> OutputDebugString() is a Win32 function (part of the API), and TRACE is a
> macro which, I believe, is part of MFC which in turn calls
> OutputDebugString() (AFAIK)

> OutputDebugString() can be used without a de{*filter*}; use a tool like
> debugview from www.sysinternals.com to view the output though...


> > Whats the difference between OutputDebugString and TRACE?

> > Which one is the best??

> > Also can I use these without starting the de{*filter*}?

> > I mean if I set the Active Configuration to Win32 Debug, but not start
the
> > de{*filter*} can I still use these methods to output to Visual Studios
output
> > window??
> > Are there any other methods that can write to the output window in
Visual
> > Studio without starting the de{*filter*}?



Tue, 22 Apr 2003 22:20:12 GMT  
 OutputDebugString vs TRACE??

Guys, Your answers are great!

I have something new to tell you, but it is for remote debugging and
multiple local code units (threads, processes) debugging .

The application name is Team Remote De{*filter*} 2000.

Team Remote De{*filter*} 2000 allows you and your team to trace any number of
code units of any kind (ASP,MTS,ActiveX Exe,DLL, COM,COM+,Thread,etc.),
written in any language (ASP, VB,VC++,VJ,Delphi) residing on multiple shared
and dedicated servers at the same time fast, easy, simple and exciting!

You can debug any number of code units anywhere by many programmers at the
same time!

Check out
www.RemoteDe{*filter*}.com/Index.Html

Take Care,

Dan
Chief Software Architect
Spline Technologies Corp.
"Achieve More!"


Quote:
> Just to augment Joe's augmentation of Rowland's post...

> OutputDebugString also has a fixed sized buffer, of 1024
> characters I believe, so if you try and print more than that at
> one go it will get truncated.

> For some reason the fixed size buffer used by TRACE is
> smaller - just 512 characters. Odd...

> Also, TRACE lets you redirect the output to an arbitrary
> CDumpContext, so you can redirect it to a file if you want.

> OutputDebugString - using this means you can't use printf
> style formatting, means you need to include <windows.h>,
> and it means you're putting in gratuitious Windows
> dependencies in your code.

> TRACE() - this offers a lot of advantages over
> OutputDebugString. It sort of means you're putting in
> gratuitious MFC dependencies, but you can always implement
> TRACE yourself for non-MFC projects.

> Alternately, many people implement dprintf() or some
> equivalent, which is just a different name for TRACE() and
> can also use OutputDebugString or write to a file, and may
> offer extra options.

> It's also worth noting that you can use OutputDebugString
> in release builds as well - not just debug builds. However
> you should avoid shipping products that still use
> OutputDebugString. TRACE gets removed in release builds
> automatically, which is usually what you want. It's also
> convenient to have a variant macro that is retained in
> release builds, to aid in debugging them.

> .Bruce Dawson.

> P.S. I hate developers who leave calls to OutputDebugString
> in their release code. When I'm running DBWin32 or other
> OutputDebugString trappers I get occasional debug spews
> from shipped applications running on my machine. For some
> reason it's mostly sound drivers, which clutter up my debug
> output window whenever I'm debugging a multi-media app.
> Creative Labs - are you listening?


> > Greets,

> >     Just to augment Rowland's post.... TRACE uses OutputDebugString()
> > internally, yet with a fixed size buffer.  You may consider your own
macros,
> > functions or templates that do same yet offer more flexibility.

> > Regards,

> > Joe



> > > OutputDebugString() is a Win32 function (part of the API), and TRACE
is a
> > > macro which, I believe, is part of MFC which in turn calls
> > > OutputDebugString() (AFAIK)

> > > OutputDebugString() can be used without a de{*filter*}; use a tool like
> > > debugview from www.sysinternals.com to view the output though...


> > > > Whats the difference between OutputDebugString and TRACE?

> > > > Which one is the best??

> > > > Also can I use these without starting the de{*filter*}?

> > > > I mean if I set the Active Configuration to Win32 Debug, but not
start
> > the
> > > > de{*filter*} can I still use these methods to output to Visual Studios
> > output
> > > > window??
> > > > Are there any other methods that can write to the output window in
> > Visual
> > > > Studio without starting the de{*filter*}?

> --
> .Bruce Dawson, Humongous Entertainment (we're hiring).
> http://www.*-*-*.com/
> Send job applications by e-mail, post technical questions
> to the newsgroups please. Thanks.



Fri, 25 Apr 2003 03:00:00 GMT  
 OutputDebugString vs TRACE??
Quote:

> P.S. I hate developers who leave calls to OutputDebugString
> in their release code.

Why?

Quote:
> When I'm running DBWin32 or other
> OutputDebugString trappers I get occasional debug spews
> from shipped applications running on my machine.

Well, I think the code to Dbmon is present amongst the code samples and
so (if memory serves me right) you can tweak it to ignore the debug
prints from some processes/threads, for example you could make it read
some text file with IDs of what to look for and then ignore everything
else.


Tue, 10 Jun 2003 03:13:32 GMT  
 OutputDebugString vs TRACE??


Quote:

> > P.S. I hate developers who leave calls to OutputDebugString
> > in their release code.
> Why?

What possible reason do you have for shipping something with
OutputDebugStrings in release code? Its meant for debugging purposes alone.
Not only does it slow down code (very very little but not == 0), but IMHO
indicates sloppy programming/testing


Mon, 16 Jun 2003 13:42:04 GMT  
 OutputDebugString vs TRACE??

Quote:



> > > P.S. I hate developers who leave calls to OutputDebugString
> > > in their release code.
> > Why?

> What possible reason do you have for shipping something with
> OutputDebugStrings in release code? Its meant for debugging purposes
alone.
> Not only does it slow down code (very very little but not == 0), but IMHO
> indicates sloppy programming/testing

It's impossible to completely test your program in all environments.  I
agree that they shouldn't be running all the time, but I see nothing wrong
with a command line switch to enable them to help debug at a customers site
if they have a problem.


Tue, 17 Jun 2003 05:08:01 GMT  
 OutputDebugString vs TRACE??
Quote:




> > > P.S. I hate developers who leave calls to OutputDebugString
> > > in their release code.
> > Why?

> What possible reason do you have for shipping something with
> OutputDebugStrings in release code?

I, personally, wouldn't see anything wrong with printing some diagnostics.

Quote:
> Its meant for debugging purposes alone.

Says who? Raj Ranjagarajan? Well, seems like Jeremy disagrees with that.

Quote:
> Not only does it slow down code (very very little but not == 0), but IMHO
> indicates sloppy programming/testing

Bullshit. You're simply not an experienced developer and have a bunch of preconceived
notions that are based on nothing. It's part of the Windows API and you can use it for
whatever the hell you want in any environment. Hell, you can use it for IPC, for that
matter (not that it's popular, but possible.) After all, what's so special about "Debug"
vs "Release" builds? It's just two precooked configurations set by a #define. That's the
way Microsoft "helps" guys like you who don't know any better. You can create a million
other configurations and call them what you want. You're missing the point here.


Tue, 17 Jun 2003 11:56:43 GMT  
 OutputDebugString vs TRACE??
Quote:






> > > > P.S. I hate developers who leave calls to OutputDebugString
> > > > in their release code.
> > > Why?

> > What possible reason do you have for shipping something with
> > OutputDebugStrings in release code? Its meant for debugging purposes
> alone.
> > Not only does it slow down code (very very little but not == 0), but IMHO
> > indicates sloppy programming/testing

> It's impossible to completely test your program in all environments.  I
> agree that they shouldn't be running all the time, but I see nothing wrong
> with a command line switch to enable them to help debug at a customers site
> if they have a problem.

Bingo! A very good point. The reader needs to keep in mind that one doesn't need a
de{*filter*} to read them (check DbMon code sample.) You can log these messages, you can pump
them into another program, or to the network, whatever. Just because it's called Output
DEBUG string, doesn't mean it's "for debugging only." It's a useful facility that one can
use whenever it fits the task.


Tue, 17 Jun 2003 12:00:04 GMT  
 OutputDebugString vs TRACE??

Quote:
> > What possible reason do you have for shipping something with
> > OutputDebugStrings in release code?
> I, personally, wouldn't see anything wrong with printing some diagnostics.

I concur, although I'd much rather prefer debugging release code remotely
rather than having it tagged with a bunch of diagnostic code.

Quote:
> Bullshit. You're simply not an experienced developer and have a bunch of
>preconceived

There was no need for a personal attack here, but I am glad you are here to
share your vast knowlege with the rest of us.


Tue, 17 Jun 2003 16:12:39 GMT  
 OutputDebugString vs TRACE??


Quote:
>> > What possible reason do you have for shipping something with
>> > OutputDebugStrings in release code?
>> I, personally, wouldn't see anything wrong with printing some diagnostics.

>I concur, although I'd much rather prefer debugging release code remotely
>rather than having it tagged with a bunch of diagnostic code.

What about debugging the release version, which at sometime, you will
need to do (even if it's a "little" debug) and ODS() helps no-end.
Load the exe into DevStudio, start the debug session, let DS moan
there's no debug info, then happily watch the output window for that
tell-tale bad-data to find out why the {*filter*}y thing doesn't work under
release mode.

Also, output to the debug stream for a release version is nice,
especially a small signature for program description and version
number output, so anyone debugging your exe will have some info to
tell you (if needed).

Hope this helps,

Jimbo



Tue, 17 Jun 2003 20:43:06 GMT  
 OutputDebugString vs TRACE??

Calling OutputDebugString in a release build is fine. However calling
OutputDebugString in the shipped build is sloppy - unless it only happens
when enabled with a command line switch or something similar. It slows
down the program and intereferes with debugging on developers machines
(I shouldn't have to rebuild dbmon!)

The worst case is the sound drivers on my machine which spit out 150
lines of OutputDebugString text. That means that when I am debugging any
of my apps that uses sound or AVI then I get a massive burst of irrelevant
debug info. It takes several seconds for it to all scroll by.

Quote:

> What about debugging the release version, which at sometime, you will
> need to do (even if it's a "little" debug) and ODS() helps no-end.
> Load the exe into DevStudio, start the debug session, let DS moan
> there's no debug info, then happily watch the output window for that
> tell-tale bad-data to find out why the {*filter*}y thing doesn't work under
> release mode.

I agree that debugging the release version is critically important. However
if you're still listening to "DS moan there's no debug info" then you're
working too hard. You can and should enable debug info in release
builds. Always.

Quote:
> Also, output to the debug stream for a release version is nice,
> especially a small signature for program description and version
> number output, so anyone debugging your exe will have some info to
> tell you (if needed).

I disagree. That means that dbmon will be cluttered with irrelevant
messages from programs that you're not trying to debug.

Perhaps the best solution if you want to leave in calls to OutputDebugString
is checking IsDe{*filter*}Present() first.

--
.Bruce Dawson, Humongous Entertainment (we're hiring).
http://www.*-*-*.com/
Send job applications by e-mail, post technical questions
to the newsgroups please. Thanks.



Sun, 22 Jun 2003 02:09:49 GMT  
 OutputDebugString vs TRACE??
On Tue, 02 Jan 2001 10:09:49 -0800, Bruce Dawson

Quote:

>The worst case is the sound drivers on my machine which spit out 150
>lines of OutputDebugString text.

!!!  Thats a bit excessive.

Quote:
>I disagree. That means that dbmon will be cluttered with irrelevant
>messages from programs that you're not trying to debug.

I'd not really messed with dbmon and I didn't realise that it caught
ODS()'s to anything.  I thought it wasn't working until I ran a debug
version of my code and there's the output !

Where has all the other debug messages gone (like the LoadLibrary()
notifications, dll relocation  and "First Chance Exceptions" thrown
and caught by the system ?  

Quote:
>Perhaps the best solution if you want to leave in calls to OutputDebugString
>is checking IsDe{*filter*}Present() first.

Are the missing messages handled this way then ?

(now going to browse the source)

Jimbo



Sun, 22 Jun 2003 05:59:05 GMT  
 OutputDebugString vs TRACE??
I'm sure that the LoadLibrary(), DLL relocation and "First Chance
Exception" messages sent by the system are wrapped in some sort
of IsDe{*filter*}Present() check, although some of them may
actually come from the de{*filter*} (First Chance Exception maybe?).

There are a few other places where the OS behaves differently
when debugging. The OS debug memory allocation system, for
instance, is only enabled when inside the de{*filter*}. That's why those
"hardcoded breakpoints" that people complain about only show up
when debugging.

Quote:

> On Tue, 02 Jan 2001 10:09:49 -0800, Bruce Dawson

> ...
> Where has all the other debug messages gone (like the LoadLibrary()
> notifications, dll relocation  and "First Chance Exceptions" thrown
> and caught by the system ?

> >Perhaps the best solution if you want to leave in calls to OutputDebugString
> >is checking IsDe{*filter*}Present() first.

> Are the missing messages handled this way then ?

> (now going to browse the source)

> Jimbo
> --


--
.Bruce Dawson, Humongous Entertainment (we're hiring).
http://www.*-*-*.com/
Send job applications by e-mail, post technical questions
to the newsgroups please. Thanks.


Sun, 22 Jun 2003 08:53:54 GMT  
 
 [ 16 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Deadlocks caused by OutputDebugString / TRACE near thread exit

2. Trace Writing to particular Trace Listeners

3. DBWin32 OutputDebugString & TRACE capture and display utility now free.

4. DBWin32 OutputDebugString & TRACE capture and display utility now free.

5. DBWin32 OutputDebugString & TRACE capture and display utility now free.

6. Is there a utility to view output of OutputDebugString/TRACE w/o loading the debugger?

7. Use of "OutputDebugString" and "TRACE"

8. MASM vs TASM vs VC++ vs DJGPP vs A*^ vs PCC vs DEBUG,, "Hello World!"

9. OutputDebugString is not working in Service under Windows 2003

10. DBWin32 V2.2 Captures OutputDebugString on '95/'98/NT

11. OutputDebugString() Question?

12. OutputDebugString and Terminal Server

 

 
Powered by phpBB® Forum Software