

IMVU’s CallStack API Now Open Source (super useful if you ship software on windows) - eries
http://aegisknight.org/2009/04/imvus-callstack-api-now-open-source/

======
eries
If you haven't seen Chad's excellent series on how to capture all the
different ways a process can terminate on windows, I highly recommend the
previous installments:

[http://aegisknight.org/2009/04/imvu-crash-reporting-
plugging...](http://aegisknight.org/2009/04/imvu-crash-reporting-plugging-the-
vc-runtimes-escape-hatches/)

[http://aegisknight.org/2009/03/crash-reporting-in-imvu-
last-...](http://aegisknight.org/2009/03/crash-reporting-in-imvu-last-chance-
exceptions/)

[http://aegisknight.org/2009/02/reporting-crashes-in-imvu-
c-c...](http://aegisknight.org/2009/02/reporting-crashes-in-imvu-c-call-
stacks/)

[http://aegisknight.org/2009/02/reporting-crashes-in-imvu-
cal...](http://aegisknight.org/2009/02/reporting-crashes-in-imvu-call-stacks-
and-minidumps/)

This is some advanced mojo. I think it's a huge lost opportunity to ship
internet-enabled software but not have it report back on exactly what went
wrong when it crashes.

------
jey
Analogous thing on Linux: [http://tombarta.wordpress.com/2008/08/01/c-stack-
traces-with...](http://tombarta.wordpress.com/2008/08/01/c-stack-traces-with-
gcc/)

But all this is all moot for production code since there's Google Breakpad:
<http://code.google.com/p/google-breakpad/>

------
buggy_code
I don't get it.

Instead of "Let's get C++ easier to debug"

why not:

"Let's only write performance intense parts in C++", and have the rest in an
interpreted scripting language, where things like this (and more) come much
cheaper?

~~~
simonw
They might well be going for "Let's only write performance intense parts in
C++, and make those bits easier to debug"

~~~
chadaustin
Bingo. Most of our application is Python, but all of the 3D stuff is in C++.

