LogBuddy debugging aid, improved

[jj2007]

Is really necessary to call the functions of the dll using GetProcAdress ?

Dll & Declare:

Code Select Expand

    Dll "msvcrt"                   ; good ol' CRT
    Declare double sin, C:1        ; the crt sinus function returns a REAL8 in ST(0)
    Print Str$("Sinus(3)= %Jf from CRT\n", sin(3.0)) 
See also Dynamic vs static linking in the Lab; besides, the Dual 64- and 32-bit Assembly doesn't use *.lib files except for a small stub - it's all GetProcAddress under the hood.

[TimoVJL]

Is really necessary to call the functions of the dll using GetProcAdress ?

If you don't use import library, it is easiest way to get function address.
Of course there are other ways, but not to show in this forum, as rules are rules.

[NoCforMe]

So @Guga, to answer another question of yours: no, no plans here to make this into a full-scale debugger. I'll leave that to the likes of OllyDbg.

BTW, if you want to do anything with my code, I'd be happy to provide all the source; you could do what you like with it.

I think I figured out how to watch variables. Will post if and when I have it working. That's probably about as far as I want to take this project.

[guga]

Tks NoCForme.

If you could provide the source, it would be appreciated it.      I would like to read how you managed the equates. For what i saw so far you used equates like WM_UAHNCPAINTMENUPOPUP. These i didn't knew about them. It could be good to update RosAsm equates set as well :)

[NoCforMe]

Here's everything you need to make the DLL, I think. (If anything's missing, let me know.)

Please ignore all the "watch" stuff; I've been working on putting that feature in. It assembles and links OK; the watch stuff is still inactive.

Any questions, let me know.

[guga]

Tks a lot, NoCforMe 

[NoCforMe]

We now have variable watching. I'm very pleased to present this version.
Try the attached program, StrucTest.exe. (Be sure to have LogBuddy.dll in the same folder.) Go to the "Generic Dialog" window; type a number into the (unlabeled) edit control, then click "A Button" and look at the first variable in the watch window.

Here's how that works:

• The debuggee (StructText.exe) requests that a variable be watched, using the @LogBuddyWatchVar macro:

Code Select Expand

@LogBuddyWatchVar TestVar, "TestVar", $watch_UD_dword

• This does two things: creates a new element in the WATCH structure, and creates a new item in the Watch listbox.
• To enable watching, the Watch window proc starts a timer. The WM_TIMER handler goes through the WATCH array and process each element:
  The current value of the variable is read, using its pointer stored in the array;
  The value is formatted into text, using the variable type/size ($watch_UD_dword in the example above, which is an unsigned decimal DWORD);
  The formatted text is stored in the buffer pointed to by the array;
  The listbox item for that variable is updated with the new buffer text.
• That last action--updating the listbox--causes a WM_DRAWITEM message to be sent to the parent window proc. In that handler, the new value of the variable is displayed.

You cannot view this attachment.

The reason I'm using an owner-draw listbox (hence the WM_DRAWITEM messages) is because I've split each listbox item in two, the first half for the variable name, the second for its value. I wouldn't be able to show each item this way if I didn't do the drawing myself (using DrawText()).

It seems to work quite well. The timer interval is set to 2000 mSec. There's a Settings dialog you can use to play around with the time to see how that works.
Thinking about this, I've come to see that one of the biggest weaknesses of this app is the fact that it runs as part of the debuggee's process, which means that if the debuggee crashes, LogBuddy crashes.

If someone wanted to develop this further, it'd probably be a good idea to at least look into running the logger in a separate process. This would eliminate that problem, and might also improve performance. However, it would introduce a new problem, one I don't know how to deal with, which is memory access between processes. I don't know how the logger would be able to access the debuggee's memory. I don't think you'd want to use shared memory here.

If anyone has any light to throw on that subject, it'd be appreciated.

Anyhow, as always, lemme know whatcha think.

[guga]

Great job. Working as expected.     

[NoCforMe]

It looks like the starting point for sharing memory between processes is CreateFileMapping(), with a hFile value of INVALID_HANDLE_VALUE.

[guga]

Do you want me to send the full rosasm section related to the debugger ? If you could read the syntax and understand the logic, perhaps it may help.

[NoCforMe]

Do you want me to send the full rosasm section related to the debugger ? If you could read the syntax and understand the logic, perhaps it may help.

Um, can you just briefly describe it here first? Let us know what it does, how it works?