> On Apr 4, 2016, at 6:13 PM, Rugxulo <rugx...@gmail.com> wrote:
> 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?

Fairly sure. I noticed that it was the problem under DOSBox. So, I added a 
detector to V8Power Tools and skip it inside DOSBox. After hearing of the issue,
the issue under QEMU sounded exactly the same. So, went straight to the RAM 
creation and skipped it. FDI works fine afterwords. All other external 
utilities that are 
used by FDI are used in may places. So, if one of those was the culprit, it 
exhibit issues elsewhere as well.

HOWEVER, that being said, that does not mean there is a bug in SHSURDRV. 
The problem could be in the kernel, freecom. Or, even possibly in my 
I have not tested had a chance to fully examine the problem. But, so lar it 

> 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?

Don’t know about everyone else. But, I tested it on 2.4.0. 

> 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:

Freedos-user mailing list

Reply via email to