Difference between revisions of "User talk:LoveN"

From ReactOS Wiki
Jump to: navigation, search
(Back from the dark side of the moon: new section)
(Back from the dark side of the moon)
Line 55: Line 55:
 
our own debugger would be a much better option. It's a *lot* of work to make a good
 
our own debugger would be a much better option. It's a *lot* of work to make a good
 
debugger, but if I can't get the situation mended, I might eventually have to.
 
debugger, but if I can't get the situation mended, I might eventually have to.
 +
 +
 +
:Last I heard WinDbg is now functioning quite well. Why would you want the source code to your debugger? --[[User:Lone Rifle|Lone Rifle]] 13:57, 10 November 2009 (UTC)

Revision as of 13:57, 10 November 2009

Welcome!, your skills could be of help here, please visit #reactos to get in touch with the team and have a chat about how to get started, in case you haven't already done so... :) -- gabriel_it

Of course, he meant #reactos on Freenode IRC =) . There's also the ros-dev mailgroup which can be subscribed from here. -- Lone Rifle 09:26, 23 July 2009 (UTC)

Yeah, that's what I meant ;). -- gabriel_it

Thank You. Of course, amigos.. I will show my prompt on #reactos from time to time :)
27 Aug 2009: Last few weeks I was busy building and rebuilding machines for my local net.
Finally, I got me a box fast enough to run VMware without wearing out my razor blades, if you know what I mean ;^)
Now I got to figure out how to set up VMware for kernel debugging of ReactOS. I should be possible to use a named pipe redirection of a COM port in the VM, and a corresponding virtual COM port on the host's end of the pipe. I'll just have to find that last bit. I don't wanna blow a whole lot of effort writing and debugging that part if there already is one. If You have experience of this issue, don't hesitate to post me a hint, amigo..

Hi, I know what you mean ;) welcome back!

These will probably be of use: [[1]] [[2]] [[3]] [[4]]

Good luck! -- gabriel_it 08:52, 27 August

See also ReactOS Remote Debugger --Lone Rifle 09:19, 27 August 2009 (UTC)

Back from the dark side of the moon

Real life sure takes it's toll, but here I am again. I still haven't managed to get a kernel debugger setup the way I want it, but using 'com0com' virtual null modem, a superb piece of software, I wrote me a COM port logger that I use to at least capture debugging output strings.

The ROS Remote Debugger seems to be a nice attempt, but (1) it's written in C# and I don't have a compiler to build it, and (2) the in-official binaries just don't do their job on my box, so it's a no-go.

GDB didn't seem like an option, considering all the warning bells and whistles I saw around the place, and building it proved to be tedious. When I was about to get that finished, my system was hit with tremendous destructive force by some new unknown virus. I'm still picking up the pieces, and now support death penalty to all virus writers! So GDB fell off the deep end too.

Then I considered WinDbg, but saw that it was counter-recommended, and supposedly with spotty support at best, so it too became a no-go. Recently I saw that Timo had rewritten kdcom to improve WinDbg support, but I still haven't had the time to try it out.

During all of this I have seriously considered to write my own debugger, in C/C++, to mend this frustrating situation. While using WinDbg may seem an attractive solution, it has the downside that we don't have it's source code. I think having the source to our own debugger would be a much better option. It's a *lot* of work to make a good debugger, but if I can't get the situation mended, I might eventually have to.


Last I heard WinDbg is now functioning quite well. Why would you want the source code to your debugger? --Lone Rifle 13:57, 10 November 2009 (UTC)