DOS ain't dead

FD Debug needed an update:

http://www.japheth.de/debxxf.html

there was a bug in v1.04-1.14 which has been fixed.

btw, GRDB also has got an update very recently! See LADSoft site!

---
MS-DOS forever!

> FD Debug needed an update:
>
> http://www.japheth.de/debxxf.html

Are you the official maintainer ? There's a small annoyment in this and one (or a few more?) previous versions of the (free) debug : after breaking on int3 (one present in the debuggee, not one inserted by debug for processing BP) we want the "g" command (no parameters) to restart at the next instruction after the int3.

It maybe a matter of preference, but having used debug - or sid, its DRDOS counterpart - almost every single day for over 20 years I think I know what's convenient to a user and what's not.

When stopping on "unexpected" int3 please increment user ip before displaying instruction & registers. Whether you do this though, or prefer to display at the position of the int 3, absolutely please ensure that a "g" command without an explicit restart address continues execution after the int 3 !

---
Ninho

> FD Debug needed an update:
>
> http://www.japheth.de/debxxf.html
>
> there was a bug in v1.04-1.14 which has been fixed.

Thanks for the update

> Are you the official maintainer ? There's a small annoyment in this and
> one (or a few more?) previous versions of the (free) debug : after
> breaking on int3 (one present in the debuggee, not one inserted by debug
> for processing BP) we want the "g" command (no parameters) to restart at
> the next instruction after the int3.

Yes, this is a bug in v1.14-1.15.

---
MS-DOS forever!

> http://www.japheth.de/debxxf.html

Hey Japheth, the link to the DEBUG tutorial is broken. I think it should be this...

http://www.japheth.de/Debug/Debug.txt

... instead of ...
http://www.japheth.de/Debug\Debug.txt

> Hey Japheth, the link to the DEBUG tutorial is broken. I think it should
> be this...
>
> http://www.japheth.de/Debug/Debug.txt
>
> ... instead of ...
> http://www.japheth.de/Debug\Debug.txt

Fixed! There's now also a v1.16 which fixes the other bug mentioned recently (and some more).

---
MS-DOS forever!

> Fixed! There's now also a v1.16 which fixes the other bug mentioned
> recently (and some more).

Thanks; still buggy though :=(

> m 1000 1007, 1010

... doesn't work (with or without commas, which BTW should always be optional, since nobody can remember where they are/aren't needed). It does not emit an error, but the move is not effected (or maybe /some/ undesired move is ?)

> m 1000L8 1010

works as awaited.

Regards...

---
Ninho

> Thanks; still buggy though :=(
>
> > m 1000 1007, 1010
>
> ... doesn't work (with or without commas, which BTW should always be
> optional, since nobody can remember where they are/aren't needed). It does
> not emit an error, but the move is not effected (or maybe /some/ undesired
> move is ?)

I'm unable to see the problem. Probably if you can post a more detailed error description a bug fix may be possible for v1.17 (which will come out soon because v1.16 contains a small regression which is to be fixed with v1.17).

---
MS-DOS forever!

> I'm unable to see the problem. Probably if you can post a more detailed
> error description a bug fix may be possible for v1.17 (which will come out
> soon because v1.16 contains a small regression which is to be fixed with
> v1.17).

It's a very strange bug indeed, sometimes the move works and immediately afterwards a similar move doesn't. I don't have the time to dig now, honest - I just did this :

m 1000 1007 1010 (it worked)
m 1000 1007, 1020 (didn't work)
m 1000 1007, 1020 (again, didn't work)
m 1000 1007 1020 (no comma. worked!)

Don't focus on the comma, it may or may not be related to this bug. Sorry I must leave you now

---
Ninho

> I'm unable to see the problem. Probably if you can post a more detailed
> error description a bug fix may be possible for v1.17 (which will come out
> soon because v1.16 contains a small regression which is to be fixed with
> v1.17).

Have you been able to locate the problem ? A little more exercising the interface, while not extensively, makes it look like I've been hitting a bug in the command parser - probably not limited to the "move" command : the bug seems to happen only when the command letter ("m" in this case) is immediately followed by the argument without intervening "blank". Then the move is (sometimes?) not effected and yet no error signaled! Either flag the absence of a blank after a command "verb" as an error - but it is valid syntax in both MSDOS debug/DRDOS sid - or ensure that the arguments are still parsed properly.

Regards

---
Ninho

> the bug seems to happen only when the command letter ("m" in this case) is
> immediately followed by the argument without intervening "blank".

Yes, a blank is needed to avoid ambiguity. Some commands consist of 2 letters, and if the second letter can be interpreted as a hex number, the parser has a tiny problem. This affects:

M - MC
I - ID
O - OD

There are no plans to change this.

---
MS-DOS forever!

> Yes, a blank is needed to avoid ambiguity.
> M - MC
> I - ID
> O - OD

Ack.,

> There are no plans to change this.

But this is /bad/ if no feedback/warning/error is given on bad/ambiguous commands ! Furthermore, a command such as : m1000L8 1010 is nowhere ambiguous, yet it (seems to be) silently ignored by Fdebug !

IOW, the bug is not that a space is required after the "m" command (etc.), it is your choice, but the bug is that you do not emit an error message when the blank is missing. That needs repair IMHO ;=)

---
Ninho

> But this is /bad/ if no feedback/warning/error is given on bad/ambiguous
> commands ! Furthermore, a command such as : m1000L8 1010 is nowhere
> ambiguous, yet it (seems to be) silently ignored by Fdebug !
>
> IOW, the bug is not that a space is required after the "m" command (etc.),
> it is your choice, but the bug is that you do not emit an error message
> when the blank is missing. That needs repair IMHO ;=)

Ok, now there's an error msg in such cases.
v1.17 also fixes a regression in v1.16's R command.

---
MS-DOS forever!

>> you do not emit an error message
>> when the blank is missing. That needs repair IMHO ;=)
>
> Ok, now there's an error msg in such cases.

Sweet !

-m1000 1007 1010
          ^ Error

I'd prefer the caret to appear under the first "1" rather than the blank after "1000", but admittedly it is now little more than a cosmetic fix.

> v1.17 also fixes a regression in v1.16's R command.

Regards...

---
Ninho

http://www.japheth.de/debxxf.html

---
MS-DOS forever!

Thanks!

Here's a suggestion for enhancement - which you may like or not : add accelerated trace, from branch to branch instruction, using the DebugMSR [if present; else emulate the feature by doing an ordinary x86 trace but display only branch instructions to the user]

Regards,

---
Ninho