
              NOVELL TECHNICAL INFORMATION DOCUMENT

TITLE:              NETX, EMSNETX, and XMSNETX Fix Windows Hangs
DOCUMENT ID:        TID021203
DOCUMENT REVISION:  B
DATE:               11AUG94
ALERT STATUS:       Yellow
INFORMATION TYPE:   Symptom Solution
README FOR:         NET33X.EXE

NOVELL PRODUCT and VERSION:
NetWare Client for DOS/MS Windows 1.1

ABSTRACT:

Windows will hang when a detach from the server is made from Windows using the
File Manager, exiting Windows, then starting it, doing a second detach from a
server.  This file contains NETX, EMSNETX, and XMSNETX to fix the Windows
hanging problem.

-----------------------------------------------------------------
DISCLAIMER
THE ORIGIN OF THIS INFORMATION MAY BE INTERNAL OR EXTERNAL TO NOVELL.  NOVELL
MAKES EVERY EFFORT WITHIN ITS MEANS TO VERIFY THIS INFORMATION.  HOWEVER, THE
INFORMATION PROVIDED IN THIS DOCUMENT IS FOR YOUR INFORMATION ONLY.  NOVELL
MAKES NO EXPLICIT OR IMPLIED CLAIMS TO THE VALIDITY OF THIS INFORMATION.
-----------------------------------------------------------------

ADDITIONAL CONFIGURATION

Third-Party Product and Version:

Windows 3.1

SYMPTOM

Windows will hang when a detach from server is made from Windows using the
File Manager, exiting Windows, then starting it, and doing a second detach
from a server.

SOLUTION

Apply NET33X.EXE.  The VNetwareFlag was fixed to be reset when Windows exits.

Self-Extracting File Name:  NET33X.EXE     Revision:  B

Files Included     Size     Date      Time

\
  NET33X.TXT         (This File)
    NETX.EXE      78749   05-24-94    8:53a
 EMSNETX.EXE      90605   05-24-94    8:55a
 XMSNETX.EXE      87273   05-24-94    8:57a

Installation Instructions:

1.   Make a backup copy of the existing shell (NETX.EXE, XMSNETX.EXE, or
EMSNETX.EXE).

2.   Copy this new version over the existing shell.

3.   Reboot the workstation.

IMPORTANT:

FOR PC DOS 6.10 AND MS DOS 6.21 USERS:

(Problem using the %OS_VERSION parameter)

The default login script, as well as many system login script files contain
the following commands:

     MAP INS S1:=SYS:PUBLIC
     MAP INS S2:=SYS:PUBLIC/%MACHINE/%OS/%OS_VERSION

The %MACHINE variable applies to the LONG MACHINE TYPE= <Name> parameter in
the NET.CFG file.  It defaults to IBM_PC

The %OS variable applies to the DOS NAME= <Name> parameter in the NET.CFG
file.  It defaults to MS DOS.  PC DOS users typically will create a directory
called PCDOS, and set DOS NAME=PCDOS in the workstation NET.CFG file.  This
allows the coexistence of MS DOS and PC DOS with the same version number to be
mapped under the %OS directory.

For example:

     SYS:PUBLIC\IBM_PC\MSDOS\V6.00
     SYS:PUBLIC\IBM_PC\PCDOS\V6.00

The %OS_VERSION variable applies to the DOS VERSION returned from DOS INT
21h-Function 30h, which is the "GET DOS VERSION" function.  NetWare checks the
AL register for the major version number and the AH register for the minor
version number.

Using INT 21h, Function 30h for PC DOS v6.00, will return 6.00 as the version.
This matches the DOS VER command from PC DOS v6.00, which also returns version
6.00.  However, using INT 21h, Function 30h for PC DOS v6.10, will also return
6.00 as the version.  This does not match the VER command from PC DOS v6.10,
which shows the version as 6.10.

Using INT 21h, Function 30h for MS DOS v6.20, will return 6.20 as the version.
This matches the DOS VER command from MS DOS v6.20, which also returns version
6.20.  However, using INT 21h, Function 30h for MS DOS v6.21, will also return
6.20 as the version.  This does not match the VER command from MS DOS v6.21,
which shows the  version as 6.21.

This is similar to what happens with DOS 4.01.  The DOS VER command (which
returns an ASCII text string) reports the DOS version as version 4.01;
however, internally (using the Get Dos Version function call), DOS 4.01
reports itself as DOS version 4.00 to applications.

This means that PC DOS v6.10 users will be mapped to the
SYS:PUBLIC\IBM_PC\PCDOS\V6.00 directory by default, because

INT 21h-Function 30h returns 6.00 as the version and the NETX.EXE shell relies
on this function to return the correct DOS version.

MS DOS 6.21 users will be mapped to the SYS:PUBLIC\IBM_PC\MSDOS\V6.20
directory by default, because INT 21h-Function 30h returns 6.20 as the version
and the NETX.EXE shell relies on this function to return the correct DOS
version.

This will result in invalid command.com errors if comspec is set to the
network "DOS directory" search mapping.

WORKAROUND OPTIONS FOR PC DOS 6.10 USERS:

Option 1:

     Add the following line to the workstation's config.sys file: 
DEVICE=SETVER.EXE

     To add netx.exe to the setver table, the following at the DOS prompt:

          SETVER NETX.EXE 6.10

     To list the elements in the setver table so you can make sure NETX.EXE
was correctly added to the table, type the following at the DOS prompt:

          SETVER

     NOTE:  NETX.EXE can be removed from the setver table using the following
syntax:

          SETVER NETX.EXE /D

     Only do this if setver is no longer needed to report the correct DOS
version to the NETX.EXE shell.

     Reboot the workstation, and load the network software.

Option 2:

     Upgrade all workstations from PC DOS v6.00 to PC DOS v6.10, and place the
PC DOS v6.10 files into the following directory:

          SYS:PUBLIC\IBM_PC\PCDOS\V6.00.

     This will allow the default mapping of SYS:PUBLIC\IBM_PC\PCDOS\V6.00 to
work for v6.10 PCDOS users.

WORKAROUND OPTIONS FOR MS DOS 6.21 USERS:

Option 1:

     Add the following line to the workstation's config.sys file:

          DEVICE=SETVER.EXE

     To add netx.exe to the setver table, type the following command at the
DOS prompt:

          SETVER NETX.EXE 6.21

     To list the elements in the setver table so that you can make sure
NETX.EXE was correctly added to the table, type the following at the DOS
prompt:

          SETVER

     NOTE:  NETX.EXE can be removed from the setver table using the following
syntax:

          SETVER NETX.EXE /D

     Only do this if setver is no longer needed to report the correct DOS
version to the NETX.EXE shell.

     Reboot the workstation, and load the network software.

Option 2:

     Upgrade all workstations from MS DOS v6.20 to MS DOS v6.21, and place the
MS DOS v6.21 files into the following directory:

          SYS:PUBLIC\IBM_PC\MSDOS\V6.20

     This will allow the default mapping of SYS:PUBLIC\IBM_PC\MSDOS\V6.20 to
work for v6.21 MSDOS users.

Patch History:

Problems Addressed 16DEC93

1)   Provides support for DOS 6.x, rather than just 6.0 and below.  Added
support for versions 6.x of DOS. (See the IMPORTANT section of the
Installation Instructions of this document.)

2)   Adds support for the NCP return code 150.  Now when the shell receives a
150 return code from Int 21 function 50h, it will put a 24h in the AX
register, indicating a "sharing buffer overflow" error.

3)   BACKUP from DOS 5.0 fails when specifying a NetWare drive as the target
drive.  Int 21 function 60 was failing (file not found) when parsing root
directory names, such as "f:\".

4)   Unable to set PRINT TAIL value in NET.CFG to 0. This has been fixed in
this release.

5)   The destination file's date changes with the NCOPY /C option.  A bug in
the cache code could cause NCOPY /C to update the destination file with the
current date and time.  Specifically, using NCOPY /C to copy  a 30911 byte
file would cause the bug.  Some other sizes would not fail.

6)   Interrupt 21h function 40h errors were not being passed on to the
application.  The shell was clearing the carry flag on write errors, causing
an application to interpret that no write error had occurred.

7)   Interrupt 21h function 4B01h (load but do not execute) was causing the
workstation to hang.

8)   The stack size was increased in order to accommodate the "PRINT TAIL"
parameter in NET.CFG.

9)   Interrupt 21h function 4409h, which determines whether the specified
device is local or remote, was returning incorrect values when run on a
network drive.

10)  The shell was returning an incorrect print job number.

11)  If a section of a file is locked with int 21h - 5Ch, then another
workstation accesses the same file and tries to read the locked area with int
21h - 3Fh, it will return successful.


-----------------------------------------------------------------
Any trademarks referenced in this document are the property of their
respective owners.  Consult your product manuals for complete trademark
information.
-----------------------------------------------------------------




