User talk:LoveN

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)

For the same reasons I want the source of the system I run.. Independence!

Picture a void scenario where MS don't exist, only your own source code.. To get your computer to do anything at all, You have to write the program for it (with one bootstrapped C++ comp to go). i.e If you don't have a debugger source to build, you don't have a debugger..

When it comes to <just> capturing kdbg output any serial logging app will do. Hercules or putty are two possibilities for Windows, more examples here. A free of charge C# compiler is available with the Visual Studio C# Express Edition btw (Windows only).--Grschneider 18:24, 10 November 2009 (UTC)

Thanks for the hint on capturing, but I rather like my own logger. I wrote it to suit my style.

As far as C# is concerned, I wouldn't touch it with a ten foot pole. (That goes double for .NET).

I want to be in control of my own programs, which means I always use my own app framework.

It's called Windows Core Lib and is designed to suit _my_ programming style.

I have never released it.. Not sure I ever will (so I can change it without breaking someone's prog).

So... you won't use Java either? --Lone Rifle 09:10, 16 December 2009 (UTC)

I never needed it since I didn't have to make web apps where it would be useful.

I consider Java to be a tool purely for web-based apps that need to run on many platforms.

For local apps that run on a specific platform it is inefficient.. It all wraps around

the underlying OS anyway, so it only slows business down (compared to targeting the OS).

Other than that, I just don't really like the Java syntax ;)

Current work..

Currently I'm writing a SoundFont compatible soft synth for ReactOS. I haven't announced this on the mailing list. That can wait until I feel I have something to announce, but it will take some time.

It is based on FluidSynth, but I'm stripping away everything that isn't needed, and retaining only the sound generator. (Well, it's not really that "only", all things considered.)

The extracted Fluid synth core (nicknamed "Pink Fluid"), which is currently underway, will be given a standard MIDI output device driver front end with SoundFont driver extensions. If necessary, I will add any missing underlying multimedia system functions too, I just hope I won't have to (re)write the PCM audio output device as well.

This work should fit well with the project, since it's announced on the wiki pages that no other developer is currently working on MIDI support.

I _was_ working on augmenting the CodeBlocks backend, but I put that on ice for the moment, since MIDI support seems a lot more important (and a lot more fun for someone like me ;).