I don't know about you, but it seems whenever I write a program I end up with bugs that I need to track down and stomp. Sometimes a debugger (I use OllyDbg) works, but other times not even a real debugger will help much.
Over the years I've come up with several debugging aids of my own; this latest one is really simple, yet quite effective at finding out what's going on inside your code. It's a window in the program (assuming your program is a GUI app, not a console app) that can display text to clue you in. Here's my recipe:
1. Create an edit window in your program's main window or dialog. Make it big enough to show the text you'll be displaying; multi-line assumed here. Make it read-only (no need to have it accept typed-in input). Make the control multi-line with a vertical scrollbar:
window style = WS_CHILD or WS_VISIBLE or ES_MULTILINE or ES_READONLY or WS_VSCROLL
Store the edit control handle in a global variable to make it easily accessible.
2. Create a function in your code to display text in the window. Here's mine:
;====================================
; LogResults()
;
; Appends text to an edit control.
; Handle to window is ResultsDispHandle.
;
; On entry,
; EAX--> text to add
;====================================
LogResults PROC
LOCAL textPtr:DWORD
MOV textPtr, EAX
; Set selection to the very end, add the text + CR/LF:
INVOKE SendMessage, ResultsDispHandle, EM_SETSEL, -1, -1
INVOKE SendMessage, ResultsDispHandle, EM_REPLACESEL, FALSE, textPtr
INVOKE SendMessage, ResultsDispHandle, EM_REPLACESEL, FALSE, OFFSET CRLFstr
; Make edit control scroll to the very end:
INVOKE SendMessage, ResultsDispHandle, WM_VSCROLL, SB_BOTTOM, 0
RET
LogResults ENDP
To display text, set EAX to point to the text buffer, then call LogResults(). The function adds the text to the edit buffer, then scrolls to the end. You can scroll back through the text to see earlier output. I automatically add a carriage return/line feed for each item displayed so I don't have to add that to each display string.
Simple but effective.
Hints: for more bulletproof debugging, use PUSHA/POPA in any logging functions to preserve all registers. You can write specialized functions, or if you want to display one or a few variables, use something like this:
LOCAL buffer[256]:BYTE
INVOKE wsprintf, ADDR buffer, OFFSET <format string>, <variable(s) to log>
LEA EAX, buffer
CALL LogResults
Can you post a working, complete example? Thanks.
Sure, give me a day or two.
Hi NoCforMe!
Quote from: NoCforMe on September 21, 2023, 10:24:44 AMI've come up with several debugging aids of my own;
In Masm32 SDK package you have VKim debug system.
What problem you see in VKdebug?
HSE
Never used it. I'll have to take a look at it.
I'm guessing it's more than I need at this level; what I described here is a pretty low-level debugging aid. Doesn't show anything about processor state, memory, code, etc.
OK, I took a look at it. I'm sure it's a useful tool, but two things: first, it's not as easy to use as my method described here. With my debugging window, there's no installation required, just create the window (edit control) and send stuff to it. With VKDebug you have to install the package, learn how to use the various functions and macros, etc. Plus it uses the registry (ugh!).
Second thing is that I've already created a similar tool, called LogBuddy, which I've posted here previously. Don't know if mine measures up to the VK tool, but it works well. However, it's more complex and requires some "installation" (it uses a DLL).
Different levels of debugging for different needs.
Quote from: NoCforMe on September 22, 2023, 05:45:56 AMI'm guessing it's more than I need at this level
Who care? You can use what you need. :thumbsup:
"Who care"? I care. I don't want to use a sledgehammer to kill a mosquito.
Quote from: NoCforMe on September 22, 2023, 05:45:56 AMWith VKDebug you have to install the package, learn how to use the various functions and macros, etc.
Of course, you think is more easy to reinvent the wheel :biggrin:
Must be clear for beginners that to use any tool requiere some learning, VKdebug is very easy and you have to install it just once.
You can do what you want, NoCforMe. :thumbsup:
But nobody need to travel your personal calvary. :biggrin:
Quote from: HSE on September 22, 2023, 06:22:49 AMQuote from: NoCforMe on September 22, 2023, 05:45:56 AMWith VKDebug you have to install the package, learn how to use the various functions and macros, etc.
Of course, you think is more easy to reinvent the wheel :biggrin:
I checked my folders, and voilà, there it is: \Masm32\vkdebug\ - installed 30.10.2014. That's probably the day when I spontaneously decided to reinvent the wheel (http://www.jj2007.eu/MasmBasicQuickReference.htm#Mb1019) :biggrin:
Anyway, I am curious to see a working example from NoCforMe :thumbsup:
Quote from: jj2007 on September 22, 2023, 06:38:13 AMthere it is: \Masm32\vkdebug\ - installed 30.10.2014.
Perhaps that was a reinstallation. :thumbsup:
VKdebug is in Masm32 SDK at least from 2008. I think a lot before, but I'm not sure.
The readme.txt is dated 16.9.2002, so it's over 21 years old. For its time, it was probably a good tool, but there was a reason why I rolled my own: it's clumsy.
Quote from: jj2007 on September 22, 2023, 07:35:59 AMThe readme.txt is dated 16.9.2002, so it's over 21 years old.
Yes, but I don't know when was added to package.
Quote from: jj2007 on September 22, 2023, 07:35:59 AMbut there was a reason why I rolled my own: it's clumsy.
I also adapted a little to my taste, just that was superseded by ObjAsm32 Debug System :biggrin:
Quote from: jj2007 on September 22, 2023, 07:35:59 AM[...] but there was a reason why I rolled my own: it's clumsy.
Exactly. It always strikes me funny when people say "so why don't you just use (x) instead of reinventing the wheel?". Take my LogBuddy; don't know if you've tried it or not, but I think it's a pretty good debugging tool. Can show all or some of the messages a window receives, display variables, dump memory, etc. However, it takes a lot of setup to use: you have to put in a code stub at the end of your program code, initialize it, do some other stuff. Which is sometimes a pain in the ass. Hence this simple alternative to do
minimal debugging. Takes a small amount of effort to put it in your code (the worst part is figuring out where to place a fairly sizeable edit control in your main window or dialog).
You asked and I agreed, so I will post a working example. I'm working on other things at the moment, though, so it'll be a little while.
NoCforMe, walking your own path, even if reinventing the wheel,is have fun while getting more skilled in new things :thumbsup:
DebugView / DbgWin.exe exists and usable with OutputDebugString
https://learn.microsoft.com/en-us/sysinternals/downloads/debugview
Hey, I don't mind thread drift; long live thread drift!
But I do mind people missing the point. By a mile.
Let me try an electronics analogy here: what I'm describing here is like hooking up a LED to a certain signal line to see if it goes high or low.
Everyone else here is telling me I should haul out the logic analyzer, hook up dozens of probes, program the damn thing, then go through the output.
Simplicity is the keyword here ...
Two lines:
WndProc proc uses esi edi ebx hWnd, uMsg, wParam:WPARAM, lParam:LPARAM
inc msgCount
deb 4, "msg", chg:msgCount
SWITCH uMsg
(http://www.jj2007.eu/pics/DbgTwoLines.png)
OK, OK; another flashing neon billboard for MasmBasic.
Which is not to say that I don't recognize the power and utility of your creation: I do. And its debugging capabilities are, I'm sure, very effective and easy to use.
I guess I'm writing for those of use here who are, for whatever reason, not users of MasmBasic, and who must "roll their own".
Quote from: NoCforMe on September 23, 2023, 05:41:03 AMOK, OK; another flashing neon billboard for MasmBasic.
Take it as pseudocode. I hope it serves as inspiration when you "roll your own". Maybe you can make it even simpler?