X-Envelope-to: NOVELL@SUVM.BITNET
Receipt:  Return Receipt requested.
XGW-Version: IMail SMTP Gateway v1.54 1/16/92
XGW-To:   NOVELL@SUVM.BITNET
Newsgroups: bit.listserv.novell
Date:         Thu, 16 Apr 1992 17:41:00 MDT
Reply-To:     Novell LAN Interest Group <NOVELL@SUVM.BITNET>
From:         "Dean R. Brunson" <DBRUNSON@NSC.UTAH.EDU>
Subject:      More MS-DOS 5.0/DR-DOS 6.0 Eval Results

Last night I downloaded the new DR DOS 6.0 compatibility upgrade from
CompuServe.  This release was primarily intended to provide compatibility
with Windows 3.1.  I have been testing this release against a list of
problems we have had with the original release of 6.0, and which I posted a
message about last week.  Some problems are solved, and some remain.  Here's
an update of our original findings.

>   Most troubling to us is that DR-DOS has a problem with the WD8003
>   Ethernet cards.  On a stock IBM-XT booted with plain-vanilla DR-
>   DOS 6.0, loading IPX (or IPXODI) causes floppy disk access to
>   slow by about 2,000%.  A bootup/login sequence usually taking 30-
>   40 seconds takes over NINE MINUTES under DR-DOS 6.0.

This is fixed!  The first thing I did was upgrade the test boot disk we had
used for the original testing, and it ran right alongside the other DOS's
we've used there -- NO SLOWDOWN!  I suspect that this may be a general fix
for BIOS's older than 1987.

>   Most significant generally is that DR's HIDOS.SYS is not
>   compatible with EXEPACK'ed files older than about two years.
>   This includes the first several releases of WordPerfect 5.1.
>   Some enterprising DR users have developed a way to patch your old
>   EXE's to run with DR DOS.  We reject this approach out of hand,
>   because of the support complications it introduces:
>   1)Reinstalling the application from original disks will break
>   your system; 2)it violates the license agreements of most
>   commercial software vendors; and 3)you'll be laughed off the
>   planet if you call tech support to fix a problem, and it turns
>   out to be the result of a patched EXE.

It was not HIDOS.SYS, but loading DOS high via the DOS=HIGH or HIDOS=ON
commands in config.sys.  This reduces the size of DOS in conventional memory,
and allows a program to start loading lower in memory than 64Kb.  That's what
the early EXEPACK'ed files can't handle.  (MS-DOS 5.0 automatically corrects
for this, and avoids the problem from the user's standpoint).

Incidentally, here's a list of major commercial affected EXE's (that impact
us):

     WordPerfect 5.1 from 11-89 (original release) through 8-90

     NetWare 2.15C Utilities:
          capture, castoff, caston, chkvol, colorpal, endcap, flag, flagdir,
          grant, larchive, listdir, lrestore, macback, map, menu, narchive,
          ndir, nprint, nrestore, nver, psc, pstat, purge, remove, rendir,
          revoke, rights, salvage, send, setpass, settts, smode, systime

     NetWare 3.11 Utilities:
          castoff, caston, colorpal, endcap, send, settts, systime

>   DR provides a work-around command-line switch that also solves
>   this problem (by disabling memory management), so long as you run
>   HIDOS.SYS.  If you elect to use 386MAX, BlueMAX, QEMM386, etc.,
>   you'll get the incompatibility, but no way to work around it
>   short of patching the EXE.

MEMMAX.EXE allows you to block program access to the first 64Kb block of
conventional memory, using the command MEMMAX -L.  THIS COMMAND WORKS WITH
QEMM 6.0, as well as with HIDOS.SYS, so there IS a workaround if you're using
QEMM.

Still, you (or your user) will have a bumpy ride if you run an offending EXE
from the command line.  And whether you have to run MEMMAX separately, or you
build it into a batch file, you do lose that memory -- in a typical system
installation, about 40Kb.  You'll have to remember to run MEMMAX +L after the
EXE to recover that memory, or build that into your batch file, too (or just
kiss the memory good-bye -- gee, you could just not load DOS high in the
first place...).

   Some DR batch commands are not completely compatible with MS-DOS
   (either 3.3 or 5.0).  The most conspicuous one for us is that "if
   exist" in MS-DOS will return true if the file exists, even if the
   file is hidden.  DR-DOS will return false if the file exists, but
   is hidden.

   DR logs the disk differently than MS-DOS.  This results in
   extremely slow exits to the dos prompt from some programs (it depends
   on the size of the disk you're exiting to).

These items remain the same.



        Dean Brunson
        Network Support Center

        581-3323
        DBRUNSON@EDU-UTAH-NSC
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU