Technically the debugger is based on a prototype by ominc, which has been ported to BB1.7 by oberoncore+x512+Ivan.
I have tested the prototype but was not very happy with the user interface. The main problem was that it required to start the
debugger first and attach the debugged BlackBox process to it later. In my opinion, the reverse approach would be more natural,
i.e. while working in BlackBox it should be possible to attach a debugger to it and to debug a command very much like
executing a command directly. A first version of this 'reversed' approach is now available.
The main differences over the ominc prototype are:
- improved user interface: debugger is attached to running BB, no flickering when single-stepping, tool dialog, etc.
- internationalized
- relevant DevDebug changes since BB1.6 applied to RTDebug.
A test version is available from http://blackboxframework.org/unstable/i ... 1.1023.zip.
If you want to debug a command M.P then select M.P in a text viewer and execute Dev->Debug Command.
If you want to open a module M in the debugger (e.g. for setting breakpoints) then select M in a text viewer and execute Dev->Debug Module.
Docu is included.
The debugger is a normal BlackBox process which simply uses the startup option /LOAD DevRTDebug.
DevRTDebug is a new module that uses the Windows debug API for attaching a debugger to a running process.
DevRTDebug is only loaded in the debugger process. Normal BlackBox execution does not load this module and is not affected.
There is only a small interface added in DevDebug for attaching (starting) a run-time debugger to the running BlackBox.
A couple of missing Windows debug API functions have been added to WinApi.
A nice side-effect of the reversed approach, and may be an indication that it is the right approach, is the fact
that the Kernel support for starting under the prototype run-time debugger with the magic lines
Code: Select all
S.PUTREG(ML, S.ADR(modList));
WinApi.OutputDebugStringW("BlackBox started");
The changes are https://redmine.blackboxframework.org/p ... a4d9f1453b.
Note: This also fixes an error in DevDebug.ShowArray, where the type of the variable vi has been changed from SHORTINT to INTEGER in issue-#19.
This variable is used for reading 2-byte characters and must be reset to SHORTINT.
I would be glad to get feed-back on this version of debugger.
- Josef