DOS ain't dead

> > > Because your hook is inreentrant
> >
> > This would be a criminal BUG because it was supposed to be reentry-safe
> >
>
> Please calm down! "Will your TSR allow the debugger to single step into
> Int 21 without causing a mess?" was kind of a trick question. Correct
> answer is "No", but it's half of the truth only, the fully correct answer
> is "No, and I don't care at all, because it's your crappy debugger which
> is faulty"

I rather expected this because of the question, but don't approve your intention. Well, yes, I probably won't ever use some program by DOS386, but I still prefer acceptable useless programs over crappy ones

> The reason is simple: your code clears IF, which is a hint for any
> debugger that a critical section is entered which isn't allowed to be
> interrupted. The problem is that all DEBUGs ignore this signal - they
> aren't designed to debug "low-level" code.

IF is often meaningless if any form of multitasking is running.

> You can make your code more tolerant by implementing Christian's
> stack frame solution, but it's probably not worth the effort.

The problem here is that even "normal" TSRs (not DEBUG) might want to use DOS functions reentrant in MS-DOS. Even the Int24 handler of COMMAND.COM might crash UI21DEB, because it (is allowed to and) calls some low functions (01h-0Ch) during another Int21 call.

---
l

Japheth wrote:

> > This would be a criminal BUG because it was supposed to be reentry-safe
> Please calm down!

But ... who exactly is supposed calm down here ?

> "Will your TSR allow the debugger to single step into Int 21 without
> causing a mess?" was kind of a trick question.

I see. The optimal case of a post of yours is a tricky question, the other, also pretty frequent case, are just rude attacks without any relation to original topic

> Correct answer is "No"

Indeed.

> but it's half of the truth only, the fully correct answer is
> "No, and I don't care at all, because it's your crappy debugger which is faulty"

I see. Just to be prepared to the very worst case that my deBUGGER will never get fixed, can you suggest some replacement ? Some piece of software that isn't crappy ? Maybe UPX ? DGJPP ? Quak-Baysic ? EDR-DOS ? s'ASS'er virus ?

> The reason is simple: your code clears IF, which is a hint for any
> debugger that a critical section is entered which isn't allowed to be
> interrupted. The problem is that all DEBUGs ignore this signal - they
> aren't designed to debug "low-level" code.
> You can make your code more tolerant by implementing cm's stack
> frame solution

I'll fix the BUG's

> but it's probably not worth the effort

I see ...

Cm wrote:

> I probably won't ever use some program by DOS386
> but I still prefer acceptable useless programs over crappy ones

Interesting point. The fear or virii pushes people into the irrationality, when the irrationality is exhausted they move on into the absurdity, and when the absurdity is exhausted then ...

> So you see, it isn't. It might be if the code is not traced (so that disabling
> the Interrupt Flag disables executation of other code because DOS is
> [supposed to be] single-tasking) but else it doesn't.

I see.

> It just calls Int21 between all instructions

Excellent (RTFS)

> (you could avoid this by setting my own DEBUG fork's [NDebug's]
> "assume InDOS" mode, but it's DEBUG's right to do that anyway)

I'm not that sure about that. In JDEBUG source I see 3 branches:

* INT $21 console
* BIOS console
* INT $21 redirected

And I'm very skeptical about both the INT $21 console: dropped in favor of BIOS if debugging DOS kernel ... but why not always ? and the INT $21 redirect ... seems obsolete, no need to abuse DEBUG as an assembler anymore (maybe things were very different 20 years ago, heh ).

> in the beginning of your handler, all used variables like vvstack, vvbckflor and
> vvbckflid get overwritten with the values DEBUG's Int21 call leaves there.



> By setting up a stack frame instead of using the same variables again, each
> re-entry gets its own private variables (which costs some stack space, but
> DOS itself uses ~30 bytes user stack anyway) so you can safely re-enter
> this initial, critical code.

Nice.

> Your reentrancy counter (vvreecnt) would be sufficient if the code really used
> it (despite the machine halting [?] when it reaches 255).

Any better ideas ? Set up a 256-bit counter providing a "sufficiently low" probability of overflow before the universe implodes ?

> At one point, the counter is set to zero which is probably no good idea (I didn't
> do much research on that one). The code you're using to decrement the counter
> is fancy, but I would at least flag an error somehow (which could then be shown
> when running UI21DEB.COM the next time) if the counter was already zero
> because that should never happen. The really bad thing about it is that you
> don't do anything if the counter was not zero when executing the handler:
> you're re-using the same inreentrant data the previous Int21 call did use
> (f.e. vvbckax and the other register storage variables), overwriting the
> previous content. Generally speaking, you don't have to eliminate all
> inreentrant data and replace it by stack frame variables as long as you only
> use it one time. You've to skip all usage of inreentrant data when the handler
> is re-entered (for whatever reason).

I see the problem.

> Of course MS-DOS's usage of InDOS is not sufficient.

Interesting.

> Re-entering MS-DOS's Int21 handler during certain time frames will crash the
> machine without any error message. Microsoft assumes other Int21
> users/handlers to take care of not re-entering its handler by not using (most)
> Int21 functions when InDOS is non-zero.

COOL.

> Feel free to ask more questions.

Now I have plans for next version fixes and started rewriting it

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***