DOS ain't dead

CandyMan 10.02.2023, 10:04	Bug in JEMM (Developers) Post reply
	Here it is: `@DbgOutS <"launching Int 19h",10>,?RBTDBG mov ds:[bptable.pInt06], offset fastboot_1 mov eax,19h call Exec_Int fastboot_1:` It should be like this: `... mov ds:[bptable.pInt19], offset fastboot_1 ...` FASTBOOT did not work because of this.

Japheth

Germany (South),
10.02.2023, 13:10

@ CandyMan

Bug in JEMM

Post reply

> Here it is:
> > @DbgOutS <"launching Int 19h",10>,?RBTDBG > mov ds:[bptable.pInt06], offset fastboot_1 > mov eax,19h > call Exec_Int > fastboot_1: >
> It should be like this:
> > ... > mov ds:[bptable.pInt19], offset fastboot_1 > ...
>
> FASTBOOT did not work because of this.

Nice find - and a very good opportunity to test the PL0 debugger variant Deb386. In theory it should work in those circumstances, but so far I only tested the Jemm initialization with it.

---
MS-DOS forever!

Japheth

Germany (South),
11.02.2023, 03:37

@ Japheth

Bug in JEMM

Post reply

> > Here it is:
> > > > @DbgOutS <"launching Int 19h",10>,?RBTDBG > > mov ds:[bptable.pInt06], offset fastboot_1 > > mov eax,19h > > call Exec_Int > > fastboot_1: > >
> > It should be like this:
> > > > ... > > mov ds:[bptable.pInt19], offset fastboot_1 > > ...
> >
> > FASTBOOT did not work because of this.

How did you come to your conclusion? Does the modification work for you? At first glance the suggestion sounds plausible, but actually isn't correct - the current code does what it is supposed to do. I checked this with the debugger. Changing the value of bptable.pInt19 instead of bptable.pInt06 results in an exception 06 when Ctrl-Alt-Del is pressed ( see the comment in restorevecs; the _first_ bp has to be modified, and the first bp is bptable.pInt06 ).

---
MS-DOS forever!

CandyMan 15.02.2023, 17:38 @ Japheth	Bug in JEMM Post reply
	Japheth, what do you think about JEMM storing and restoring the size of XBDA (first byte) when returning to realmode and FASTBOOT? When I load JEMM, my BIOS uses XBDA to read from disk and clears the first byte of it. This only happens when VDS is enabled because with the NOVDS option this is not the case.

Japheth

Germany (South),
16.02.2023, 05:21

@ CandyMan

Bug in JEMM

Post reply

> Japheth, what do you think about JEMM storing and restoring the size of
> XBDA (first byte) when returning to realmode and FASTBOOT?
> When I load JEMM, my BIOS uses XBDA to read from disk and clears the first
> byte of it. This only happens when VDS is enabled because with the NOVDS
> option this is not the case.

I also have a machine that clears the first byte of the XBDA. Is this a known bug or even documented behavior?

---
MS-DOS forever!

CandyMan 16.02.2023, 12:07 @ Japheth	Bug in JEMM Post reply
	> I also have a machine that clears the first byte of the XBDA. Is this a > known bug or even documented behavior? This seems to be common with newer BIOSes that are not as compatible as they used to be.

CandyMan 23.02.2023, 16:47 @ Japheth	Bug in JEMM Post reply
	HX dos extender (I think HXLDR32.EXE) does not load programs with PE header below address 0x0040 (some compressed exe files). Here sample test file to download: https://megawrzuta.pl/download/16704c1d07e0f88f630585b2e06c0724.html

Japheth

Germany (South),
23.02.2023, 17:30

@ CandyMan

Bug in JEMM

Post reply

> HX dos extender (I think HXLDR32.EXE) does not load programs with PE header
> below address 0x0040 (some compressed exe files).
>
> Here sample test file to download:
> https://megawrzuta.pl/download/16704c1d07e0f88f630585b2e06c0724.html

Yes, I remember some obscure packed binaries that hx's PE loader cannot load. Not worth for further investigation, IMO.

---
MS-DOS forever!

Bug in JEMM (Developers)

Bug in JEMM

Bug in JEMM

Bug in JEMM

Bug in JEMM

Bug in JEMM

Bug in JEMM

Bug in JEMM