DOS ain't dead

lDebug release 8 (Announce)

posted by ecm  , Düsseldorf, Germany, 10.03.2024, 15:02

> > Here's another release of lDebug (with a small L).
>
> Very nice!
>
> If you always have to explain the "little l", you should perhaps rename the
> debugger It might become tedious.

Nevah!

> > Another set of bugs fixed involves the drive locking needed to write
> sectors to
> > a drive on MS-DOS v7 and v8. The first bugfix is
>
> I also once "played" with the "drive locking" thing when modifying WDe, but
> my impression is, it's a big sh*t - don't want to mess with that again.

I traced through the (DOS) kernel code that handles the lock and unlock. Neither of the "query lock" functions documented in the Interrupt List is implemented in the DOS kernel so the only way to get the current lock status is to peek into the kernel's internal structures for the lock flags.

> -------
>
> I tried ldebugx with a current test case ( LFN support of Open Watcom v2.0
> ). It stops at the breakpoint in protected-mode, but at the end, when the
> program already has "finished", it gives a GPF ( presumably in the debugger
> itself ).
>
> Here's the test case if you want to take a look yourself:
> https://github.com/Baron-von-Riedesel/Testcases/tree/main -
> It's the hello.zip file, the binary is hello.exe.

Thanks for the report! Should be fixed now: https://hg.pushbx.org/ecm/ldebug/rev/5f4daee63025

The problem was that my function entry_to_code_sel assumed a 16-bit stack. This function is part of the data code split (mentioned on the blog) which made it so the entry segment is not equal to the code segment, so they need to be addressed with different selectors as well. I fixed this by first switching stacks before using the function.

Writing of which, I checked all uses of this function. I think the only case that may still have a 32-bit stack is in the exception handlers: https://hg.pushbx.org/ecm/ldebug/file/92ea23f12b9d/source/pmentry.asm#l213

Can a DPMI exception handler be called with a 32-bit stack? Seems like it is possible, but for dosemu2 and HDPMI it seems like the stack is either 16-bit or ESPH is zero, as a build with _PM_ENTRY_SECTION=0 works as expected.

---
l

Complete thread:

• lDebug release 8 - ecm, 08.03.2024, 19:29 (Announce)
  • lDebug release 8 - Japheth, 10.03.2024, 10:40
    • lDebug release 8 - roytam, 10.03.2024, 11:53
    • lDebug release 8 - ecm, 10.03.2024, 15:02
      • lDebug release 8 - ecm, 10.03.2024, 15:25
        • lDebug release 8 - Japheth, 11.03.2024, 10:47
    • lDebug release 8 - ecm, 11.03.2024, 09:30