Dec 052017
 
Novell patch to avoid Black Screen of Death problem using DOS program under Windows on a netware network. Patch dated Sept. 9, 93.
File BSDUP1.ZIP from The Programmer’s Corner in
Category Network Files
Novell patch to avoid Black Screen of Death problem using DOS program under Windows on a netware network. Patch dated Sept. 9, 93.
File Name File Size Zip Size Zip Type
BSDUP1.TXT 9979 3905 deflated
IPXODI.COM 30051 15762 deflated
LSL.COM 17760 10366 deflated
VIPX.386 23850 9159 deflated

Download File BSDUP1.ZIP Here

Contents of the BSDUP1.TXT file



NOVELL TECHNICAL INFORMATION DOCUMENT

TITLE: Black Screen of Death
DOCUMENT ID: TID013403
DOCUMENT REVISION: A
DATE: 13SEP93
ALERT STATUS: Yellow
INFORMATION TYPE: Symptom Solution
README FOR: BSDUP1.EXE

NOVELL PRODUCT and VERSION:
NetWare Client for DOS/Windows

ABSTRACT:
These newer files fix a problem when using Windows or Windows for
Workgroups on a network. The symptom is a blinking underlined curser in
the upper left hand corner of the screen when entering a DOS box or DOS
application and the workstation hangs.
_________________________________________________________________

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.
_________________________________________________________________

Self-Extracting File Name: BSDUP1.EXE Revision: A

Files Included Size Date

\
BSDUP1.TXT (This File)
VIPX.386 23850 5-11-93 version 1.15 (930511)
IPXODI.COM 30051 4-23-93 version 2.11 (930423)
LSL.COM 17760 7-28-93 version 2.02 (930728)


I. Description
---------------

These newer files fix a problem when using Windows or Windows for
Workgroups on a network. The symptom is a blinking underlined curser in
the upper left hand corner of the screen when entering a DOS box or DOS
application and the workstation hangs. The following factors may
contribute to the problem:

* Third-party device drivers or terminate-and-stay-resident (TSR)
programs.
* An incorrect system configuration including memory management.
* I/O, memory, or IRQ confilcts.
* Problems in VIPX.386.
* A problem in the Windows 3.1 virtual timing driver (VTD).


II. VIPX.386
-------------

VIPX.386 is a Windows 3.X virtualization driver for IPXODI.COM driver that
was enhanced jointly by NOVELL and Microsoft. It virtualizes requests to
the globally loaded IPX driver. When a request is made to IPX, VIPX will
allocate a request buffer in the system's global memory, copy the original
request to the global buffer and give the global request to IPX. When the
global request completes, IPX will call VIPX. VIPX will then copy any
results back to the original request buffer and call the application which
submitted the request.


II.A. Version Compatibility with Dedicated IPX
-----------------------------------------------

Novell officially ceased maintenance on the dedicated IPX driver (IPX.OBJ)
version 3.10 dated 11-21-91. The last version of VIPX to explicitly
support that driver is 1.10. The current version of VIPX supports
IPXODI.COM only. It is strongly recommended that you update your dedicated
IPX driver with IPXODI.COM when using versions of VIPX later than 1.10.
You can find the latest ODI drivers in the DOSUP?.ZIP file, currently
DOSUP7.ZIP.


II.B. Packet Size Limitations
------------------------------

VIPX.386 will only virtualize packets which are 8000 (decimal) bytes or
less. Any DOS and Windows IPX or SPX applications which use networks with
a physical packet size greater than 8000 bytes may not work with VIPX.386.
For example, IBM Token Ring can be configured to run with 16K packets. A
request by a DOS or Windows IPX application to send a 16K packet will be
truncated to 8000 bytes. On the other hand, any 16K packet that is
received by the LAN driver will be dropped because VIPX cannot allocate a
packet big enough to handle it.


II.C. Memory Manager Limitations
---------------------------------

When a request is passed up from IPX, VIPX will immediately test the
request buffer to see if it is in global memory already. If it is in
global memory, the request will be passed back down to IPX without any
virtualization. For example, a TSR loaded before Windows is considered to
be in global memory. If that TSR calls IPX, VIPX will test the requests
and pass them back down to IPX. This is done because there is no need to
virtualize requests which are already global.

The use of UMA memory complicates the test for global memory. There are
two basic scenarios. Scenario One is when a TSR has been loaded high
before Windows was loaded. In this case, IPX requests will come from
global UMA memory. VIPX will simply pass these requests back down to IPX.
Scenario Two is when a TSR is loaded high in a Windows DOSBOX. In this
case, IPX requests will come from local UMA memory. VIPX will virtualize
these requests.

Some memory managers test for global UMA memory and will work properly
under both scenarios. However, there are other memory managers that do not
work properly under Windows. With these drivers, all LOCAL DOSBOX UMAs
look as if they are GLOBAL UMAs. Under Scenario Two, when a TSR calls IPX,
VIPX will test the request buffer and think that it is in global UMA memory
when it is really in LOCAL UMA memory. As a result, VIPX will pass a local
ECB to IPX without virtualization. The normal result of this is a hung
machine or data corruption.

If you are using third party memory managers and hang, don't load TSRs
USING THE IPX INTERFACE (INCLUDING IPX ITSELF) HIGH. THEY MUST BE LOADED
IN CONVENTIONAL MEMORY.


III. Specialized Configuration Parameters
------------------------------------------

Under most circumstances, VIPX will work fine under the default
configuration. However, there may be some applications which require
custom configuration of the driver. This is a list of SYSTEM.INI
parameters which can be used to configure VIPX:

[VIPX]
VipxMappingPages =[number of 4K pages] (default = 16)
VipxFailOverSizedPackets =[ON|OFF|TRUE|FALSE] (default = OFF)
VirtualizeIrq[0-F] =[ON|OFF|TRUE|FALSE] (default = OFF)

III.A. VipxMappingPages
------------------------


This is the number of pages that VIPX can use to globalize requests to the
global IPXODI.COM driver. VIPX is not absolutely guaranteed to have all of
these pages available at any one point, since this is the requested number
of pages for SHARED global mapping which VIPX makes to the Windows VMM at
initialization time.


III.B. VipxFailOverSizedPackets
--------------------------------

This parameter tells VIPX to fail any requests which require more than the
maximum allowed globalization size. The actual maximum will vary according
to which media the user is on. The absolute maximum is 8000 (decimal)
bytes. With media that have smaller packets than 8000 bytes, the maximum
allowed size is the maximum packet size that can be put onto the media.


III.C. VirtualizeIrq[0-F]
--------------------------

VIPX 1.15 avoids a deadlock between the PC and Network Interface Card (NIC)
by virtualizing the NIC's IRQ(s). With ODI and dedicated IPX (IPX.OBJ)
drivers, VIPX will automatically read the configuration of the NIC from the
driver and virtualize the selected IRQs. However, when using the IBM LAN
Support Program with either SLANSUP.OBJ or LANSUP.COM, the LAN IRQ is not
readable from the driver. The only way to get this information is to read
the NIC hardware itself. The problem with doing this is that the hardware
can be Token Ring, PCN2 or Ethernet. VIPX must now be aware of many
different hardware configurations. Instead of this, VIPX requires the IBM
LAN Support user to specify the NIC's IRQ in the [VIPX] section of the
SYSTEM.INI. IRQs range from 0 to F (hex). An example is listed below:

[VIPX]
VirtualizeIrq2=TRUE
VirtualizeIrq3=TRUE

In this example, VIPX will virtualize both IRQ 2 and IRQ 3. VIPX can
virtualize up to 4 different LAN IRQs. The reason for virtualizing
multiple IRQs is to allow other LAN cards and protocols to be installed on
the same PC and prevent them from deadlocking the PC. For example, you may
have IPX running through an NE2000 card on IRQ 3 and TCP/IP running through
to an IBM Token Ring card on IRQ 2.


III.D. TimerCriticalSection
----------------------------

As of version 1.15 of VIPX, TimerCriticalSection is required to be set on.
The recommended setting is as follows:

[386Enh]
TimerCriticalSection=10000

The reason for this parameter is to avoid a deadlock with the LAN IRQ
Virtualization code. See section III.C VirtualizeIrq[0-F].


IV. IPXODI.COM
---------------

IPXODI.COM had a bug in SPX. During a retry, SPX would jump to invalid
memory causing an invalid opcode exception in v86 mode only when SPX is
being used. Few applications use SPX. This usually manifests itself as a
reboot, hung machine or blank screen with cursor in upper left corner.
This version of IPXODI.COM should be used instead of the one found in
DOSUP7.ZIP.


V. LSL.COM
-----------

LSL.COM had a number of bugs and one was a bug that caused a deadlock
situation with the LAN adapter. A Do Send for Windows needed a Start and
End Critical Section call added. It is now language enabled. A memory
calculation bug when calculating the amount of memory to reserve when going
TSR is fixed. This version of LSL.COM should be used instead of the one
found in DOSUP7.ZIP. It will only take about 300 bytes of extra memory.


VI. INSTALLATION
-----------------

* Rename or backup the old VIPX.386, IPXODI.COM and LSL.COM.
* Copy IPXODI.COM and LSL.COM to where the NIC software is initialized.
* Copy VIPX.386 to your WINDOWS\SYSTEM directory.
* Virtualize the NIC's IRQ in the [VIPX] section of the System.ini if using
IBM LAN SUPPORT.
* Put TimerCriticalSection=10000 in the [386Enh] section of the
System.ini.
* Reboot the PC and load the ODI drivers.
* Enter windows.



 December 5, 2017  Add comments

Leave a Reply