The "go everywhere, do everything" theme of lDebug has gained a new feature: Conditionally Debuggable builds allow to switch between the non-debuggable mode (handlers are hooked when the debugger starts up and unhooked only when it terminates), and the debuggable mode.
In the debuggable mode, the prior debugger's handlers
are preserved in most of the debuggable application.
Only when calling the run function,
the debuggable debugger sets up its own handlers.
That means a great majority of the debuggable's code
can be debugged using another instance of lDebug.
Traditionally, FreeDOS Debug would require a lower-level debugger like one built into a virtual machine to be debugged. In recent years build options were added to never hook interrupts 1 (trace interrupt) and 3 (breakpoint interrupt), allowing to debug most parts. However, these options imply that you cannot actually run a debuggee and have it return control to the instance that is to be debugged.
The Return of the Symbolic Branch!
Recent comments by Bret Johnson caused me to revisit the symbolic branch of lDebug. These were one and two, referencing my earlier reply to this thread on DOS assembly language resources.
In particular, the second message ends in:
I also sometimes use ECM's lDebug, but that is mostly when I'm trying to figure out what someones else's program is doing and don't have the source code or some other way to look at the symbols/names to help try and figure out what's going on. lDebug is much better/easier than D86/D386 for certain kinds of debugging/research.
So, the natural reaction is to consider: what is lDebug not (yet!) better and easier for than the competition? (Mind, I didn't actually ask Bret about this yet.)
‘Move fast and break things’ is a development mantra popularised by Facebook and picked up with enthusiasm by software development teams both small and large. The idea is that if you aren’t breaking things you’re delivering value too slowly.
Why 'Move Fast and Break Things' Doesn’t Work, capacitas Insights (also in the Internet Archive)
mov is of course an 8086 instruction,
and mak is a script name for build scripts that I tend to use, most intricately to build lDebug.
Today a patch I sent to mercurial-devel was allowlisted. It is reproduced here for reference.
rebase: add boolean config item rebase.norebasesource
This allows to use rebase without recording a rebase_source extra field. This is useful for example to build a mirror converted from another SCM (such as svn) by converting only new revisions, and then incrementally add them to the destination by pulling from the newly converted (unrelated) repo and rebasing the new revisions onto the last old already stored changeset. Without this patch the rebased changesets would always receive some rebase_source that would depend on the particular history of the conversion process, instead of only depending on the original source revisions.