DOS ain't dead

> A nice feature would be if lDebug were capable of loading code over a
> serial line. Then one could code on PC A and debug it on PC B. Would be
> especially useful for bootloader development.

You can actually use its serial I/O support to control the debugger across a serial port. However to load a program you'd currently have to enter the program as data using F, E, or R commands. Or have a script do that for you on the terminal side. The debugger doesn't implement anything like X/Y/ZModem as yet.

---
l

> > I wrote an article over on my tech blog, comparing the recent FreeDOS
> > Debug's DebugB for boot mode operation to the capabilities of my
> debugger
> > when boot loaded.
>
> Cool!
>
> However, don't you agree that your eagerness to compare YOUR debugger with
> Debug/X's DebugB variant - which is WIP - is a bit exaggerated?

It passes the time. And I want to advertise my software, obviously. I may report on your progress if you do continue to work on Debug/X's boot mode support.

> About the name: that "FreeDOS" prefix is an invention of yours. I admit the
> github name "DOS-debug" is rather dull ( I would prefer "Debug/X" as name,
> but I'm unsure if that would be accepted ). In any case, FreeDOS isn't even
> mentioned in the Debug/X documents - and the DebugB variant is totally
> unknown to FreeDOS, so to say.

Well, historically some earlier versions did identify themselves as "FreeDOS Debug", though indeed recent ones are called "DOS Debug". However, as recently as August you yourself referred to "FreeDOS DEBUG.COM", which I believe was referring to recent DOS Debug/X, in https://github.com/86Box/86Box/issues/2551 Quoting:

> This trick is used in FreeDOS DEBUG.COM ( I'm the maintainer of this little program ) in the line assembler part to optimize size.
>
> As it has turned out in my tests, 86Box ( v3.7) does ignore the second byte of the AAM instruction and always fills AX with "decimal" digits. Hence FreeDOS debug.com's line assembler is unusable in 86Box.

Continuing your post:

> About DebugB: there's no intention on my side to make the installation too
> smooth. I can confirm that DebugB works. After all, the handful of people
> that might be interested in this tool ( I mean, REALLY interested, not
> counting the ones who are just bored and are looking for a new toy to play
> with ) will surely find out how to handle it, based on the documentation
> that is actually provided.

"It's not a bug, it's a feature" =)

(I do believe that it works generally, all the reviewing of the code I did does make it look fine -- except for minor problems like relocating once at the end of init without checking for overlap.)

> DebugB might just be an intermediate step to a little ring0-debugger, being
> able to intrude into Jemm's context - or, more advanced, intruding into
> VCPI clients like HDPMI - without having to adjust Jemm/HDPMI.

I'll eagerly await any such developments, though I think ring0 PM support is probably beyond the scope of lDebug so I may not fork those features if it comes to that.

---
l

> DebugB might just be an intermediate step to a little ring0-debugger, being
> able to intrude into Jemm's context

That variant does now exist, it's on github:

https://github.com/Baron-von-Riedesel/Jemm
https://github.com/Baron-von-Riedesel/DOS-debug

it needs Jemm v5.83 to work. No binaries supplied yet.

---
MS-DOS forever!