home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
OS/2 Shareware BBS: 14 Text
/
14-Text.zip
/
OS2TECHG.ZIP
/
OS2TECHG.INF
(
.txt
)
Wrap
OS/2 Help File
|
1993-10-26
|
631KB
|
8,537 lines
ΓòÉΓòÉΓòÉ 1. Title Page ΓòÉΓòÉΓòÉ
A Technical Guide to OS/2 2.0
January 1993
Martin McElroy
European Personal Systems Center (EPSC)
Basingstoke
UK
MCELROM at NHBVM7
+44 (0)256 343204
Converted to IPF by:
Leshek Fiedorowicz
CIS#74170,2007
ΓòÉΓòÉΓòÉ 2. Notices ΓòÉΓòÉΓòÉ
ΓòÉΓòÉΓòÉ 2.1. Trademarks ΓòÉΓòÉΓòÉ
The following terms are trademarks or registered trademarks of the IBM
Corporation in the United States and/or other countries:
OS/2 Extended Services
Presentation Manager NetView
WIN-OS/2 Workplace Shell
AIX IBM
DB2 DDCS/2
Operating System/2 SQL/DS
OS/400 RISC
PS/2 RISC System/6000
Systems Application Architecture SAA
SAA Distributed Database Connection Services/2 SQL
System/370 Audio Visual Connection
All trademarks appearing in this document are owned by their respective
companies.
ΓòÉΓòÉΓòÉ 2.2. Disclaimer ΓòÉΓòÉΓòÉ
Some of the information in this paper concerns future products, or future
releases of products currently commercially available. The discussion regarding
Microsoft Windows is based upon information which the Microsoft Corporation has
made publically available, and is subject to change. The description and
discussion of IBM's future products, performance, functions and availability
are based upon IBM's current intent and are subject to change.
ΓòÉΓòÉΓòÉ 2.3. Special notices ΓòÉΓòÉΓòÉ
References in this publication to IBM products, programs, or services do not
imply that IBM intends to make these available in all countries in which IBM
operates.
Any reference to an IBM program, product or service is not intended to imply
that only IBM's program, product or service may be used. Any functionally
equivalent program, product or service may be used instead.
IBM may have patents or pending patent applications covering subject matter in
this document. The furnishing of this document does not imply giving any
license under any patent or pending patent.
ΓòÉΓòÉΓòÉ 3. Preface ΓòÉΓòÉΓòÉ
This document describes the features and benefits of OS/2 Version 2.0 from a
technical perspective. It is aimed at customer technical staff, software
developers, IBM staff, dealers and business partners, and anyone else who needs
to understand the detail of how OS/2 2.0 has been designed and implemented.
Its primary aim is to help those evaluating the product to understand why OS/2
2.0 is the platform of choice for the 90s.
The structure of the document is designed to lead the reader from an awareness
of the needs of the PC systems of the 90s, to an understanding of how OS/2 2.0
meets those needs. It therefore covers the design of OS/2 as well as its key
features, and goes on to discuss future directions for OS/2. The guide can
either be read sequentially, in its entirety, or individual sections may be
used for reference purposes, relating to specific aspects of OS/2 (such as DOS
compatibility). To help in the latter use, here is a summary of the aim and
contents of each section:
OS/2 Version 2.0 sets the background against which OS/2 has been developed. It
describes how the PC environment is radically different from that of the 80s,
and the resulting needs of customers deploying PC systems. It also recounts how
OS/2 has been designed to address those needs, culminating in release 2.0.
Why OS/2? outlines the most important reasons why OS/2 is the platform of
choice for the 90s. It is a summary of the arguments provided in the rest of
the document. It can be regarded as a management summary, and as such is
designed so that it can also be used standalone, separate from the rest of the
document. It is suitable for use in proposals, or customer reports on OS/2 2.0.
OS/2 2.0 key elements prefaces the three chapters on DOS, Windows and OS/2
support that follow, by describing some of the technologies that underpin the
whole system. Features such as multi-tasking, hardware support, 32-bit design
and Multiple Virtual DOS Machines (MVDM) are the foundation for many of the
specific aspects described in the three sections that follow. They are also
fundamental to understanding OS/2's superiority to DOS-based systems.
Better DOS describes the extensive support for DOS applications, and the ways
in which OS/2 2.0 provides a better environment for running DOS applications
than DOS itself. This section includes discussion of the memory usage,
protection and the steps taken to ensure the widest possible compatibility with
existing DOS applications.
Better Windows begins by explaining some of the aspects of DOS/Windows 3.x, in
order to show how OS/2 2.0 provides a better Windows environment. An important
factor is the discussion of how DOS/Windows 3.x is used widely for running
multiple DOS applications, perhaps even more than for running Windows
applications. This leads on to a description of how OS/2 2.0 is a superior
multi-DOS environment, which also runs Windows applications, supporting Windows
features such as DDE, clipboard and OLE. The section concludes with a brief
discussion of why many developers are already porting their Windows
applications to OS/2, and some of the tools available to help.
Better OS/2 describes some of the additional features in OS/2 2.0 compared with
OS/2 1.3. It illustrates the benefits of a 32-bit OS/2, and discusses
migration from 16-bit OS/2 1.x.
Workplace Shell discusses the user interface of OS/2 2.0. It begins by
outlining the reasons why OS/2 2.0 uses a new user interface model, and the
benefits it provides. Emphasis is placed on the fact that users have greater
flexibility to work the way they want, and concentrate on the information they
are working with, not the steps the computer needs to follow. This section also
describes some of the components and features of the Workplace Shell, comparing
them with older GUI systems like DOS/Windows.
OS/2 in a connected environment points out how OS/2 2.0 is the client of choice
in client-server systems, and is the base for a family of products which
connect the OS/2 client into LAN, mini and host based systems, including open
systems. Some of the OS/2 products that offer these features (Extended
Services, OS/2 LAN Server, TCP/IP for OS/2) are briefly described. Another
crucial element in considering connected, rather than standalone systems, is
the ability to support systems management tools, so that the cost of
maintaining and managing the system does not exceed the benefits. This section
also discusses migrating from older connectivity products such as DOS-based
terminal emulators and networking products.
Futures describes some of the areas in which OS/2 is expected to be enhanced to
address the growing sophistication of PC usage, and emerging technologies such
as distributed computing, multimedia and object-oriented technology. It aims to
provide an understanding of the framework within which OS/2 will continue to
develop throughout the 90s.
The Appendices give some background information on OS/2 2.0 and comparisons
with other environments.
Appendix A compares OS/2 2.0 features with those of DOS/Windows 3.x, including
a detailed comparison of support for DOS applications
Appendix B discusses the hardware requirements for OS/2 2.0 and gives a
summary of performance considerations and tuning hints.
Appendix C gives a guide to other books, publications and materials relating
to OS/2 2.0, where the reader may find more information.
To use the guide most effectively, it is important not only to understand its
contents, but also its purpose. Although the document is technical in nature,
it does not aim to be a technical reference. This is beyond the scope of a
document of this length. Those looking for such details should consult the
OS/2 Technical Compendium referenced in the Appendices (see Further reference
materials ). This guide stands in technical content and level of detail,
between the product information brochure, and the comprehensive discussion of
the OS/2 Technical Compendium.
The guide covers OS/2 function in the release made generally available at the
end of March 1992. It gives some discussion of planned updates to be made
available during 1992, but details may change before such updates are
available. Readers are advised to check with IBM representatives or Authorised
Dealers for specific dates and functions.
Although this guide is suitable as an introduction to OS/2 for software
developers, it is NOT intended as a developers' guide. Issues for programmers
are dealt with only as they affect the fundamental OS/2 architecture or in as
much as they concern the OS/2 user. More detailed information for OS/2
programmers may be obtained from your local IBM contacts or via the OS/2
Developer Assistance Program, or on local bulletin boards or Compuserve.
No guide to OS/2 can pretend that the product exists only in a standalone
environment. The chapter OS/2 in a Connected Environment discusses how OS/2 2.0
is ideally suited to the needs of the connected PC, whether it be LAN-based, or
integrated within an enterprise network. It also describes in brief some of the
other members of the OS/2 family, such as Extended Services for OS/2, or OS/2
LAN Server. However, detailed discussion of these products would probably
double the size of the document. A separate technical guide covering the OS/2
systems extensions is planned (contact your IBM representative for more
information).
References to Microsoft Windows 3.x are made to denote the versions of Windows
currently available (3.0 and 3.1) which act as an extension to DOS, running on
a DOS base. The term, "Windows 3.x" is used throughout the guide where the
comment is applicable to both 3.0 and 3.1. A specific version number is used
when talking only about one or other release. References in this document to
Windows/NT (which Microsoft has announced they expect to ship in 1993) are
based on information which the Microsoft Corporation has made publicly
available.
ΓòÉΓòÉΓòÉ 4. OS/2 Version 2.0 ΓòÉΓòÉΓòÉ
ΓòÉΓòÉΓòÉ 4.1. The changing PC environment ΓòÉΓòÉΓòÉ
In 1981, when IBM introduced the first IBM Personal Computer, no-one
anticipated how much it would change the face of the computer industry. In the
first half of the 1980s, PC use was mainly confined to improving personal
productivity by using spreadsheets, word processors and other widely available
applications.
However, it has been clear from the mid-1980s and beyond that the PC needs to
perform a broader role in the organisation. As greater amounts are spent on PC
technology, more is being demanded, and increasingly the PC is being seen as a
"window" on the enterprise, a single screen from which company-wide information
resources can be accessed, and a base for mission critical, "line-of-business"
applications that previously would only have run on a mainframe. Thus, PCs have
been increasingly connected together in Local Area Networks (LANs) and to host
computers, making them a critical part of the corporate data network.
In addition, new technologies like Graphical User Interfaces (GUIs) and
multimedia, along with greater connectivity, offer the potential to provide
even more information in an easily accessible manner, so that not only can more
uses be found for PCs, but also more users. In this way, PCs can be used to
transform the business, not just increase productivity or automate existing
processes.
And the trend towards "rightsizing" applications continues, moving critical
applications to PCs on a LAN, using a client-server approach. The market
analysts Forrester Research published a report in May 1992, identifying the
growth in demand for a new "super client", driven by the migration of business
applications towards LANs and client-server.
Unfortunately, much of this remains an aspiration, rather than reality. An
article in a June 1990 issue of PC Week said that the PC must now "grow up",
saying that PCs must be considered as "business tools", not "microcomputers".
But a number of requirements must be in place before the PC can "grow up" and
before the "super client" can emerge:
o "Industrial Strength" reliability: unless the PC can demonstrate itself to
be as robust an environment as the host computer, it cannot expect to take
over some of the applications the host runs today, nor even participate fully
in sharing those applications via a client-server or co-operative processing
setup. There is little point in having a reliable server or host if the
client platform is unstable.
o Networking "Built In": the PC environment needs to allow straightforward and
simultaneous connection to a variety of other platforms: LAN, mid-range, UNIX
and mainframe, and to be able to handle the variety of communications
protocols that results from the multi-vendor environment in most companies.
o Performance: the PC platform must demonstrate that it can adequately share
the processing load, by exploiting the power of the base hardware. Since
most client-server and connectivity applications will require multiple
processes, the ability to run several concurrent tasks efficiently is
fundamental. In this respect, the requirement for performance measurement
goes beyond the simple benchmarking of one application at a time, and leads
towards determining overall throughput and concurrency.
o Wide Application Choice: the platform of the 90s should build on
compatibility with existing productivity applications, and allow
"mission-critical" applications to be developed for the same platform, so
that the user's system can handle both business and productivity
applications.
o Ease of use and low training costs: in expanding the use of the PC,
additional complexity in terms of communications and multiple applications
are inevitably introduced. These must be implemented while presenting the
user with a way of working the system that is as easy to learn and adapt to
as possible, both for the user's sake (for better user adoption) and for the
organisation's (in less "down time" while learning the system). This applies
not only to existing users: to expand the use of the PC and bring in more
users, to make it a truly business system, barriers to learning the system
must be lowered.
o Easily managed: put simply, the costs of installation, integration,
maintenance and updates most not exceed the benefits of running the system.
o Investment protection: all of these aims must be achieved without completely
starting from scratch. To retain users' comfort and capitalise on the
existing investment in applications and hardware, maximum use must be made of
the systems and applications in place, where possible integrating them with
the new systems. But the design of such a system should offer compatibility,
but not be constrained by the past. Investment exploitation is as important
as protection in the long term.
All in all, the requirements of the PC systems of the 90s can be summed up in
one word: integration. The means of integration will be software, and in
particular the operating environment. Once the basis is there, applications to
exploit it will follow. In short, an advanced operating system is needed for
the PC of the 1990s, one that can exploit the benefits of the ten years' worth
of productivity applications, while moving the PC platform forward to address
the needs of the 1990s and become a "business" machine, rather than just a
productivity tool.
ΓòÉΓòÉΓòÉ 4.2. Cheaper processors and memory ΓòÉΓòÉΓòÉ
Some of the obstacles to the widespread use of an advanced platform, such as
high memory costs and insufficient processor capacity, are now being removed.
Memory prices have fallen dramatically over the last three or four years, and
the recent development of the 16 megabit DRAM chip means that memory is being
packaged in ever larger units (4MB or in future 8MB at a time). This will
continue the rise in the average amount of memory installed in PCs: in 1992,
nearly all IBM PS/2s using an Intel i386SX processor or above, ship with at
least 4MB of memory installed as standard, and nearly all other PC vendors are
doing the same. Indeed, 8MB is no longer an unusual configuration, and many
high end machines can be installed with 16 and even 32MB of memory.
Furthermore, processor power is increasing rapidly, and Intel's i386 processor
family (i386SX and i386DX) has become the largest volume Intel processor
shipped in PCs. According to industry estimates, in 1991, the majority of new
PC shipments had a 386SX or above, and by the mid-1990s this figure will
increase to over 90% as the i486 ships in greater volume. In fact, recent
changes in the competitive microprocessor market, have led to large reductions
in prices on even 486 chips, particularly the 486SX, so that some vendors are
even using the 486SX as the mainstream processor across their product range.
Therefore, 32-bit processors, whether 386 or 486, completely dominate new
shipments of PCs.
The result of this is that the new PCs shipped have a minimum of a 386SX and
4MB of memory, and commonly a 486SX and perhaps 8MB. This enables
substantially more to be done with the PC platform and, in particular, an
advanced operating system base that can really begin to fulfil the PC's
potential.
Processor shipments and decreasing memory prices
ΓòÉΓòÉΓòÉ 4.3. OS/2 so far ΓòÉΓòÉΓòÉ
In the mid-1980s, IBM realised the need for an advanced platform, and saw that
single-tasking DOS was not likely to be able to meet these demands. IBM
therefore set out with Microsoft to develop OS/2. In 1987, the first
character-based version, OS/2 1.0 appeared, followed by the inclusion of the
Presentation Manager GUI in Version 1.1 (1988), and by Version 1.2 in 1989.
These were all based on the Intel 80286 (286) processor's protected mode, and
were therefore 16-bit releases. Intel 386-based machines were supported, but
their full 32-bit potential was not exploited because of the requirement to
support the large base of 286 machines at the time.
These first releases provided the basis for a "platform of the 1990s", but the
learning curve involved in providing the operating system function itself and
in developing applications to exploit it, proved a greater challenge than
expected.
In 1990, IBM took over chief responsibility for the 16-bit versions of OS/2,
and later that year, produced Version 1.3, which has become a widely used
platform among companies who are beginning to develop in-house
"line-of-business" applications, benefiting from its multi-tasking, large
memory, industrial strength robustness and protection between processes. In
addition, 1.3 provided these capabilities with lower memory requirements than
previous releases, while adding extra features such as high quality font
support via the built-in Adobe Type Manager.
Although OS/2 1.3 has been highly regarded as a platform for line-of-business
applications, limits in the capability of the 286 processor set bounds on what
could be achieved in terms of compatibility with the existing range of DOS
productivity applications. This, in turn, placed limits on the level of
integration between new applications and the existing, extensive installed base
of DOS applications.
OS/2 2.0, which first shipped in March 1992, has been designed to build on the
strengths of OS/2 1.3, such as multi-tasking and threading, robust protection
between applications, and large memory support. It adds to those facilities,
greater compatibility with the existing installed base of DOS and Windows
applications, so that users can choose from the widest range of applications on
an Intel-based platform. Because it is designed for 32-bit processors like the
386 and 486, it can escape the limitations of the 286, and provide not only a
better platform for supporting old applications, but a new foundation for
32-bit applications which can fully exploit the capabilities of the 32-bit
hardware. That is why OS/2 2.0 is the Integrating Platform, bringing together
the investments of the past, and providing a base for the future.
ΓòÉΓòÉΓòÉ 5. Why OS/2? ΓòÉΓòÉΓòÉ
This section summarises the reasons why OS/2 is the platform of choice for the
1990s:
ΓòÉΓòÉΓòÉ 5.1. The best of both worlds ΓòÉΓòÉΓòÉ
In the PC environment of the 90s, where both personal productivity and
line-of-business applications are required, only OS/2 can satisfy both needs.
It provides a better platform for DOS applications than DOS itself, and runs
the widest range of DOS and Windows applications, as well as being the best
platform for running in-house mission critical applications, with its
industrial strength, robust protection, and powerful multi-tasking. You don't
have to choose between different systems for your different needs - OS/2 can do
both.
ΓòÉΓòÉΓòÉ 5.2. Broad appeal ΓòÉΓòÉΓòÉ
OS/2 2.0 is, therefore, a platform of broad appeal, not just for high end
usage, or for niche applications like servers, but as a client system, and a
productivity machine. You do not need to be a "power user" to appreciate the
benefit of running several DOS and Windows applications on a reliable base. Not
only the features of the product, and the applications it can run, but its
price and the breadth of PC systems it can run on, have been planned to address
the widest possible audience of PC users. And this has already been proved to
be true. On August 12th, 1992, IBM announced that it had shipped one million
copies of OS/2 2.0 since its initial shipment in March. This represents,
according to data from independent estimates, an initial success comparable to
that claimed for DOS/Windows 3.0 in 1990.
During the first ten years of the PC, users, IS staff, and developers found it
difficult to arrive at a common platform: DOS and Windows satisfied the users's
needs for productivity applications, but lacked the reliability and full
connectivity support to be trusted in mission-critical environments by IS staff
and developers, whose systems remained mostly on the mini and mainframe.
However, OS/2 2.0 is a platform that can appeal to all three communities; the
right choice for the IS strategy, can now also be the platform that developers
and users can choose for themselves.
ΓòÉΓòÉΓòÉ 5.3. Freedom of choice ΓòÉΓòÉΓòÉ
Today's computing environment can be confusing: the sheer variety of options
can be overwhelming. And in making choices about hardware and software
platforms, it is difficult to follow a path which keeps a wide range of options
open. Too often choices can be constrained by compatibility issues or by a
limited growth path. OS/2 2.0 aims to simplify the decision by providing a free
choice: the widest range of applications on a wide range of hardware.
OS/2 2.0 can run DOS, Windows and OS/2 16-bit applications; it provides the
widest choice of applications on an Intel-based platform. More and more 32-bit
OS/2 applications are appearing, making the choice even greater. In fact, OS/2
2.0 is such a good environment for DOS and Windows applications, that even if
you only use DOS applications on a 386-based machine, OS/2 2.0 is the best
environment to run them in.
Furthermore, all applications running under OS/2 2.0, whether DOS, Windows or
OS/2 applications, gain added value from working together; they can share
information and be run from the common Workplace Shell desktop. This not only
protects your current investment in DOS, Windows and OS/2 applications, but
adds value to them by integrating them together.
OS/2 2.0, and Extended Services and OS/2 LAN Server, are supported on a wide
range of IBM-compatible hardware as well as IBM PS/2s. This means you can run
OS/2 with confidence on hundreds of machines from vendors including Compaq,
Olivetti, Dell, Hewlett Packard and Toshiba, and with IBM support. In fact,
even though IBM cannot test OS/2 on all the models and manufacturers in the
market, it is likely that most PCs equipped with an Intel 386SX or above
processor, will work.
ΓòÉΓòÉΓòÉ 5.4. A productive environment for the user ΓòÉΓòÉΓòÉ
OS/2 provides an object-oriented user interface, the Workplace Shell, which
allows users to think of the information they want to work with, not think
first of what application needs to be loaded. This is a business-oriented,
rather than computer-oriented way of working. In this way, users become more
productive. They can concentrate more on what they want to do, and less on how
to do it. The Workplace Shell also provides a single, consistent environment
in which multiple applications can be loaded from different sources. It is an
easy environment to learn, since once you know how to drag a file's icon with
the mouse to put it into a folder, you can use the same operation to print it,
and to copy it to another disk or folder. In addition, companies can benefit
from a standard interface, which complies with IBM's Common User Access (CUA)
definition for user interface design.
Also, since many applications can be loaded and running at the same time, users
can be more productive, especially in work that involves much interruption and
switching from one task to another. OS/2's true multi-tasking means that
long-running processes can simply be switched to the background, while the user
continues with something else. This results in less "wait time" for the user.
At the same time, more can be done with the existing set of applications by
allowing them to share information easily via consistent interfaces like the
clipboard.
ΓòÉΓòÉΓòÉ 5.5. Better DOS, Windows and OS/2 ΓòÉΓòÉΓòÉ
OS/2 2.0 doesn't just run the widest range of applications on an Intel
platform. It also aims to improve even on the native environment of each
application, and provide a better environment for that application to work in:
ΓòÉΓòÉΓòÉ 5.5.1. A better DOS ΓòÉΓòÉΓòÉ
it adds to the DOS environment: multi-tasking, more memory and application
integration (see Better DOS ).
ΓòÉΓòÉΓòÉ 5.5.2. A better Windows ΓòÉΓòÉΓòÉ
it provides a superior environment for running DOS applications than either
Windows 3.0 or Windows 3.1, and also runs a wide range of Windows applications
with no loss of function, as well as taking advantage of the better
multi-tasking, memory support, and reliability of OS/2 (see Better Windows ).
ΓòÉΓòÉΓòÉ 5.5.3. A better OS/2 ΓòÉΓòÉΓòÉ
it improves even on previous releases of OS/2 itself, providing a new
object-oriented user interface, a graphical install program, and access to
powerful 32-bit applications (see Better OS/2 ).
ΓòÉΓòÉΓòÉ 5.6. A platform you can rely on ΓòÉΓòÉΓòÉ
When the PC becomes the focal point of information processing, as in today's
environment it often is, then the PC platform must show the stability and
reliability of the host environment. The main reason why the PC has not been
trusted to fulfil this crucial role to date, is because its operating system -
DOS - was not designed for "mission critical" use, but as a personal
productivity environment. Nor can extensions to DOS such as Microsoft Windows,
offer the required stability while they continue to be based on DOS. Only OS/2,
which has been designed to protect applications from one another, can deliver
the stable platform required for full multi-tasking and greater protection from
system crashes. It is no use having the most fault tolerant server or host, if
the client keeps going down. And even the productivity user's PC is "mission
critical" from that user's perspective, so that reliability is a requirement
for every PC.
ΓòÉΓòÉΓòÉ 5.7. Superior connectivity ΓòÉΓòÉΓòÉ
OS/2 2.0 is both the server and the client platform of choice. Its strong
multi-tasking and robust protection make it the best available base for working
in a connected environment, in client-server and distributed processing. It
provides a consistent platform for both server and client, can handle multiple
concurrent communications protocols (eg NETBIOS, APPC, IPX, TCP/IP) with ease,
and even provides a LAN-independent user interface to mixed vendor networks. It
is enabled for automated LAN-based installation. But most important, OS/2
offers the stability and reliability in a client to match the reliability of
the server or host. The result is that "mission critical" applications which
depend on communications with various systems can be implemented much more
safely on OS/2 than on DOS or any of its extensions.
OS/2 2.0 is also the base system for a family of networking and communications
products from IBM, including Extended Services for OS/2 and OS/2 LAN Server.
Extended Services for OS/2 provides powerful communications and database
function in a single integrated package. It supports multiple communications
protocols (EHLLAPI, NETBIOS, APPC, X.25 and asynchronous) and terminal
emulators (3270, 5250, ASCII, VT100). It includes a full function
client-server relational database management system (RDBMS). This RDBMS is
part of an SAA family of relational databases which also includes DB2 and
SQL/DS. Extended Services for OS/2 also includes query and database management
tools.
OS/2 LAN Server works with OS/2 to provide Local Area Network support to DOS
and OS/2 machines. It includes facilities for sharing resources such as files
and printers, and to manage those shared resources, providing security control,
applications management, and network statistics.
Both Extended Services for OS/2 and OS/2 LAN Server 2.0 run on both OS/2 2.0
32-bit and the 16-bit OS/2 1.3.1 bases. OS/2 LAN Server 3.0 runs only on the
OS/2 2.0 base. Both Extended Services for OS/2 and OS/2 LAN Server are also
supported on selected non-IBM as well as IBM equipment. More details on these
and other networking products are available in the chapter on OS/2 in a
connected environment (see OS/2 in a connected environment ).
ΓòÉΓòÉΓòÉ 5.8. The integrated system ΓòÉΓòÉΓòÉ
OS/2 not only makes DOS, Windows and OS/2 applications run together, but also
provides a GUI, and, with Extended Services for OS/2 and LAN Server, database,
communications, and LAN support. For developers, all the Application
Programming Interfaces (APIs) and services have been designed to work together.
This means customers don't have to do the systems integration work with a
variety of DOS-based packages to include all the function required, and work
around any incompatibilities or problems. Instead, the OS/2 function has been
designed and tested to work together - IBM has already done the integration
work.
OS/2 also has advanced features built in and integrated with the rest of the
system: the Presentation Manager GUI itself, font handling with Adobe Type
Manager (ATM) (now for both OS/2 applications and Windows applications), REXX
(the extended batch language which can be used to integrate different
applications and automate common routines)
The Workplace Shell environment integrates DOS, Windows and OS/2 applications
and makes them work together, even though they may have been written by
different vendors and never designed to do so. Also, OS/2 can permit working
combinations (such as a 32-bit OS/2 word processor and a 16-bit DOS
spreadsheet) that would never have been possible before. In summary, the whole
is greater than the sum of the parts: in running not only OS/2, but DOS and
Windows applications, OS/2 makes them work together from the same user
interface. This helps reduce the differences between applications, and between
the local machine and the network, and make it all act as one system. That's
why OS/2 is the integrating platform.
ΓòÉΓòÉΓòÉ 5.9. 32-bit power ΓòÉΓòÉΓòÉ
OS/2 2.0 is the first mainstream 32-bit platform for Intel-based PCs. It offers
the ability to take full advantage of the performance of today's 32-bit PCs.
And over over 1000 32-bit OS/2 applications are being developed (several
hundred of which had already shipped by September 1992), to demonstrate what
can be achieved with a 32-bit system.
The OS/2 32-bit API also allows developers to create richer, more sophisticated
applications. It overcomes the constraints imposed by existing 16-bit systems
(see Why 32-bit OS/2? ). This allows applications like multimedia to exploit
their full potential and power. OS/2 provides this foundation today. Moving
to the OS/2 32-bit API now, gets developers ready for future developments in
OS/2, such as object-oriented technology, distributed computing and portability
to RISC. So 32-bit is not just about exploiting the power of today's
environments, but also to move forward to build for the future. But most of
all, OS/2 2.0 gives you the benefits of a 32-bit system NOW - no need to wait
for other alternatives with uncertain delivery dates.
ΓòÉΓòÉΓòÉ 5.10. Platform for growth ΓòÉΓòÉΓòÉ
The design of OS/2 not only preserves the investments of the past, but allows
maximum flexibility for future growth. It also makes the OS/2 system itself
ready to develop further (for portability to other processors, for example).
OS/2 will be the base of new developments for many of the features that will be
a requirement for the workstation of the mid-90's, such as multimedia,
object-oriented systems, support for the Distributed Computing Environment
(DCE) and portability across different processors. It has the extra power to
support such advanced features as they emerge. Requirements of this kind will
demand a robust, architected and powerful 32-bit system, and that system is
OS/2.
With OS/2 2.0, IBM has reaffirmed its commitment to OS/2, and its conviction
that the workstation of the 1990s requires a real advanced platform, not a
series of extensions to DOS, which is fundamentally ill-equipped for these
requirements.
ΓòÉΓòÉΓòÉ 5.11. Value for money ΓòÉΓòÉΓòÉ
OS/2 2.0 offers a "3 in 1" environment, with everything you need to run DOS,
Windows and OS/2 applications in the one package. It also includes a series of
productivity applications, utilities and games for which you need to pay extra
in the DOS world. OS/2 provides scalable font support for both Windows and
OS/2 applications with Adobe Type Manager at no extra charge. OS/2 2.0 offers
all this function at a price less than the combined cost of DOS and Windows
3.1, even before taking into account the extra utilities you would need to buy
under DOS or Windows to achieve the same function. Upgrading from DOS or
Windows makes the cost of moving to OS/2 even less.
ΓòÉΓòÉΓòÉ 5.12. Exploits today's investment, and is a base for the future ΓòÉΓòÉΓòÉ
OS/2 supports the widest choice of applications from the past ten years of the
PC, and is the best platform for the present requirement of client-server and
reliable connectivity. It also provides the best base for future technologies.
That's how OS/2 2.0 can integrate past, present and future requirements. It
already has NOW what other environments can only promise for the future, with
the best and most reliable migration path - why wait?
ΓòÉΓòÉΓòÉ 6. OS/2 2.0 key elements ΓòÉΓòÉΓòÉ
This section examines some of the key technologies and features of OS/2 2.0,
which affect all applications running in the system. The following sections
cover OS/2 from an application point of view, showing how it exceeds the
capabilities of DOS, Windows 3.x and previous releases of OS/2.
ΓòÉΓòÉΓòÉ 6.1. 32-bit ΓòÉΓòÉΓòÉ
OS/2 2.0 is the first version of OS/2 to support a 32-bit addressing system and
programming model. Although implemented on the Intel 386 and 486 family of
processors, it is really a 32-bit system rather than an Intel-specific system.
Mike Kogan, one of the lead designers of 32-bit OS/2 has said in his book The
Design of OS/2 2.0 (see Further reference materials ), "OS/2 2.0 was not
designed to be 386-specific, but rather 32-bit OS/2 implemented on the 80386
platform". Part of the design of OS/2 2.0 has been to leave the maximum
possible scope for future portability, both in the API and the subsystems like
Presentation Manager (PM).
OS/2 2.0's 32-bit design provides significant benefits to the user and the
programmer, including better performance, simpler programming and ease of
migration from 16-bit applications, as well as reinforcing the benefits of
inter-process protection associated with previous releases of OS/2.
ΓòÉΓòÉΓòÉ 6.1.1. Flat memory model ΓòÉΓòÉΓòÉ
OS/2 2.0 features a different memory addressing model from 1.3 - the flat
memory model. This enables each process to look at memory as a large linear
address space which can be addressed by a simple 32-bit offset (sometimes
referred to as "0:32"), as opposed to the segment/offset combination ("16:16")
required by OS/2 1.3 and other 16-bit systems like DOS and Windows. The 0:32
model therefore hides all details of segmented memory management from the
32-bit programmer, resulting in :
- much simpler programming
- better performing code
- greater portability to other instruction sets (ie non-Intel).
One example of better performance is in calling Dynamic Link Libraries (DLLs),
which are common in both the OS/2 system and OS/2 applications. Since all code
and data are addressable within the same linear address space, there is no
longer any need for segment switching.
ΓòÉΓòÉΓòÉ 6.1.2. Large memory address space ΓòÉΓòÉΓòÉ
Using the 32-bit flat memory model, the 386 processor supports up to a 4
gigabytes (GB) linear address space. In fact, up to 64 terabytes can be
addressed by the processor using a non-linear addressing model. To get some
idea of the enormity of such numbers, this means that, if an average page in a
book contained 2000 characters, and each book 500 pages, a task could address
any character in any book in a library with more than 70 million books
(70,368,744,177,664 characters to be precise)!
For reasons of compatibility with OS/2 1.x 16-bit applications, the address
space per process in OS/2 2.0 is restricted to 512MB (since this is the maximum
address space possible for 16:16 applications). This is addressed using the
flat memory model, allowing programmers to reference memory under OS/2 2.0 as
one single huge address space. Although 512MB is hardly likely to be a
limitation in practice, this memory limit will be removed in a future release
of OS/2.
Within a given process, memory objects can be allocated for any size, no longer
limited to the 64KB segment maximum, but any size between 1 byte and 512MB.
This gives the programmer much greater flexibility in memory management. For
the user, this means that programmers can spend more time on making their
programs more powerful and even easier to use, and less on segmented memory
management.
ΓòÉΓòÉΓòÉ 6.1.3. Virtual memory ΓòÉΓòÉΓòÉ
OS/2 2.0 can use more memory than is physically installed in most PCs, by using
the hard disk for additional memory, usually referred to as virtual memory.
Although 16-bit systems like OS/2 1.3 and Windows 3.x also offer memory
overcommit via swapping segments to disk, the larger process address space
available under OS/2 2.0 means that virtual memory is effectively limited only
to available disk space, whereas Windows 3.x can offer only 16MB maximum, or
four times the physical memory installed in the machine, whichever is less.
OS/2 2.0 takes advantage of the 386 processor's support for fast and effective
paging of memory to and from disk (see 4KB demand paging ). It is also not
limited to the segment-based swapping of OS/2 1.3.
ΓòÉΓòÉΓòÉ 6.1.4. Mixed 16-/32-bit environment ΓòÉΓòÉΓòÉ
Not only are OS/2 1.x applications supported, and are binary-compatible with
2.0, but OS/2 2.0 can support mixed model programming. In order to support
applications written for 16-bit, the OS/2 designers had to develop an
architecture in which 16- and 32-bit modules could reside simultaneously. This
was not only for ease of conversion from 16-bit programs, but also because the
system itself contains a mixture of 16- and 32-bit service routines. This is a
difficult task because segmented and flat memory models are so different.
OS/2 provides address conversion between 16:16 and 0:32 addresses, to allow
16-bit API calls to be serviced internally by 32-bit routines, and vice versa.
A series of procedures called "thunks" within the system facilitate this
process, by handling any necessary parameter conversion for APIs. This
technique is used internally between 16- and 32-bit parts of the system itself,
but the user never notices - the system takes care of it. They are tools
internal to the system, and not APIs for the programmer to learn and use - and
certainly no user needs to know how to handle them.
Note that the mixed model gives great flexibility, both in migrating
applications from 16- to 32-bit, and also in allowing 32-bit applications to
make the best possible use of existing 16-bit service routines, window classes
etc., developed for previous releases of OS/2. The important point here is how
OS/2 2.0 helps the migration process to 32-bit.
ΓòÉΓòÉΓòÉ 6.2. Intel 386/486 exploitation ΓòÉΓòÉΓòÉ
Since OS/2 2.0's 32-bit capabilities are implemented on Intel's i386 and i486
family of processors, it is not surprising that the system takes advantage of
some of the processor's features. Indeed, some of them (especially virtual
8086 mode) are vital to some of the most notable features of the system. It is
for that reason that OS/2 2.0 requires a 386SX processor or higher to run.
Unlike OS/2 1.3, it will not run on machines equipped with an 80286, nor will
it run on 8088 and 8086 machines supported by DOS.
ΓòÉΓòÉΓòÉ 6.2.1. Growth in processor power ΓòÉΓòÉΓòÉ
It is widely recognised how substantial have been the improvements in processor
speed and capacity, even since 1981 and the launch of the first IBM PC. Since
then, processor clock speed has increased by a factor of seven, and memory
address space by four thousand to one. This growth in processor power lowers
the cost of the hardware technology to run advanced operating systems and
applications. The software and hardware are now at a sufficiently advanced
stage, to enter a new phase of personal computing, beyond the basic
productivity applications that have characterised its usage to date (see
Cheaper processors and memory ).
ΓòÉΓòÉΓòÉ 6.2.2. 386/486 now majority of shipments ΓòÉΓòÉΓòÉ
PCs using the i386 family (which includes the SX as well as DX models) are now
shipping in greater volumes than any other Intel processor. Add to the number
of 386s the growing volumes in 486SX and DX processors, and there are a growing
number of 32-bit processors in the marketplace. Until OS/2 2.0, there has not
been a 32-bit system for Intel processors which has provided sufficient
compatibility with existing 16-bit applications, to become a standard.
ΓòÉΓòÉΓòÉ 6.2.3. 386SX versus DX ΓòÉΓòÉΓòÉ
It is important to understand that both 386SX and 386DX processors are
supported by OS/2. Even though the 386SX has a 16-bit external data bus, it is
a 32-bit processor internally, fully compatible with the 386DX processor's
instruction set, supporting multiple Virtual 8086 sessions (essential for the
Multiple Virtual DOS Machines features of OS/2 2.0), protected mode operation
and full 32-bit addressing. It can therefore support all of the features that
OS/2 2.0 provides, just as the 386DX does. The main difference is in the
throughput for I/O, owing to the 16-bit data bus. Nevertheless, many users
find it an excellent combination of 386 function, compatibility and performance
at a reasonable price. IBM's own 386SLC chip, which appears in, among others,
some models of the PS/2 Model 57, adds performance features such as caching to
the basic 386SX design; it represents an excellent platform for OS/2 2.0.
ΓòÉΓòÉΓòÉ 6.2.4. 486SX and DX ΓòÉΓòÉΓòÉ
All the 386 features used by OS/2 2.0 are also supported by the 486. Therefore
machines using a 486SX or 486DX will also run OS/2 2.0. In many operations, the
486 is faster than the 386, which will provide performance benefits to users of
OS/2 2.0 on 486-based machines. The 486SX is very similar to the 486DX, but
does not have the built-in math co-processor function which the 486DX has. The
price of the 486SX processor has fallen rapidly during 1992, so that machines
using 486SX can often be obtained at prices competitive with 386DX machines.
The 486SX therefore represents an economical entry into 486 power for OS/2 2.0.
ΓòÉΓòÉΓòÉ 6.2.5. Features of 386 chip used by OS/2 2.0 ΓòÉΓòÉΓòÉ
Among the specific features of the 386/486 processors supported by OS/2 2.0,
and used to provide additional function beyond OS/2 1.3, are:
Protected mode operation
Virtual 8086 mode
4KB demand paging
Numeric co-processor support
ΓòÉΓòÉΓòÉ 6.2.5.1. Protected mode operation ΓòÉΓòÉΓòÉ
To understand the significance of protected mode, let us briefly review some of
the different models of memory management which the 386 processor can use:
ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Memory management models Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé MODEL Γöé PROCESSORΓöé MAX Γöé ADDRESSINΓöé PRO- Γöé SYSTEM Γöé
Γöé Γöé ARCHI- Γöé PHYSICAL Γöé STYLE Γöé TECTION Γöé SOFT- Γöé
Γöé Γöé TECTURE Γöé ADDRESS Γöé (SEG- Γöé BETWEEN Γöé WARE Γöé
Γöé Γöé Γöé SPACE Γöé MENTED Γöé PROC- Γöé EXAMPLE Γöé
Γöé Γöé Γöé Γöé VS. Γöé ESSES Γöé Γöé
Γöé Γöé Γöé Γöé FLAT) Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Real Γöé 8086 Γöé 1MB Γöé seg- Γöé none Γöé DOS Γöé
Γöé mode Γöé Γöé Γöé mented Γöé Γöé Γöé
Γöé Γöé Γöé Γöé (64KB) Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Seg- Γöé 80286 Γöé (on 286) Γöé seg- Γöé yes Γöé OS/2 Γöé
Γöé mented Γöé Γöé 16MB Γöé mented Γöé Γöé 1.3, Γöé
Γöé Memory Γöé Γöé Γöé (64KB) Γöé Γöé Windows Γöé
Γöé Model Γöé Γöé Γöé Γöé Γöé 3.x Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Flat Γöé i386 Γöé 4GB Γöé flat Γöé yes Γöé OS/2 Γöé
Γöé Memory Γöé Γöé (16MB on Γöé Γöé Γöé 2.0 Γöé
Γöé Model Γöé Γöé 386SX) Γöé Γöé Γöé Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
In reality, operating systems like OS/2 create an architecture with indirect
selectors/descriptors rather than direct segment/offset addressing. This
provides memory protection between processes to support multi-tasking. This is
just one example of the ways in which an operating system builds on the base
capabilities of the processor. Virtual memory is another function provided by
the operating system but relying on a processor feature (in this case on the
286 and above).
In OS/2, all process address spaces are kept separate from each other. This
allows OS/2 to maintain protection between different processes running in the
system, whether they be DOS, Windows or OS/2 applications, or other parts of
the system itself. The result is that, if a process attempts to reference
memory outside its own address space, it is trapped by the system. In contrast,
multi-tasking systems based on single-tasking DOS, such as Windows, cannot
always offer protection. Windows applications, for example, share the same
Local Descriptor Table as Windows itself, which limits the memory protection
Windows can provide to its applications (see Reliability and Reliability and
protection ).
ΓòÉΓòÉΓòÉ 6.2.5.2. Virtual 8086 mode ΓòÉΓòÉΓòÉ
The 386 offers a mode called virtual 8086 (V8086) mode, which emulates multiple
instances of an Intel 8086 processor to provide some compatibility with real
mode applications (such as most DOS applications) under a protected mode system
(like OS/2 2.0). Applications running in V8086 mode, can run concurrently with
other 8086 applications and protected mode applications, and take advantage of
the virtual memory and paging facilities of the 386. V8086 mode is a superset
of protected mode.
The CPU provides high performance hardware support to enable switching between
V8086 and protected mode - this eliminates the performance overhead of mode
switching associated with lower processors such as the 286. This is why
multiple DOS capability can be provided so much more easily and more
effectively in OS/2 2.0, which requires the 386 facilities, than in OS/2 1.3
which was based on a 286-style architecture.
V8086 processes are protected from each other in OS/2 2.0. This gives
compatibility with the real mode world of DOS applications while providing
greater address space and protection. In OS/2 2.0, each Virtual DOS Machine
(VDM) is encapsulated in its own unique linear address space, and thus cannot
corrupt another application's code or data. Traps or exceptions are handled by
the VDM Manager in OS/2 2.0, and execution is passed to an exception handler,
or the VDM terminated. Therefore, OS/2 2.0 runs in protected mode all time,
even for DOS applications, hence the greater protection of the system against
application errors or failures.
In real mode, an application can directly address any object in memory between
0 and 1MB, including portions of the operating system (whether this be DOS,
DOS/Windows, or OS/2 1.3, all of which provide varying amounts of real mode
execution). A DOS program that accidentally wrote to a system area, or
directly addressed a hardware device and left it in an unknown state, could
cause system integrity problems. Real mode is less of an issue in a
single-tasking system like DOS, where it is more than likely that the
application is the only one executing in the system; but in a multi-tasking
system, it represents a "trap door", which can endanger system integrity. This
is part of the difficulty in running a multi-DOS environment like Windows 3.0
or 3.1 on a DOS base; as long as there is real mode access (as long as it runs
on DOS as we know it today), there is a potential risk. In fact, even Windows
3.1 , which is claimed to offer greater protection and stability, does not
change the design of Windows in this respect. It is still possible for a DOS
Terminate-and-Stay-Resident (TSR) program to switch the system into real mode
and open up the potential for endangering system integrity (see Reliability for
more on this).
The only solution is to run the operating system in protected mode, and provide
a multi-DOS mode using features like V8086, so that the system never runs in
real mode. This is exactly what OS/2 2.0 does, and it is one of the key
differences between it and Windows 3.x in terms of overall integrity: Windows
implements V8086 function in a system running on DOS, and some real mode access
is inevitable - hence its occasional fragility when working with DOS
applications or TSRs; OS/2 2.0 never executes in real mode.
ΓòÉΓòÉΓòÉ 6.2.5.3. 4KB demand paging ΓòÉΓòÉΓòÉ
Demand paging is the 386's method of providing virtual memory to the system;
when physical memory is exhausted (memory "overcommitment"), the disk may be
used to provide additional virtual memory. Memory overcommit is provided on
286-based operating systems such as OS/2 1.3 as well, but is usually based on a
segment-swapping mechanism. As the name suggests, segment swapping is closely
tied to the segmented model used in OS/2 1.3, and the swapper algorithm has to
do much work to compact segments of varying sizes into a unit capable of being
swapped to disk, or much I/O work in swapping large segments.
OS/2 2.0 manages memory internally using pages, each of which is 4KB in size.
Each memory object handled by the system is regarded as a set of one or more
pages, and therefore memory is allocated in units of 4KB (although to optimise
memory management, programmers may handle a page as multiple smaller objects).
Paging offers a number of advantages over swapping, which was the mechanism
used in OS/2 1.3:
Better granularity: when memory becomes over-committed (ie there is no more
real memory left to load applications), individual 4KB pages may be swapped to
and from disk, rather than entire memory objects (or segments as in OS/2 1.x).
In turn, this will improve performance, especially in terms of the lower I/O
cost of moving 4KB pages as opposed to whole segments.
Programmers can write their applications to take advantage of the smaller
granularity of memory object (ie 4KB page as opposed to a whole segment). This
will reduce the working set (overall memory usage) of applications and thence
improve performance. Memory objects can be allocated in logical units, without
the artificial constraints of segment sizes; this means that you can allocate
smaller or larger memory objects according to the needs of the application,
rather than the constraints of the system. Once again, this makes programming
much simpler.
It is important to remember that paging is carried out without any awareness on
the part of the application. Programmers may allocate memory to co-operate
with this mechanism for performance reasons, but the user need not be aware of
the paging system at all. It will simply translate into the performance
benefits mentioned above.
Simpler swap algorithm: because of the more granular paging, OS/2 2.0 does not
need to move around different sized segments to compact them into a single swap
segment of the right size, as was done in 1.x. This makes the swap algorithm
simpler and therefore faster, improving overall system performance. Indeed,
unlike OS/2 1.x, the swapper file, SWAPPER.DAT is designed to actually shrink
as well as grow during use of OS/2 2.0. This is in order that applications
requiring high availability (such as LAN servers) do not need to be rebooted to
recover swap disk space.
The 386 has hardware support, such as buffering and caching, to support paging.
Once again, OS/2 is taking advantage of the processor's built-in features.
ΓòÉΓòÉΓòÉ 6.2.5.4. Numeric co-processor support ΓòÉΓòÉΓòÉ
Some OS/2 applications can make use of an i387 numeric co-processor if one is
installed in a 386 PC running OS/2 2.0 (or 486DX systems, which have
co-processor function built in). Where a 387 is not installed, OS/2 2.0
provides a 387 emulator to all applications running in protected mode,
available to both 32-bit and 16-bit applications, but not VDMs running DOS
applications. DOS applications must continue to use whatever mechanisms they
are currently using to detect co-processor presence.
ΓòÉΓòÉΓòÉ 6.3. Multiple Virtual DOS Machines (MVDM) ΓòÉΓòÉΓòÉ
OS/2 2.0 features a totally redesigned environment for DOS compatibility. It is
based on the Virtual 8086 mode of the 386 processor, and results in a DOS
environment where multiple DOS applications can be run, each in their own
separate "virtual machine". "Virtual machine" means that the virtual 8086 mode
process simulates a self-contained DOS environment, in which the application
runs. Access to I/O resources is usually not done directly to the physical
device, but via a virtual device; this virtualisation allows the DOS
application to believe it owns all the system resources, just as it does under
DOS. Behind the scenes, the OS/2 system manages concurrent access to these
physical resources, from both DOS and OS/2 applications.
Each Virtual DOS Machine, or VDM, emulates an entirely independent instance of
DOS. It is in fact a generic emulated version of DOS (which resembles DOS
5.0), not the real DOS retail product. Each VDM is a separate process,
protected from the others, and multi-tasking alongside the others. This design
allows OS/2 to provide superior support for DOS applications than in previous
releases of OS/2.
ΓòÉΓòÉΓòÉ 6.3.1. Contrast with OS/2 1.3 DOS support ΓòÉΓòÉΓòÉ
It is useful to look at the OS/2 2.0 DOS support in the light of 1.3's DOS
support. The following table gives a summary of the key difference in DOS
support between 1.3 and 2.0:
ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 2. DOS environments - OS/2 1.3 and 2.0 compared Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Γöé OS/2 1.3 Γöé OS/2 2.0 Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Processor mode Γöé Real mode Γöé V8086 mode Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Protection/Integrity Γöé Low Γöé High Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Number of DOS applica- Γöé 1 Γöé up to 12 full Γöé
Γöé tions Γöé Γöé screen; up to Γöé
Γöé Γöé Γöé 240 windowed Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Background execution Γöé No Γöé Yes Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Windowed Γöé No Γöé Yes Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Cut and Paste Γöé No Γöé Yes Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Conventional memory free Γöé 512KB Γöé 633KB Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DOS Extended Memory Γöé None Γöé 16MB per appli- Γöé
Γöé Γöé Γöé cation (XMS) Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé EMS/XMS Γöé No Γöé Yes Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DPMI Γöé No Γöé Yes Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Overcommit Γöé Swap Γöé Page - Avail- Γöé
Γöé Γöé Γöé able disk Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Timing Dependent applica- Γöé Foreground Γöé Foreground / Γöé
Γöé tions Γöé Γöé Background Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Recover from hang/crash Γöé Sometimes Γöé Usually Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
Let's take a look at some of these aspects in more detail:
ΓòÉΓòÉΓòÉ 6.3.1.1. 286-based architecture ΓòÉΓòÉΓòÉ
OS/2 1.3 On the 286, there is no V8086 mode, so 1.x had to run DOS
applications in real mode, thus requiring a protect-to-real mode
switch when moving from an OS/2 to DOS application. This involves
significant performance degradation (see below).
OS/2 2.0 DOS applications run in V8086 mode. No protect-to-real mode
switching is needed.
ΓòÉΓòÉΓòÉ 6.3.1.2. Relative performance ΓòÉΓòÉΓòÉ
OS/2 1.3 A switch from real mode to protected can be done on a 286 (though
it costs many CPU cycles). A switch the other way, from protected
to real, means effectively rebooting the CPU, but OS/2 has to
preserve all the system control information, process states etc, at
the same time, so that the normal processing can continue after the
switch. This switching back and forth from real (DOS box) to
protected (rest of 1.x) generates significant overhead. This can
mean that OS/2 background tasks are slowed significantly when
running a DOS application in the foreground.
OS/2 2.0 DOS applications run in V8086 mode. No protect-to-real mode
switching is needed.
ΓòÉΓòÉΓòÉ 6.3.1.3. System integrity ΓòÉΓòÉΓòÉ
OS/2 1.3 Since 1.3 does not run always in protected mode (unlike 2.0), any
switch into real mode allows an errant DOS application to directly
address any object in memory under 1MB, including portions of the
OS/2 1.x kernel (the same is true in Windows 3, hence its
comparative lack of integrity.)
Also, DOS applications could directly address a hardware device and
leave it in an unknown state, which may cause OS/2 device drivers
to fail.
Either of these scenarios could cause the whole system to crash.
OS/2 2.0 All OS/2 2.0 processes, including DOS applications in VDMs, are
protected from each other, and cannot write outside their own
address space. Hardware access is controlled through Virtual Device
Drivers (see Virtual Device Drivers (VDDs) ), which handle the
DOS-OS/2 hardware concurrency problem.
ΓòÉΓòÉΓòÉ 6.3.1.4. Background execution ΓòÉΓòÉΓòÉ
OS/2 1.3 DOS applications are suspended when not in the foreground. This was
a decision made in 1.x, mainly to avoid the overhead in
real-protected-real mode switching; it means that timing dependent
applications like communications programs are unsuitable for
running in an OS/2 1.3 DOS box, as they cannot receive interrupts
while suspended.
OS/2 2.0 In 2.0, the virtualisation of interrupts and hardware access allows
most communications programs to run in background in a VDM.
ΓòÉΓòÉΓòÉ 6.3.1.5. Amount of memory ΓòÉΓòÉΓòÉ
OS/2 1.3 Since DOS applications run in real mode, some of the OS/2 device
driver and kernel code has to be located below 1MB to service the
real-mode (DOS box) requests. This has an inevitable result on the
amount of memory available below 1MB, and therefore on DOS
application space, which, in 1.3, depending on the configuration,
is about 520KB. This prevents some larger DOS applications from
even loading. No EMS or XMS support is provided in 1.3.
OS/2 2.0 OS/2 2.0 locates most driver and even DOS emulation code outside
the DOS application's address space in a VDM. This provides even
more conventional memory than under standalone DOS, and full
support for EMS and XMS (see below).
ΓòÉΓòÉΓòÉ 6.3.2. Memory: Conventional, Expanded, Extended ΓòÉΓòÉΓòÉ
Memory management under DOS today is quite complex, and often requires the user
to know about various different memory types. To support some DOS
applications, OS/2 2.0 needs to provide more than just conventional memory.
ΓòÉΓòÉΓòÉ 6.3.2.1. Definitions ΓòÉΓòÉΓòÉ
The diagram below shows some of the types of memory commonly referred to, and
is a useful reference for the discussion below:
Memory: Conventional, Expanded, Extended
Conventional memory is the name given to the memory area up to 640KB
accessible by DOS applications.
Extended Memory refers to any memory above the 1MB line addressed by the
processor in protected mode. (1MB is the normal limit addressable by the
processor in real mode). The LIMA (Lotus/Intel/Microsoft/AST) Extended Memory
Specification (XMS) version 2.0 provides a standard for the use of extended
memory on 80286 and above computers. The specification provides for moving
code and data objects to and from extended memory to base (conventional)
memory, and is operating system independent (even though the technique for
determining that XMS is present relies on the DOS interrupt vector 2Fh). XMS
manages 3 different kinds of memory, described below:
- High Memory Area (HMA)
- Extended Memory Blocks (EMBs)
- Upper Memory Blocks (UMBs)
High Memory Area (HMA) is the region of memory between 1MB and the 64KB above
it (minus 16 bytes). This can be addressed by enabling one of the processor's
address lines to allow the processor to access an extra 64KB beyond the normal
1MB limit in real mode. Its operation is due to an anomaly in the 286 and
above, which has been exploited by this technique to give a valuable extra
address space. Drivers like HIMEM.SYS, which appear in DOS 5.0 and MS-Windows
3.x, exploit this technique.
Extended Memory Blocks (EMBs) are blocks of extended memory above the HMA, not
accessible from real mode and serve usually as data storage. An XMS driver can
move memory between extended and conventional memory to offer up to 64MB of
extended memory in up to 255 blocks.
UMA, UMBs: between 640KB and 1MB (the limit addressable by the processor in
real mode) lies the Upper Memory Area (UMA). In this area are reserved
portions of memory for BIOS, video buffers etc. Usually, however, there are a
number of address ranges not used (for example, since there are address ranges
for monochrome, CGA and EGA adapters, it is not possible to use all of these
ranges at the same time. Thus there will be a number of "gaps" in the UMA.
These can be used by memory managers such as exist in DOS 5.0 itself, or by
third party utilities such as Quarterdeck's QEMM product. They can be used to
load various drivers, or in DOS 5.0's case, even part of the system itself, to
free more memory below the 640KB line. The address ranges used in this manner
are usually called Upper Memory Blocks or UMBs. The number and size of UMBs
will depend on the hardware configuration.
Expanded Memory (EMS) is a page mapping technique that provides additional
memory support, by allowing DOS applications to allocate and access up to 32MB
of additional memory. This is done by creating memory objects in expanded
memory that can be mapped into the real mode 1MB address space, thus allowing
DOS applications to access address spaces beyond 640KB at the cost of having to
quickly remap the memory that is to be accessed. In effect, parts of the 8086
address space become moving "windows" into larger virtual memory objects in an
expanded memory area. The expanded memory specification was developed by
Lotus, Intel and Microsoft, and is thus known as LIM EMS. The latest version of
the specification is 4.0. EMS is provided under DOS either by a special memory
adapter and driver, or by defining portions of memory above 1MB for use as
expanded memory by a driver that sometimes ships with DOS (eg EMM386.EXE with
DOS 5.0).
DOS Protect Mode Interface (DPMI): The DPMI specification provides a standard
interface that can access memory above 1MB and is addressable by computers with
an Intel 80x86 (or later) microprocessor. The specification was created by a
group of eleven companies in the industry (including Microsoft, Lotus and
Intel, as well as Quarterdeck, Rational Systems and Phar Lap), to allow
multiple DOS extender applications to multi-task reliably under a multi-tasking
environment. It superceded the VCPI specification (see below).
DPMI is a specification that exists in two versions. The 0.9 version was
implemented in Windows 3.0. The 1.0 specification added new features while
remaining fully compatible with 0.9. OS/2 2.0 is compatible with the 0.9 level,
and adds some 1.0 features.
Virtual Control Program Interface (VCPI) is an earlier DOS extender
specification, created by Phar Lap and Quarterdeck. While it allowed 386
expanded memory managers and DOS extenders to coexist, it did not address the
problem of DOS extenders coexisting within a multi-tasking environment.
Examples of applications written to this specification include Lotus 1-2-3
version 3.0 and Autocad/386 (Lotus 1-2-3 3.1+ changed the type of extender used
from VCPI to DPMI).
ΓòÉΓòÉΓòÉ 6.3.3. MVDM memory management ΓòÉΓòÉΓòÉ
MVDMs support all of the above types of memory, providing Virtual Device
Drivers for both EMS and XMS functions, thus allowing DOS applications all the
memory management functionality possible under DOS, including use of UMBs for
the DOS 5.0 LOADHIGH, DEVICEHIGH commands and for TSRs. Indeed, DOS emulation
in OS/2 2.0 VDMs owns the UMBs, but can free them for application use with
statements in CONFIG.SYS or in DOS Settings. Note that the availability and
size of UMBs depends on the same principle as under DOS (ie configuration of
that DOS virtual machine). VDM DOS settings like MEM_INCLUDE_REGIONS and
MEM_EXCLUDE_REGIONS allow some detailed configurable control over UMBs for
separate VDMs. This is an advantage over DOS itself, which for obvious reasons
can only apply one UMB configuration for all DOS applications that load,
leading to many DOS users maintaining multiple CONFIG.SYS files for their
different required configurations, and rebooting between them.
OS/2 2.0 provides Virtual Device Drivers (VDDs) for both EMS and XMS. The
Virtual Expended Memory driver (VEMM.SYS) supports up to 32 MB of expanded
memory per VDM, and the Virtual Extended Memory driver (VXMS.SYS) up to 16MB
per VDM. These figures could be made higher, but are restricted for
compatibility with EMS and XMS support under DOS. DPMI applications can access
up to 512MB in OS/2 2.0. In contrast, DOS and DOS extenders like Windows 3.x
can offer extended memory only up to four times the physical memory in the
machine or 16MB, whichever is less.
Virtualising EMS, XMS access means one VDM's use of memory does not affect
others - more than one VDM can use XMS and EMS.
EMS and XMS memory is mapped into the system's linear address space, and
managed just like any other allocated memory. VEMM is compatible with LIM EMS
4.0 specification, and VXMS compatible with LIMA version 2.0 functions. The
amount of EMS or XMS is configurable in CONFIG.SYS or in DOS settings.
ΓòÉΓòÉΓòÉ 6.3.3.1. Protection ΓòÉΓòÉΓòÉ
VDMs operate in entirely separate process address spaces, and are controlled by
a VDM Manager. They can thus be terminated on detection of illegal
instructions without affecting the rest of system, or when the application is
"hung". Thus problems in one VDM do not corrupt others, nor the system.
ΓòÉΓòÉΓòÉ 6.3.3.2. Memory management ΓòÉΓòÉΓòÉ
Since VDMs take advantage of the virtual memory and paging facilities of the
386, they are swappable and, therefore, starting several DOS sessions will not
significantly increase system memory requirements. Note, also, that each DOS
session is individually configurable, so that EMS and XMS support can be
switched off if not required, reducing overall virtual memory requirements. As
always, of course, there is a balance to be made between memory usage and
performance when overcommitting memory.
ΓòÉΓòÉΓòÉ 6.3.3.3. DOS emulation ΓòÉΓòÉΓòÉ
All DOS services (eg I/O) are emulated within the MVDM kernel or passed to the
OS/2 kernel (eg file services). Most of this emulation runs in protected mode
outside the VDM (hence the large amount of DOS memory available). All
documented (and some undocumented) DOS features are supported (such as device
driver loading/support, program loading and execution, memory management) as
well as all documented (and some undocumented) DOS interrupts (INT 20h, INT
21h, INT 27h etc). This provides a highly compatible "DOS 5.0-like"
environment.
ΓòÉΓòÉΓòÉ 6.3.3.4. Input/Output ΓòÉΓòÉΓòÉ
File Input/Output (I/O) in VDMs is made through the OS/2 file system, which,
via VDM DOS emulation, provides a compatible interface to file I/O for DOS
applications. Thus DOS applications can, without modification, take advantage
of OS/2's Installable File Systems (IFS) like HPFS, and the enhanced FAT (see
File systems ). Other I/O is performed either by DOS emulation or via Virtual
Device Drivers (VDDs), such as BIOS, video, printer, keyboard (see below). DOS
applications may continue to run and access system resources quite unaware that
those resources are virtual, and real access to devices is provided by OS/2 2.0
itself. This guarantees compatibility but also allows DOS applications to take
advantage of the inherent strengths of the OS/2 environment.
ΓòÉΓòÉΓòÉ 6.3.4. Virtual Device Drivers (VDDs) ΓòÉΓòÉΓòÉ
OS/2 2.0 isolates DOS and Windows applications from I/O devices that are
controlled by OS/2 device drivers, by emulating, or virtualising them for one
or more DOS or Windows applications. This is done by Virtual Device Drivers
(VDDs). VDDs provide a virtual instance of the real hardware, which is
controlled by a physical protected mode driver (PDD - see PDDs below).
ΓòÉΓòÉΓòÉ 6.3.4.1. VDD features ΓòÉΓòÉΓòÉ
VDDs therefore provide the following support:
1. Protection: VDDs allow DOS applications to access hardware and BIOS without
affecting other VDMs or other protected mode processes. This prevents VDMs
from corrupting each other, or the system.
2. Virtualisation: VDDs avoid direct hardware access from DOS applications,
but provide a virtual, or emulated, hardware state that lets the
application think it is doing so. To do this, they maintain a virtual
hardware state for each VDM. This means applications can, for example,
access BIOS and video RAM (as Lotus 1-2-3 does), and receive hardware and
software interrupts. In addition, VDDs can either perform I/O through a
PDD, or directly address an I/O device itself for greater performance. In
this way, virtual video drivers can support fast screen I/O to match
performance expectations of DOS users working with programs like 1-2-3.
3. Sharing: VDDs allow sharing of devices across the system between DOS and
OS/2 applications where there is a VDD/PDD combination for that device.
There is also support for many DOS device drivers, to allow devices that do
not have a VDD/PDD combination, to be supported in a VDM, for access
exclusive to that VDM.
4. Memory: the VDD is a protected mode driver which allows virtual device
driver support to be loaded above the VDM's first megabyte of address
space. This means that there is no memory impact on the use of VDDs for DOS
applications. Only where DOS device drivers need to be loaded is there any
impact under 1MB, and then the same as in DOS.
ΓòÉΓòÉΓòÉ 6.3.4.2. PDDs ΓòÉΓòÉΓòÉ
Physical Device Drivers (PDDs) correspond to OS/2 device drivers in 1.3, but
with an important difference: they execute entirely in protected mode, unlike
the bimodal 1.x device drivers. Real mode interrupt handling is no longer
required since VDMs run in V8086 mode - all interrupt processing is therefore
done in protected mode. Most OS/2 1.x device drivers work "as is": the part
of the driver capable of being run in real mode (needed for the 1.x DOS
compatibility box) is not supported, but their protected mode portion will
usually work. However, an old 1.x device driver is unlikely to service VDMs,
because the VDD requires support from the PDD that does not exist in older
drivers.
This also means that no portion of the OS/2 device drivers needs to be located
below the 1MB line, and therefore increases the size of the environment
available to DOS applications. But DOS applications may still make use of
these PDDs through the VDD interface.
ΓòÉΓòÉΓòÉ 6.3.4.3. How VDDs work ΓòÉΓòÉΓòÉ
VDDs work by facing two ways: to the application, providing a virtual hardware
state, and to the PDD or device, performing the physical I/O.
At boot time, VDDs are loaded, and many establish communications with the
corresponding PDD via a direct call interface. The list in the section VDD
examples shows which VDDs have a direct interface with an OS/2 PDD. The VDD
controls the DOS application's access to the device, and relies on the PDD to
manage the physical hardware operations.
The example below, and the accompanying diagram, show how the virtual COM
driver (VCOM.SYS) works.
1. The COM PDD services all hardware interrupts from the asynchronous ports,
and buffers the data being transmitted or received.
2. The direct call interface between the VDD and PDD allows the VCOM to
emulate asynchronous BIOS functions to send and receive characters, or to
set and query the state of a COM port, as well as receive the interrupts
passed on by the PDD.
3. All of the time, the DOS application believes it is controlling these
functions itself (just like it would under DOS), and is having interrupts
and data from the PDD and the COM port reflected back to it by the VDD to
maintain the illusion. The DOS application is therefore accessing only a
virtual copy of the COM port. The VDD gets control when a DOS application
performs direct I/O to a port (IN our OUT instructions), or via BIOS or
other software interrupts (INT instructions).
4. OS/2 applications can simultaneously access the COM functions via the PDD
using normal OS/2 function calls like DosOpen.
HowVDDswork
Not all VDDs need to operate with a PDD in this way. Some VDDs (eg video)
directly access the device for performance reasons. DOS applications still do
not address the device directly themselves - the VDD still virtualises the I/O
to the DOS application.
The VDD/PDD interface is required where hardware interrupts need to be
simulated into one or many VDMs (COM is a good example). This is important so
that DOS applications that want to control the hardware device directly, do not
need to get control at interrupt time, but can be deferred until the OS/2
kernel dispatches the VDM task. This preserves system integrity and maintains
overall system performance. This interrupt latency, as it is called, may cause
problems for a minority of applications that are highly dependent on real-time
interrupts. But the vast majority of DOS applications, even high speed
communications, can be dealt with successfully.
VDDs can be made swappable, and are installed using DEVICE= statements in
CONFIG.SYS.
Additional VDDs can be written by third parties for their devices, via a
published programming interface, using the Virtual Device Helper (VDH) services
provided by the MVDM kernel.
A VDD is required only if a device will be shared with other VDMs or OS/2
processes. If a particular device is to be used exclusively by one DOS
application, the DOS device driver may be used. Thus, OS/2 2.0 can provide
"generic" support to most DOS device drivers, but such support is limited to
that VDM. It does provide greater compatibility and a wider support of devices,
enhancing the DOS compatibility of OS/2 2.0 (see DOS device drivers for more).
DOS Device drivers can be loaded via the DOS Settings (see DOS Settings ).
ΓòÉΓòÉΓòÉ 6.3.4.4. VDD examples ΓòÉΓòÉΓòÉ
VDDs exist for most of the common device types. The following table lists some
of the ones that are included in OS/2 2.0:
ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 3. Virtual Device Drivers Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé NAME Γöé DESCRIPTION Γöé INTERFACES Γöé
Γöé Γöé Γöé WITH PDD Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé VBIOS Γöé DOS system areas like ROM BIOS Γöé Γöé
Γöé Γöé and interrupt vector tables are Γöé Γöé
Γöé Γöé mapped from physical memory into Γöé Γöé
Γöé Γöé the VDM address space by Γöé Γöé
Γöé Γöé VBIOS.SYS. Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé VCDROM Γöé CD-ROM support Γöé * Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé VCMOS Γöé CMOS data area and Real time Γöé Γöé
Γöé Γöé clock support Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé VCOM Γöé Asynchronous COM ports Γöé * Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé VDMA Γöé Direct Memory Access (DMA) Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé VDPMI Γöé DOS Protect Mode Interace - used Γöé Γöé
Γöé Γöé in WIN-OS/2 and applcations like Γöé Γöé
Γöé Γöé Lotus 1-2-3 3.1+ Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé VDPX Γöé DOS Protect Mode Extender Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé VDSK Γöé Disk/diskette, only for INT 13 Γöé * Γöé
Γöé Γöé copy-protection Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé VEMM Γöé Expanded memory support - up to Γöé Γöé
Γöé Γöé 32MB per VDD Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé VFLPY Γöé Floppy disk interface Γöé * Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé VKBD Γöé Keyboard - also has INT 9h emu- Γöé * Γöé
Γöé Γöé lation code to perform functions Γöé Γöé
Γöé Γöé usually performed by CBIOS, such Γöé Γöé
Γöé Γöé as key and scan code queuing, Γöé Γöé
Γöé Γöé update of keyboard LEDs, and Γöé Γöé
Γöé Γöé processing for Print Screen, Γöé Γöé
Γöé Γöé SysReq, Break and Pause (INT 5h, Γöé Γöé
Γöé Γöé INT 15h, INT 1Bh respectively). Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé VLPT Γöé Printer Γöé * Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé VMOUSE Γöé Mouse Γöé * Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé VNPX Γöé Numeric co-processor (x87) Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé VPIC Γöé Programmable Interrupt Controller Γöé Γöé
Γöé Γöé (8259) Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé VTIMER Γöé Timer Γöé * Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé VWIN Γöé For WIN-OS/2 "seamless" support Γöé * Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé VXMS Γöé Extended Memory (XMS) specifica- Γöé Γöé
Γöé Γöé tion - up to 16MB per VDD Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Video Γöé Supports all documented video Γöé * Γöé
Γöé (VCGA, Γöé modes from mono to XGA, including Γöé Γöé
Γöé VMGCA, Γöé the documented modes of VGA and Γöé Γöé
Γöé VEGA, Γöé 8514/A. Γöé Γöé
Γöé VVGA, Γöé Γöé Γöé
Γöé V8514, Γöé Γöé Γöé
Γöé VXGA, Γöé Γöé Γöé
Γöé VSVGA) Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé refers to base set of VDDs automatically loaded at system Γöé
Γöé initialisation time; others can be loaded via DEVICE= state- Γöé
Γöé ments in CONFIG.SYS. Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
ΓòÉΓòÉΓòÉ 6.4. Multi-tasking ΓòÉΓòÉΓòÉ
OS/2 has always been highly regarded for its industrial-strength multi-tasking
design. OS/2 2.0 continues those strengths, harnessing the CPU-level support
of the 386 processor for even more efficient multi-tasking.
ΓòÉΓòÉΓòÉ 6.4.1. Why do I need multi-tasking? ΓòÉΓòÉΓòÉ
Some people believe that they do not need multi-tasking, on the premise that "I
can only manage one thing at a time myself". However, the simplest way of
understanding the need for multi-tasking is to imagine what happens when you
get an interruption at work. Consider this simple scenario:
You are working on a report (using your word processor) when the telephone
rings. It's the boss, and he wants the latest sales figures from you now.
Quickly, you stop what you're doing, put aside the word processor, and connect
to the database to run the report routine. While logging on and running the
report, you start your spreadsheet program, so you can put the report from the
database into the spreadsheet, to make some extra calculations that are
required. When the report has run and the spreadsheet has recalculated, you
take the figures into your charting program to make a graph. You may also wish
to cut and paste this graph into a new document that you create with your word
processor (which you call up quickly after you put it aside) to explain the
figures to the boss. In addition, if you are a cautious person, you may back
up the report you have created and keep your own copy on diskette (in which
case it would have been nice to have started that formatting five minutes ago
when you were logging on!) Once you've created the new document, with the
latest sales figures and calculations shown in a graph, you may wish to send it
to the boss via electronic mail. Finally, you can return, after a brief rush
of activity, to your original report where you left it.
Such a scenario is characteristic of much of our work. Many of us are driven by
interruptions. In fact, it is not an exaggeration to say that any PC user who
has a phone can benefit from multi-tasking. The benefits are obvious:
o handle interruptions
o less waiting for one operation to complete (the "hourglass" in Windows 3.x is
a sign of a platform with only limited multi-tasking)
o let the computer do the work while you stay productive
o handle "beneath the covers" function like logging on, printing and running
database reports
o give smooth, even performance between different tasks
But perhaps the most persuasive argument is to imagine how the above scenario
would have been achieved using DOS!
ΓòÉΓòÉΓòÉ 6.4.2. What is pre-emptive multi-tasking? ΓòÉΓòÉΓòÉ
Most users understand that multi-tasking allows more than one application to
run at once. Of course, without multiple processors, they do not actually
execute instructions simultaneously - the CPU still only processes one
instruction at a time, but the operating system can divide CPU time between
several processes to make it appear to the user that those processes are
executing simultaneously. Therefore most multi-tasking operates on the basis
of some form of CPU time-slicing.
Furthermore, it is important to distinguish between multi-tasking, where
applications continue to execute when in the background, and context switching,
where they lie dormant until given the user focus. Some environments (such as
OS/2 1.3 DOS Box, Windows 3.x standard mode, and DOS 5.0's Task Switcher) are
only context switching. In these cases, the background task does not receive
CPU cycles, and time is devoted only to foreground tasks.
Some of the tasks in the scenario outlined above can be achieved using systems
that offer only context-switching, or non-pre-emptive multi-tasking. But a
pre-emptive multi-tasking system would allow the whole job to be achieved
faster and more efficiently, because the overall performance of the system
would be more balanced (see Why is it important? ). Systems management tasks
like background "agents" to collect configuration and performance data, are
very difficult to implement except in a pre-emptive multi-tasking system (see
OS/2 for client-server ).
Multi-tasking is pre-emptive when the processor allocates a finite time to each
task, and then switches the processor to another task, even if the first task
is not "ready" to give up the processor. Non-pre-emptive implies that tasks
can "hold on" to the processor within certain limits.
ΓòÉΓòÉΓòÉ 6.4.3. Why is it important? ΓòÉΓòÉΓòÉ
To understand the significance of the difference between pre-emptive and
non-pre-emptive multi-tasking, it is useful to contrast the approach taken by a
DOS multi-tasker like Windows 3.x, with OS/2's approach.
Multi-tasking under Windows 3.x
Windows 3.x implements a time-slicing scheduler on top of DOS, which is in
itself a single-tasking operating system. In Windows Enhanced mode (which
requires a 386 or above - see Windows 3.x modes ), DOS applications run in
virtual machines which are pre-emptively multi-tasked; Windows applications run
together in one separate virtual machine; this process is pre-emptively
multi-tasked in relation to the other DOS sessions.
However, Windows applications themselves only support co-operative
multi-tasking, which means that Windows applications need to be "well behaved"
to give up the processor attention to allow other tasks to proceed, with
specific use of functions such as yield(). Windows applications are therefore
pre-emptively multi-tasked with respect to the rest of the system, but only
co-operatively among Windows applications. When a Windows program needs to do
some lengthy processing, or is waiting for I/O, it needs to take special
precautions against halting all other Windows programs for this duration.
Needless to say, some do not, and that is why the user can be frequently faced
with the hourglass icon for periods of time when doing extensive processing or
I/O. Furthermore, a Windows application has no guarantee of processor time
within any period, which can potentially cause problems for applications
needing regular processor attention, such as communications programs.
Even though DOS applications are pre-emptively multi-tasked in Windows, the
scheduler algorithm is fairly unsophisticated, time-slicing on a static
allocation basis (the proportions can be tuned by the user, but they remain
static). This means that, even though an application may be unable to make any
effective use of its processor share (for example when it is tied up with an
I/O request), it will get it anyway, even though more deserving candidates are
waiting their turn. Thus the multi-tasking can be bogged down with applications
that are "I/O bound", like Application 1 in the above diagram, waiting for an
I/O device to respond.
Finally, since DOS itself is single-tasking, it has only one I/O queue, and
cannot therefore easily handle multiple I/O requests except by processing them
serially. So extenders like Windows that rely on DOS may be further weighed
down by the single-tasking character of the operating system.
One of the best illustrations of the I/O limitations of Windows 3.0 or 3.1 is
to try running a spreadsheet recalculation, and a download from a host machine
to the hard disk, while also attempting to format a floppy disk from the DOS
prompt (not unlike the scenario we discussed previously). You will see that at
least one of the tasks (usually the diskette format if it is not in the
foreground) will process in a very "jumpy" way, and often will pause for very
long periods. It is not unusual in such a scenario, to see one of the tasks
come to a near standstill as the others progress. If one of the background
applications is a communications program, the lack of processing time available
to the background application may even result in loss of data.
Multi-tasking under OS/2
In contrast, OS/2 pre-emptively multi-tasks all processes, and also provides
another, more granular unit of execution - the thread. Threads can be thought
of as distinct subroutines within a process, which can execute without
immediate reference to the main logic, such as file I/O, database read/write,
recalculation. In OS/2 these threads can be dispatched separately, and be
multi-tasked with each other, and along with other processes. In fact, the
basic unit of execution for the scheduler is the thread, and all processes
contain at least one thread.
The advantage of threads is that more time-consuming operations can be put into
separate threads, and the main thread of the program devoted to user input;
this helps the application to maintain an interactive and responsive feel even
when processing other sub-tasks in the background (see Application 1 in the
diagram). In this way, threads help prevent the kind of "I/O bound" feel to
many DOS and Windows programs. But it should be noted that use of threads
applies to more than just I/O operations: it is a powerful tool that can be
used for any operation that can be run in background while allowing the user to
regain control of the application, for further input.
Threads do not exist in any currently available version of Windows (at the time
of writing). Indeed, though the promised future product, Windows/NT (a
different operating system) is claimed to offer multi-threading, Windows
applications will need to be rewritten to take advantage of this facility,
since Windows 3.x programs are inherently single-threaded. Porting from a
Windows 16-bit program to a future 32-bit version of the Windows API will not
be enough, nor can threads be easily added later; they must be woven into the
basic design of the program to be used effectively. In fact, another promised
feature of Windows/NT, symmetric multiprocessing, may have little value until
multi-threaded Windows programs exist. Symmetric multiprocessing is the
ability of a system to run multiple threads of execution on different
processors concurrently (eg on multiple 486s within the same machine). By
definition it requires a multi-threaded system, and therefore, to take full
advantage of it, multi-threaded applications, and Windows today is only
single-threaded. So this feature will need new versions of applications to show
its advantage. In fact, the most likely early candidates for multi-threaded
Windows/NT programs are those (like Sybase SQL Server and Oracle) that are
already multi-threaded by design because they exist today as multi-threaded
OS/2 programs. It is one of many examples where Windows/NT promises little that
is not already available with OS/2 Version 2.0.
Again, in contrast with DOS and Windows 3.x, the OS/2 scheduler is much more
intelligent than a simple time-slicer. It can detect when applications are I/O
bound (like Application 2 in the diagram), and shift CPU time to another thread
or process. Thus, priorities can be changed dynamically to preserve overall
system responsiveness.
And, to complete the picture, since OS/2 itself has a multi-tasking,
multi-threaded design, it can provide multiple I/O queues and therefore
overlapped I/O between processes. This helps to improve the perceived
performance, especially in heavy system loads.
The following table summarises the differences between Windows 3.x and OS/2
2.0:
ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 4. Multi-tasking - Windows 3.x and OS/2 2.0 Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Γöé WINDOWS 3.X Γöé OS/2 2.0 Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Multi-tasking DOS Γöé pre-emptive Γöé pre-emptive Γöé
Γöé applications Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Multi-tasking Γöé co-operative Γöé pre-emptive (if in Γöé
Γöé Windows applica- Γöé Γöé separate VDMs) Γöé
Γöé tions Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Priority Γöé static Γöé dynamic Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé I/O processing Γöé serial, single Γöé overlapped, mul- Γöé
Γöé Γöé queue Γöé tiple queues Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
What this means to the user is that OS/2's multi-tasking is smoother, more
consistent, less likely to be bogged down by I/O or by an application
attempting to monopolise the processor, and more responsive and interactive in
feel.
ΓòÉΓòÉΓòÉ 6.4.4. Multi-tasking and the user interface ΓòÉΓòÉΓòÉ
One of the advantages of a graphical environment is that it can represent
concurrent tasks by icons and windows on the screen, thereby giving a visual
indication of the number and variety of tasks. This is true of both Windows and
OS/2.
However, OS/2 2.0 builds on the basic benefits of the "first generation" GUIs
like Windows 3.x and OS/2 1.3, and adds some features specifically designed to
aid smoother multi-tasking and switching between tasks:
o the "Window List" is more functional than the Windows 3.x task list, allowing
several applications to be "resurfaced" on the screen, or closed, at once,
rather than moving to and clicking on discrete icons for each task
o the ability to "hide" windows when not in use, rather than reducing to an
icon on the screen , results in a less cluttered desktop, making it easier to
find what you want quicker, especially in screen resolutions with limited
screen "real estate", such as VGA.
o OS/2 2.0 allows whole groups of applications and data to be grouped together
in a logical unit (a "project", as it were) by putting them together in a
common folder. This is more convenient and flexible than just creating
directories and copying files manually, as you would have to in DOS and
Windows. (You can also be more flexible in naming such folders, going beyond
the eight character limits even in a FAT file system - see Descriptive names
)
o Each folder can also be given a "workarea" property. This allows several
applications to be opened, hidden or closed, together, simply by opening or
closing the folder, rather than going to each window individually. For
example, a folder containing a spreadsheet, word processor and graphics
applications may have all these programs running together, but then close
them or hide them in a single operation on the folder, and restore them all
to the state they were in previously, in another single operation. This means
the whole state of work in progress can be quickly set aside, and another
begun or resumed easily. OS/2's ability to save and restore what you were
doing from one boot to another is a specific example of this workarea feature
None of these user interface features appear in either Windows 3.x or in the
current beta test releases of Windows/NT. The result of all of this is that
the Workplace Shell is much easier to use in a multi-tasking scenario than
older GUIs. The user interface matches the internal design in being optimised
for multiple tasks, making it easy to move from one task to the next.
ΓòÉΓòÉΓòÉ 6.5. File systems ΓòÉΓòÉΓòÉ
OS/2 offers superior file system support, which leads to increased performance.
The OS/2 architecture also allows other file systems to be installed in a
modular fashion (Installable File Systems or IFS). It is therefore more
flexible in design to accommodate future enhancements; for example, OS/2 now
includes CD-ROM support via an IFS.
OS/2 also provides support for very large disks, a consideration that is
particularly relevant to server environments. OS/2 supports hard drives up to
2GB in size. In Windows 3.1 the limit is only 1GB.
OS/2 2.0 provides file I/O services not only to OS/2 applications, but to DOS
and Windows applications running in VDMs. Therefore, DOS and Windows
applications can take advantage of the advanced function, without having to be
modified, since the DOS emulation of MVDM provides a compatible interface to
the file system for DOS applications.
Both major OS/2 file systems have been improved under OS/2 2.0, allowing better
performance not only for applications themselves, but also in the paging
performed by the system when using virtual memory.
ΓòÉΓòÉΓòÉ 6.5.1. High Performance File System (HPFS) ΓòÉΓòÉΓòÉ
HPFS was first introduced to OS/2 in version 1.2, and is an example of the kind
of advanced function that has not yet been implemented in less sophisticated
systems like DOS. It was introduced as an alternative to the File Allocation
Table (FAT) system which came from DOS. HPFS is particularly good for managing
large disks and partitions or large files. It provides fast and consistent
performance, outperforming DOS-based FAT systems in tests run by IBM, in nearly
all cases. (OS/2 2.0 implements an enhanced FAT system that uses some similar
caching features as HPFS, which can also give high performance in many
circumstances - see below).
HPFS is particularly good in disk utilisation (compared to FAT). It uses a
highly contiguous file allocation system, which results in especially good
performance (relative to FAT) in accessing files or data in a cluttered or full
partition. It implements a B-Tree directory structure and search algorithm, as
opposed to sequential under FAT. HPFS also allows for multi-threaded I/O,
caching of directory pointers in memory for quicker access of last directories
used, and read-ahead and lazy write (lazy write buffers up write requests from
applications and commits them to disk after a given time or during disk
inactivity.) These advanced features allow for substantial performance
increases and greater tuning. HPFS can also provide write error recovery on
the fly with "hotfix" facilities.
Since it is FAT-compatible at API level, applications running under OS/2 can
use either system, and do not have to be written specifically for one or the
other. It also presents a consistent interface to other components of OS/2
like MVDM, to allow DOS and Windows to use HPFS volumes as if they were FAT.
HPFS also supports the use of long file names, for greater usability, so
instead of having LJS1290.TXT, you can have a file name "Letter to John Smith
December 90". Obviously applications need to be coded with this in mind. DOS
and Windows applications can use files that adhere to the 8.3 naming system on
HPFS without any difficulty.
HPFS has been enhanced in version 2.0 to add performance-related features such
as command chaining (providing a list of contiguous sector requests required to
fulfil an I/O request) and scatter/gather facilities such as are supported in
Small Computer Systems Interface (SCSI) adapters to gather physically
discontiguous pages in a data buffer, and perform I/O in a single operation.
ΓòÉΓòÉΓòÉ 6.5.2. Enhanced FAT ΓòÉΓòÉΓòÉ
OS/2 2.0 includes an enhanced version of the FAT file system which is
completely compatible with the FAT system under DOS. This gives greater
performance but full compatibility with existing FAT systems. It adds features
like lazy write and improved caching to FAT. This means that DOS applications
running with a FAT file system under OS/2 2.0 will be substantially faster for
disk-based operations than under DOS. All of these benefits can be obtained
without having to reformat your hard disk - the OS/2 enhanced FAT driver works
with existing DOS FAT volumes.
ΓòÉΓòÉΓòÉ 6.5.3. SCB exploitation ΓòÉΓòÉΓòÉ
OS/2 2.0 implements the Subsystem Control Block (SCB) architecture for more
intelligent and efficient disk access. SCB defines a standard way of
communicating between device drivers running on the main system CPU, and I/O
processors located on advanced function adapters (like SCSI) that are capable
of operating independently from the CPU. SCB therefore fits naturally with the
use of SCSI adapters, and will allow better exploitation of SCSI functions like
scatter/gather and command chaining. The implementation is transparent to the
OS/2 user and the developer; there are no application considerations, simply
improved performance. It is simply a means of getting more out of a system
that provides advanced intelligent adapters for disk I/O. Exploitation of
newer, more advanced devices such as SCSI is better under OS/2 than under
Windows, which does not provide such features.
ΓòÉΓòÉΓòÉ 6.6. Broad hardware support ΓòÉΓòÉΓòÉ
OS/2 1.x was separately distributed by both IBM and Microsoft. IBM delivered
IBM OS/2, which was specifically optimised for and supported on IBM equipment
(AT and PS/2 family), while Microsoft distributed MS OS/2 to its OEMs like
Compaq and Olivetti (many of these versions had manufacturer-specific
modifications too). This meant that there were different versions of OS/2
according to the machine it ran on. Although this was not in essence any
different than had always been the case for DOS, the perception was that
supporting OS/2 in a mixed hardware environment was hampered by the lack of a
"generic" version of OS/2.
This problem has been overcome in OS/2 2.0, which supports a broad range of
machines with an Intel 386SX or above, with a single version of OS/2. This
shows that OS/2 2.0 does not run only on IBM equipment. Open hardware support
applies not only to the base system, but also to Extended Services for OS/2 and
OS/2 LAN Server (some models may require more memory installed to run the
systems extensions). IBM supplies regularly updated lists of the models it has
tested via bulletin boards (see the list in OS/2 Bulletin Board Systems ) and
IBM representatives. Among the vendors whose models are supported, are Compaq,
AST, Olivetti, Toshiba, Hewlett Packard, Dell, Gateway, Wang, DEC, NCR, Tandy,
ACER, CompuAdd and many others. Ask your IBM representative to look for the
PCMTABLE package on the MKTTOOLS disk.
In fact, even though IBM cannot test OS/2 on all the models and manufacturers
in the market, it is likely that most PCs equipped with an Intel 386SX or above
processor, will work. More models are being tested all the time, and IBM is
committed to working with as many manufacturers as possible to determine OS/2
compatibility. Indeed, the evidence from user registrations for OS/2 2.0 in
Europe alone, suggests that users are already running OS/2 2.0 on hundreds of
machines that have not yet appeared on any "official" list. By 2 September,
1992, 802 models had been recorded from registration cards that do not appear
on the list of tested models.
OS/2 is not limited to machines with Micro Channel architecture. Even the
supported PS/2 models include AT-bus machines like the Model 40, as well as
Micro Channel machines like the Model 57. AT-bus, Micro channel and EISA
machines from a variety of vendors are supported.
Furthermore, IBM is now making OS/2 2.0 available, preloaded on the hard disk
of selected IBM PS/2 models, including the Models 56 and 57. This is a
convenience for users, who do not need to install the operating system at all,
but can switch on the PC to discover the system already set up for their use,
along with a number of new applets and help on using the system. IBM is making
this facility available to other IBM-compatible hardware manufacturers, and
arrangements have already been made with a number of vendors, including Dell
and Olivetti, to provide OS/2 2.0 with selected models in their hardware range.
Contact your supplier for the latest information.
OS/2 also has broad support for different displays, disks and printers. Most
of the major display standards (VGA, 8514, XGA) have full support. SuperVGA
(SVGA) support exists for some adapter types already (some existed in OS/2
1.3), and more drivers are appearing from the SVGA chip set vendors like
Trident and Tseng. Many SVGA DOS and Windows drivers are also supported in
full screen DOS and WIN-OS/2 sessions, even if the main desktop has to run in
VGA mode if there is no PM screen driver. IBM plans further enabling of
SuperVGA support in an update option to be made available by the end of 1992.
OS/2 supports 205 models of printer, which covers over 90% of the printer
market, from dot matrix, to inkjet and laser printers. Models from the major
vendors like Epson, Hewlett Packard and IBM receive wide coverage (look at the
file PMSETUP.INF in the \OS2 directory for the complete list). There is also
generic text printing support which should work on any printer. Furthermore, if
a Windows driver exists for a device, it can be installed in WIN-OS/2, and used
for Windows applications running under OS/2 2.0 (the product includes
additional Windows printer drivers for Canon, HP and NEC printers). Where both
a Windows and an OS/2 printer driver exist, they can both be installed in one
step at installation time.
Generic INT13 disk support is provided in OS/2 2.0, which should allow most of
the common drive types to work. IBM and Adaptec have developed a common
specification which will make the development of vendor-specific SCSI drives
much easier. Drivers already exist for some of the OEM SCSI adapter vendors.
More are in development, and IBM is producing tools to help support the
development of drivers for displays, printers and disks.
OS/2 1.x suffered from a relative lack of OS/2 device driver support, but OS/2
2.0 can make use of many devices via their DOS device driver (see DOS device
drivers ). Devices such as hand scanners and fax cards can often be supported
in this way, broadening the range of devices available to OS/2 users.
OS/2 device support is broadening as the industry increases its support, but
IBM continues to develop drivers itself and work with other vendors to ensure
that even wider support is provided.
ΓòÉΓòÉΓòÉ 7. Better DOS ΓòÉΓòÉΓòÉ
There are over 20,000 DOS applications available today. In order to be an
integrating platform for PC-based applications, the primary task for OS/2 2.0
is to fully support that wide range of applications.
OS/2 version 1.3 was limited in the support it could provide for DOS
applications, mainly due to the limitations of the 286 architecture on which
the OS/2 1.x base was designed. However, use of the 386, and in particular the
virtual 8086 mode of the processor, allows DOS applications support to be much
more extensive in version 2.0 - indeed, a better DOS than DOS itself.
ΓòÉΓòÉΓòÉ 7.1. Multiple DOS applications ΓòÉΓòÉΓòÉ
Several DOS applications can be run at once in OS/2 2.0. All DOS applications
can be invoked from an icon on the Workplace Shell desktop, or from any DOS or
OS/2 command prompt. They can be run in a full screen session (rather like
they were in 1.3), or windowed on the Workplace Shell desktop. Both text-based
applications (such as Lotus 1-2-3 v2.2 and WordPerfect) and applications that
run in graphics mode (such as Lotus Freelance Plus or Harvard Graphics, as well
as the Microsoft Flight Simulator or other games programs) can be run.
Graphics mode applications can be run windowed alongside text-based
applications running in windows. This cannot be done without restrictions in
Windows 3.0, and although Windows 3.1 does allow VGA graphics to run in a
window, this feature will not be available under Windows/NT, where, according
to Microsoft, the application will have to run full screen.
Multiple DOS applications in windows on the Workplace Shell desktop
DOS applications running in a window on the Workplace Shell desktop can take
advantage of many of the ease of use features of the Workplace Shell, such as
sizing the window to a convenient size, tiling windows so several applications
can appear alongside each other, and hiding them to make more space on the
screen while leaving the application running. Furthermore, many DOS
applications will be able to take advantage of the font support in PM windows:
you can change the font size to better suit the size of the window you are
running in (the range of sizes available is determined by the display adapter
you are using - on VGA, for example, there are 10). Again, all of this support
is provided by PM: no modification is required to the DOS application.
Contrast this with DOS, where getting a small font size for applications like
Lotus 1-2-3, requires re-running the Install program, and the risk of creating
an invalid setup.
DOS applications that support the mouse get use of the mouse, even when running
in a window (there are DOS settings to give the DOS application exclusive use
of the mouse pointer while in the application window - see DOS Settings ).
This is much easier to set up in OS/2 2.0 than it is under Windows 3.1 (Windows
3.0 did not support DOS windowed applications using a mouse), as it only
requires one change to the DOS settings (which are automatically set up for
many programs via the Migrate option - see Migrating applications ); in Windows
3.1, you need to have already installed the DOS mouse driver in AUTOEXEC.BAT or
CONFIG.SYS (thus reducing the memory available to all DOS applications whether
or not they use the mouse).
All of this means that, without changing any of your DOS applications, the
Workplace Shell environment can "add value" to the applications while
preserving full compatibility with the way they are used under DOS.
ΓòÉΓòÉΓòÉ 7.2. Application integration ΓòÉΓòÉΓòÉ
OS/2's DOS support is not simply a question of compatibility - under OS/2 2.0,
you can make your applications work together in a way that is not possible
under plain DOS. It is possible to copy information from one application to
the clipboard, and paste it into another. This can be between two DOS
applications, between a DOS application and an OS/2 application, or any
combination of DOS, Windows and OS/2 applications.
Moreover, both text and graphics can be cut and pasted between applications,
(although graphics can only be received by those applications that are capable
of handling bitmap data - mainly OS/2 and Windows applications). This allows
two-way sharing of data between applications.
This means that DOS applications not only integrate better with GUI
applications written for Windows and OS/2, but also with other DOS
applications, even though they may not have been written to work together.
Imagine, for example, if you were using the DOS versions of Lotus 1-2-3 and
WordPerfect, and you wanted to incorporate some figures from your spreadsheet
into the report you are writing on the word processor. Under DOS, you would
need to quit one application (the word processor) to load another (the
spreadsheet), retrieve the spreadsheet file and make the conversion into a file
format the word processor understands (perhaps plain ASCII, thus losing any
formatting you have created in the spreadsheet), exit the spreadsheet
application, load the word processor and the report again, and import the data
into your report. Whereas in OS/2 2.0, you can simply use the clipboard. With
the applications running side by side in windows on the desktop, mark some data
from the spreadsheet, copy it to the clipboard, and paste it into the word
processor - all without closing files or applications. The clipboard takes care
of any data conversion. As the number of applications you need to integrate
grows, so the difficulty of remembering different methods of data conversion
grows, but in OS/2 2.0, the user simply works with copy and paste each time.
Thus, standard, unmodified DOS applications can be integrated under the OS/2
Workplace Shell. DOS applications can also be written to take advantage of the
OS/2 environment, or OS/2 applications written to start DOS applications. One
example of this is the OS/2 command prompt in OS/2 2.0, which can start DOS
applications simply by typing the name of the .EXE file, just as one would from
a DOS command prompt. This helps to reduce the need to differentiate between
DOS and OS/2 applications, from the user's point of view.
Another method of integration is via the named pipes mechanism, which allows
DOS and OS/2 applications to be written to communicate with each other.
ΓòÉΓòÉΓòÉ 7.3. Multi-tasking of DOS applications ΓòÉΓòÉΓòÉ
Not only can several DOS applications run at the same time, in separate windows
on the Workplace Shell desktop, but each continues to run in the background
while you are working on another. In this way, DOS applications can take
advantage of OS/2's pre-emptive multi-tasking, overlapped I/O, and OS/2 file
system performance. Let's take a look at each of these in turn:
ΓòÉΓòÉΓòÉ 7.3.1. Pre-emptive multi-tasking ΓòÉΓòÉΓòÉ
As was explained earlier ( Multi-tasking ), OS/2 was designed to manage
processor time smoothly between multiple applications, not only OS/2
applications, but also DOS and Windows applications running in Virtual DOS
Machines (VDMs). This is more sophisticated than the simple time-slicing
mechanism employed by Windows 3.x, and takes into account, for example, when
applications are "I/O bound", waiting for an I/O device to respond. In OS/2
priorities can be changed dynamically by the processor according to such
criteria, in contrast to the static approach employed by Windows 3.x.
Therefore, even though both environments employ pre-emptive multi-tasking for
DOS applications, the OS/2 scheduler is more sophisticated than Windows'
scheduler. Relative performance between applications can be tuned by a number
of DOS settings (see DOS Settings for some examples of DOS settings).
The result of all of this, is that OS/2 provides a more balanced performance
between applications, not only those from DOS, but between them and Windows and
OS/2 applications.
ΓòÉΓòÉΓòÉ 7.3.2. Overlapped I/O ΓòÉΓòÉΓòÉ
All DOS applications have their I/O requests serviced by OS/2 (although the
application makes calls to DOS I/O in the same way as usual, they are trapped
and serviced by OS/2).
This allows DOS applications to take advantage of OS/2's better I/O
capabilities without needing to be rewritten. Just by running under OS/2 they
can benefit from OS/2's ability to overlap I/O requests and services. This
improves performance in many scenarios, particularly where multiple
applications are running.
ΓòÉΓòÉΓòÉ 7.3.3. Access to OS/2 file system ΓòÉΓòÉΓòÉ
Although DOS applications have not been written to use the OS/2 file systems,
they can without modification use them and derive the same benefits as OS/2
applications do. All file access uses the OS/2 file system. Both the HPFS and
enhanced FAT file systems under OS/2 provide superior performance compared to
DOS (**)
Therefore despite the inevitable multi-tasking overhead, many applications will
perform just as well, and some will perform better, than under native DOS. In
test cases run by IBM, multi-tasking performance of DOS applications was
superior to that under Windows 3.x.
ΓòÉΓòÉΓòÉ 7.4. Memory usage ΓòÉΓòÉΓòÉ
Memory has been one of the biggest constraints on the development of the DOS
environment. The 640KB limit was for a long time an inhibiting factor for many
users and application developers. Despite many workarounds, such as the LIM
expanded memory, use of the HMA area, and the growth of DOS extenders (see
Memory: Conventional, Expanded, Extended for a more detailed discussion),
memory management under DOS is a complex and frustrating task, and there still
remain limitations for the large number of DOS applications written to use only
conventional memory below the 640KB mark.
ΓòÉΓòÉΓòÉ 7.4.1. Comparison with memory usage under DOS ΓòÉΓòÉΓòÉ
Part of the problem has been that successive releases of DOS have added
function, but removed some of the vital conventional address space. The
following chart shows the relative memory sizes free under various versions of
DOS:
DOS application memory space - a comparison
As the chart also shows, OS/2 Version 2.0 provides a DOS conventional memory of
633KB, at least as good, if not better, than even DOS 5.0 or DR-DOS 6.0. (The
respective vendors of both of the latter products promote the amount of memory
free as key selling points for their systems).
And that is only for default configurations. In the real world, many device
drivers are needed for various applications, whether for memory (expanded or
extended), connectivity (LAN, 3270), or mouse. In OS/2 2.0 these features are
supported without taking precious conventional memory away, whereas, even in
systems like DOS 5.0 that can move certain device drivers into the HMA area,
there is nearly always a conventional memory impact. The following table shows
some sample configurations which illustrate this point vividly:
ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 5. Memory comparison: OS/2 2.0, DOS 5.0, Windows 3.1 Γöé
Γöé enhanced mode Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Γöé OS/2 2.0 Γöé DOS 5.0 Γöé WINDOWS Γöé
Γöé Γöé Γöé Γöé 3.1 Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Conventional DOS memory after Γöé 633KB Γöé 622KB Γöé 577KB Γöé
Γöé default install Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Various scenarios, built on default configuration: Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé CONFIG #1 - POPULAR FEATURES Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé file I/O Γöé YES Γöé 1 Γöé 1 Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé EMS Γöé YES Γöé 8 Γöé 8 Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé mouse Γöé YES Γöé 14 Γöé 14 Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé fast file access Γöé YES Γöé 20 Γöé 20 Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé REMAINING APPLICATION MEMORY Γöé 633KB Γöé 579KB Γöé 534KB Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé CONFIG #2 - LAN CONNECTIVITY Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé LAN adapter drivers and LAN Γöé YES Γöé 100 Γöé 100 Γöé
Γöé requester Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé REMAINING APPLICATION MEMORY Γöé 633KB Γöé 522KB Γöé 477KB Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé CONFIG #3 - 3270 CONNECTIVITY Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé 3270 adapter drivers and Γöé YES Γöé 28 Γöé 28 Γöé
Γöé emulator Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé REMAINING APPLICATION MEMORY Γöé 633KB Γöé 594KB Γöé 549KB Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé CONFIG #4 - NLS PACKAGE/COUNTRY SUPPORT Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé NLS keyboard Γöé YES Γöé 7 Γöé 7 Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé NLS display Γöé YES Γöé 8 Γöé 8 Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé NLS printer Γöé YES Γöé 11 Γöé 11 Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé NLS other (eg codepage) Γöé YES Γöé 5 (min) Γöé 5 (min) Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé REMAINING APPLICATION MEMORY Γöé 633KB Γöé 591KB Γöé 546KB Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
Of course, the above configurations are by no means mutually exclusive: it
will be very common to have elements from at least two of the configuration
groups above. Indeed, groups 1, 2 and 3 together could be considered a fairly
essential configuration for a corporate, connected workstation, running any
modern DOS applications. That means the difference between OS/2 and DOS grows
greater. Note also, of course, that because Windows 3.1 and 3.0 are DOS
extenders, and run on top of DOS, that any reductions in the memory available
for DOS will be passed on to Windows, and to any DOS applications executing
under Windows. While it may not be a problem for Windows applications running
in standard or enhanced mode, which use extended memory anyway, it will
substantially reduce the effectiveness of most DOS applications running under
Windows because of the constraints on conventional memory.
The reason OS/2 can provide all these features without loss of DOS application
space is because many features are supported by OS/2 device drivers, which are
available to OS/2 and DOS applications, and which do not affect the amount of
application space available to DOS applications. Only the DOS emulation kernel
resides below 1MB. In this way, the MVDM architecture makes available to DOS
applications the maximum amount of conventional memory.
In fact, if that were not enough, it is possible to increase DOS application
space still further. One of the DOS settings is VIDEO_MODE_RESTRICTION (see
DOS Settings ). This frees much of the video buffer space above the 640KB line
by restricting applications to text or CGA graphics mode only, allowing more
than 720KB memory free - an unheard of figure for DOS users!
This increased size of conventional memory space may even mean that, where DOS
users could not load TSR programs with larger DOS applications, they can under
OS/2! Furthermore, there are many scenarios encountered by Windows 3.x users
today, where they require access to a network, and a Windows application, at
the same time as using a DOS application that requires 590K or more memory (the
latter is not uncommon with the more modern DOS applications). This
combination is usually not possible under Windows 3.x, and the user has to exit
Windows to run the DOS application, or remove network support. Under OS/2 2.0,
this setup can be achieved easily.
And, of course, more conventional memory means more space for data and, for
some DOS applications, better performance, making OS/2 a better DOS environment
than DOS itself, by overcoming one of DOS's most fundamental limitations -
memory.
ΓòÉΓòÉΓòÉ 7.4.2. Expanded and Extended Memory ΓòÉΓòÉΓòÉ
OS/2 also supports the full range of other memory types supported under DOS and
Windows 3.x: HMA, XMS, expanded and extended memory and DPMI (see Memory:
Conventional, Expanded, Extended for an explanation of these memory types).
This means that not only do all DOS applications have more conventional memory
available, but those which have been written to access more memory can work in
the same way under OS/2 2.0.
For example, expanded memory conforms to the LIM 4.0 specification, and will
provide expanded memory to applications like Lotus 1-2-3 release 2 using the
standard DOS INT 67h services. Each VDM is provided with a separate EMS
emulation, so each can access as much expanded memory as necessary, and not
conflict with each other. The amount of expanded memory is configurable by the
user in DOS settings, as well as a limit set across all VDMs if required. In
Windows 3.x, expanded memory can only be used if a physical expanded memory
adapter is in the machine, therefore limiting the number of users who can mix
applications needing expanded and extended memory.
XMS support (LIMA version 2.0 level) is provided via a virtual device driver
(the same is true of EMS), and manages three types of memory: High Memory Area
(HMA), Upper Memory Blocks (UMBs) in the Upper Memory Area (UMA) and Extended
Memory Blocks (EMBs). These are used by various DOS applications and TSRs, and
by Windows 3.x and DOS 5.0. Just as DOS 5.0 can load part of the system into
the HMA, and device drivers into UMBs, so can OS/2 2.0 via the statements
DOS=HIGH and DEVICEHIGH= in CONFIG.SYS; these settings can also be made for an
individual VDM by changing the DOS Settings DOS_HIGH and DOS_UMB (see DOS
Settings ). Furthermore, more extended memory can be provided to DOS
applications under OS/2. DPMI-compliant applications such as Lotus 1-2-3
version 3.1+ can access up to 512MB of extended memory in an OS/2 VDM.
The key point is that OS/2 provides compatible services for extended and
expanded memory for DOS applications, as well as a larger conventional address
space, and also provides higher limits for many of the DOS applications that
use extended memory. And this can usually be provided as default without any
configuration effort on the user's part.
ΓòÉΓòÉΓòÉ 7.4.3. Multiple DOS applications - effect on memory ΓòÉΓòÉΓòÉ
Runing several DOS applications will not cause an excessive effect on memory
use or performance. Because OS/2 operates a virtual memory system, you do not
need to have extra physical memory to have large memory applications, nor to
run several of them at once. Any memory required above what is physically
installed will be found by using the disk as virtual memory. VDMs are
swappable when inactive, reducing the overall overhead on physical memory.
Furthermore, applications that do not use EMS, XMS or DPMI, can have the
default VDM settings changed to remove any expanded/extended memory
requirements, thus reducing the overall virtual memory required.
ΓòÉΓòÉΓòÉ 7.5. Reliability and protection ΓòÉΓòÉΓòÉ
In DOS, most applications run in the real mode of the processor. DOS extender
applications execute mainly in protected mode, but still have to switch back to
real mode to perform certain I/O instructions (such as most calls to DOS
services) or when passing control to TSRs like device drivers. Protected mode,
as its name suggests, provides a measure of protection in the CPU between
processes, but while in real mode, applications can write to any area of
memory. Errors can exist even in the best-written and well tested of DOS
applications, which can cause such system corruption under DOS, often leading
to a system crash or hang, forcing the machine to be rebooted. Windows 3.x, as
a DOS extender, can be prone to some of these problems. The problem can be
particularly acute under Windows, since one application that crashes may affect
all the programs running at that time. Therefore, the potential for data loss
and for wasted time in resetting the system, is even greater. That is why it
is crucial that a multi-tasking environment provides as much protection as is
possible. There is a limit to how much can be achieved under DOS or a DOS
extender.
In fact, although Windows 3.1 is claimed to provide greater protection than
Windows 3.0, by "rebooting" individual DOS sessions and adding parameter
checking, it is still as prone as before to the risk of a DOS TSR (such as a
DOS network driver) taking the system out of protected mode into real mode (see
Reliability ). Neither Windows 3.0 nor 3.1 can prevent this "trap door" in its
system integrity as long as they run on DOS. It is, in architectural terms,
fundamentally prone to such problems, no matter what error checking code is
implemented at higher levels.
In OS/2 2.0, each VDM emulates an entirely independent instance of DOS, and
each VDM has its own separate address space (just like other processes under
OS/2), applications are protected from one another, and the system is protected
from applications. The VDM Manager (VDMM) within the OS/2 kernel can terminate
VDMs when an application or device driver performs an illegal operation, while
allowing other VDMs to continue running. While it is not impossible to crash
OS/2 (no system is secure from applications designed specifically to subvert
the normal means of protection), it provides a higher degree of crash
protection than any alternatives running on DOS.
Therefore, OS/2 is better protected than DOS, and provides all the benefits of
a DOS extender, including multi-tasking of DOS applications, without the
uncertainty of using an operating system (DOS) that was never designed for
multi-tasking.
ΓòÉΓòÉΓòÉ 7.6. Compatibility ΓòÉΓòÉΓòÉ
Of course, none of the benefits of extra memory, application protection,
integration, multi-tasking and so on, are of much value to users unless they
can be certain that their DOS application will run. It is impossible to
guarantee all applications will run, of course (there are more than 20,000
commercial applications without even counting the investment made by in-house
corporate developers - an impossible testing task!). But it is worth
understanding how OS/2 2.0 has been designed to provide the maximum
compatibility possible in a multi-tasking environment.
ΓòÉΓòÉΓòÉ 7.6.1. Overcoming OS/2 1.3 limitations ΓòÉΓòÉΓòÉ
Since OS/2 2.0 is not constrained by some of the limitations of the OS/2 1.3
DOS box, particularly with regard to more memory (some DOS applications simply
did not have enough memory free to run in the OS/2 1.3 DOS Box), and support
for interrupt-dependent programs like communications, it is able to offer wider
compatibility for DOS applications. However, OS/2 2.0 has taken compatibility
still further, and has been designed to take into account some of the aspects
of DOS applications which show their single-tasking heritage.
For example, some so-called "bad" applications directly address hardware
devices, and assume they have sole control over them. Many applications write
directly to the video memory buffer to improve screen refresh performance.
Perhaps the best known example of such an application is Lotus 1-2-3. In a
multi-tasking environment, it is important to be able to handle multiple
applications wanting to write to the screen at once, and maintain visual
consistency on the screen, while keeping maximum compatibility with existing
applications. OS/2 does this via its virtual device drivers. There is a virtual
video device driver, and also a virtual COM driver, which handles contentions
between applications wanting to use the COM port, and provides all DOS
applications with COM services at the same time.
The video virtual device driver is of further interest in that it provides
applications with fast screen I/O by allowing the foreground application to
write directly to the video hardware, but still insulating the physical
hardware from background VDM screen activity. It also provides services for
DOS applications that use BIOS video routines, by intercepting the ROM BIOS
video interrupt (INT 10h) and performing the requested operations directly,
thus improving performance.
ΓòÉΓòÉΓòÉ 7.6.2. DOS device drivers ΓòÉΓòÉΓòÉ
Many common device types (video, keyboard, mouse, COM, EMS, printer) are
supported by virtual device drivers. If neither a virtual device driver nor
OS/2 protected mode device driver is available, OS/2 2.0 can still provide
support for many DOS device drivers via a "generic" DOS device support. This
would usually entail exclusive access to that adapter and device driver from
one single VDM. This will be more than adequate for many DOS applications,
which use many device drivers for only one application anyway. And it has the
great advantage of allowing the large number of DOS device drivers, for the
plethora of adapters now available for PCs, to be used "as-is" under OS/2 2.0.
Scarcity of protected mode device drivers was an inhibitor to adoption of OS/2
1.x; it need not be for 2.0.
IBM has demonstrated how DOS device drivers for scanners, FAX cards, MIDI
adapters can all be supported, and DOS applications that depend on them work
unmodified. Furthermore, there are a variety of devices in the banking and
manufacturing industries that can also be supported via this approach. Even
3270 applications can be supported with the DOS device driver in this way.
However, a better approach would be to use an OS/2 device driver, as provided
with Extended Services for OS/2, for example, which can support both DOS and
OS/2 3270 applications simultaneously. This is better than running the DOS
driver in a VDM, which only allows access exclusive to that VDM. A similar
restriction exists in the March General Availability code, with DOS network
drivers (eg for Token Ring adapter). These can often be used, but allow the
adapter only to be used within a single VDM (so that, for example, DOS 3270
communications via Token Ring cannot be used concurrently with DOS-based
networking through the same Token Ring adapter). This restriction can be
overcome for Token Ring using the Network Transport Services/2 product (NTS/2)
- see IBM Network Transport Services/2 running on an OS/2 2.0 base. This
product provides a virtual device driver (VDD) for 802.2 access. This VDD
allows 802.2 device sharing between VDMs so that, for example, Personal
Communications/3270 and program using the LAN can run together.
Even so, not all DOS device drivers are supported. Some block device drivers
(usually disk and tape drivers) are not supported, though some can run by
booting the "real" DOS inside a VDM (see Virtual Machine Boot (VMB) ).
The result of this is that OS/2 opens the door to an even wider range of DOS
applications and devices that can run as before, but taking advantage of the
OS/2 benefits described here.
ΓòÉΓòÉΓòÉ 7.6.3. What DOS version? ΓòÉΓòÉΓòÉ
OS/2's DOS emulation is just that - an OS/2-specific DOS kernel that emulates
DOS services. It is "DOS 5.0 - like", in that it should run all applications
supported by DOS 5.0.
Should applications require dependencies on a specific version of DOS there are
a number of strategies available to the OS/2 2.0 user. First of all, it is
possible to "fake out" the DOS version, in other words, fool the application
into thinking you are using a specific version of a DOS component. This is
using the DOS_VERSION setting in DOS Settings (see below). If this is not
enough, it is possible to boot the real version of DOS inside that VDM only
(see Virtual Machine Boot (VMB) ).
ΓòÉΓòÉΓòÉ 7.6.4. DOS Settings ΓòÉΓòÉΓòÉ
The DOS_VERSION option described above is just one of a number of "DOS
Settings" that can be changed to control the environment in each VDM. These are
set for that VDM only. Some settings can be made for all VDMs via AUTOEXEC.BAT
and CONFIG.SYS, such as DEVICE=... statements (ANSI, VXMS, VEMM, VMOUSE, VVGA,
VCOM), and some (though not all) can be changed while the application is
running. Several of these settings can also have an effect on DOS
compatibility, others can improve performance.
DOS Settings notebook
This means that each individual VDM can have its own optimised settings: some
with EMS, others without; some have DOS loaded high, others have special DOS
device drivers loaded in that VDM only. This gives great flexibility in
configuration, and allows the user to run different DOS applications
concurrently without having to maintain different CONFIG.SYS files and reboot
between them.
Among the commonly used or interesting settings are:
ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 6. Some VDM DOS Settings Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé SETTING Γöé DESCRIPTION Γöé DEFAULT Γöé
Γöé Γöé Γöé SETTING Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéDOS_BACKGROUND_EXECUTIONΓöé When set off, suspends execution of the Γöé On Γöé
Γöé Γöé program when it is in the background. Γöé Γöé
Γöé Γöé Useful for preventing degradation of Γöé Γöé
Γöé Γöé multi-tasking performance when a single Γöé Γöé
Γöé Γöé application is polling heavily for key- Γöé Γöé
Γöé Γöé board input. Rather less fine control Γöé Γöé
Γöé Γöé than using IDLE_SENSITIVITY and Γöé Γöé
Γöé Γöé IDLE_SECONDS, which should be attempted Γöé Γöé
Γöé Γöé first (see below). Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DOS_DEVICE Γöé Allows DOS device drivers to be loaded in Γöé Existing Γöé
Γöé Γöé an individual VDM, rather than across all Γöé drivers Γöé
Γöé Γöé DOS sessions. It adds to the drivers Γöé from Γöé
Γöé Γöé specified in CONFIG.SYS, which apply to Γöé CONFIG Γöé
Γöé Γöé all DOS sessions. The path and name of Γöé SYS are Γöé
Γöé Γöé the device driver are entered, and this Γöé listed Γöé
Γöé Γöé driver is available only for that VDM. Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DOS_UMB Γöé Gives the DOS emulation kernel use of Γöé On Γöé
Γöé Γöé Upper Memory Blocks, so that DOS TSRs and Γöé Γöé
Γöé Γöé device drivers can be loaded into Γöé Γöé
Γöé Γöé addresses between 640 and 1024KB, thus Γöé Γöé
Γöé Γöé freeing memory for DOS applications below Γöé Γöé
Γöé Γöé 640KB. This is similar to the DOS 5.0 Γöé Γöé
Γöé Γöé function, allowing use of the DEVICEHIGH Γöé Γöé
Γöé Γöé and LOADHIGH commands. The UMB ownership Γöé Γöé
Γöé Γöé can be relinquished by turning this Γöé Γöé
Γöé Γöé feature off, if an application program Γöé Γöé
Γöé Γöé needs to manage UMBs. This setting can Γöé Γöé
Γöé Γöé also be made globally in CONFIG.SYS. Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DOS_VERSION Γöé Allows OS/2 to report a "fake" DOS Γöé 20 (ie Γöé
Γöé Γöé version number to a request from a Γöé OS/2 Γöé
Γöé Γöé program in the VDM, in order to support Γöé Version Γöé
Γöé Γöé applications that check for a specific Γöé 2.0) Γöé
Γöé Γöé DOS version number. This is important for Γöé Γöé
Γöé Γöé applications such as Lotus 1-2-3 version Γöé Γöé
Γöé Γöé 3.1Γö╝, which look for the presence of DOS Γöé Γöé
Γöé Γöé 3.3 or above. The parameters set are the Γöé Γöé
Γöé Γöé name of the DOS executable (eg Γöé Γöé
Γöé Γöé 123DOS.EXE) followed by the DOS major and Γöé Γöé
Γöé Γöé minor version number (eg 3,30 for DOS Γöé Γöé
Γöé Γöé 3.3), then the number of times to "fool" Γöé Γöé
Γöé Γöé the application (255 means "every time") Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DPMI_MEMORY_LIMIT Γöé Specifies the maximum amount of protected Γöé 2 Γöé
Γöé Γöé mode memory available to DPMI applica- Γöé Γöé
Γöé Γöé tions running in a VDM (in MB). It is Γöé Γöé
Γöé Γöé important to set this figure high enough Γöé Γöé
Γöé Γöé for a WIN-OS/2 VDM running multiple Γöé Γöé
Γöé Γöé Windows applications in the same VDM. Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé IDLE_SECONDS Γöé Disables the IDLE_SENSITIVITY (see below) Γöé 0 Γöé
Γöé Γöé setting for a period of time after Γöé Γöé
Γöé Γöé "useful" work by the application has been Γöé Γöé
Γöé Γöé detected. Some programs appear to be Γöé Γöé
Γöé Γöé waiting for input, but then change and Γöé Γöé
Γöé Γöé continue other work. The setting needs Γöé Γöé
Γöé Γöé to be made high enough to allow the Γöé Γöé
Γöé Γöé application to run fast enough, but not Γöé Γöé
Γöé Γöé too high as to give the program more Γöé Γöé
Γöé Γöé resources than it needs Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé IDLE_SENSITIVITY Γöé Sets a threshold for judging when appli- Γöé 75% Γöé
Γöé Γöé cations will be deemed idle (ie waiting Γöé (refers Γöé
Γöé Γöé for I/O, polling etc). OS/2 2.0 can Γöé to % of Γöé
Γöé Γöé detect idle programs, especially those Γöé maximum Γöé
Γöé Γöé with a high rate of polling for input, Γöé possible Γöé
Γöé Γöé and gives them less time to run, Γöé polling Γöé
Γöé Γöé assigning the CPU to more "deserving" Γöé rate) Γöé
Γöé Γöé applications. This setting allows a user Γöé Γöé
Γöé Γöé to modify OS/2's "best guess" at what it Γöé Γöé
Γöé Γöé considers idle. The lower the number, the Γöé Γöé
Γöé Γöé more likely OS/2 will judge the applica- Γöé Γöé
Γöé Γöé tion idle. Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé MOUSE_EXCLUSIVE_ACCESS Γöé Allows a VDM to run applications that Γöé Off Γöé
Γöé Γöé maintain their own mouse pointers, and Γöé Γöé
Γöé Γöé which manage their own mouse positions Γöé Γöé
Γöé Γöé and movements, by forcing the physical Γöé Γöé
Γöé Γöé mouse driver to send its movements Γöé Γöé
Γöé Γöé directly to the virtual mouse driver (and Γöé Γöé
Γöé Γöé therefore to the DOS application) rather Γöé Γöé
Γöé Γöé than going through PM. Only one mouse Γöé Γöé
Γöé Γöé pointer appears when that VDM window has Γöé Γöé
Γöé Γöé the focus. Useful when running DOS appli- Γöé Γöé
Γöé Γöé cations that require use of the mouse, in Γöé Γöé
Γöé Γöé windows on the Workplace Shell desktop, Γöé Γöé
Γöé Γöé and prevents the situation where you can Γöé Γöé
Γöé Γöé see 2 mouse pointers, one for the DOS Γöé Γöé
Γöé Γöé application, and one for PM, and have Γöé Γöé
Γöé Γöé difficulty synchronising them. An example Γöé Γöé
Γöé Γöé of a DOS application that can use a mouse Γöé Γöé
Γöé Γöé in a VDM is WordPerfect 5.1 for DOS. Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé PRINT_TIMEOUT Γöé Sets the time in seconds after which the Γöé 15 Γöé
Γöé Γöé spooler will close a print job initiated Γöé Γöé
Γöé Γöé by the VDM, and begin to print. This Γöé Γöé
Γöé Γöé means that printing can begin from DOS Γöé Γöé
Γöé Γöé applications that do not close their Γöé Γöé
Γöé Γöé print jobs, without having to exit the Γöé Γöé
Γöé Γöé DOS application Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé VIDEO_FASTPASTE Γöé Improves the speed of paste operations Γöé Off Γöé
Γöé Γöé from the clipboard to a DOS application. Γöé Γöé
Γöé Γöé Not all applications can support this. Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé VIDEO_MODE_RESTRICTION Γöé Extends DOS address space beyond 640KB by Γöé None Γöé
Γöé Γöé limiting video mode support to CGA, pro- Γöé Γöé
Γöé Γöé viding up to 96KB (depending on video Γöé Γöé
Γöé Γöé adapter installed) extra for DOS applica- Γöé Γöé
Γöé Γöé tions Γöé Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
Help is provided with OS/2 2.0 to guide users in modifying these settings, but
it should be noted that much of the time, DOS settings will neither need to be
examined nor changed. The vast majority of applications will work with the
default settings. Many of the most common DOS applications can have their
settings automatically created by the Migrate program (see below).
ΓòÉΓòÉΓòÉ 7.6.5. Migrating applications ΓòÉΓòÉΓòÉ
OS/2 2.0 provides a migration database (DATABASE.DAT) that contains parameters
and settings for commonly used DOS, Windows and OS/2 programs. This binary
database file is used by the Migrate Applications object to place the program
icons onto the desktop and customise their DOS or WIN-OS/2 settings to the
recommended values (which have been determined during pre-release testing).
This means that for many common DOS and Windows programs, there will be no need
to modify DOS settings, since the Migrate program will automatically place a
program object on the desktop with the optimal settings. These are placed in a
"DOS Programs" folder and a "Windows programs" folder as appropriate. Migrate
also allows applications not in the migration database to be migrated, but with
the default DOS settings, which can then be modified manually if preferred.
These programs are placed in folders called "Additional DOS programs" and
"Additional Windows programs" as appropriate. All folders created by Migrate
are given the appearance of the group icons used in Windows 3.x and OS/2 1.3,
for visual familiarity. This aim is furthered by the fact that Migrate detects
the presence of the program icon for a Windows application, and adds it to the
program reference it creates in the OS/2 folder. This means that Windows
applications appear in OS/2 with their normal icon. DOS applications are given
the standard DOS icon for full screen or windowed sessions as appropriate. The
settings for each object can be modified to add a user-defined icon as
necessary. Many tools, such as CVTICO, exist on bulletin board systems, to
convert icons from Windows format to OS/2 format, so that any public-domain
icons that exist in Windows format for common DOS applications, may be used in
OS/2.
Migrate can be run during the install process or at any time after (the Migrate
object is found in the System Setup folder).
Migrate Applications object
System Administrators can set up their own custom migration database, to set up
applications unique to their environment, using the PARSEDB tool supplied with
OS/2 2.0. Thus, an optimal collection of DOS Settings can be determined for a
given program, and then supplied to other users.
ΓòÉΓòÉΓòÉ 7.6.6. Virtual Machine Boot (VMB) ΓòÉΓòÉΓòÉ
Should neither the basic DOS emulation of OS/2 2.0 nor any DOS settings provide
an answer to compatibility problems with a given DOS application, the ultimate
recourse is to boot the real version of DOS on which it depends, in a VDM. This
can be done either from the DOS boot diskette or from an image file created on
the hard disk. This applies not only to PC-DOS and MS-DOS versions, but also
non-IBM systems such as DR-DOS (and in theory any 8086 operating system
kernel). A VMDISK utility is supplied with OS/2 to create disk images.
Once booted, the VDM is running that real copy of DOS, and the boot image path
or drive becomes the A: drive for that VDM.
The VMB feature, by booting the "real" DOS, provides the maximum achievable
compatibility in a multi-tasking environment.
Even so, there will be some architectural compatibility issues that even VMB
cannot address. Most of these are limitations that arise from application or
device driver features that are fundamentally at odds with the principles of a
multi-tasking system. These issues include VDM interrupt latency (which may
prevent some DOS "real-time" applications from giving sufficient performance),
support for VCPI DOS extender applications (see below), and I/O to
system-managed DASD that bypasses the file system (the latter is prohibited for
obvious reasons - this could pose a threat to the integrity of the whole file
system and affect other applications.) But these are fairly minor restrictions
in an immensely wide scope of compatibility.
ΓòÉΓòÉΓòÉ 7.7. DOS extenders ΓòÉΓòÉΓòÉ
OS/2 2.0 can support DOS extender applications, those applications that have
broken the 640KB limit by running in protected mode and including their own
memory manager which "takes over" from DOS's. These include DOS multi-tasking
environments such as DESQview or Windows 3.x, as well as applications that
include DOS extender code, such as 1-2-3 3.1+.
OS/2 2.0 supports the DPMI (DOS Protected Mode Interface) specification for
extender applications, allowing applications written to this specification to
run under OS/2 2.0 and access up to 512MB of extended memory (see the
description of DPMI in Definitions ). OS/2 2.0 is a DPMI host, which provides
DPMI services to DOS extender applications (DPMI clients).
VCPI applications will not run under OS/2 2.0 because they are architecturally
incompatible with a multi-tasking operating system (see Definitions ). VCPI
applications do not run under Windows 3.0 or 3.1 either. However, many VCPI
applications have been rewritten to support DPMI, in order to support Windows
3, and OS/2 2.0 can take advantage of all of these.
ΓòÉΓòÉΓòÉ 8. Better Windows ΓòÉΓòÉΓòÉ
One of the most popular DOS extenders is Microsoft Windows. Windows 3.0 shipped
in May 1990, and gained a lot of media attention in the market. In April 1992,
Microsoft shipped an updated version, Windows 3.1, which was originally
described by Microsoft as a "maintenance" update, but has added a number of new
features, to address some of Windows 3.0's limitations. In this chapter, most
discussion will refer to both Windows 3.0 and 3.1 together as Windows 3.x,
since, except for some details, they compare to OS/2 2.0 in roughly the same
way.
Though Windows has undoubtedly had a significant impact on the market, there
has been considerable speculation in the press about how successful it has
been. Microsoft claims that over ten million copies of Windows 3.0 were sold
up to March 1992 (although IDC estimate that more than half of these may have
been shipped with the purchase of a new machine, of which they and Creative
Strategies estimate only 30 and 55% respectively, are in use). The company
also said that it shipped 3 million copies of Windows 3.1 in the first three
months after its shipment. However, in a report in the Wall Street Journal in
August, a spokesperson for the software retailer, Egghead, commented that the
preloading of systems like Windows with hardware, had affected retail sales.
She said that the company overstocked Windows 3.1 in anticipation of a heavy
retail demand for the system that failed to materialize. "We bought strong
quantities of Windows 3.1 and they've been selling at a slower rate than we
anticipated," she said.
Windows Magazine, in its October 92 issue, estimated that the "real situation"
with regards to the number of Windows users was around 4.5 million. A recent
Dataquest study estimated that as of September 1992, 18% of the PCs in the US
are running Windows, which equates to around 2.6 million users. This concurs
with figures quoted in OS/2 Magazine from ADAPSO/ITAA, saying that Windows has
penetrated only just over 10% of the total DOS market. Whatever figures are
used, Windows Magazine says that "financial analysts and software
companies...uniformly dismiss [Microsoft's figure of 13 million Windows users]
as meaningless."
There have also been a number of ISVs developing applications for Windows.
According to Microsoft, over 4,500 applications had been developed for the
Windows environment by March 1992.
Windows 3.x is, of course, in one sense an alternative or competitive solution,
since it provides a GUI and a basic multi-tasking environment. On the other
hand, some customers require IBM to support the Windows applications that they
have purchased, under OS/2 2.0. This section examines OS/2's relationship to
Windows 3.x, and how OS/2 can be a "better Windows".
ΓòÉΓòÉΓòÉ 8.1. What is MS-Windows? ΓòÉΓòÉΓòÉ
First of all, it is important to understand what Windows is. When it was first
released in 1985, it provided a GUI environment running under DOS, for which
applications had to be specially written to take full advantage. Although
versions before version 3.0 had gained some developer support, market success
was comparatively limited, and many of the major ISVs (eg Lotus, WordPerfect,
Borland) had not developed Windows-specific applications. Some of the reasons
for this were perhaps the lack of Windows-capable machines, the limited
multi-tasking, and the fact that it provided only limited relief for the two
main perceived limitations of DOS: the 640KB memory barrier, and multi-tasking
the DOS applications that people already had. Windows 3.0 overcame many of
these problems, especially in being able to multi-task DOS applications and
allowing Windows itself to take advantage of extended memory.
ΓòÉΓòÉΓòÉ 8.1.1. Windows 3.x modes ΓòÉΓòÉΓòÉ
The Windows environment itself has three modes, though the options available to
any user depend upon machine processor and installed memory. These modes are
important to mention here as they are relevant to the discussion later of how
OS/2 runs Windows applications. The italicised description of the three modes
comes from the MS-Windows User's Guide:
ΓòÉΓòÉΓòÉ 8.1.1.1. Real mode (NOT AVAILABLE IN WINDOWS 3.1) ΓòÉΓòÉΓòÉ
An operating mode that Windows runs in to provide maximum compatibility with
versions of Windows applications prior to 3.0. Real mode is the only mode
available for computers with less than 1MB of extended memory.
Real Mode is equivalent to previous versions of Windows (2.x), and can address
640KB conventional memory, plus LIM 4.0 expanded memory (extended memory can be
used for a virtual disk or disk-caching only). Real Mode requires an 8088
processor or above, and 640KB memory (384KB free conventional memory after DOS
and other memory resident software including network drivers).
Microsoft withdrew support for real mode in Windows 3.1, so that only standard
mode and 386 enhanced mode are now available. This means that programs
requiring Windows real mode (eg programs written for Windows 2.x) will not run
in Windows 3.1. However, Windows real mode programs (including Windows 2.x
applications) WILL run under OS/2 2.0. In this respect, OS/2 2.0 is providing
better support for Windows programs than Windows 3.1 itself.
Note that although Windows real mode runs in the real mode of the processor
(see Protected mode operation ), the two are not identical terms; even though
Windows 3.1 has eliminated Windows real mode, it cannot by its very design
prevent the system moving out of protected mode into the real mode of the
processor, and this represents a potential hole in system integrity (see
Reliability and protection and Reliability for more on this subject).
ΓòÉΓòÉΓòÉ 8.1.1.2. Standard mode ΓòÉΓòÉΓòÉ
The normal operating mode for running Windows. This mode provides access to
extended memory and also lets you switch among non-Windows applications.
Standard Mode uses 286 protect-mode to give Windows and Windows applications
direct access to up to 16MB extended memory. Expanded memory for DOS
applications is only supported with physical expanded memory cards (not
emulation of expanded memory using extended memory). Standard Mode requires a
286 processor or above, 1MB memory (minimum 256KB of free extended memory), and
the XMS driver HIMEM.SYS loaded. Windows applications need to be written to
comply with the memory management rules for Windows 3.x to run in Standard
Mode.
Standard mode is recommended by Microsoft when running only Windows
applications (ie no DOS applications) in certain configurations, even on a 386.
ΓòÉΓòÉΓòÉ 8.1.1.3. 386 Enhanced mode ΓòÉΓòÉΓòÉ
A mode that Windows runs in to access the virtual memory capabilities of the
Intel 80386 processor. This mode allows Windows to use more memory than is
physically available and to provide multi-tasking for non-Windows applications.
386 Enhanced Mode uses protected mode to give Windows and Windows applications
direct access to up to 16MB extended memory. The Virtual-8086 mode of the 386
is used to provide multiple DOS environments for non-Windows applications, and
virtual memory support is provided (for Windows applications only) using the
demand paging feature of the 386 processor. Most DOS applications can be run in
a window. 386 Enhanced Mode requires a 386 processor or above, 2MB memory
(minimum 1024KB of free extended memory), and the XMS driver HIMEM.SYS loaded.
Windows applications need to be written to comply with the memory management
rules for Windows 3.x to run in 386 Enhanced Mode.
ΓòÉΓòÉΓòÉ 8.1.2. Windows 3.x key aspects ΓòÉΓòÉΓòÉ
Windows 3.0 added a number of extra features to previous Windows releases, but
many people believe that its three main features are as follows:
ΓòÉΓòÉΓòÉ 8.1.2.1. DOS extender (memory > 640KB) ΓòÉΓòÉΓòÉ
Windows 3.x is first and foremost a DOS extender. It is itself a DPMI host
application running on top of DOS, which provides applications (in this case
Windows applications written specially for that environment) with extended
memory support to break the 640KB DOS limit.
Windows can provide additional memory for applications that have been written
to take advantage of this capability. But the vast majority of applications
still are written for the DOS environment, and even under Windows can only
address up to 640KB. In fact, as we saw in our discussion on memory available
under OS/2 2.0 and Windows earlier, since Windows inherits the DOS environment
for each DOS application it runs, it provides less memory in most scenarios
than would be available under OS/2 2.0, for the same DOS application in the
same configuration.
Nevertheless, since Windows, in standard and enhanced modes, runs much of the
time in protected mode (requiring a 286 or 386 processor for these modes), it
can itself take advantage of extended memory to run, leaving conventional
memory free for DOS applications (but at the cost of some overhead in
conventional memory for Windows itself - see Comparison with memory usage under
DOS ).
ΓòÉΓòÉΓòÉ 8.1.2.2. Multi-DOS environment ΓòÉΓòÉΓòÉ
Windows 3.x also offers, in its 386 enhanced mode, multi-tasking of DOS
applications. Several DOS applications can be run at once, and most text-based
applications can appear in a window alongside other DOS or Windows
applications, in 386 enhanced mode. However, Windows 3.0 enhanced mode does
not offer as flexible support as OS/2 2.0 does, for running graphics-based
applications - like Microsoft Flight Simulator - in windows on the screen
alongside text-based applications. DOS applications running in VGA mode can be
displayed in a window on the Windows 3.1 desktop, but according to Microsoft,
Windows/NT will not support windowed DOS VGA graphics at all. (**)
In enhanced mode, Windows also provides a pre-emptive time-slicing mechanism to
multi-task between these DOS applications, though, as we saw before (
Multi-tasking of DOS applications ), OS/2 2.0's mechanism is more sophisticated
and will tend to provide a more balanced performance when multi-tasking DOS
applications. For many users of 386 machines running on a DOS base, Windows
enhanced mode provides welcome additional function, and the ability to swap
between their DOS applications. Standard mode allows multiple DOS applications
to be loaded, but they do not run in background nor can they be windowed.
ΓòÉΓòÉΓòÉ 8.1.2.3. Windows applications ΓòÉΓòÉΓòÉ
Of course, there have also been a number of applications written specifically
for Windows 3.x. These are graphical applications written to the Windows APIs,
and can take advantage of extended memory (up to 16MB), the GUI environment, as
well as Windows system-supported functions like DDE (Dynamic Data Exchange).
Although the Windows environment was ignored by many of the major vendors at
first, there are now many applications developed specifically for Windows 3.x.
Applications developed for previous releases of Windows cannot run reliably
under the two higher modes of Windows, but only under real mode. This means
that if you are running Windows 3.0 in standard or enhanced mode, and wish to
run, for example Excel 2.1, you must close all your Windows and DOS
applications, exit Windows and restart in real mode. Windows 3.1, because it
does not support real mode, will not run Windows 2.x applications at all. OS/2
2.0 can run real and standard mode Windows applications side by side on the
Workplace Shell desktop.
Although Microsoft claims that there are over 5,000 Windows applications in the
market, the majority of applications sales are still in DOS applications (to
say nothing of the installed base). There are many items of evidence to back up
this statement:
o Sales of DOS applications were still $112 million more than those of Windows
applications in the second quarter of 1992 (Software Publishers' Association
- SPA)
o In figures quoted in Windows Magazine, based on projections by Dataquest,
Windows applications still represent less than 25% of the market in most
application categories, and never as much as half in any (see the graph below
which illustrates these figures in detail)
o Even in 1997, DOS applications will outsell Windows applications (Dataquest)
Windows application sales as a proportion of total PC application sales
o Many PC publications both in Europe and the US track sales of applications
from a variety of channels, in order to determine a "Top 20" list of
applications. The trend since May 1990 is clear: despite the apparent
success of Windows in the market, few Windows applications make it into the
Top 20, as the graph below shows. In fact, there are rarely more than 5
Windows applications in the top 20, and only two of them regularly appear -
Excel for Windows and Word for Windows by Microsoft.
Number of Windows applications in the top 20 selling applications
o There have also been several news items showing how the Windows applications
market may not be as large as some vendors may have suggested. Here are some
references from recent reports:
- "The smaller software companies are not making money out of Windows, and
Windows 3.1 is not going to change that" (International Data Corp.) (**)
- "The Windows market is really only the size of the Macintosh market"
(Gordon Eubanks, CEO of Symantec, who produce Norton Desktop for Windows,
one of the best selling Windows applications)
- Lotus warned analysts of lower than expected revenues in June 1992,
blaming "weakness in the market for Windows spreadsheets rather than loss
of [market] share". "We're disappointed that the overall Windows apps
market didn't explode like the channel thought it would" (Robert Weiler,
Senior VP, Lotus)
- Lotus is not the only major Windows vendor to suffer falls in share prices
owing to lower sales of Windows applications: Aldus reported lower
earnings at the end of June 1992, owing to, among other reasons, "lower
than expected sales of its Windows-based products".
- Ruthann Quindlen, a software industry analyst, was quoted in an interview
with Infoworld's editor, that she "regret[ted] saying... that Windows was
going to create opportunities for small PC software companies". Listing
many software companies suffering from slowing growth, earnings
shortfalls, falling stock prices, she "had hoped that Windows would grow
the market...But no." She concluded that "the only Windows apps doing well
are Microsoft's"
- "Companies that have invested a lot of money in developing Windows
applications are battling for a small share of what is a very small pie"
(Personal Computer Magazine (UK), May 1992)
o Windows applications are still heavily outnumbered by the 20,000 or more DOS
applications, which also tend to have been longer in the market and built up
a substantial installed base.
In fact, there is also much evidence to suggest that Windows itself is
outselling Windows applications by a factor of three or four to one:
o in the year to March 1992, when Microsoft claimed there were ten million
copies of Windows shipped, IDC estimated 3.5 million Windows applications
were sold.
o In early 1992, Microsoft stated that there had been $1.6 billion of Windows
applications sold. If we take an average price of $500, this would give just
over three million copies of all Windows applications together.
o In October 1991, Windows annual run rate, according to Microsoft, was 7.8
million. The SPA's estimate of the volume of Windows application sales for
1991 was $1000 million. This could mean that for every copy of Windows
shipped, there was just over $120 spent on Windows applications, or about one
quarter of a copy of Lotus 1-2-3 for Windows at its current recommended
retail price!
If Windows were being used primarily to run Windows applications, one might
expect the user to have more than one Windows application. On this assumption,
the number of Windows application users may be only 15% or less of the total of
Windows users. Either many people have bought Windows and are not using it, or
they are using it for something else.
A study of PC Magazine subscribers indicates a possible answer. The study was
conducted in the US by Ziff Davis Research Department and Alpert Research,
Inc., of 1840 PC Magazine readers. The study has been reviewed by William
Zachmann, a well known independent commentator on the industry, in the June 11,
1991 issue of PC Magazine (Volume 10, Number 11, Page 97). Zachmann reported
that respondents who personally used or were familiar with Windows, confirmed
that the most desirable features of Windows were its memory management,
multi-tasking and extended memory capabilities. GUI capabilities, and the
availability of Windows applications were of only secondary importance.
Windows user survey quoted in PC Magazine June 11, 1991 issue
Zachmann's conclusion was:
" "All of this strongly supports my contention that Windows 3.0's success
is due more to its usefulness as a reasonably good DOS memory manager and
multi-tasker, than to any groundswell of support for GUIs and Windows
applications. The study results also corroborate my observation that
sales of Windows applications lag far behind reported sales of Windows
itself." "
Many observers agree with Zachmann, that it has been the combination of DOS
extender and basic DOS multi-tasking, implemented on a DOS base, that has been
the principal factor in Windows' success. This indicates that Windows is being
used more as a DOS extender and multi-tasker than as an environment to run
Windows applications. Even vendors such as Lotus, who are developing a suite
of applications for Windows, have claimed that Windows is being used to run
DOS applications more than it is used for Windows applications.
This is an important consideration when we look at what it means to be a
better Windows than Windows. It seems as if many users look to Windows as a
DOS environment first, and that Windows applications are currently a secondary
issue. Therefore, to be a better Windows than Windows, OS/2 2.0 needs to:
o first, be a better DOS extender/multi-tasker
o and run Windows applications, first ensuring compatibility and, if possible,
some advantages over running it under Windows.
As it happens, OS/2 2.0 is able to do both: create a better DOS environment
for DOS applications, as well as provide full compatibility for Windows
applications, and even some advantages in that respect.
ΓòÉΓòÉΓòÉ 8.2. OS/2 versus Windows as a multi-DOS environment ΓòÉΓòÉΓòÉ
It is clear that any discussion of Windows cannot ignore its DOS heritage. In
fact, this is both its great advantage, but also the source of most of its
shortcomings. Windows runs under DOS, which is an advantage from the point of
view of migration from DOS, but is also a disadvantage in the limitations that
DOS imposes on it.
ΓòÉΓòÉΓòÉ 8.2.1. Memory ΓòÉΓòÉΓòÉ
For example, we have already seen that since each DOS session created in
Windows inherits the whole DOS environment in place before Windows loaded, DOS
programs may have limited space in which to load. Although the combination of
DOS 5.0 and Windows 3.x helps to relieve some of the pressure on conventional
memory, most DOS applications have significantly less memory under Windows than
they do under OS/2 2.0 (see Comparison with memory usage under DOS for
details.)
ΓòÉΓòÉΓòÉ 8.2.2. Reliability ΓòÉΓòÉΓòÉ
DOS was designed as a single-tasking environment. Although DOS extenders like
Windows can provide multi-tasking under DOS, the base system was never designed
for it, and many of the applications running under such an environment assume
they are the only application in the system. DOS runs in real mode, and does
not provide protection between processes. Windows provides this protection
instead, allowing a measure of multi-tasking. However, Windows still needs to
use DOS for certain system functions, and so do many of the DOS-based TSRs (eg
Network and Communications drivers) that are needed to run alongside Windows,
and hence real mode is difficult to avoid when running Windows 3.x. Any time
that is spent in real mode is a potential "trap door" for application errors to
violate the system's integrity. Even though DOS applications run in separate
address spaces in enhanced mode, DOS and DOS TSRs still require access to real
mode, and the potential remains for an application conflict or bad pointer to
corrupt the DOS system area or Windows itself.
Furthermore, Windows applications all run in the same address space under
Windows 3.x, and therefore it is possible for an error in a Windows program, to
take down all the Windows applications together, and sometimes the whole
system, thereby affecting the DOS applications as well. These symptoms occur
in a variety of ways, not always a "crash" or "hang" but sometimes messages
like "This application has violated system integrity" or "Unrecoverable
Application Error".
Windows 3.1 is claimed by Microsoft to provide greater protection from these
errors, by checking the parameters passed by applications, The users of Windows
3.1 will judge how effective this will prove, but it is a significant technical
challenge to provide full protection under DOS, unless an attempt is made to
eliminate real mode (of the processor, not Windows real mode) execution
altogether. Indeed, although the message "Unrecoverable Application Error" no
longer appears, it has been replaced in many scenarios by "Application Error"
or "General Protection Fault". In some circumstances, Microsoft still advise
that data in other sessions be saved, but then to exit and restart Windows,
perhaps even reboot. In this case, the effects on a user would be little less
drastic than before. In fact, though some have claimed that Windows 3.1
heralds "the demise of the UAE", the essential aspects of the Windows
architecture remain unchanged. Windows applications still execute in the same
address space, still sharing a common Local Descriptor Table, or LDT (this is
why parameter checking is needed, but it only attempts to catch problems to
which the basic architecture leaves the system prone). Parameter checking is
much more important to Windows than it is for OS/2, which has other mechanisms
(notably separate address spaces) to protect the system from wayward
applications.
Furthermore, although many I/O and other functions are taken over by Windows (
leading Microsoft to call Windows 3.1 an "operating system" (**) ), DOS and
DOS TSRs are still available (and indeed required if you want to run Windows on
a network, or with host communications), so the system still does not close the
real mode "trap door".
Any access to real mode is a potential danger; this is true even in OS/2 1.3,
where the DOS compatibility box ran in real mode and was therefore a potential
danger to system integrity. The only certain way to high reliability is to run
the operating system only in protected mode. No current version of DOS can do
this, but OS/2 2.0 runs entirely in protected mode: even when running DOS
applications, there is no real mode operation.
OS/2 has been designed for high reliability from the start, and version 1.3 is
already widely respected for its industrial strength design. In OS/2 2.0, all
applications, both DOS and OS/2, and even Windows applications, run in separate
process address spaces, protected from each other, and much care has been taken
in the design to avoid giving wayward applications the potential to corrupt any
other applications or the system. Usually in OS/2 2.0, the worst a "bad"
application can do is to cause an error that will cause the kernel to have that
process stopped and closed. In these circumstances, the other applications
continue running unaffected. This is why OS/2 has already been chosen by many
companies as the development environment for line of business, mission critical
applications. If your business depends on your application, you do not want to
see it brought down with a UAE.
Some have tried to show that OS/2 can be "broken" by wayward applications, but
no operating system is safe from code written with inside knowledge of the
system internals, designed specifically to manipulate parts of the system in a
destructive way that mainstream applications would never attempt. The added
protection OS/2 offers compared to other DOS extender alternatives, is against
the occasional bugs in applications that cause them to write to memory where
they should not. The issue is not really whether either environment is totally
"crash-proof" but the overall integrity of the operating system in day-to-day
usage. In this case, we are not really comparing OS/2 to Windows, but OS/2 to
DOS.
ΓòÉΓòÉΓòÉ 8.2.3. Performance ΓòÉΓòÉΓòÉ
OS/2's multi-tasking design is more sophisticated than Windows, allowing DOS
applications to multi-task more smoothly. Windows has only a simple
time-slicing algorithm, which can be adjusted by the user to give "bias" to
certain applications. This means that priority levels are static, and do not
take into account, for example, when applications are I/O bound. On the other
hand, OS/2 can set priority levels dynamically, detecting when applications are
"idle" through polling or waiting for I/O, and assigning CPU cycles to other
applications. This advanced scheduler works in a similar way with OS/2
applications, pre-emptively multi-tasking them alongside the DOS applications.
Even Windows applications running in VDMs take advantage of this superior
scheduling mechanism for smoother multi-tasking. Windows 3.x offers only
co-operative multi-tasking between Windows applications, but pre-emptive with
respect to the rest of the system. This means that applications have to be
specifically written to give the processor up, with yield() calls, to allow
other Windows applications to have their fair share of the processor. (See
Multi-tasking of DOS applications and Multi-tasking for a more complete
discussion of this topic.) In OS/2 2.0, Windows applications can be
pre-emptively multi-tasked by running them in separate VDMs.
OS/2 offers a choice of two superior file systems, which DOS applications
running under OS/2 use whenever they do file I/O. OS/2 2.0 has the High
Performance File System (HPFS) and an enhanced FAT file system, both of which
provide superior performance than under DOS in nearly all situations. This
means that in file-based operations, OS/2 will nearly always be quicker than
DOS or Windows running the same combination of applications under the normal
DOS-based FAT system. Furthermore, OS/2 is able to overlap I/O requests to the
system, taking advantage of its own multi-tasking design, allowing the system
to be more responsive to I/O request and keep applications waiting less.
The result of this is that the same combination of multiple DOS applications is
likely to run faster under OS/2 than under either DOS or any DOS extender like
Windows, if it does any significant disk-based I/O. Applications that are more
compute-bound may show less difference (and in single tasking, DOS itself is
obviously likely to be faster in all except file-intensive operations).
And when more than one task is being done, OS/2's performance advantage becomes
evident. Because of OS/2's superior multi-tasking, it can run background
tasks, such as file copying, communications, or spreadsheet recalculation, with
no visible impact on foreground work. With Windows, the cursor movement can
lag behind the mouse movement, and displaying of characters can lag behind
keyboarding to the point where system becomes almost unusable until the
background job is done.
Here is an illustrative scenario from the testing of National Software Testing
Laboratories (NSTL), and independent testing and evaluation organisation: to
load MS Word for Windows on a PS/2 Model 57 with 8MB, with nothing else running
takes 7.2 seconds with Windows 3.1 and 9.3 seconds with OS/2 2.0. If you do
the same load with an XCOPY in the background, Windows load time jumps to 41.1
seconds, compared with 15.3 seconds for OS/2.
Again, the comparison is really between OS/2 and DOS - Windows simply runs on
DOS and inherits its limitations.
ΓòÉΓòÉΓòÉ 8.2.4. Integration ΓòÉΓòÉΓòÉ
One of the other big differences between the DOS compatibility provided by OS/2
compared to that of Windows is in the area of how easy it is to set up DOS
applications to work. There are many ways in which DOS applications integrate
much more easily into the OS/2 environment than they do under Windows:
o DOS Settings vs PIF files: Many have commented that Windows's method of
assigning special settings to a DOS program via a Program Information File
(PIF) is cumbersome. This is even more so compared to the consistency of the
way the DOS Settings option is implemented in OS/2 2.0. Compare, for
example, WordPerfect 5.1 for DOS. Both Windows 3.1 and OS/2 2.0 detect the
program's presence on the disk, and create a unique set of program settings.
But with OS/2 2.0, all of these settings are easily found together by
clicking on the settings of the program object's icon. In Windows, clicking
on the icon in Program Manager allows you to select its basic properties
from the File Properties menu in Program Manager. But the dialog allows you
only to change the command invoked, the working directory and icon. To
change other options, you need to find the PIF file referenced in File
Properties and edit the PIF file with the PIF editor (which by default is
also in another program group). The PIF file contains all the other settings
such as video mode, EMS/XMS settings, priority and idle detection, but also
confusingly has options for startup directory and shortcut key, which are
equivalent to (but overridden by) the settings in File Properties in Program
Manager. So there are two places to look for settings, and sometimes two
places to set the same setting. Furthermore, some important options are
missing altogether from the PIF or Program Manager; mouse access in a
windowed DOS application, for example, can only be achieved by first loading
the DOS mouse driver (which is distinct from the Windows mouse driver - you
need two mouse drivers if you want to use the mouse for both Windows and DOS
applications) before starting the application. Searching on "mouse" in the
Windows help system does not yield this information. OS/2 allows the user
to find all customisation for a given program in one settings notebook:
command, working directory, icon, EMS, mouse access and so on.
o Multiple working combinations: The amount of memory available when running a
DOS program in Windows 3.1 enhanced mode is at most about 580K, and can be
considerably less than 500K in a LAN-connected environment. And the more
features that are required (eg 3270 access, country settings) means less
memory for DOS sessions. This can mean that larger DOS programs, including
many newer DOS programs or latest versions, do not have enough memory to
run. Thus, users are faced with having to run different combinations of
applications: DOS program plus network but not with Windows; a Windows
program with the network, but not the DOS application, and so on. Some
users even have to maintain different CONFIG.SYS and AUTOEXEC.BAT
combinations, rebooting between them according to the combination of
applications they are running. Many users also have to buy third party
utilities such as QEMM, and experiment with various settings, to get the
amount of memory they need. Use of such utilities sometimes creates new
integration issues, such as getting memory managers, disk cache programs and
network drivers to co-exist. In OS/2 2.0, not only can different
applications be run at the same time as well as the network, but also any
different combinations of settings can be easily maintained in DOS settings,
and different configurations run at the same time.
o Swap file: To allow for better performance in swapping to and from disk in a
memory-constrained environment, Windows 3.x offers a permanent swap file.
This is a contiguous area of disk, usually not accessible via DOS commands,
and therefore preventing other files making any use of that space. Indeed,
even if Windows does not need the full amount of space, it cannot be
regained for application use until the feature is disabled. The OS/2
SWAPPER.DAT file is designed to shrink as well as grow, so it is more
flexible in allowing other files to be created alongside it.
These are a just a few examples of the way in which OS/2's integration of DOS
applications is superior to that of Windows 3.1, and such integration
translates into lower running and support costs.
In conclusion, we can certainly say that as a DOS environment, which appears
to be the most important consideration even to many Windows users, OS/2 is a
better Windows than Windows. Now let's take a look at the other
consideration, compatibility with Windows applications.
ΓòÉΓòÉΓòÉ 8.3. Running Windows applications under OS/2 ΓòÉΓòÉΓòÉ
ΓòÉΓòÉΓòÉ 8.3.1. Standard mode support ΓòÉΓòÉΓòÉ
As far as OS/2 2.0 is concerned, Windows applications are just a special case
of DOS applications, which need a special environment (Windows 3.x) to run. The
key, therefore, to Windows applications compatibility, is to provide those
applications with as similar an environment as possible to what they have under
DOS, while taking advantage of the inherent design superiority of OS/2.
First of all, it should be understood that the Windows 3.0 shrinkwrapped,
retail package, can be run in a VDM in Windows real mode, (though Windows 3.1
cannot be run in this way because it does not support real mode) and Windows
applications started from within this VDM by the Windows Program Manager. It
cannot be run in standard or enhanced mode because of the way Windows has
implemented the DPMI memory management scheme (it assumes it is a DPMI host and
cannot act as a DPMI client - see DOS extenders ). Many Windows applications
run in real mode quite adequately. In fact, applications written for Windows 2
cannot run in any other mode, and therefore will not run in Windows 3.1. It
may be true that many Windows applications have been upgraded for Windows 3,
but this forces an upgrade on users who may be quite happy with the function in
their current package. It means that the Windows upgrade path is now closed to
users of Windows 2 based applications. OS/2 2.0 does not force such a choice,
and will run Windows 2 and Windows 3 applications side by side, without having
to exit and run in another mode. In fact, some have commented that it is
ironic that OS/2 2.0 runs a wider range of Windows applications than Windows
3.1 itself.
Standard mode is needed for many Windows applications (eg Excel 3.0 and 4.0).
To accommodate these applications, OS/2 needs to provide additional support.
Basically, these applications need to access DPMI services for extended memory
support, which is usually supplied by Windows 3.x running in standard mode or
above. As we have seen already, OS/2 2.0 offers DPMI services and the ability
to access extended memory.
The other requirement is to supply Windows services to Windows applications.
This is done in OS/2 2.0 by modifying the Windows kernel and running it in
standard mode in a VDM. As part of the joint development and cross-licensing
agreement between IBM and Microsoft, IBM has access to both the Windows 3.0 and
3.1 source code. IBM has modified the source to provide a Windows kernel
capable of running as a well-behaved DPMI client within an OS/2 VDM (the retail
version of Windows 3.0 can only be a DPMI host). This means that OS/2 2.0
includes all the necessary Windows code to run Windows applications. A separate
copy of Windows 3.x is not required. The Windows environment in OS/2 is called
WIN-OS/2.
Since Windows 3.1 shipped after OS/2 2.0, OS/2 provides a modified Windows 3.0
kernel in the release made generally available in March 1992. IBM has the
ability to, and intends to, include Windows 3.1 support in a future update,
even though there are very few applications that require this support (see
Windows 3.1 ).
OS/2 therefore supports Windows applications running in standard mode in a VDM.
This means that the Windows kernel that runs under OS/2 runs in standard mode,
and Windows applications run just as they would under DOS Windows 3.x in
standard mode. The use of the VDM design, which provides a self-contained DOS
environment, means that the environment is identical, from the application's
point of view, to running under Windows loaded in standard mode, on DOS. This
design therefore provides the maximum compatibility with the DOS/Windows
environment. In fact, it offers a wider range of compatibility, since Windows 2
applications, which require real mode operation under Windows 3.0 in DOS, can
be run alongside Windows 3.0 applications running in standard mode. This
combination is not possible at the same time in Windows 3.0, and is not
possible at all in Windows 3.1, since Windows real mode has been discontinued
in Windows 3.1.
ΓòÉΓòÉΓòÉ 8.3.2. 386 Enhanced mode ΓòÉΓòÉΓòÉ
Windows has another mode - 386 enhanced mode, which requires the 386 processor.
OS/2 2.0 does not need to support enhanced mode for Windows applications, since
for most Windows applications, there is no difference between standard and
enhanced as far as the application itself is concerned. Standard mode provides
Windows applications with all the memory management and other functions they
need. Enhanced mode adds to standard mode the capability for multi-tasking DOS
sessions and demand paging for efficient virtual memory, both of which are
provided (in a superior fashion) by OS/2 2.0 itself. Indeed, Microsoft
recommends in the Windows 3.0 manual on page 429, that users running only
Windows 3.0 applications should run in standard mode, even on 386 systems with
2-3MB of memory, as there is a performance improvement in doing so. Therefore,
OS/2 2.0 provides equivalent function to enhanced mode for most users.
There are, however, a small number of Windows applications which require
enhanced mode to run. These are not supported in the first release of OS/2 2.0.
It is believed that there are only at maximum three or four of these in the
market, which represents less than 0.1% of Windows 3.x applications, if we take
Microsoft's figure of 5,000 Windows applications. Such applications require
enhanced mode either because they rely on features only available in enhanced
mode, or have been coded using the WINMEM32.DLL, a set of routines that provide
some 32-bit functions for Windows applications, such as Wolfram Research's
Mathematica and Caere Omnipage Professional. It is unlikely there will ever be
many in the latter category of applications, since the WINMEM32.DLL is very
difficult to use, and Microsoft themselves warn in Appendix E of the Windows
Programmers Reference: "only experienced Windows application programmers with
extensive experience writing assembly-level code should attempt to use these
functions in an application." That is because even something as basic as
memory management using these routines can be very complex, requiring the
programmer to create his own assembly language interfaces between the 16 and
32-bit parts of his program (note that such "thunks" are provided by OS/2 2.0
between 16 and 32-bit modules - see Mixed 16-/32-bit environment ). Charles
Petzold, possibly the most widely respected authority on Windows programming,
whose book on the subject is a standard reference work, concluded on this
subject that "something is seriously wrong when memory access becomes
difficult", and contrasted the current Windows approach with the ease of 32-bit
memory management under OS/2 2.0. At the time of writing, Microsoft had not
stated whether WINMEM32.DLL applications would be able to run under a 32-bit
Windows environment and have said that it is unlikely that such Intel-specific
applications would run unchanged in a future version of Windows/NT running on a
RISC processor.
So, although there are a very small minority of Windows applications that will
not run under OS/2 2.0, the vast majority will run, and in a mode which allows
access to their full function. Indeed, to the Windows application, the
environment will appear exactly the same as under DOS/Windows standard mode,
but there will be greater overall protection, and the ability to pre-emptively
multitask such applications along with DOS, OS/2 and other Windows
applications.
ΓòÉΓòÉΓòÉ 8.3.3. Contrast with previous approaches (BCL) ΓòÉΓòÉΓòÉ
It should be emphasised that IBM's approach of building Windows code into OS/2
is quite different from previous approaches by Microsoft, which have included a
Binary Compatibility Layer (BCL) which attempted to translate Windows calls to
PM calls in real time. By providing the "real" Windows code, modified mostly
for memory management purposes, the potential for performance degradation is
greatly minimised. Those who previously suggested that IBM's approach is
"impossible" may have been thinking of a BCL-type approach, rather than the
method actually used in OS/2 2.0.
ΓòÉΓòÉΓòÉ 8.3.4. How they run ΓòÉΓòÉΓòÉ
ΓòÉΓòÉΓòÉ 8.3.4.1. Single session or separate session ΓòÉΓòÉΓòÉ
Windows applications can be started from an icon in the Workplace Shell, just
like other applications: OS/2 16 and 32-bit, DOS etc. They are launched into a
VDM which is, like other VDMs, protected from the rest of the system. Users
have a choice of loading the Windows application into its own VDM (even if
other Windows applications are already running in separate VDMs) or being
loaded into a VDM which contains other Windows applications. These are termed
Single application and Multiple application VDMs (SAVDM/MAVDM) respectively.
This is controlled in the settings for the program object: when choosing
"WIN-OS/2 window", you can check (SAVDM) or leave empty (MAVDM) the check box
entitled "Separate Session"; or if running in a WIN-OS/2 Full Screen session,
simply load the program from the Program Manager in the Full Screen session in
the normal way.
Single and Multiple application Windows groups
Single application Windows sessions load the application executable (eg
EXCEL.EXE for Excel 3.0) along with a modified WIN.COM file (WINOS2.COM). This
is exactly the same effect as typing "WIN EXCEL" when running DOS/Windows 3.x.
The Windows application then runs under the WIN-OS/2 environment, in its own
VDM. As far as the application is concerned, this is exactly the same as
running under DOS/Windows; the modified Windows kernel provides the same
services in a compatible way. Additional Windows applications can be loaded
into separate VDMs in the same way.
Multiple application Windows sessions allow the user to run several Windows
applications within the same VDM. This is the closest possible fit to the
DOS/Windows usage, especially when run in a separate WIN-OS/2 Full Screen
session, when it is difficult to tell you are not running under DOS. In this
way, users migrating to OS/2 from Windows are able to run under OS/2 but have
the general "look and feel" of their DOS-based Windows environment.
Single application VDMs provide the best protected way to run Windows
applications under OS/2. Since the application runs in a self-contained Windows
environment in its own VDM, it is fully protected from other applications, and
the system is protected from it. This means that if the application crashes
for any reason, it only affects that VDM, and in fact only that one
application. Even other Windows applications running in other VDMs are not
affected. This is a significant improvement in reliability over Windows under
DOS (both 3.0 and 3.1), in which, since all Windows applications and Windows
itself share the same Local Descriptor Table (LDT), a failure in one Windows
application may bring down the entire Windows system or corrupt the data areas
of other Windows programs.
But even though the SAVDM is fully protected, it can still share data via
clipboard or DDE with other Windows applications or PM applications (see
Clipboard/DDE ).
However, each SAVDM must load its own copy of WIN-OS/2, and will therefore
increase the overall working set of OS/2, affecting memory requirements and
performance. If memory is limited, MAVDMs provide the ability to run several
Windows applications with less resources required. But this is at the cost of
losing the additional protection of the separate VDM. If one Windows
application crashes within a Multiple application Windows session, it may cause
all the applications within that VDM to fail; but the effect is only within
that VDM - the other VDMs running DOS or Windows applications within other VDMs
are not affected and continue executing. So even here there are benefits
running Windows applications under OS/2, for greater reliability from system
crashes. MAVDM will also lose the additional WIN-OS/2 benefit of pre-emptive
multi-tasking for the Windows applications within that VDM (but not any other
WIN-OS/2 sessions). MAVDM is also a requirement where Windows applications
need to communicate with each other via shared memory, and where applications
want to use OLE between each other (see OLE ).
ΓòÉΓòÉΓòÉ 8.3.5. Full Screen or Seamless ΓòÉΓòÉΓòÉ
In the Limited Availability version of OS/2 2.0 which shipped in December 1991,
a WIN-OS/2 VDM ran only in a separate Full Screen session. The user clicked on
an icon (eg WordPerfect for Windows) in the Workplace Shell, and a separate
Full Screen WIN-OS/2 VDM was launched along with the Windows application. The
user could toggle back and forth using Alt-Esc, Ctrl-Esc, or a little OS/2 icon
that appeared in the corner of the Windows screen. But this was the only
visual clue that you were in OS/2 at all: the screen looked exactly like
DOS/Windows 3.0. This Full Screen function is still provided in the product
shipped in March 1992 (there is an icon marked "WIN-OS/2 Full Screen" in the
Command Prompts Folder).
There are some minor differences between the icons that appear in the WIN-OS/2
Full Screen environment versus DOS/Windows: many of the Windows
mini-applications and utilities (eg Notepad, games, PIF editor) have OS/2
equivalents or are no longer relevant; others, such as the clock, are retained
for compatibility. OS/2 adds icons for returning to PM from a WIN-OS/2 Full
Screen session (since the Windows user wants to have access to either Ctrl-Esc
or Alt-Esc key combinations for compatibility with his Windows environment) and
for DDE management (see later).
The Windows print manager is retained, and Windows printer device drivers
supported. The Windows Control Panel can be used to install Windows printer
drivers not supported by OS/2, and to configure other Windows printer drivers,
just as in DOS/Windows.
This full screen Windows function fulfilled the commitment made in April to
provide Windows compatibility in 1991 (completed in the Limited Availability
(LA) product shipped in December 1991). But during the early autumn of 1991,
IBM received feedback from many of its beta testers to bring forward the
functions it had been discussing for a future version to run Windows
applications on the same screen as other DOS and OS/2 applications. The
decision was taken to move the GA (General Availability) date to March 1992 to
allow this function (and others) to be added. It was first shown in Lee
Reiswig's "OS/2 live" show at Fall Comdex in October 1991.
This latter function has since been called "Seamless Windows". But the term is
not very accurate; it was chosen by the marketplace, not by IBM. It is
important, in fact, to note that most of what makes OS/2 2.0 "a better Windows"
was already delivered with the LA product in December: protection between
applications, pre-emptive rather than co-operative multi-tasking for better and
more consistent multi-tasking performance, integration with other DOS and OS/2
PM applications via clipboard and DDE, with no loss of compatibility. Many
people still run their Windows applications full screen, even with the GA
version, as it does what they need. In fact, full screen has some benefits
over Seamless operation (better performance, especially for clipboard and DDE,
and more visually compatible with DOS/Windows).
In any case, much of the WIN-OS/2 environment represents a "seamless" migration
from the DOS/Windows environment anyway: automatic installation of Windows
printer drivers, re-creation of existing Windows program groups and WIN.INI
settings.
Also, for most users, the most important aspects of integration are to be able
to run all applications from the same user interface, and to allow all
applications to share data. These benefits apply to Full Screen and Seamless
operation alike. Windows applications can be loaded from the same folders as
DOS and OS/2 applications, from the new Workplace Shell, and data can be shared
via clipboard and DDE.
But in the context in which it refers to the opposite of "Full Screen",
"Seamless" operation merely refers to the way the WIN-OS/2 application is
displayed on the screen, in its own window on the Workplace Shell desktop as
opposed to in a separate Full Screen session (see the diagram below, using
Excel 3.0 for Windows):
Windows Full Screen and Seamless Sessions
Note that the fundamental way the WIN-OS/2 application works is the same
whether it runs Full Screen or Seamless: it runs in its own protected VDM; it
runs with the modified Windows code, it runs in standard mode. But the
additional element is the way the screen output is mapped on to the Workplace
Shell screen. Also, you can have any combination of SAVDM/MAVDM, or Full
screen/Seamless:
o SAVDM Full Screen (WIN-OS/2 Full Screen in DOS Settings)
o SAVDM Seamless (WIN-OS/2 window in DOS Settings - "Separate Session"
checked)
o MAVDM Full Screen (WIN-OS/2 Full Screen object in "Command Prompts")
o MAVDM Seamless (WIN-OS/2 Window - "Separate Session" unchecked; the default
for most applications)
ΓòÉΓòÉΓòÉ 8.3.5.1. How does it work? ΓòÉΓòÉΓòÉ
Please note that what follows is a simplified explanation. There are no
specific considerations for users or programmers in the way the Seamless
WIN-OS/2 operation works.
The two key considerations in the design of the "Seamless" function were:
1. Maintain compatibility
2. Retain high performance
This resulted in a more "low level" implementation to avoid the limitations
inherent in attempting to map Windows calls to PM. Instead, both the PM and
Windows screen device communicate with each other via a Virtual Device Driver
(VDD), VWIN, providing synchronisation of access to the video display
hardware. Each device driver "owns" its section of the screen. (This was a
significant task in the time available, even for VGA; it can easily be
understood why Seamless function is only available for VGA in the GA March 92
release, but drivers for above VGA are in development and will be delivered
later in 1992). A new entry in WIN.INI, SDISPLAY.DRV= , denotes the change.
The best way to understand the way it all works is to consider an example.
Refer to the numbered diagram below while reading the following explanation:
How Seamless Windows works
When a WIN-OS/2 application creates a window, the Windows screen device driver
requests the PM screen device driver to open up a "black hole" of the same
dimensions (see step 1 in the diagram). The Windows device driver then has
control of the video hardware and paints into this space (step 2).The result
is that the WIN-OS/2 application (which is completely unaware of this process)
creates its main and secondary windows on the Workplace Shell screen alongside
(and sometimes overlapping) other OS/2 application windows. Notice this means
that the WIN-OS/2 application paints its own frame controls and mouse pointer
(eg title bar, minimise/maximise buttons) and even the infamous Windows
hourglass!), and these controls will therefore look like Windows controls, not
PM ones. If you put Excel for Windows and Excel for OS/2 side by side, you'll
see the difference. Although this creates some minor visual inconsistencies
(most users don't even notice!), it preserves compatibility and performance.
The WIN-OS/2 application window can be sized and moved as normal merely
changing the co-ordinates of the "black hole" into which it paints (see steps
3A and 3B). The PM screen device driver repaints any part of the PM screen
space previously governed by the WIN-OS/2 window. Other WIN-OS/2 applications
(whether launched from the same WIN-OS/2 VDM or not) can create their own main
windows (see step 4), or the existing applications can create secondary
windows which can extend beyond the original window's co-ordinates. Corel
DRAW! for Windows creates a main window with a tool bar which hangs below the
bottom of the window if resized, resulting in a non-rectangular window. OS/2
2.0 handles such exceptions without a problem.
If an OS/2 application window is created, moved or resized to overlap a
WIN-OS/2 application's window (see step 5A) the PM screen device driver will
cause a "white hole" to be created in the "virtual" screen space of the
WIN-OS/2 session (step 5B). This causes the WIN-OS/2 application to avoid
painting the part of the window that has been "covered" by the OS/2
application, and restrict repainting to the portion which is still "visible"
under or around the "white hole" (see step 5C). If the OS/2 application
window is subsequently closed, moved or resized, the screen drivers
communicate again to change the size of the "white hole" (in a similar way
that the co-ordinates of the "black hole" are changed in step 3B).
The use of "black" and "white" holes means that WIN-OS/2 and OS/2 (including
DOS) application windows can overlap each other normally, without one
incorrectly painting over the other. The two screen drivers keep a record of
each other's state without affecting any of the OS/2 or WIN-OS/2 applications.
This means there are no significant compatibility or programming
considerations. Since the PM screen device driver is always aware of the
changes made by WIN-OS/2 applications' windows, there is no impact to OS/2
applications, and likewise for WIN-OS/2 applications which create, move,
resize and destroy windows in the normal way. Performance is good, because
communication is at a low level between screen drivers, not an API mapping
layer, and compatibility is excellent because no fundamental changes occur to
either the Windows GDI or PMWIN (the main window-creating components of
WIN-OS/2 and PM respectively). And as far as the user is concerned - it just
works, minimising the difference between DOS, Windows and OS/2 applications.
In fact, it achieves the aim of "seamlessness" by making applications behave
in similar ways, whether DOS, Windows or OS/2 applications. To the user, it
appears easy, but the technical accomplishment behind it is considerable.
ΓòÉΓòÉΓòÉ 8.3.5.2. High resolution support ΓòÉΓòÉΓòÉ
At General Availability time in March 1992, Seamless drivers were only
available in VGA. This means that the whole system (including PM) must run in
VGA if Seamless operation is required. The installation program gives users
with 8514/A or XGA adapters the choice between high resolution WIN-OS/2 in full
screen, or Seamless in VGA. Remember that the choice also affects the
resolution PM appears in. This choice will become redundant once Seamless
drivers for resolutions higher than VGA appear. Drivers for XGA and SVGA will
become available by the end of 1992 (see OS/2 1992 developments ).
Since OS/2 2.0 shipped in March, IBM and other vendors have continued work on
drivers at resolutions higher than VGA. Drivers for XGA and some SVGA chip
sets will be made available in a service pack by the end of 1992, rather than
than waiting for a new version of OS/2. It is to be remembered that to enable
Seamless operation, both Windows and PM screen drivers need to be modified, for
each resolution.
ΓòÉΓòÉΓòÉ 8.3.6. Clipboard/DDE ΓòÉΓòÉΓòÉ
An important benefit of the Windows environment is the inter-application
communications it offers to Windows applications, allowing them to share data.
The two most common methods for achieving this are via the clipboard, and
Dynamic Data Exchange (DDE).
The Windows clipboard, like PM's clipboard, usually allows applications to
share data on a "once only" basis. Data is "cut" from one application to the
clipboard, and "pasted" from the clipboard into another application.
Applications that support the clipboard sometimes allow a link to be set up
between applications, using the same or similar commands, and that link is
usually handled via DDE. DDE is a message-based protocol allowing applications
to pass information back and forth, updating items as they choose. For
example, an information feed like a stock market ticker, can be linked via DDE
to a spreadsheet, and update it with the latest information as the data
changes.
Both clipboard and DDE are supported for Windows applications in OS/2 2.0.
Since OS/2 already supports both of these functions (OS/2 1.3 provided similar
functions for OS/2 16-bit applications), it is mainly a matter of integrating
the Windows support within OS/2 so that Windows and OS/2 applications can
access the same function.
The way in which this is done in OS/2 2.0 is quite similar for clipboard and
DDE. Each requires one protected mode (OS/2) program acting as a "server" for
messages between applications. Also, in each VDM running a Windows
application, a pair of applications needs to be running: a modified version of
the Windows clipboard viewer program for clipboard, and a "ServerAgent" program
for DDE. The ServerAgent, which is started when the VDM is started, takes DDE
messages from the Windows application and routes them to the DDEServer and
receives messages from the DDEServer and passes them to the application running
in the VDM.
Clipboard and DDE are also available between applications running in the same
VDM. This works in exactly the same way as today under DOS/Windows; the local
VDM-based clipboard or ServerAgent programs are not needed unless clipboard and
DDE are required outside the VDM. Users can also specify that their clipboard
and DDE is local to that VDM only, or "public" to the whole system. If sharing
between Windows and OS/2 applications is not required, the clipboard should be
kept "private", to improve overall performance.
The result of this is that clipboard and DDE are supported in OS/2 2.0 between
Windows applications, and between Windows and OS/2 applications. DOS
applications can also participate in clipboard sharing. Thus, there is a
consistent way of sharing text and graphical data between DOS, Windows and OS/2
applications.
ΓòÉΓòÉΓòÉ 8.3.6.1. OLE ΓòÉΓòÉΓòÉ
Object Linking and Embedding (OLE) is a mechanism created by Microsoft and
endorsed by other vendors, to extend the data sharing currently possible in
Windows. It is intended to support the creation and editing of "compound
documents", where elements may come from a number of different applications,
and still be editable by the source application, even when linked in another
document or application.
Several ISVs are intending to support OLE, but today only a minority of
applications actually support it. Examples include Microsoft Excel version 3.0,
and Lotus Notes version 2.0. Windows 3.1 is expected to simplify the enabling
of this function, because it includes the necessary support in the product, but
applications still need to be rewritten to take advantage of it. Therefore, OLE
is more of a potential standard in the Windows world, than a current,
widely-used one. In addition, it has some technical limitations which preclude
its widespread use in a networked environment in its current form.
Microsoft had previously announced their intention to provide OLE libraries for
OS/2 in mid-1991, but no toolkit has yet been shipped. OS/2 2.0 supports OLE
between Windows applications in the same Multiple application Windows session,
as long as the applications include their own OLE DLLs. An example of such an
application is Microsoft Word for Windows version 2.0, which includes its own
"mini-applications" for functions like charting and drawing, and links to the
main word processing module using OLE. Since there is not yet any equivalent
function in OS/2, OLE will currently work between Windows applications only.
IBM is currently investigating a superset of current Windows OLE function for a
future release of OS/2.
ΓòÉΓòÉΓòÉ 8.3.7. Windows 3.1 ΓòÉΓòÉΓòÉ
In April 1992, Microsoft shipped an updated version of Windows, Windows 3.1. It
offers a number of new functions, and a substantially expanded API set,
including Multimedia and Pen extensions (although the latter functions require
separate add on products). Since OS/2 2.0 had already shipped by the time
Windows 3.1 shipped, IBM has no specific support for Windows 3.1 APIs in the
first release of OS/2 2.0, nor is it certain how important such support is.
IBM's aim is to run Windows applications, not Windows. Windows 3.1 support is
only an issue if it enables new windows applications to be developed which may
not run under the current level of WIN-OS/2. Whether developers will build in
functions requiring Windows 3.1, will depend on how they view the risk of only
targeting part of the Windows installed base (those who have moved up to 3.1).
Microsoft promised compatibility between Windows 3.0 and 3.1, and are offering
developers the opportunity to ship the extra 3.1 function in DLLs along with
the application. If this enables the application to run under Windows 3.0, it
should do for WIN-OS/2, by the same logic. If developers follow this path, the
need for Windows 3.1 support in OS/2 2.0 may not be as urgent as some suggest.
Indeed, there have been very few Windows 3.1-specific applications appearing in
the first few months after the shipment of DOS/Windows 3.1. At one time,
Microsoft had announced that they would make Windows 3.1 capable of being a
DPMI client, and thus run under OS/2 2.0. However, Windows 3.1 does not
possess this capability.
Nevertheless, IBM has the Windows 3.1 source code through the joint licensing
agreement and will continue to monitor the need for additional levels of
Windows support. IBM is fully able to provide such support without help from
anyone else, as it has done so far with the development of OS/2 2.0. On April
6th 1992 Microsoft shipped Windows 3.1. On April 7th, IBM showed the Windows
3.1 Program Manager running in a Seamless window under OS/2 2.0 (not the GA
version). This was not an announcement of Windows 3.1 support, merely an
indication that it could be done. Work is now taking place on updating WIN-OS/2
support (see OS/2 1992 developments ) and is in beta test at the time of
writing. The main part of the work is extensive compatibility testing with
Windows 3.0 applications. The aim is to ensure that the change to Windows 3.1
level of support, does not lead to the kind of compatibility problems that were
reported in PC Week soon after the release of DOS/Windows 3.1, and referenced
in the Windows 3.1 APPS.HLP file. Because of these compatibility problems, and
the withdrawal of support for Windows real mode by Microsoft, it is true to
say, at the time of writing, that OS/2 2.0 runs a wider range of Windows
applications than DOS/Windows 3.1.
ΓòÉΓòÉΓòÉ 8.4. A better Windows? ΓòÉΓòÉΓòÉ
So, in conclusion, the approach taken to running Windows applications under
OS/2 2.0 has a number of benefits:
o Compatibility: gives high compatibility with the widest range of Windows
applications, since the applications are running under the real Windows
code, modified only for compatibility with OS/2.
o Performance: since the applications run under a modified version of Windows
itself, it does not suffer from the performance limitations of a Binary
Compatibility Layer (BCL) approach, such as was previously attempted (and
subsequently abandoned) by Microsoft. Although single tasking scenarios may
be up to 20% slower, multi-tasking performance is comparable to that under
Windows and in many scenarios better, because of the superior multi-tasking
design of OS/2. Indeed, the more the system is loaded, the faster Windows
performance will tend to deteriorate in comparison with the same
configuration under WIN-OS/2. Even the example quoted earlier from NSTL's
independent benchmarking (see Performance ) shows Windows performance less
than WIN-OS/2 even with only one background process.
o Protection: since Windows applications can run in separate VDMs, they are
better protected from each other, so that errant applications cannot bring
down the system. Windows applications themselves are protected from DOS
applications more than is possible under DOS/Windows.
And, as we have already seen, OS/2 2.0 represents a superior environment for
multiple DOS applications (see OS/2 versus Windows as a multi-DOS environment
), since there is more memory, better multi-tasking, and more protection than
under any DOS or DOS extender. Therefore, in being a better multi-DOS
environment, and running Windows applications with full compatibility and
extra protection, OS/2 2.0 is a better Windows environment overall.
ΓòÉΓòÉΓòÉ 8.5. Porting Windows applications to OS/2 ΓòÉΓòÉΓòÉ
Of course, although OS/2 can offer excellent compatibility with Windows
applications, those applications still remain Windows applications, and they
are therefore limited in the extent to which they can integrate with OS/2. For
example, full drag and drop functionality and other exploitation of the
Workplace Shell, is only possible if you write for that environment, and that
means OS/2. OS/2 applications have full access to a 32-bit API, 32-bit memory
management, and multi-threading capability, allowing the same application to be
much more responsive to the user (for example, retrieving a new file while
saving the old one, rather than having to wait with the hourglass showing, as
you might in a 16-bit, single-threaded environment like DOS/Windows.) Minor
issues of look and feel are also different (as is apparent when the application
is run in a window alongside OS/2 applications).
Compatibility with existing Windows applications is important: but it does not
mean that users should not be offered the chance of using better, more powerful
and more responsive applications by using native OS/2 applications. Some have
tried to suggest that having a Windows application is enough, since it will run
under OS/2 anyway, and therefore one version will cover both markets.
Developers who have followed this "lowest common denominator" approach, are now
finding themselves unable to differentiate themselves from the competition, and
indeed at a disadvantage in the OS/2 marketplace.
Increasingly, users who migrate to OS/2 2.0, are demanding "native" OS/2
applications, and vendors who can only offer Windows applications running under
WIN-OS/2 are finding themselves uncompetitive if they do not supply a real
32-bit OS/2 version. WIN-OS/2 may be a "better Windows", but it is not as good
as real 32-bit OS/2 and the Workplace Shell. Therefore, vendors have
considerable incentive to write for OS/2 and not keep only to Windows support.
And over 1000 OS/2 32-bit applications are in development: more than 150
shipped within three months of the release of OS/2 version 2.0. Vendors who
have committed to OS/2, or who already have products available, include Lotus,
Borland, Software Publishing Corp., Novell, Corel Systems, Micrografx,
WordPerfect, DeScribe, ZSoft, Oracle, Gupta and Computer Associates. And IBM is
also delivering a number of applications (in addition to the systems extensions
described in OS/2 in a connected environment ) including Personal AS/2, and
ImagePlus/2.
Writing for OS/2, and in particular using the OS/2 32 bit API, positions the
software developer to take advantage of the developments in the OS/2
environment, including multimedia, distributed computing and the increasing use
of object technology (see Futures ).
However, possibly the most convincing argument for developers now, is the fact
that over one million copies of OS/2 2.0 have been shipped within six months of
its first availability, and OS/2 2.0 looks set to continue its success. The one
million mark is for many commercial developers, a sign of viability for a
platform. Ed Zander, president of SunSoft, Inc., the software subsidiary of Sun
Microsystems, was quoted in PC Week about Microsoft's views on porting its
applications to SunOS: "Microsoft tells every company that walks in there that
it won't do the ports until the architecture has an installed base of 1
million" Microsoft's Bill Gates was quoted by PC Magazine as saying he would
only consider developing for OS/2 when it shipped more than 2 million units.
OS/2 has already passed the one million mark and is heading towards the second.
Whether the report in PC Magazine has any relevance to any future plans
Microsoft may have for OS/2 2.0 applications, is unknown.
Although the Windows and PM APIs are in some respects different, porting tools
like the Developers' Migration Kit (see below) are being developed which aid
the migration of Windows applications to OS/2, to allow them to take advantage
of OS/2 benefits. These are tools at the developer rather than user level: the
Windows applications compatibility solution described above is a user-oriented
solution, to gain maximum compatibility with existing shrink-wrap applications
and derive some inherent OS/2 benefits like true multi-tasking and reliability;
there are also developer tools, which allow applications to be ported from
Windows to OS/2 and add OS/2 functionality in the process. Among such tools are
those being produced by IBM and Micrografx.
ΓòÉΓòÉΓòÉ 8.5.1. IBM/Micrografx porting tools ΓòÉΓòÉΓòÉ
In April 1991, IBM announced a joint development and licensing agreement with
Micrografx, Inc., a leading vendor of Windows and OS/2 applications. Part of
that agreement included IBM's and Micrografx's intention to produce a porting
toolkit to help move Windows applications to OS/2.
The Developers' Migration Kit/2, announced in July 1992, allows developers to
port applications and drivers from Windows to OS/2 with little or no code
changes. There are tools for applications and for device drivers. The
applications porting kit, and the device driver kit are based on the Mirrors
technology from Micrografx. Developers can maintain a common code base between
Windows and OS/2, or OS/2 specific functionality as they port. The latter is
recommended to enable better integration with the Workplace Shell (see
Workplace Shell exploitation ) Drivers ported with the driver tools, such as
the HP Paintjet driver, are already part of the OS/2 2.0 base printer driver
suite.
This will increase the number of OS/2 applications by leveraging the Windows
application base, and make it easier for developers to participate in both
opportunities. This in turn will give the user another option to take advantage
of his existing investment, but also have a wider choice of real OS/2
applications.
The way in which the porting process takes place is similar to a product
previously distributed by Microsoft, the Windows Libraries for OS/2 (WLO). WLO
was derived from Micrografx Mirrors technology, but IBM and Micrografx are now
using a more mature version of the technology in the Developers' Migration
Kit/2. Furthermore, the philosophy of the Developers' Migration Kit is
somewhat different to that of WLO: the latter retained something of the
original BCL approach (see Contrast with previous approaches (BCL) ), allowing
a Windows application to run on OS/2 by emulating Windows on top of OS/2,
providing OS/2 versions of the Windows libraries the application usually links
to. Although the porting process is similar, the Developers' Migration Kit is
designed specifically to produce applications for OS/2 2.0 (not both 16- and
32-bit as was WLO's aim), and has a number of additional tools to help optimise
the port for the OS/2 environment. The result is likely to be better
performing OS/2 2.0 applications than were possible using the WLO approach.
ΓòÉΓòÉΓòÉ 9. Better OS/2 ΓòÉΓòÉΓòÉ
OS/2 1.3 has been widely respected and well received. Nevertheless, as well as
being a better DOS than DOS, and a better Windows than Windows, OS/2 2.0 is
even a better OS/2 than OS/2 1.3. This section will show why.
ΓòÉΓòÉΓòÉ 9.1. Compatibility ΓòÉΓòÉΓòÉ
OS/2 allows applications written for previous releases of OS/2 to work without
modification on version 2.0. The design of OS/2 always took this into account,
and provides binary compatibility not only for the commercial applications
written by ISVs, such as Lotus 1-2-3 for OS/2, but also the "line of business"
applications written in-house by various companies to support their key
business activities. It is estimated by one independent source that as much as
$4 billion of investment has been made in such systems running on OS/2.
Compatibility with these applications is a statement of IBM's intention to
protect that investment while migrating forwards to new and better
environments.
The OS/2 design had to take account of 16-bit applications running in a 32-bit
system, and the system itself provides many services to allow 32-bit modules to
call existing 16-bit modules, thus allowing for mixed 16/32-bit applications.
This means that the mixed model gives great flexibility, both in migrating
applications from 16- to 32-bit, and also in allowing 32-bit applications to
make the best possible use of existing service routines, window classes etc,
developed for previous releases of OS/2. (See Mixed 16-/32-bit environment ).
Furthermore, the consistency of the API between 16- and 32-bit, allows
relatively easy migration to 32-bit. The PM API in particular was designed
with 32-bit in mind, and this makes the 16- to 32-bit conversion relatively
straightforward. Conversion can be done in stages if preferred, the mixed
16:32 model allowing a variety of approaches from recompiling and relinking, to
full rewrite for critical sections, optimising for 32-bit.
ΓòÉΓòÉΓòÉ 9.2. Graphical installation ΓòÉΓòÉΓòÉ
The user's first view of the system, at installation time, is very different
from 1.3. Instead of being entirely text-based, after the first disks,
installation is done in a graphical mode. This is more consistent with the
main user interface, and provides better feedback to the user: a progress
indicator bar shows how far through the installation the user has got, and
pictures of disks appear at the bottom to show how many disks have been used
and how many remain.
The Install program is more intelligent; it can figure out your mouse, display,
keyboard and country setup, and offer defaults for you to choose. For those who
need more detailed control over their system, the selective install which first
appeared in 1.3 is also in 2.0, but as a graphical dialog box with check boxes
to select the options and buttons to indicate how much each item takes up on
disk, as well as a cumulative indication of the total disk space required for
the components chosen. Among the options that can be chosen or left are the
on-line documentation, REXX, fonts, HPFS, and MVDM/DOS support. These options
allow further selection at a more granular level. For example, many people
install DOS support but not Windows support, since they have no Windows
applications. Even individual utilities and applications can be selected or
not; and the size of each component is listed to help you determine whether or
not you want to spare the disk space. This can make a difference, as the Tools
and Games "applets" (see Applets ) take up to 5.7Mb of disk space. But a
listing of the individual utilities and games allows you to see what each item
takes (eg games: JIGSAW 68K, SOLITAIRE 375K; applets: TERMINAL 1501K, PM
CHART 1159K).
Installation program - progress indicator
The user is given an easier and less error-prone way to control some of the
parameters in CONFIG.SYS, by cycling through valid options. Once the product
is installed, further customisation is possible via the OS/2 system folder
(which contains options similar to the OS/2 1.x Control Panel). Options can be
added individually at a later point with the "Selective Install" object in the
"System Setup" folder.
For users wanting to install OS/2 over an existing DOS system, OS/2 install
offers migration of existing DOS, Windows and OS/2 applications. If the
install program detects applications it recognises on the disk, it will offer
the user the option to put them in a folder. This way, the system can come up
with the user's existing applications already available. These applications
are also set up with an optimal collection of DOS and Windows settings. System
Administrators can create their own custom database of applications to migrate
in a similar way (see Migrating applications ).
When installing over a Windows 3.0 or OS/2 1.3 machine, the program groups are
migrated into folders so that the groupings of programs are the same in the new
environment. Device drivers from either DOS or OS/2 CONFIG.SYS files can be
migrated too, as well as printer definitions from either Windows 3.0 or OS/2
1.3.
For new users, the install can give a tutorial on use of the mouse in order to
guide the user through installation.
As well as being simpler and more appealing to look at, installation is faster,
due to an enhanced compression/uncompression algorithm for unpacking files from
the disks. Install can be done from any drive to any drive, allowing OS/2 2.0
to be installed, in future, from CD-ROM, or any other media that can be
accessed as a normal drive letter, including across a LAN if required. In
addition, tools and services are available from IBM to assist the automated
installation of many machines. Remote installation and systems management is a
major area of development for OS/2, but many basic tools and facilities are
here today (see Configuration, Installation, Distribution (CID) ). Most
important of all, is that OS/2 2.0 is already enabled for automated LAN-based
installation. See the publication OS/2 2.0 Technical Compendium, Volume 5:
Remote Installation and Maintenance (GG24-3780-00), for more details.
Such automated installation tools can substantially reduce the amount of time
taken to install OS/2 on a number of machines, since installation can take
place simultaneously on several machines without operator intervention. The
option for automated, LAN-based install, reduces objections to the amount of
time taken to install the operating system. Even in a standalone environment,
installation is straightforward, and though the number of disks required for an
OS/2 installation does mean that a manual install will usually take at least 20
minutes, it is usually one single operation to install the system, with one
reboot in the middle. Many people forget that although Windows comes on less
diskettes, it does require DOS to be installed first, causing a two-stage
installation process, and, for certain requirements, some co-ordination between
the DOS and Windows installations is required (for example, if you want to use
a mouse in a DOS window inside Windows 3.x - see Integration ).
ΓòÉΓòÉΓòÉ 9.2.1. Boot Manager ΓòÉΓòÉΓòÉ
For users who wish to retain more than one operating system on their disk, OS/2
includes a multiple boot facility (Boot Manager). This allows different
operating systems to be placed on separate partitions, in order to select which
partition to boot at power-on or reset time. Since OS/2 can support the vast
majority of DOS, Windows and OS/2 16-bit applications, it is not anticipated
that this will be needed by many people for booting DOS or OS/2 1.3 instead of
2.0, but instead may be used with other systems such as AIX, or as a testing
tool for developers or technical support staff.
It works by allocating a 1MB primary disk partition to a Master Boot Block
(MBB) which contains code that is always executed first at boot time and
handles further access to the hard disk. It displays a menu allowing the user
to select the logical drive from which to start the system. Once this logical
drive is selected, the operating system loader for the appropriate system is
loaded as normal. New versions of FDISK and FDISKPM allow the user to select
the logical drive for use. DOS and OS/2 1.3 have to be installed on a primary
partition on the first hard disk, but OS/2 2.0 can be booted from any partition
on any drive. This gives greater flexibility in planning installation than is
possible using DOS, or Windows, which is dependent on DOS for booting.
ΓòÉΓòÉΓòÉ 9.3. OS/2.0 - the 32-bit system ΓòÉΓòÉΓòÉ
There are a number of obvious benefits to users in working with OS/2 2.0. There
are also many benefits for developers. Developer benefits can also be relevant
to users: anything that helps developers ultimately helps users, since it
becomes easier to write better and more powerful applications, and provide the
opportunity for applications that could not be produced before.
ΓòÉΓòÉΓòÉ 9.3.1. Why 32-bit OS/2? ΓòÉΓòÉΓòÉ
First, it is worth examining why it is significant that OS/2 is a 32-bit
system, and what benefits this can provide.
ΓòÉΓòÉΓòÉ 9.3.1.1. Better performance ΓòÉΓòÉΓòÉ
One of the most obvious benefits of a 32-bit OS/2 program is that it will
almost certainly perform faster than a 16-bit equivalent. An OS/2 32-bit
application can make use of the full 32-bit instruction set and extended
registers of the Intel processor. Some 32-bit compiled programs will also be
smaller in size because of the smaller number of CPU instructions needed to
complete certain tasks. Low level functions such as string manipulation, data
movement and pointer operations will often be twice as fast under 32-bit.
Furthermore, if the application is coded to the flat memory model, there are
none of the overheads of segmented programming, such as the need to reload
segment registers every time a different 64KB of memory needs to be accessed.
This is slow and also an inconvenience and wasted code for the developer.
The system itself provides more efficient paging than both the swapping
mechanism of OS/2 1.3, and the memory paging used in the 16-bit Windows system
(even on a 386). Applications that take advantage of the smaller memory
granularity (memory can be swapped out to disk in 4KB pages) by intelligent
organisation of code and collaboration with the paging mechanism by allocating
memory in page size units, can show a significant performance improvement.
The performance improvements that are possible depend on the changes made: they
range between 5% and up to around 40%. An example of the improvements possible
is in the REXX interpreter, part of the OS/2 base system. Performance has been
dramatically improved since it was changed to run in 32-bit mode, as the graph
below shows:
Comparison of 32- and 16-bit performance - REXX
Even more encouraging is how such benefits can be achieved with relatively
little additional development time. since OS/2 was designed with 32-bit in
mind, migration from 16-bit has been made as straightforward as possible (see
Migration 16- to 32-bit ).
The difference between 16-bit and 32-bit can be significant, especially when it
is comparing Windows and OS/2 capabilities at the same time. DeScribe is a
graphical word processing application which exists for 16-bit OS/2 (OS/2 1.x)
and for 16-bit Windows (Windows 3.x). The company has, in the past,
demonstrated beta test versions of its 32-bit OS/2 release (which shipped soon
after OS/2 2.0's March availability), comparing it with its own 16-bit Windows
version. Comparisons made by Describe, Inc., show that the 32-bit OS/2 version
can be anything between 30 and 300% faster than the 16-bit Windows version, to
complete the same operation. In addition, the OS/2 32-bit version implements
features like multi-threading which cannot be offered in the Windows version
(since Windows 3.x cannot provide multi-threading). This makes it possible,
for example, to save one file and then start loading another while the previous
file is being saved to disk, or looking at one document while another is
repaginating. This results in even higher perceived performance to the user,
because the application is more responsive, and less time is spent looking at
an hourglass icon.
ΓòÉΓòÉΓòÉ 9.3.1.2. More sophisticated applications ΓòÉΓòÉΓòÉ
Applications that may need space and better ability to handle large data
objects (eg DTP, CAD/CAM, financial modelling, multimedia, database) will be
easier to develop in a 32-bit system. Indeed, some may not be possible or
feasible in a 16-bit system. In a segmented environment, programmers have to
develop their own algorithms to use multiple segments to implement a single
logical structure, which is complex and may make it difficult to achieve
performance objectives. This is another issue that may help some applications
move from the Unix environment to OS/2, since they have not been feasible on an
Intel platform till now. Also, OS/2's support for overlapped I/O enables
support for more sophisticated applications, like multimedia, where it allows
better synchronisation between audio and video.
ΓòÉΓòÉΓòÉ 9.3.1.3. Workplace Shell exploitation ΓòÉΓòÉΓòÉ
Windows and DOS applications will load from the Workplace Shell, but not take
full advantage of the drag and drop capabilities and other methods of
participating in the shell. It is possible to provide compatibility, but not
full integration, since Windows applications remain Windows applications (see
Porting Windows applications to OS/2 ).
Some of the examples of what can be achieved by integrating the application
with the Workplace Shell include:
o drag and drop printing, and file loading
o drag and drop installation
o consistency of user interface with the rest of shell - ease of learning
applications
o registration of application objects, so they can appear as templates and
have their own file associations
o interaction with other Workplace Shell objects
o more powerful user navigation: context menus, settings controls, views etc
o on line documentation, including integration with the Master Help Index if
required
o shutdown notification (eg start up with same collection of views and objects
next time - pick up from where you left off)
Although the benefits of Workplace Shell integration do not specifically arise
from the fact that the system is 32-bit, they can only be achieved today by
coding to the OS/2 32-bit API. 16-bit Windows can provide very little of this
function today.
ΓòÉΓòÉΓòÉ 9.3.1.4. Portability ΓòÉΓòÉΓòÉ
Applications written for OS/2 2.0 will be much easier to port to other 32-bit
systems like AIX than applications written for 16-bit systems, as dependencies
on processor specifics (such as the Intel segmented model) are eliminated.
Ports from other environments (Unix etc) will be easier for the same reason.
This will give the user an even wider choice of applications.
Applications written for OS/2 2.0 will also be better prepared for systems as
yet unreleased such as a future portable version of OS/2.
ΓòÉΓòÉΓòÉ 9.3.1.5. Simpler programming model ΓòÉΓòÉΓòÉ
In OS/2 2.0, there is no need to take into account the requirements of the
Intel segmented model, calling for code to be broken down into 64KB segments,
and also no need for segment manipulation when passing control between threads
or calling DLLs, for example, as is currently the case in 16-bit systems like
OS/2 1.3 and Windows. Instead, memory is allocated with a 32-bit pointer that
maps into an address space of 512MB, with no 64KB limit on the size of
individual segments. Memory can therefore be allocated in logical units
dictated by the requirements of the application rather than the constraints of
the segmented memory model. This leads not only to better performance (reduced
segment reloading), but reduced application development time (less code needed
to do the same job, since segment handling code is no longer necessary).
32-bit OS/2 coding is also simpler because there is only one memory model,
instead of the many (small, medium, huge) under the segmented application model
(represented by OS/2 1.3, DOS, Windows).
The result for the user is that powerful and sophisticated applications will
appear quicker, and some will be feasible for the first time, because they are
easier to develop. Also more programming time can be spent on providing better
function or usability rather than managing memory segments, which should also
benefit the user.
ΓòÉΓòÉΓòÉ 9.3.1.6. Exploit hardware investment ΓòÉΓòÉΓòÉ
32-bit programs allow companies to take advantage of the investment in 32-bit
hardware systems that they have been purchasing for several years. Currently,
32-bit hardware is, in most cases, running 16-bit software. 16-bit software
does not take advantage of the features of the hardware that have been
optimised for 32-bit operation. 386 machines have simply been used as "go
faster" 286 or 8086 machines, until a 32-bit system has become available to
take advantage of it. As we have seen, the benefits of 32-bit are not just in
performance, but in broadening the scope of what can be done. Waiting any
longer for 32-bit alternative systems to become available, simply increases the
length of time that the investment is left unexploited.
All in all, 32-bit equals a richer set of applications, which are faster, and
allow more choice and more function for users; in this way, developer benefits
become user benefits.
ΓòÉΓòÉΓòÉ 9.3.2. Migration 16- to 32-bit ΓòÉΓòÉΓòÉ
Best of all, migration from 16- to 32-bit OS/2 applications can often be
accomplished relatively easily. PM was designed with 32-bit use in mind, and
the design of OS/2 2.0 has taken into account the need, not only to run OS/2
1.3 applications unmodified, but also to make it straightforward to change the
16-bit OS/2 application to exploit 32-bit. In some cases, little more than a
few function call changes are required. In many cases, changes will be needed
to change from a segmented 16-bit memory management to the flat memory model of
2.0. How much work is involved here depends on how many dependencies the
existing 16-bit application has on segment manipulation. What certainly can be
said is that movement from 16- to 32-bit OS/2 will be no more difficult than
changes to other 32-bit APIs (such as a future 32-bit Windows API), when they
appear. Windows 3.x is based on an inherently 16-bit segmented model; unlike
OS/2, it did not have the benefit of being designed with 32-bit migration in
mind.
ΓòÉΓòÉΓòÉ 9.3.3. OS/2 - a 32-bit API - TODAY ΓòÉΓòÉΓòÉ
Some arguments against OS/2 rest on claims that OS/2 is not a full 32-bit
system, or that other DOS-based alternatives provide a 32-bit system today.
Such claims are based on misconception. The essence of whether a system is
32-bit or not, does not lie in how its internals are coded, but in the benefits
it offers to users and programmers. In fact, even to developers, the key issue
is not what the system looks like internally, but what kind of programming
interface is offered. And, in this respect, OS/2 already offers a full 32-bit
API, which has been designed to offer the maximum ease of migration from 16-bit
(see above). The OS/2 32-bit API enables developers to escape from the
limitations of 16-bit segmented memory management to a flat memory model, but
also offers multi-threading, advanced graphics support, and powerful
interprocess communicatons. The OS/2 32-bit API is also enabled to accommodate
extensions like multimedia and pen-based computing. It therefore opens up the
future path not only for multimedia and pen, but also portability to RISC, and
for increasing use of object-oriented technology, distributed networking and
other developments.
In contrast, Microsoft offers today only a 16-bit API for Windows 3.x. The only
32-bit function currently available is the sparse set of functions in the
WINMEM32.DLL, which even Microsoft itself warns, requires advanced Windows and
assembly level programming skills. Applications coded in this way may not be
easily portable to other processors, if extensive use is made of Intel assembly
language. Since WINMEM32.DLL is a set of eight 32-bit function calls grafted
on to a 16-bit DOS extender, the 32-bit code cannot make calls to 16-bit
Windows or DOS functions, and therefore the WINMEM32 program has to create its
own interfaces between the 16- and 32-bit code segments, with address and
parameter translation, ie the application must implement its own thunks, and
they must be implemented in assembler. This is in contrast with OS/2 2.0,
which is designed to allow easy mixed model programming, and provides thunk
controls to move between 16- and 32-bit modules. This makes developing 32-bit
applications much easier, and much easier to migrate from 16-bit.
Microsoft has announced that when Windows/NT ships, it will implement a 32 bit
API, referred to as Win32. Publicly available specifications of the Win32 API
show it to be very similar in principle to the OS/2 32-bit API, with few extra
features. But since Windows/NT is not scheduled to ship before the first half
of 1993 at the earliest, Microsoft has announced a subset of the Win32 API,
Win32s, will be available for developers working on Windows 3.1. This is
understood to offer flat memory model programming (although details of the
thunking that will be required are as yet unavailable), but will not offer
advanced features like multi-threading and advanced graphics, which Microsoft
says will not be available until Windows/NT appears. Industry commentators
have pointed out that the result of this is that developers will have to
consider three different Windows APIs:
o Win16 (Windows 3.x)
o Win32s (Windows 3.1)
o Win32 (Windows/NT)
and have to consider how they can design programs across three APIs, which can
meet the stated Microsoft goal of scalability across the various future
Windows offerings.
On the other hand, OS/2 is available today, and the 32-bit API has been
available to developers for several years now, offering all the features
promised across the three separate future Windows offerings, in one single
API. And the target platform has sold over a million units, several months
before any alternative is due to appear.
Internally, OS/2 is a hybrid 16-/32-bit system. The majority of the system
code (including most of the kernel, VDDs and the Workplace Shell) is 32-bit.
Some other parts are obviously 16-bit as they aim to provide compatibility
with older 16-bit software: for example, WIN-OS/2 is a modification of 16-bit
Windows code, and is therefore as 16-bit under OS/2 as it is under DOS! Also,
OS/2 maintains 16-bit code where it has been designed to accommodate 16-bit
modules and DLLs, offering support for mixed 16- and 32-bit code that is not
apparent in Microsoft's stated aims for Windows/NT. Device drivers and parts
of the file system are also still 16-bit. Other 16-bit parts would gain little
benefit from being adapted to 32-bit (such as the command line utilities like
TREE and SORT). In general, OS/2's mixture of 16-bit and 32-bit code is well
suited to the range of today's applications where 16-bit calls predominate. It
remains to be seen how well Windows/NT will be optimised for the 16-bit
applications which will still be the majority (especially as it will not be
able to run any of the OS/2 32-bit applications which will comprise the
majority of 32-bit applications when NT finally ships). As 32-bit applications
grow in popularity, OS/2's mixture will become more 32-bit.
But it must be stressed that the internals of the system are irrelevant to
both users and programmers. Programmers care about a 32-bit API: OS/2 offers
a shipping product with a 32-bit API; Microsoft only currently supplies a beta
version of Windows/NT. Users care about compatibility and performance, and
OS/2 provides both of these within its design. Where 32-bit can offer
potential benefits (eg performance or future portability), the system
components either have been moved to 32-bit or will be over time (for example,
the 32-bit PM graphics engine and screen device drivers, which will be
delivered by the end of 1992 as an update pack). On the other hand, though
Microsoft claims that Windows 3.1 has significant 32-bit code internally
(though only when running in 386 enhanced mode), it does not offer any 32-bit
API nor multi-threading, so the benefits of 32-bit are only partly realised.
One of the key issues in the "32-bit" debate is portability to and from other
processor families such as RISC. But such portability for OS/2 or Windows
requires two things: the operating system kernel and subsystems, and the
applications. If the API is not 32-bit, there is little point in having a
portable kernel, since the applications cannot move without the API. OS/2 has
a mature 32-bit API TODAY, and it has been available for over 4 years (since
the original Microsoft OS/2 2.0 SDK). This API was designed to accommodate the
future directions of OS/2, including portability to RISC, a promise we made
together with Microsoft in 1989. Although Windows 3.1 contains some 32-bit
modules internally in some of its components (eg FastDisk) some of these are
so Intel-specific that moving them to RISC will be difficult, if they are
attempted at all. So once again, the issue of the internals of a system is an
irrelevance, and moreover a distraction from the real issue: the key factor in
a 32-bit design is balancing the aims of portability and performance, but most
of all, ensuring that applications can be delivered to exploit the system via
the 32-bit API. Today, OS/2 delivers such an API, with features that are only
promised for the future by Microsoft.
ΓòÉΓòÉΓòÉ 10. Workplace Shell ΓòÉΓòÉΓòÉ
The new user interface for OS/2 2.0 is one of the more obvious ways in which
the new OS/2 is better than before. But because it is a new interface, some
aspects need some discussion as to why they are new and what benefits they
bring.
ΓòÉΓòÉΓòÉ 10.1. Why another user interface? ΓòÉΓòÉΓòÉ
The new look of OS/2 2.0 sets it apart visually not only from previous versions
of OS/2, but also from other GUI environments on Intel-based PCs, such as
Windows. To some, a new look presents opportunity; for others, who do not like
change, the difference can seem a problem. It is worth examining some of the
reasons why OS/2 2.0 presents a new look and feel, rather than just continuing
with the OS/2 1.x look.
o Move to the future
OS/2 is not only a system that protects past investments in DOS, Windows and
OS/2 1.x, but is also a platform for the future. It aims to provide the kind
of object-based interface that will be the norm in tomorrow's
object-oriented systems, but can deliver this function today, since
386-based platforms have the power to support it. This is the new look
defined in IBM's Common User Access (CUA) 1991 guidelines for the
"workplace" model. But CUA is not just a set of rules - it is based on a
vision of how computers can really become more useful and useable. Ask your
IBM contact about the "CUA Vision" disk-based presentation and video (see
CUA Vision materials ), to see where the workplace model is heading in
future, and what sort of applications can be developed.
o Need to attract new users
The PC marketplace is beginning to slow in growth. Vendors end up selling
more hardware and software to the same people, and IS departments find it
difficult to broaden the base of computer usage. That is because apart from
the pioneers and early adopters, PCs are still too difficult to use for too
many people. Current users would like to do more with their existing
systems, but are constrained by the difficulties of learning so many
different applications, each with their own unique way of working. And the
fact that we are finding neither new uses nor new users for PCs, means that
the return on our investment is limited, and the benefits are not being
fully realised.
o Focus on INFORMATION, not the computer
Too much of today's use of PCs requires the user to know a lot about the way
the computer handles the data. Even GUIs like Windows and OS/2 1.x are
basically a graphical representation of the same old computer-oriented way
of working. Instead of worrying about different and inconsistent "managers"
(File Manager, Program Manager, Desktop Manager), with some handling files,
others programs etc, the user can focus on the information he wants to work
with, and let the system worry about file and programs. You can have icons
representing a report, and have the system associate that with a given
application (such as a word processor) so that clicking on the icon loads
the application. In this way, programs become tools to achieve the real
desired result - working with information.
o 2nd generation GUI
OS/2 2.0's user interface, and the design principles behind it, is the
result of more than five years of analysis, prototyping and testing in IBM's
usability laboratories. The results of the tests indicate that an
information-oriented user interface like the Workplace Shell is more
productive and easier to pick up for first time users. Once the basic
principles are learned, even experienced users of old GUIs like Windows,
find they prefer the Workplace Shell, since more complex tasks can be
accomplished easier and it is more flexible. It is an interface that builds
on the achievements of "first generation" GUIs like OS/2 1.x and Windows,
and moves users on to the "second generation".
OS/2 Workplace Shell
o Harmonise different user interfaces
People who have been using PCs for some time will have acquired knowledge of
many different types of user interface: DOS applications have very few
standards in user interface terms, and even Windows adds another dimension
and another set of standards to learn. The Workplace Shell does not
eliminate these differences (it must retain them for compatibility), but
does offer a user interface layer above the individual differences, to
provide a level of consistency and integration. For example, all
applications, whether DOS, Windows or OS/2, can:
- be launched from icons on a common desktop
- appear in windows which can be sized, moved and hidden
- share data via a consistent set of commands (Mark/Edit/Copy/Paste)
- retrieved from the background, or closed via a common Window List The
migration towards future object-based systems such as those based on the
Taligent venture (see Object-oriented environments ), provides the potential
for convergence of ideas from the Workplace Shell, Motif, and the Apple
Macintosh desktop.
o New, but evolutionary
This progress can be made now without compromising compatibility with the
past. The old ways of working with the PC can be kept alongside new ways:
- the C:\> command prompt can be retained as an icon or even a menu item
from the desktop context menu.
- you can use folders just like Windows 3.x or OS/2 1.x groups, and use the
icons within them just like programs, thus treating the Workplace Shell
like the graphical program loader that Windows is for many users.
This allows the user to take what he knows and apply it immediately, while
learning new skills that will make his work more productive. This mix and
match of new and old knowledge makes evolution towards the 2nd generation
GUI much easier.
The key is to provide compatibility, but not to let the past bar your way to
the future.
ΓòÉΓòÉΓòÉ 10.2. An INFORMATION-oriented user interface ΓòÉΓòÉΓòÉ
The first generation GUIs like Windows and OS/2 1.x have been a good
introduction to the benefits of GUI for many people, but they are also a
constraining factor on the progress of the man-machine interface. This is
because the user interface design relies heavily on computer-oriented concepts
like files, programs and directories. The user interface (UI) model is built
around various "managers": File, Print, Program and Desktop. To navigate
through the system, the user must know about the difference between a file and
a program, about the physical layout and organisation of data on the disk, and
to understand some of the constraints this imposes (for example, you cannot put
files in a program group, only programs, but programs can be loaded from the
File Manager). There were other usability constraints which related more to
the implementation of the user interface, rather than the design itself. In
the Windows 3.0 and OS/2 1.3 File Managers, only one directory tree window
could be opened, even on a system with multiple drives. The Print Manager only
interacted directly with the File Manager via drag and drop, but other
applications either could not, or implemented their own drag and drop protocol.
Development of user interface
Moreover, this style of user interface imposes an application-oriented way of
working, or an "action-object" paradigm: a user wanting to create a report will
load his word processor, then look for the file containing the report. The
ideal for the user would be to encourage an information-oriented way of
working, or one that uses the "object-action" paradigm, as this is the way we
work more naturally when away from the computer. Moreover, it is important not
to forget the computer is an item of information technology. It is the
information that the user wants to work with, that is why he uses the computer
in the first place.
The Workplace Shell does not make the user look for the word processor to
create a report, but rather allows him to click on an icon representing the
report, and automatically load the application (the word processor) associated
with it. This use of the object-action paradigm, and the focus on information,
is why the Workplace Shell is sometimes called an object-oriented user
interface (OOUI). It means that you create a letter by dragging a new copy from
a "template" (see Templates ), and regard the application as a tool to work
with the information, rather than a program which you must "feed" with data.
The new shell is designed to provide a more task-oriented, not process-oriented
way of working, allowing the user to focus on what they want, not how to do it.
The new shell will also reduce the amount of system-specific knowledge needed,
by being more analogous to the manual way of performing tasks (using the
physical desktop analogy).
Notice, however, that the new object-oriented way does not preclude the old
ways of working. If you need the C:\> prompt, it is available; if you want
folders full of program icons, which you click on to load, and then go through
the "File Open" menu to find your data, that can be done too. You can mix and
match the action-object and object-action techniques as you wish. But even with
older DOS programs, some of the benefits of an OOUI (such as clicking on an
icon representing a report, and having the system load the appropriate
application), can be realised very easily without a radical change to working
style. In fact, even if the Workplace Shell is used as a graphical program
loader, there are features in it (such as workareas) which make it a better one
than Windows (see Multi-tasking and the user interface ).
ΓòÉΓòÉΓòÉ 10.3. Workplace Shell components ΓòÉΓòÉΓòÉ
Not only do the design principles of the Workplace Shell differ from the older
GUI models, but it is also visually different, and it includes a number of new
features that did not appear in previous versions of OS/2.
ΓòÉΓòÉΓòÉ 10.3.1. User interface elements ΓòÉΓòÉΓòÉ
In this section we will look at some of the user interface elements that
contribute to the new look and feel.
ΓòÉΓòÉΓòÉ 10.3.1.1. Desktop ΓòÉΓòÉΓòÉ
If you are familiar with OS/2 1.x or Windows 3.x, the first thing you will
notice about OS/2 2.0 is that there is no obvious Desktop Manager, Task List or
Groups. Instead, the screen represents your desktop, and everything on the
desktop is an object - files, devices, programs etc. This means the desktop is
the background of activity, and items can be placed on the desktop or in
folders - in fact, anywhere you want; there is no restriction on where icons
are placed as there is in Windows or OS/2 1.x. This means you can have either a
"tidy" or a "messy" desktop according to the way you work. Although the
desktop is meant to give you a visual association with a familiar idea (your
own desk), the Workplace Shell desktop is not meant to be exactly the same as
your real desktop; it offers a bit more than your real desktop. After all, if
the computer only did the same things as you could do manually, why use a
computer at all?
ΓòÉΓòÉΓòÉ 10.3.1.2. Objects and folders ΓòÉΓòÉΓòÉ
The items on the desktop are objects: files, programs, devices (such as disk
drives, the shredder and printers). Objects reside in folders or on the desktop
(which is actually just the highest level folder). Folders are used instead of
group windows, and are more powerful and flexible. Folders can contain any
object, including other folders (again, just like the physical desktop), and
can group items according to a given project or activity (features like
workareas take this even further - see Multi-tasking and the user interface )
You can also have more than one view of a folder, allowing you to look at the
same information from different perspectives ; a simple example is in the
Drives object, which lists the files by drive and directory; this allows
multiple simultaneous views - Tree, Details, Icon views - of the same
directory.
Each object is visually represented by an icon. You work with objects by
direct manipulation - ie by pointing at it with the mouse (see below). Notice
that sometimes only the terminology is different: what OS/2 2.0 calls a
"Program object", Windows and OS/2 1.x might have called a "Program reference"
or "Program icon".
ΓòÉΓòÉΓòÉ 10.3.1.3. Direct manipulation ΓòÉΓòÉΓòÉ
Direct Manipulation is the act of working with an object by pointing at it with
the mouse, double clicking to load it or open it, or dragging it somewhere
else. Since most older user interface models worked by an action-object
paradigm, experienced computer users are used to a certain level of indirection
in using a computer (ie you go through a menu to invoke a command to work on an
object). But the Workplace Shell allows users to work with objects more
naturally, as they would on a real desktop - directly. So, although experienced
users may be tempted to think of direct manipulation as a gimmick, it is in
fact a much more natural, consistent, and, in most cases, effective way of
working with the system.
A specific example of direct manipulation is drag and drop. This is where one
icon is "picked up" with the mouse and moved somewhere else, often to another
icon or folder. Note that this use implies that objects can be programmed to
understand what it means to have something dropped on them, or for them to be
dropped on something. In fact, there are APIs supplied for programmers to set
the behaviour of their own icons (eg for selection, dragging and dropping).
Use of these APIs allows greater consistency between the shell and
applications, and also greater integration. Developers can now register their
objects (ie applications) with the system and have them used as an integrated
part of the system. This all results in a more powerful and consistent
interface for the user.
Although Windows 3.x offers some direct manipulation facilities and some APIs,
its use in the system is currently limited mainly to the File Manager.
Interaction between different parts of the system is therefore more limited
than in OS/2 2.0, compromising the benefits of consistency.
ΓòÉΓòÉΓòÉ 10.3.1.4. Descriptive names ΓòÉΓòÉΓòÉ
Objects and folders can be given any descriptive name. For example, the user
may have a folder called "Annual Report to the Shareholders", which may contain
an icon called "Shareholder Report Draft 14 dated 6th March". This may be a
document created using a Word Processing program. Another icon may represent a
spreadsheet containing the latest financial results. Notice that icons can
represent data files, and to edit them, the user can simply click on the object
to invoke the application that created that file, and edit it further. Even
though files are physically stored by their old 8.3 file names (at least using
the FAT file system), they can be represented on the desktop or in a folder by
the more descriptive long name. It is easier to see that "Letter to Joe" would
be more meaningful to any user (even the creator of the file!) than
LJB0905.TXT. This feature is implemented at the file system level, so that even
data files relating to old DOS applications can be given long names in this way
- applications do not need to be rewritten.
The use of descriptive names is in keeping with the principle of allowing the
user to focus on the information, not the computer's way of working. In this
way, OS/2 offers more fexibility than Windows, in which the computer-oriented
way of working still shows through in the retention of 8.3 file names, despite
the graphical veneer on the surface.
ΓòÉΓòÉΓòÉ 10.3.1.5. Associations ΓòÉΓòÉΓòÉ
Associations can be created between files and programs, on a file-by-file or
wild card basis. This means that simply by double clicking on a data file, it
can be loaded into the associated application. OS/2 applications can also
create their own file types and associations which are created automatically
when the program is installed (DeScribe and Excel for OS/2 are just two of the
applications that do this already). Associations can also allow a data object
to be dropped on a program icon and have the program loaded with the data file.
Multiple associations can be created per object.
ΓòÉΓòÉΓòÉ 10.3.1.6. Shadows ΓòÉΓòÉΓòÉ
Since object icons can be placed anywhere on the desktop or in folders, this
flexibility encourages different arrangements of programs, data and devices
into "projects". This may mean that the user wishes to place a given object in
more than one folder. Instead of physically copying an object from one folder
to another, which can waste disk space and also cause maintenance problems if
the object is subsequently changed, the Workplace Shell allows the user to set
up a "shadow" of that object. (Apple Macintosh users will be familiar with the
idea which they call an alias.) The shadow is linked to the original object
such that changes in the original are rippled through to the shadows.
Shadows allow different uses of the same object, and allows work to be
organised without regard to the physical location of data (they are
particularly useful for working with data or devices located on a server). In
this respect the combination of folders and shadows is much more powerful than
the use of group folders and specially created directories in Windows or OS/2
1.x.
ΓòÉΓòÉΓòÉ 10.3.1.7. Templates ΓòÉΓòÉΓòÉ
Templates are a means of easily creating new objects. Most objects can be
defined from an existing type, or template. The system provides templates for
the common objects such as data files, program objects, folders, printers and
so on. For example, program objects are created by dragging a program template
from the Templates folder, and entering the information about the program
executable and working directory.
But users and programmers may define their own templates. Programmers can
create new file types (eg a Customer Invoice) and define templates via their
own applications. Users can create templates themselves. For example, a "memo
pad" template can be created, to use to create new memos, each of which may be
automatically associated with a chosen word processor, and would contain a
department logo, and headings for the "To:", "From:" and "Subject" parts of the
memo. Or a chart template could be created, so that each new chart created
inherited the default characteristics: a logo and given fonts and colours.
Since many business processes are repetitive, templates match many users' work
very well. Any kind of information that has the same basic structure in each
instance, and only the specifics beneath the "headings" change, is suitable for
creating templates. Templates provide a consistent way of creating new objects,
whether data, program, folder or device.
ΓòÉΓòÉΓòÉ 10.3.1.8. Pop-Up menus ΓòÉΓòÉΓòÉ
Clicking with Mouse Button 2 on an object's icon, or on an open folder,
displays a menu of options to work on the object. These pop-up menus display
only the actions appropriate to the current state of that object. This reduces
screen clutter and increases ease of use by eliminating redundant or
inapplicable options. This menu can be customised by the user (for example, to
change the application loaded from the "Open" menu, or to add user-defined
commands).
The use of Mouse Button 2 is one example of the UI innovations that has
received some criticism in the computer press, though it is not clear why.
Indeed, it is somewhat ironic that when Borland's Quattro Pro for Windows was
reviewed in beta test, one reviewer praised its' use of Mouse Button 2 as a
"Property Inspector". In fact, the Property Inspector provides very similar
functions for a spreadsheet or graph element (otherwise known as an object!) as
the Workplace Shell's pop-up menus do for object icons. While it is likely that
Borland's UI designers came up with the idea independently, it is strange that
what is a virtue from one vendor can be criticised in another. It is an
illustration of how perception, rather than objective evaluation, is a danger
when considering user interface design. (At least there is now the potential
for some consistency in the use of Mouse Button 2 to work on an individual
object - previously it was not used at all under Windows or OS/2.)
ΓòÉΓòÉΓòÉ 10.3.1.9. Visual Clues ΓòÉΓòÉΓòÉ
It is important, for the user's comfort and satisfaction, that clues are
supplied to aid learning and provide a context for what the user is doing. A
major principle in the Workplace Shell is to provide visual feedback where
possible, to keep the user informed about what is happening. These are often
ignored by the casual reviewer, but they contribute to the usability of the
system. Among the examples of such visual clues are:
o change of mouse pointer between clock icon, normal pointer, I-beam for
editing, according to the context
o half-toned icon during copy of object (as opposed to normal tone for a move
operation)
o a line drawn between a shadow and its original during the shadow operation
o a box drawn round an object which would be the target of a drag-drop
operation
o shading behind the icon of an object that is in use
o "no-entry" sign on an icon when it cannot be dropped on a given object
o highlight of the object or objects (by darker shading) which are currently
selected (and for which the current pop-up menu is valid)
These visual clues are more widespread and more subtle than in less
sophisticated GUIs such as Windows, where it is sometimes difficult to
determine the context of an operation or an object, because of the lack of
visual clues. (Consider, for example, how the new user reacts to an icon in
the Program Manager and another, for the minimised application, at the bottom
of the screen, with no apparent difference between them, yet they behave
differently.)
ΓòÉΓòÉΓòÉ 10.3.1.10. Consistency ΓòÉΓòÉΓòÉ
One of the most important aspects of the Workplace Shell is its consistency.
Not only does it provide a consistent means of loading programs from different
origins (DOS, Windows, OS/2) and make them work together, but it also provides
a standardised interface to different tasks, through the use of drag and drop.
For example, OS/2 allows drag and drop to be used for copying, deleting and
printing a file, where DOS uses three different commands (COPY, ERASE, PRINT),
each with their own set of parameters. As stated before, it also provides a
consistent interface (Mark/Edit/Copy/Paste) to sharing data between
applications, whether DOS, Windows or OS/2 applications. And drag and drop is
applied to many other actions throughout the shell, such as setting colours and
fonts. This consistency is reinforced when using programs that integrate with
the Workplace Shell and use the same manipulation techniques (see Workplace
Shell exploitation ). The consistency of the Workplace Shell (where drag and
drop are pervasive) can be contrasted with the rather superficial use of such
techniques in Windows 3.1. Consistency is not achieved where drag and drop can
only be done from the File Manager, and not throughout the shell.
Consistency means that not only is the environment easier to use, but new
actions are learned quicker, often by experimentation. In fact, the key to
judging a user interface is not how easy it is to do something in an hour or a
day (after all, no user interface is completely intuitive), but what extra can
be achieved after the basics have been learned, and how easy it is to do more.
ΓòÉΓòÉΓòÉ 10.3.1.11. Flexibility ΓòÉΓòÉΓòÉ
The user has complete freedom to set the look and behaviour of the shell.
Colours, fonts and even background images can be set for the desktop, and for
each folder individually. Icons and descriptive text can be set for each
object, and even the behaviour of objects and their windows (such as whether a
window is hidden or minimised to the desktop) and the use of mouse buttons can
be customised, where appropriate on an object-by-object basis. This flexibility
is important, because users rarely agree on what is preferable. The Workplace
Shell reinforces the truth that the PC is a Personal computer.
ΓòÉΓòÉΓòÉ 10.3.2. Controls ΓòÉΓòÉΓòÉ
As well as providing a different way of working, the new look and feel of the
Workplace Shell is established by a number of new user interface controls,
including the following:
Container described above as folders, used to logically group objects on
the desktop. It can provide multiple views of the objects
(icon, text, tree, details).
Notebook an easy way to navigate through a complex dialog. It looks like
the paper notebook you may use at your desk. It supersedes
separate dialog boxes by providing multiple pages, selectable
by tabs. The notebook control is used to allow the user to
tailor the settings of each object.
Slider allows the user to select a quantity from a range of possible
values, by using a control very similar in appearance to that
found on many electronic devices - a "sliding" button.
Container
Slider
Notebook
There are also standard dialogs for open and save file, and font selection.
All of these controls have programming interfaces, so that developers can use
them in their own applications, to allow a common look and feel between
applications and the shell.
ΓòÉΓòÉΓòÉ 10.3.3. Applets ΓòÉΓòÉΓòÉ
OS/2 2.0 also ships with a number of mini-applications and utilities,
("Applets") which give some basic functionality to get started immediately, as
well as acting as a learning aid, particularly for manipulating objects with
the mouse. (They also provide a bit of fun!). These range from productivity
applications like an editor, simple spreadsheet, calendar and card file, to a
charting program and terminal emulator. There is also a utility that allows
the user to search through the disks for files matching a file specification or
even a given item of text. Of course, there are also a number of games
including an OS/2 version of Solitaire that allows you to cheat if the game is
not going in your favour!
Applets are not intended as full function applications, but as a means of
getting productive use of the system even without installing extra software.
However, many of them are powerful enough in their own right to serve the
occasional user of, for example with PM Chart, a charting package, without
needing to invest in more software. They help to make the system appealing to
both the first time and the less experienced user.
ΓòÉΓòÉΓòÉ 10.3.4. Extra facilities ΓòÉΓòÉΓòÉ
There are a number of extra features contained in the shell to help overall
productivity, or improve ease of use:
System Setup This object allows the system to be easily configured
and changed to suit the individual. Not only does it
contain options for installing new features or adding
drivers, and for setting colours and fonts, but also
for modifying some of the default behaviour of the
system (eg whether windows are hidden or minimised to
the desktop; whether clicking on an icon creates a
new instance or retrieves a running instance of a
program; whether to prompt when deleting an object,
and so on).
Drives This object replaces the File Manager from previous
releases. It provides similar function to the OS/2
1.3 File Manager. It has a multi-threaded design to
give good performance even in large directories. It
is no longer restricted by the Multiple Document
Interface (MDI) design of the OS/2 1.3 File Manager
(which is still evident in the Windows 3.1 File
Manager), but instead creates a series of modeless
(**) windows, which can be moved wherever the user
wishes. Drives offers all of the function commonly
used by the File Manager in either Windows 3.x or
OS/2 1.3, with the addition of greater flexibility in
certain operations. For example, in keeping with the
rest of the shell, it offers different simultaneous
views of any drive or directory, either icon view,
tree view, or details view (the latter lists file
size, creation date, and other details). Since the
windows created by the Drives object are just like
any others in the shell, files can be dragged between
the desktop and different directories, and to the
printer or any folder.
Printers The ease with which OS/2 handles printing (with drag
and drop) is one of its strongest features, but
equally impressive is the flexibility of printer
setup and customisation of settings. Different print
objects may be set up, not only to represent each
physical printer, but also to represent a particular
combination of settings: for example, you can set up
the same printer to print portrait Times Roman
(represented by one icon, which you can give a
descriptive name such as "Portrait - for letters")
and create another icon to represent the same printer
running in Landscape mode with a small font for those
wide spreadsheet reports (to which you give another
name). Both these printer objects can be kept on the
desktop or in a given folder, and print output can be
directed to either according to the results required.
Convenience features The shell also includes several features for greater
user convenience. The user can set his own background
("Wallpaper") for the desktop, or any folder, as well
as a keylock security feature (blanks the screen and
locks up the keyboard and mouse after a
user-specified period). The desktop layout
(positions of folders, applications loaded etc), can
be autosaved at shutdown and restored when next
starting the system. The workarea feature (see
Multi-tasking and the user interface ) makes it
possible to do this on a folder by folder basis. This
means that different projects (or even different
users sharing the same PC) can be kept logically
separate. All of these features help make the system
easier and more enjoyable to use.
Tutorial The default action after installation is to start the
tutorial, so that the first time user is taken
through the key elements of using the Workplace
Shell. The tutorial is highly recommended, even for
an experienced user of DOS Windows, or OS/2 1.x, to
familiarise oneself with the differences from the
previous environment. The tutorial can be revisited
at any time; it usually resides in the Information
folder.
Online Help The tutorial is just one of the items of information
that the OS/2 user has available. As well as
context-sensitive help being always available through
the F1 key, there is also a Master Help Index, which
gives a "how to" reference guide to using the system.
The Command Reference from version 1.3 is also
retained, and there is in addition, a glossary of
terms. The ability of the shell to keep multiple
modeless windows open, allows the help text to remain
on screen while an operation is performed, to guide
the user through the process.
Master Help Index
The Master Help Index and Glossary use a variety of
techniques to present information to the user: text
in different colours and fonts, hyperlinks and even
pictures. The Help facility also includes an
indexing and searching system, to help users find the
help they need. All of these facilities are open to
the OS/2 developer as well, using the Information
Presentation Facility (IPF). This allows online help
to be created very simply from text files containing
a tag language. New functions in OS/2 2.0 include
the ability to predefine the help window size and its
position relative to the parent window; multiple help
pages (windows), called viewports; support for
multiple fonts, and easy setup of tables of
information; "tear off" help pages, allowing a user
to retain the help on screen as he follows an
example; and hypergraphics - the ability to click on
a graphic and be linked to text or more graphics.
All of these facilities are available to application
programmers, so that on-line help for applications
can be created to have a consistent look and feel
with the rest of the shell. Some developers are
creating on-line guides for their applications, and
by placing them in the Information folder on the OS/2
desktop, creating an "on-line bookcase".
In fact, the IPF facility can be used even more
widely than just online help for a program; in IBM it
is used as a general information delivery tool, for
online documents and reference guides - sometimes it
can be easier to use the computer to search for
information and then browse or print it, especially
if (as with most reference information) there are a
lot of cross-references.
One of the help items added after feedback from the
OS/2 beta test program was the "Start Here" object.
This was in response to customers who asked that the
shell provide the user with a visual focal point, in
case, looking at a desktop with no open windows and
no menus, he became confused and did not know what to
do next. The Start Here object allows a first time
user (or an occasional user) to find a focal point to
go and retrieve information about common operations.
It is not a replacement for the help system, but an
easy starting point to find out more.
ΓòÉΓòÉΓòÉ 10.3.5. Adobe Type Manager (ATM) ΓòÉΓòÉΓòÉ
One of the most important aspects of a graphical environment is, of course,
that it continue to handle text well, and provide the benefits of different
fonts and typefaces. OS/2 2.0 continues the innovation of OS/2 1.3, in
including the Adobe Type Manager (ATM) as an integrated part of PM. ATM
provides scalable font technology, to display and print high quality type on a
variety of screens and printers (not just PostScript printers, but laser
printers, inkjets and even dot matrix printers). ATM is closely related to
Adobe's PostScript printer language, and both use the same Type 1 font format.
This means that companies with an investment in PostScript on printers or on
other platforms (such as Macintosh, AIX, VAX/VMS and IBM System/370) can be
assured of a compatible use of fonts in OS/2. ATM is a widely used font
standard, with over 12,000 fonts available and over $4 billion invested. It is
under consideration as an ISO standard. Indeed, for SAA systems, Type 1 is the
standard font format, and included in OS/2 2.0 are 13 Type 1 fonts from 4
families (Times Roman, Helvetica, Courier and Symbol) that will be implemented
as "core fonts" across all SAA platforms. Any of the 12,000 fonts available
in Type 1 format can be installed and used with OS/2 applications, via the Font
Palette.
ATM allows OS/2 applications to render fonts in any size on the screen and
printer, retaining the high quality of the typeface. It allows WYSIWYG (What
You See Is What You Get) between screen and printer, which is important not
only for Desktop Publishing, but even for word processing and spreadsheets. ATM
is also available for DOS/Windows 3.x as a separate product, ATM for Windows,
but OS/2 includes this utility at no extra charge in OS/2 2.0, so that users
running Windows applications may take advantage of Type 1 fonts in their OS/2
and in their WIN-OS/2 sessions. However, in OS/2 it is not a separate utility,
but an integral part of the PM system. OS/2 applications can use Type 1 fonts
without any changes to the applications.
Windows 3.0 had no in-built scalable font technology, and ATM for Windows was a
popular product in that environment. However, in Windows 3.1, Microsoft
introduced their own proprietary font technology, TrueType. This is not
available on other platforms, except for Apple System 7, and according to
Microsoft has 600 fonts available (compared to Type 1's 12,000 or more). OS/2
has the ability to include support for other font formats such as TrueType,
through an open font interface which is available to font providers; such
support would usually be provided by the owner of the technology (in this case
Microsoft). This would allow TrueType support to be provided in OS/2 in an
integrated way, like ATM, if Microsoft wishes to expand the platforms on which
TrueType is available. OS/2's aim is to provide open font support, not be tied
to a proprietary font technology.
In summary, the benefits of using ATM and Type 1 in OS/2 include:
o better quality screens and printouts
o WYSIWYG between screen and printer
o improved output even on less expensive printers
o wide choice of fonts
o investment protection in Type 1 fonts and PostScript
o a compatible font technology between OS/2 and WIN-OS/2
o integrated font technology available to OS/2 applications without change
o font portability to other platforms (Macintosh, VAX/VMS, AIX, S/370)
ΓòÉΓòÉΓòÉ 10.3.6. LAN-independent shell ΓòÉΓòÉΓòÉ
As well as being a powerful and easy interface for working with data held
locally, the Workplace Shell has a degree of "LAN-awareness" built in. Although
it does not include requester code in the base system, the Workplace Shell is
able to recognise the presence of network requester software such as the OS/2
LAN Requester for OS/2 LAN Server, or the NetWare requester for OS/2. It
provides an API which other network providers can write to, to integrate more
fully with the Workplace Shell. In this respect, it is not tied to any single
LAN system, but can provide a graphical view of data held on different networks
- it is "LAN-independent".
OS/2 has provided access to multiple LAN systems at the same time (eg NetWare
and OS/2 LAN Server) since OS/2 1.3: not only does it handle the concurrent
protocols required (eg NETBIOS, IPX etc) but now, in OS/2 2.0, can offer a
graphical view of network resources (files, printers etc) consistent with the
rest of the shell. By providing the same constructs for remote as for local
data (folders, icons, printer and file objects), data can be moved between one
folder and another, without the need to know the precise location of the data
or which server software is running. This makes access in multi-vendor
networks much easier.
Among the features it provides are:
o ability to login/logout to network servers through a graphical dialog
- this includes presenting an appropriate login dialog (if necessary)
before a network object can be accessed; this means that, for objects
that have specific login requirements, prompts for login are displayed,
even if the main login is completed.
- an extra item on context menus for network objects is Login or Logout
- provides consistent login (though NOT a single login) between NetWare and
OS/2 LAN Server - the difference between LOGIN (NetWare) and LOGON (OS/2
LAN Server) are minimised
o browse available servers and resources (subject to logon viewing permission)
- A "Network" folder contains an icon for each requester installed (for
example, one for NetWare and one for OS/2 LAN Server); clicking on the
icon provides a view of the servers available
LAN Server Tree view
- shared directories and printers are given similar icons to standalone
objects, but have a mini-network icon to distinguish if necessary, as
shown in the folder below. This folder is from a NetWare server, but it
is impossible to distinguish between NetWare and LAN Server - that's what
is meant by LAN-independent:
Folder with network resources
o resources can be moved onto the desktop, or any folder, for easy and
convenient access
- servers, shared disks, files or printers can be shadowed into any folder
including the desktop (see Shadows )
- this is not just for the current session, but the icons representing the
remote objects will be retained on the desktop at next boot, and the
appropriate login dialog presented when the icon is next used
o seamless access to network folders, files and printers
- remote disk resources can be opened (if appropriate access privilege in
force) to show folders and files (behaves just like the Drives object for
local data). Programs and data can be used and copied or shadowed from
this network disk (without having first to assign the network directory a
drive letter such as X:).
- shared printers are easy to set up (prompts to install matching local
device driver if not already installed, and sets up rest of
configuration)
- printer object can be opened to show queued jobs and job status (just
like local printer), but user can only manipulate (hold, release, cancel)
his own jobs; administrator can manipulate all jobs
- network printer can be the default (no need for local printer to be
defined)
Draggingashadowofanetworkresourcetothedesktop
Drag and drop printing on the network
Disk and printer resources set up for use by an administrator will appear as
drive objects and printer objects, like local resources. Thus, once a user has
logged on, he can see a P: drive and an X: drive, if these have been set up
for him by the LAN administrator. In addition, the user can assign his own
drive letters and logical ports to network objects that he has access rights
to (similar to doing a NET ALIAS command in OS/2 LAN Server).
But the key point of the LAN-independent shell, is that all access is
graphical, through the Workplace Shell. There is no need for the command
prompt or for character-based menus. This helps to bridge the gap between the
LAN and local resources, and provide a more consistent and seamless access to
both.
ΓòÉΓòÉΓòÉ 10.3.7. System Object Model (SOM) ΓòÉΓòÉΓòÉ
One of the most significant elements of the Workplace Shell is something that
users never see - the System Object Model (SOM). SOM is an object model - a way
of defining objects to the system. It is the foundation of the object-oriented
design of the Workplace Shell. In fact, the Workplace Shell itself is built on
SOM: Workplace Shell objects (folders, the shredder, the clock and so on) are
SOM objects. This means that the Workplace Shell is object-oriented, not only
in its user interface, but also in the way it is built. It is built on an
object foundation - quite literally, built with objects.
The fact that the Workplace Shell is built on objects, means that it can take
advantage of the benefits of object-oriented design: it is extendable. Suitably
written programs can add their own user defined objects or evolve them from the
base classes provided with the system. The result can be that the distinction
between application objects and system objects becomes blurred - the
applications blend with the rest of the shell to provide a seamless set of
services to the user. This is the starting point for evolution towards a full
object-oriented environment, where distinctions between applications and the
system cease to exist, and objects can be combined in different ways to
accomplish user tasks.
The way in which such objects are built in OS/2 2.0 is via SOM. SOM tools are
provided with the OS/2 2.0 developers' toolkit. SOM is not a programming
language, but a system for defining and manipulating object class libraries. It
provides a set of APIs and a run-time library to allow object-oriented programs
to be written to interface with the Workplace Shell. In fact, SOM has a wider
scope even than the Workplace Shell objects you see on the desktop. It is a
means of implementing object-oriented constructs, and is designed to be system
and language-independent. This is an important feature, because most
object-oriented development environments today are language specific (eg you
can use either C++, or Smalltalk, but not mix both), and therefore it is
difficult to share or subclass objects or classes from other environments.
Note that you do not need to develop SOM objects to get a high degree of
integration with the Workplace Shell. Many features such as drag and drop are
provided in standard PM APIs.
The significance of SOM, rather, is in providing an object-based layer on
today's generation of operating system. This allows many of the benefits of
object-oriented programming to be realised on a platform that also provides
compatibility with older applications. As such, SOM provides the architectural
foundation today, for OS/2 to move in future towards increasing object-oriented
content. The Taligent joint venture (see Object-oriented environments ) is
another potential source of object technology. As object-oriented development
becomes increasingly important throughout the 90s, OS/2 and SOM will evolve to
meet the need to use such techniques in developing OS/2 applications.
ΓòÉΓòÉΓòÉ 10.4. Moving from a previous GUI ΓòÉΓòÉΓòÉ
The design of the Workplace Shell has been tested for several years in IBM's
usability laboratories, and the beta test of OS/2 2.0 provided more information
on how easy it is to learn and use. In general, people who had little
experience of computers found the Workplace Shell easy to pick up and use, once
the basic principles had been explained. For DOS users who have not been
exposed to GUI before, and for Macintosh users, the transition is not very
difficult either. IBM's tests, and the evidence of the OS/2 2.0 beta test,
showed that the main category of users who encountered difficulties, were those
who had used a previous PC-based GUI, such as Windows 3.x or OS/2 1.x.
During the beta test, as a direct result of customer feedback, some changes
were made to improve the migration for this latter class of user. These
included the ability to predefine the look and feel of the shell to be more
like that of Windows 3.x or OS/2 1.x, and individual features such as the
choice of minimising windows to icons on the desktop, rather than "hiding" the
window, which is the default Workplace Shell behaviour.
In fact, though the default look and feel can appear different on first view,
most items are very familiar to the Windows or OS/2 1.x user once the
connection is made between the old style and the new:
ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 7. Windows 3.x and OS/2 1.3 vs. Workplace Shell Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé WINDOWS 3.X - OS/2 1.3 Γöé OS/2 2.0 WORKPLACE SHELL Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Groups Γöé Folders (offers more function - see Γöé
Γöé Γöé Objects and folders ) Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Desktop Manager/Program Γöé None. Instead, a random "messy desk" Γöé
Γöé Manager Γöé assortment of objects (files, pro- Γöé
Γöé Γöé grams or devices). This can be made Γöé
Γöé Γöé as "messy" or as "tidy" as you wish. Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Icons Γöé Objects. This is an important dis- Γöé
Γöé Γöé tinction. An icon now represents the Γöé
Γöé Γöé object (file, program or device) and Γöé
Γöé Γöé not a running program. The main Γöé
Γöé Γöé consequence of this is in the way Γöé
Γöé Γöé minimised windows are treated Γöé
Γöé Γöé (usually they are hidden, but you Γöé
Γöé Γöé can choose to represent them as Γöé
Γöé Γöé icons on the desktop - this can be Γöé
Γöé Γöé set on a per-object basis) Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Print Manager Γöé Now separate print objects for each Γöé
Γöé Γöé printer (see Extra facilities ) Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé File Manager Γöé Now a "Drives" object for each drive Γöé
Γöé Γöé (see Extra facilities ) Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Control Panel Γöé Separate objects for colour, fonts, Γöé
Γöé Γöé mouse etc. Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Task List Γöé Window List (also accessible via Γöé
Γöé Γöé Ctrl-Esc) Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Menus Γöé Pop-up menus, see Pop-Up menus Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Minimise button Γöé This "hides" the window rather than Γöé
Γöé Γöé places an icon on the desktop, but Γöé
Γöé Γöé the behaviour can be customised to Γöé
Γöé Γöé iconise the window if required. Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Adding Programs Γöé Use Templates, see Templates Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Mouse usage Γöé Two button mouse usage. In general, Γöé
Γöé Γöé button 1 selects and button 2 drags. Γöé
Γöé Γöé Use the Tutorial to learn more about Γöé
Γöé Γöé the mouse. Mouse button behaviour Γöé
Γöé Γöé can be changed to suit the user Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
But in nearly every case, not only does the Workplace Shell equivalent provide
the Windows function, but it also offers more flexibility. For example,
folders offer far more function than the simple group windows in OS/2 1.x or
Windows 3.x (see Objects and folders for more information):
o allows data files, programs and devices to be grouped together
o allows long descriptive names
o colours, fonts and icons can be easily changed on a per-folder basis
o the workarea property can be set to enable groups of applications to be
opened and closed together
Furthermore, much of the new function provides a powerful incentive to learn
because of the many benefits, for example:
Templates A consistent way of creating new objects, whether
programs, data files or folders. In Windows 3.x these
would take a different procedure for each item. (See
Templates )
Hiding windows Although this behaviour takes some getting used to for the
Windows or OS/2 1.x user, the experience of the beta test
program suggests that most people never wish to go back to
the old way, in which the desktop is cluttered with
minimised icons. Hiding reduces clutter from the screen,
and the Window list (see below) is a much more effective
and consistent way of retrieving open windows. Tests show
that minimising a running program to an icon is confusing
for users who have not used a computer before, as there
are often two copies of the icon, one to represent the
program reference, and the other the running program, and
the user does not know how to differentiate between them.
Window List This is a more powerful tool than the Task List, as groups
of applications can be resurfaced, closed or tiled in one
step (see Multi-tasking and the user interface )
Mouse Buttons Since Mouse Button 2 is unused in Windows, there is no
comparison, except that there is a happy coincidence of
use between IBM and Borland in their use of the Mouse
Button 2 to produce a pop-up menu on a given object (see
Pop-Up menus )
Flexible Desktop Objects and windows can be placed where the user wishes,
and the action of the desktop is modeless - there is no
need to close certain windows before others can be opened.
There are therefore no artificial restrictions in the
user's movement around the desktop.
But, even if the new function does not attract, it is not necessary to learn
all of the new ways at once. OS/2 provides all the old function too: there
is an object for the DOS or OS/2 command prompt, for those users addicted to
the C:\> prompt; and Windows users can select a WIN-OS/2 Full Screen session
if the familiarity of the Windows environment is required (see Full Screen or
Seamless ).
But the most important difference from Windows is the Workplace Shell's
flexibility: you can put icons where you choose, not where the Program Manager
or File Manager allow you; you can change the look or behaviour of almost any
aspect of the system if the default does not suit you; and you can use drag
and drop across most of the system, not just the File Manager.
ΓòÉΓòÉΓòÉ 10.5. Benefits of the Workplace Shell ΓòÉΓòÉΓòÉ
But all of the function and power of the Workplace Shell would be useless
unless it provided tangible benefits over other GUIs. This section lists some
of the advantages.
ΓòÉΓòÉΓòÉ 10.5.1. Easy to learn ΓòÉΓòÉΓòÉ
No system is totally intuitive, but the Workplace Shell offers a number of aids
to quick and effective learning. The tutorial gives most of the basic elements,
and can be revisited at any time. There are productivity applications and games
to get productive quickly, and have fun while learning. And the online help
system is comprehensive as a reference, or as immediate help when required. The
"Start Here" icon gives a focal point if you ever get completely lost!
ΓòÉΓòÉΓòÉ 10.5.2. Flexible ΓòÉΓòÉΓòÉ
Almost anything can be changed if the default does not suit. You can change
colours, fonts and background images, not just for the system as a whole, but
for each folder. The behaviour of mouse and keyboard, of how windows work, and
most other system defaults are all configurable. And the workarea principle can
make each project have a different combination of icons and folders, to suit
the job you are doing.
ΓòÉΓòÉΓòÉ 10.5.3. Personal ΓòÉΓòÉΓòÉ
The Workplace Shell returns to the principle that the PC is a Personal
computer. Its' motto could be "have it your way". A secretary's desktop can
look different from a manager's desktop, and each different from an engineer's.
You can have as many or as few icons as you wish. You can change the look and
feel to behave more like OS/2 1.x or Windows 1.x.
ΓòÉΓòÉΓòÉ 10.5.4. Simple ΓòÉΓòÉΓòÉ
Though the Workplace Shell is a powerful environment, it does not overwhelm the
user. You can start by using what you know and are familiar with (including the
C:\> prompt if you wish!), and move on to learn new function as you need it.
Much of the new function and tasks can be learned by experimentation, as the
consistency of the shell, and the visual feedback (eg "no-entry" signs where
icons cannot be dropped) allows users to teach themselves.
ΓòÉΓòÉΓòÉ 10.5.5. Compatible ΓòÉΓòÉΓòÉ
The Workplace Shell offers the old ways of working like the DOS prompt and the
Windows Full Screen. It takes nothing away. But it also provides a standard way
of running applications without compromising any compatibility. It does not
enforce a way of working with older applications that is foreign to the user.
You can either close applications in the consistent OS/2 way by double clicking
on the system icon, or use the application commands (such as / Quit for Lotus
1-2-3).
ΓòÉΓòÉΓòÉ 10.5.6. Consistent ΓòÉΓòÉΓòÉ
The Workplace Shell provides the same way of working whether your resources are
local or on the LAN. It allows you to use techniques like drag and drop
consistently across the system, where you would need three different commands
in DOS, and would be restricted to doing things from the File Manager only in
Windows.
ΓòÉΓòÉΓòÉ 10.5.7. Information-oriented ΓòÉΓòÉΓòÉ
The Workplace Shell allows users to work in a more natural way, by focusing on
the information they need to work with. There is less need to worry about the
computer's housekeeping, like files and directories. All in all, you work the
way you want to work, not the way the computer forces you.
ΓòÉΓòÉΓòÉ 10.5.8. Integrating ΓòÉΓòÉΓòÉ
Applications are loaded in the same way, data objects are treated in the same
way, whether they come from a DOS, Windows or OS/2 program. The Workplace Shell
integrates local and remote resources. The whole purpose is to present as
seamless an interface as possible to the variety of tools, application and data
that users need to do their job. in this respect, it is a unifying interface,
and reinforces the key aim of OS/2 2.0 as the integrating platform.
ΓòÉΓòÉΓòÉ 11. OS/2 in a connected environment ΓòÉΓòÉΓòÉ
OS/2 is the critical component in IBM's vision of the complete, managed,
client-server system. It is the key element which allows the PC to become the
focal point of information processing. Instead of in the past, where key data
processing was performed at a remote host, and information provided to users
from the central system, the OS/2 vision moves the PC to the centre, and places
the user in control of the information. This vision lies at the heart not only
of IBM's user interface design (see Workplace Shell ), but also of its strategy
to make OS/2 the base for an integrated family of networking extensions, that
allows OS/2 to be a completely network-aware system. This makes OS/2 the
Integrating Platform, not only for local productivity applications, but for the
other components of the enterprise system. It is no longer realistic to view
the PC in isolation from the rest of the corporate network.
The OS/2 family of networking extensions
The systems extensions to OS/2 complete the picture of the full function OS/2,
designed to address the needs of the PC platform of the 90s, as discussed in
the section The changing PC environment . They add to the wide application
choice, ease of use, investment protection and reliability of the base system,
by providing extensive connectivity, management tools and exploitation of the
existing corporate network. This section expands on the strengths of OS/2 2.0
as an easy-to-use productivity platform, and shows how, as a base platform, and
with its extensions, OS/2 is enabled to act as the "super client" of today, and
the future.
ΓòÉΓòÉΓòÉ 11.1. OS/2 for client-server ΓòÉΓòÉΓòÉ
OS/2 is not only today's server platform of choice (acknowledged by both IBM
and Microsoft), but the best available client. These are some of the reasons
why:
o Consistent Platform for both Client AND Server: It is clear that if the
same platform can be used for both the client and the server, then the
benefits of consistency will lead to a much more manageable platform, with
only one operating system to support. OS/2 is the only operating system
available that is consistent across client and server.
o Multiple Concurrent Network Protocols: OS/2's great strength in
communications is acknowledged across the industry. In particular, OS/2's
multi-tasking design allows it to handle multiple communications protocols
(eg NETBIOS, 3270, IPX, TCP/IP) with ease. This ease of integration is in
contrast with the problems of attempting such concurrency under DOS or
Windows, such as lack of memory, poor multi-tasking performance and the
instability of DOS-based multi-tasking. In a world where heterogeneous or
mixed-vendor connectivity is becoming the norm (a recent report estimated
that 70% of LANs run more than one protocol), OS/2 is today's only reliable
client choice. At the Networld trade show in early 1992, IBM demonstrated a
single OS/2 client machine with one Token Ring card, connected to a "wall of
servers", which included three LAN servers, one running NetWare, another
Banyan Vines, and another OS/2 LAN Server; a RISC System/6000 running AIX,
an AS/400 and an ES/9000. One client was connected simultaneously to all
these shared resources - it was, of course, an OS/2 2.0 client.
o Enabled for LAN-based install: OS/2 can be installed from a server to
multiple clients, allowing faster and more controlled installation, with the
added benefits of greater automation. Future tools will be available from
IBM to ease the system administrator's job still further (see Graphical
installation for more information on installation).
o LAN-independent shell: OS/2's Workplace Shell provides a graphical view of
resources, whether on the local machine or on the LAN. Remote drives can be
set on the LAN from products including NetWare, OS/2 LAN Server, Banyan
VINES, or TCP/IP for OS/2, and also on host systems using Virtual Disk
facilities in products like PC Support/400 and Workstation LAN File
Services/VM. The Workplace Shell gives seamless access to different server
environments, making multiple connectivity easier to implement, and provides
consistent access to network files and printers (see LAN-independent shell )
o Easier to Manage: OS/2 provides the ability to allow administrative tasks
(such as collection of local configuration data and performance measurement)
to be run on the client while preventing excessive impact on local
performance and usability. Such tasks are becoming increasingly important in
a highly distributed PC client-server environment, and particularly where
PCs are being rolled out into mission-critical usage in remote locations
where on-site support cannot be provided. Remote diagnosis and support is
therefore critical in such environments. But background monitoring and data
collection cannot be achieved easily on a single-tasking platform like DOS.
And the limitations of environments like Windows, that attempt to graft a
multi-tasking layer on top of single-tasking DOS, are revealed when such
systems management functions are attempted. Even if such tasks could be run
in the background on Windows (not always the case), the lack of true
multi-tasking would cause the background "probe" to be intrusive to the
user's foreground activity. Only a pre-emptive multi-tasking environment
like OS/2 can offer these benefits.
o Supports both productivity and line-of-business applications: Today's
client-server environments are moving beyond the simple file and print
sharing of the first LANs, towards applications like Lotus Notes, and SQL
database applications, that can deliver competitive edge through enabling
workgroup communication. In this environment, it is important to deliver
not only the support for in-house "line-of-business" applications, but
leverage the investment in client productivity applications. OS/2 2.0 is
the only platform that delivers industrial strength reliability AND wide
application compatibility.
o Reliability: This is perhaps the most critical issue of all. Many of the
reported problems with Windows 3.0 occurred in networking environments. It
is clear that although Windows 3.1 may have improved reliability in some
areas, it has not changed any of the architectural deficiencies that cause
its limitations in networking; most of the problems stem from the fact that
Windows continues to run on DOS (see Reliability and protection and
Reliability ). The issue can be summed up thus: what use is it having a
fault-tolerant server if you cannot rely on your client?
Forrester Research's May 1992 report on the growth of the "super client" (see
The changing PC environment ) identifies OS/2 2.0 as being a leading candidate
to satisfy the demand for a highly protected, network-aware, true
multi-tasking client platform, for use in "line-of-business" applications.
According to Forrester, the "super client" role is beyond the scope of either
Windows 3.1 or Windows/NT, and predicts for the latter "product delays...and
bloated hardware requirements". That independent analysts should make such
statements is not surprising, given the difference in protection between OS/2
2.0 and Windows 3.1, and the difference in hardware requirements and
availability of OS/2 2.0 and Windows/NT. OS/2 2.0 is the platform that meets
the exacting requirements of the modern client platform (see The changing PC
environment ) in an acceptable configuration, and is available today, not
promised for the future.
ΓòÉΓòÉΓòÉ 11.2. The OS/2 family of networking extensions ΓòÉΓòÉΓòÉ
OS/2 2.0 is part of a family of products and systems extensions, which are
designed to work together. In other environments, customers have to buy third
party software (if it is available) and hope it will all work together; with
IBM these extensions are tested together and integrated. Here are some of the
systems extensions from IBM which complement the OS/2 base system:
ΓòÉΓòÉΓòÉ 11.2.1. Extended Services for OS/2 ΓòÉΓòÉΓòÉ
Extended Services for OS/2 is a separate product which provides communications
and database functions. It includes Communications Manager, which offers a
wide range of connectivity and protocols (all of which can be active at the
same time ); and also provides Database Manager, a powerful client-server SQL
relational database, part of the SAA family of relational databases that
includes DB2 and SQL/DS. Extended Services for OS/2 release 1.0 works with
both the OS/2 Version 1.3.1 16-bit base and OS/2 Version 2.0 32-bit base. This
will be an advantage in mixed 286 and 386 environments. Extended Services is
supported on a selected range of IBM-compatible PCs, not just PS/2s.
In keeping with the intention to offer modular options to customers, Extended
Services comes in two forms, which differ only in their database function:
Extended Services for OS/2 delivers Communications Manager and Database Manager
in a single package, providing an "all-in-one" complete connectivity solution;
Extended Services with Database Server for OS/2 adds the ability to create
databases on a server, and offers cost-effective client functions for DOS,
Windows and OS/2 clients.
Extended Services is a key component for OS/2's participation in the SAA
standards, particularly for communications protocols (APPC, CPI-C, and APPN)
and relational database (SQL, DRDA). It is one of the key building blocks for
the SAA co-operative processing applications of the future, both by third party
applications vendors and by customers themselves.
ΓòÉΓòÉΓòÉ 11.2.2. DDCS/2 ΓòÉΓòÉΓòÉ
SAA Distributed Database Connection Services/2 (DDCS/2) is a complement to
Extended Services. It offers host database connectivity to an OS/2 client and,
working with Database Manager, allows DOS, Windows and OS/2 clients to access
host databases conforming to the Distributed Relational Database Architecture
(DRDA), which includes not only IBM's DB2, SQL/DS and OS/400, but potentially
third party database products too. DDCS/2 widens the scope of the OS/2 client,
and is part of the wider SAA distributed database direction.
ΓòÉΓòÉΓòÉ 11.2.3. OS/2 LAN Server ΓòÉΓòÉΓòÉ
OS/2 LAN Server version 2.0 is a powerful platform for providing LAN services
to DOS, Windows and OS/2 clients.
Entry and Advanced levels are available. Entry provides an economical base
system for both the 16-bit and 32-bit bases while Advanced adds features like a
high performance 386 file system (HPFS386) and additional error recovery, on
the 16-bit base. OS/2 LAN Server 3.0, which at the time of writing had entered
beta test, will offer, among other new features, the ability to run Advanced
level function like HPFS386 on the OS/2 32-bit base. Other new features in LAN
Server 3.0 include:
o high level of NetWare and OS/2 LAN Requester client co-existence, on the
client desktop, and when integrating NetWare resources into an OS/2 LAN
Server domain as externally defined resources
o peer Services, which allows a OS/2 requester to share resources with one
peer
o redirected Install, delivering unattended install within the CID process
o 802.2 Virtual Device Driver (VDD), enables DOS 802.2 applications to share
an adapter with other DOS and OS/2 applications (this function is also
included in NTS/2 - see IBM Network Transport Services/2 )
o OS/2 TCP/IP coexistence via support of NETBIOS over TCP/IP, allowing support
of a greater range of protocols
o improved disk fault tolerance, mirroring without the need for rebooting the
server, and mirroring of the boot drive
o support for Apple Macintosh clients via an add-on product
Like Extended Services, OS/2 LAN Server is supported on a range of selected
IBM-compatible equipment as well as PS/2s.
OS/2 LAN Server is a robust, scalable solution, from the small LAN, to the
large and complex. It makes life easy for the user, the LAN administrator, and
the systems manager:
o for the user - a single view of all resources available, and automatic
allocation of resources. Combined with the Workplace Shell, this becomes
even easier.
o for the administrator - the Domain feature makes management of large LANs
much easier, and allows location-independent resource naming, making changes
easier to implement.
o for the systems manager - performance and management tools, including
integration with the SAA host-based NetView.
OS/2 LAN Server provides excellent performance. In tests run by LANQuest Labs,
an independent benchmarking company (report dated June 1992), OS/2 LAN Server
Version 2.0 had the best overall performance compared to Novell NetWare 3.11
and Microsoft LAN Manager.
In the future, IBM plans to enhance OS/2 LAN Server towards full distributed
function for the LAN environment, including common distributed services,
common developer infrastructure, and open industry standards.
ΓòÉΓòÉΓòÉ 11.2.3.1. OS/2 LAN Server and Microsoft LAN Manager ΓòÉΓòÉΓòÉ
In 1989, IBM and Microsoft made a commitment to work towards greater
commonality between Microsoft LAN Manager and OS/2 LAN Server. The original
scope of work has now been completed, and commonality has been achieved at the
API and functional level. This means that applications can be written to run
on both platforms. OS/2 LAN Server clients and Microsoft's LAN Manager clients
can coexist and interoperate on the same LAN. Both clients can logon and
access resources at either or both servers. OS/2 LAN Server and LAN Manager
utilise a common underlying security system as well, which includes common user
domains, access control and server local security. OS/2 LAN Server's support
for selected non-IBM equipment means that customers can now buy LAN Server on
both IBM and OEM machines, and also achieve consistency that way.
Microsoft has not, at the time of writing, committed support in Microsoft LAN
Manager for OS/2 2.0, either as a server or as a client, although they have
access to the OS/2 2.0 code. Nevertheless, customers using LAN Manager 2.0 may
obtain OS/2 2.0 client access to the server, using IBM LAN Enabler version 2.0
(see LAN Enabler ).
Although the current release of OS/2 LAN Server contains code licenced from
Microsoft, future OS/2 LAN Server plans (see above) have no dependency on
Microsoft, whose declared future plans for LAN Manager place little emphasis on
OS/2.
ΓòÉΓòÉΓòÉ 11.2.4. NetWare from IBM ΓòÉΓòÉΓòÉ
IBM, as an open vendor, provides its customers with the two major options for
server software: OS/2 LAN Server and NetWare from IBM. OS/2 LAN Server is an
excellent platform in an environment requiring IBM host connectivity today, and
complements the use of Extended Services, but many customers have NetWare-based
LANs, for application, historical and functional reasons. They therefore
require co-existence and interoperability between the two standards. NetWare
expands IBM's ability to offer better solutions in a mixed networking
environment, where support of diverse clients (Unix, Macintosh) are required in
addition to DOS, Windows and OS/2.
OS/2 2.0 is an excellent client for NetWare. OS/2 1.3 plus the OS/2 NetWare
Requester offered access to services on the various NetWare platforms. For
OS/2 2.0, the NetWare Workstation Kit for OS/2 Version 2.0 includes the
requester code and utilities required for a fully functional NetWare client. A
separate product, NetWare Services for OS/2, adds to the requester code, a MAP
utility for network management.
IBM offers co-existence between LAN Server and NetWare. With the OS/2 LAN
Requester and the NetWare OS/2 requester installed, the same OS/2 workstation
can log on to both types of server. This allows customers to use both products
according to immediate requirements and installed base. Greater
interoperability is planned. One key element in achieving this is the
commitment by Novell to move NetWare to the 32-bit OS/2 base. This will
combine the strengths of NetWare with the power of 32-bit OS/2 as a server
platform. Novell's plans amount to a key endorsement of OS/2 as both a server
and client platform. IBM will continue to offer interoperability with NetWare
systems as we incorporate more distributed services into the OS/2 LAN Server.
ΓòÉΓòÉΓòÉ 11.2.5. LAN Enabler ΓòÉΓòÉΓòÉ
IBM LAN Enabler version 2.0 offers the OS/2 requester, LAN Support Program and
DOS LAN Requester (DLR), identical in function to that provided with OS/2 LAN
Server 2.0, in a separate product. The package includes requesters for DOS,
Windows, OS/2 1.3 and OS/2 2.0, as well as protocol support, NDIS-compliant
network adapter drivers, LAN API support, and a VDD for NETBIOS applications.
This product will allow 286 and 386 PCs to connect to servers including OS/2
LAN Server 2.0 and Microsoft LAN Manager 2.0, and other compatible servers,
without having to buy a separate copy of LAN Server, or Extended Services for
OS/2. It also allows OS/2 2.0 client access to NETBIOS, 802.2 and NDIS
applications without buying LAN Server or Extended Services.
This enhances the function of OS/2 2.0 as a client to different networks by
providing the necessary function in a package separate from the server, at an
economical price.
ΓòÉΓòÉΓòÉ 11.2.6. IBM Network Transport Services/2 ΓòÉΓòÉΓòÉ
IBM Network Transport Services/2 (NTS/2) provides networking support on an OS/2
2.0 base, without requiring OS/2 LAN Server or Extended Services for OS/2. It
provides the LAN adapter and protocol support (LAPS) to support networking
applications on an OS/2 2.0 machine, and to enable automated installation of
OS/2 and other CID (**) -enabled software across a LAN.
NTS/2 is a combination of:
1. Network Driver Interface Specification (NDIS) compliant transport protocol
and network adapter software
2. OS/2 2.0 support for DOS programs requiring NETBIOS and IEEE 802.2 APIs,
by providing a VDD/PDD combination for NETBIOS and 802.2. This allows DOS
applications using a Token Ring adapter, to share that adapter with other
DOS and OS/2 applications running on the same machine. For example, this
allows DOS and Windows 3270 emulation programs using Token Ring to share
the adapter with OS/2 LAN Requester.
3. Configuration Installation Distribution (CID) enabling software, including
a LAN CID utility (LCU) to manage the automated installation process.
Note that the LAPS function was also released earlier in the LAN Enabler/2
v2.0 product. NTS/2 adds to LAN Enabler/2, the CID support to allow automated
installation of OS/2 in a LAN environment. In this respect, NTS/2 is more akin
to the DOS-based LAN Support Program, with the addition of CID support (ie it
provides the network transports and APIs to enable LAN support), whereas LAN
Enabler/2 can be thought of as related to the OS/2 LAN Requester (since it
provides command line and menu interfaces to manage LAN-based resources).
ΓòÉΓòÉΓòÉ 11.2.7. Open systems connectivity ΓòÉΓòÉΓòÉ
Although OS/2 is the SAA client platform, it is also vital that it embraces the
open systems world. IBM's strategy is to enable OS/2 and AIX in particular, to
interoperate as much as possible. TCP/IP for OS/2 is one product that provides
significant networking co-existence with UNIX-based systems, providing support
for many open standards such as TCP/IP, NFS, TELNET and X-Windows. This allows
OS/2 to extend its client capability into the open systems arena. IBM's
strategy is to link the OS/2 and open systems worlds closer together through
common systems extensions, connectivity and management tools (see AIX
interoperability )
The combination of the OS/2 2.0 base, and TCP/IP for OS/2, means that the OS/2
2.0 user can today view, on the same screen, DOS, Windows, and OS/2
applications as well as Unix applications through X terminal or TELNET. This
widens still further the range of application support OS/2 2.0 can provide.
ΓòÉΓòÉΓòÉ 11.3. Systems management ΓòÉΓòÉΓòÉ
Connecting PCs together is only one part of the process of integrating the PC
into the enterprise system. The more PCs are installed in a company, the
harder it is to control their installation, maintenance, problem solving and
performance tuning. IBM has proven strength in handling complex, distributed
networks, and therefore understands the importance of providing tools to help
manage these tasks. To date, systems management for OS/2 has been provided by
two means:
o by functions integrated directly into OS/2 and extensions like Extended
Services (such as the First Failure Support Technology - FFST/2)
o by separate standalone products which address a specific and distinct aspect
of the overall task of managing OS/2 systems
In the latter category, IBM has already produced a variety of products, based
on OS/2, to assist various aspects of systems management. The table below
lists a few of them:
ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 8. OS/2 systems management tools Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé SPM/2 Γöé System Performance Monitor/2 (SPM/2) tracks key Γöé
Γöé Γöé aspects of a system's use: CPU, disk etc, to Γöé
Γöé Γöé identify performance problems. This can be used Γöé
Γöé Γöé in both server and client environments. Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé NetView Γöé an installation management tool, working in con- Γöé
Γöé Distrib- Γöé junction with the host-based NetView, that Γöé
Γöé ution Γöé includes a LAN Download Utility to install or Γöé
Γöé Manager/2 Γöé upgrade software via a LAN server to Γöé
Γöé Γöé LAN-connected PCs. Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé SAA Γöé allows host-connected OS/2 machines to receive Γöé
Γöé Delivery Γöé software updates from the host Γöé
Γöé Manager Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DCAF Γöé Distributed Console Access Facility (DCAF) Γöé
Γöé Γöé allows remote diagnosis and management, by Γöé
Γöé Γöé receiving screens from and controlling the key- Γöé
Γöé Γöé board of a remote OS/2 machine. Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
IBM is continuing to expand on this range of management tools, and to
integrate them more closely. IBM's long term goal is the provision of an
architected management platform which adheres to indistry standards from
organisations such as ISO, X/Open and OSF.
IBM's strategy for systems management is based on the belief that in
establishing the true cost of a PC system, the initial hardware and software
cost is only a small proportion. The extra costs, what many independent
analysys call "cost of ownership", relate to issues like integration, support
and systems management; or, as it was stated in The changing PC environment ,
the costs of maintaining the systems should not exceed the benefits it
provides. With the growth in the size and complexity of LANs and
client/server systems, planning and managing these systems has become
increasingly difficult, time-consuming and expensive. In a report in April
1992, Gartner Group said that "Costs surrounding product updates represent the
largest component of PC software life-cycle costs". Customers are therefore
investing a growing amount of resources into distributed systems management
(DSM) and are demanding that they be simplified and automated.
On October 6th, 1992, IBM responded to customer demands for solutions to DSM
problems with 2 major announcements:
o the IBM LAN NetView family of DSM products
o a generalized solution for configuration, installation, and distribution
(CID) of OS/2, its subsystems, and application software.
ΓòÉΓòÉΓòÉ 11.3.1. IBM LAN NetView family ΓòÉΓòÉΓòÉ
The IBM LAN NetView family of products is an OS/2-based platform for performing
DSM functions in enterprise-wide, multivendor local area networks (LANs). The
LAN NetView platform provides the ability to monitor and control information
processing resources, including hardware and software, throughout an
enterprise. Information is collected from monitored resources (managed
systems) and sent to other resources (managing systems). The offerings allow
the management of OS/2 2.0, DOS 5.0, and DOS 5.0 with Windows 3.1 clients.
The new platform allows the LAN administrator at a workstation to access
different systems management applications using the same screen. It provides
enhanced automation and greater integration among products to streamline such
management tasks as detecting hardware or software failures on the network -
which often require the combined efforts of users and trained personnel at both
remote and central locations.
The set of LAN NetView distributed system management applications being
developed by IBM include:
o LAN NetView Manage, the platform product that provides system services for
LAN NetView management applications.
o LAN NetView Start, LAN NetView Monitor and LAN NetView Fix, three management
applications designed to run on that platform. They provide, respectively,
configuration, systems performance and fault-management services.
o LAN NetView Tie, which provides a LAN-to-NetView link for customers who
prefer to divide management of system resources between LAN- and host-based
products, or who prefer to centralize all management on the host processor.
IBM is encouraging vendors to provide agents for their system resources to
allow LAN NetView products to manage them, and is encouraging vendors to
provide additional system management applications on this platform. Among the
vendors who have declared their support are Novell, Microcom, Computer
Associates and Ungermann-Bass. Customers may also choose to implement their
own LAN NetView compliant distributed system management applications.
To encourage the development of third-party systems management applications,
LAN NetView provides a set of common application programming interfaces (APIs)
that have been accepted by key industry organizations that further standards,
such as the Open Software Foundation (OSF) and X/Open, and accepted by IBM's
SystemView. One of these interfaces, named the X/Open Management Protocol
(XMP), allows developers to create applications without having to know the
underlying management and transport protocols, such as CMIP and SNMP.
SystemView has adopted XMP as its Common Management Interface Protocol (CMIP),
and the LAN NetView products are among the first management products in the
industry to incorporate elements of the OSF's Distributed Management
Environment (DME) technology.
ΓòÉΓòÉΓòÉ 11.3.2. Configuration, Installation, Distribution (CID) ΓòÉΓòÉΓòÉ
IBM also recognises the need to provide a generalised solution to the problem
of automated installation and configuration of multiple PCs.
On October 6, IBM announced its CID strategy. CID is not a single product, but
a collection of processes with supporting products. It automates the processes
of configuration, installation and distribution in the DSM environment and
dramatically improves productivity for system administrators. This allows both
standalone LAN and host-attached LAN customers to realize dramatic resource
savings by using the CID processes.
Though there are several aspects to CID enablement, its primary objective is to
provide unattended, remote installation of OS/2, its subsystems, and
application software on LAN attached workstations. Customers with both large
and small networks will be able to remotely install and manage software such as
OS/2 or OS/2 applications from a single location, without requiring the
involvement of the desktop workstation user. The CID process can apply to
installing not only OS/2 system code, but also supported application code. Each
system requires a physical LAN connection, but is not reliant upon a file
server like OS/2 LAN Server or Novell NetWare for the distribution mechanism.
The installation process is performed by an individual who initiates the
installation process at their workstation and performs other tasks such as
removing/replacing diskettes when prompted and rebooting the system when
prompted. This individual would not be required to know the responses to
detailed product installation questions. The answers to the product
installation questions are kept in response files which contain specific
responses to each installation question. The response files are unique to each
product. Each product provides either a utility or a model which the system
administrator can use to generate the response files. A procedure file which
may be tailored is set up by a system administrator and stored on the code
server. This procedure file contains the commands which initiate product
installations for other CID enabled products such as IBM LAN Server 3.0.
CID provides the ability to individually tailor PCs or groups of PCs. Previous
solutions allowed for cloning, where software is distributed by duplicating the
files across the network. These duplicated files did not always fit individual
workstation environments and sometimes required extensive changes from the
local user. With CID technology, individualized support is now enabled for
OS/2 products and applications, so that users can automatically receive new
software already configured for their computers. DOS and Windows users will
continue to be supported in the short term by cloning, with integrated support
for DOS clients to be provided by mid-1993.
Among the products that are being delivered to implement the CID process are:
o LAN NetView Start, which allows administrators to manage and plan the
configuration and installation of OS/2 software across the network.
o Network Transport Services (NTS/2), which provides NetBIOS connectivity and
helps execute instructions generated by Start about installing software on
the workstation.
o NetView Distribution Manager/2 (NetView DM/2), which will now provide
expanded software distribution and installation capabilities, including
change management and recovery, across standalone or interconnected LANs
from a single site on the LAN.
o Enhancements to NetView Distribution Manager (NetView DM) for an MVS host,
which, in conjunction with Netview DM/2, will now allow centrally controlled
distribution and installation, as needed, of system software, user and
vendor software, software changes and data files.
o Software Profile Management Facility, which works with NetView DM to store
descriptions, or "profiles," of groups of users with similar
characteristics, simplifying software installation and updates for a large
number of workstations.
All system and application software to be installed using this method must be
CID enabled. OS/2 Version 2.0, OS/2 LAN Server 3.0, NTS/2 v1.0 and OS/2
Extended Services Database Manager are all CID enabled. Enabling consists of
allowing installation to be redirected to a network drive, and the ability to
provide user input through a response file.
In addition to CID enabling our own products, IBM is encouraging vendors to
provide CID enabled applications. IBM also announced agreements with
independent software vendors (ISVs) who intend to enable selected products to
take advantage of CID. To date, a total of 164 vendors have committed their
products to become CID-enabling, including Computer Associates, Describe,
Lotus, Micrografx, Novell, Software Publishing Corp., Symantec and
WordPerfect.
ΓòÉΓòÉΓòÉ 11.3.3. Commitment to open standards ΓòÉΓòÉΓòÉ
One of the most important aspects of IBM's systems management strategy,
including OS/2 systems management, is IBM's intention to esnure
interoperability with a broad range of other vendors' systems management
products. That is why the IBM systems management products aim to support
industry standards such as CMIP and SNMP, and are based on the OSI Management
Framework standards implemented by Hewlett Packard's Open View Network
Management Server Product version 3.1. Thus the IBM tools will be able to take
advantage of a programming interface consistent with the Open Software
Foundation Distributed Management Environment (OSF/DME), as well as being part
of SystemView, IBM's strategy for enterprise-wide systems management.
OS/2 is the base platform for all of these management extensions, because it is
only OS/2 that is extendable in this way, and can provide the support for these
management functions (see OS/2 for client-server ). It is further illustration
that OS/2 is the true client of choice, as well as the server.
ΓòÉΓòÉΓòÉ 11.4. Migration from existing connectivity products ΓòÉΓòÉΓòÉ
IBM recognises that customers who wish to move towards the "super client"
platform, still have signficant investments in older connectivity products.
OS/2 2.0, as the integrating platform, provides a wide degree of support for
DOS-based connectivity products, as well as supporting other existing
networking products.
ΓòÉΓòÉΓòÉ 11.4.1. Networking on OS/2 ΓòÉΓòÉΓòÉ
Not only does OS/2 provide support for the two most popular network server
products, NetWare and OS/2 LAN Server, but it is also a platform that runs a
large range of the other major LAN software products, either as client, or
server, or both. Many of these products had support for OS/2 1.3, but new
versions are being produced for OS/2 2.0 from vendors such as Banyan (who are
developing a requester for their VINES network system) and Digital (who are
planning support for their Pathworks product). This makes OS/2 not only the
client of choice in these networks, but also, for many of them, the base server
platform.
DOS requester products for some of these products can be supported, running in
a VDM, though this often (as in the case of IBM DOS LAN Requester for OS/2 LAN
Server) requires booting the real version of DOS in a VDM (see Virtual Machine
Boot (VMB) ). Although DOS network drivers can often be run in a VDM, they can
only provide services to that individual VDM, since there is usually no Virtual
Device Driver for the protocol stack or the Media Access Control driver (eg
802.2). Obviously, this restriction is usual for OS/2 2.0 (see DOS device
drivers ), and in most cases causes no loss of function where a device is
dedicated to a single application (as it usually is for fax cards and
scanners). However, it tends to defeat the purpose of networks to have the
resources available to only one application, and therefore OS/2-based network
requesters and drivers are recommended whenever they are available (many
vendors already have or are working on OS/2 2.0 requester code for their server
product; contact your vendor for details).
ΓòÉΓòÉΓòÉ 11.4.2. DOS communications applications under OS/2 ΓòÉΓòÉΓòÉ
Because of OS/2's extensive compatibility with existing DOS and Windows
applications, it can even run DOS-based communications applications. This
includes not only popular asynchronous communications products such as ProComm
Plus, but also IBM's own DOS 3270 and 5250 products, Personal
Communications/3270 and DOS PC Support/400. The communications aspects are
straightforward, as OS/2 is designed to handle multiple concurrent protocols
and even background communications with more reliability than is possible under
DOS extender environments such as DOS/Windows 3.x (see Virtual Device Drivers
(VDDs) for more discussion of how it does this).
However, both Personal Communications/3270 and DOS PC Support/400 require some
customisation before they can be made to run satisfactorily under OS/2 2.0: the
first requires tailoring the DOS Settings, the second requires booting the
"real" DOS in a VDM to support special functions like shared folders (which
uses a block device driver) - see Appendices A and B in OS/2 Technical
Compendium - Volume 2: DOS and Windows Environment (GG24-3731-00) for more
details.
There are, even with these settings, some restrictions when running these
applications:
o File transfer must be executed from the same VDM as the emulator runs in
(you may need to enable session switching to the VDM DOS prompt via the DOS
Setting KBD_CTRL_BYPASS)
o Limitations in PC Support function (only Basic DOS, not Extended DOS
support; other DOS, Windows or OS/2 applications cannot access PC
Support/400 facilities)
o Sharing of Token-Ring Adapter (if using Token Ring rather than DFT or
Twinax) with other applications is not possible without an 802.2 VDD. This
restriction disappears if the 802.2 VDD from NTS/2 is installed (see DOS
device drivers and IBM Network Transport Services/2 ).
Because of these restrictions, it is recommended to use OS/2 versions of these
emulators and communications functions, which appear in Extended Services for
OS/2, because of the higher function, easier installation and access of
resources across DOS, Windows and OS/2 applications. Nevertheless, the support
of most functions for the DOS applications under OS/2 enables, for many users,
a more than adequate migration. This is in contrast to some of the press
reports concering Windows/NT, which warn that compatibility with existing
DOS-based connectivity programs and device drivers is likely to be extremely
limited, forcing users to consider buying new connectivity software if it is
available by the time Windows/NT ships. This is, of course, one of the many
compatibility issues that have to be encountered when a new platform is
introduced.
ΓòÉΓòÉΓòÉ 12. Futures ΓòÉΓòÉΓòÉ
It is of course important, as well as examining the strengths of OS/2 2.0, the
current release, to look at the future of OS/2 and some of the areas in which
it will develop.
OS/2 will continue to evolve to satisfy new requirements and bring forward new
technologies. With OS/2 2.0 we have designed the system not just for 1992, but
as a platform for many developments throughout the 90s.
The OS/2 32-bit architecture (OS/2 2.x) represents the base for the immediate
future. OS/2 2.0 has the functions that customers need today, and has been
designed to carry through to the next major steps, into the world of
object-oriented technology and distributed systems. This section examines some
of the areas in which OS/2 will be enhanced to meet the needs not only of
today's "super client" (see The changing PC environment and OS/2 for
client-server ), but of the long term vision of the "window on the world". The
OS/2 direction is towards a single client system, encompassing existing
investments and harnessing new technologies like object and multimedia, and a
scalable, robust server platform exploiting the increasing power of the
hardware, and distributed networking support based on open standards.
ΓòÉΓòÉΓòÉ 12.1. OS/2 1992 developments ΓòÉΓòÉΓòÉ
By the middle of 1992, IBM had delivered:
o OS/2 2.0 base system
o Extended Services for OS/2
o OS/2 LAN Server 2.0
By the end of 1992 and into early 1993, IBM intends to consolidate on the
early success of OS/2 2.0, by delivering updates to address the following
issues:
o improved device driver support
o enhanced "Seamless Windows" capability
o performance and memory enhancements
o enhanced WIN-OS/2 support
o extensions for multimedia and pen
The current hybrid 16-/32-bit PM graphics engine will be replaced by more
32-bit technology. This will allow at the same time 32-bit screen device
drivers to be delivered for VGA, SVGA and XGA. It is intended that these
drivers will not only improve screen performance, but also deliver high
resolution "Seamless Windows" capability for resolutions above VGA (see High
resolution support ). IBM plans to update WIN-OS/2 function to include Windows
3.1 features. Work is continuing to reduce the memory requirements of the
system, and to improve performance in low-end configurations. Such work will
produce performance benefits in all configurations.
Further multimedia extensions (MMPM/2) releases will ship in 1993, adding
video and image capabilities to the audio functions shipped in the first
release, which became available in June 1992. OS/2 Pen extensions and a
developers' toolkit are planned for late 1992 or early 1993.
During the same period, IBM will produce device adaptation kits to ensure that
more drivers for disks, displays and printers will appear from third party
vendors. Some of these may be available via IBM and public bulletin boards.
If you have a query about a specific device, you are advised to contact the
vendor in question first, to understand their development timeframes and
proposed distribution methods.
Many of the individual changes described above will be made available in a
service pack before the end of 1992. Some selective fixes are already being
made available through bulletin boards and via Compuserve. Other function,
such as the WIN-OS/2 3.1 support, is currently in beta test.
These are just the enhancements in the base product. Also planned are a series
of enhancements to the systems extensions, including a new release of OS/2 LAN
Server, enhancements to Communications Manager and the LAN Enabler, as well as
further developments in automated configuration, installation and
distribution. These will take place between the end of 1992 and early 1993.
ΓòÉΓòÉΓòÉ 12.2. 32-bit system extensions (communications, database, LAN) ΓòÉΓòÉΓòÉ
OS/2 2.0 is the base for Extended Services for OS/2, which provides a powerful
set of communications and database functions, and for OS/2 LAN Server version
2.0. The first releases of Extended Services for OS/2 and LAN Server (versions
1.0 and 2.0 respectively) on the OS/2 2.0 base are 16-bit only, in order to
provide the same system on both OS/2 2.0 and 1.x. This will allow customers to
standardise on common systems extensions across mixed 1.x and 2.0 (16- and
32-bit) bases.
However, future releases of both Extended Services for OS/2 and LAN Server will
be full 32-bit products, taking advantage of the 32-bit environment to allow
even better performance, concurrency and throughput. In addition, Novell will
provide a 32-bit version of NetWare on the OS/2 2.0 base, fulfilling the
commitment made in the IBM-Novell February 1991 joint announcement.
Using these 32-bit extensions will allows customers to fully exploit 32-bit
performance and throughput across the entire system.
ΓòÉΓòÉΓòÉ 12.3. Multimedia ΓòÉΓòÉΓòÉ
As applications become more sophisticated, multimedia technology embedded in
mainstream applications as well as in separate applications will become
increasingly important.
OS/2 is already an excellent platform for multimedia, as products such as IBM's
Audio Visual Connection (AVC), M-Motion and the ActionMedia II Developer's
Toolkit have shown. But the 32-bit OS/2 environment allows easier development
of more sophisticated multimedia applications, and will give the potential to
include multimedia features in many other applications, thus making its use
more widespread. In particular, the multi-tasking and overlapped I/O
capabilities of OS/2 will allow the kind of applications to be developed that
are not feasible under environments like Windows, that are based on DOS.
Multimedia Presentation Manager/2 (MMPM/2) is a series of extensions to OS/2
enabling it to handle multiple media (audio, images and video) in a consistent
way. Current DOS, Windows and OS/2 multimedia applications (IBM examples
include Storyboard Live!, AVC and Linkway) all include their own multimedia
device support and use their own unique data formats. MMPM/2 provides a level
of standardisation by offering:
o a hardware-independent layer, the Media Control Interface (MCI), which
allows new functions, devices and data formats to be added in a modular way
o a common data specification (RIFF) agreed by both IBM and Microsoft, and
common between the OS/2 and Windows multimedia extensions
MMPM/2 provides data streaming and synchronisation services to enable easy
management of and transfer of data between devices. MMPM/2 also presents a
series of "applets" which control and play devices like MIDI devices, digital
audio, and Compact Disc. The Multimedia Presentation Manager Toolkit/2
(MMPMTK/2) is also available to help programmers write OS/2 multimedia
applications. It includes language bindings for C and MASM, sample programs
and documentation. The MCI has both a procedural message interface for C and
MASM, and an interactive string interface. The latter allows easy
incorporation of multimedia function into a variety of applications (including
productivity applications like spreadsheets and word processors).
The multimedia extensions for Windows will run under the WIN-OS/2 environment,
but users and developers of multimedia may prefer to use the OS/2 facilities,
which provide as wide a range of device support, data compatibility through
formats like RIFF, but greater function, performance, and device utilisation.
For example, OS/2's support for sharing of media devices between multimedia
applications is superior to that possible under Windows.
Overall, OS/2 provides a better multimedia environment that Windows, because
of:
o Better encapsulation of system resources by OS/2. Under Windows 3.x the
programmer needs to be aware of directly controlling the system resources.
o Better stability of OS/2, especially in the area of multi-tasking which
provides improved coexistence of applications with less coding effort. For
example, yield points required under Windows 3.x are not necessary with
OS/2.
o Better graphics, such as Bezier functions, on OS/2.
o Better performance, through use of the flat memory model and pre-emptive
multi-tasking.
o more capacity for large data objects (image, sound) through the flat memory
model
The combination of better multi-tasking and the support for threads leads to
better synchronisation of the multiple data streams needed for multimedia. An
example is synchronising digital audio with analog video for a firing cannon
or a talking head. OS/2 "fast threads" are an enhancement specifically added
to improve the performance of threads for multimedia applications. In Windows
3.x, synchronisation is left entirely to the application. Developers have to
write it themselves, thus increasing development time and cost. OS/2 controls
multiple accesses to resources more effectively than Windows, so that audio
and video can run without noticeable interruption while loading other
applications. Such seamless integration of multimedia into the normal business
desktop is more difficult to achieve in an environment like Windows, that does
not provide pre-emptive multi-tasking.
Multimedia applications frequently need to deal with large memory objects for
bit maps, audio streams, or even streams of bit maps. These objects are much
easier to manipulate in the flat 32-bit memory model provided by OS/2 2.0.
All of these features will make OS/2 2.0 the multimedia platform of choice.
IBM and Apple announced, in July 1991, the two companies' intention to
collaborate on multimedia standards. In October 1991, IBM and Apple announced
the formation of an independent, joint venture company, Kaleida, to develop
multimedia specifications and technologies. This brings two of the leaders in
the multimedia industry together, and increases the possibility of a
broad-based industry standard.
ΓòÉΓòÉΓòÉ 12.4. Pen-based computing ΓòÉΓòÉΓòÉ
Pen-based computing is likely to be an important means of expanding the use of
computers in the next few years. IBM has explored the use of Go Corporation's
PenPoint operating system for dedicated pen-based portable systems. IBM
believes that some new applications may require the use of technology
specifically designed to exploit the pen interface. Nevertheless, applications
for existing systems may also benefit from pen-based extensions, particularly
on desktop machines, where the pen may prove, in some circumstances, to be a
better input tool than those currently available. IBM is exploring these
options through technology which we have demonstrated publicly, using pen
extensions for OS/2. In future, as the technology develops, the tablet and
desktop systems will both offer OS/2 and Pen extensions. It shows once again
how OS/2 is the base for most of IBM's innovative new technology in software.
ΓòÉΓòÉΓòÉ 12.5. Systems management ΓòÉΓòÉΓòÉ
Some companies in the desktop marketplace operate only in the PC arena, and
their strategies display little understanding of the difficulties of
configuring, maintaining and managing large volumes of PCs in a highly
connected environment. As companies' use of PCs grows, and their importance in
the corporate network increases, systems management of these distributed PCs
becomes of fundamental importance. The business platform of the 90s will need
to be a manageable platform, else the costs of keeping the system running will
endanger the benefits.
There is already a range of products available for OS/2 to support the systems
manager, including NetView Distribution Manager/2 and LAN Automated
Distribution/2 to help automated installation, SPM/2 for performance and
resource management, and DCAF for remote diagnosis (see Systems management ).
OS/2 will also become a full participant in IBM's SystemView strategy and more
products will be delivered to support the process of fault reporting, remote
diagnosis, asset management, software delivery and maintenance. It is easier
to provide this support on a true multi-tasking platform, which can accommodate
administrative processes or threads capturing management data, while processing
its normal local applications. The limitations of DOS (and therefore of
Windows) confine the function that can be provided to such systems.
ΓòÉΓòÉΓòÉ 12.6. Presentation Manager futures ΓòÉΓòÉΓòÉ
PM is the strategic SAA API for GUI development. IBM is fully committed to its
continued support and future enhancements. It has not been announced yet how
and in what timeframe the following will be delivered in product form, but they
represent some of the areas for future development:
ΓòÉΓòÉΓòÉ 12.6.1. 32-bit implementation ΓòÉΓòÉΓòÉ
It is planned that the internals of PM will be migrated to a full 32-bit
implementation. (In OS/2 2.0, a full 32-bit API is already provided - future
changes simply affect the way PM works internally). This will give improved
performance (it is anticipated that this change may improve performance for
many applications running on the Workplace Shell desktop). The first stage of
this is being provided in the Service Pack available by the end of 1992, with
the 32 bit PM Graphics Engine. Later work will move the PMWIN subsystem to a
full 32 bit implementation. In addition, parts of PM are currently written in
16-bit Assembler, and are being rewritten in C for greater portability in
preparation for a move to a portable version of OS/2.
ΓòÉΓòÉΓòÉ 12.6.2. Continuing object-oriented direction ΓòÉΓòÉΓòÉ
PM already exhibits some characteristics of an object-oriented environment,
especially in programming for the Workplace Shell and the System Object model
(SOM) - see System Object Model (SOM) . This direction will continue, not only
in the method of programming, but also in the user interface, driven by the
increasing object-orientation of SAA Common User Access (CUA). SOM itself will
evolve to offer increasing object content to OS/2.
ΓòÉΓòÉΓòÉ 12.6.3. Distributed PM ΓòÉΓòÉΓòÉ
This technology will allow an OS/2 PM application to be distributed across a
network to other OS/2 PM systems, to X Terminals or workstations running the X
Window system, or to DOS/Windows machines running an X server. This means that
32-bit OS/2 PM applications will be made available to 286 based DOS/Windows or
OS/2 1.x PCs, and X terminals or workstations connected to the OS/2 PM
application via a network using the X11 protocol. In essence, the OS/2 PM
application acts, in X terminology, as an X client. X server function (where
an application running on a UNIX RISC machine can appear in a window on a PC
running OS/2) has already been delivered with TCP/IP for OS/2 v1.2. These
developments allow OS/2 to integrate more fully into the open systems world as
well as providing a wider user base for OS/2 PM applications.
ΓòÉΓòÉΓòÉ 12.7. Object-oriented environments ΓòÉΓòÉΓòÉ
In looking ahead to the future, a key challenge to the IT industry, customer
and commercial developers alike, is the ability to deliver software solutions
in a more timely and cost effective manner. Object-oriented (OO) technologies
have proven to make software development and maintenance easier, faster, less
prone to error, and therefore less expensive. Object-oriented programming is
now being endorsed by the software industry as a more productive programming
approach, encouraging greater re-use of code. It is also more suitable for
object-oriented user interfaces, like OS/2 2.0's Workplace Shell.
One of IBM's goals for Personal Systems operating systems is to provide an
object-oriented development and operational environment that is customisable,
allowing developers and users to take incremental advantage of new
technologies, while protecting their investments in existing applications.
We are well on our way to achieving this with OS/2 2.0. OS/2 itself already
exhibits many aspects of object-oriented programming, particularly in the
System Object model (SOM), the object model that underpins the Workplace Shell
(see System Object Model (SOM) ). Furthermore, the Workplace Shell itself has
many characteristics of an object-oriented user interface (see An
INFORMATION-oriented user interface )
IBM also intends to encourage object-oriented development for OS/2 2.0. OS/2
will continue to be enhanced with extensions to improve support for
object-oriented programming languages, as well as enhancing SOM. SOM is a
technology for packaging software objects. It allows objects to interoperate
without requiring that they be written in the same language or compiled
together. SOM is the key element which allows applications to integrate with
the desktop facilities of the Workplace Shell. It supports objects written in
C today. C++ and other languages will be supported in the future. IBM intends
to extend SOM, to provide application frameworks to further increase programmer
productivity, and to provide tools to assist end users with visual programming
(assembly of objects). IBM will enhance SOM to be compliant with the Object
Management Group's (OMG's) Common Request Broker Architecture (CORBA). OMG is
the leading object technology consortium that has published CORBA. Adherence
to this standard will provide management for distributed heterogeneous networks
comprised of multivendor operating platforms.
Customers can start to build applications with object-oriented tools today
under OS/2, not only with C using SOM, but also with products like Enfin/2 and
Digitalk's Smalltalk/V PM . Furthermore, Borland have announced an agreement
with IBM under which Borland will supply their C++ object-oriented development
tools for OS/2 2.0, thus helping programmers who want to use C++ for
object-oriented development under OS/2 2.0. Other object-oriented development
tools vendors are also endorsing the OS/2 environment by supplying their tools
for OS/2 2.0.
IBM has made significant investments of its own in object-oriented programming,
of which SOM and the Workplace Shell are clear examples. Through alliances, IBM
is supplementing its own technology with that of the leaders in the
object-oriented industry, in order to provide for the future development of
OS/2.
The agreement between IBM and Apple, announced in October 1991, included both
companies' intention to form a joint venture company, Taligent, to develop a
next-generation operating environment based entirely on object-oriented (OO)
technology. IBM and Apple had independently come to the conclusion that
object-oriented technology is key to solving the ever-increasing application
development challenge. The two companies had been involved in developing
object-oriented technology in-house for some time. One of the key objectives in
forming Taligent was to bring the benefits of this technology to customers
sooner than either partner could have achieved alone.
IBM will licence Taligent's system, as will Apple and other hardware system
manufacturers. IBM and Apple are both contributing technology to the Taligent
venture. Among Apple's contributions was their "Pink" technology and among
IBM's offerings was SOM.
Taligent's technology will be used separately by both Apple and IBM as the core
of new products expected in the mid- to late-90s. These products will operate
in parallel to, and complement the evolution of, OS/2 and AIX. Over time IBM
intends to utilize a subset of Taligent's object services and frameworks to
benefit OS/2 application development and enable future compatibility with
Taligent's environment.
Taligent's system software environment will emerge in the mid-90s, targeted at
specific market segments that can readily leverage this technology. Once the
Taligent system is available, IBM intends to create an OS/2 "personality" as a
vehicle for protecting application investments. This will provide a path for
customers who want to take advantage of the Taligent system.
Therefore, in the mid to late 90s, OS/2 and the new object-oriented environment
will co-exist, and customers will be able to choose between an OS/2 system or a
full object-oriented environment. But even then, not all customers may need or
want to adopt a full object-oriented environment, and will stay with OS/2 as
OS/2's object-oriented content increases. OS/2 will remain the mainstream IBM
Personal Systems operating system, and will continue to be developed and
enhanced through the 90s. Since OS/2 itself will become increasingly more
object-oriented, and its applications will run in the new environment,
evolution towards a full object-oriented environment can be made gradually and
seamlessly over time. IBM believes there will continue to be many customer and
hardware requirements that demand OS/2, after the availability of Taligent.
OS/2 - an object-oriented future
This approach is possible because OS/2 2.0 already contains many
object-oriented features, such as the System Object Model, and the Workplace
Shell user interface. Because of OS/2's object-oriented content, and because
OS/2 applications will continue to run in the new system, OS/2 is the platform
best suited to evolve towards a fully object-oriented environment.
Some have tried to suggest that IBM's direction towards a future
object-oriented environment in some way threatens OS/2. The opposite is the
case: the IBM-Apple announcement endorses and strengthens the OS/2 strategy.
Since OS/2 already displays significant object-oriented content, and since OS/2
applications will be fully supported in the new object-oriented environment, it
follows that using, programming for and deploying OS/2 is an excellent way to
secure an object-oriented direction. If the future is object-oriented, OS/2 is
the way to get there.
ΓòÉΓòÉΓòÉ 12.8. Distributed computing ΓòÉΓòÉΓòÉ
IBM recognises the increasing importance of open networking, linking to mixed
vendor environments, both clients and servers. In May 1990 the Open Software
Foundation (OSF) announced the Distributed Computing Environment (DCE), a group
of technologies aimed at simplifying the work for users and application
developers in these complex computing environments. In endorsing DCE, IBM
subsequently announced not only support for DCE on AIX but also the intent to
extend the Systems Application Architecture (SAA) to incorporate key elements
of DCE. As one of the SAA systems, OS/2 will be a platform for the delivery of
the key elements of DCE.
For those not familiar with DCE, it consists of a number of key technologies.
Of these, six are of particular interest for distributed environments including
OS/2, and can be summarised as follows:
Remote Procedure Call (RPC)
The basic notion is that procedures called by an application may
actually be run on a computer somewhere else in the network. The RPC
mechanism takes care of the communications details so that writing
distributed applications approaches the simplicity of applications
on a single machine.
Distributed Naming Service
This provides a single naming model throughout the distributed
environment. Resources such as servers, files, disks, or print
queues are identified by name independent of the physical location
in the network. Full X.500 support is provided.
Time Service
Many distributed applications need a single time reference to
properly determine event sequencing and duration. The time service
provides a mechanism for synchronising each computer in the network
to a recognised time standard.
Security Service
Provides the network with authentication, authorisation, and user
account management. Authentication validates the identity of a user
or service to prevent fraudulent requests. Authorisation is the
process of determining whether an authenticated user should have
access to a resource. These facilities are made available through a
secure communications capability provided by the RPC.
Threads Service
A facility to support concurrent programming, much like threads in
OS/2. This will be used by other DCE components to implement their
services.
Distributed File System
Joins the file systems of the nodes in the network through a
consistent interface that makes global file access as easy as local
file access. The Distributed File System should provide users with
a uniform name space, file location transparency, and high
availability.
IBM's intention is that OS/2 LAN Server will evolve towards a full distributed
LAN system, providing DCE services as described above. OS/2 LAN Server will
incorporate architectures and industry standards which fully meet customer
requirements and will include technologies such as:
o Distributed Relational Database Architecture (DRDA)
o Open Software Foundation (OSF) Distributed Management Environment (DME)
o OSF's Distributed Computing Environment (DCE)
o Transarc/ENCINA Online Transaction Processing
OS/2 is a key part of IBM's plans for the delivery of key elements of
distributed computing. IBM has already shown technology demonstrations of OS/2
participating in a distributed environment along with AIX. Distributed
computing support will make OS/2 an even more open platform, as both a client
and a server.
ΓòÉΓòÉΓòÉ 12.9. AIX interoperability ΓòÉΓòÉΓòÉ
IBM is committed to providing greater co-existence and interoperability between
SAA and AIX systems. OS/2 will participate in this strategy. This does not
involve merging function, but retaining the unique strengths of the two
systems. The aim is to make it easier for customers to build mixed networks
combining the best of both OS/2 and AIX, RISC and Intel hardware, according to
their applications.
Part of this strategy involves putting compatible key systems components, such
as relational database, on both platforms. As well as providing a 32-bit
database on OS/2 in future, IBM will also provide a compatible 32-bit database
for AIX, and support client operations between AIX and OS/2 databases. Another
element of the strategy is to improve co-existence by providing networking
support. Products like TCP/IP for OS/2, already exist to fulfil this
requirement, and IBM intends to strengthen OS/2-AIX inter-networking in future
through DCE, DME and other technologies.
ΓòÉΓòÉΓòÉ 12.10. Future Windows compatibility ΓòÉΓòÉΓòÉ
OS/2 2.0 supports Windows 3.0 applications by including modified Windows code
under the cross-licencing agreement with Microsoft. The March 1992 release of
OS/2 2.0 does not contain support for Windows 3.1, since at the time when OS/2
2.0 shipped, Windows 3.1 was not available. It would be impossible to plan
support for a product that had not shipped by the time OS/2 2.0 was available.
IBM plans, and is able, to support Windows 3.1 at a later point, if it proves
necessary (see OS/2 1992 developments and Windows 3.1 ). In fact, on April 7th,
1992, the day after Microsoft shipped Windows 3.1, IBM demonstrated the Windows
3.1 Program Manager running under OS/2 2.0.
It is important to understand that OS/2 2.0 supports Windows applications, not
Windows. Windows support in OS/2 is only relevant for the Windows applications
that OS/2 customers wish to use. IBM continues to licence the DOS/Windows
source code, and has rights to all source code in development until September
1993, in order to continue to provide support for 16-bit Windows applications.
Microsoft has not made its future plans clear on 16-bit Windows application
support, but it may be difficult for Microsoft to persuade its customers to
accept future versions of 16-bit Windows that do not support today's 16-bit
Windows applications. IBM considers that it has the ability to provide support
for today's generation of Windows 16-bit applications, as long as is necessary.
There are, as yet, no 32-bit Windows applications available, because Microsoft
does not plan to ship its first 32-bit Windows platform until some time in
1993. However, there are a growing number of OS/2 applications: hundreds are
already shipping, and over 1000 have been announced for shipment by the end of
1992 or early 1993. OS/2 will therefore have the largest number of 32-bit
applications for some time. Therefore, the trend in the marketplace towards
real 32-bit applications, and the continuing success of OS/2, may make Windows
support a moot point. The issue may be rather what levels of OS/2 32-bit
compatibility can Microsoft build into their future products.
Since many of the applications currently available or under development for
16-bit Windows 3.x will also be available for 32-bit OS/2, future Windows
compatibility may cease to be an issue, since running native OS/2 versions of
applications will be superior to running the Windows versions even in WIN-OS/2
(see Porting Windows applications to OS/2 ). Support for Windows applications
is intended mainly as a migration to OS/2 2.0, but investment in Windows
applications should not be considered a long-term strategy for customers
planning an OS/2 future. Many vendors now understand the need to provide real
OS/2 versions of their software for competitiveness' sake, and are not relying
on running their Windows version under OS/2 to address the OS/2 opportunity
properly. Furthermore, the evidence suggests (see Windows applications ) that
Windows applications have not made anything like the same impact on the market
as Windows itself. IBM will continue to monitor the continued need for
supporting Windows applications, and will exercise its skills and intellectual
rights to do what its customers require.
ΓòÉΓòÉΓòÉ 12.11. Portable version of OS/2 ΓòÉΓòÉΓòÉ
The joint IBM-Microsoft statement at Comdex in November 1989, indicated that
both companies were committed to producing a version of OS/2 that could run on
non-Intel processors such as RISC, and include US Department of Defense
security at the C2 level and symmetric multiprocessing. IBM remains committed
to this direction.
The most important part of the work in portability lies in ensuring that
applications are easily portable to any new platform. The other element of
portability is to provide a portable operating system kernel (the low level
code that interfaces with the processor). In fact, the importance of the
latter has often been exaggerated in relation to the former: there is no point
in having a portable kernel if you cannot move your applications easily.
IBM has already made great progress in the first step with the 32-bit OS/2 API,
which eliminates many of the dependencies of the 16-bit Intel-based
architecture. This provides the potential of a 32-bit code base which is ready
to take advantage of a future move of the kernel to other processors. The
kernel may change underneath, but the API must be established and preserved.
It is also clear in the design of OS/2 2.0 how IBM is already preparing many of
the key components of OS/2 (such as the subsystems like PM and the Workplace
Shell, and the API set) for easier portability and to accommodate future
directions. In contrast, although Microsoft has publicised its portable
kernel, the other elements required for portability, specifically a full 32-bit
API with multi-threading, interprocess communications and advanced graphics,
are not yet delivered. And it is unclear from their public disclosures about
Win32s (see OS/2 - a 32-bit API - TODAY ) how to make a straightforward
migration to take advantage of RISC, without changes to the code base. The
Windows API today remains 16-bit, and 32-bit exploitation, including the full
benefits of portability, remain a future promise.
As for the choice of kernel, IBM has a variety of options, through licencing
agreements. IBM is working on a range of technologies, and will announce its
direction when it has fully evaluated the available technology in the light of
customer requirements. Suffice it to say that although the "NT" in Microsoft's
future system, Windows/NT, stands for "New Technology", the idea of a portable
micro-kernel is not new, and other examples already exist in a mature form,
including the OSF's micro-kernel based on the Carnegie-Mellon Mach technology.
IBM has chosen not to integrate Windows/NT code into its future offerings. But
NT is by no means the only way of achieving the objectives stated in November
1989.
As far as customers and application developers are concerned, if portability is
a key issue, 32-bit application development under OS/2, rather than migration
from 16-bit DOS and its extensions, is the clearer path.
ΓòÉΓòÉΓòÉ 12.12. Conclusion ΓòÉΓòÉΓòÉ
OS/2 is therefore not only taking advantage of today's requirements, and the
wide range of DOS, Windows and OS/2 applications that already exist, but
provides an immediate future for powerful 32-bit developments, including a
32-bit API and the potential to integrate with the new OS/2 Workplace Shell
user interface. The requirements of the workstation of the late 1990s for an
object-oriented platform supporting multimedia, DCE and systems management, can
only be served by a robust, architected 32-bit platform. That platform is
OS/2.
ΓòÉΓòÉΓòÉ 13. Appendices ΓòÉΓòÉΓòÉ
ΓòÉΓòÉΓòÉ 13.1. Comparison tables ΓòÉΓòÉΓòÉ
ΓòÉΓòÉΓòÉ 13.1.1. DOS environments ΓòÉΓòÉΓòÉ
The following notes refer to the table on the next page.
1. See Comparison with memory usage under DOS , Amount of memory and Memory
2. See MVDM memory management and Expanded and Extended Memory Also see
Standard mode for Windows 3.x's EMS support.
3. The phrase "none/switch" means that no individual DOS application can
overcommit memory, but the real mode portion can be moved to disk to make
room for another DOS application. However, extended or EMS memory
allocated by the application is not switched to disk. OS/2 1.3 can swap
the DOS application to disk when running protected mode applications.
Windows 3.x 386 enhanced mode can overcommit up to four times the physical
memory on the machine. OS/2 2.0 is limited only by the amount of
available disk space.
4. Although the default is to swap through the file system, Windows 3.x 386
enhanced mode does allow swap space to be pre-allocated, and gain improved
performance by avoiding the DOS file system. Because this disk space is
pre-allocated, none of it is available to be shared dynamically for any
other use. OS/2 2.0 implements access to the swap space via the file
system for both FAT and the HPFS. The OS/2 2.0 implementation provides
the flexibility of a dynamically sized swap file combined with good
performance.
5. OS/2 2.0 and Windows 3.1 provide windowing of DOS applications on the
Workplace Shell desktop in all text and VGA graphics modes, while Windows
3.0 only supports windowing of text and CGA modes. According to
Microsoft, Windows/NT will not support windowed VGA graphics.
6. Although Windows 3.x does include a print spooler, and printing
concurrently from DOS applications is not supported. Windows permits only
one DOS application to print and requires that other DOS applications be
suspended if they attempt to print concurrently. Use of a DOS print
spooler (loaded prior to Windows 3.x.) is not a viable solution, since
printing concurrently from multiple DOS sessions causes all the output to
be jumbled together on the same page. Windows does warn of a device
conflict in use of the printer in the latter case and offers a choice on
how to proceed, but whatever the choice made, the same incorrect output
results. OS/2 2.0 provides correct spooling of printer output from
concurrent DOS applications.
7. Some DOS applications are extremely timing sensitive, mostly
communications applications using high data rates. These are supported in
all systems when the application is in the foreground. However, in DOS,
OS/2 1.3., Windows 3.0 real mode, and Windows 3.x standard mode, the
application is suspended while in the background and so cannot satisfy any
timing constraint. In 386 enhanced mode, Windows 3.x provides the option
of setting exclusive mode, so a timing sensitive application can be run in
the foreground without interference due to time slicing. However, all
other applications are suspended while this DOS application is running in
this mode. In some cases the need for exclusive mode can be avoided by
manually adjusting the relative priorities. The ability to dynamically
manage priorities permits OS/2 2.0 to multi-task timing critical
applications both in the foreground and background. Detailed
configuration of idle time detection is also possible in the DOS Settings
(see DOS Settings ).
8. Although Windows 3.1 has addressed some of Windows' limitations in terms
of stability, it is still based on DOS, and therefore still prone to
problems caused by DOS-based TSRs which take the system out of protected
mode into real mode (see Reliability and protection and Reliability ).
ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 9. Comparison of DOS environments Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Γöé Γöé Γöé WINDOWS 3.0 ON IBM DOS 5.0 Γöé WIN 3.1 ENH Γöé Γöé
Γöé Γöé Γöé Γö╝---------------Γö¼----------------Γö¼---------------+ MODE WITH DOS Γöé Γöé
Γöé Γöé IBM DOS 5.0 Γöé OS/2 1.3 Γöé REAL Γöé STANDARD Γöé ENHANCED Γöé 5.0 Γöé OS/2 2.0 Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Conventional Memory Γöé 622 KB Γöé 529 KB Γöé 558 KB Γöé 571 KB Γöé 569 KB Γöé 577 KB Γöé 633 KB Γöé
Γöé - with EMS & Mouse (1) Γöé 601 KB Γöé Γöé Γöé Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Memory w/ LAN Attach Γöé 543 KB Γöé 486 KB Γöé 386 KB Γöé 391 KB Γöé 441 KB Γöé 477 KB Γöé 633 KB Γöé
Γöé - configured as PCLP Γöé Γöé Γöé Γöé Γöé Γöé Γöé Γöé
Γöé Receiver Γöé Γöé Γöé Γöé Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Memory w/3270 Attach Γöé 522 KB Γöé 495 KB Γöé 486 KB Γöé 492 KB Γöé 541 KB Γöé 549 KB Γöé 633 KB Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Extended Memory (XMS) Γöé 16 MB Γöé none Γöé 16 MB (total) Γöé 16 MB (total) Γöé 16 MB (total) Γöé 16 MB (total) Γöé 16 MB(per app)Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé EMS 4.0 Memory(2) Γöé 16 MB Γöé none Γöé 16 MB (total) Γöé none Γöé 16 MB (total) Γöé 16 MB (total) Γöé 32 MB(per app)Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Γöé
Γöé Γöé
Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Physical RAM for DOS Γöé 0-1 MB Γöé 0-640 KB Γöé 0-1 MB Γöé 0-1 MB Γöé Any/Paged Γöé Any/Paged Γöé Any/Paged Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Memory Overcommit(3) Γöé None/Switch Γöé None/Swap Γöé None/Switch Γöé None/Switch Γöé 4 x RAM Γöé 4 x RAM Γöé Avail Disk Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Swap File(4) Γöé File System Γöé File System Γöé File System Γöé File System Γöé Physical Γöé Physical Γöé File System Γöé
Γöé Γöé Γöé Γöé Γöé Γöé (Preallocated)Γöé (Preallocated) Γöé (Dynamic) Γöé
Γöé Γöé Γöé Γöé Γöé Γöé or File SystemΓöé or File System Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Γöé
Γöé Γöé
Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Number of DOS Apps Γöé 16 Γöé 1 Γöé 16 Γöé 16 Γöé 16 Γöé 16 Γöé >32 Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Background Execution Γöé No Γöé No Γöé No Γöé No Γöé Yes Γöé Yes Γöé Yes Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Γöé
Γöé Γöé
Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Invocation Γöé Shell/Cmd Γöé Icon Γöé Icon Γöé Icon Γöé Icon Γöé Icon Γöé Icon Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Windowed(5) Γöé No Γöé No Γöé No Γöé No Γöé Yes Γöé Yes Γöé Yes Γöé
Γöé Γöé Γöé Γöé Γöé Γöé (Text, CGA) Γöé (Text, VGA) Γöé (Text, VGA) Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Cut & Paste Γöé No Γöé No Γöé Yes Γöé Yes Γöé Yes Γöé Yes Γöé Yes Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Print Spooling(6) Γöé Yes Γöé Yes Γöé No Γöé No Γöé No Γöé Yes Γöé Yes Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Installable File System Γöé No Γöé Yes Γöé No Γöé No Γöé No Γöé No Γöé Yes Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Γöé
Γöé Γöé
Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Direct Hardware Access Γöé Yes Γöé Yes Γöé Yes Γöé Yes Γöé Yes Γöé Yes Γöé Yes Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Timing Dependent Apps.(7Γöé Foreground Γöé Foreground Γöé Foreground Γöé Foreground Γöé Exclusive OptiΓöénExclusive OptioΓöé Foreground/ Γöé
Γöé Γöé Γöé Γöé Γöé Γöé (Manual) Γöé (Manual) Γöé Background Γöé
Γöé Γöé Γöé Γöé Γöé Γöé Γöé Γöé (Automatic) Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Γöé
Γöé Γöé
Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DPMI Γöé No Γöé No Γöé No Γöé No Γöé Yes Γöé Yes Γöé Yes Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé VCPI and DOS Extenders Γöé Yes Γöé No Γöé No Γöé No Γöé No Γöé No Γöé No Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Γöé
Γöé Γöé
Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Continues after serious Γöé Rarely Γöé Rarely Γöé Rarely Γöé Rarely Γöé Sometimes Γöé Often Γöé Yes Γöé
Γöé Application errors (8) Γöé Γöé Γöé Γöé Γöé Γöé Γöé Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
ΓòÉΓòÉΓòÉ 13.1.2. OS/2 2.0 compared with Windows 3.0/3.1 ΓòÉΓòÉΓòÉ
ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 10. OS/2 2.0 compared to Windows 3.0/3.1 Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Γöé WINDOWS 3.1 Γöé OS/2 2.0 Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Hardware Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Processor Γöé 286; 386SX+ Γöé 386SX+ Γöé
Γöé Γöé (1) Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Minimum hard drive Γöé Approx 9MB Γöé Approx 13MB Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Hard drive for Full install Γöé 11MB - plus Γöé 27.6MB Γöé
Γöé Γöé 50% of Γöé Γöé
Γöé Γöé remaining Γöé Γöé
Γöé Γöé partition for Γöé Γöé
Γöé Γöé swap file Γöé Γöé
Γöé Γöé (default) (2) Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Largest hard drive Γöé 1GB Γöé 64GB (HPFS) Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Largest file size Γöé 1GB Γöé 2GB Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé SCSI exploitation Γöé No Γöé Yes Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé File System options Γöé FAT only Γöé Enhanced FAT Γöé
Γöé Γöé Γöé or HPFS Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Memory Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Physical Memory Limit Γöé > 16 MB Γöé > 16 MB Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Virtual Memory Limit Γöé 4 x Physical Γöé 512 MB per Γöé
Γöé Γöé Γöé process (or Γöé
Γöé Γöé Γöé Disk space) Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Memory Model Γöé Segmented (64 Γöé Flat memory Γöé
Γöé Γöé KB) Γöé objects Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Multi-tasking (3) Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Multi-tasking - DOS Applica- Γöé Time Slicing Γöé Pre-emptive Γöé
Γöé tions Γöé Γöé Time Slicing Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Multi-tasking - Windows & OS/2 Γöé Co-operative Γöé Pre-emptive Γöé
Γöé Apps Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Priority Γöé Static (set Γöé Dynamic Γöé
Γöé Γöé by user) Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Dispatchability Γöé Process Γöé Thread Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé System Services Γöé Serial Γöé Parallel / Γöé
Γöé Γöé Γöé Overlapped Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Reliability/Protection (4) Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Protection between Applica- Γöé Limited Γöé Protected Γöé
Γöé tions Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Kernel protection - DOS Appli- Γöé Limited Γöé Protected Γöé
Γöé cations Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Kernel protection - Windows & Γöé Limited Γöé Protected Γöé
Γöé OS/2 Apps Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Remains in protected mode (5) Γöé No - access Γöé Yes Γöé
Γöé Γöé to real mode Γöé Γöé
Γöé Γöé possible Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Reliability/Availability/ServicΓöé None in 3.0. Γöé Standalone Γöé
Γöé (RAS) Support (6) Γöé In 3.1: Error Γöé Dump, Error Γöé
Γöé Γöé Logging/Dump Γöé Logging, Γöé
Γöé Γöé via Γöé Trace Utili- Γöé
Γöé Γöé Dr.Watson; No Γöé ties & APIs Γöé
Γöé Γöé Trace APIs or Γöé Γöé
Γöé Γöé Trace format- Γöé Γöé
Γöé Γöé ting Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Compatibility Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Multiple Concurrent DOS Appli- Γöé Yes (enhanced Γöé Yes Γöé
Γöé cations Γöé mode only) Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Windows 2.x Applications Γöé No Γöé Yes Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Windows 3.0 Applications Γöé Most (7) Γöé Most Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Clipboard support Γöé Windows and Γöé Windows, DOS Γöé
Γöé Γöé DOS only Γöé and OS/2 Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DDE support Γöé Windows apps Γöé Windows and Γöé
Γöé Γöé only Γöé OS/2 apps Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé OLE support Γöé Yes Γöé Yes Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé 16-bit OS/2 Applications Γöé No Γöé Yes Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé 32-bit OS/2 Applications Γöé No Γöé Yes Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Printing and Fonts Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Print spooling Γöé Limited (8) Γöé Yes, for all Γöé
Γöé Γöé Γöé applications Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Adobe Type Manager standard Γöé No Γöé Yes Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Network printing support Γöé Some Γöé Full (9) Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Background printing perform- Γöé Unpredictable Γöé Predictable Γöé
Γöé ance Γöé Γöé (10) Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé National Language Support Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Number of Language Versions Γöé 12 Γöé 16 Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Data Interchange Γöé ISO8859/CP819 Γöé CP850 (con- Γöé
Γöé Γöé (different Γöé sistent Γöé
Γöé Γöé from DOS) Γöé throughout Γöé
Γöé Γöé Γöé OS/2) Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Host connectivity/Interchange Γöé 3rd party Γöé Included in Γöé
Γöé Γöé Γöé Extended Ser- Γöé
Γöé Γöé Γöé vices for Γöé
Γöé Γöé Γöé OS/2 Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Code Page Γöé Single Γöé Selectable Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Other Factors Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Full 32-bit APIs Γöé No Γöé Yes Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Concurrent High Speed Comms Γöé Unreliable Γöé Yes Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Background Comms (11) Γöé Unreliable Γöé Yes Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé OEM Hardware Support Γöé Yes Γöé Yes Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Development Tools Γöé Yes Γöé Yes Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Command Language Γöé .BAT Γöé .BAT, .CMD Γöé
Γöé Γöé Γöé and REXX Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Installation migration for Γöé Limited Γöé Yes Γöé
Γöé existing apps Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 10. OS/2 2.0 compared to Windows 3.0/3.1 Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Γöé WINDOWS 3.1 Γöé OS/2 2.0 Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé User Interface Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé CUA compliance Γöé Graphical Γöé Workplace Γöé
Γöé Γöé Model ('89) Γöé Model ('91) Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Icons representing non-loaded Γöé No (3rd Γöé Yes Γöé
Γöé files on desktop Γöé party) Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Place icons anywhere on Γöé No (files in Γöé Yes Γöé
Γöé desktop Γöé File Manager, Γöé Γöé
Γöé Γöé programs in Γöé Γöé
Γöé Γöé Program Γöé Γöé
Γöé Γöé Manager, Γöé Γöé
Γöé Γöé printers - no Γöé Γöé
Γöé Γöé icons) Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Group windows Γöé Single-layer Γöé Multi-layer, Γöé
Γöé Γöé (can't put Γöé hierarchical Γöé
Γöé Γöé group inside Γöé folders Γöé
Γöé Γöé another Γöé Γöé
Γöé Γöé group) Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Customise GUI look/feel Γöé No Γöé Yes Γöé
Γöé Γöé Γöé (Workplace Γöé
Γöé Γöé Γöé Shell, Γöé
Γöé Γöé Γöé Windows 3.x, Γöé
Γöé Γöé Γöé OS/2 1.x) Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Context Menus Γöé No Γöé Yes Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Drag/Drop across entire Shell Γöé Windows 3.0 - Γöé Yes Γöé
Γöé environment Γöé No. Windows Γöé Γöé
Γöé Γöé 3.1 - File Γöé Γöé
Γöé Γöé Manager only Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Object Management Γöé No Γöé Yes Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Graphical Install Γöé Yes Γöé Yes Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Intelligent fonts Γöé Windows 3.0 - Γöé Yes (Adobe Γöé
Γöé Γöé No (ATM sepa- Γöé Type Manager Γöé
Γöé Γöé rate pur- Γöé for OS/2 & Γöé
Γöé Γöé chase). Γöé Windows - Γöé
Γöé Γöé Windows 3.1 - Γöé 1200 fonts) Γöé
Γöé Γöé Yes (TrueType Γöé Γöé
Γöé Γöé - 650 fonts) Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Long file names Γöé No Γöé Yes Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Applets Γöé Yes Γöé Yes Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Consistent GUI logon Γöé No - requires Γöé Yes Γöé
Γöé Γöé Network Γöé Γöé
Γöé Γöé vendor Γöé Γöé
Γöé Γöé utility Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Interactive Tutorial Γöé Yes Γöé Yes Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Command Reference Γöé No Γöé Yes Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Advanced Connectivity(12) Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Client and Server platform Γöé No Γöé Yes Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Multiple Concurrent Protocols Γöé Limited Γöé Yes Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé SNA LU6.2 Γöé 3rd party Γöé Yes Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé APPN Γöé 3rd party Γöé Yes Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé TCP-IP Γöé 3rd party Γöé IBM TCP-IP Γöé
Γöé Γöé Γöé for OS/2 Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Systems Management Γöé 3rd party Γöé Various from Γöé
Γöé Γöé Γöé IBM (13) Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé SQL Database Server Γöé MS SQL Server Γöé Yes Γöé
Γöé Γöé (requires Γöé Γöé
Γöé Γöé OS/2) Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé SQL Database Client Γöé 3rd party Γöé Yes Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé NFS Γöé 3rd party Γöé IBM TCP-IP Γöé
Γöé Γöé Γöé for OS/2 Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé X-Windows server Γöé 3rd party Γöé IBM TCP-IP Γöé
Γöé Γöé Γöé for OS/2 Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
Γöé Γöé Γöé Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
1. Although Windows 3.1 will run on a 286, this does not enable enhanced mode
support, which is required to be competitive with OS/2 function
(multi-tasking DOS applications, demand paging, 32-bit support).
2. See Disk space
3. See Multi-tasking of DOS applications , Multi-tasking and Performance
4. See Reliability , Reliability and protection and Protected mode operation
5. See Reliability , Reliability and protection
6. Windows 3.1 uses Dr.Watson, OS/2 2.0 uses SYSLOG and Standalone Dump
7. Windows 3.1 will not run some Windows 3.0 applications, which will need
updates. Compatibility notes are listed in the APPS.HLP file. Several
Windows 3.0 applications need updated versions to run on Windows 3.1. OS/2
2.0 runs all but a very small minority of Windows 3.0 applications, as
well as all the Windows 2.x applications that Windows 3.1 will no longer
support (no real mode support provided) - see Real mode (NOT AVAILABLE IN
WINDOWS 3.1) and 386 Enhanced mode
8. Print spooling is not provided by Windows 3.1 for DOS applications, only
for Windows applications. OS/2 2.0 provides print spooling for DOS,
Windows and OS/2 applications
9. OS/2 2.0 has extensive user print management capabilities (40 APIs vs 12
APIs in Windows 3.1) for querying, holding, releasing and deleting jobs
(including a graphical view of job and queue status).
10. OS/2 consistently outperforms Windows with background print operations, in
multi-tasking environments
11. See notes on Background Execution in Appendix A on DOS applications.
12. OS/2 2.0's "Yes" answers here are all using Extended Services for OS/2
except where stated. It is important to note that the Windows column
refers to Windows specific programs (i.e. written to explicitly take
advantage of Windows GUI, memory addressability, or time-slicing).
Although there are many DOS connectivity options, and they may be usable
under Windows, the integration of these complex subsystems and any
co-residency of two or more options (eg TCP/IP and SNA) is completely the
responsibility of the customer as a custom integration effort. Moreover,
Windows on DOS has substantial architectural limitations which make
multiple network connections difficult to integrate than under OS/2 (lack
of memory, lack of protection, and weak multi-tasking support). OS/2's
base environment provides tools and system support designed to allow this
type of multi-connectivity installation. Besides, all the extra software
required for these functions under OS/2 comes from IBM, and one can
therefore anticipate a greater degree of integration (see OS/2 for
client-server ).
13. See Systems management
ΓòÉΓòÉΓòÉ 13.2. Hardware requirements and performance ΓòÉΓòÉΓòÉ
The main reference to OS/2 system requirements is the OS/2 2.0 Information and
Planning Guide (G326-0160-00), and the equivalent guides for Extended Services
for OS/2 and OS/2 LAN Server. Anyone planning installation of OS/2 across
several workstations should obtain these guides. In this section we will
discuss only the key issues - for the detail, you should consult the
Information and Planning Guide. This section only discusses issues relating to
the base system, not to the extensions, though many of the principles apply to
both.
ΓòÉΓòÉΓòÉ 13.2.1. Minimum requirements ΓòÉΓòÉΓòÉ
OS/2 2.0 is designed for personal computers with the following minimum
requirements:
o Intel (or compatible) i386SX microprocessor or above
o 4MB of memory
o 60MB hard disk with 15-30MB of free disk space
o 2-button mouse or other pointing device
Please note that this is a minimum. Many will be satisfied with this
configuration if simple tasks are undertaken, but for more powerful
multi-tasking and larger applications, more memory may be required. There is a
trade-off to be made between memory and performance, in particular: OS/2 can
work around a limit in physical memory by swapping to disk, but since disk
access is slower than memory access, this will tend to reduce overall
performance, which will show itself more in switching between applications
than in the performance of an individual session.
OS/2 2.0 will not run on machines equipped with an Intel 80286 processor.
Therefore, computers such as the IBM PC AT, PS/2 Model 30-286, and Models 50,
50Z, and 60 cannot be used with OS/2 2.0. However, OS/2 2.0 does support
non-386 based machines that have been upgraded with a 386 or 486 processor
using the Aox Micromaster, Intel SnapIn, or Kingston SX/Now! card.
In addition, OS/2 2.0 is supported on a broad range of IBM-compatible systems,
including models from Compaq, AST, Olivetti, Toshiba, Hewlett Packard, Dell,
Gateway, Wang, DEC, NCR, Tandy, ACER, CompuAdd and many others.
The certification of compatibility is based on IBM's tests of key functions of
OS/2 2.0, based on selected model configurations provided by the manufacturers
of these non-IBM hardware systems. Test results are available on CompuServe,
IBM Forums (OEM and OS2ARENA), and other bulletin boards. If you need
additional information, please consult your hardware supplier. If you are
using a specific model, and wish to have it certified, please check with your
IBM representative or Authorised Dealer. If it has not been tested by IBM,
IBM welcomes your help in making contact with the manufacturer to have the
machine tested. IBM wishes to make the range of OS/2 compatibility as broad
as is possible.
In practice, OS/2 has been designed to operate correctly with a wide range of
hardware, and the evidence from many of the users who have registered their
copies already (see Broad hardware support ) indicates that OS/2 2.0 is
already running on a large number of different machines.
ΓòÉΓòÉΓòÉ 13.2.2. Processor ΓòÉΓòÉΓòÉ
Because of its 32-bit addressing power, the OS/2 2.0 operating system requires
a computer that has a system unit equipped with an Intel (or compatible) i386
(or higher) microprocessor. The i386SX microprocessor provides adequate
performance for those who work in lower-demand application environments. In
most environments that demand multiple concurrent processes, the i386DX will be
adequate for satisfactory performance. The IBM 386SLC chip offers high
performance from a 386SX design, and along with the new 486SLC chip, offers
outstanding price-performance for an OS/2 system. Systems equipped with the
386SLC represent a viable entry point for a multi-tasking OS/2 client.
486SLC-based systems represent an excellent option for throughput even of heavy
multi-tasking loads. With prices of 486SX systems being reduced, they can be a
cost-effective option for client workstations. For computers that will be used
as network servers, consider the i486 series. Also consider the 486 as a base
processor for those who expect to switch frequently and rapidly among a large
number of concurrent tasks.
ΓòÉΓòÉΓòÉ 13.2.3. Memory size ΓòÉΓòÉΓòÉ
Memory and disk storage are closely related because of the ability of the
operating system to manage the allocation of memory resources between real
physical memory and hard disk space. In general, it is important, when
calculating memory and disk requirements, to work on the concept of "working
set", in simple terms the sum of physical memory and swap file size. The
balance of physical memory installed versus swap space is key to determining
overall performance - the more working set is gained from swap space rather
than physical memory, the lower overall system performance.
4MB is adequate for an entry-level workstation running few tasks. This enables
users to run applications or other system utility programs concurrently, but it
presents a constrained environment (limited memory) for some large
applications. In limited memory configurations, performance of applications
might be reduced, particularly when the operating system is loading an
application or switching from one application to another or to the desktop.
This is as a result of paging, as the code required is loaded to memory from
disk, and the least recently used memory is paged to disk to make room.
Although more tasks can be accommodated by swapping, performance degradation
would suggest more memory would be required for more intensive multi-tasking.
However, an OS/2-only workstation (ie no DOS or Windows applications) with a
LAN requester can perform acceptably in a 4-5MB configuration. This indicates
that the entry level configurations are suitable for some client scenarios.
To estimate probable working set requirements, estimate 2.5MB for the base
system without any applications, 0.6MB per concurrent DOS session, and 1MB per
concurrent WIN-OS/2 session. (The latter two figures assume the default amounts
of XMS, EMS and DPMI memory installed, which are 2048K, 2048K and 2MB
respectively - the actual figure may therefore be more, or less, depending on
the settings chosen.) Thus a system running DOS and Windows applications can
run satisfactorily in 6MB. A connected workstation (eg LAN requester plus 3270
emulators) will require around 8MB (though note the low entry point above for
OS/2-only clients with just a LAN requester).
The amount of memory installed can be an important factor in performance,
particularly when swapping between applications. Since working sets of 1-2MB or
more are being switched, the performance difference between a 4MB and a 6MB
configuration can be substantial; a further increase to 8MB is appreciable, but
not usually to the same extent. The system tends to handle overcommitment on
memory well above the 8MB point. Large applications and heavy multi-tasking
will benefit from 8MB or more.
Though adding more memory inevitably adds to the cost of the system, it is to
be remembered that the cost of memory is decreasing. Although OS/2 2.0 will
tend to require more memory than Windows 3.1 for equivalent software
configurations, the cost of the memory will often be less than $100 at today's
memory prices. Many customers are finding that the extra costs for memory are
compensated by the increased function and stability that OS/2 offers. Customers
hoping to achieve the combination of a 32 bit, stable multitasking platform, on
an affordable hardware configuration, may consider this trade-off between
function and system requirements. Furthermore, independent analysts have
predicted that Windows/NT will require an even higher configuration than OS/2
2.0. Gartner Group has told its customers that it believes "a mainstream
platform for Windows/NT will be a 486DX with 12 to 16 megabytes of RAM (and up)
on the workstation"
It is to be remembered that in all the above estimates for OS/2 memory
requirements, results will vary with the configuration of the machine and the
applications run. Also, performance is a subjective matter - few people agree
on what is acceptable relative to the cost of a configuration. Customers are
recommended to carry out their own benchmarks to assess the most suitable
configuration for their requirements.
ΓòÉΓòÉΓòÉ 13.2.4. Disk space ΓòÉΓòÉΓòÉ
The requirements stated in this section are for the operating system, swap
space, and print spool jobs. They do not consider space required for extra
applications and data.
Although the maximum space required for OS/2 installation is 27.6MB plus swap
space, the minimum installation can be as little as 12.7MB (no DOS or Windows
support), 14.6MB (DOS, but no Windows support) and 16.9MB (DOS and Windows
support). These are taken from the cumulative total in the selective install
option; the total in each of these scenarios can be lower still by eliminating
selected files after installation. Typical scenarios will require less than
20MB and sometimes only 15MB.
The decision of whether to install certain components can make a large
difference to the space taken: WIN-OS/2 requires 3MB, Productivity applications
1.3MB, tools and utilities 3.6MB and games 0.8MB. The optional systems
utilities (eg BACKUP, ATTRIB, TREE, RECOVER, SORT), which are often removed
after installation on both OS/2 and DOS machines, take up 1.2MB.
The amount required for swap space will vary according to system load. The
system allocates a minimal swap file on loading; this defaults to a figure
based on the physical installed memory (the Information and Planning Guide has
a table with the detailed figures), for example, a 6MB swap file for a system
with 4MB of memory, a 4MB swap file for an 8MB machine. The figure can be
modified by the user at installation time, or later by modifying the SWAPPATH
parameter in CONFIG.SYS. The installation program also allows the user to set
the location of the SWAPPATH to a different partition. This can be a good idea
if the main partition is 30MB or less.
If you are choosing the type of machines to use as OS/2 machines, remember that
for any environment that uses virtual memory (swapping to disk to create more
memory), a fast disk is recommended. This is an important factor, especially
for those who expect to switch frequently and rapidly among a large number of
concurrent tasks.
Some figures in the industry have criticised the amount of space taken by OS/2
2.0, but there is always a cost associated with high function. In fact, if you
consider what OS/2 offers:
o a full DOS environment
o a complete Windows environment
o a copy of the OS/2 kernel and system, with compatibility for both 16- and
32-bit applications
o a font manager for both OS/2 and Windows (ATM), plus associated fonts
o a series of utilities, including a file search tool, a charting package, and
a personal organiser
o an object-oriented graphical shell
and then compare the likely disk space required to assemble all this function
under either DOS or Windows (here are some suggested equivalents):
o DOS version 5.0
o Windows 3.0 or 3.1
o ATM for Windows
o (For example) XTree Gold, Micrografx Charisma, and Polaris Packrat
o Norton Desktop for Windows
then it is likely you have taken at least as much space (and probably more)
than OS/2 2.0. (And that's ignoring the extra monetary cost of acquiring these
separate third party applications.)
Furthermore, the differences between Windows 3.1 and OS/2 2.0 in disk space
are exaggerated. Although Windows will nearly always take less for the base
installation, you can see from the above figures that OS/2 2.0 can come within
3 or 4MB of the Windows total. Moreover, the figures quoted by many people do
not mention the fact that if you choose, during Windows installation, to have
a permanent swap file (chosen by many Windows users to gain acceptable
performance), the default is to take 50% of the free space on your partition.
This can result in an overall disk usage (system plus swapper) of close to
OS/2's and sometimes more (dependent on the size of the partition). OS/2
allows detailed and granular control over what is installed, so it is at least
easy to know what your likely requirements are.
Furthermore, many newer applications take large amounts of disk space anyway.
A full installation of Word for Windows version 2.0 takes up to 15Mb of disk
space. This puts the requirements for the operating system into some
perspective.
For those concerned about disk space in general, data compression tools such
as Stacker, which are available on DOS, are under development for OS/2. Stac
Electronics have announced their intention to produce an OS/2 version of
Stacker, which will be available before the end of 1992. Other vendors are
producing OS/2 disk compression tools, which are expected to ship in 1992.
ΓòÉΓòÉΓòÉ 13.2.5. Performance considerations ΓòÉΓòÉΓòÉ
IBM's performance aims for OS/2 2.0 are as follows:
o Close to DOS for single tasking DOS applications
o Close to Windows 3.x for single tasking Windows applications
o Superior to Windows for multi-tasking
o Equivalent to or better than OS/2 1.3
It is very important to understand that achieving these aims is subject to the
obvious limits on comparing single tasking performance:
o DOS applications which are processor-intensive, or require continual
servicing of interrupts, are always going to perform better in DOS where
they do not have to share the CPU with other processes. However, despite
this, there is little performance loss for most DOS applications in a single
tasking scenario in a full screen DOS session. In a windowed session, screen
scrolling and update will be affected by runnning the application within a
window, and the extra virtualisation that needs to occur. This will
particularly affect applications running in graphics mode. If higher
performance is required, switch to full screen (the Alt-Home toggle allows
flexibility: use full screen most of the time for maximum performance, but
switch to windowed when interaction with the rest of the system (eg
clipboard) is needed. On the other hand, DOS applications that are disk and
I/O-intensive (such as database programs) can perform as much as 200-300%
faster, due to the superior caching in the OS/2 FAT system, or using HPFS
(see Enhanced FAT ). As most applications are a mix of disk and processor
operations, comparisons will differ according to the application chosen.
o Although for Windows applications, single tasking scenarios may be between 5
and 20% slower, this is hardly the best basis on which to compare
performance (since Windows is supposed to be a multi-tasking environment as
well). The differences mainly relate to application load time (usually
caused by the fact that the Windows application often loads into a separate
VDM, and then loads its own instance of WIN-OS/2. (A real comparison would
be to add the time to load Windows under DOS to the load time of the Windows
application, and compare it to the total under OS/2 2.0). Running the
application in a Full Screen WIN-OS/2 session rather than Seamless sometimes
yields better performance.
o In fact, DOS applications often run faster under OS/2 2.0 than under Windows
3.1, particularly disk-intensive applications, due to the superior FAT
implementation (see above).
o When considering multiple application scenarios, OS/2 shows its superiority.
Even running two applications together can show a big difference between
OS/2 2.0 and Windows 3.1. Try, for example, formatting a diskette from the
DOS prompt while running another application under Windows 3.1, and compare
the operation in OS/2 2.0. In Windows, if the format operation is in
foreground, it can starve the background process of processor time, and if
put to background, may scarcely progress at all. Under OS/2 2.0 the share of
processor load is much more even. This is hardly a heavy processing load.
Another illustrative scenario comes from the testing of National Software
Testing Laboratories (NSTL), an independent testing and evaluation
organisation: to load MS Word for Windows on a PS/2 Model 57 with nothing
else running takes 7.2 seconds with Windows 3.1 and 9.3 seconds with OS/2
2.0. If you do the same load with an XCOPY in the background, Windows load
time jumps to 41.1 seconds, compared with 15.3 seconds for OS/2. When more
than one task is being done, OS/2's performance advantage becomes evident.
Because of OS/2's superior multi-tasking, it can run background tasks, such
as file copying, communications, or spreadsheet recalculation, with no
visible impact on foreground work. With Windows, the cursor movement can
lag behind the mouse movement, and displaying of characters can lag behind
keyboarding to the point where system becomes almost unusable until the
background job is done.
Benchmarks from some sources are misleading, and are easily skewed by the
choice of scenario. The best guide is to run your own, to simulate your own
usage.
ΓòÉΓòÉΓòÉ 13.2.6. Tuning hints ΓòÉΓòÉΓòÉ
When considering overall performance, there are many variables, including how
balanced a processing load you want to achieve, or whether you want to give one
process as much CPU as possible. Therefore hints can only be generic, and must
be considered in the light of specific application requirements. Nevertheless,
here are a few basic ideas. More are contained in the chapter on "Optimising
Performance" in the OS/2 2.0 Installation and Planning Guide.
o To conserve OS/2 system resources and reduce memory requirements:
- close applications when they are not going to be used again.
- close folders if they are not needed.
- move commonly used functions out of folders and to the desktop, and close
the folder that contained the object.
- However, be careful not to overload the desktop - keep only as many
objects as you really need
o If certain applications are always used, put them in the Startup folder.
This will increase boot time but have everything ready to run
o Pre-initialising the SWAPPER.DAT file at boot time will help if a certain
group of applications are always loaded. The setting can be made in the
SWAPPATH parameter in CONFIG.SYS. You should be careful to observe swap
growth beforehand, and not set the initial swapper too large, lest you have
a detrimental effect.
o The cache sizes for FAT and HPFS can improve performance if increased.
Experimentation is the best way to discover the right results for your
configuration
o Set the system path statements (PATH and LIBPATH especially) based on usage
patterns, so that applications are quicker to load.
o Turn off public clipboard and DDE if sharing between Windows and OS/2
applications is not required
o Load Windows programs into a single WIN-OS/2 session, except those that
require greater protection. Ensure that the DPMI_MEMORY_LIMIT is set
appropriately
o If XMS, EMS and DPMI memory are not required (as is the case for many DOS
applications), set them to zero in DOS Settings
o DOS Settings parameters can have substantial effect on relative performance
of individual applications, and on their effect on others when running in
the background. See DOS Settings and Version 2.0 Volume 2: DOS and Windows
Environment (GG24-3731-00). Remember that many applications require little
attention when in background, as they are usually waiting for input, and can
therefore safely be given little CPU.
ΓòÉΓòÉΓòÉ 13.3. Further reference materials ΓòÉΓòÉΓòÉ
Here are some useful publications on OS/2 2.0 that are either already available
or about to be published:
ΓòÉΓòÉΓòÉ 13.3.1. IBM ITSC OS/2 2.0 Technical Compendium ("Red Books") ΓòÉΓòÉΓòÉ
This is a detailed and comprehensive description of OS/2 2.0 in five volumes,
published by the IBM International Technical Support Center in Boca Raton,
Florida (the same location as the development laboratory for OS/2 2.0). It is
essential reading for anyone needing to understand OS/2 2.0 in depth. This
guide has borrowed much material from the Red Books. They can be ordered
together, as OS/2 Technical Compendium (GBOF-2254), or separately, as follows:
Volume 1: Control Program (GG24-3730-00)
Volume 2: DOS and Windows Environment (GG24-3731-00)
Volume 3: Presentation Manager (GG24-3732-00).
Volume 4: Application Development (GG24-3774-00)
Volume 5: Print Subsystem (GG24-3775-00)
Another important Red Book is OS/2 Remote Installation and Maintenance
(GG24-3780-00). This contains practical instructions on how to install OS/2
across a LAN, discussing the various approaches. It will be supplemented, by
the end of 1992, by two other books:
Automated CID Installation of OS/2 V2.0 (GG24-3783)
Automated CID Install of ES 1.0, NTS, LS (GG24-3781)
Other red books may be of interest. Here is a selection of some of the ones
covering OS/2 and its extensions:
GG24-3875-00 LAN SERVER 2.0 NEW FUNCTIONS AND FEATURES
GG24-3890-00 NETWARE FROM IBM: NETWORK PROTOCOLS & STANDARDS
GG24-3794-00 EXTENDED SERVICES FOR OS/2 DATABASE MGR NEW FEATURES
GG24-3781-00 AUTOMATED INSTALL FOR CID ENABLED EXT SERVICES...
GG24-3580-01 DEVELOPING A CUA WORKPLACE APPLICATION
ZZ81-0295-00 EVALUATION OF OS/2 APPLICATION DEVELOPMENT TOOLS
GG24-3641-01 PRACTICAL INTRO TO OBJECT-ORIENTED PROGRAMMING
GG24-3822-00 MIGRATING FROM A DOS/WINDOWS ENVIRONMENT TO OS/2
GG24-3749-00 MULTIMEDIA APPLICATION ENABLERS & PS/2 ULTIMEDIA
GG24-3653-01 IBM PERSONAL SYSTEM/2 MULTIMEDIA FUNDAMENTALS
Copies can be ordered through IBM via the publication numbers in parentheses.
ΓòÉΓòÉΓòÉ 13.3.2. The OS/2 Developer (previously Personal Systems Developer) ΓòÉΓòÉΓòÉ
This is a quarterly publication from IBM's US Developer Assistance Program
(DAP). Subscriptions can be made direct with the publishers in the US. Contact
your local IBM office for details. Its publication number is G362-0001.
The OS/2 Developer contains many articles on a wide variety of OS/2 topics, and
there have been many articles on OS/2 2.0, and on the system extensions like
Database Manager and LAN Server, as well as material on OS/2 applications and
development tools.
ΓòÉΓòÉΓòÉ 13.3.3. Personal Systems Technical Solutions ΓòÉΓòÉΓòÉ
This publication comes from the Personal Systems Competency Center in Dallas,
USA. It covers both hardware and software, and contains many useful articles on
OS/2 2.0. It is published quarterly. The publication number is different for
each issue, but all are of the type G325-50xx-00, where xx is a two digit
number. Issues 5012, 5014, 5015, 5016 and 5017 all contain useful articles on
OS/2 2.0
ΓòÉΓòÉΓòÉ 13.3.4. OS/2 White Papers ΓòÉΓòÉΓòÉ
These papers were first issued by IBM in April 1991, and a second set appeared
in January 1992. They are an excellent guide to IBM's OS/2 strategy and future
product directions. They include:
o OS/2 2.0 Considerations: an excellent guide to OS/2 2.0's features, market
positioning, application migration, and future directions (reprinted in the
Personal Systems Developer Summer 1991 issue). This guide makes use of some
of the material in this paper.
o OS/2 LAN Server: a summary of current LAN offerings and future directions.
o OS/2 System Performance Management: an overview of current OS/2 and LAN
Server parameters and tuning facilities as well as future directions.
o OS/2 System Management: a good overview of current IBM SAA SystemView
facilities in OS/2 environments and future directions.
o OS/2 Database Manager Highlights and Directions: an overview of current
database offerings and future directions.
o OS/2 Communications Manager Highlights and Direction: a detailed overview of
Communications Manager function.
o OS/2 Performance Considerations: a guide to some of the issues involved in
tuning performance for OS/2 2.0
o OS/2 2.0 Windows environment: an explanation of how the WIN-OS/2 environment
is architected, and what benefits the environment has versus Windows 3.x
o OS/2 LAN Server Positioning: a guide to the relative strengths and
weaknesses of LAN Server versus Microsoft LAN Manager 2.0 and Novell NetWare
3.11
o OS/2 LAN Server Migration: how to move both clients and servers to OS/2 LAN
Server 2.0 from various previous IBM LAN products.
o OS/2: The Bigger Picture: an overview of IBM's OS/2 strategy and future
directions
o Upgrading to OS/2 2.0: a review of the various options in upgrading from
DOS, Windows or OS/2 1.3 to OS/2 2.0, and what is required for each
migration path
o Getting Started with the OS/2 Workplace Shell: a brief introduction to the
capabilities of the Workplace Shell. This is worth a read before starting on
the shell for the first time
o Client-Server Computing: an overview of the various IBM products that
address the client server environment, including Extended Services for OS/2
and OS/2 LAN Server
o OS/2 2.0: the Development Platform of Choice: reasons why OS/2 2.0 is an
excellent target for developers, including a review of the range of various
development tools available
The White Papers can be obtained from your IBM representative. They are on the
IBM MKTTOOLS disk as WPAPERS and WPAPERS2 packages. They can be copied and
distributed to anyone who wants to understand about OS/2.
ΓòÉΓòÉΓòÉ 13.3.5. IBM OS/2 Information ΓòÉΓòÉΓòÉ
IBM has published a variety of brochures and information about OS/2. Here is a
selection, with the publication numbers. These can be obtained from your
dealer or IBM representative. Please note the following list is specific to
those issued in Europe. Local publication numbers may vary, and some brochures
may not be available in all countries. Contact your local IBM representative
for a list relating to your country.
ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 11. OS/2 product information Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Γöé IBM OS/2 V2.0 Product Informa- Γöé G 511 Γöé Γöé
Γöé Γöé tion Γöé 1545-01 Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Γöé Extended Services for OS/2 Γöé G 511 Γöé Γöé
Γöé Γöé Spec sheet Γöé 1546 Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Γöé OS/2 Local Area Network Server Γöé G 511 Γöé Γöé
Γöé Γöé 2.0 Spec sheet Γöé 1554 Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Γöé OS/2 2.0 Decision Maker's Bro- Γöé G 511 Γöé Γöé
Γöé Γöé chure Γöé 1548 Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Γöé The OS/2 partnership Γöé G 511 Γöé Γöé
Γöé Γöé Γöé 1738 Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Γöé OS/2 - The Customer's Choice Γöé G 511 Γöé Γöé
Γöé Γöé Γöé 1739 Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Γöé The New OS/2: Wouldn't it be Γöé G U20 Γöé Γöé
Γöé Γöé great if... Γöé 2020 Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
ΓòÉΓòÉΓòÉ 13.3.6. IBM OS/2 Applications Solutions Directory ΓòÉΓòÉΓòÉ
This is a guide, published in the US, listing most of the applications
available for OS/2 today. There are thousands to choose from! The main guide
is orderable through IBM as G362-0002-02, and there is a supplement of 32-bit
applications (G362-0029) which are either in development or already shipping.
ΓòÉΓòÉΓòÉ 13.3.7. CUA Vision materials ΓòÉΓòÉΓòÉ
This is a video and a companion booklet outlining IBM's vision for the way user
interfaces will develop. The booklet includes a demonstration diskette with a
graphical demonstration of the principles discussed. Both the video and the
diskette offer a fascinating insight into the principles behind the OS/2
Workplace Shell, which embodies the first stages of the vision, and into where
the Workplace Shell may be headed in future.
The video is orderable as GV26-1004-00 (VHS PAL) or GV26-1003-00 (VHS NTSC) and
the booklet as G242-0215-00.
ΓòÉΓòÉΓòÉ 13.3.8. OS/2 in the Corporate Environment ΓòÉΓòÉΓòÉ
This is a short book published by Intelligent Environments Ltd, one of the
leading vendors of OS/2 developement tools. It is an independent view of where
OS/2 fits in the corporate computing world, including specific examples of
where customers are implementing client-server solutions using OS/2 today.
Contact Intelligent Environments for details. They are based at:
Intelligent Environments Europe Ltd., Intelligent Environments Inc.
Crystal house 2 Highwood Drive
PO Box 51 Tewkesbury
Sunbury-on-Thames MA 01876
Middlesex USA
TW16 7UL
United Kingdom
Tel: +44 (0)932 772266 Tel: +1 508 640 1080
Fax: +44 (0)932 771499 Fax: +1 508 640 1090
ΓòÉΓòÉΓòÉ 13.3.9. OS/2 Notebook ΓòÉΓòÉΓòÉ
This is a book from Microsoft Press, edited by Dick Conklin, who is the editor
of the Personal Systems Developer, containing the best of articles from that
publication. It includes a wide range of articles on OS/2 2.0 and its
extensions like Extended Services and OS/2 LAN Server. Its ISBN number is
1-55615-316-3.
ΓòÉΓòÉΓòÉ 13.3.10. The Design of OS/2 ΓòÉΓòÉΓòÉ
This book is co-written by Mike Kogan, one of the OS/2 2.0 System Architects,
and H.M. Deitel. It is published by Addison-Wesley (ISBN 0-201-54889-5). The
following paragraph is from the publisher's abstract:
" The primary goal of The Design Of OS/2 is to provide insights into the
design decisions and philosophy of the OS/2 operating system. It
discusses the motivation, architecture, and realization of OS/2 in the
personal computing marketplace. The design of the major components of
OS/2 are described in terms of their API architecture, internal data
structures, and algorithms. Each area focuses on bridging operating
systems theory to the realization of the design and implementation of
OS/2. Where it is significant, an objective comparison of the technical
aspects of OS/2 and other operating environments is provided. A key
thrust is to describe the evolution of personal computer operating systems
from DOS through 16-bit OS/2 and 32-bit OS/2. "
ΓòÉΓòÉΓòÉ 13.3.11. Other OS/2 Books ΓòÉΓòÉΓòÉ
There are a variety of books published on OS/2, including many new titles for
OS/2 2.0. Here are a few of the titles:
o Using OS/2 by Barry Nance and Greg Chicares, from Que books (ISBN
0-88022-863-6)
o Now that I have OS/2 2.0 on my Desk - What do I do next? by Stephen Levenson
and Eli Hertz, published by Van Nostrand Reinhold (ISBN 0-442-01227-6)
o Inside OS/2 2.0, by Mark Minasi, John W. Little, Marlene Semple and Bill
Camarda, from New Riders Publishing (ISBN 1-56205-045-1)
o OS/2 2.0 Quick Reference, by Barry Nance, from Que books (ISBN
1-56529-068-2)
o Stepping Up To OS/2 2.0, by Robert Albrecht and Michael Plura, from Abacus
(ISBN 1-55755-160-X)
o OS/2 2.0 Complete, by Peter Franken, from Abacus (ISBN 1-55755-157-X)
o Integrating Applications with OS/2 2.0, by William Zach, from Van Nostrand
Reinhold (ISBN 0-44201-234-9)
o Client-Server Programming with OS/2 2.0 by Bob Orfali and Dan Harkey, from
Van Nostrand Reinhold (ISBN 0 442-01219-5)
o Writing OS/2 Device Drivers in C, by Steve Mastrianni, from Van Nostrand
Reinhold (ISBN 0 442-01141-5)
o OS/2 Presentation Manager GPI, by Graham Winn, from Van Nostrand Reinhold
(ISBN 0-442-00468-0)
o Learning to Program OS/2 2.0 PM by Example, by Stephen A. Knight, from Van
Nostrand Reinhold (ISBN 0-442-01292-6)
o OS/2 Application Development Tools by Brian Proffit, from Premier Publishing
(ISBN 1-881899-00-4)
o Converting Applications to OS/2, by David Moskowitz et al, from Brady Press
(ISBN 0-13-171943-2)
o OS/2 2.0: The Usable, Portable Guide, by John Haber and Herbert R. Haber,
from Usable Portable Publications Inc., (ISBN 0-945965-27-4)
At the time of writing, four other books were about to made available. ISBN
numbers were not obtainable, but IBM order numbers are supplied here:
G362-0014 THE OS/2 2.0 USER'S GUIDE FOR THE WORKPLACE SHELL by Maria Tyne
from Computer Information Associates,
G362-0010 THE COBOL PRESENTATION MANAGER PROGRAMMING GUIDE by David M.Dill
Published by Van Nostrand Reinhold
G362-0012 COMPREHENSIVE PERFORMANCE FOR THE OS/2 2.0 DATABASE MANAGER by
Bruce Tate, Tim Malkemus, and Terry Gray (IBM, Austin, TX).
Published by Van Nostrand Reinhold
G362-0013 C PROGRAMMING IN THE OS/2 2.0 ENVIRONMENT by V. Mitra Gopaul.
Published by Van Nostrand Reinhold
The book by Barry Nance sold its first print run in a few weeks, and moved
into the top ten computer titles. Even Steve Mastrianni's book, which
addresses a more specific audience, is already into its first reprint. In
October, it was announced that the Barnes and Noble computer book bestseller
list contained three of the above OS/2 books, for 17 consecutive weeks. The
books were the ones by Orfali and Harkey, Minasi et al., and Levenson and
Hertz. Sales of books are often regarded as one of the signs of a flourishing
platform (witness the sales in books about Lotus 1-2-3, WordPerfect, and
Windows). This indicator also shows the amount of interest there is now in
OS/2.
In fact, OS/2 books are not only appearing in English. An indicator of the
success of OS/2 is that books in national languages are appearing, a testimony
not only to the strength of OS/2 in the countries involved, but also of its
widespread appeal (books in English would usually be considered to reach a
wider market, especially among computer experts, but OS/2's appeal to end
users means a viable market at which to target books in the native language.)
Here is a list of some OS/2 books written and published in Germany:
"OS/2 2.0, Grundlagen und Praxis"
von Hans Fremuth (mit Vorwort von H. Kahl) im tewi Verlag
(in deutscher Sprache)
ISBN 3-89362-212-8
"OS/2 2.0, Das Kompendium"
von Olaf Koch, Norbert Meder und Peter Scheuber (mit Beitrugen
von Whittle und Pignatelli) im Verlag Markt & Technik
(in deutscher Sprache)
ISBN 3-87791-302-2
"OS/2 - 2.0, Der Data Becker Fuhrer"
im Verlag DATA BECKER
(in deutscher Sprache)
ISBN 3-89011-637-X
"OS/2 Version 2 deutsch, Das Data Becker Handbuch"
von Peter Franken im Verlag DATA BECKER
(in deutscher Sprache)
ISBN 3-89011-505-5
"Von DOS und Windows nach OS/2 2.0, Tips & Tricks"
von Robert M. Albrecht und Michael Plura im Verlag DATA BECKER
(in deutscher Sprache)
ISBN 3-89011-543-8
"Schnell Anleitung OS/2 Version 2 deutsch"
im Verlag DATA BECKER
(in deutscher Sprache)
ISBN 3-89011-658-2
"QuickStart OS/2 2.0, Der Einsteig in 20 Schritten"
von Harald Babiel im SYBEX Verlag
(in deutscher Sprache)
ISBN 3-88745-859-1
ΓòÉΓòÉΓòÉ 13.3.12. OS/2 Monthly ΓòÉΓòÉΓòÉ
This is an independent magazine dedicated to news, views and technical
information about OS/2. It is published by:
JDS Publishing
PO Box 4351
Highland Park
NJ 08904
USA
Tel: +1-908-247-0952
ΓòÉΓòÉΓòÉ 13.3.13. Moving to the Workplace Shell video ΓòÉΓòÉΓòÉ
This video (part number 41G5097) guides the new user of OS/2 2.0 through the
Workplace Shell. It is meant to be a light and enjoyable introduction to the
capabilities of the shell, to encourage you to explore for yourself.
ΓòÉΓòÉΓòÉ 13.3.14. OS/2 Frequently Asked Questions (FAQ) ΓòÉΓòÉΓòÉ
This document, maintained by Timothy F. Sipples (sip1@ellis.uchicago.edu), is
an excellent basic reference to many common questions and answers about OS/2.
It is available in electronic form on most of the bulletin board systems
mentioned in OS/2 Bulletin Board Systems It is just one example of many of the
excellent reference materials and tools made available by OS/2 enthusiasts
around the world, on bulletin board systems.
ΓòÉΓòÉΓòÉ 13.3.15. OS/2 2.0 Information and Planning Guide ΓòÉΓòÉΓòÉ
This publication (G326-0160-00) gives an overview of OS/2 2.0 function, as well
as assistance in estimating memory and disk space requirements. It is
recommended for anyone planning to install OS/2 2.0 on a number of machines.
Guides are also available for Extended Services for OS/2 (G326-0161-00) and
OS/2 LAN Server (G326-0162-00).
ΓòÉΓòÉΓòÉ 13.4. OS/2 Bulletin Board Systems ΓòÉΓòÉΓòÉ
Bulletin board systems (BBS) are often a good way of getting information about
OS/2, whether technical support, news or useful utilities. In many countries,
IBM runs a BBS as a means of customer support; but there are also many other
BBSs run by OS/2 enthusiasts. Here is a list of some of the BBSs:
ΓòÉΓòÉΓòÉ 13.4.1. IBM Bulletin Boards ΓòÉΓòÉΓòÉ
Not all countries operate a BBS. Here is a list of some of the countries that
do, with the connection details:
IBM Sweden
Phone: 46+8-7932200 Dealers 46+8-7934222 Customers
Lines: 10 Lines
Speed: 1200-14400 Connection rate (V.32 and MNP)
10 USR DS 14400 modems
********************************************************
IBM Austria
IBM Bulletin Board System Austria:
Phone: 043-222-21145-6600
Speed: 9600
Lines: 2
********************************************************
IBM Germany
IBM Bulletin Board System Germany
Fidonet : 2:241/7411.0@FIDONET
Phone : 049-711-785-7777
********************************************************
IBM Canada
Canadian Sofware Support Center, specializing in OS/2 and OS/2 support.
Vancouver - 604-664-6464 Montreal - 514-938-3122
Toronto - 416-946-4244 or 4255
********************************************************
IBM Switzerland
Name: IBM-BBS HITLINE Communications
Phone: 0041 56 321 800 (16 lines/14000 Baud)
ISDN: 0041 56 320 589 (1 line/128kBits/s)
*********************************************************
IBM Denmark
Name: IBM OS/2 BBS
Phone: + 45 42 88 72 22
Lines: 3 lines
Speed: 9600 (V32 and MNP)
Location: Lyngby, Denmark
********************************************************
IBM Belgium
International BBS name : The IBM Belgium BBS
In country BBS name : End-User Node.
Location: IBM Belgium s.a. J.F.Kennedylaan 2, B-1831 Diegem.
Modem number : 32-2-725.60.10
8 lines, up to 9600 bps, 8,n,1, V32 24/24
No MNP4 no MNP4.
********************************************************
IBM USA
IBM National Support Center BBS, located in Atlanta GA.
1-404-835-6600 => First available modem
1-404-835-6296 => First available Hayes Ultra
1-404-835-5300 => First available USR V.32bis with ASL
1-404-835-5578 => First available IBM 7855 model 10
********************************************************
IBM Finland
IBM OS/2 Bulletin Board System
Phone: +358-0-480 422
Speed: 9600, 8, n, 1
********************************************************
IBM Spain
Bulletin Board System IBM OS/2
Phone: 34 1 397 55 80 34 1 397 58 73
34 1 397 55 81 34 1 397 59 63
Speed: 9600, 8, n, 1
********************************************************
IBM UK
Phone: +44-(0)256-336655 (>12000 - V.32 MNP-5)
Lines: 15
********************************************************
IBM Israel
Phone: 049-711-785-7777
Additional Info: 2:241/7411.0@FIDONET
********************************************************
IBM Netherlands
Phone: +31 (0)20-6974757
Additional Info: Lines 8 Courier Dual Standard 14K4
********************************************************
IBM Norway
Phone: 47-2-999450
********************************************************
ISM South Africa
Phone: 27.11.224.2000
Info - Lines: 47 55 81
Speed: 9600,8,n,1 (V32 and MNP)
********************************************************
ΓòÉΓòÉΓòÉ 13.4.2. Other BBSs ΓòÉΓòÉΓòÉ
The following information was provided by the US OS/2 Support Line:
O S / 2 B B S ' s A C R O S S T H E W O R L D
-----------------------------------------------------
This list is a compilation of OS/2 BBS's across the world. If you wish to
make an addition or correction to this list, please send the information to
the following (as netmail or logged onto the BBS itself):
BBS : LiveNet, 1:170/110@fidonet, (918) 481-5715
Location : Tulsa, OK, USA
Sysop : Dave Fisher
This list is distributed to many FidoNet nodes found in this OS/2 BBS listing
via the Fernwood distribution system. All BBS's listed are in alphabetical
order by country, and then by BBS name. Unless otherwise noted, all node
addresses are FidoNet.
A current list can always be file-requested from LiveNet as 'OS2WORLD'.
Enjoy!
Last Update: May 14, 1992
Legend: * : OS/2 is primary interest of board
F : Board is a FidoNet node
% : Entry is new or changed as of last list
-A : HST, MNP modem
-B : HST, MNP V.32 (and/or V.42) modem
-C : HST, MNP V.32bis/V.42bis modem
-D : MNP V.32/V.42bis modem
-E : MNP V.32 modem
USA BBS's show states, International BBS's show three letter country codes.
-----------------------------------------------------------------------------
Graham Stair 3M Australia +61-2-498-9184 Aus 9600-E * F
Ian Watson OZ-Share OS/2 BBS +61-7-398-3759 Aus 9600-E * F
Alan Salmon PC User's Group +61-6-259-1244 Aus 2400
Felix Tsang Programmer's BBS +61-2-875-1296 Aus 9600-E * F
Bill Bolton Software Tools Mail Exc +61-2-449-2618 Aus 9600-E * F
+61-2-449-9477 Aus 9600-E * F
John Della-Torre The Poet's Dilemma +61-2-804-6412 Aus 2400-E
Norbert Fuerst The Styrian OS/2 Jumbo +43-316-673237 Aus 9600-A * F
Danny Bruggeman Hellfire +32-2-7515203 Bel 9600-D * F
Bas Heijermans Moving Sound OS/2 BBS +32-3-3850748 Bel 9600-D * F
Benoit HUON Os/2 MANiA BELGIUM +32-2-3872021 Bel 9600-D * F
Tony Bearman Bear Garden (604) 533-1867 Can 9600-C * F
Chris Ange-Schultz Home Front BBS (514) 769-5174 Can 2400 * F
Peter Fitzsimmons RT Labs (416) 867-9663 Can 9600-B * F
Gerry Rozema The Idle Task (604) 273-5588 Can 14.4-B * F
Jerry Stevens The Locutory (613) 722-0489 Can 9600-D * F
Alec Herrmann The Nibble's Roost (604) 244-8009 Can 14.4-B * F
Kevin Lowey University of Saskatche (306) 966-4857 Can 14.4-C * F
Jorgen Ollgaard Josti-BBS +45-47-380120 Den 9600-C * F
+45-47-380524 Den 9600-C * F
Rene Carlsen OS/2 Task & FrontDoor H +45-98451070 Den 9600-A * F
Emmanuel Sandorfi Os/2 MANiA (Help Maximu +33-164-090460 Fra 9600-C * F
Romeo Bernreuther CCWN-BOX +49-7151-68434 Ger 14.4-B * F
Peter Plischka IBM Mailbox +49-201-210744 Ger 9600-C * F
+49-201-295181 Ger 9600-B * F
Juergen Berger JERRY'S OS/2-BBS +49-6134-26563 Ger 2400-A * F %
Oliver Lass LRZ-System +49-228-331214 Ger 2400 *
+49-228-334372 Ger 9600-D *
Oliver Schwabedissen MoonFlower +49-6145-31602 Ger 9600-C * F
Richard Clement OS/2 Express +49-6183-74270 Ger 9600-D * F
Harald Kipp OS/2 Point +49-234-9279222 Ger 9600-B * F
Michael Breukel PC Softbox OS/2 +49-6196-27799 Ger 2400 * F
Markus Noller Second Source +49-7191-56267 Ger 2400 * F
Kalle Braun Terrania City +49-228-317752 Ger 14.4-B F
Thomas Tegel The CAT +49-7971-72446 Ger 14.4-D * F %
Karlheinz Kissel The_File_Store +49-6106-22266 Ger 9600-C * F
Chris Leuder Zaphod BBS +49-228-262894 Ger 14.4-B F
+49-228-229147 Ger 2400 F
Joop Mellaart INFOBOARD +31-4752-6200 Hol 2400 * F
Marcel Stikkelman PC-Square +31-79-424107 Hol 14.4-C * F
Pasquale Cantiello FastForward BBS +39-823-812099 Ita 14.4-C * F
Luigi Ravina Italy Network +39-11-8180069 Ita 9600-A * F
Roberto Sonzogni Runnin' with The Devil +39-363-302798 Ita 9600-C * F
Dave Jones The TJD Support BBS +31-1720-38558 Net 9600-A *
Terje Slydahl PerlePorten +47-83-33003 Nor 9600-C * F
+47-83-33003 Nor 2400 * F
Alex Wyss Gepard's Oracle Zuerich +41-1-3637037 Swi 14.4-C * F
Michael Buenter MICS OS/2 Paradise +41-41-538607 Swi 9600-C * F
Ernesto Hagmann PC-Info +41-61-9412204 Swi 9600-C * F
Mike Gove MonuSci CBCS +44-454-633197 UK 9600-C * F
Phil Tuck The TJD Support BBS +44-535-665345 UK 9600-C *
+44-535-665345 UK 9600-A *
Patrick O'Riva AsmLang and OS/2 (408) 259-2223 CA 14.4-B * F
Steve Lesner Bullet BBS (203) 329-2972 CT 9600-B * F %
(203) 322-4135 CT 9600-B * F %
Jim Dailey Cajon Zone OS/2 (619) 588-6634 CA 9600-D * F
Bob Germer Capital City BBS (609) 386-1989 NJ 14.4-C * F
Dennis Conley Communitel OS/2 BBS (702) 399-0486 NV 14.4-C * F
Emmitt Dove Fernwood (203) 483-0348 CT 9600-C * F
(203) 481-7934 CT 14.4-B * F
Bill Cook GREATER CHICAGO Online! (708) 895-4042 IL 9600 * F
Bogie Bugsalewicz I CAN! BBS (312) 736-7434 IL 9600-C F
(312) 736-7388 IL 2400 F
n/a IBM National Support Ce (404) 835-6600 GA 2400
(404) 835-5300 GA 9600-C
Ed June Information Overload (404) 471-1549 GA 9600-A * F
James Chance Lee's Lounge (410) 721-9452 MD 14.4-B * F
Robert McA Live-Wire (214) 307-8119 TX 9600-B F
Dave Fisher LiveNet (918) 481-5715 OK 16.8-C * F
Chuck Gilmore Magnum BBS (805) 582-9306 CA 9600-C *
Joe Salemi Max's Doghouse (703) 548-7849 VA 2400-A * F
Paul Breedlove Multi-Net (503) 883-8197 OR 9600-C *
Ron Bemis Nibbles & Bytes (214) 231-3841 TX 9600-A F
Craig Swanson OS/2 Connection (619) 558-9475 CA 14.4-D * F
Pete Norloff OS/2 Shareware (703) 385-4325 VA 9600-C * F
(703) 385-0931 VA 9600-C * F
Brady Flowers Oberon Software (507) 388-1154 MN 14.4-C *
Unknown Omega-Point BBS (714) 963-8517 CA 2400
Paul Beverly PMSC OnLine Resource (803) 735-6101 SC 2400 * F
Louis F. Ursini Quantum Leap (215) 967-9018 PA 2400
Ken Rucker RucK's Place/2 (817) 485-8042 TX 14.4-C * F
Randy Edwards Socialism OnLine! (719) 392-7781 CO 9600-B * F
Ed Barboni System-2 RBBS (215) 631-0685 PA 9600-D F
(215) 584-1413 PA 9600-D F
Mark Lehrer The Akron Anomoly (216) 688-6383 OH 9600-C F
Bill Schnell The Asylum BBS (918) 832-1462 OK 9600-B * F
Felix Tang The Excelsior (203) 466-1826 CT 14.4-C * F
(203) 466-1892 CT 2400 * F
Bob Hatton The Monster BBS (908) 382-5671 NJ 9600-A *
Woody Sturges The OS/2 Woodmeister (314) 446-0016 MO 14.4-C * F
Troy Kraser The Other World (904) 893-2404 FL 9600-D F
Mark Wheeler The SandDollar (407) 784-4507 FL 9600-A * F
Art Fellner The Soldier's Bored (713) 437-2859 TX 9600-C * F
Bill Andrus The Systems Exchange (703) 323-7654 VA 9600-A * F
Unknown WSI BBS (901) 386-4712 TN 2400
------------------------------------------------------------------------------
ΓòÉΓòÉΓòÉ <hidden> ΓòÉΓòÉΓòÉ
In this document, the i386 and i486 processors will often be referred to as 386
and 486 respectively. Where discussion relates to 386 or 486 SX or DX models
specifically, terms such as 386SX will be used. Otherwise the terms will be
used to refer to any member of the 386 or 486 family as appropriate. The term
80X86 is sometimes used to denote the range of 32 bit processors currently
shipped by Intel (ie 386 and 486 together, but NOT the 80286).
ΓòÉΓòÉΓòÉ <hidden> ΓòÉΓòÉΓòÉ
Windows can either be hidden (the installed default), minimised to the desktop,
as happens in Windows 3.x and OS/2 1.3, or minimised to a Minimised Window
Viewer, according to the user's preference. This can be set on a per-object
basis.
ΓòÉΓòÉΓòÉ <hidden> ΓòÉΓòÉΓòÉ
See, for example, the benchmarks run by NSTL in their Software Digest Ratings
Report Volume 9, Number 4
ΓòÉΓòÉΓòÉ <hidden> ΓòÉΓòÉΓòÉ
The Microsoft document "Microsoft Windows/NT Operating System - An Overview"
confirms that "...OS/2 supports some MS-DOS programs requiring some
special-purpose, custom device drivers, whereas Windows NT does not. Examples
are 3270 emulators, fax boards, scanners and MIDI boards." (p13)
ΓòÉΓòÉΓòÉ <hidden> ΓòÉΓòÉΓòÉ
Quoted in Wall Street Journal, 6th August, 1992
ΓòÉΓòÉΓòÉ <hidden> ΓòÉΓòÉΓòÉ
Windows Magazine, October 1992, p16
ΓòÉΓòÉΓòÉ <hidden> ΓòÉΓòÉΓòÉ
See Microsoft's document entitled "Microsoft Windows NT Operating System"
ΓòÉΓòÉΓòÉ <hidden> ΓòÉΓòÉΓòÉ
SPA figures quoted in Windows Magazine, November 1992
ΓòÉΓòÉΓòÉ <hidden> ΓòÉΓòÉΓòÉ
Quoted in Windows Magazine, February 1992
ΓòÉΓòÉΓòÉ <hidden> ΓòÉΓòÉΓòÉ
Quoted in Computing (UK), April 23, 1992
ΓòÉΓòÉΓòÉ <hidden> ΓòÉΓòÉΓòÉ
Quoted in PC Week, March 30, 1992 - p131
ΓòÉΓòÉΓòÉ <hidden> ΓòÉΓòÉΓòÉ
Quoted in PC Week, March 30, 1992 - p132
ΓòÉΓòÉΓòÉ <hidden> ΓòÉΓòÉΓòÉ
Reported in Computergram Online Issue #1952 - 29th June 1992
ΓòÉΓòÉΓòÉ <hidden> ΓòÉΓòÉΓòÉ
Quoted in PC Week, March 30, 1992 - p132
ΓòÉΓòÉΓòÉ <hidden> ΓòÉΓòÉΓòÉ
Reported in Computergram Online Issue #1949 - 24th June 1992
ΓòÉΓòÉΓòÉ <hidden> ΓòÉΓòÉΓòÉ
Article in Infoworld, September 14th, 1992 - p51
ΓòÉΓòÉΓòÉ <hidden> ΓòÉΓòÉΓòÉ
Though how this "operating system" is able to load without DOS, has not been
made clear by Microsoft.
ΓòÉΓòÉΓòÉ <hidden> ΓòÉΓòÉΓòÉ
Quoted in PC Week, July 29, 1991 - p111
ΓòÉΓòÉΓòÉ <hidden> ΓòÉΓòÉΓòÉ
The report in PC Magazine, May 12, 1992 - p32, said : "When CEO Bill Gates was
asked what it would take for Microsoft to write for OS/2, he said 2 million
copies in the first year - but they'll sell less than 10% of that"
ΓòÉΓòÉΓòÉ <hidden> ΓòÉΓòÉΓòÉ
MDI means that multiple child windows are contained within the bounds of the
parent window, and no child window can be sized beyond the bounds of the
parent. The Windows 3.1 File Manager and the behaviour of the directory windows
within it, provide an example of MDI.
ΓòÉΓòÉΓòÉ <hidden> ΓòÉΓòÉΓòÉ
Modeless (as opposed to modal) refers to the behaviour of child windows in a
GUI. Modal windows have to be closed or the dialog within them completed
before the parent window can be accessed. They tend to enforce a particular
pattern of progressing through several windows (an example is in the use of
error dialogs, which tend to be modal.) Modeless means that the user may move
from the child window back to the parent without closing intermediate windows
or dialogs. An example is the "Find" dialog in the OS/2 System Editor.
ΓòÉΓòÉΓòÉ <hidden> ΓòÉΓòÉΓòÉ
CID stands for Configuration, Installation, Distribution - see Configuration,
Installation, Distribution (CID)
ΓòÉΓòÉΓòÉ <hidden> ΓòÉΓòÉΓòÉ
See PC Week July 27, 1992 - page 1. The lack of support for DOS device drivers
is confirmed in the Microsoft document "Microsoft Windows NT Operating System".
ΓòÉΓòÉΓòÉ <hidden> ΓòÉΓòÉΓòÉ
Gartner Group - Personal Computer Research Notes, P-230-853, July 31, 1992