Programmer 7500/MAX_PROGRAMMERS.iso/PROGRAMS/UTILS/NOVELL/AN101A.ZIP/AN101A.TXT

Text File | 1991-02-15 | 153.0 KB | 3,464 lines

NetWare and Microsoft Windows Integration

Jason Lamb
Senior Consultant
Systems Research Department

Abstract:

     This Application Note will explain the integration of the Microsoft
     Windows environment with Novell's  NetWare network operating system.
     Since Windows is a graphical user interface (GUI) that runs on top of
     MS-DOS, this Application Note will primarily deal with the integration
     issues for the NetWare workstation. We will also cover some network
     administration  issues regarding Windows as well as some Windows
     theory and mechanics.

Disclaimer

     Novell, Inc. makes no representations or warranties with respect to
     the contents or use of these Application Notes (AppNotes) or of any of
     the third-party products discussed in the AppNotes. Novell reserves
     the right to revise these AppNotes and to make changes in their
     content at any time, without obligation to notify any person or entity
     of such revisions or changes. These AppNotes do not constitute an
     endorsement of the third-party product or products that were tested.
     Configuration(s) tested or described may or may not be the only
     available solution. Any test is not a determination of product quality
     or correctness, nor does it ensure compliance with any federal, state
     or local requirements. Novell does not warranty products except as
     stated in applicable Novell product warranties or license agreements.

     Copyright { 1991 by Novell, Inc., Provo, Utah. All rights reserved.

     As a means of promoting NetWare AppNotes, Novell grants you without
     charge the right to reproduce, distribute and use copies of the
     AppNotes, provided you do not receive any payment, commercial benefit
     or other consideration for the reproduction or distribution, or change
     any copyright notices appearing on or in the document.

Acknowledgments

     Put simply, this Application Note would not exist without the hard
     work and technical expertise of some very important individuals. First
     off, I want to extend my thanks to the person who brought this project
     to the Systems Research Department. He is:

     Doug Knight         Senior Systems Engineer

     Doug continues to present seminars on Windows and NetWare Integration
     around the country, and it was he who provided all the initial, and
     much of the ongoing information and support for this project.

     Another group of key individuals involved in this project, were the
     people in Novell, responsible for the development, marketing, and
     support, of the NetWare Windows Client software. They are:

     Earle Wells         Support Engineer

     Karl Best           Technical Writer, Windows

     Tom Scribner        Architect / Software Engineer, Windows

     Danny Young         Software Engineer, Windows

     Andy Cox            Product Manager, DOS/Windows Clients

     Without this team there would be no issue with Windows and NetWare
     integration, because there would be no integration. Also, without
     Andy's constant drive this project could not have been finished in its
     time frame. Additionally, there were other engineers who, while not
     mentioned here, played an invaluable part in the production of this
     report.

     Lastly, this Application Note was worked on up to the very last
     minute. This couldn't have been possible without the support of the
     people who run the Application Note Program.

     Ron Lee             Managing Editor

     Bob Jones           Technical Writer / Desktop Publishing Specialist

     J. Warren Harding   Publisher / Manager Systems Research Department

     The only people left to thank are you. You as the reader, are the key
     to whether these, and other Novell information efforts, hit the mark.
     The only way we can know for sure, is if you let us know. Thanks.

Jason Lamb

Editor's Note: Feedback is encouraged to the author at FAX [phone]

Introduction

     This Application Note will explain the integration of the Microsoft
     Windows environment with Novell's  NetWare network operating system.
     Since Windows is a graphical user interface (GUI) that runs on top of
     MS-DOS, this Application Note will primarily deal with the integration
     issues for the NetWare workstation. We will also cover some network
     administration  issues regarding Windows as well as some Windows
     theory and mechanics.

     It probably comes as no surprise that the demand for this type of
     information is very great. Windows 3.0 has done more to excite the PC
     world than many products of recent memory. As might be understandable,
     the pace at which we tried to cover these issues was also great. As a
     result this Application Note has evolved out of a simple install and
     tips guide, into the monster you now hold in your hands. But don't
     fret if the size is a little daunting. We will go over each section of
     the Application Note below. From that you should be able to get a good
     idea what sections will be the most important to you.

     We will begin by looking at the history of the Windows product line.
     This will cover from the very first shipped version, up to today's
     version 3.0. Following that we will look at two major pieces of the
     Windows environment, application support and memory management.

     We will follow that with a look at something new for Windows,  network
     support. This would be the first section to look at, if the concern is
     to know the installation issues first. Network services and network
     related files will be covered in depth in this section. Following that
     we will go through the process necessary for installing Windows on a
     NetWare file server, as well as the process for configuring Windows to
     run on NetWare workstations.

     Next we will cover some startup considerations, as well as the
     important Windows and NetWare configuration files. Following that we
     will look at some run time considerations and finish up with some
     additional Windows LAN administration tips. The remainder of the
     document covers troubleshooting issues and appendices.

     As this project evolved we found that our focus had also evolved.
     While we always felt that it was important to provide an installation
     guide and tips manual for the LAN administrator who needs to install
     software today, we also felt it was of equal importance that the LAN
     administrator gain some understanding of what makes Windows and
     NetWare Windows support, tick. It's our hope that this report can
     serve this two-fold purpose for people interested in the integration
     of Windows and NetWare.

Windows History

     Microsoft first announced Windows as a GUI for MS-DOS computers, in
     1983. However it would be two years later before Windows actually
     shipped to customers. In November of 1985 the first release of
     Microsoft Windows, version 1.01, became available. Windows 1.01 ran on
     a two floppy drive 8088 based PC with a minimum of 320KB of RAM. The
     most memorable feature of this version was the fact that the
     environment forced tiling of all the windows (rather than overlap
     them). This was done because it was thought that the automatic tiling
     would minimize the amount of work needing to be performed.

     In 1987 version 1.01 was followed by Windows 2.0. Version 2.0 sported
     an enhanced look in order to appear more like another Microsoft GUI
     announced that year, OS/2 Presentation Manager. Among its new
     features, version 2.0 allowed overlapping windows and introduced a new
     memory management scheme. Specifically version 2.0 added support for
     the Expanded Memory Specification (EMS), that had been developed by
     Lotus, Intel and Microsoft. This specification outlined a bank
     switching method of memory management that would increase available
     application memory under MS-DOS. Using this memory management scheme,
     Windows could provide applications with similar increased memory
     space.

     With the introduction in 1988 of Windows 2.1, Windows itself was split
     into two separate products. The first product was Windows/286 and
     while this version could actually run on an 8088/6 CPU, Microsoft was
     now strongly recommending that the minimum processor be an 80286.
     Among its features, Windows/286 added support for the newly defined
     Extended Memory Specification (XMS), developed by Microsoft. XMS
     provides a standard method for allocating, using and releasing
     extended memory. Utilizing XMS and a modified version of Windows/286,
     this Windows environment could actually make use of the first 64KB RAM
     of extended memory for itself and Windows applications. This would
     actually be a prelude to the memory management architecture of Windows
     3.0.

     The second product was Windows/386. This version's main difference was
     multitasking support for Windows and non-Windows applications.
     Windows/386 utilized the 80386's virtual 8086 mode to run DOS
     applications in their own separate virtual machine.

Windows 3.0

     The announcement of Windows 3.0 on May 22,1990 was one of the most
     celebrated roll outs of a computer software product ever. The fact
     that pre-release versions of Windows 3.0 had been widely distributed
     and available for some time to the developer and IS communities, did
     nothing to dampen the enthusiasm for the product when it was announced
     at simultaneous press announcements on both coasts.

     In terms of the Windows product line the version number change from
     2.1 to 3.0 was well justified. Windows 3.0 provides significant visual
     as well as structural changes from previous versions. Gone are the two
     separate products, Windows/286 and Windows/386. Windows 3.0 will run
     on either the 8088/6, 80286, 80386, or 80486 Intel processors,
     although Microsoft still recommends the minimum processor be an 80286.

     Featured changes to Windows 3.0 are an enhanced look utilizing a
     proportional font, three-dimensional shading, color, and a new icon
     based desktop. Also, for the first time Windows now provides direct
     network support for certain networks. This includes the ability to
     connect to file servers and print servers from within the Windows
     environment. Novell NetWare support was written by Novell and is
     provided to Microsoft to be bundled in with the Windows 3.0 package.
     shows the new Windows 3.0 look.

     : Windows 3.0

Real Mode

     One of the biggest changes with Windows 3.0 is that it can be run in
     either one of three different modes. These are Real, Standard and 386
     Enhanced mode. Real mode is the recommended mode for running most
     Windows applications written prior to version 3.0. This mode requires
     640KB of RAM and can run on any Intel 8088/6 processor and above. Real
     mode is the only Windows mode to utilize expanded memory for both
     Windows and Windows applications. Expanded memory conforming to the
     EMS 4.0 specification is required for this.

Standard Mode

     The second mode is Standard mode and it incorporates among other
     things, a memory management technology designed to give access to the
     large protected mode memory address space of the 80286 processor or
     higher. However, it gives this access to Windows and Windows
     applications only. This memory management technique is called a DOS
     extender and it means that it is possible for Windows applications to
     be written which can access up to 16MB of RAM. This is what is meant
     when mention is made of Windows breaking the 640KB barrier.

     Standard mode requires an 80286 processor or higher, as well as at
     least 256KB of extended RAM. This is RAM above the conventional RAM
     space of 640KB. Lastly, in order to run Windows in Standard mode you
     are required to load an Extended Memory Specification (XMS) memory
     manager, version 2.0 or higher.

386 Enhanced Mode

     The third Windows 3.0 mode is the 386 Enhanced mode which as you might
     suspect, requires an 80386 processor or above. 386 Enhanced mode
     provides a similar DOS extender memory management technology as
     Standard mode. The difference is that Windows in 386 Enhanced mode
     provides virtual memory capability by using the paging features of the
     80386 processor. By creating paging space on DOS disks for Windows to
     swap memory contents to, this allows Windows and Windows application
     to have access to more memory than is physically installed in the
     system. Windows in this mode actually provides virtual memory space up
     to four times the amount of physical memory installed. In its largest
     configuration this could result in Windows applications being able to
     access 64MB of RAM.

     Additionally as in Windows/386, 386 Enhanced mode provides
     multitasking support by utilizing the virtual 8086 mode of the 80386
     processor. Minimum requirements for this mode are 1 megabyte of
     extended memory above the conventional 640KB RAM, and an XMS memory
     manager, version 2.0 or higher.

The Windows Environment

     Microsoft Windows is a GUI developed to run on top of MS-DOS. However,
     Windows will typically take over many of the standard operating system
     chores from MS-DOS. It is for this reason that Windows is described as
     an operating environment. Windows, in fact, handles much of the
     application support that is usually associated with an operating
     system, such as user input, graphics output to displays and printers,
     and memory management. It does however, use MS-DOS for some services
     like file I/O, and other disk operations.

     There are two areas of the Windows environment that are important to
     understand, in terms of Windows and network support, and in terms of
     understanding the Windows environment in general. These areas are
     Windows applications support, and Windows memory management.

Windows Applications

     Within the Windows environment there is support for two different
     types of applications. The first is the Windows specific application.
     This type of program is written to use all the system services
     provided by Windows, and consequently cannot run without loading at
     least a minimal version of Windows first.

     Because the Windows environment provides new or changed access to
     system resources, application programmers have to develop applications
     that directly call these resources if they are to take advantage of
     the Windows environment. This has the benefit of releasing the
     application programmer from having to develop routines that handle
     system resources such as the screen output, printer output, and user
     interface. The programmer can just make use of the standard Windows
     resources to handle these tasks.

Non-Windows Applications

     This second type of application supported by the Windows environment,
     is the DOS application not written to run under Windows. These types
     of applications are sometimes referred to as standard applications (in
     versions of Windows prior to 3.0), non-Windows applications (with the
     introduction of Windows 3.0), or simply DOS applications.

     Since there exists a large amount of standard DOS applications,
     Microsoft has equipped Windows (since early versions), with the
     ability to run these standard MS-DOS applications without exiting the
     Windows environment. Version 3.0 provides support for running these
     non-Windows applications from within Windows, in all three modes Real,
     Standard and 386 Enhanced.

     Windows programmers, since early versions of Windows, informally
     provided another classification for non-Windows applications. These
     programmers would refer to non-Windows applications as "old apps".
     They further split "old apps" into both "good old apps" and "bad old
     apps". The classifications of "good" and "bad" were not in regards to
     the perceived quality of the application, but rather in how this type
     of application would behave while running under Windows. The way in
     which the application was written to access the PC, directly
     determines much of its ability to run from within Windows.

     "Good old apps" were non-Windows applications that were character
     based and written to use all DOS and BIOS services, as opposed to
     directly accessing the hardware. The "good" in "good old apps" is
     applied only for the reason that Windows could successfully trap many
     of the system calls these types of applications would make, and
     translate them into appropriate Windows calls. To the user prior to
     Windows 3.0, these would be the types of non-Windows applications that
     could be run from inside of a window on the Windows desktop.

     "Bad old apps" were non-Windows applications that were typically
     graphical based and made calls directly to the hardware. Since Windows
     could not trap all the system calls these types of applications would
     make, these would typically have to be run in, what was known prior to
     version 3.0 as, full screen mode. This would allow the application to
     access system resources, in particular the screen, more directly.

     Windows/286 and Windows/386 could even go as far, as to swap Windows
     applications and most of the Windows environment out of memory to
     disk, in order to let the "bad old app" have full access to system
     resources. In the Windows/386 product this was referred to as running
     an application in exclusive mode.

     Most prior problems with running non-Windows applications came from
     these "bad old apps". Even when running these types of applications in
     exclusive mode it was possible to issue system calls that would
     conflict with or confuse Windows.

     Windows 3.0 has refined previous, as well as added further, support
     for running non-Windows applications. This added support is different
     based upon which mode of Windows you are running. Real and Standard
     modes support non-Windows applications by utilizing task switching for
     the separate DOS sessions and the Windows session. 386 Enhanced mode
     supports non-Windows applications by creating virtual machines for
     each separate DOS session and the Windows session.

Real and Standard Mode Support

     In Real and Standard mode running non-Windows applications can only be
     done in what was previously referred to as exclusive mode. Windows and
     Windows applications are suspended while the system is given over to
     the non-Windows session. This means that you cannot run these non-
     Windows applications inside of a Window while in Real and Standard
     modes.

     In Real and Standard mode, Windows will perform task switching. This
     means that when a non-Windows application is run, either from a DOS
     prompt called from within Windows, or when the program is called
     directly from within Windows (to Windows there is no difference),
     Windows will create a session for it and allocate a block of RAM for
     its use. In order to allocate this block of memory, Windows will
     switch certain items out of the lower 640KB of RAM, or conventional
     RAM, to either extended memory or to disk. Windows will then suspend
     itself and any running applications, in order to let the called
     non-Windows application run.

     When another non-Windows application is run, or when the Windows
     session is called up, you will see a message saying "Switching" while
     Windows again switches a portion of the current contents of the lower
     640KB of RAM out to either extended memory or disk.

     : Windows Task Switching

     Note that the entire contents of the lower 640KB of RAM is not swapped
     out when this task switching is performed. Windows maintains what is
     referred to as global memory which is not switched out of the lower
     640KB of RAM, and which contains system information such as the
     COMMAND.COM processor, Terminate and Stay Resident (TSR) programs, and
     network or other drivers. This global memory is used as system
     resources for each successive switched session. Memory which is
     switched out is used only by its specific application and is referred
     to as local memory.

     Operationally this provides a single global memory component that is
     never swapped out of the lower 640KB of RAM, and separate switchable
     local memory components (one for each session running) that are
     swapped in and out of the lower 640KB of RAM.  shows how the Standard
     mode, task switching process works.

386 Enhanced Mode Support

     Windows 386 Enhanced mode provides a different method of running non-
     Windows applications. As with Windows/386, 386 Enhanced mode utilizes
     the virtual 8086 mode of the 80386 chip to create and maintain
     separate virtual machines, for both Windows sessions, and non-Windows
     application sessions. Using this mode of the 80386 allows Windows to
     isolate each session from each other, and to virtualize access to
     system resources among all sessions.

     The technique of virtualization is not new to computer technology. It
     basically involves convincing the calling application that it has
     direct access to the system resources, whether it does at that moment,
     or not. A simple analogy might be the phone system. With all of the
     various phone systems installed across the country, a user never knows
     over which wires (or whether in fact it's wires at all), or through
     which route their particular phone call might take. They can assume
     that it is a certain connection through a certain route, and as far as
     the phone call is concerned it doesn't matter whether they're right or
     not. The phone call operates in exactly the same way regardless. It's
     the phone company, or rather the phone company's computers, that
     retain responsibility for providing the actual connection and route.

     Using this technique Windows virtual device drivers allow access to
     the system resources, to be shared among all virtual machines. Virtual
     machine support under 386 Enhanced mode is a combination of software,
     as well as hardware management of the virtualization. This combination
     is much more powerful than any similar software only based approach.

     As a result, these virtual machines allow Windows to successfully trap
     system calls from non-Windows applications, since these calls must be
     given to the virtual device driver first. It is for this reason that
     under 386 Enhanced mode, unlike Standard mode, non-Windows application
     sessions can be run in a few different ways. They can be run inside of
     a window on the desktop, in full screen mode, multitasked in the
     background, or in exclusive mode.

     : Windows Virtual Machines

     Like Windows in Standard mode, 386 Enhanced mode Windows maintains a
     global memory segment for system information like the COMMAND.COM
     processor, drivers and other TSRs. This global memory is memory
     located in the first virtual machine, which is the Windows session.
     This virtual machine is sometimes referred to as the System VM
     (Virtual Machine) or as VM0.  However unlike Standard mode, in 386
     Enhanced mode when a new virtual machine is created, the global memory
     of VM0 is simply remapped as the lower memory of the new virtual
     machine. This is done using the virtual memory addressing capability
     of the 80386.  represents the 386 Enhanced mode's virtual machine
     mechanics.

PIF Files

     Even with the enhanced non-Windows application support available in
     Windows 3.0 it is sometimes advisable to guarantee the amount and type
     of system resources for each non-Windows application session. Windows
     allows a user to configure this through the use of Program Information
     Files or PIF files. These files are covered in depth in the Microsoft
     Windows User's Guide pages 440-490. All settings in both standard and
     386 Enhanced mode are explained in this section of the manual.  shows
     the PIF settings available in 386 Enhanced mode.

     : _DEFAULT.PIF 386 Enhanced Advanced Features


     Fig. shows the settings available through PIF files in Windows
     Standard mode.

     Again, for a complete discussion on these settings please consult the
     Microsoft Windows User's Guide pages 440-490.

     : _DEFAULT.PIF Standard Mode Features

Windows Memory Management

     In this next section, rather than explain various PC memory management
     techniques, such as expanded memory, extended memory, and DOS
     extenders, we will instead concentrate on explaining the way in which
     PC memory is managed among Windows and non-Windows applications, in
     all three Windows modes.

Real Mode

     As mentioned in the opening introduction, Real mode Windows requires
     an 8088/6 CPU or higher and at least 640KB of RAM. Also, Real mode
     Windows can utilize EMS 4.0 expanded memory. This means that Windows
     and Windows applications can have access to more than 640KB of RAM
     through the use of expanded memory only. Non-Windows applications also
     have access to more than 640KB of RAM through the use of the same
     expanded memory.

     In order for this to happen two things must exist. The first, is EMS
     4.0 software and hardware needs to be installed on the system. The
     second, is that the Windows application, (as does the non-Windows
     application), needs to be written to use expanded memory. This is more
     typical of Windows applications prior to version 3.0, since this was
     the way in which larger memory address space was available in older
     versions of Windows. (The first XMS support only provided Windows and
     Windows applications with an additional 64KB of usable memory).

     Version 3.0 Windows applications would not utilize expanded memory
     because Windows 3.0 introduces a new memory management scheme that is
     far more powerful than expanded memory. Most informal recommendations
     suggest only using Windows Real mode, and expanded memory Windows
     applications, as an interim step before moving up to more powerful
     modes of Windows.

Standard Mode

     Standard mode introduces Windows applications to the larger protected
     mode address space of the 80286 chip. In order to run Windows in
     Standard mode you must have an 80286 CPU or higher, at least 256KB of
     extended RAM and an XMS memory manager, version 2.0 or higher.

Windows Applications

     Utilizing the DOS extender technology described in the opening
     section, Standard mode allows Windows and Windows applications to
     access up to 16MB of RAM. If you refer back to  you will see that
     Windows maintains a global memory component and switches out various
     local memory components based upon what is called to run.

     It should be clear that even though the figure depicts all local
     memory components to be the same size, in operation they are not. Due
     to the DOS extender technology utilized as part of Windows memory
     management, the Windows session can be much larger than standard
     non-Windows sessions. The only thing that is required to take
     advantage of this is to run Windows in Standard mode and to run
     Windows applications written to run under Windows 3.0.

Non-Windows Applications

     As previously mentioned non-Windows applications running under Windows
     Standard mode face, task switching when they are called upon to run.
     They can only be run in exclusive mode and they have access to a 640KB
     window of memory to run in. While it might be nice to think that this
     window of memory is reserved for the application alone, it is not.
     This 640KB window is comprised of both the global, and local memory
     components, spoken of earlier. This is the manner under which most
     non-Windows applications will run in Standard mode.

     One small caveat here, is that non-Windows applications are only
     usually limited to the 640KB window, mentioned above. If the non-
     Windows application is written to use the same DOS extender technology
     as Windows, then this application can simultaneously have access to
     the same memory space as Windows and the Windows applications.
     Additionally, through the use of PIF files, you can control the amount
     of memory given over to the DOS extender compliant, non-Windows
     application.

     Finally even though Standard mode Windows does not use expanded memory
     for either Windows or Windows applications, a non-Windows application
     can have access to expanded memory. The expanded memory must simply be
     installed on the system (and not conflict with any Windows memory
     managers) prior to loading Windows, and it will be available to the
     application.

386 Enhanced Mode

     386 Enhanced mode Windows requires an 80386 CPU or higher, 1MB of
     extended RAM, and an XMS memory manager, version 2.0 or higher. 386
     Enhanced mode provides all the same memory management techniques
     available in Standard mode, with a few notable additions. One addition
     is the previously mentioned virtual memory capability of 386 Enhanced
     mode. In this mode, a Windows applications can access up to 64MB of
     RAM. A second addition is that 386 Enhanced mode also provides EMS 4.0
     expanded memory for non-Windows applications. This is done all without
     loading any EMS memory managers.

DOS Protected Mode Interface (DPMI)

     While DOS extender technology is not new by PC standards, Microsoft's
     implementation of the one in Windows is new. The Windows DOS extender
     technology was announced with the introduction of Windows 3.0, and it
     has recently been published as a specification from Intel. It is
     called the DOS Protected Mode Interface (DPMI). As with Standard mode,
     DPMI compliant non-Windows applications can have simultaneous access
     to the large virtual memory address space of Windows in 386 Enhanced
     mode. You can also limit the amount of DPMI memory available to an
     application by using a 386 Enhanced mode PIF file.

     The only problem with a new DOS extender is that it can easily
     conflict with other DOS extenders. The most popular DOS extender to
     date is just such an example of a conflicting one. The older Virtual
     Control Program Interface (VCPI) is the most widely implemented  DOS
     extender and it does conflict with DPMI. Because of this conflict, as
     of version 3.0, Windows in 386 Enhanced mode will not allow a VCPI
     application to run in a non-Windows session.

Windows and Networks

     Improved network support is one of the most significant enhancements
     in Windows 3.0. Prior versions of Windows were mostly ignorant of
     network operations, either treating such operations as server disk
     access as if it were local drive access, or by not supporting certain
     network operations at all. With version 3.0 much of this has changed.

Windows Network Services

     Microsoft developed Windows 3.0 to support various types of networks
     through the use of Windows network drivers. Certain types of network
     operations like mapping drives and connecting to servers and print
     queues, can be done through the use of Windows network drivers, and as
     such, these operations can be done from within the Windows desktop.

     The network services provided to Windows users through the NetWare
     Windows driver, allows Windows users to attach and detach to any
     NetWare server, although you cannot login or logout of NetWare
     servers. You can also add, change, and delete, drive maps as well as
     connect, and disconnect, from any NetWare print server and queue.
     Lastly, NetWare support includes the ability to receive network
     messages while within the Windows desktop.

     Along with the ability to perform certain types of network operations
     from within Windows, you can also install Windows exclusively for
     network workstations, including diskless workstations. This involves
     keeping a shared directory of all Windows files on the server and
     utilizing a new SETUP option to install only the necessary unique
     Windows user files, into separate user directories.

Windows/NetWare Files

     Prior to installing Windows on a NetWare network it is necessary to
     have all the proper files. These include files from the Windows
     distribution diskettes, and files from Novell. The Novell supplied
     files are available from a variety of Novell sources including  the
     CompuServe Information Service - Novell Support Forum, NetWire. The
     following is the list of the necessary Windows/NetWare files and a
     description of their function.

Novell-Supplied Files

     In order to determine if you have the necessary Novell-supplied files
     and versions, consult Appendix A which contains a complete list of
     necessary files listing the filename, size, and date. Appendix A also
     lists where these files can be obtained from NetWire. These new
     NetWare shell and utilities software are not exclusively for the
     operation of Windows, but these are the only NetWare shell version and
     requisite utilities that will properly operate with Windows 3.0. The
     latest version of the NetWare shell is v3.01e.

     : Novell-Supplied Windows Files

     : Novell-Supplied Windows Files

Special Notes - Novell Files

     Special care must be made in regards to the BINDFIX utility. Running
     prior versions of BINDFIX with the newer NetWare shells can create
     problems. Before using BINDFIX with the new NetWare shells, please
     read Appendix B, which includes the Novell Technical bulletins 255 and
     256. These bulletins cover BINDFIX problems, resolutions and the
     latest program version listing.

     It is also recommended that if you use TBMI.COM you should remove
     VIPX.386 (which is explained in the Windows Supplied Files section
     below) from your system. In order to do this you must edit the
     SYSTEM.INI file (explained in the Windows/NetWare Configuration Files
     section later in this document), to remove the automatic loading of
     VIPX.386.

Windows-Supplied Files

     Except where noted, the following files ship with the Windows 3.0
     distribution diskettes.

     : Windows-Supplied NetWare Files

Installation

     Prior to installing any software on a network server, it is important
     that all licensing issues be handled, as required by the software
     manufacturer. Please consult Microsoft licensing material, to
     determine the necessary procedure for correct licensing of Windows on
     a network.

     The bulk of this installation section will cover Windows installation
     for shared server access, with just minimal workstation Windows user
     files. If it your desire to install full copies of Windows locally for
     each NetWare workstation, you can skip the following sections until
     Startup Considerations.

     The basic steps necessary to installing Windows on a NetWare network
     are simple.

     : Windows Netware Installation

     The remainder of this section will go into more depth on each one of
     these steps, as well as explain certain startup and runtime
     considerations for running Windows on a NetWare network.

Setup NetWare Workstations and Servers

     Prior to installing Windows on the network, it is important that all
     workstations have the correct NetWare shells. This includes correct
     versions of IPX.COM and either of the three shell software components,
     NETx.COM, EMSNETx.EXE, or XMSNETx.EXE. As stated previously, it is
     recommended that if there is a choice between using one of the two
     upper memory shells, EMS or XMS, it is recommended to use the XMSNET
     shell. This is because Windows utilizes XMS, and not EMS memory, in
     Standard and 386 Enhanced mode.

     After the NetWare workstations have had the proper shells loaded on
     them you need to have all NetWare servers updated with the proper
     version of NetWare utilities. Take special care with the BINDFIX
     utility. Prior to running BINDFIX with the new NetWare shells, please
     read the Technical Bulletins located in Appendix B.

     If you are unsure whether you have the correct files or not, Appendix
     A contains a complete list of the necessary NetWare utility and shell
     files, listing the filename, size, and date. Appendix A also describes
     where on NetWire these files can be obtained.

     After all workstations and servers have been updated the next step is
     to configure the Windows software on the server.

Setup Windows Shared Files

     The first step in doing this is to create a Windows shared directory
     on the server. It is from this directory that each users' specific
     version of Windows will be built. In order to do this you only need to
     use the Microsoft supplied utility EXPAND.EXE to uncompress the
     compressed Windows files and copy them to a single directory on the
     server.

     The batch file documented in the Microsoft Windows User's Guide on
     page 553, can accomplish this is as follows:

     : EXPALL.BAT

     After copying the program EXPAND.EXE and the newly created batch file
     EXPALL.BAT to the F:\WINDOWS directory, you can then insert the first
     Windows diskette in drive A and run the EXPALL batch file.

     Simply repeat this step for all the supplied Windows diskettes. Once
     all files have been expanded you can rename all of the Windows device
     drivers from *.SY$ to *.SYS if you wish. (Although the SETUP program
     will do this for you as it copies the required device drivers to the
     user's Windows directory, when configuring each workstation). The last
     step should be to flag all files as shareable read only (SRO).

     Some notes regarding the EXPAND program. If you notice the structure
     of the above batch file you will notice that the batch file will run
     the EXPAND program singly against each file on the diskette, rather
     than to try to expand them en masse one right after another. This is
     done for a reason. If you choose to simply issue a command like the
     following:

     expand a:*.* f:\windows

     You will not be successful. The first difficulty is that EXPAND does
     not give the user status as to what files it is uncompressing, nor how
     far along it is in uncompressing the file. While that is merely
     annoying, this combined with the second problem, could lead you to
     think that all files were processed, when in fact they weren't.

     This is because the EXPAND.EXE program will process files on the
     diskette in directory order until all files are processed, or until it
     comes upon a file that is not compressed. If it does find an
     uncompressed file, it will stop and display a message saying that this
     file is not compressed. Unfortunately it will also stop processing the
     files on the diskette. This could leave some files, in directory order
     after the uncompressed file, that were not uncompressed and copied to
     the server directory. Currently with Windows 3.0 the only uncompressed
     files are SETUP.EXE, EXPAND.EXE, SETUP.INF and TOSHWIN.VCD.

Setup Windows User Files

     Once you have setup the shared Windows directory on the server, you
     then need to configure the workstations. The first step is to run the
     SETUP program for each workstation. In order to install a network
     workstation set of Windows files, you need to run SETUP with the /N
     parameter. This instructs SETUP that this is a network workstation,
     and that the only files necessary to copy, will be the ones specific
     to this workstation.

     SETUP will then ask you where the personal Windows files will be
     located. Depending on your configuration you may elect to store these
     files in the user's personal directory on the file server, or on a
     local disk.

     If you generate a SETUP error that says "Cannot create WIN.COM", this
     usually indicates you ran SETUP /N with Windows files that have not
     been uncompressed. In order to fix this, uncompress all the Windows
     files with the EXPAND.EXE program and run SETUP /N again.

     One of the choices that is given the user during the installation of
     Windows, is to build the Application Groups. If you choose to do this,
     and you click yes to the All Drives option, Windows will search all
     the attached drives starting at the root directory for any application
     that SETUP knows about. (The information on what applications Windows
     knows about is located in the SETUP.INF file) It will then build the
     appropriate groups, based upon what applications it found.

     A problem here is that this utility will search all drive maps
     beginning at the root level, which, unless you are using the MAP ROOT
     option of the MAP command, would mean that the program will search and
     tag the same program files once for each drive map, that was mapped to
     the same volume. This increases the time the utility takes to run, as
     well as clutters up the final display of found programs.

     A better strategy for configuring applications is to MAP ROOT a drive
     map to the highest point in the directory tree that you want the
     installation program to look through. Then just select that drive from
     the dialog box. This would obviously have to be done prior to entering
     the SETUP program.

     If you did not MAP ROOT the appropriate drive map prior to entering
     SETUP, you can just cancel this choice and run this same utility from
     inside Windows. This is done from the Windows Setup " Options " Set Up
     Applications menu.

     Fig. shows the files that SETUP will create and/or copy to the Windows
     user's personal directory. In addition to those listed, if the mouse
     used is a Microsoft or compatible one, SETUP will also copy MOUSE.SYS
     to the user's personal directory.

     : Windows Network User Files

Startup Considerations

     The following sections will deal with some startup considerations
     regarding running Windows on a NetWare workstation. These
     considerations are memory management, drive caching, Windows swap
     files, and network login issues.

Memory Management

     One of the SETUP program choices involves the changing of your
     AUTOEXEC.BAT and CONFIG.SYS files. If the user files are being
     installed in a network directory, SETUP will create a AUTOEXEC.BAT and
     a CONFIG.SYS which will contain recommendations for how to configure
     the workstation's AUTOEXEC.BAT and CONFIG.SYS file, but it will copy
     those files into the selected network directory. If you are installing
     these files on a local drive, SETUP will in fact offer and then change
     these files for you. The AUTOEXEC.BAT changes are nothing more than
     including the new personal Windows directory in the PATH statement.

     However, recommended changes to the CONFIG.SYS will usually have more
     affect on your system. SETUP will always want to install HIMEM.SYS and
     SMARTDRV.SYS into your CONFIG.SYS file. This will sometimes mean
     replacing current memory managers already installed in your
     CONFIG.SYS. (In fact there is a list of memory managers in the
     SETUP.INF file that Windows specifically looks to remove from
     CONFIG.SYS files due to the fact that they conflict with HIMEM.SYS.)

     Before accepting these recommendations it is important to consider the
     following. The only memory manager that is required to run Windows in
     two of its three modes, is an XMS compatible one, version 2.0 or
     higher. Loading HIMEM.SYS will limit what further memory management
     you will be able to do. For example, HIMEM.SYS does not allow you to
     make use of the High RAM (sometimes referred to as Upper or Adapter
     RAM) area between 640KB and 1024KB in the PC memory map, for loading
     TSRs or other drivers. Some third party products do provide
     alternative XMS solutions.

     Currently Quarterdeck is shipping a combination Expanded Memory, XMS
     Extended Memory, and High RAM memory manager in its QEMM386 product.
     If you are currently using the 5.11 version of this driver, you do not
     need to load Microsoft's HIMEM.SYS. Qualitas, and All Computer, Inc.,
     among others, also ship products which contain XMS 2.0 or higher,
     compatible memory management.

     If you want to use an XMS only driver like Microsoft's HIMEM.SYS, and
     you want to utilize expanded memory for DOS applications, you must
     take care not to load memory managers that will conflict with one
     another. Microsoft's EMM386.SYS (on 80386 equipped PCs only) and its
     HIMEM.SYS can be loaded together.

     Also, in regards to expanded memory and Windows, Windows and Windows
     applications only use expanded memory in real mode. In Standard and in
     386 enhanced mode, Windows and Windows application use extended
     memory, via the XMS specification. Additionally, running in 386
     Enhanced mode, Windows provides expanded memory support for non-
     Windows applications as part of Windows. No additional expanded memory
     manager is required.

     Looking at your AUTOEXEC.BAT and CONFIG.SYS, as well as your user's
     needs you should consider the following in .

     : Memory Considerations

SMARTDRV.SYS

     SMARTDRV.SYS is a Windows "aware" drive caching program. Depending
     upon how much memory is installed in your system, the SETUP program
     can be liberal in the amounts of memory that it recommends be
     allocated, for this program. Experimenting to see if there are
     significant performances changes using lesser amounts of memory, is
     advisable since the additional free memory will become useful, as you
     begin to use bigger Windows programs. If you already use another drive
     caching program, testing both caching programs for performance in and
     out of the Windows environment can be beneficial in determining the
     correct caching program to use. If you do not have a local hard drive
     from which you are performing Windows work, do not use a drive caching
     program. SMARTDRV will not cache network drives.

Swap Files

     Windows will use temporary swap files for various operations such as
     spooled output files from the Windows Print Manager. The location of
     the temporary swap files will default to the location of the Windows
     startup files, unless explicitly told to swap elsewhere via the TEMP
     environment variable (or in 386 Enhanced mode, the PagingDrive=
     SYSTEM.INI setting). As in the following:

     SET TEMP=C:\TEMP

     This would use the directory TEMP on this workstation's drive C. Using
     network drives to perform this swapping activity carries certain
     penalties. Swap files that are swapped to network disks, not only
     creates more work load for the server, it creates more traffic over
     the network. Additionally, when you are placing swap files on an
     Advanced NetWare 2.15 server, there will be a marked increase in
     Windows load time. This is especially true when running Windows in 386
     Enhanced mode.

     The problem is that when a swap file is created, Windows will allocate
     a chunk of disk space for the swap file, prior to using it. When this
     is done on a NetWare server, NetWare will allocate the requested disk
     space, but prior to allowing the user access the file, NetWare will
     also zero fill the allocated file space. This is a NetWare operating
     system security measure and cannot be turned off.

     The solution for problems resulting from using the network for
     swapfile location is to simply move the swapfiles to local devices.
     While a local hard drive is a good place for swap files, a local
     floppy disk drive should not be considered.

     RAM disks are speedy places for swap files, however, it is recommended
     that you have a minimum size RAM disk of 2MB, for any configuration.
     The memory set aside for the RAM disk must always be considered
     against having this memory available to Windows applications. You also
     need to load a RAM disk device driver that will not conflict with any
     loaded memory managers. If you have further questions regarding RAM
     disks and Windows you can consult the Microsoft Windows User's Guide
     pages 530-535.

     In 386 Enhanced mode you can specify a location for a permanent
     swapfile as opposed to temporary, on a local DOS device. This cannot
     be setup on a network drive at all. This is also outlined in the
     Microsoft Windows User's Guide on pages 520-530.

Logging in to the Network

     It is recommended that users first login to their servers and then run
     Windows. While you are running Windows, you will be able to attach and
     detach servers, print queues, and drive maps all from within the
     Windows desktop.

     Windows documentation suggests that if your network driver supports
     login and logouts from the Network Utility menu, then it is perfectly
     acceptable to do so. The Windows NetWare driver explicitly does not
     support this feature, at this time. In order to maintain integrity
     among the separate DOS and Windows sessions, you should not login or
     logout of a server from any DOS session.

     Finally both the user's personal directory, and the shared server
     Windows directory, should be in the user's path (assigned as NetWare
     search drives). It is important that the user's personal directory
     precede the main Windows directory in the path. SETUP will suggest
     that, as a PATH statement in your AUTOEXEC.BAT. Since you will always
     be logging into your server before running Windows, these can be set
     up as search drives as opposed to set up in the PATH statement.

Windows/NetWare Configuration Files

     Prior to logging into your network and running Windows there are some
     settings in certain configuration files which should be understood.
     These configuration settings reside in four files. The NET.CFG file,
     the WIN.INI file, the SYSTEM.INI file and the NETWARE.INI file. The
     following section will look in depth at the necessary Windows, NetWare
     and network settings contained in these files.

     All configuration files are standard ASCII files and can be edited
     with any text editor, like Windows Notepad. It is important that if
     they are edited, the files be saved as standard ASCII text. Saving
     them in word processor's document format would render them unusable to
     Windows and/or NetWare. It is also recommended that when changing any
     configuration lines in the Windows .INI files that you first comment
     the original line out by using a semicolon at the front of the line,
     and then add the changed configuration line. For example changing the
     NetHeapSize in the SYSTEM.INI file would look like that pictured in .

     : Changing .INI Settings

SYSEDIT Utility

     There is an undocumented Windows utility that can aid in viewing and
     editing certain startup files, called SYSEDIT. When this utility is
     run from the Windows desktop it opens four windows, and calls up a
     separate file in each window. The four files are WIN.INI, SYSTEM.INI,
     the workstation's AUTOEXEC.BAT, and CONFIG.SYS. These files can then
     be edited and saved with the SYSEDIT utility.

     SYSEDIT is installed in the user's SYSTEM directory when a full
     version of Windows is installed, or it is located in the shared server
     directory in the case of network installations of Windows. SYSEDIT can
     be installed in any program group by simply following Windows
     procedure for doing so.

SHELL.CFG

     NET.CFG is a configuration file that can either replace the SHELL.CFG
     or be used along with it. Some settings can only be used in the
     NET.CFG file. Later on in this Application Note, some of the TBMI
     settings, will be an example of these. However, for this discussion
     all of the following settings can go in either configuration file. In
     order to determine which configuration files you should be using, and
     for a fuller description of the SHELL.CFG and NET.CFG configuration
     files, you can consult Appendix A and E from the NetWare 386 3.1
     Installation Manual.

     There are several NET.CFG settings that might be useful for running
     the Windows environment. The first concerns the way in which the
     NetWare shell handles the directory entries (.) and (..). To DOS, the
     (.) and the (..) represent the current and the previous directories in
     the directory structure, respectively. When using certain types of
     programs NetWare will not usually show these as directory entries.
     This can cause some problems for File Open dialog boxes in Windows
     applications. (It would not be possible to double click on the (..)
     entry to move one directory up in the path.) This is solved with the
     following NET.CFG setting:

SHOW DOTS=ON

     This setting will insure that the shell will show the (.) and (..), as
     the current and previous directories to all applications. However, in
     order to use this option you must update the MAKEUSER and BINDFIX
     NetWare utilities to be the same or newer than those listed in
     Appendix A. Additionally, please consult the Novell Technical
     Bulletins in Appendix B regarding the BINDFIX utility.

     NetWare's default of 40 open files per workstation, is also something
     that user's might need to increase. Microsoft recommends increasing
     that to 60 open files with the NET.CFG setting of:

FILE HANDLES=60

     This should be consistent with the FILES statement in your CONFIG.SYS
     file (FILES in the CONFIG.SYS file and FILE HANDLES in the NET.CFG
     should always be consistent). This means that this user would need a
     FILES=60 statement in their CONFIG.SYS file.

     Applications that use NetBIOS communications can sometimes require
     specific timing on NetBIOS broadcasts, (such is the case with 3270
     terminal emulation software). Use the following values if there is a
     problem with NetBIOS sessions hanging:

     NETBIOS BROADCAST COUNT=5

     NETBIOS BROADCAST DELAY=10

WIN.INI

     WIN.INI is the Windows Initialization file that primarily contains
     settings that allow a user to alter or customize their Windows
     environment or customize their Windows applications. This file is used
     to keep track of user and Windows application defaults as well as
     define the standard screen fonts which are display dependent.

     There are basically nine sections to the WIN.INI file. They are shown
     in .

     : WIN.INI Sections

     The only specific change that Windows SETUP makes to the WIN.INI file,
     when configuring a NetWare workstation, is to specify a program to
     load upon Windows startup, in the [windows] section. The line that is
     added by SETUP is:

     [windows]

     load=nwpopup.exe

     NWPOPUP.EXE is the program that translates NetWare message broadcasts
     into Windows format which is then displayed on the Windows desktop.
     One thing to remember about NWPOPUP.EXE is that even though you never
     see an indication that it is running or loaded, it is a running
     Windows application. This is important when running the Windows
     Swapfile application which must be run only when no other applications
     are running. (See pages 520-530 in the Microsoft Windows User's Guide
     regarding Swapfile.)

     In order to disable the NWPOPUP.EXE program you can either remove it
     from the load= line in the WIN.INI file, or you may Disable Broadcast
     Messages from the Network option of the Windows Control Panel.

SYSTEM.INI

     The SYSTEM.INI is the second important Windows initialization file.
     This file is used to define and customize Windows for your hardware,
     or system configuration.

     It is extremely important that you remember that changing settings
     incorrectly in the SYSTEM.INI file can result in a Windows system that
     will not run. Before making changes, consult the appropriate Microsoft
     manuals and/or SYSINI.TXT files. Also, make changes by commenting out
     the original line with a semicolon at the beginning of the line, and
     then repeating the entire line after the original, with your new
     settings. This way you can change values and still have the original
     setting listed in the file.

     There are six basic sections in the SYSTEM.INI file. They are:

     : SYSTEM.INI Sections

     (In any of the Windows configuration files, if you want to enable a
     Boolean setting, you can enter: true, yes, on, or 1. If you want the
     Boolean setting to be disabled, you can enter: false, no, off, or 0.)

     Following, is a more in-depth discussion of the NetWare section
     settings.

     [NetWare]

     RestoreDrives=<Boolean>

     Normally when you exit Windows, all of your drive mappings are
     restored to the way they were before you started Windows, and all
     changes you made inside Windows are lost. RestoreDrives is the setting
     that determines this. The default condition is true, which means all
     drive maps are restored to their previous state before entering
     Windows. This means any drive maps made while within Windows will be
     lost upon exiting.  If you set the RestoreDrives value to false, the
     mappings you made inside Windows will remain when you exit Windows.

     [NetWare]

     NWShareHandles=<Boolean>

     As stated previously, in Windows 386 Enhanced mode each DOS session
     that gets started whether as a DOS command prompt or as a non-Windows
     applications, is created using the virtual 8086 mode of the 80386.
     This creates a separate virtual machine for each session.

     Also each virtual machine you start in Windows gains its own set of
     drive mappings. It copies this information from the global memory of
     the System VM. However, the default method for doing this is to copy
     this drive mapping information into the local memory of the specific
     virtual machine. This means that changes to one virtual machines drive
     maps are not reflected throughout all virtual machines. Mapping
     changes are local to each VM.

     NWShareHandles allows you the option of maintaining the drive map
     information in the global memory of the System VM. This would mean
     that changes in any VM's drive maps would be instantly reflected in
     all other VMs.

     Other SYSTEM.INI settings that can affect network operations are
     listed in and . Appendix C provides detail on each of these setting as
     described from the Windows supplied text files SYSINI.TXT,
     SYSINI2.TXT, and SYSINI3.TXT. This detailed description explains each
     setting in regards to what it does and how it can affect network
     operations. Additionally, default, changing and suggested values, are
     given for each setting, where applicable.

     : SYSTEM.INI Network Settings

     : SYSTEM.INI Network Settings (continued)

NETWARE.INI

     This third Windows initialization file, is exclusively created for
     NetWare users. This file is not on any NetWare or Windows distribution
     disk, but instead is created by the NetWare Windows driver,
     NETWARE.DRV, whenever the driver cannot find a current copy of the
     file. The NETWARE.INI file contains three kinds of information.

     : NETWARE.INI

     The first kind of information, is information regarding the utilities
     available to the Windows user through the network driver. In this case
     shows the standard NETWARE.INI as created by NETWARE.DRV.

     Using the syntax UTILITY=NAME, this shows that the NetWare Windows
     driver provides four utilities. The ability to attach to a server,
     detach from a server, to enable receiving messages and disable
     receiving them. Note that the syntax is composed of a description of
     the utility, which shows up as the choice in the Control Panel "
     Network list box, an equal sign, and an executable command name. The <
     character preceding the command name, signifies an internal command,
     which is internal to the NetWare driver.

     Fig. shows the Windows NetWare network utilities main menu, which is
     accessible from the Control Panel " Network selection.

     : Windows NetWare Network Utilities

     The second type of information available in the NETWARE.INI file is
     environment settings. The current options available are listed in .
     These settings must go under the heading of [MSW30-PrtQ] as shown.

     : NETWARE.INI Environment Settings

     These environment settings control how the Windows Print Manager keeps
     track of, and displays information about print jobs. MaxJobs is a
     setting which controls how many print jobs are visible in the Windows
     Print Manager queue. MaxJobs has a range 1-250 with a default setting
     of 50. MaxBufSize is the companion setting to MaxJobs. This setting
     configures the size of the buffer in bytes, that Windows will use to
     store information about print jobs in the Print Manager queue. The
     MaxBufSize range is 3500-30000 with 3500 being the default setting.
     UpdateSeconds is simply the time interval that the Print Manager
     automatically checks and updates the Print Manager queue.
     UpdateSeconds range is 1-65 with the default at 30. This function can
     still be done at any time manually, via the Print Manager menus.

     The third kind of information that can be contained in NETWARE.INI is
     user again user configurable. This can be other programs which need to
     be accessed from the Control Panel " Network menu. The following are
     some examples of lines that can be added:

     : NETWARE.INI External Programs

     Fig. shows the Windows NetWare network utilities drop down selection
     menu, which is accessible from the Control Panel " Network selection
     after selecting the down arrow button. This drop down menu shows the
     four internal NetWare commands from the NETWARE.INI file. This menu
     also shows the external commands listed in the  sample, NETWARE.INI
     file.

     : Windows NetWare Network Utilities

Runtime Considerations

     The following are some runtime considerations for running Windows on a
     NetWare workstation. The first is something mentioned previously in
     this Application Note, and it regards the use of the newly added, MAP
     ROOT ability. The second run time consideration is in regards to
     integrating Windows printing output with NetWare print spooling.

Map Root

     Most users are familiar with the fact that drive mappings in NetWare,
     prior to the addition of the MAP ROOT command, would map a drive
     letter to a drive/directory combination beginning at the root level of
     the target volume. This means that when you created a drive map like
     the following:

     MAP F:=FS1/SYS:USERS/GUEST

     You would assign drive letter F: to point to the directory GUEST a
     subdirectory of USERS, which exists at the root level of the SYS
     volume on server FS1. If you then changed to F: and executed the DOS
     command to change a directory to the next level up, CD .., you would
     change your drive F: pointer to point to the next directory level up,
     in this case the directory USERS.

     As a result, a problem that is created, is with applications that
     ignore default directories for a drive letter. In particular, the
     Windows File Manager resets the default directory for a drive letter
     to the root level. Using the above example the File Manager would
     reset drive F: to point to the root level of volume SYS on server FS1.
     Another example where this happens is when Windows scans the connected
     drive letters for the purpose of building application groups. This is
     done during the SETUP program, or once in Windows, by running the
     Windows Setup " Options " Set Up Applications utility.

     Drive  A:   maps to a local disk.

     Drive  B:   maps to a local disk.

     Drive  C:   maps to a local disk.

     Drive  D:   maps to a local disk.

     Drive  E:   maps to a local disk.

     Drive  F: = FS1\SYS:  \USERS\BILL

     Drive  G: = FS1\SYS:  \USERS\BILL\WP

     -----

     SEARCH1:  = Z:. FS1\SYS:  \PROGRAMS

     SEARCH2:  = Y:. FS1\SYS:  \PROGRAMS\WIN

     SEARCH3:  = X:. FS1\SYS:  \PROGRAMS\WP51

     SEARCH4:  = W:. FS1\SYS:  \PUBLIC

     Given the following drive maps as an example, running the Windows
     Setup " Options " Set Up Applications utility and selecting All Drives
     to scan, would cause the utility to scan the SYS: volume and all
     subdirectories (which you had sufficient privileges to scan) six
     separate times. This would also build a list of applications that
     Windows "knows" about, six times larger than actual, since each
     location of the application file would be defined by the drive letter
     identifier.

     In order to force applications not to reset default directories on
     drive letters, the updated MAP.EXE program and NetWare shells (consult
     Appendix A for listings of these files) were modified to allow the use
     of fake roots. Reissuing the previous example drive mapping with the
     MAP ROOT command looks like the following:

     MAP ROOT F:=FS1/SYS:USERS/GUEST

     This would assign the drive pointer to the same volume/subdirectory
     location as in the previous MAP command, however this time when you
     changed to the F: drive and issued the DOS command, CD.., the drive
     map and directory location would not change. To all applications and
     DOS, this drive letter would look like a root directory. The
     difference between both types of drive maps can be noted when you
     display your drive maps with the MAP command. The following is an
     example of drive maps and search drive maps issued by both the MAP and
     MAP ROOT commands.

MAP Drives

     Drive  F: = MS1\SYS:USERS\BILL\WP

     SEARCH1:  = Z:. [MS1\SYS:  \USERS\BILL\WIN3]

MAP ROOT Drives

     Drive  F: = MS1\SYS:USERS\BILL\WP  \

     SEARCH1:  = Z:. [MS1\SYS:USERS\BILL\WIN3  \]

     Since the Windows File Manager program resets drive identifiers to
     their root level, at the minimum it is recommended that you use MAP
     ROOT drive mappings for all search drives and for regular drive maps
     that are used consistently. One issue to watch out for when you begin
     using MAP ROOT is applications that have relied on being able to
     explicitly state a complete path based on a previous drive letter
     mapping.

NetWare Printing

     Windows is best described as an operating environment. This is because
     Windows controls some aspects of the PC's operating environment that
     were previously controlled by the operating system. The handling of
     output devices is one of those areas.

     The NetWare shell is considered an operating system extension because
     it extends normal DOS functions across a network. As in the case of
     spooled printed output. The situation this creates is one in where the
     way in which Windows hands off the printed output must be integrated
     with the way NetWare spools the output to the shared printers. Whether
     print jobs are defined in PRINTCON for all users, or whether all users
     use separate CAPTURE or NPRINT statements to send output off to
     network printers, there are four options that need to be set in order
     things to work right. These are shown in .

     : NetWare Printcon Windows Printing Options

     The reasons for these settings are as follows. First, Windows always
     sends a form feed after a print job in much the same way as some
     standard DOS applications do, so this feature can be turned off for
     NetWare.

     NetWare will perform tab expansion, (converting a tab character to 8
     blank spaces), for output when told to do so and it is in fact the
     default method for handling printed output. However, almost all
     Windows output is in bitmap form. The problem is that the byte values
     resembling tab characters can occur randomly in any bitmap output.
     With tab expansion on, this would cause the print job to be expanded
     with blank spaces wherever NetWare encountered a byte value for a tab.
     At the printer this would create seemingly random blank spaces in the
     output. For this reason it is necessary to tell NetWare to perform no
     tab expansion. This is done by specifying the file contents as Byte
     Stream in print job configurations and by using the NT switch with
     CAPTURE and NPRINT.

     Turning off the automatic endcap and the timeout is necessary due to
     the fact that Windows can exceed the NetWare timeout periods in the
     production of some print jobs. This problem would be shown by
     receiving partial print jobs at the printer.

     Other NetWare printing options are not necessary for Windows printing.

     An example of the CAPTURE and NPRINT commands that contains all the
     necessary switches would be the following:

     CAPTURE NFF NT NA TI=0

     NPRINT filespec NFF NT NA TI=0

NetWare Non-Windows Application Support

     As mentioned earlier in this Application Note, Windows handles non-
     Windows Applications by either task switching these sessions in and
     out of conventional RAM space in Real and Standard mode, or by running
     virtual 8086 sessions in 386 Enhanced mode.

     A problem was recognized in regards to applications that accessed the
     network as they were run from within Windows. Novell has since added
     improved support for non-Windows applications running under both
     Standard and 386 Enhanced mode. The problem that was corrected was
     first recognized under the task switched environment of Standard mode.

     As mentioned in the opening sections of this Application Note, when
     Windows in Standard mode performs its task switching it maintains
     global memory which is not switched out of the lower 640KB of RAM, and
     which contains system information such as the COMMAND.COM processor,
     Terminate and Stay Resident (TSR) programs, and network or other
     drivers. This global memory is used as system resources for each
     successive switched session.

     Operationally this provides a single global memory segment that is
     never swapped out of the lower 640KB of RAM, and separate switchable
     local memory segments (one for each session running) that are swapped
     in and out of the lower 640KB of RAM.

     Running most applications on a NetWare LAN in this environment, would
     not usually cause a problem. This is because the NetWare shell that is
     loaded, intercepts all calls a DOS application makes and then makes
     the determination whether to pass it along to the network or to the
     local PC. The very same network shell is one of the pieces of system
     information located in the Windows global memory. Because this memory
     never gets switched out of conventional RAM, the shell can correctly
     buffer and coordinate network communications among the various
     switched sessions.

     However there are a number of non-Windows network applications that
     communicate with the network by directly issuing IPX/SPX calls,
     forgoing the NetWare shell. In the aforementioned task switched
     environment this would create a situation where an application in
     local memory would make calls directly to the IPX/SPX driver located
     in global memory with the danger that before the communications can
     complete, the current local memory contents would be switched for
     another application. When this happens the IPX/SPX driver will lose
     contact with the calling application and not be able to use its data
     for network communications.

     It is for this type of non-Windows applications that the Task switched
     Buffer Manager for IPX/SPX (TBMI) was developed.

Task switched Buffer Manager for IPX/SPX (TBMI)

     The Task switched Buffer Manager for IPX/SPX (TBMI) is a combination
     of two programs that serve to buffer and synchronize direct IPX/SPX
     network communications between the network and applications that
     operate in a task switching environment. Such as Windows in Standard
     mode.

     In order to accomplish this, TBMI is loaded prior to running Windows.
     By doing this, TBMI installs itself in what becomes the global memory
     segment for Windows. Situated there TBMI intercepts calls to IPX/SPX
     from applications running in the local memory segments. TBMI then
     buffers each separate IPX/SPX communications for each calling
     application. The second portion of TBMI is loaded with each non-
     Windows application (that communicates directly with IPX/SPX) and is
     called TASKID. This memory resident program passes task identification
     information to TBMI which allows TBMI to map each network
     communication with the correct calling application. Both TBMI and
     TASKID components are necessary for proper synchronization of network
     communications to take place.

     TBMI is not needed for both Windows applications and for non-Windows
     applications that utilize the NetWare shell for network
     communications. Windows applications utilize a different mechanism to
     access IPX/SPX network communications and non-Windows applications
     that utilize the NetWare shell for network communications are serviced
     similar TBMI functions as part of the shell's duty. Lastly, there is
     no need for TBMI in any type of non-Windows application session if you
     will not be switching between sessions.

     Finally if your are unsure as to whether or not you need to use TBMI
     or not, the TBMI.DOC file included with the TBMI files states the
     following.

     "If you are not sure that your applications make direct call to
     IPX/SPX, go ahead and run TBMI. It will only affect operations by
     using up a small amount of memory, After running the application for a
     period of time, enter the command TBMI /D and look at the count values
     associated with the fields `Far Call Usage' and `Old Int Usage'. These
     values specifies how many times TBMI has actually received calls. If
     these values are zero, then your application is not using TBMI and you
     may safely run the application without it."

     The following is the statistical output from issuing the TBMI /D
     command.

     Task Switched Buffer Manager for IPX/SPX - version 1.0

     (C) Copyright 1990, Novell Inc.  All rights reserved

     TBMI is currently resident

     Interrupt 2Fh hooked

     Interrupt 64h hooked

     Interrupt 7Ah hooked

     TBMI Buffers in use           :    0000

     TBMI Max buffers used         :    0000

     TBMI Unavail buffer count     :    0000

     TBMI Old int usage count      :    0000 u (This value)

     TBMI Far call usage count     :    0000 u (And this value)

     TBMI Next ID number avail     :    0001

     TBMI Most recent ID number    :    0000

     TBMI Outstanding ID count     :    0000

     TBMI Configured ECBs          :    0014

     TBMI Configured Data ECBs     :    003C

     TBMI Configured sockets       :    0014

     TBMI Current sockets          :    0000

TBMI.COM

     The following are the instructions and configuration parameters for
     running TBMI, from the TBMI.DOC file included with the program files.

     This program provides the data buffers needed to virtualize the IPX
     and SPX requests made from applications running in a DOS session.
     Because these buffers need to be allocated before Windows starts, TBMI
     must be run before starting Windows.  shows the valid TBMI command
     line parameters.

     : TBMI Command Line Parameters

     This program reads configuration information from a configuration file
     in the current directory. One parameter is entered on each line in the
     configuration file. This file's name is NET.CFG by default; a
     different name can be specified using the /C parameter on the command
     line.  shows the valid configuration file parameters.

     : TBMI NET.CFG Settings

TASKID.COM

     The TASKID.COM program must be run in each DOS session before an
     application is started in that session that requires direct IPX or SPX
     support. This provides the two-way communication needed for
     virtualizing asynchronous events in the DOS session. This program
     provides a unique ID to TBMI which is used in virtualizing IPX and SPX
     calls.

     Fig. shows the valid command line parameters.

     : TASKID Command Line Parameters

     It is recommended that you unload TASKID from the DOS session's memory
     before closing the session. Do not unload TASKID before task
     switching.

TBMI Usage

     Do the following to start TBMI.

     1.   Start TBMI by entering the command "TBMI" on the command line,
          followed by optional command line parameters listed above.

     2.   Start Windows normally.

     3.   Start a DOS session by clicking on the DOS Prompt icon. At the
          new DOS prompt, enter the command "TASKID" followed by optional
          command line parameters listed above.

     4.   Repeat step #3 for each DOS prompt you open before running an
          application from that prompt.

     Before closing a DOS session with the EXIT command, remember to first
     type "TASKID /U" to unload TBMI from that session. Failure to unload
     TASKID from a session's memory before closing the session may result
     in loss of data buffers and machine hanging. It is not necessary to
     unload TBMI after exiting Windows, but you may wish to do so to free
     up memory.

     TBMI could be included in a batch file starting Windows to insure that
     it is always started before Windows and unloaded afterwards. For
     example, the batch file WIN.BAT could include the following:

     TBMI

     WIN

     TBMI /U

     A batch file can also be created to automatically load and unload
     TASKID when starting and exiting a DOS session. The batch file must be
     specified instead of COMMAND.COM in either the Properties box or the
     PIF file of the DOS Prompt icon. The batch file should include the
     following lines:

     TASKID

     COMMAND

     TASKID /U

Windows 386 Enhanced Mode and TBMI

     It is recommended that once TBMI is installed on your system that you
     remove the automatic loading of VIPX.386 as TBMI also replaces the
     functionality provided by the 386 Enhanced mode driver. This is done
     in the SYSTEM.INI file under the [386Enh] section, as shown in .

     : Removing VIPX.386

     NetWare Utility Program Information Files (PIF)

     The last issues in regards to running non-Windows applications from
     within Windows concerns NetWare utility programs. In keeping in line
     with Microsoft recommendations, Novell recommends setting up PIF files
     for running NetWare utilities. This provides the primary benefit of
     locking down system resources for use by the NetWare utilities.

     : NETWARE.PIF Standard Mode

     Fig. shows the suggested PIF settings for NetWare utilities as listed
     in the example NETWARE.PIF file for Windows in Standard mode.

     : NETWARE.PIF 386 Enhanced Mode Basic Settings

     Fig. shows the suggested basic PIF settings for NetWare utilities as
     listed in the example NETWARE.PIF file for Windows in 386 Enhanced
     mode.

     : NETWARE.PIF 386 Enhanced Mode Advanced Settings

     Finally,  shows the suggested advance PIF settings for NetWare
     utilities as listed in the example NETWARE.PIF file for Windows in 386
     Enhanced mode.

     For further information regarding PIF files consult the Microsoft
     Windows User's Guide pages 440-490.

Advanced Windows LAN Administration

     In setting up multiple Windows workstations, an issue that has been
     raised is in regards to setting up the Windows configuration files so
     that users might be able to login to the network and run Windows, all
     from various differently configured workstations. Windows does not
     lend itself easily to this, but with a little configuration it is
     possible to accomplish. In order to do this the Windows users' files
     must be located on network drives (which raises the issue of swap file
     locations but that's discussed elsewhere in this document). Also,
     changes need to be made to both how the SYSTEM.INI and the WIN.INI
     files are set up.

     Since the hardware configuration information is located in the
     SYSTEM.INI file it is necessary to maintain a common set of SYSTEM.INI
     files for either each workstation, or for each class of workstation.
     Then based upon a system variable at run time a batch file can copy
     the necessary SYSTEM.INI file to the user's Windows directory. The
     system variable used as an example here is SYS_TYPE.

     If the network is made up of distinct classes of workstations then
     environment variables could be used to identify each class. For
     example for all Compaq 386es with VGA displays could be assigned the
     environment variable:

     SET SYS_TYPE=CPQ386V

     For all IBM 286 PS/2s with VGA the environment variable could be:

     SET SYS_TYPE=IBMPS22V

     SYSTEM.INI files for each class of machine could be created by running
     SETUP on one of the machines and then copying the SYSTEM.INI file to
     the common SYSTEM.INI directory, and renaming based upon the system
     type. Such as CPQ386V.INI and IBMPS22V.INI.

     A Windows batch file could then consist of the following commands:

     @ECHO OFF

     COPY  F:\WINDOWS\SYSINI\%SYS_TYPE%.INI   F:\USERS\BILL\SYSTEM.INI

WIN

     However, in order for this to work properly the WIN.INI file, which
     maintains most of the application and environment specific information
     needs to have one section modified. That is that the WIN.INI files for
     all users should have all screen fonts installed for all possible
     monitor types.

     This is because the screen fonts section of the WIN.INI file is the
     only hardware dependent part of this file. This allows each user to
     maintain a unique WIN.INI file which would contain their own
     application specific and environment information regarding the user
     and application defaults used by Windows and Windows applications.

     shows what the [fonts] section of such a WIN.INI file might look like.
     This WIN.INI file would be configured for CGA, Hercules Monochrome
     (which uses the EGA fonts), EGA, and VGA displays.

     : WIN.INI Screen Fonts

     Additional advanced Windows LAN management topics are covered in the
     following publications:

     Graphic Facts About Networking with Windows. Automated Design Systems,
     Inc. 1988-1990.

     Saber LAN Setup Guide for Windows Version 1.0. Saber Software
     Corporation 1990.

Troubleshooting

     This section covers common problem areas and common technical support
     questions and answers. The first part provides a history of the
     NetWare DOS shell and the problems that have been corrected with the
     shell revisions. Following that will be a break down of other Windows
     / NetWare problems and solutions by category of problem. Some of these
     categories are initial setup, application, Windows, and NetWare
     problems.

     If after consulting this section you find you have problem that is not
     covered here you may pursue the problem with your local NetWare
     dealer. If you still cannot resolve the problem you can contact Novell
     Technical Support at 1-800-526-7937 (1-800-LAN-SWER). This service is
     a charge service.

NetWare DOS Shell History

     The following is a historical description of the problems and
     solutions to various NetWare DOS shell issues for the NetWare DOS
     Shell v3.01. This history file is included in the latest version of
     the NetWare DOS shell. This document is also updated with each
     subsequent release of the NetWare DOS shell.

     : NetWare Shell 3.01 Rev. A

     Loading SiteLock by Briteworks would fail, causing the DOS workstation
     to hang. This problem was corrected with the 3.01 rev B shell.

     : NetWare Shell 3.01 Rev. B

     Using the Preferred Server option caused the network response time to
     be functionally slower than if the user did not use this option. The
     3.01 rev C shell corrected this problem.

     When using DOS 4.0 with EMSNETx and XMSNETx shells the DOS directories
     would not display correctly under   Windows. This was corrected with
     the 3.01 rev C shell.

     The enhanced memory shells were not sending header information when
     using job configurations that included escape codes. For example, a
     job that should print landscape would print using the default mode
     (portrait).

     When printing to a captured LPT device an error message "Device not
     ready" would appear. A retry would allow the job to continue. The 3.01
     rev C shell corrected this problem.

     Fake roots were being deleted on paths with volume names before the
     path was determined valid such as CD PRN: would delete the fake root.
     This was fixed with the 3.01 rev C shell.

     On 286-based servers the Dynamic Memory Pool (DMP) 1 was not being
     released properly with the XMSNETx and EMSNETx shells causing the
     server to hang eventually. With the 3.01 rev C shell the memory is
     released when exiting the Windows DOS Prompt.

     : NetWare Shell 3.01 Rev. C

     The NetWare DOS Shells Rev. C was made available to NetWare Developers
     only. The NetWare DOS shells v3.01 rev D was released to all users and
     contains all the 3.01 rev C changes.

     : NetWare Shell 3.01 Rev. D

     When running the 3.01 rev D shell on a NetWare V2.15 or less operating
     system, external program execution (using the #) from the login script
     does not work unless the user has open privileges at the volume root.
     This has been corrected in the shells dated 9/18/90 or later.

     Nver will return Rev. C instead of Rev. D. This has been corrected in
     the shells dated 9/18/90 or later.

     : NetWare Shell 3.01 Rev. D

     When using the DOS 4.0 "TrueName" (undocumented DOS command) command
     invalid data was returned to the shell. This invalid data causes
     Emerald's System's backup to not function properly. The 3.01 rev E
     shell corrects this problem.

     Microsoft Link was reporting a scratched file error when linking a
     large number of files. This was corrected in 3.01 rev E of the NetWare
     DOS shell.

     Added support for VERSION.EXE utility. This support was not present in
     earlier releases of the shell.

     Corrected a problem with the rename function where the wrong error
     code would be returned to applications such as Platinum Accounting by
     Advanced Business Microsystems. This error was also exhibited with the
     NETGEN message: Cannot find DRVRDATA.DAT.

     Corrected a problem where the shell was not correctly maintaining the
     default server after logout when an X.25 bridge is used.

     On ELS NetWare servers you would get one less connection than the
     maximum when using remote boot. The 3.01 rev E shell corrected this
     problem allowing the user to get all connections to the server.

     Enabled file caching in EMSNETx and XMSNETx shells. File caching was
     not enabled in earlier releases of the enhanced memory shells. Also
     fixed a problem where these shells were passing an incorrect file
     server address to IPX. The error most commonly seen was "No response
     from server <servername>"

     Added the /? option to the command line which displays version and
     usage information.

     Added a feature in the 3.01 rev E shell that tells the user that a TSR
     is loaded when trying to unload the shell.

     : NetWare Shell 3.01 Rev. E

DOS Issues

     Problem:       DOS 4.0 and Windows Generic Problems

     Explanation:   Some problems seem to exist when running Windows and
                    using DOS 4.0 ANSI.SYS and SHARE.EXE.

     Solution:      Try removing ANSI.SYS from DOS startup files.

     Microsoft recommends in the NETWORKS.TXT file to try removing
     SHARE.EXE from DOS startup files. (Some versions of DOS 4.0 and DOS
     4.01 automatically load SHARE.EXE when using single drive sizes of
     greater than 32mb. To disable SHARE.EXE from loading you can rename
     the program file.)

NetWare Issues

     Problem:       SHGEN goes from A: to B: endlessly

     Explanation:   This is due to the fact that the SHGEN.EXE program will
                    look for one of two things when it runs. It will either
                    look to see if it being run from a diskette labeled
                    SHGEN-1 and if it is, it will proceed to look for all
                    the necessary files in the root level of this diskette.
                    (These would be the files from the DSWIN2.ZIP and the
                    IPX.OBJ from DSWIN1.ZIP archives) Or SHGEN.EXE will
                    look for a subdirectory at the default directory level
                    called SHGEN-1 for the necessary files and optionally
                    look for directories labeled LAN_DRV_.??? for LAN
                    driver files.

     Solution:      Put all the files from DSWIN2.ZIP and the IPX.OBJ from
                    DSWIN1.ZIP, on a floppy labeled SHGEN-1 and then run
                    SHGEN.EXE. Or create a subdirectory called SHGEN-1 and
                    put all the files from DSWIN2.ZIP except SHGEN.EXE in
                    that directory along with the IPX.OBJ from DSWIN1.ZIP.

     Problem:       Can't figure out which NetWare diskettes the DSWIN
                    files go on

     Solution:      The files should be put on the working copies of your
                    NetWare diskettes as follows:

                    DSWIN1.ZIP                         SHGEN-1

                    DSWIN2.ZIP                         SHGEN-2

                    DSWIN3.ZIP                         UTIL-1

                    DSWIN4.ZIP                         UTIL-2

     Problem:       Novell Menu System returns "Cannot find beginning of
                    menu file" type error message when exiting Windows

     Explanation:   Windows expects to be the only menu system and not be
                    run from another menuing system.

     Solution:      The Novell Menu system can be used if the menu utility
                    and overlays are copied to a local drive, and executed
                    from there. Alternatively several third party menu
                    utility vendors will operate correctly in this
                    situation.

     Problem:       Receiving EMS memory errors

     Explanation:   The EMS NetWare shell was very strictly written to the
                    LIM/EMS 4.0 specification.When the Expanded Memory
                    Manager returns an error, the EMS NetWare shell simply
                    returns that error to the screen with the notation that
                    the error has been returned. Any errors of this kind
                    are a result of a non-LIM/EMS 4.0 compatible driver.

     Solution:      Upgrade EMS driver to latest LIM/EMS 4.0 compatible
                    version.

     Problem:       Not enough XMS memory to run Windows in Standard or
                    Enhanced mode

     Explanation:   After using the NetWare XMS shell, there was not enough
                    XMS memory left over for Windows to run in either
                    standard or 386 Enhanced mode.

     Solution:      Add more memory or use either the conventional or
                    expanded memory NetWare shell.

Initial SETUP Issues

     Problem:       SETUP Program hangs when loading

     Explanation:   Some types of systems can cause the Windows SETUP
                    program to hang when SETUP attempts to read the system
                    information.

     Solution:      Run SETUP with the /I switch.

     Problem:       SETUP Program hangs when loading (continued)

     Explanation:   Windows uses the I/O address 2E0h for detecting an 8514
                    video adapter. Some NICs will also use this I/O address
                    and cause a conflict with Windows

     Solution:      Change the NIC's I/O address.

     Problem:       SETUP Error: "Cannot create WIN.COM"

     Explanation:   You will usually get this error when you run SETUP /N
                    and the Windows files have not been uncompressed.

     Solution:      Uncompress all the Windows files with the EXPAND.EXE
                    program and run SETUP /N again.

     Problem:       Error: "Update network shell" type error

     Explanation:   This error is caused by not using the 3.01 or higher
                    version NetWare shells.

     Solution:      Use the 3.01 or higher version NetWare shells.

Windows Issues

     Problem:       Windows hangs when loading

     Explanation:   Windows may hang for a number of reasons.

                    The first thing that can be done to isolate this type
                    of problem is to attempt to run Windows in any of its
                    three modes.

                    WIN /r              runs Windows in Real mode.

                    WIN /s              runs Windows in Standard mode.

                    WIN /3              runs Windows in 386 Enhanced mode.

                    If Windows refuses to run in 386 Enhanced mode but will
                    run in Standard and Real modes, look for problems in
                    the [386Enh] section of the SYSTEM.INI file. Problems
                    such as conflicting page frame addresses, and not
                    enough memory, can be the problem.

                    If Windows refuses to run in both Standard and 386
                    Enhanced mode then problems could exist with your XMS
                    memory manager. Look for conflicts there.

                    If Windows refuses to run in real mode this usually
                    indicates setup or configuration problems. Check the
                    setup and configuration, especially available memory.

     Problem:       Windows hangs when loading

     Explanation:   Windows may hang for a number of reasons.

                    Windows' default EMS page frame is at D000-DFFF. If the
                    base memory address of an installed adapter card
                    overlaps this memory area, you can have problems.

     Solution:      Either change the base address of the affected card, or
                    use the EMMExclude statement in the SYSTEM.INI file to
                    exclude the memory segment in question. The following
                    are some possible conflict areas:

                    Some 16-bit VGA Cards                        C400-C7FF

                    IBM Token Ring Card ROM 8KB                  CC00-CDFF

                    IBM Token Ring Card Shared RAM 16KB          D800-DBFF

     Problem:       Windows hangs when loading (continued)

     Explanation:   NICs that use interrupt 2 (IRQ 2) or interrupt 9 (IRQ9)
                    or greater, can cause problems when running Windows in
                    386 Enhanced mode.

     Solution:      1) Change the NIC's interrupt.

     Solution:      2) Use the VPICDA.386 driver (available from Novell) in
                    place of the VPIC driver in the [386Enh] section of the
                    SYSTEM.INI file.

     Problem:       Windows hangs when loading (continued)

     Explanation:   Some PCs treat the COM ports as a "family". If you have
                    a serial mouse on COM1, using IRQ4 and your NIC is set
                    to IRQ 3, it may hang being unable to access the
                    network. This is especially true of Ethernet cards.

     Solution:      Change the NIC's interrupt level.

     Problem:       Windows hangs when loading (continued)

     Explanation:   If you are using the XMSNETx or EMSNETx shells, there
                    is a memory allocation bug with Windows 3.0. This is
                    typified by Windows hanging when loading.

     Solution:      You can get around this problem by using the
                    conventional memory NetWare shell, NETx. Alternatively
                    you can upgrade to Windows 3.0a which corrects this
                    problem.

     Problem:       Can't find Group (.grp) files

     Explanation:   This error usually occurs as a result of mis-mapped
                    drives. The specified location of the group files is in
                    the PROGMAN.INI file. If the user has changed drive
                    mappings from what was referenced in PROGRAM.INI, it
                    will result in this error message.

     Solution:      Correct either the drive map assignments to reflect the
                    values in PROGMAN.INI or change PROGMAN.INI values to
                    correspond to the drive map assignments.

     Problem:       Group files are corrupt

     Explanation:   This seems to be mostly a Windows problem. If the group
                    files become corrupted and they cannot be used, they
                    must be reconstructed.

     Solution:      Delete the old group files and restore them from a good
                    backup or rebuild them by hand.

Hardware Issues

     Problem:       Problems using MAP ROOT with some ethernet cards.

     Explanation:   There are some problems using older Western Digital
                    Ethercard Plus cards and drivers, Everex ethernet cards
                    and drivers, and the new MAP ROOT command.

     Solution:      Contact the respective manufacturers for updated
                    drivers.

     Problem:       Problems running Windows with SMC Arcnet NICs and SMC
                    Turbo Drivers

     Explanation:   There are some problems running Windows and NetWare
                    using older SMC Turbo drivers with SMC Arcnet NICs.

     Solution:      Contact SMC for updated Turbo II drivers.

Application Issues

Btrieve Requester

     The following information is provided from Novell Development Products
     Division and is included in files used to run Btrieve under Windows
     3.0.

     The use of BREQUEST.EXE in Windows 3.0 is made possible by a DLL which
     acts as an interface between the application and the requester. The
     DLL makes use of the DOS Protected Mode Interface (DPMI) provided by
     Windows 3.0 to access the requester which runs in REAL mode.

     The DOS Btrieve requester must be version 5.15 or greater. Previous
     versions of the requester will not work properly with the DLL.

     The user must load the DOS Btrieve requester prior to starting
     Windows, and the DLL must be locatable by Windows. Access to local
     files is possible if you have the client based version of Btrieve for
     Windows by renaming the Btrieve DLL to WBTRLOCL.DLL and specifying
     local=yes as noted below.

     The number of file servers (/S:) and redirected drives (/R:) options
     used to initialize the Btrieve requester must be large enough to
     accommodate additions after loading.

     If both DLL's are used, a Btrieve VERSION operation will return both
     versions if the data buffer length is at least 10. The Btrieve
     requester version information will be immediately followed by that of
     the client based Btrieve.

     Additional status code: 1013. This status is returned when the DLL's
     task list is full. The number of tasks can be increased up to 255 as
     specified below. The most common cause of this problem is that the
     application does not successfully complete a call to WBTRVSTOP()
     before terminating while other Btrieve tasks are active. This causes
     the task entry to remain and eventually will fill up the table.

     The DLL needs to know a couple of things for initialization. Set in
     WIN.INI (defaults):

     [brequestDPMI]

     datalength=4096     ; same as the /D: option used for DOS requester

     chkparms=no         ; validate pointer parameters

     local=no            ; access local files through Btrieve DLL

     tasks=10            ; maximum of active tasks to use the DLL

     The datalength option should be the same as the /D: used to initialize
     the DOS requester when it is loaded. This should be at least as large
     as the largest record to be accessed.

NetWare 3270 LAN Workstation

     What follows is the 3270READ.ME file that covers running the NetWare
     3270 LAN Workstation program with Microsoft Windows. It is also
     included in the TBMI.ZIP file available on NetWire. This document as
     the 3270READ.ME file, is entitled "Guidelines for Using the NetWare
     3270 LAN Workstation with Windows 3.0".

Guidelines

     The following guidelines enable the NetWare 3270 LAN Workstation for
     DOS to run in a Windows 3.0 environment. It should be understood that
     the NetWare 3270 LAN Workstation for DOS is a DOS application, and, as
     such, complies with DOS limitations with respect to the Windows
     environment. In addition, running an SPX application which makes
     direct calls to IPX or SPX under Windows requires the use of the TBMI
     and TASKID programs.

     Novell is supplying these guidelines as an interim solution prior to
     the release of the NetWare 3270 LAN Workstation for Windows, which
     will be a true Windows-based application. Please note that if you
     encounter problems which appear to be workstation-related, we would
     like for you to reproduce the problem in a non-Windows environment
     prior to calling Technical Support.

Installation Tips

     Before loading Windows, you must remove VIPX.386 from the NETWORK=
     statement in the SYSTEM.INI Windows file.

     Use the following sequence to load the software:

     IPX (use IPX.OBJ v3.02)

     NET3 or NET4 (optional)

     Login to file server (optional)

     TBMI

     WIN (from Microsoft Windows diskette)

     Double click on the DOS icon and load TASKID, followed by WSLAN

     We recommend that you enable the NetWare 3270 LAN Workstation to run
     in background and full-screen modes. Attempting to run the workstation
     software in a window may cause unpredictable results.

     Because Windows 3.0 uses some of the same key sequences as the NetWare
     3270 LAN Workstation, you will need to redefine them in order to avoid
     conflicts. Specifically, the <Alt><SysRq> and <Alt><Esc> (if
     configured for host printing) key combinations are used by both
     products. These key sequences may be redefined in either the
     DEFAULT.PIF file for the DOS session in Windows or by using the KEYDEF
     utility for the NetWare 3270 LAN Workstation.

     If you would like to create an icon to execute a batch file to load
     WSLAN, the following sequence of commands is recommended:

     TASKID

     WSLAN

     PAUSE

     JUMP

     WSEXIT

     TASKID /U

     EXIT

     Note that the above is useful for those who need a single host session
     only and do not wish to run Send and Receive or API applications. This
     is because when you jump back to the DOS session, WSLAN must be
     unloaded in order to prevent the host session from hanging. However,
     we hope that this .BAT file illustrates the options available to
     customize your Windows environment.

Limitations

     1)   You must run in 386 Enhanced mode. We recommend that your machine
          have at least 4MB of memory.

     2)   You must use LAN printer redirection for printing from the host
          session.

     3)   SNA must use either Definite Response (set in the bind image) or
          Pacing (set to a non-zero value in VTAM) if you do not set the
          window session for background processing.

     4)   Closing the host window task without unloading the workstation
          software will cause the host session to hang. This will prevent
          you from getting back into the host session. Therefore, it is
          recommended that you run WSEXIT, followed by TASKID /U, prior to
          closing the host window.

     5)   A limitation of Windows is that it may not reload special fonts
          when you switch between workstation sessions. This causes the
          host status line to appear corrupted if your host session is
          configured for Extended Data Stream. Simply jumping to DOS, then
          back to your host session, causes WSLAN to automatically reload
          the status line font.

     6)   Sometimes Windows needs to be reloaded several times when you
          have a TSR in place. If, when you load Windows, you are taken
          back to the DOS prompt, simply reload Windows.

     7)   The mouse is not supported in a host session.

     8)   Vector Graphics is not supported in a host session.

NetWare Asynchronous Communication Server

     What follows is the Novell Communications Products Division technical
     bulletin regarding operating the NetWare Asynchronous Software
     Interface (NASI) software while within Windows 3.0. This file is
     included in the NetWire ZIP archive PTF234.ZIP.

     PTF 234:       TBMI Windows DOS Compatibility Box for NACS

     APPLIES TO:    NetWare NACS

     SUPERSEDES:    NA. However, the TBMI and TASKID are the same as in
                    TBMI.ZIP

     DATE:          January 4, 1991

     If you encounter problems which appear to be NACS/NASI related you
     must reproduce the problem in a non Windows environment prior to
     calling Technical Support.

     TBMI (Task switched Buffer Manager for IPX/SPX) and IPX.OBJ v3.02
     correct problems running an application that makes direct calls to IPX
     or SPX (called a peer-to-peer application) under NetWare within a DOS
     box in a multitasking environment such as Windows. With TBMI and
     TASKID loaded, you will be able to switch away from a running peer-
     to-peer application (such as NACS) without problems.

     Installation

     1.   See "Limitations" below

     2.   Generate IPX.COM from the v3.02 IPX.OBJ.

     3.   Remove VIPX.386 from the NETWORK=statement in the SYSTEM.INI
          Windows file.

     4.   (Optional) Create one or more configuration files. TBMI reads
          configuration information from a configuration file in the
          current directory. Enter one parameter on each line in the
          configuration file. The file's name is NET.CFG by default; a
          different name can be specified using the /C parameter on the
          command line.

Running

     1.   Load the new IPX

     2.   Load NET3 or NET4

     3.   Login to file server

     4.   Load TBMI

     5.   Run WIN.

     6.   Double click on the DOS icon and load TASKID, followed by NASI.
          Run NASI in background and full-screen modes. Attempting to use
          NASI in a window may cause unpredictable results.

     7.   At the new DOS prompt, enter the command "TASKID" followed by
          optional command line parameters in each DOS session. This
          provides the two way communication needed for virtualizing
          asynchronous events in the DOS session. TASKID provides a unique
          ID to TBMI to be used in virtualizing IPX and SPX calls. We
          recommend that you unload TASKID from the DOS session's memory
          before closing the session. Do not unload TASKID before task
          switching.

     8.   Repeat step #7 for each DOS session you will be using before
          loading NASI. Load NASI only once.

     9.   To Exit. Before closing a DOS session with the EXIT command,
          remember to first type "TASKID /U" to unload TASKID from that
          session. Failure to unload TASKID from a session's memory before
          closing the session may result in loss of data buffers and
          machine hanging. It is not necessary to unload TBMI after exiting
          Windows, but you may wish to do so to free up memory.

Limitations

     1)   You must run in 386 Enhanced mode.

     2)   Closing the NASI window task without unloading NASI may cause
          hanging.  Therefore, we recommend that you run UNLOAD, followed
          by TASKID /U.

     3)   Sometimes Windows needs to be reloaded several times when you
          have a TSR in place. If, when you load Windows, you are taken
          back to the DOS prompt, simply reload Windows.

Batch File

     If you would like to create an icon to execute a batch file to load
     NASI, the following sequence of commands is recommended:

     TASKID

     NASI

     (name of communications program)

     UNLOAD

     TASKID /U

     EXIT

Appendix A: NetWare Files

     What follows is a listing of all the necessary NetWare files for
     running Windows 3.0. The listing is grouped according to the ZIP
     archive that the files are available in, from the Novell NetWire
     service on the Compuserve Information Service system.

NDD NetWire ZIP Files

     The following ZIP files can be obtained from the NDD portion of
     NetWire. You simply need to type GO NDD at any Compuserve prompt and
     you will be moved to this location. You can then follow the
     instructions for downloading any of these files.

     DSWIN0.TXT     10318     1-15-91

     This file is a text file that describes the various other DSWIN?.ZIP
     files available from the Novell Download Directory (NDD), and covers
     some installation tips.

     DSWIN1.ZIP     246741    1-15-91

     DOC.TXT        36128     5-15-90   11:46a

     EMSNET3.EXE    58952     11-27-90  5:26p

     EMSNET4.EXE    59432     11-27-90  5:25p

     HISTORY.SHL    5489      12-10-90  9:30a

     IPX.OBJ        19917     12-18-90  9:48a

     LICENSE.TXT    6128      5-22-90   4:14p

     NET3.COM       48838     11-27-90  5:25p

     NET4.COM       49265     11-27-90  5:24p

     README         6023      5-21-90   3:01p

     SHELL.TXT      1190      5-22-90   4:12p

     XMSNET3.EXE    56056     11-27-90  5:27p

     XMSNET4.EXE    56488     11-27-90  5:26p

     DSWIN2.ZIP     213457    5-23-90

     $RUN.OVL       2400      7-13-89   9:30a

     CMPQ$RUN.OVL   2400      7-26-89   10:26p

     COMCHECK.EXE   76840     9-01-87   11:53a

     COMCHECK.HLP   2673      9-01-87   11:53a

     DCONFIG.EXE    22247     6-06-88   11:46a

     ECONFIG.EXE    24269     4-14-88   8:21a

     IBM$RUN.OVL    2400      7-13-89   9:30a

     INT2F.COM      640       7-28-88   11:48a

     LICENSE.TXT    6128      5-22-90   4:14p

     NLINK.EXE      37633     8-10-89   9:37a

     SHCONFIG.EXE   97365     5-04-89   10:57a

     SHCONFIG.HLP   33082     5-04-89   10:15a

     SHELL.TXT      1190      5-22-90   4:12p

     SHELLS.DAT     23        8-17-87   1:44p

     SHGEN.EXE      26321     5-04-89   10:06a

     SNE1000.LAN    881       5-03-90   9:18a

     SNE1000.OBJ    5415      12-27-89  2:30p

     SNE2.LAN       133       5-03-90   9:17a

     SNE2.OBJ       4781      11-29-89  1:55p

     SNE2000.LAN    881       5-03-90   9:18a

     SNE2000.OBJ    6121      12-27-89  12:16p

     SPCN2.LAN      969       8-15-89   11:22a

     SPCN2.OBJ      6003      5-26-88   12:03p

     SPS110.LAN     112       8-15-89   11:22a

     SPS110.OBJ     6023      8-17-88   4:41p

     SRXNET.LAN     1253      8-15-89   11:22a

     SRXNET.OBJ     6727      10-10-88  11:43a

     STOKEN.LAN     100       8-15-89   11:22a

     STOKEN.OBJ     4464      5-05-89   10:11a

     SYS$ERR.DAT    6489      7-29-87   9:57a

     SYS$HELP.DAT   17343     8-11-87   10:06a

     SYS$MSG.DAT    22298     12-22-87  8:42a

     VOLUMES.DAT    40        2-10-88   9:31a

     DSWIN3.ZIP     430346    5-23-90

     AUTOEXEC.BAT   292       5-16-90   8:30a

     BINDFIX.EXE    39424     10-30-89  4:29p

     FILER.EXE      270781    5-11-90   4:23p

     FILER.HLP      65519     8-09-89   4:41p

     LICENSE.TXT    6128      5-22-90   4:14p

     MAKEUSER.EXE   133595    5-14-90   10:46a

     MAKEUSER.HLP   2015      2-22-89   10:03a

     NETWARE.PIF    545       4-26-90   1:37p

     PRINTDEF.EXE   180211    5-04-90   11:05a

     PRINTDEF.HLP   37815     10-27-89  1:32p

     SESSION.EXE    111827    8-07-89   9:59a

     SESSION.HLP    21066     8-07-89   9:54a

     SHELL.TXT      1190      5-22-90   4:12p

     DSWIN4.ZIP     347915    5-23-90

     CAPTURE.EXE    41025     5-04-90   9:20a

     FLAG.EXE       29821     5-09-90   3:54p

     FLAGDIR.EXE    27093     3-23-90   11:06a

     GRANT.EXE      32385     8-01-89   4:02p

     INSTALL.EXE    15061     5-14-90   5:49p

     LICENSE.TXT    6128      5-22-90   4:14p

     LOGIN.EXE      70301     7-28-89   12:52p

     MAP.EXE        45077     8-11-89   4:21p

     NCOPY.EXE      58261     8-10-89   4:17p

     NDIR.EXE       89226     8-14-89   10:17a

     NPRINT.EXE     61021     5-04-90   8:31a

     REMOVE.EXE     47674     7-18-89   11:46a

     REVOKE.EXE     33549     7-24-89   3:43p

     RIGHTS.EXE     17545     7-21-89   2:39p

     SHELL.TXT      1190      5-22-90   4:12p

     TLIST.EXE      28921     7-18-89   11:57a

     VPICDA.386     11063     5-14-90   5:51p

NOVA NetWire ZIP Files

     Additionally you may find it necessary to download the following ZIP
     archive files from the Novell NetWire Forum A. To do this you can
     simply type in GO NOVA from any Compuserve prompt. You can then follow
     the forum instructions for downloading these files. These files will
     be located in the download library 16 Novell New Uploads.

     TBMI.ZIP  30401     1-03-91

     3270WKST.ZIP   7510      12-18-90  3:20p

     IPX.OBJ        19917     12-18-90  9:48a

     README.TXT     1007      12-21-90  11:26a

     TASKID.COM     2623      12-19-90  3:48p

     TBMI.COM       16817     12-19-90  4:34p

     TBMI.DOC       9725      11-12-90  8:44p

     The following are the unarchived files from the 3270WKST.ZIP archive
     file included inside the TBMI.ZIP archive file.

     3270WKST.ZIP   7510      12-18-90

     3270READ.ME    4138      12-18-90  8:18a

     JUMP.EXE       11161     12-18-90  8:01a

     PTF234.ZIP     36084     1-04-91

     IPX.OBJ        19917     12-18-90  9:48a

     READ.ME        9472      1-04-91   12:35p

     TASKID.COM     2623      12-19-90  3:48p

     TBMI.COM       16817     12-19-90  4:34p

     UNLOAD.EXE     11349     8-14-89   4:17p

Out-of-Date NetWire ZIP Archives

     The following listings of NetWire Windows related ZIP archives that
     are out of date as of this printing.

     DSWIN1.ZIP     242932    5-22-90

     This archive contained the version 3.01 Rev. A NetWare shells.

     DOC.TXT        36128     5-15-90   11:46a

     EMSNET3.EXE    58584     5-08-90   3:40p

     EMSNET4.EXE    59000     5-08-90   3:39p

     IPX.OBJ        19166     5-07-90   3:18p

     LICENSE.TXT    6128      5-22-90   4:14p

     NET3.COM       48544     5-08-90   3:37p

     NET4.COM       48907     5-08-90   3:35p

     NETBIOS.EXE    23088     4-20-90   2:25p

     READ.ME        6023      5-21-90   3:01p

     SHELL.TXT      1190      5-22-90   4:12p

     XMSNET3.EXE    55672     5-08-90   3:42p

     XMSNET4.EXE    56056     5-08-90   3:41p

     DSWIND.ZIP     201958    9-18-90

     This archive contained the version 3.01 Rev. D NetWare shells.

     EMSNET3.EXE    58664     9-18-90   2:38p

     EMSNET4.EXE    59096     9-18-90   2:42p

     NET3.COM       48576     9-18-90   2:21p

     NET4.COM       48939     9-18-90   2:22p

     REVD.TXT       2207      9-18-90   3:05p

     XMSNET3.EXE    55752     9-18-90   2:32p

     XMSNET4.EXE    56152     9-18-90   2:41p

     SH301E.ZIP     204845    12-20-90

     This archive contains the current version 3.01 Rev E NetWare shells,
     it is just a subset of the files included in the DSWIN1.ZIP archive.

     EMSNET3.EXE    58952     11-27-90  5:26p

     EMSNET4.EXE    59432     11-27-90  5:25p

     HISTORY.SHL    5489      12-10-90  9:30a

     NET3.COM       48838     11-27-90  5:25p

     NET4.COM       49265     11-27-90  5:24p

     README.TXT     581       12-11-90  4:16p

     XMSNET3.EXE    56056     11-27-90  5:27p

     XMSNET4.EXE    56488     11-27-90  5:26p

Appendix B: BINDFIX Technical Notes

     The following is the Novell Technical bulletins regarding problems
     with BINDFIX.EXE and the new NetWare shells. Please read this
     thoroughly before using BINDFIX with the new shells.

Technical Bulletin 255

     October 26, 1989

     BINDFIX Aberration

     When BINDFIX.EXE is executed under the following conditions, data loss
     will occur:

     The NetWare operating system is version 2.15 or below.

     The NetWare shell being used on the workstation where BINDFIX.EXE is
     being executed is a NetWare 386 shell, version 3.0.

     The NetWare 386 v3.0 shell is using the "SHOW DOTS ON" parameter. The
     default for this parameter is ON.

     A user has been deleted from the bindery without the corresponding
     mail directory being deleted. This occurs when the SYSCON utility
     being used was an earlier version shipped with NetWare v2.11 or below
     and the shell being used is a NetWare 386 version 3.0 shell.

     The BINDFIX user answers "Yes" to the question, "Delete mail
     directories of users that no longer exist?"

     Note: Data loss will occur only when all the above conditions are met.

The Cause

     The early versions of SYSCON.EXE were not prepared to deal with the
     directory entry '.' (from the NET.CFG parameter "SHOW DOTS = ON").
     This resulted in the user mail directory not being properly deleted.

     BINDFIX.EXE, similarly, is unable to deal with the '.' directory
     entry. When it attempts to delete mail directories of nonexistent
     users, it will get caught in a loop of deleting files and directories.

Preventive Measures

     We recommend that NetWare users use the 3.0 shell only with NetWare
     386 file servers and with NetWare 386 utilities.

     In an internetwork environment where it may be necessary to use the
     3.0 shell with 2.1x file servers, place the command "SHOW DOTS = OFF"
     in the NET.CFG file.

     Users of some applications need the "SHOW DOTS = ON" parameter set.
     Make sure that they have insufficient rights to run BINDFIX.EXE.

     Make sure that there are no versions of SYSCON.EXE on your
     internetwork that are earlier than NetWare version 2.12.

     Maintain current backups.

Technical Bulletin 256

     Date: November 3, 1989

     Update to Technical Bulletin 255

     The NetWare 386 shell available on NetWire has been changed. The file
     date on NETX.COM is now 10/31/89. In the earlier version, the default
     setting for the SHOW DOTS parameter was SHOW DOTS=ON. The default for
     this parameter has now been changed to SHOW DOTS=OFF. This change is
     effective only on the shell on NetWire dated 10/31/89. Please be aware
     that the shell that comes with the NetWare 386 software will still
     have the default of SHOW DOTS=ON.

     The SHOW DOTS default parameter was changed to avoid data loss, as
     discussed in Technical Bulletin 1-255.

BINDFIX Conclusions

     The version of BINDFIX.EXE listed in the ZIP archive below has been
     modified to handle the '.' when using a 3.0 shell with the SHELL.CFG
     (or NET.CFG) parameter "SHOW DOTS=ON". These circumstances would
     previously cause BINDFIX to delete all directories and files.
     Technical bulletins 255 and 256 outline the problem and mention a 3.0
     shell which has the default of "SHOW DOTS=OFF". This new shell was
     only a partial fix. This copy of BINDFIX now allows users to
     comfortably use the 3.0 shell with BINDFIX.

     The version of BINDFIX.EXE listed below is available on NetWire in
     NOVA in the the following ZIP file:

     BINDFX.ZIP     23153     12-18-89  12:45p

     255.TXT        2344      10-31-89  5:05p

     256.TXT        766       11-03-89  8:34a

     BINDFIX.EXE    39424     10-30-89  4:29p

     READ.ME        480       12-06-89  3:51p

Appendix C: SYSTEM.INI Network Settings

     The following SYSTEM.INI settings are ones that can have an affect on
     network operations either directly, in the case of settings that
     control things like the network buffer response size that Windows will
     use, or indirectly, in the case of settings that control how adapter
     memory (the memory between 640K and 1024K) is used.

     The format explanation and definitions used here are from the Windows
     supplied text files, SYSINI.TXT, SYSINI2.TXT, and SYSINI3.TXT. For
     further discussions on SYSTEM.INI settings, please consult these files
     and your Windows User's Manual.

Format

     Windows initialization files have the following format:

     [section name]

     keyname=value

     In this example, [section name] is the name of a section. Sections are
     used to break settings into logical groups. The enclosing brackets
     ([]) are required, and the left bracket must be in the leftmost column
     on the screen.

     The keyname=value statement defines the value of each setting. A
     keyname is the name of a setting. It can consist of any combination of
     letters and digits, and must be followed immediately by an equal sign
     (=). The value of the setting can be an integer, a Boolean value, a
     string, or a quoted string, depending on the setting. There are
     multiple settings in most sections.

     You can include comments in initialization files. You must begin each
     line of comments with a semicolon (;).

     The settings will not appear alphabetically in the SYSTEM.INI file. If
     you want to change a setting, you will have to search for the setting
     in the appropriate section. Many of the settings explained in this
     file are rarely needed and will not appear in your SYSTEM.INI file
     unless you add them yourself.

     The syntax, purpose, and recommended method for changing each setting
     appear in the following format:

SettingName=<value-type>

     Default:       This is Windows' built-in value for this setting.

     Purpose:       This paragraph briefly describes the function of the
                    setting.

     To change:     This sentence states the recommended method for
                    changing the value of this setting.

     The <value-type> indicates whether the value should be a number, a
     letter, a range of numbers, a Boolean value, or something else. If you
     want to enable a Boolean setting, you can enter: true, yes, on, or 1.
     If you want the Boolean setting to be disabled, you can enter: false,
     no, off, or 0.

     Many settings listed in this document do not normally appear in your
     SYSTEM.INI file. Most of these settings have a built-in default value
     that is present whether or not the setting appears in SYSTEM.INI.

     SETUP assigns a value to each setting in the [boot] and [keyboard]
     sections, and to the Device setting and its synonyms in the [386Enh]
     section. These settings have no built-in default values. These
     settings must appear in SYSTEM.INI in order for Windows to function
     properly, so be careful not to delete them.

[boot] Section

     CAUTION: All settings in this section are required. If you modify or
     delete one of these settings, Windows might not operate properly.
     There are no built-in default values for these settings; SETUP assigns
     values based on your system configuration.

     The [boot] section contains a list of the drivers and Windows modules
     that Windows uses to configure itself each time you start it. The
     following are the [boot] section settings that can affect network
     operation:

     network.drv=<filename>

     Default:       none

     Purpose:       Specifies the filename of the network driver you are
                    using.

     To change:     Choose the Windows SETUP icon from the Main Group
                    window. If you are installing a device driver that is
                    not included with Windows, run SETUP from MS-DOS.

[NonWindowsApp] Section

     The [NonWindowsApp] section contains settings that affect the
     performance of non-Windows applications. The following are the
     [NonWindowsApp] section settings that can affect network operation:

     NetAsynchSwitching=<0-or-1>

     Default:       0

     Purpose:       Indicates whether Windows will allow you to switch away
                    from an application (running in real mode or standard
                    mode) after it has made an asynchronous network BIOS
                    call. The default value of 0 specifies that such task
                    switching is not allowed. Switching away from some
                    applications that make these calls might cause your
                    system to fail. Once Windows detects an asynchronous
                    NetBIOS call, it will not allow switching from the
                    application even if no more of these calls are made.
                    Set this value to 1 if you are sure the applications
                    you use will not receive network messages while you are
                    switched away from them.

     To change:     Use Notepad to edit the SYSTEM.INI file.

SwapDisk=<drive-colon-directory>

     Default:       (The directory pointed to by the TEMP environment
                    variable; if there is no TEMP variable, then the
                    default is the Windows directory)

     Purpose:       Provides the name of the disk drive and directory to
                    which Windows running in real mode or standard mode
                    swaps non-Windows applications.

     To change:     Use Notepad to edit the SYSTEM.INI file.

[standard] Section

     The [standard] section contains settings that are specific to running
     Windows in standard mode. The following are the [standard] section
     settings that can affect network operation:

Int28Filter=<number>

     Default:       10

     Purpose:       Specifies the percentage of INT28h interrupts,
                    generated when the system is idle, that are made
                    visible to software that is loaded before Windows.
                    Windows will reflect every nth interrupt, where n is
                    the value of this setting. Increasing this value might
                    improve Windows' performance, but may interfere with
                    some memory- resident software such as a network. Set
                    this value to 0 to prevent INT28h interrupts. But note
                    that setting this value too low will add to system
                    overhead that might interfere with communications
                    applications.

     To change:     Use Notepad to edit the SYSTEM.INI file.

NetHeapSize=<kilobytes>

     Default:       8

     Purpose:       Specifies the size (in kilobytes) of the buffer pool
                    that standard-mode Windows allocates in conventional
                    memory for transferring data over a network. Some
                    networks require a larger buffer than the default.
                    Increasing this value will diminish the amount of
                    memory available to applications. If no network
                    software is running, this setting will be ignored and
                    no memory will be allocated.

     To change:     Use Notepad to edit the SYSTEM.INI file.

[386Enh] Section

     The [386Enh] section contains information specific to running Windows
     in 386 enhanced mode, including information used for virtual-memory
     page swapping. The following are the [386Enh] section settings that
     can affect network operation:

AllVMsExclusive=<Boolean>

     Default:       false

     Purpose:       If enabled, this setting forces all applications to run
                    in exclusive full-screen mode, overriding all contrary
                    settings in the applications' program information files
                    (PIFs). Enabling this setting might prolong the length
                    of the Windows session when you are running network and
                    memory- resident software that is incompatible with
                    Windows.

     To change:     Use Notepad to edit the SYSTEM.INI file.

Device=<filename-or-*devicename>

     Default:       none (SETUP assigns appropriate values based on your
                    system configuration.)

     Purpose:       Specifies which virtual devices are being used with
                    Windows in 386 enhanced mode. This value can appear in
                    two ways: either the name of a specific virtual device
                    file, or an asterisk (*) followed immediately by the
                    device name. The latter case refers to a virtual device
                    that is in the WIN386.EXE file. Synonyms for Device=
                    are Display=, EBIOS=, Keyboard=, Network=, and Mouse=.
                    Filenames usually include the .386 extension. Multiple
                    device lines are required to run Windows in 386
                    enhanced mode.

     To change:     Use Notepad to edit the SYSTEM.INI file.

Display=<filename-or-*devicename> (See "Device=", above)

     Default:       none (SETUP assigns an appropriate value based on your
                    system configuration.)

     Purpose:       Specifies the display device that is being used with
                    Windows in 386 enhanced mode. This setting is a synonym
                    for Device=.

     To change:     Choose the Windows SETUP icon from the Main Group
                    window.

DualDisplay=<Boolean>

     Default:       See "Purpose."

     Purpose:       Normally, when running in 386 enhanced mode, the memory
                    between B000:0000 and B7FF:000F will be used by the
                    general system unless a secondary display is detected.
                    If this setting is enabled, this memory will be left
                    unused and available for display adapters. If this
                    setting is disabled, the address range will be
                    available on EGA systems but not under VGA systems,
                    since the VGA display device supports monochrome modes,
                    which use this address space.

     To change:     Use Notepad to edit the SYSTEM.INI file.

EBIOS=<filename-or-*devicename> (See "Device=", above)

     Default:       none (SETUP assigns an appropriate value based on your
                    system configuration.)

     Purpose:       Specifies the extended BIOS device that is being used
                    with Windows in 386 enhanced mode. This setting is a
                    synonym for Device=.

     To change:     Use Notepad to edit the SYSTEM.INI file.

EMMExclude=<paragraph-range>

     Default:       none

     Purpose:       Specifies a range of memory that Windows will not scan
                    to find unused address space. This has the side effect
                    of turning off the RAM and ROM search code for the
                    range. The range (two paragraph values separated by a
                    hyphen) must be between A000 and EFFF. This scanning
                    can interfere with some adapters that use the same
                    memory area. The starting value is rounded down and the
                    ending value is rounded up to a multiple of 16K. For
                    example, you could set EMMExclude=C800-CFFF to prevent
                    Windows from scanning the addresses C800:0000 through
                    CFFF:000F. You can specify more than one range by
                    including more than one EMMExclude line.

     To change:     Use Notepad to edit the SYSTEM.INI file.

EMMInclude=<paragraph-range>

     Default:       none

     Purpose:       Specifies a range of memory that Windows will scan for
                    unused address space regardless of what may be there.
                    EMMInclude takes precedence over EMMExclude if you
                    specify ranges that overlap. The range (two values
                    separated by a hyphen) must be between A000 and EFFF.
                    The starting value is rounded down and the ending value
                    is rounded up to a multiple of 16K. For example, you
                    could set EMMInclude=C800-CFFF to ensure that Windows
                    scans the addresses C800:0000 through CFFF:000F. You
                    may specify more than one range by including more than
                    one EMMInclude line.

     To change:     Use Notepad to edit the SYSTEM.INI file.

EMMPageFrame=<paragraph>

Default:       none

Purpose:       Specifies the starting paragraph where the 64K page frame
               will begin when Windows in 386 enhanced mode cannot find a
               suitable page frame. Allows an EMM page frame in an area
               containing some unused RAM or ROM. For example, you could
               set EMMPageFrame=C400 to start the page frame at C400:0000.

To change:     Use Notepad to edit the SYSTEM.INI file.

EMMSize=<kilobytes>

     Default:       65,536

     Purpose:       Specifies the total amount of memory to be made
                    available for mapping as expanded memory. The default
                    allocates the maximum possible amount of system memory
                    as expanded memory. You should specify a value for this
                    setting if you run an application that allocates all of
                    the available expanded memory. This will be apparent
                    if, when you run the application, you can never create
                    any new virtual machine. If this value is zero, then no
                    expanded memory will be allocated, but the EMM driver
                    will be loaded. This setting does not prevent the EMM
                    driver from being loaded; use the NoEMMDriver to
                    disable EMM.

     To change:     Use Notepad to edit the SYSTEM.INI file.

FileSysChange=<Boolean>

     Default:       on (But in a standard SYSTEM.INI file, SETUP will set
                    FileSysChange=off, disabling this setting.)

     Purpose:       Indicates whether File Manager will automatically
                    receive messages any time a non-Windows application
                    creates, renames, or deletes a file. When this setting
                    is disabled, a virtual machine can be run exclusively
                    even when it manipulates files. Enabling this setting
                    can slow down system performance significantly.

     To change:     Use Notepad to edit the SYSTEM.INI file.

InDOSPolling=<Boolean>

     Default:       no

     Purpose:       If enabled, prevents Windows from running other
                    applications when memory-resident software has the
                    InDOS flag set. Enabling this setting is necessary if
                    the memory-resident software needs to be in a critical
                    section to do operations off an INT21 hook. Enabling
                    this setting will slow down system performance
                    slightly.

     To change:     Use Notepad to edit the SYSTEM.INI file.

INT28Critical=<Boolean>

     Default:       true

     Purpose:       Specifies whether a critical section is needed to
                    handle INT28h interrupts used by memory-resident
                    software. Some network virtual devices do internal task
                    switching on INT28h interrupts. These interrupts might
                    hang some network software, indicating the need for an
                    INT28h critical section. If you are not using such
                    software, you might improve Windows' task switching by
                    disabling this setting.

     To change:     Use Notepad to edit the SYSTEM.INI file.

MapPhysAddress=<range>

     Default:       none

     Purpose:       Specifies the address range (in megabytes) in which the
                    memory manager will preallocate physical page-table
                    entries and linear address space. Use this setting if
                    you are using a DOS device driver (such as an older
                    version of RAMDrive that uses extended memory) that
                    needs this contiguous memory.

     To change:     Use Notepad to edit the SYSTEM.INI file.

MaxPagingFileSize=<kilobytes>

     Default:       none

     Purpose:       Specifies the maximum size (in kilobytes) for a
                    temporary swap file.

     To change:     Use Notepad to edit the SYSTEM.INI file.

MinTimeSlice=<milliseconds>

     Default:       20

     Purpose:       Specifies the minimum amount of time (in milliseconds)
                    a virtual machine will be allowed to run before other
                    virtual machines can take over. A smaller value (such
                    as 10 milliseconds) will make multitasking appear
                    smoother, but will diminish the overall system
                    performance.

     To change:     Choose the 386 Enhanced icon from the Control Panel
                    window.

MinUserDiskSpace=<kilobytes>

     Default:       500

     Purpose:       Tells Windows how much disk space (in kilobytes) to
                    leave free when creating a temporary swap file. You
                    would want to use this setting if your system's paging
                    drive has less available space than Windows can use for
                    paging. This setting has no effect if a permanent swap
                    file exists.

     To change:     Use Notepad to edit the SYSTEM.INI file.

NetAsynchFallback=<Boolean>

     Default:       false

     Purpose:       If enabled, tells Windows to attempt to save a failing
                    NetBIOS request. When an application issues an
                    asynchronous NetBIOS request, Windows will attempt to
                    allocate space in its global network buffer to receive
                    the data. If there is insufficient space in the global
                    buffer, Windows will normally fail the NetBIOS request.
                    If this setting is enabled, Windows will attempt to
                    save such a request by allocating a buffer in local
                    memory and preventing any other virtual machines from
                    running until the data is received and the timeout
                    period (specified by the NetAsynchTimeout setting)
                    expires.

     To change:     Use Notepad to edit the SYSTEM.INI file.

NetAsynchTimeout=<seconds>

     Default:       5.0

     Purpose:       Specifies the timeout period (in seconds) when Windows
                    needs to enter a critical section in order to service
                    an asynchronous NetBIOS request. It is used only when
                    NetAsynchFallback is enabled. This value can include a
                    decimal (such as 0.5).

     To change:     Use Notepad to edit the SYSTEM.INI file.

NetDMASize=<kilobytes>

     Default:       32 on Micro Channel (TM) machines 0 on non-Micro
                    Channel machines

     Purpose:       Specifies the DMA buffer size (in kilobytes) for
                    NetBIOS transport software if a network has been
                    installed. In this case, the buffer size is the larger
                    value between this value and the value of
                    DMABufferSize.

     To change:     Use Notepad to edit the SYSTEM.INI file.

NetHeapSize=<kilobytes>

     Default:       12

     Purpose:       Specifies the size (in kilobytes) of the buffers that
                    Windows in 386 enhanced mode allocates in conventional
                    memory for transferring data over a network. All values
                    are rounded up to the nearest 4K.

     To change:     Use Notepad to edit the SYSTEM.INI file.

Network=<filename-or-*devicename> (See "Device=", above)

     Default:       none (SETUP assigns an appropriate value based on your
                    system configuration.)

     Purpose:       Specifies the type of network you are using with
                    Windows in 386 enhanced mode. This setting is a synonym
                    for Device=.

     To change:     Choose the Windows SETUP icon from the Main Group
                    window.

Paging=<Boolean>

     Default:       yes

     Purpose:       Enables or disables demand paging (virtual memory). You
                    would disable this setting only if you need the disk
                    space normally used for a temporary swap file.

     To change:     Use Notepad to edit the SYSTEM.INI file.

PagingDrive=<drive-letter>

     Default:       none

     Purpose:       Specifies the disk drive where Windows in 386 enhanced
                    mode will allocate a temporary swap file. This setting
                    is ignored if you have a permanent swap file. If you
                    don't have a permanent swap file and no drive is
                    specified or the specified drive does not exist,
                    Windows will attempt to put your temporary swap file on
                    the drive containing your SYSTEM.INI file. If the
                    specified drive is full, paging will be disabled.

     To change:     Use Notepad to edit the SYSTEM.INI file.

PSPIncrement=<number>

     Default:       2

     Purpose:       Specifies the amount of additional memory, in 16-byte
                    increments, that Windows should reserve in each
                    successive virtual machine when the UniqueDOSPSP
                    setting is enabled. The setting that will work best for
                    your machine might vary depending on your memory
                    configuration and the applications you are running.
                    Valid values are 2 through 64. See UniqueDosPSP for
                    more information.

     To change:     Use Notepad to edit the SYSTEM.INI file.

ReflectDosInt2A=<Boolean>

     Default:       false

     Purpose:       Indicates whether Windows should consume or reflect DOS
                    INT 2A signals. The default means Windows will consume
                    these signals and therefore run more efficiently.
                    Enable this setting if you are running memory-resident
                    software that relies on detecting INT2A messages.

     To change:     Use Notepad to edit the SYSTEM.INI file.

SysVMEMSLimit=<kilobytes>

     Default:       2048

     Purpose:       Specifies how many kilobytes of expanded memory Windows
                    should be permitted to use. Setting this value to 0
                    prevents Windows from gaining access to any expanded
                    memory. Setting it to #1 gives Windows all the
                    available expanded memory that it requests.

     To change:     Use Notepad to edit the SYSTEM.INI file.

SysVMEMSLocked=<Boolean>

     Default:       no

     Purpose:       Indicates whether to swap Windows' expanded memory to
                    the hard disk. Locking expanded memory can improve the
                    performance of a Windows application that uses it, but
                    locking it slows down the rest of the system.

     To change:     Use Notepad to edit the SYSTEM.INI file.

SysVMEMSRequired=<kilobytes>

     Default:       0

     Purpose:       Specifies how many kilobytes of expanded memory must be
                    free in order to start Windows. Leave this setting at
                    zero if no Windows application requires expanded
                    memory.

     To change:     Use Notepad to edit the SYSTEM.INI file.

SysVMV86Locked=<Boolean>

     Default:       false

     Purpose:       If enabled, causes the virtual-mode memory being used
                    in the system virtual machine to remain locked in
                    memory rather that being swapable out to disk. Because
                    Windows handles this process, there is no known reason
                    to enable this setting.

     To change:     Use Notepad to edit the SYSTEM.INI file.

SysVMXMSLimit=<kilobytes>

     Default:       2048

     Purpose:       Specifies the maximum amount of memory (in kilobytes)
                    the extended memory driver will allocate to DOS device
                    drivers and memory-resident software in the system
                    virtual machine. Set the value to #1 to give an
                    application all the available extended memory that it
                    requests.

     To change:     Use Notepad to edit the SYSTEM.INI file.

SysVMXMSLocked=<Boolean>

     Default:       no

     Purpose:       Indicates whether to swap the memory allocated by the
                    extended memory driver to the hard disk. Locking the
                    XMS memory (enabling this setting) can improve an
                    application's performance, but it slows down the rest
                    of the system.

     To change:     Use Notepad to edit the SYSTEM.INI file.

SysVMXMSRequired=<kilobytes>

     Default:       0

     Purpose:       Specifies how many kilobytes of extended memory must be
                    reserved by the XMS driver in order to start Windows.
                    Leave this setting at zero if there are no XMS users in
                    the system virtual machine.

     To change:     Use Notepad to edit the SYSTEM.INI file.

TimerCriticalSection=<milliseconds>

     Default:       0

     Purpose:       Instructs Windows to go into a critical section around
                    all timer interrupt code, and specifies a timeout
                    period (in milliseconds). Specifying a positive value
                    will assure that only one virtual machine at a time
                    will receive timer interrupts. Some networks and other
                    global memory-resident software may fail unless this
                    setting is used. However, using it will slow down
                    performance and can make the system sluggish or seem to
                    stop for short periods of time.

     To change:     Use Notepad to edit the SYSTEM.INI file.

TokenRingSearch=<Boolean>

     Default:       true

     Purpose:       Tells Windows whether to search for a token ring
                    network adapter on machines with IBM PC/AT (R)
                    architecture. Disable this setting if you are not using
                    a token ring card and the search interferes with
                    another device.

     To change:     Use Notepad to edit the SYSTEM.INI file.

UniqueDOSPSP=<Boolean>

     Default:       false (see below for exception)

     Purpose:       If enabled, tells Windows to start every application at
                    a unique address (PSP). Each time Windows creates a new
                    virtual machine to start a new application, Windows
                    reserves a unique amount of memory (i bytes) below the
                    application. For example, the first application would
                    be loaded at address M, the second at address M+i, the
                    third at M+2i, and so forth. The amount of memory i is
                    determined by the PSPIncrement setting (earlier in this
                    section). These settings should help assure that
                    applications in different virtual machines all start at
                    different addresses. Some networks use applications'
                    load addresses to identify the different processes
                    using the network. On such networks, failing to enable
                    this setting might cause one application to fail when
                    you exit another, because the network interprets them
                    as the same. However, enabling this setting will leave
                    slightly less memory for non-Windows applications. If
                    you are running a network based on Microsoft Network or
                    LAN Manager, the default value is true. See the
                    NETWORKS.TXT online document to find out whether the
                    network you are running is one of these.

     To change:     Use Notepad to edit the SYSTEM.INI file.

VirtualHDIrq=<Boolean>

     Default:       on

     Purpose:       Allows Windows in 386 enhanced mode to terminate
                    interrupts from the hard disk controller, bypassing the
                    ROM routine that handles these interrupts. Some hard
                    drives might require that this setting be disabled in
                    order for interrupts to be processed correctly. If this
                    setting is disabled, the ROM routine handles the
                    interrupts, which slows the system's performance.

     To change:     Use Notepad to edit the SYSTEM.INI file.

WindowKBRequired=<kilobytes>

     Default:       256

     Purpose:       Specifies how much conventional memory (in kilobytes)
                    must be free in order to start Windows.

     To change:     Use Notepad to edit the SYSTEM.INI file.

WindowMemSize=<number-or-kilobytes>

     Default:       #1

     Purpose:       Limits the amount of conventional memory Windows can
                    use for itself. The default value (#1) indicates that
                    Windows can use as much of this space as it needs. You
                    can try entering a positive value less than 640 if
                    there is not enough memory to run Windows in 386
                    enhanced mode.

     To change:     Use Notepad to edit the SYSTEM.INI file.

Appendix D: Bibliography

Books

     Microsoft Windows User's Guide Version 3.0. Microsoft Corporation.
     1985-1990.

     Microsoft Windows User's Guide Version 2.0. Microsoft Corporation.
     1987.

     Using Microsoft Windows/386. Microsoft Corporation. 1987.

     Microsoft Windows User's Guide Version 2.0. Microsoft Corporation.
     1987.

     Graphic Facts About Networking with Windows. Automated Design Systems,
     Inc. 1988-1990.

     Saber LAN Setup Guide for Windows Version 1.0. Saber Software
     Corporation 1990.

     Duncan, Ray.  Extending DOS. Reading, MA.: Addison-Wesley Publishing
     Co., Inc. 1990.

     Norton, Peter, and Yao, Paul.  Peter Norton's Windows 3.0 Power
     Programming Techniques. New York, NY.: Bantam Books, Inc. 1990.

Articles

     Geary, Michael. An Introduction to Microsoft Windows Version 3.0: A
     Developer's Viewpoint.   Microsoft Systems Journal. (July 1990): 1-
     28.

Electronic Documents

     WINDOWS 3.00 AND NETWORKS. Microsoft Corporation. 1990.

     NETWORKS.TXT. Microsoft Corporation. 1990.

     SYSINI.TXT, SYSINI2.TXT, SYSINI3.TXT. Microsoft Corporation. 1990.

     WININI.TXT, WININI2.TXT. Microsoft Corporation. 1990.