DOS ain't dead

Hi Japheth,
I guess you know I've been working on a port of PAQ8o8 to DOS. Well, for various reasons, I ended up also making a Win32 port (much easier due to multi-target ability of OpenWatcom). However, back in January of this year, I successfully ran the Win32 version under HXRT in pure DOS (on my P4). Now, however, I've tried it again, and it no longer works. So, I'm guessing that something broke on your end since then. So, whatever previous version worked, but the latest HXRT.ZIP doesn't. Even without custom DOS stub or UPX or .ASM additions (-dNOASM), it still borks (lots of garbage), just by invoking without arguments! (It works fine in real Windows, FYI.)

Test files are here: paq8o8z-jun7.zip (w/ srcs)

> Hi Japheth,
> I guess you know I've been working on a port of PAQ8o8 to DOS. Well,
> for various reasons, I ended up also making a Win32 port (much easier due
> to multi-target ability of OpenWatcom). However, back in January of this
> year, I successfully ran the Win32 version under HXRT in pure DOS (on my
> P4). Now, however, I've tried it again, and it no longer works. So, I'm
> guessing that something broke on your end since then. So, whatever
> previous version worked, but the latest HXRT.ZIP doesn't. Even without
> custom DOS stub or UPX or .ASM additions (-dNOASM), it still borks (lots
> of garbage), just by invoking without arguments! (It works fine in real
> Windows, FYI.)
>
> Test files are here:
> paq8o8z-jun7.zip
> (w/ srcs)

I can confirm this problem. It's related to SEH, the current thread's EFlags register content is destroyed in the exception handler..

[EDIT]: a HXRTD package has been uploaded where this bug is hopefully fixed:

this one

[/EDIT]

---
MS-DOS forever!

>
> [EDIT]: a HXRTD package has been uploaded where this bug is hopefully
> fixed:
>
> this one
>
> [/EDIT]

Seems to work compressing now but hangs upon finishing, at least in DOSBox 0.72. (Also, hangs at help message end, too.) I guess this is due to quit():

// Error handler: print message if any, and exit
void quit(const char* message=0) {
  throw message;
}

EDIT: It works (and quits) fine when run via "dpmild32 paq8o8zw ..." but not when HXLDR32 TSR is loaded. (Strange.)

> EDIT: It works (and quits) fine when run via "dpmild32 paq8o8zw ..." but
> not when HXLDR32 TSR is loaded. (Strange.)

There's a bug in DosBox's emulation of int 21h, ax=4b01h, which makes it incompatible with HxLdr32. I reported it, but since no old game is affected ......

The problem is mentioned in hxldr32.txt

---
MS-DOS forever!

> > EDIT: It works (and quits) fine when run via "dpmild32 paq8o8zw ..." but
> > not when HXLDR32 TSR is loaded. (Strange.)
>
> There's a bug in DosBox's emulation of int 21h, ax=4b01h, which makes it
> incompatible with HxLdr32. I reported it, but since no old game is
> affected ......
>
> The problem is mentioned in hxldr32.txt

Gah, why didn't I just run under QEMU ?! Sorry, my bad. (Note to self: "DOSBox is not a full emulator, it's only for games." Maybe if I wrote a game that needed int 21h,4B01h ?? )

Oh well, you could work around that by not installing if Z:\{rescan, imgmount, mem}.com exists and DOS version reported is 5. Also, at least 0.72 reports "S3 Incorporated. Trio64" for VESA mfgr. string.

(I don't expect you to do that, though. AFAIK, you never fixed the "HXLDR32 loads even if no EMS found, won't work, and won't uninstall" issue.)

> Gah, why didn't I just run under QEMU ?! Sorry, my bad. (Note to self:
> "DOSBox is not a full emulator, it's only for games." Maybe if I wrote a
> game that needed int 21h,4B01h ?? )

Hehe, this is typical. I wrote some suggestion regarded to implementation of CPUID (i don't remember exactly) to Dosbox developers but they was not interested because of games don't need it. Hm but it may be better emulator not just for games...

---
DOS gives me freedom to unlimited HW access.

> > Gah, why didn't I just run under QEMU ?! Sorry, my bad. (Note to self:
> > "DOSBox is not a full emulator, it's only for games." Maybe if I wrote
> a
> > game that needed int 21h,4B01h ?? )
>
> Hehe, this is typical. I wrote some suggestion regarded to implementation
> of CPUID (i don't remember exactly) to Dosbox developers but they was not

It's open source. Make your own advanced version.

> interested because of games don't need it. Hm but it may be better
> emulator not just for games...

I especially like its debugger, because it resembles Soft-ICE.

---
Forum admin

> Hehe, this is typical. I wrote some suggestion regarded to implementation
> of CPUID (i don't remember exactly) to Dosbox developers but they was not
> interested because of games don't need it. Hm but it may be better
> emulator not just for games...

If they're too busy, I understand. I just hope they keep a list of all bugs, "important" or not so that somebody somewhere has the awareness to potentially fix 'em.

P.S. It was you and I who e-mailed each other re: CPUID. Basically, DOSBox won't let you change the CPUID bit in the flags, so you can't detect CPUID is supported (even though it is, in this case: 486 DX2).

> P.S. It was you and I who e-mailed each other re: CPUID. Basically, DOSBox
> won't let you change the CPUID bit in the flags, so you can't detect CPUID
> is supported (even though it is, in this case: 486 DX2).

Oh yes. And it remains the same in last 0.72. I use version from http://ykhwong.x-y.net/cvs/frame.html. But I don't care emulators need some work on new HW. E8xxx has changed multiplier and cache size format in MSR. And I'd like to try change multiplier and vcore on the fly :) BTW intel still didn't revealed reading of Tjmax so DTS temperature measurement is still confusing. There's a lot of winsw (coretemp, speedfan, realtemp, everest) which reports different temperatures, lol :)

---
DOS gives me freedom to unlimited HW access.

> HXRTD package has been uploaded where this bug



> __/__/2008: version 3.3
> _ bugfix: thread idle detection code might have caused a GPF.
> _ bugfix: exception handler destroyed content of application's EFlags

The first update after 2.14

> _ source of v3.2 gave assembly errors, STARTUPINFO changed to STARTUPINFOA.

Related to JWASM ?

I've been quiet about HX recently ... for obvious reasons

Nevertheless, I have a bunch of pending issues to (re)report ... please let me know when you prepare releasing of 2.15 and time is appropriate to report them

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

> > _ source of v3.2 gave assembly errors, STARTUPINFO changed to
> STARTUPINFOA.
>
> Related to JWASM ?

No.

> Nevertheless, I have a bunch of pending issues to (re)report ... please
> let me know when you prepare releasing of 2.15 and time is appropriate to
> report them

I want 2 things to be added for 2.15

1. Making DKRNL32 aware of multi-core cpus and use them - optionally. Rob Bugel has mailed me a quick solution which works with HDPMI, but it is not integrated in DKRNL32 yet.

2. Supply a JWasm/Wlink Makefile for at least HDPMI, DPMILDR and the four basic Win32 emulation dlls (DKRNL32, DADVAPI, DUSER32 and DGDI32). Regretably current Wlink isn't really usable for linking dlls with huge amounts of exports. It might be necessary to make a JWlink...

---
MS-DOS forever!

> 1. Making DKRNL32 aware of multi-core cpus and use them - optionally. Rob
> Bugel has mailed me a quick solution which works with HDPMI, but it is not
> integrated in DKRNL32 yet.

Wow, you mean that multithread win32 app would utilize multicore when running under HX? BTW How will you do controlling of APIC and such HW releated things of multiprocessor systems? Or is is all embedded in DKRNL32.

---
DOS gives me freedom to unlimited HW access.

> Wow, you mean that multithread win32 app would utilize multicore when
> running under HX? BTW How will you do controlling of APIC and such HW
> releated things of multiprocessor systems? Or is is all embedded in
> DKRNL32.

Yes. Of course it will work only if DKRNL32 runs on HDPMI. DKRNL32 will have to boot the APs and switch them to protected-mode. All cpus will run in the very same DPMI client.

---
MS-DOS forever!

> Yes. Of course it will work only if DKRNL32 runs on HDPMI. DKRNL32 will
> have to boot the APs and switch them to protected-mode. All cpus will run
> in the very same DPMI client.

And it doesn't need any .sys drivers from NT? BTW how complicated would be loading of windows .sys drivers e.g. for USB U/OHCI, SATA, VGA... and using treirs functions from own apps? E.g. replacing your VESA driver by vendor specific windows driver and utilize acceleration, higher refresh... Heh but it would tends to making win clone like reactos :)

---
DOS gives me freedom to unlimited HW access.

> > Yes. Of course it will work only if DKRNL32 runs on HDPMI. DKRNL32 will
> > have to boot the APs and switch them to protected-mode. All cpus will
> run
> > in the very same DPMI client.
>
> And it doesn't need any .sys drivers from NT?

What?

> BTW how complicated would be
> loading of windows .sys drivers e.g. for USB U/OHCI, SATA, VGA... and using
> treirs functions from own apps?

Very complicated.

---
MS-DOS forever!

> > BTW how complicated would be
> > loading of windows .sys drivers e.g. for USB U/OHCI, SATA, VGA

> Very complicated.

But maybe this bug would be easy to fix ?

bug

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