Getting KCrash & DrKonqi on windows

[George Kiagiadakis]

On Mon, Mar 1, 2010 at 1:00 AM, George Kiagiadakis
<kiagiadakis.george at gmail.com> wrote:
> On Sun, Feb 28, 2010 at 10:00 PM, Patrick Spendrin <ps_ml at gmx.de> wrote:
>> I'd love to see the problems myself, so maybe you can tell us where your
>> code resides, so that more people can take a look at it.
>
>
> I'll try to get the KDE patches into shape as well tomorrow and I'll notify you.

Hi,
I have committed the drkonqi fixes to trunk and everything required in
KCrash except for the actual porting patch which I am attaching here.
It applies on top of latest kdelibs trunk. That means that you can now
try drkonqi if you want, just apply this patch to kdelibs and modify
the CMakeLists.txt of kdebase/runtime so that drkonqi gets built.

I am not yet committing this patch, as I would like someone to review
it first. Plus, there are a few things that need some discussion.

1) Currently I pass the windows exception code as the signal number.
This should not cause any trouble to the default handler or drkonqi
(which needs some extra code though to display a nice string for it),
but I am thinking it might cause trouble to apps that register their
own crash handler (if any). The possibilities would be either to just
document this behavioral change on windows or to translate the codes
to unix signal numbers, which however will lose us some information
since the windows error codes give some more detail about the nature
of the exception. See [1] for a list of them.

2) Currently, if drkonqi is not launched, I let windows do the default
action, which is to quit the app. I am thinking that maybe I should
let it call the default exception filter so that microsoft's error
reporting (or whatever is set in the AeDebug registry key) pops up? (I
haven't really tried to do that, but I guess that's what would happen
if I called the previously set exception filter)

[1]. http://msdn.microsoft.com/en-us/library/aa363082(VS.85).aspx

Regards,
George