Xref: utzoo comp.sys.novell:1334 comp.windows.ms:12081
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!spool.mu.edu!uunet!europa.asd.contel.com!wlbr!WLV.IMSD.CONTEL.COM!mcc
From: mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
Newsgroups: comp.sys.novell,comp.windows.ms
Subject: Re: Printer problem with Windows and Novell
Message-ID: <1991Apr29.215825.21375@wlbr.imsd.contel.com>
Date: 29 Apr 91 21:58:25 GMT
Article-I.D.: wlbr.1991Apr29.215825.21375
References: <1991Apr29.133659.119488@rrz.uni-koeln.de>
Sender: news@wlbr.imsd.contel.com (news)
Organization: Contel Federal Systems
Lines: 31
Nntp-Posting-Host: wlv.imsd.contel.com

In article <1991Apr29.133659.119488@rrz.uni-koeln.de> ro@rrz.uni-koeln.de (Jochen Roderburg) writes:
>
>  [much deleted]
>
>With QEMM I have tried every combination of QEMM parameters, loading
>drivers high and low, using NET, XMSNET, EMSNET, nothing works.
>The exact result varies, but always I have garbage before and after the
>*real* print file. The garbage is something random from memory, I always
>find parts of my resident programs in it.
>After these result I had a strong suspicion against QEMM, and started
>another test series with HIMEM.SYS instead, but even this doesn't work
>with XMSNET. The only combination which works is HIMEM.SYS with NET4,
>what is clearly not the desired configuration, because with this I can't
>save any byte of our precious DOS memory.
>
Unfortunately, my environment is not exactly the same--I don't do windows.
I leave that for the domestics.

I have found that QEMM386 can be used to load NET4 in upper memory without
any ill effects.  I do use the DOSSHELL to avoid consuming precious disk
space with small batch files (*.MEU in effect allows multiple batch files
to be combined) and load its SHELLB into upper memory.

In this environment there is no problem printing to an HP LJIII.

I don't see any particular advantage to using XMSNETn or EMSNETn if one is
going to load the NET shell into upper memory.  The memory management versions
may be just a little too smart for their own logic when their root is loaded
high.

Merton Campbell Crockett