Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to index page
Thread view  Board view
DOS386(R)

20.02.2009, 05:53
(edited by Rugxulo, 18.05.2009, 08:53)
 

UI21DEB deBUGGER rele | DGJPP's persistent ENOENT bugginess (Announce)

My new deBUGGER is out :-)

Download: UI21DEB.ZIP (46 KiB)

bugywget_181.png
fat28kil_161.png
gifenont_587.png
mtrronnt_200.png

(snipped "blue TFM" at DOS386's request, see download for documentation)

More information inside the package :-)

Both King Udo and Japheth wrote (2+1/2 years ago, in other forum, when discussing "poor writing performance in DOS" issue) :

> Are you sure that you are not doing something strange ???

Well, damn late :-D , but now this issue as well as similar issues can be clarified instantly using my deBUGGER :clap:

I am aware that I will not make DGJPP adorers too happy with my findings, but that's the deal, the purpose of a deBUGGER is indeed to find BUG's in other applications :crying:

DOS386(R)

20.02.2009, 06:19

@ DOS386
 

UI21DEB deBUGGER rele | DGJPP's persistent ENOENT bugginess

BTW I fixed the horrible "TSR-unable-to-find-out-that-already-installed-BUG" reported by cm in my previous TSR :clap: , but still no uninstall :crying:

Also, some things mentioned in the program / source / manual don't work yet, there are notes about them. It could be made even much better, but waiting with the release until "it can't be made better anymore" would be equivalent "release it never", so it's now out as-is.

Of course I wouldn't oppose the get the 2 filename related bugs fixed in DGJPP :-P , but I'm unable to fix anything there in (since it's C and it doesn't even compile (???) on DOS), and have no access to the devels, so I did what could with "my" compiler. :clap:

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

cm(R)

Homepage E-mail

Düsseldorf, Germany,
20.02.2009, 20:19

@ DOS386
 

UI21DEB deBUGGER rele | DGJPP's persistent ENOENT bugginess

> # OS: My new (not yet released) DOS, RxDOS 7.30, FreeDOS 1.1,
> EDR-DOS 7.01.08 or compatible

Time machines are fun, aren't they? And, just being curious, do you really work on a DOS kernel? Is it based on some known DOS or written from scratch?

> # NTV-DM emulation in DOS (real NT not needed anymore)

Well, some applications might even try to check for NT (and fail miserably when doing so with Int21.3306) because they use NTVDM's BOPs, which I'm sure your little TSR doesn't emulate.

> # Useful for checking application compatibility with both the future
> and the past

If developers ever care they don't need some fancy program for that. But, oh, they don't care anyway.

> # Can disable FAT28 AH=$73 calls, thus temporarily emulate an old DOS
> version
>
> # Can disable the "NTLFN API" AH=$71 calls, (including King Udo's
> "looooooong seek" AX=$7142 call)
>
> # Can disable the "extended open" AH=$6C call (this breaks many things)
>
> # Can disable obsolete FCB calls (except AH=$29)
>
> # Can separately disable the "parse form FCB" AH=$29 call (this breaks
> EDR-DOS)

I looked into the code that disables functions and it seems to work well, setting even the Carry Flag as I'd expect it. (I didn't test the program to ensure it works, but it looks good.) Is there a particular reason you're returning error 02h ("DTA wrap") on some of these FCB calls? I would rather change all these that now return 02h to error 01h, which is either "At end of file" or "Disk full".

> # Can set the famous "NTrue DOS version" to $3205 (this shouldn't be able
> to break anything, however, if anyone bothers to check oneself, tests
> will bring up a massive evidence of the opposite quickly)

Yes, developers tend to think Int21.3306 is a save check for NT. However my programs (such as mah local DEBUG fork) use a better check that won't fail because some SETVER-type program fakes a MS-DOS version of "5.50".

> # Can fix (to some degree) faulty filenames ("multiple-slash-BUG" and
> "multiple-dot-BUG") supplied by many (including, but not necessarily
> limited to) NTVDM-DGJPP application, allowing to run them in DOS

Now that's really useful; I would say some of this should even be done by DOS itself. Most occurances of the "multiple slash" bug as known from MS-DOS (and copied by EDR-DOS for compatibility) can be fixed easily without breaking the (sort of) UNC support MS-DOS had.

> BTW I fixed the horrible
> "TSR-unable-to-find-out-that-already-installed-BUG" reported by cm
> in my previous TSR :clap: , but still no uninstall :crying:

You tried your best and got... hm. "Trash" might describe it well, but a similar method was indeed used by many programmers. Next time think about using some multiplex interface (preferably AMIS) which will find the installed TSR even if another TSR hooked Int21 afterwards.

I would prefer no uninstall even in the next version if it just did the things it does now, but properly. Among the errors, there is also that your Int21 hook is not reentrant. Poping the stack to get to the flags is dangerous; set up a stack frame addressed by bp instead.

---
l

DOS386(R)

24.02.2009, 06:02

@ cm
 

UI21DEB deBUGGER rele | DGJPP's persistent ENOENT bugginess

Laaca wrote:

> Well, I have a old DOS utility XRAY

wow ... why nobody (=you) did point it ever before :confused: ?

> also reports all INT21h calls and maybe also some others.
> I'll compare it with your debugger.

:-)

cm wrote:

> Time machines are fun, aren't they?

YES.

> they use NTVDM's BOPs, which I'm sure your little TSR doesn't emulate.

Probably true, but not a critical problem for me ;-)

> Is there a particular reason you're returning
> error 02h ("DTA wrap") on some of these FCB calls?

RBIL.

> would rather change all these that now return 02h to error 01h,
> which is either "At end of file" or "Disk full".

Maybe good idea.

> that's really useful; I would say some of this should even be done by DOS itself.

Please start bugging King Udo - if you are not yet banned from his forum unlike me :lol:

> You tried your best and got... hm. "Trash" might describe it well

describe what well ? :confused:

> Next time think about using some multiplex interface (preferably AMIS)
> which will find the installed TSR even if another TSR hooked Int21 afterwards.

Maybe good idea. Of course one shouldn't hook INT $21 anymore after UI21DEB is installed, and TFM doesn't point this. Seems you found a minor documentation bug.

> I would prefer no uninstall even in the next version if it just did the
> things it does now, but properly.

:confused:

> Among the errors

What errors ? :confused: You didn't point any except the minor FCB 1 vs 2 thing and the minor TFM thing.

> there is also that your Int21 hook is not reentrant.
> Poping the stack to get to the flags is dangerous
> set up a stack frame addressed by bp instead.

Please supply a test case that breaks it. I don't get the "danger".

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

Laaca(R)

Homepage

Czech republic,
24.02.2009, 10:28

@ DOS386
 

UI21DEB deBUGGER rele | DGJPP's persistent ENOENT bugginess

XRAY:
http://www.laaca.borec.cz/xray.zip

---
DOS-u-akbar!

rr(R)

Homepage E-mail

Berlin, Germany,
24.02.2009, 21:43

@ DOS386
 

UI21DEB deBUGGER rele | DGJPP's persistent ENOENT bugginess

> > Well, I have a old DOS utility XRAY
>
> wow ... why nobody (=you) did point it ever before :confused: ?

You didn't ask! There also are Intercept/Interpret, argus161.zip, kgb104.zip, log21v17.zip, stepdos.zip, and trace27.zip.

DOS386(R)

25.02.2009, 03:06

@ rr
 

UI21DEB deBUGGER rele | DGJPP's persistent ENOENT bugginess

> Well, I have a old DOS utility XRAY
> XRAY: http://www.laaca.borec.cz/xray.zip

COOL. Indeed old, from 1990.

> You didn't ask!

Right :-| just the bugs and mysteries were around and nobody had an idea ...

> There also are
> Intercept/Interpret,
> argus161.zip, kgb104.zip, log21v17.zip, stepdos.zip, and trace27.zip.

Registering INT $21 calls is not unique. At least, UI21DEB:

- is more free
- is more open source
- supports newer calls, also NTLFN strings, and my AX=$7142 support definitely is unique
- filename fixing is probably unique (besides DOSLFN/STARLFN)
- maybe less aggresive than XRAY (no console/file/printer I/O)
- can stat large amount of reads and writes (any other can ?)

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

cm(R)

Homepage E-mail

Düsseldorf, Germany,
25.02.2009, 13:15

@ DOS386
 

UI21DEB deBUGGER rele | DGJPP's persistent ENOENT bugginess

> - can stat large amount of reads and writes (any other can ?)

I used some similar programs and at least one just called the previous Int21 handler to write its stats to a file.

---
l

Japheth(R)

Homepage

Germany (South),
25.02.2009, 14:09

@ DOS386
 

UI21DEB deBUGGER rele | DGJPP's persistent ENOENT bugginess

> > there is also that your Int21 hook is not reentrant.
> > Poping the stack to get to the flags is dangerous
> > set up a stack frame addressed by bp instead.
>
> Please supply a test case that breaks it. I don't get the "danger".

DEBUG (MS-DOS) might be a test case. By default it steps into Int 21h. Optionally, use FD Debug and set "trace mode" to 1 ( -TM 1"); or use GRDB instead. Will your TSR handle allow the debugger to single step into Int 21 without causing a mess?

---
MS-DOS forever!

DOS386(R)

01.03.2009, 08:24

@ Japheth
 

UI21DEB deBUGGER released | the mess

> > supply a test case that breaks it. I don't get the "danger".
> DEBUG (MS-DOS) might be a test

might evaluate into Closed: NOT a BUG also ...

> Optionally, use FD Debug and set "trace mode" to 1 ( -TM 1")

Done !

> your TSR handle allow the debugger to single step into Int 21 without causing a mess

There is no mess at all ... just a tiny problem that the IRET supposed to jump back into the app jumps into garbage instead and I have no idea why :confused:

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

cm(R)

Homepage E-mail

Düsseldorf, Germany,
01.03.2009, 10:40

@ DOS386
 

UI21DEB deBUGGER released | the mess

> > your TSR handle allow the debugger to single step into Int 21 without
> causing a mess
>
> There is no mess at all ... just a tiny problem that the IRET
> supposed to jump back into the app jumps into garbage instead

This is the whole mess.

> and I have no idea why :confused:

Because your hook is inreentrant and JDEBUG ;-) uses Int21 as long as the InDOS flag is not set. The traced Int21 call then probably returns into DEBUG (I think DEBUG last calls Int21.40 [write LF after Int21.0A], or Int21.50 [set PSP to debuggee's if the SDA is not used]). The solution is to set up a reentrant stack frame to get the flags, and set up your own "InUI21DEB" flag. If that is set when entering the handler, completely skip to where you chain to the old handler.

---
l

DOS386(R)

01.03.2009, 13:59

@ cm
 

UI21DEB deBUGGER released | inreentrant mess

Thanks. BTW, since the release up to now I found cca 72'537'637'325'994 bugs in UI21DEB, so NO, it's not (yet) state of the art :crying:

> Because your hook is inreentrant

This would be a criminal BUG because it was supposed to be reentry-safe :crying:

> and JDEBUG ;-) uses Int21 as long as the InDOS flag is not set.
> The traced Int21 call then probably returns into DEBUG

As long as I don't know exactly what magic/mess JDEBUG does on the INT and IRET instructions :confused:

> The solution is to set up a reentrant stack frame to get the flags

maybe true ... still, no idea why this should be better :confused:

> and set up your own "InUI21DEB" flag.

But I already have a reentrancy counter !!!

> If that is set when entering the handler, completely
> skip to where you chain to the old handler.

So skip the "hacks" ... but what does this change ? Or do I have JMP to original INT $21 instead of CALL'ing it to avoid the "mess" on return ?

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

cm(R)

Homepage E-mail

Düsseldorf, Germany,
01.03.2009, 16:19

@ DOS386
 

UI21DEB deBUGGER released | inreentrant mess

> Thanks.

No problem.

> > Because your hook is inreentrant
>
> This would be a criminal BUG because it was supposed to be reentry-safe
> :crying:

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.

> > and JDEBUG ;-) uses Int21 as long as the InDOS flag is not set.
> > The traced Int21 call then probably returns into DEBUG
>
> As long as I don't know exactly what magic/mess DEBUG does on the INT and
> IRET instructions :confused:

It doesn't any. It just calls Int21 between all instructions (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) so 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.

> > The solution is to set up a reentrant stack frame to get the flags
>
> maybe true ... still, no idea why this should be better :confused:

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.

> > and set up your own "InUI21DEB" flag.
>
> But I already have a reentrancy counter !!!

Your reentrancy counter (vvreecnt) would be sufficient if the code really used it (despite the machine halting [?] when it reaches 255). 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).

Of course MS-DOS's usage of InDOS is not sufficient. 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.

> > If that is set when entering the handler, completely
> > skip to where you chain to the old handler.
>
> So skip the "hacks" ... but what does this change ? Or do I have JMP to
> original INT $21 instead of CALL'ing it to avoid the "mess" on return ?

Well, jumping to it is not exactly required (although, at least for Int2F hooks, you should chain by jumping whenever possible) but it is required not to re-use any of your inreentrant data when re-entering. If recording of the called functions, applying filename fixes, etc. (hacks applied by UI21DEB) are all coded reentrant, you can still apply these even when your handler is reentered - just manage to serialize (or ignore/skip unserialized) access to the record buffer and any other inreentrant data you use. (The vvreecnt flag can be considered reentrant if only accessed appropriately.)

Feel free to ask more questions.

---
l

Japheth(R)

Homepage

Germany (South),
02.03.2009, 07:48

@ DOS386
 

UI21DEB deBUGGER released | inreentrant mess

> > Because your hook is inreentrant
>
> This would be a criminal BUG because it was supposed to be reentry-safe
> :crying:

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" :-D

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, but it's probably not worth the effort.

---
MS-DOS forever!

cm(R)

Homepage E-mail

Düsseldorf, Germany,
02.03.2009, 15:28

@ Japheth
 

UI21DEB deBUGGER released | inreentrant mess

> > > Because your hook is inreentrant
> >
> > This would be a criminal BUG because it was supposed to be reentry-safe
> > :crying:
>
> 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" :-D

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(R)

Homepage

Germany (South),
03.03.2009, 07:52

@ cm
 

UI21DEB deBUGGER released | inreentrant mess

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

If a DOS application does a CLI, it can safely assume that no hw interrupts will occur. It doesn't need to care about possible flaws in v86-monitors.

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

I didn't scrutinize the TSRs code, but if all usages of global variables are protected by CLI, then it probably IS reentrant - the "single-step" exception doesn't really count.

---
MS-DOS forever!

DOS386(R)

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

@ Japheth
 

UI21DEB deBUGGER released | crappy and incrappy stuff

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

Japheth(R)

Homepage

Germany (South),
15.03.2009, 08:17

@ DOS386
 

UI21DEB deBUGGER released | crappy and incrappy stuff

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

You. Using the :crying: emoticon means crying, in case you don't know that.


> > "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:

Examples, please! And please don't come with excerpts of my old small-talks with Lutscho. These obviously weren't meant serious and we two had a lot of fun. :-)

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

I have absolutely no clue what you want to hear or read. Please supply more details!

> > but it's probably not worth the effort
>
> I see ...

I doubt that. It's "not worth the effort" because a) it isn't a bug, b) you probably will cause a mess when implementing the feature and c) besides cm and me there's virtually noone who will ever try to single-step this code.

---
MS-DOS forever!

cm(R)

Homepage E-mail

Düsseldorf, Germany,
15.03.2009, 21:02

@ DOS386
 

UI21DEB deBUGGER released | crappy and incrappy stuff

> > "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:

This isn't true, just as it won't be true to say all your posts are crap and some more crying.

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

Do you plan on writing any virus soon? To fear the mass of DOS users or so?

> > It just calls Int21 between all instructions
>
> Excellent (RTFS) :clap:

If you prefer NASM source, mail me.

> > (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.

Well it still is, especially in case of Int21.50 and Int21.51 which are reentrant in M[es]S-DOS. For Int21 character I/O, see below.

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

Well, because apparantly Japheth never used DEBUG's help command '?' when tracing DOS. I'm currently looking for more occurances of Int21 that have to be avoided during InDOS mode. (L's and W's DOS calls are obvious cases here. I'll add "Can't do this while InDOS" messages for these.)

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

I don't know what exactly you mean by "Int21 console". If you mean functions 01h-0Ch, these are redirected through the PHT (RBIL JFT) too as mentioned in RBIL61.

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

What about a 1-bit NUL counter which is never increased? That's probably as useful as your previous solution ;-)

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

Just as interesting as all the other bad crap (there's some good crap too..) Microsoft did. More interesting might be whether (E)DR-DOS and DOS-C duplicate this uncomfortable behaviour.

---
l

Laaca(R)

Homepage

Czech republic,
20.02.2009, 20:21

@ DOS386
 

UI21DEB deBUGGER rele | DGJPP's persistent ENOENT bugginess

Well, I have a old DOS utility XRAY, which also reports all INT21h calls and maybe also some others. I'll compare it with your debugger.

---
DOS-u-akbar!

Back to index page
Thread view  Board view
15108 Postings in 1358 Threads, 245 registered users, 11 users online (1 registered, 10 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum