Hi, On Mon, Apr 4, 2016 at 12:28 AM, Jerome E. Shidel Jr. <jer...@shidel.net> wrote: > > I have tested under QEMU on Linux and have detected the issue and its cause. > > It appears to be that SHSURDRV is locking up the system in DOSBox and QEMU. > It does not seem to have this issue on the native hardware I’ve tested.
Are you sure? I often use SHSURDRV (386, XMSv3 version) as RAM drive under QEMU with no problems. Of course, my version is reassembled without the (bloated, unused by me) ZLIB/"GZIP" stuff (so it's only like 6 kb now). What QEMU version are you using? I think I'm on 2.5.0 at this point, but newer versions are coming soon. (Yeah, some Linux distros, e.g. Ubuntu LTS, still only have older 2.0.0.) I get mine for Win32/64 (precompiled) from http://qemu.weilnetz.de . > Drawbacks of not having the RAM DISK or RAM DISK creation failure: > > FDI will not be able to import language or target directory settings from a > previous installation. > > FDI will not be able to automatically partition an empty drive in normal mode. > (False back to running fdisk) > > I will look into detecting QEMU tomorrow sometime. I don't know of a really good way to detect QEMU. Sometimes the VESA string tells what emulator, but here it's only saying "VESA 3.0 SeaBIOS VBE(C) 2011". Another way is to check the processor string (e.g. cpulevel.com | find /i "This CPU calls itself"), but that's only available in later cpus, so you can't exactly use "-cpu pentium" (or even pentium2 or pentium3) and expect it to work. But if you omit any cpu restrictions, by default (for me) it now says "QEMU Virtual CPU version 2.5+". Not sure of other ways (though check news://comp.os.msdos.programmer, I think it was discussed there before). I think you can detect things like DOSEMU via BIOS date. EDIT: I'm guessing this is the thread I'm thinking of: "detecting emulation or console windows" (May 31, 2014): https://groups.google.com/forum/#!topic/comp.os.msdos.programmer/l2e4kYnhX-8 > I would hate to have to disable automatic drive partitioning. QEMU seemed a > slow compared to > VMware and native hardware. QEMU is indeed slower than VBox (with VT-X), but KVM (QEMU with VT-X) is pretty speedy too. But I think they still use TCG as quasi-JIT, so it's not as slow as it could be. ------------------------------------------------------------------------------ _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
