Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

UI21DEB deBUGGER released | crappy and incrappy stuff (Announce)

posted by DOS386, 15.03.2009, 02:39
(edited by DOS386 on 15.03.2009, 02:57)

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 ? :confused:

> "Will your TSR allow the debugger to single step into Int 21 without
> causing a mess?" was kind of a trick question.
I see. :surprised: 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 :crying:

> 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" :-D
I see. :-D 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 ? :hungry: 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 :hungry:

> 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 ... :lol3:

> 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) :clap:

> (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 ? :confused: 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 :lol:).

> 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 ***

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
21998 Postings in 2024 Threads, 395 registered users, 127 users online (0 registered, 127 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum