Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!munnari.oz.au!uhccux!uhunix1.uhcc.Hawaii.Edu!pilger
From: pilger@uhunix1.uhcc.Hawaii.Edu (Eric Pilger)
Newsgroups: comp.sys.ibm.pc.misc
Subject: Re: qemm-386/386maxx experience sought
Message-ID: <9315@uhccux.uhcc.Hawaii.Edu>
Date: 11 Sep 90 16:00:02 GMT
References: <83514@tut.cis.ohio-state.edu>
Sender: news@uhccux.uhcc.Hawaii.Edu
Organization: University of Hawaii
Lines: 30

In article <83514@tut.cis.ohio-state.edu> pritch@tut.cis.ohio-state.edu (Norm Pritchett) writes:
>
> qemm-386 and 386max have been recommended to me. I am trying to
>find someone who has actually had experience using either of these
>products with network device drivers .  Had any successes/problems? 
>

I have been loading my network software high with QEMM for over a
year now.  It saves me about 96K.  Not all the drivers can be loaded
high.  Some want to define multiple drivers, which QEMM can't handle.
Another one just doesn't work, but the big ones work just fine.

QEMM is a quality product.  However, keep in mind that products like
QEMM and 386max run in protected mode.  This means that they will
clash with other pieces of protected mode software that don't follow
their rules (Virtual Control Program Interface.)

Examples of things I have run across that don't conform to VCPI are:

Halo Graphics
Data Translation DT-2851 Frame Grabber Software
Microsoft Windows 3.0 (Quarterdeck has generated a fix for QEMM)

Anything that has to access Extended memory is a potential conflict.
Device drivers and software that people send with these devices usually
don't conform to VCPI.

				   Eric Pilger
				   Systems Programmer
				   NASA Infrared Telescope Facility