Dec 282017
A paper on 3COM's current and future postion on Windows 3.
File WIN3.ZIP from The Programmer’s Corner in
Category Network Files
A paper on 3COM’s current and future postion on Windows 3.
File Name File Size Zip Size Zip Type
WIN3.TXT 32646 10231 deflated

Download File WIN3.ZIP Here

Contents of the WIN3.TXT file

Windows 3.0 White Paper - Overview

3Com recognizes Windows 3.0 as a central part of customers' strategic
plans for the desktop. As such, 3Com offers a wide range of Windows 3.0
compatible functionality at first customer ship of Windows 3.0. Moreover,
3Com will continue its role as the market leader in DOS network
connectivity solutions by expanding these initial capabilities. 3Com
envisions an environment in which a single user can be connected to
multiple hosts through multiple protocols, thereby fully merging the
strengths of Windows' graphics and Demand Protocol Architecture's
freedom of choice in host connectivity.

Users have three key concerns in using Windows 3.0 in a networked
environment: memory availability, the integration of network
connectivity into the Windows environment, and the use of network
applications in the Windows environment.

This paper is an overview of these issues. For someone intending to
implement Windows 3.0 in their 3Com networked environment, the
companion papers on Windows Architecture and Windows Compatibility
and Plans should be consulted.

Memory Availability

True Windows applications are freed from the familiar DOS 640k memory
barrier. However, until all common DOS applications are rewritten to
become Windows applications, and until customers invest in these new
versions, memory availability in a networked Windows environment will
be a major customer concern.

3Com's NBP (Netbios Protocol) provides a solution for this memory
squeeze. By implementing a fast, fully functional local area network
protocolin 25k or less of DOS memory, the combined impact of Windows
and the network on DOS memory availability is diminished.

Future releases of 3Com primary protocols will provide even greater
memory availability, by taking advantage of the EMM386.SYS expanded
memory manager provided with Windows 3.0. For 386 based machines
running in 386 enhanced mode, both NBP and TCP with Netbios will be
compatible with EMM386.SYS so that they can load outside conventional
DOS memory space, thereby minimizing the effect of the network on DOS
applications' memory needs.

Network Connectivity in the Windows 3.0 Environment

Users have a range of network connectivity needs in the Windows 3.0
environment. At the base level, users have the need for applications to
access files and printers over the local area network while in Windows
3.0, and to have applications in different Windows be able to use local
area network server resources simultaneously. This functionality is
available with 3+Open Lan Manager 1.1 at first customer ship of Windows
3.0, as well as with 3+Share.

The next level of functionality desired is the ability to make local area
network server connections while in Windows. This functionality is
available with 3+Open Lan Manager 1.1 while in Windows, by using the File
Manager and Control Panel dialogue boxes for connecting or disconnecting
network drives and printers.

The third level of functionality desired is the ability to use other
protocols to talk to hosts other than the protocol/host of the network
operating system. Some of this functionality is provided at first
customer ship of Windows 3.0. For example, our demand loaded XNS stack
can be used to retrieve 3+Open email. Moreover, if both the 3+Open client
and our forthcoming 3+Open Connection for Netware product are kept co-
resident while in Windows 3.0, both a Novell server and a 3+Open server
can be simultaneously accessed.

However, while in many cases demand loaded protocols can be used in the
Windows 3.0 environment, these protocols cannot remain active while
other processes are also active in the foreground. In practice, this may
have little impact on users.

Network Applications in the Windows 3.0 Environment

Finally, users are concerned with how they can use our network
applications in the Windows 3.0 environment. 3Com intends to provide a
true Windows 3.0 front-end for its 3+Open Maxess gateway, which
provides both direct token ring and synchronous modem connection to IBM
hosts. Maxess' front-end for the Windows 2.x environment is currently in
beta, and it offers such capabilities as sizable windows and multiple
simultaneous terminal emulations. Once that project completes, this
support will be ported to the Windows 3.0 platform.

Also, 3+Open Mail is available in the Windows 3.0 environment when XNS
is used as either a primary or demand loaded stack. It must be used as a
full screen, character oriented window. A true Windows front-end for
Mail is being evaluated as a future project.

In summary, 3Com provides the most widely desired features for
networking in the Windows 3.0 environment today. In the future, an
environment in which a user has the broadest range of seamless
connectivity to multiple host systems is the goal.

Windows Architecture

3Com is very excited by the capabilities of Windows 3.0 and what 3Com
can provide within the Windows 3.0 environment.

Windows 3.0 is a sophisticated single user operating system. It merges
the one job at a time architecture of DOS with some of the multi-tasking
capabilities of OS/2, while including a user friendly interface much like
Presentation Manager. Given that it is not OS/2, however, implies that
some architectural limits remain that may be significant in a networked
environment. And, subsequently, simple questions like "do you support
Windows 3.0" do not reduce to simple yes/no answers, but rather require
some explaining of Windows 3.0.

To meet this need, this paper is an explanation of the Windows 3.0
architecture and key issues in simple terms. Some technical accuracy is
sacrificed in the interest of making the big picture intelligible. Read this
in conjunction with the following paper, which lays out what functionality
is available in 3Com's product line with Windows and what functionality
is planned, in order to understand 3Com's plans with Windows.

Basic Concepts

Real and protected mode. Intel originally offered one method of operation
for its microprocessors, and that was real mode. Real mode restricted
memory addressing to one megabyte of memory, and is the source of DOS
applications being able to only address 640k of memory. DOS executes in
real mode. With the 286 and 386, Intel offered a new mode of operation,
called protected. In it addressing space is expanded to 16 meg of memory.
OS/2 currently executes in protected mode and hence offers applications
16 meg of memory space.

Extended memory. Memory above the 1 meg of addressing space offered to
real mode is referred to as extended memory.

DOS expanded memory managers. To get around the 640k limit of DOS,
various DOS memory managers trick DOS by mapping part of real memory
space to either extended memory or special physical expanded memory
cards. These memory managers usually take a 64k chunk of memory in the
area between 640k and 1 meg, and DOS applications written to be aware of
what is referred to as expanded memory can use this capability to address
more than the traditional 640k of DOS memory by referencing this 64k
block. Behind the scenes these memory managers map these applications'
memory requests to extended memory or physical expanded memory and/or
bring information in from the hard disk to extended memory when it is not
originally present in extended memory. By this means applications can
actually be larger than the 640k of DOS memory and/or be larger than the
amount of physical memory, since the memory manager brings in the
needed piece of the application from the hard disk if it is not present in
physical memory.

Some of these memory managers have the added capability of mapping the
entire real memory space from 640k to 1meg to extended memory. By this
means memory managers such as 3ComEMM can allow certain network
drivers to be loaded outside conventional DOS memory space, thereby
freeing more memory for traditional DOS applications.

Resulting from a quirk in the Intel architecture, a specialized driver can
be written to allow a 64k chunk of memory at 1meg in real memory space
to be made available. This is what the himem.sys driver included in
3+Open Lan Manager 1.1 provides.

Multitasking. Operating systems such as OS/2 offer a feature called
multitasking. This means that multiple applications can be executing at
the same time, with the operating system conducting a round robin
process of temporarily stopping one application and giving the cpu to
another, so that all applications stay active. For example, one application
can be printing in the background while a user can be doing a spreadsheet
in the foreground.

Windows applications. To be a Windows application, standard DOS
programs must be altered to observe rules on use of graphics, use of
memory, and coordination with other active Windows applications.
Certain added capabilities are available to windows applications
depending on the Windows 3.0 mode of operation.

Windows 3.0 Modes of Operation

Windows 3.0 offers 3 modes of operation - real, standard, and 386
enhanced. Each offers different capabilities and has different hardware
requirements, with 386 enhanced offering the greatest functionality and
having the greatest hardware requirements.

Real mode. Real mode is the only mode available in 8086 based machines
and any machine which has less than 1 mb of memory. Windows itself
executes in real mode, so little memory is left for DOS applications when
network memory requirements are also factored in. However, it does not
conflict with any DOS memory managers, and if expanded memory is
available it can be used by DOS applications. However, real mode is quite
slow and limited in its capabilities.

Standard mode. Standard mode is available for 286 based machines with
1 megabyte or more of memory and for 386 machines which have less than
2 mb of memory. In standard mode Windows applications, as well as
Windows itself, execute in protected mode and are not bound by DOS 640k
memory limitations, and furthermore they can execute in extended
memory. Multitasking of non-Windows applications is not available, and
therefore if a conventional DOS program is switched to the background it
is not active.

Windows standard mode is only compatible with physical expandedmemory
boards. Software based memory managers such as QEMM, Pharlap, etc,
cannot be used while in Windows. A user may wish to disable the physical
expanded memory driver and use it as extended memory, if the user is
using true Windows applications, which can then run in the extended
memory in protected mode.

Windows standard mode can still consume a significant chunk of DOS
memory space, since it does not completely reside in extended memory. A
quick look at one configuration revealed that Windows standard mode
consumed 57k of DOS memory space.

True Windows applications can be multitasked in what is referred to as
non-preemptive multitasking. With this method, multiple Windows
applications can stay active in the background, but they only get CPU time
when the Windows application which has the cpu gives it up by doing
suchthings as making a Windows call. Thus, you cannot be guaranteed that
a process will get the cpu in a timely manner.

With standard mode, most people are recommending a minimum of 3 meg
of memory on a 286 based machine to get good performance with Windows
applications, which make direct use of the memory above 1 meg. Non-
Windows applications, on the other hand, must be moved into conventional
DOS memory from disk storage.

386 enhanced mode. 386 enhanced mode is only available for 386 based
machines with 2 mb or more of memory. When you hear Windows 3.0
capabilities discussed, it tends to be in terms of 386 enhanced mode,
without qualifying the hardware platform. Windows applications operate
in protected mode, and both Windows and non-Windows applications are
multitasked, allowing jobs to complete in the background while another
job is active in the foreground. This multitasking is preemptive, meaning
that each application is guaranteed a share of the cpu time.

The only DOS memory manager supported is the expanded memory manager
which ships with Windows 3.0, EMM386.SYS. Subsequently, 3COMEMM (and
QEMM, CEMM, Pharlap, etc) does not work, and you must load network
drivers in conventional DOS memory, robbing regular DOS programs of that
memory. 386 enhanced cannot use physical expanded memory boards, so if
you have one you should disable the physical expanded memory board
driver and use it as extended memory.

Microsoft chose not to follow the standard other memory managers were
following (VCPI) to coordinate use of extended memory. Rather, Microsoft
created a new standard called DPMI. Presumably, when and if other
memory manager vendors recognize and write to DPMI, compatibility of
Windows 3.0 enhanced mode with other memory managers will be regained.

To get good performance with Windows applications in enhanced mode, the
recommendation appears to be to have 4 meg or more of memory.

Windows and the Network Interface

Windows 3.0 offers abilities to connect network drives through the File
Manager and to connect network printers from the Control Panel. These
generic calls are parsed to a network operating specific call (i.e.,
connecting to a network printer becomes a net use) and hence Windows 3.0
offers the opportunity for easy access to network resources.

Windows and Protected Mode APIs

A Windows application executing in protected mode may wish to make a
network call via an api. Imagine a generic api call such as "find server"
which passes an address to a server name. In protected mode this address
does not point to a real physical address (the byte of memory at location
1000, say) but rather a protected mode, virtual address (which points to
alogical address 1000, which the memory manager ultimately maps to a
physical address, thereby allowing applications to be moved in and out of

Unfortunately, the network protocol is a real mode process which thinks
in terms of real addresses. Consequently, there must be support for
translating the addresses in apis invoked by Windows applications from
protected mode to real mode equivalents. Microsoft provides this ability
for DOS, BIOS, and NetBIOS calls.

Windows and Protocols

Two generic issues arise with protocols executing in conjunction with
Windows. Both arise from the fact that the application which originally
made a network call may not be active when the network call completes -
in real or standard modes, the user may have switched the active process
to the background, while in enhanced mode the system is constantly
switching which process is active. Protocols per se do not keep track of
which "Window" they were talking to originally and quite cheerfully will
stuff the network data returned into whatever address was originally
passed to it, regardless of whether that "Window" is still in memory.

So, one issue is that a protocol at some level has to be "Windows aware"
to the degree that it knows which Window called it so that it does not
corrupt other active applications. The second issue is that to work well,
some degree of buffering has to be provided so that packets can be saved
until the appropriate Window is active.

Windows 3.0 provides these capabilities for Netbios. Since 3+Open Lan
Manager 1.1 and the redirector works through netbios calls, a high degree
of functionality is provided with our primary protocols - NBP, XNS, and
DLC. Multiple windows can have multiple network connections active, and
Windows 3.0's netbios support tracks which window made the network
connection and buffers network packets until the appropriate window is

Non-Switchable and Exclusive

To get around the issue of buffering when using demand loaded protocols,
two solutions arise. First, the memory resident stub should be aware of
which Window called it, so that if an unexpected network packet arrives,
it does not try to deliver the packet to an inappropriate Window. This
would be an issue if a demand loaded protocol did not end a connection and
hence a host is trying to check if the client is still active.

Keep in mind that the following issues are handled with a primary
protocol by the Netbios support of Windows, and hence only pertain to
demand loaded protocols. To ensure that an asynchronous call is not
posted when a calling process is swapped out (ie, please send me this
information, and I will continue doing other things until you complete my
request), the process associated with the demand loaded protocol should
be configured to be non-switchable in standard mode and exclusive in
enhanced mode. These are parameters associated with a process' program
information file (PIF).

If set to be non-switchable, a process cannot be switched out when it has
outstanding calls. If set to exclusive, a process cannot be swapped out
behind the scenes by Windows' preemptive multitasking abilities. Note
that exclusion can lead to compromises in the 386 enhanced environment -
other processes are not active, and will drop packets if they have network
activity outstanding. However, particularly in standard mode, this can
make a very nice fit with Windows, since protocols can be invoked through
batch files associated with a demand loaded protocol, and hence the
common graphical interface for invoking programs is preserved.

Windows Compatibility and Plans

This paper lays out in detail what 3Com believes is functional at first
customer ship of Windows 3.0, and what plans 3Com has to enhance the
functionality of its product in the Windows 3.0 environment. The
assumption is that the note on Windows architecture has been read.

The reader should be aware that basic network operating system
functionality - single protocol configurations under 3+Open or 3+Share -
is dependent on work that the Microsoft Windows team did, by
incorporating windows awareness, buffering, and protected mode api
translation for netbios in both the Lan Manager (3+Open Lan Manager 1.1)
and MS Net (3+Share) environments.

Hence, support in these configurations is largely a question of Windows
itself. 3Com worked extensively with Microsoft in the beta phase of
Windows 3.0 by conducting its own network intensive testing of single
protocol 3+Open configurations and reporting many bugs to Microsoft.
Furthermore, both 3+ and 3+Open were tested with Windows 3.0 beta with
3Call, 3Com Technical Support's online call tracking database, which uses
the Gupta SQL Windows front-end and Gupta SQL Server.

Thus, we have a high degree of confidence that such configurations work
correctly. Furthermore, 3Com plans to conduct another extensive round of
testing with the actual Windows 3.0 product in order to fully verify its
functionality in network intensive testing.

Following is a product by product description of Windows compatibility
issues and plans for enhancing capabilities under Windows 3.0.

3+Open 1.1

Single protocols - NBP, XNS, and DLC - should be compatible with Windows
3.0, and offer the ability to keep multiple network connections active
across windows in the 386 enhanced mode.

If using XNS, a user should choose the "3Com 3+Open Lan Manager (XNS only)"
option when configuring Windows. If using NBP or DLC, a user should choose
the "Lan Manager 1.x (or 100% compatible)" option. This resulted from changes
having to be made to the Windows code to eliminate conflicts with the MindsPRO

Global network connections can be made through the File Manager and
Print Manager in Windows 3.0 running over 3+Open 1.1. In addition, if you
are running the enhanced redirector, you can also view and manipulate the
print queues.

As previously described, Windows 3.0 is not compatible with 3ComEMM.
Consequently, network drivers which previously could be placed outside
regular DOS memory now consume regular DOS application space.

Protected mode api calls - such as could be made by a Windows
application SQL server front-end doing a named pipe call - are not
possible, at least initially, with 3+Open 1.1. They will be supported in
2.0, and we are exploring ways to make them available with 1.1, but no
promises can be made. In practice, this should not be a problem until
Windows applications which make named pipe and mailslot calls start
shipping. Note that protected mode Netbios calls do work, as evidenced by
usage of the Gupta SQL Windows front-end.

Netpopup is not compatible with Windows and hence a specialized version
of netpopup, called winpopup, exists. The version of winpopup packaged
with Lan Manager 2.0 beta appears to be compatible with Windows 3.0
operating in a 3+Open 1.1 environment. We are exploring ways to make
this available to 1.1 customers, but no promises can be made. The
winpopup which ships with 3+Open 1.1 is not compatible with Windows

Certain enhanced network features are only available with Lan Manager
2.0. This includes a "network browsing" option, which lets you walk
through the resources available on the network from within Windows.

Future versions of particular primary protocols will take advantage of the
expanded memory manager packaged with Windows to load themselves, or
most of themselves, outside of conventional DOS memory. Specifically,
the version of NBP which will ship with 3+Open 2.0 and TCP with Netbios
when it ships will conform to this memory manager, EMM386.SYS for
Windows 3.0. Thus, a significant amount of DOS memory space will be
reclaimed for standard DOS programs, while letting users choose either
NBP for its speed or TCP with Netbios for those customers with TCP-only

Hence, excellent solutions to the RAM Cram problem introduced by the
portion of Windows which stays in DOS memory are, or will be, available.
For one, the himem.sys area no longer needs to be used for Windows, since
Windows itself executes in protected mode. Consequently, this space can
be used to load all, or part, of the redirector outside conventional DOS
space for maximum memory savings. Consult the Windows 3.0 Release
Notes for incompatibilities with specific versions of DOS.

It is highly unlikely that 3Com will provide a network protocol which
operates in protected mode for the Windows 3.0 platform. For one, it
would require switching between the real mode redirector to the
protected mode protocol and back to the real mode MAC driver, possibly
for each packet. Hence, it would be grossly inefficient. Furthermore,
other options exist for freeing conventional DOS memory, such as
conformance with EMM386 for Windows 3.0 and/or a time in the future
when Windows can accommodate other DOS memory managers and let
other DOS memory managers load network drivers in high memory.


Windows 3.0 generically provides support for MS Net based networks,
including the ability to support multiple windowed applications and the
ability to make network connections from within Windows. It includes a
network configuration option for choosing 3+Share, which loads these MS
Net drivers.

Testing in-house by our Technical Services Operation, and by a third
party testing house, indicate that 3+Share is compatible with this
Windows support. This is contingent on using the full Netbios layer, and
not just NB.COM. Furthermore, server names or an alias for the server
name must follow Netbios naming conventions. 3Com will do testing
withthe released Windows 3.0 product to confirm this functionality, and
work with Microsoft if any issues arise.

Although it is unlikely, if major changes to 3+Share were required to
resolve a compatibility issue with Windows, we would most likely steer
customers to 3+Open, for these reasons. For one, the target hardware
base of 286 or 386 machines with 3 to 4 meg of memory is more typical
of our 3+Open clients than our 3+ installed base. Moreover, NBP and TCP
are better suited to be coded to use the EMM386.SYS driver packaged with
Windows 3.0, and hence we can offer superior memory saving options for
theseprotocols, which will be a critical issue with Windows customers.

Protocols and DPA

One generic issue with dynamically loaded protocols exists. Currently a
small stub is permanently memory resident for demand loaded protocols.
This stub must be made "Windows aware" in the sense that it will not pass
a packet on unless the window which originally invoked it is active. Else,
you risk data corruption from packets being placed ininvalid addresses. We
are exploring future enhancements to our DPA architecture in which the
protocol manager itself, and not the stub, would be made "Windows

3+Open TCP/TCP with Netbios

The current demand loaded TCP stack is not Windows compatible. When
TCP with Netbios ships, it will both support 3+Open 1.1 with Windows 3.0
and it will take advantage of the EMM386.SYS driver packaged with
Windows 3.0 to load itself outside conventional DOS memory on 386 based

Enhancements to fully utilize TCP's capabilities with Windows 3.0 are
in the works. Anticipate that future releases of TCP with Netbios will
incorporate both "Windows awareness" and buffering, so that you could
bedoing an FTP session in one window and have a DOS application
accessing a network drive in another window, all using the same TCP
stack as a primary protocol.

Moreover, 3+Open TCP will also be enhanced so that the TCP DPA stub is
"Windows aware" and can track which Window invoked it. Thus, demand
loaded TCP could be used to conduct a Telnet session. We are exploring
ways to be able to use this demand loaded stack on a non-exclusive basis,
so that other network activity could remain active.

Keep in mind that protected mode api's are a separate issue. When TCP
with Netbios is discussed, it is in terms of using the Netbios for network
server access, and not using the full RFC Netbios functionality, such as
scope. Also, support for protected mode socket and BAPI calls are
inprocess of being evaluated. We will closely track the market demand for
such functionality.

3+Open XNS

Currently, the 3+Open XNS stub is "windows aware". Consequently you can
demand load XNS in the Windows 3.0 environment. Again, while active, the
demand loaded protocol must be in exclusive mode for the 386 enhanced
mode and non-switchable in the standard and real modes. This can make a
nice fit with Windows in the standard environment, in that you can create
an icon which invokes a batch file which dynamically loads XNS, executes
an XNS specific application such as mail, then unloads the protocol.

3+Open Connection for Netware (IPX)

Our forthcoming Netware connectivity product can coexist with the 3+Open
client in a Windows 3.0 environment. Both must be loaded prior to
entering Windows, and the Netware stack cannot be unloaded while in

When entering Windows, you must configure the network connection
capabilities in the File Manager and Print Manager to be either done
relative to Netware or 3+Open. For the network operating system you
choose, you can make global network connections from the appropriate
Windows interface. For the other network operating system, to make a
network connection you must open a new screen group, and the connection
you make is local to that particular screen group. Thus, you would want to
set up global connections for the network operating system not selected
prior to entering Windows.

3+Open Maxess

A true Windows application front-end for Windows 2.x is currently in beta
test. Upon completion of that project, a Maxess Windows front-end for
the Windows 3.0 platform will be developed, which will offer the ability
to conduct multiple concurrent host sessions from protected memory

3+Open Mail

Mail currently does not offer a Windows application front-end.
Consequently, it must be used as a full screen, character oriented
window. It is not possible to size this Window, as problems will arise. It
can be executed in conjunction with the demand loaded XNS stack, through
an exclusive or non-switchable PIF. We will publish an appropriate PIF for
this functionality. This can make a very nice fit with Windows, in that
the user simply has to click on the Mail icon to demand load XNS and
invoke Mail, and the protocol can be automatically unloaded once the user
exits Mail.

Mail Minder is not compatible with Windows.

Currently, we are in process of evaluating a Windows front-end for our
Mail product line.


3Stations make an excellent Windows netstation. Since use of progload
does not conflict with Windows 3.0, and assuming the himem.sys area is
available for the redirector, memory availability for regular DOS
applications in the Windows environment is very high. Regular PCs most
likely are not able to load network drivers outside conventional DOS
memory space when used with Windows, and hence suffer a severe
RAMcram problem.

The SIMMs which can be bought with 3Stations are used as extended
memory. As mentioned before, 3 meg of memory is a practical low end for
a 286 based Windows netstation. If you have a 2X model, you may wish to
disable the expanded memory driver and use the expanded memory board as
extended memory, if you are running true Windows applications, which
cannot use expanded memory.

Usage of the EMSIM.SYS memory driver is not compatible with Windows.
Windows itself will make direct use of extended memory.

To use 800 x 600 graphics, a new Windows 3.0 driver must be obtained
from Paradise. Such a driver is currently available from Western Digital
Imaging (the parent company of Paradise Systems) by calling 415-335-2709.
It is also available on 3Com's Ask3Com service on CompuServe.


Presumably, if the particular application (terminal emulation, FTP) is
called through a non-switchable or exclusive Window, and the connection
is terminated upon switching to another Window, these applications will
work in this extremely limited sense with Windows. However, we make no
claims as to compatibility of these programs with Windows, and do not
intend to support them in a Windows environment.


Our DLC stack for 3+Open 1.1 includes an 802.2 api, which is used by such
programs as IBM's PC 3270 to directly connect to an IBM host. It appears
that at best such functionality only works on an exclusive and/or non-
switchable basis when invoked from a regular DOS program, including
breaking the connection upon exiting the Window, and the safest
statement is that we do not support use of the 802.2 api from within

Link Plus Optimizer (LPO)

The Windows release notes state that use of LPO is not compatible with
Windows, and recommend a process to remove use of LPO which also
removes the network operating system. Our own testing indicates that
LPO works fine with Windows, but only in programmed i/o mode and not in
direct memory access (DMA) mode. We will conduct further testing and
clarify this issue with Microsoft, as well as help them to correct their
documentation if indeed LPO works fine.

 December 28, 2017  Add comments

Leave a Reply