Seems that the USEDPMI example provided in the FASM DOS package
mostly crashes inside BOCHS. Never got such a crash on real PC or in QEMU.

Under HDPMI32 there is always PageF, with CWSDPMI: GPF or PageF, EIP 0 ... 5
Seems to occur after the second mode switch. Any ideas what's wrong ?
Is the example faulty or did I find a bug in BOCHS ?

Have to add that the BUG seems to be specific for FASM's USEDPMI, I never
got such a bug with executables from DGJPP (incl. FB (works), ignoring FP (too faulty by itself ) ) or DOS/32A extender.

CWDPMI - is this the Causeway Extender by Micheal Divoure

of so then one can use the environment strings ->

SET CAUSEWAY=SWAP:path --> specify swapfile path

or...

SET CAUSEWAY=NOVM --> disable dos swapfile

thought this may help

SORRY it doesn't



No. Have you a TEXT-only-Browser maybe - don't see the shot ?

Causeway DOS Extender by Michael Devore
CWSDPMI by C.W. Sandman

Anyone tested the USEDPMI inside BOCHS or has an idea ?

In bochs I need to have the causeway extender set to disable pagefile else crash when useing floppy.

sorry about miss-understood

No ideas ?

1) put "magic_break: enabled=1" to your Bochs config file
2) start `bochsdbg.exe'
3) put "xchg bx,bx" to `Usedpmi.asm', assemble
4) start `usedpmi.exe' and step through

Anybody know of an easy way (in assembly) to detect if BOCHS is running?

To bttr : thanks

http://bochs.sourceforge.net/doc/docbook/user/bochsrc.html#AEN1928



Unreproductable: if BOCHS is running or whether running inside BOCHS ?

YES !!! The USEDPMI code - if it crashes, you are inside BOCHS !!!

Could you test it please ?

Other ideas:

CPUID & measure frequency, if high-end CPU with incredibly low performance, you are inside BOCHS

Look into the BIOS

Check the VESA

That request was mainly for Eric Auer (FreeDOS), and he ended up going with VESA 2.0 OEM string (check for "BOCH") for FDAPM, so thanks!

seems to be a bug in Bochs. Apparently it doesn't like EIP to be 00000000 if CS is 32bit. If you place a NOP before "start:", it works.

hint: debugx.com can be used to debug this app in Bochs. It shows that Bochs gets confused when emulating the "mov esi, 00000018" opcode at eip=0.

Thanks. BOCHS is BUGGY and I have the luck to find all those bugs there ...

bochsy - but what can you expect, it's a pretty complicated piece of software. Wonder if QEMU's a lot better in that regard.

> it's a pretty complicated piece of software.

YES.

> Wonder if QEMU's a lot better in that regard.

It does NOT have this bug (and there are at least 2 more bugs BOCHS has/used to have and QEMU doesn't/didn't have) ...

> an easy way (in assembly) to detect if BOCHS

One more:

http://bos.asmhackers.net/forum/viewtopic.php?id=59

No QEMU test
Untested - abuse at your own risk