capabilities, which are not available in Microsoft Corp.'s Windows.
"We're absolutely convinced that Windows would crash the system under
what we're trying to do," he said.
Under Windows, for example, a user could not send an X-ray file to the
printer from the mainframe without having to halt other cycles and pre-
empt other operations. With OS/2, all of these tasks can run
simultaneously.
Since many of the doctors have had little computer training, the
database had to be designed for anyone to use, with a user-friendly
interface, according to Greenwald. "The [OS/2] graphical interface is
intuitive to them," he said.
------------------
Sales of OS/2 Apps Lag Behind DOS, Windows Offerings
From PC Week for June 8, 1992 by Jenny Sanders
For sales of OS/2 applications, there is nowhere to go but up.
Applications for OS/2 have been greatly outsold by those running on
other platforms, according to figures compiled by Software Publishers
Association in Washington. In 1991, OS/2 captured only 0.9 percent of
the revenue generated by application software sales.
While OS/2 has managed to capture only a small sliver of software
application sales in the past three years, the percentage of
applications sold that run under graphical user interfaces (GUIs) has
increased. GUI-based applications (those running on OS/2, Macs and
Windows) collectively captured a much larger share of revenue, rising to
35.6 percent in 1991 from 19.7 percent in 1990. This overall shift to
GUI-based applications may help give OS/2 2.0 the boost it needs.
Throughout 1991, the platform contributing the most to the growth of
GUI-based applications was Windows, which captured 20.2 percent of
sales, up from 5.8 percent in 1990. Sales of DOS-based applications
increased in 1991, but their share relative to other desktop platforms
diminished from 73.1 percent to 62.1 percent.
------------------
OS/2 Tools Put Powerful Ideas Into Fragile Package
From PC Week for June 8, 1992 by Peter Coffee
To be considered as more than a multitasking utility for DOS and Windows
applications, OS/2 2.0 must offer unique system services that promptly
deliver meaningful benefits. This depends on powerful development tools,
an area in which IBM has historically taken a back seat to mainstream
tool makers such as Borland International Inc. and Microsoft Corp.
In launching OS/2 2.0, IBM has sought to accelerate developer acceptance
by offering C Developer's WorkSet/2 1.0, a suite of development aids
that includes IBM's C Set/2 1.0 compiler, the WorkFrame/2 1.0
development environment and Developer's Toolkit 2.0.
PC Week Labs found these offerings more impressive in concept, however,
than in implementation -- their potential has been handicapped by
excessive memory demands, a quirky user interface and slipshod example
code.
Because the core of the development process is the compiler, C Set/2 is
the foundation of the WorkSet/2 offering. The compiler enhances the
attractiveness of OS/2 2.0 to C-language developers.
C works well with OS/2 2.0, whose flat address space -- backed up by the
386 and 486 processors' transparent, hardware-based paged memory --
finally lets developers fully enjoy the elegance of the C language, in
striking contrast to the awkward memory segments of DOS or Windows.
Easing Migration
Developers will be pleased to find that the notoriously compromising
keywords of earlier PC-based generations of C, such as "near" and "far"
and "huge," are both unnecessary and unsupported under C Set/2. IBM has
defined a migration mode that minimizes the labor involved in bringing
existing code into OS/2 2.0. In this mode, these and many other keywords
are simply ignored, eliminating the need for tedious manual location and
correction.
C Set/2 also devotes considerable ingenuity to the transparent
integration of 16- and 32-bit code. The compiler automatically generates
all code required for functions to invoke each other, whether they were
compiled as 16- or 32-bit object code. A "thunk layer" converts 32-bit
calls to 16-bit calls, adjusting both parameters and addressing schemes
as needed. In keeping with the overall openness of OS/2, developers can
use C Set/2 to implement their own thunk layer for 16-bit dynamic link
libraries.
This simplicity in managing memory, and in combining old code with new,
will free developers' brain power for the new complexities of OS/2's
multithreading capabilities. Threads, or "lightweight processes," permit
a single application to work on several subtasks at once, using the
application's single pool of resources (such as memory and files). This
avoids the overhead of resource duplication required for full-strength
processes, those that are required to run several concurrent
applications.
Multithreaded programming requires considerable mastery, however, to
avoid several new kinds of programming errors. For example, the compiler
automatically generates code to force different threads to take turns
when using shared system resources. But if a function is called with
parameters that are pointers to data, this automatic safeguard is
disabled.
As shown in example code supplied with the compiler, the C language's
STRCPY (string copy) function does not serialize access to data; two
different threads using this function to modify a shared array of
characters may overlap their operations and produce a corrupted string
as an undesired hybrid result.
Issues such as these reveal the sharp edges of C. To avoid these
hazards, many C developers rely on the protection of third-party source-
code analysis programs, such as Gimpel Software's PC-Lint, to identify
potential problems with their code. The C Set/2 compiler reduces the
need for such utilities with extensive built-in diagnostics, invoked by
a slate of /K options ranging from /Ka+ (to enable warnings about
variable assignments that would cause a loss of numeric precision) to
/Kx+ (to warn of externall y declared variables that are never used).
When PC Week Labs enabled all the diagnostic messages, the compiler
produced a daunting list of descriptive and critical comments that made
for tedious but useful reading.
These began with specifications of precisely which file paths were being
used by INCLUDE statements, potentially preventing hours of frustrating
debugging in multiproject environments.
More complex diagnostics included tracking of the level of nesting in
conditional compilations, warning of default identifier initializations,
and (frequently voluminous) listings of functions and variables that
were defined but not referenced. The last situation is a common problem
when general-purpose header files are used without modification.
But despite these fancy new dance steps, OS/2 is the last to arrive at
the party, and it must perform to tunes that are already popular
favorites. Therefore, IBM has made the C Set/2 compiler compatible with
both ANSI X3.159-1989 and also with selected extensions from Microsoft C
6.0. A manual, the C Set/2 Migration Guide, provides a detailed
discussion of the incompatibilities between C Set/2 and prior PC-based
standards.
For example, the "volatile" data type from ANSI C is now reflected in
compiler semantics, where IBM's previous C/2 compiler supported this
keyword in syntax only. This opens the door to OS/2's expected use in
systems that interface with external devices, such as shop-floor
sensors, by restricting compiler assumptions during optimization.
An interesting sign of IBM's future ambitions for OS/2 appears in the
treatment of extended-precision, 80-bit real numbers. Under C Set/2,
"long double" variables use a 16-byte field with 6 unused bytes, as
opposed to a 10-byte field under Microsoft C 6.0. This change was
presumably made to align data objects on 64-bit boundaries, potentially
offering efficiency gains on next-generation RISC machines.
Similarly, zero-width bit fields in structures now force alignment on
32-bit boundaries rather than on 16-bit boundaries as under IBM's C/2.
The compiler's extraordinary suite of sophisticated optimizations --
including advanced techniques for optimized switch statements,
reorganized expressions and simplified algebra -- are aimed at speed and
are extravagant in their use of memory. This emphasis on speed at the
expense of space is a general theme of C Set/2.
In discussions with PC Week Labs, IBM's developers asserted that in the
virtual-memory environment of OS/2, worst-case memory consumption is no
longer an issue. Corporate developers, often hampered by tight budgets
for hardware upgrades, may vehemently disagree.
In PC Week Labs' tests with small benchmark programs, enabling
optimization produced slightly larger programs with about a 5 percent
edge in speed, but results will vary with the specific characteristics
of the program being developed.
Developers should also note that IBM's Presentation Manager (PM)
Debugger -- part of C Set/2 -- is predictably confused when optimization
is used, since the debugging information is generated before the
optimizations are performed, which could potentially fold, spindle and
mutilate program logic in ways that will prove an utter mystery to the
developer attempting to follow along from source code.
The complexity of C Set/2 also makes it a resource-intensive tool. The
compiler was tested on a 16MHz 386-based PS/2 Model 70-E61 with 10M
bytes of RAM and more than 3M bytes of free swap space, available for
swapping of memory contents to disk under the management of OS/2 2.0's
virtual memory engine. Despite these generous resources, the IBM tools
were unable to build the complex sample application MAHJONGG (113K bytes
of source code and 270K bytes of bit maps) from the application's
supplied Make file.
During this test, the project environment seemed alarmingly fragile,
interrupting compilations with spurious messages such as "Compilation
aborted by user," even when the machine was left undisturbed.
MAHJONGG and another sample application, PMLINES (a line-drawing program
also provided in the WorkSet/2 package), proved to be poor examples of
the features of WorkSet/2 or the capabilities of OS/2 2.0: PMLINES
ceased to draw in its window (or even to update it when the window was
re-exposed) when particular DOS applications were running in the
background, and MAHJONGG (when compiled manually rather than using the
Make file) was unable to execute. In fact, the program could not even
generate the debugging information offered by OS/2 2.0 through the
standard dialog box that appeared when the program crashed.
For developers who can give these tools the breathing room they demand,
however, OS/2 development will get a major boost toward an era of
cooperative applications with IBM's System Object Model (SOM), an open
architecture of object-oriented services.
SOM Bindings
One of the most significant features of WorkSet/2 is the supplied set of
SOM bindings for C. These bindings are header files that add object-
oriented facilities to standard C and also permit C programs to
interface in an object-oriented manner with modules written in other
languages.
IBM intends that SOM will give OS/2 developers a unique flexibility of
object-oriented development, with modules able to exploit the benefits
of inheritance and specialization, even if written in different
languages. The SOM bindings are applied by IBM's SOM Compiler, which is
actually a precompiler with a suite of code generators that's part of
the Developer's Toolkit included with WorkSet/2. The SOM Compiler takes
definition files, written in the C-like Object Interface Definition
Language, and produces the required header files, implementation
template and a language-neutral interface file.
IBM's goals for SOM emphasize minimizing maintenance, which may be the
greatest component of software costs over the lifetime of an
application. The System Object Model Guide and Reference states, "As a
rule of thumb, if you make changes to a SOM class that will not require
source code changes in client programs, the binary versions of those
programs also will not need to be recompiled."
This has long been a benefit of interpreted and semicompiled languages
such as Smalltalk and object-oriented dialects of LISP, but this is a
new capability for fully compiled languages, especially in mixed-
language environments.
An obvious question in the context of object-oriented development is,
What about C++? IBM representatives declined to comment on the
availability of an IBM C++ for OS/2, but Borland has announced a C++ for
OS/2 2.0. IBM noted that its C++ for the AIX operating system on the
RS/6000 platform is slated for imminent release, allowing that this
might suggest that an OS/2 C++ would be the next implementation on their
plate.
To manage the kind of complex project where these methods enabled by SOM
can best assist the developer, IBM offers the WorkFrame/2 environment.
This flexible foundation meets both the immediate need of supporting the
tools that developers are already using and the long-range need of
letting tool makers create powerful new productivity aids that
incorporate the features of the OS/2 platform.
WorkFrame/2 combines with C Set/2 to create a straightforward, project-
oriented environment in which the various files associated with an
application can readily be viewed as a group. Associations are
automatic: Double-clicking on a source-code file invokes an editor,
while the same action on an executable file runs the program.
WorkFrame/2, however, shows some unfinished edges. For example, file-
listing windows do not show the object-code or the executable files
produced by a compilation until the developer uses a manual Refresh
command. This should be automatic.
In addition, after an aborted compilation by PC Week Labs, WorkFrame/2
failed to enable the Close command for the associated monitor window,
though the Stop command remained available -- the opposite of what
should have taken place. This error occurred intermittently.
WorkFrame/2 also takes liberties with common graphical-interface
conventions, frequently resulting in the accidental selection of
multiple items when only one was desired; further, it accompanies many
actions with gratuitous warning beeps that quickly become annoying.
WorkFrame/2 is packaged with several sample projects, ranging from
simple utilities to elaborate graphics using multiple threads. Project
source code is well-explained and instructive, while the projects have
enough complexity to show off OS/2's project-management features. There
were flaws in the MAHJONGG and PMLINES applications, however, that bring
their educational value into question.
Initially, developers will enjoy the ease of mixing and matching their
own tools within WorkFrame/2. In particular, developers should look at
the Enhanced Editor on the OS/2 desktop. This may quickly replace
WorkFrame/2's WorkFrame Editor as the preferred tool of developers who
want a fully GUI-based editor. It combines Common User Access
convenience with some of the power found in programmable tools such as
IBM's mainframe-based XEDIT or Mansfield Software Group Inc.'s KEDIT.
Just over the horizon, however, are the huge productivity gains that
should result when tool makers exploit the multiple levels of APIs
(application programming interfaces) that are built into WorkFrame/2.
WorkFrame/2 defines a compiler API, for example, that permits easy
setting of third-party compiler options by means of Presentation Manager
dialog boxes. Watcom has WorkFrame/2 versions of its FORTRAN 77/386 and
C/386 compilers that support this API.
Interactive Techniques
At the next level, an editor API provides a new level of convenience in
closing the compile-debug-edit loop. Drag-and-drop interfaces allow
interactive touches such as dragging an error message into an editor
window to display the associated portion of the source code.
This provides more freedom than the tightly coupled integrated editors
that have been the state of the art for other integrated environments.
Such environments typically permit sequential review of error messages
vis-a-vis source codes, while the WorkFrame/2 API allows programmers to
examine messages in any order they prefer.
IBM's PM Debugger will be challenged by the considerable complexity of
full-scale applications for OS/2 2.0. A large suite of examples will
emerge from developers' experiences that will reveal whether IBM has
correctly anticipated their requirements.
The PM Debugger provides direct debugging of PM applications in either
of two modes. In synchronous mode, the debugger calls an OS/2 API that
blocks messages from other windows, making it essentially impossible to
lock up the machine. (This, however, also blocks the PM user's normal
freedom to use many different tools at once.) The asynchronous mode is
slightly less bulletproof, but captures messages only for the
application being debugged.
Other productivity enhancements in the debugger include session
configuration files that preserve window arrangements and the states of
breakpoints and monitors.
OS/2 is a big system to learn -- far larger than the program loader of
DOS or the DOS shell of Windows. IBM's development suite is likewise a
large and complex package, and each component is likely to merit
separate review as third-party development tools for OS/2 emerge to
create a more competitive market.
For now, however, the total effect of these tools illuminates both the
strengths of OS/2 -- multitasking, powerful memory management and
advanced user-interface options -- and the pitfalls of falling in love
with these features without getting all of the details right.
For IBM to have an important role as a tool maker for its own operating
system, the company will have to rise to the standard of other
successful tool makers in shipping polished, efficient products that
make software development fruitful rather than frustrating.
C Developer's WorkSet/2 is available at a promotional price of $295
until Aug. 31. After that date, the price will be $895. Each component
of WorkSet/2 can also be purchased separately: C Set/2 is available for
$696, WorkFrame/2 costs $90, and the Developer's Toolkit is priced at
$119. IBM can be reached at (800) 342-6672.
------------------
PC Week Labs Gets Under the Hood of OS/2 2.0
From PC Week for June 8, 1992 by Larry J. Seltzer
Exhaustive testing by PC Week Labs found that OS/2 2.0 is a potential
32-bit gem that nevertheless lacks both polish and third-party
applications.
Patience will be not only a virtue but a requirement for companies
making the move to IBM's new operating system. Corporate users will have
to learn many new conventions before the potential of OS/2 2.0 becomes
apparent. Volume buyers, meanwhile, will be tempted by the potential of
OS/2 2.0, but also will be leery of its less-than-perfect DOS/Windows
compatibility, its current rudimentary support for Novell Inc.'s NetWare
and the lack of 32-bit OS/2 applications. Finally, developers will be
thoroughly plea sed with the design of OS/2 2.0 but also will be anxious
about the current lack of third-party development tools.
PC Week Labs evaluated OS/2 2.0 against a range of testing criteria and
organized its conclusions based on the operating system's major
components and capabilities: the Workplace Shell; ability to run DOS and
Windows programs; new capabilities for DOS applications; stability;
networking capabilities; hardware requirements; installation; and
documentation and on-line help.
The Workplace Shell
The most striking new feature of OS/2 2.0 is the Workplace Shell. The
Workplace Shell is only vaguely related to previous user interfaces
found in OS/2 and resembles a Macintosh more than any interface
previously seen on Intel X86 systems. The Workplace Shell constitutes
the most obvious difference between OS/2 2.0 and its competitors.
With the Workplace Shell, users have more options for configuring the
desktop than they did under previous versions of OS/2 or under Windows.
As with a Macintosh, users generally do not need to type in commands to
execute programs, manipulate files or change configuration. Users can
print files by dragging them to the appropriate printer icon and can
delete files by dragging them to the "shredder" icon. Users execute
programs by double-clicking on the associated icon.
After a short time working with the Workplace Shell, PC Week Labs found
a useful way to configure the desktop. The default configuration for
OS/2 places the icons for the DOS, Windows and OS/2 full-screen and
windowed sessions in the "Command Prompts" folder, which itself is in
the OS/2 System Folder. Accessing these icons by digging through the
folders was both inconvenient and slow, so PC Week Labs created
"shadows" of these icons on the desktop.
Shadows are aliases for an icon. The shadows that PC Week Labs created
on the desktop did not copy the icon itself or the program or any of the
configuration settings associated with the icon; instead, they made all
of these accessible on the desktop, where they were more convenient.
Shadows are useful for making objects in the Workplace Shell accessible
without disturbing the way the user has organized folders and icons.
Like the Macintosh desktop, the Workplace Shell encourages users to
think of the file system visually, with drives containing icons and
folders that themselves can contain other icons and folders.
The Workplace Shell also provides a facility wherein all OS/2 file
systems, including the file allocation table (FAT), can use names for
objects that run up to hundreds of characters, including embedded spaces
and preserved case sensitivity.
The Workplace Shell constructs a unique, standard-length DOS file name
(with as many as eight characters before and three after the period)
based on the longer name, which it saves as well. Under OS/2's High
Performance File System (HPFS) -- which, as an alternative to a FAT
system, handles larger disks and long file names -- the long name for
the object is the actual file name as well. To maintain compatibility,
all DOS and OS/2 software that cannot handle long names presents only
the first eight characte rs of the name and the first three characters
after the period.
Users must be careful not to mix up the long and short file-name
systems. Those following IBM's model of OS/2 as an "integrating
platform" and who plan on using all their old applications will continue
to use standard-length file names. Users who have OS/2 software that can
support long names can stick more closely to the Workplace Shell design
by using OS/2's long file names.
The latter group of users can also use OS/2 2.0's templates, a set of
stock objects of various types used to add a new program, create an
empty folder or create a new document to be used with OS/2 2.0's
productivity tools. PC Week Labs used these templates, mostly with OS/2
applications software, to create new objects for use with applications
or the Workplace Shell itself. DeScribe Inc.'s 32-bit DeScribe Word
Processor 3.0 adds a DeScribe document template to OS/2's Templates
folder as part of its install ation process. Users simply copy the
template to the appropriate location, change the name and launch it.
Because the template, the empty document made with the template and the
application used to modify the template are linked, users launch the
application simply by launching the document. Mac users have been
launching applications by double-clicking on documents for years, and
even Windows users have a primitive form of this in File Manager.
An object-oriented environment such as the Workplace Shell provides
objects as well as actions to perform on those objects. Users access a
menu of actions that can be performed on Workplace Shell icons by
pressing the right mouse button on the icon. Some of the options that
are available, depending on the circumstances, are Copy, Delete, Print
and Open.
If users click on the word "Open," they get the default action, which
usually opens the program. If they click on the arrow next to word
"Open," they can choose between opening the program associated with the
icon and opening the settings for the icon. If a user opens an icon with
no program defined, the Workplace Shell automatically opens the settings
notebook at the proper page for defining the program to be used.
The Labs also performed operations on groups of objects by dragging an
outline around them.
IBM also has included the elegant touch of automatically creating a
composite icon to remind users that they're dragging, for example,
several items at once into a new folder location.
Users can manipulate settings by using a new and frequently used model
in the Workplace Shell, the "tabbed book." Instead of a menu bar, the
various groups of settings are presented as pages in a book, with the
titles of the sections on tabs sticking out from the page. Clicking on
the appropriate tab brings a section to the foreground.
The settings that appear depend on the type of object and how it is
being used. For instance, a drive or folder icon has View settings,
which PC Week Labs used to arrange the icons contained therein in
ordered rows, sorted, or in free form. Many program icons have Session
settings used to determine whether they are run in a full-screen or
windowed session.
Often, the settings simplify operations that were inconvenient in
Windows (such as having to use the PIF editor to modify a program's
attributes). For instance, PC Week Labs easily changed file-attribute
flags, such as read-only, hidden and system, by clicking radio buttons
on the second page of the File Settings. Using other settings, the Labs
modified the menu presented by clicking on the object with the right
button and editing the actual icon image associated with the object.
The Workplace Shell is not without glitches. The most serious and
widespread is a lack of visual feedback for operations commenced in the
environment. For instance, when an application is launched by double-
clicking on it, the icon's gray background changes slightly in shade. On
a relatively slow system, or sometimes even on faster systems, depending
on the circumstances, a period of time elapses during which it is not
clear to the user whether the application has actually been launched. A
common reaction observed by PC Week Labs was for the user to double-
click again on the icon. After the application launches, this additional
double-click is handled, with the result depending on the
circumstances, such as the layout of the program after it loads.
Although users can work in the Workplace Shell with a keyboard and hot
keys, PC Week Labs found it very difficult to use the Workplace Shell
without a mouse -- even more arduous than using Windows with a keyboard.
The Workplace Shell, both in its design and documentation, encourages
users to carry out common file operations through graphical means:
Either drag the icon from one location to another, or right-click on it
and choose the operations available on the properties menu. After
extended testing, however, PC Week Labs found itself switching into DOS
or OS/2 windows to use COPY commands, which were more direct and
operated faster. (To compare, grouped COPY commands also are more easily
done from command prompts in Windows 3.0, though not in 3.1.)
Even longtime DOS and Windows users will recognize the potential for
flexibility and ease of use in the Workplace Shell. A Workplace Shell
system loaded with plenty of Workplace Shell-aware software will be more
impressive than the system tested by PC Week Labs, which lacked these
applications because they were not yet available.
The Workplace Shell also may perform faster as the hardware gets faster.
The best-equipped system on which PC Week Labs ran OS/2 2.0 was a Compaq
Computer Corp. Deskpro 486/33L Extended Industry Standard Architecture
(EISA) desktop system with 16M bytes of RAM and a 600M-byte hard drive.
Even on this system, the Workplace Shell could be distractingly slow at
times.
Although the Workplace Shell is the most visually distinctive feature of
OS/2 2.0, users will find that the operating system's greatest virtue is
its ability to run multiple DOS and Windows programs simultaneously. The
Windows operating environment being run in OS/2 2.0, which is called
Win-OS/2, is not an emulation but the actual Windows binaries developed
by Microsoft Corp. and modified by IBM to run under OS/2.
Running DOS, Windows Programs
PC Week Labs ran numerous DOS and Windows programs in full-screen
sessions and in windows on the Workplace Shell desktop. Although most
programs worked correctly under OS/2 2.0, it was not uncommon for them
to generate significant errors. A thorough knowledge of the DOS settings
helps in fixing many of these problems.
Several programs showed serious problems in testing. Aldus Corp.'s
Persuasion 2.1 presentation-graphics package refused to install, Central
Point Software Inc.'s PC Tools 7.1 utilities package locked up, and
Fifth Generation Systems Inc.'s Fastback Plus 3.0 backup software
occasionally locked up when backing up to a network drive. Officials
from each of the companies told PC Week Labs that their programs do not
support OS/2.
In addition, Berkeley Systems Inc.'s After Dark 2.0 Windows screen saver
presented an unintelligible display on the screen. IBM has demonstrated
earlier versions of After Dark under OS/2, however. Delrina Technology
Inc.'s WinFAX Windows fax software package also crashed its Win-OS/2
session.
PC Week Labs managed to get some programs to run after making a few
adjustments. Tool Technology Publishing Inc.'s WinTools Windows tools
package apparently tries to modify its own executable file against the
wishes of OS/2. The company's technical staff found a work-around for PC
Week Labs that involves first installing a copy of WinTools on a
DOS/Windows system, then running the registration portion of the install
program -- which is incompatible with OS/2 -- only the first time the
program is installed. Thereafter, it appears to install correctly under
OS/2.
Other applications showed less serious problems, such as Ozark West
Software's OzCIS shareware program, which ran correctly in a window in
VGA but not in XGA.
OS/2's extensive README file lists 99 applications for which IBM testing has determined that special instructions are needed. (All of the programs that showed serious testing problems in PC Week Labs tests,
except for WinTools, are listed in the README file.) Most of these 99
applications simply require a small modification to their configuration,
according to the README file, or are noted as not running properly in a
window.
PC Week Labs was unable to get some programs, such as WinFAX, to
function even after it followed the relatively minor special
instructions listed in the README file. The case of WinFAX is especially
interesting, because it was used with an Intel Corp. SatisFAXtion fax
board installed in the Gateway 2000 486/33C ISA system. The fax software
that comes with the SatisFAXtion adapter functioned correctly when both
sending and receiving, even in the background. The SatisFAXtion board
also has a long section of its own in the OS/2 2.0 README file,
detailing how to modify the installation instructions so it functions
correctly. PC Week Labs also was unable to test WinFAX successfully on
the IBM PS/2 Model L40 portable using that system's own internal
fax/modem.
PC Week Labs' tests confirmed many of the application considerations
listed in the README file. The README states, for example, that Fastback
Plus 3.0 may not back up successfully to floppy disks -- and it did not
in PC Week Labs tests. PC Week Labs successfully backed up to a network
drive with Fastback Plus 3.0 in most cases, however. Such problems
should decrease as software vendors more extensively test their DOS and
Windows applications with OS/2 2.0.
Modifying DOS or Win-OS/2 settings can help with these problems, but
these settings are poorly documented and the on-line help is inadequate.
For instance, when the help for DOS VERSION is selected, a message
reads, "Use this setting to select program versions compatible with the
DOS version used in this DOS session." The explanation for how to enter
the values used in this setting is buried deep within the Master Help
Index, a separate on-line help system.
DOS Capabilities
PC Week Labs tested several new and useful OS/2 2.0 capabilities for DOS
applications. One is background communications, which worked most of the
time. PC Week Labs determined that several DOS settings are useful for
getting communications software to work correctly.
DOS_BACKGROUND_EXECUTION and COM_HOLD should be set to "On," and it
helps to set the IDLE_SENSITIVITY to a setting of 100, thus disabling
idle detection. (Idle detection is a technique used by OS/2 to determine
whether an application is sittin g and waiting for input, which gives
OS/2 a chance to assign it low priority.)
Among the DOS programs tested, Qmodem SST, a communications program from
Mustang Software Inc., would not run in the background. As soon as PC
Week Labs switched out of the session, the carrier dropped on the modem.
OzCIS, on the other hand, worked correctly as soon as the appropriate
DOS settings were applied. Background DOS communications under Windows
also is problematic, and PC Week Labs had sporadic success with it.
PC Week Labs also tested communications using the PM Terminal program,
provided in the Productivity folder. The background communications
results for PM Terminal were quite encouraging. On a 16MHz 386SX system
with 6M bytes of RAM -- a near-minimal configuration for OS/2 -- PC Week
Labs was able to sustain a 9,600-bps transmission in the background
while using other software in the foreground. The foreground application
did not appear to be burdened by the background task.
In addition, PC Week Labs tested Hilgraeve Inc.'s HyperAccess/5, an OS/2
2.0 character-mode communications program, which worked well.
Another useful feature related to DOS settings is the ability to create
DOS sessions with different configurations. By copying the DOS Window
icon or DOS Full Screen icon and modifying the copy's settings,
including the DOS_DEVICE setting, PC Week Labs was able to create the
equivalent of different CONFIG.SYS files for the DOS sessions. By
changing the path and file name in the Program page of the settings book
from "*" to "c:\os2\mdos\command.com" and adding "/KBATCH.BAT" to the
parameter field, the Labs ran BATCH.BAT after the AUTOEXEC.BAT file.
This technique was used to make DOS sessions with the equivalent of
different AUTOEXEC files.
Perhaps the most significant improvement in OS/2 2.0 for running DOS
applications is the large amount of available conventional memory, EMS
memory and XMS memory, as well as the availability of DOS Protected Mode
Interface (DPMI) services. DPMI is an emerging standard for DOS
extenders in which DOS extended applications run at a lower privilege
level than the DPMI server, which in this case is OS/2.
Because OS/2 does not permit applications to run at the same privilege
level as itself, older techniques for DOS extenders, most notably the
Virtual Control Program Interface, are not supported. As a result, many
DOS extended programs, such as Paradox 3.5, cannot function under OS/2.
(A non-DOS-extended version of Paradox 3.5 is available.)
Part of the installation process involves migrating DOS and Windows
programs to OS/2. The Migrate program, found in the System Setup folder,
searches for DOS, Windows or OS/2 programs on the disk and creates icons
in folders for them. PC Week Labs found that, as the READ.ME file
indicates, the Migrate program often will not find a program even when
its exact location is provided. During testing, running Migrate a second
time sometimes would find the files.
Stability
The Workplace Shell and OS/2 itself occasionally crashed in tests. When
the Workplace Shell crashed, all of the icons and folders closed up, and
the screen blanked out. The Workplace Shell usually restarted itself at
this point. On a few occasions, OS/2 itself crashed, displaying a
register dump and indicating that the system was stopped.
PC Week Labs determined that, while running the beta NetWare Requester,
OS/2 2.0 would crash when the Labs separated the Token- Ring cable from
the adapter on some systems to simulate a network failure. After this,
if the user selected anything on the network drive, the system would
eventually crash.
Networking Capabilities
PC Week Labs tested OS/2 2.0 using server and requester configurations
of IBM's LAN Server 2.0 Entry package. (The Advanced package, which
includes the 32-bit HPFS386 file system, was not available in time for
review.) Using LAN Server is fairly straightforward, but its
documentation and user interface need updating.
LAN Server 2.0 is an OS/2 1.3 product that also works under OS/2 2.0.
However, little of the documentation makes reference to OS/2 2.0, and
few of the facilities for managing LAN Server are graphical. Even the
beta NetWare Requester for OS/2 tested by PC Week Labs (see related
story, Page S/10) was far more graphical and easier to use than LAN
Server 2.0.
The network operating system comes with a thin "Network Administrator
Reference Supplement for OS/2 2.0." It contains some useful information
about setting up Remote Initial Program Load stations (which boot the
operating system from a network server); information about installing
the DOS LAN Requester in DOS sessions under OS/2 in which an actual
version of DOS is running; and some of the implications for server cache
sizes under OS/2 2.0. The implications for the Workplace Shell are not
discussed.
Installing the server and requester programs for LAN Server 2.0 is easy.
PC Week Labs chose server and domain names, but was able to defer all
other decisions related to users, groups and permissions. (A domain is a
LAN Server concept describing a logical group on the network and the
resources, such as servers and devices, to which it is privy.) By
default, a user with administrative privileges named USERID with
password PASSWORD exists, and LAN Server wisely advises modifying both.
LAN Server offers mostly character-mode utilities that do not run in a
window. It is possible to modify resource assignments using these
utilities, generally in the "LAN Requester" program in the LAN Services
folder, but PC Week Labs found them difficult to use and poorly
documented. LAN Server also does not include a printed command reference
to all the command-line "Net" commands, which are used to assign
resources. The reference is on-line and contains good examples, but can
be inconvenient to use.
Based on past experience, PC Week Labs found the command-line utilities
easier to use than the LAN Requester program. For instance, at the
server, the Labs created a directory named C:\APPS into which
applications were to be installed. This could be shared across the
network by assigning it a network name with the command NET SHARE
APPDIR=C:\APPS. Users on the network assigned this directory to a
logical drive on their workstations with the command NET USE F:
\\PCWLABS\APPDIR. PCWLABS was the name of the s erver.
Printers and modems can be shared in the same way. PC Week Labs was able
to share a modem across the network by using NET SHARE to assign it the
network name "HAYES" and then assigning it to the workstation's COM2:
port with the command NET USE COM2: \\PCWLABS\HAYES. DOS, Windows and
OS/2 applications all worked well with LAN Server.
Applications tested on the server included HyperAccess/5, OzCIS,
DeScribe and Lotus 1-2-3 for Windows.
Hardware Requirements
The hardware requirements for OS/2 2.0 are somewhat hard to pin down. PC
Week Labs found that, depending on which software was being run, OS/2
2.0 ran adequately on a PS/2 Model 55, a 16MHz 386SX system with 6M
bytes of RAM and a 60M-byte hard disk. IBM claims that 4M bytes of RAM
is the minimum requirement but recommends additional RAM, depending on
what applications are being run. At times, the Model 55 was unbearably
slow.
The same rules apply to high-end hardware. PC Week Labs did not
encounter a system on which OS/2 2.0 did not leave users waiting from
time to time. A good example is 1-2-3 for OS/2: On a 486SX system with
12M bytes of RAM, it was still fairly slow.
Although OS/2 2.0's video support covers the most important bases, it
does have some large gaps. While it provides support for some high-
resolution adapters such as 8514/A and XGA, "seamless" Windows support
is available only in VGA mode. OS/2 2.0's Super VGA support is minimal
at this point. PC Week Labs tested OS/2 on several Super VGA adapters in
VGA mode. Super VGA mode was tested for DOS applications by executing
the SVGA ON command. Borland International Inc.'s Quattro Pro 4.0
correctly executed in h igh-resolution mode on a Diamond Speedstar
adapter. The Workplace Shell itself, however, cannot be executed in
Super VGA mode.
At times, PC Week Labs preferred using full-screen Win-OS/2 sessions to
seamless Windows, because it was generally faster to load programs and
perform complex display functions in full-screen mode. On the other
hand, some applications, such as Borland's C++ 3.0, require the user to
run within Windows using both Windows and DOS programs. DOS programs,
however, cannot be loaded in Win-OS/2 sessions, but only from the
Workplace Shell desktop. Therefore, users of such applications have to
choose between using seamless Windows and switching back and forth
between Win-OS/2 full-screen sessions and the Workplace Shell desktop
-- a time-consuming operation.
Installation
Although installing OS/2 takes a long time, IBM has designed this
complex process well. The installation process can preserve a user's
existing installation, be it DOS or OS/2 1.x. At the end of the process,
the applications detected are migrated to the OS/2 desktop.
Users have the option of choosing which components of OS/2 they want to
install. Uninstalled components can be added later using the "selective
install" feature, but, as PC Week Labs found, when even the smallest
feature is added in this manner, the user must cycle through OS/2 2 2.0
disks 6 though 15. A minimal installation consumes about 15M bytes of
disk space; the full installation takes up about 31M bytes.
One of the most significant choices the user must make in the
installation process is whether to use Dual Boot or Boot Manager. The
Labs installed Dual Boot, which automatically loads either DOS or OS/2,
on a system that had DOS installed. Dual Boot requires that the
CONFIG.SYS on the DOS system contain the line SHELL=C:\DOS\COMMAND.COM
C:\DOS /P and that the AUTOEXEC.BAT contain the line SET
COMSPEC=C:\DOS\COMMAND.COM. When the system was set up this way, Dual
Boot was installed automatically when OS/2 2. 0 was installed.
To use Dual Boot, users simply launch the Dual Boot icon in the Command
Prompts folder. The system reboots and starts DOS. Under DOS, running
"C:\OS2\BOOT /OS2" reboots the system and starts OS/2 again.
Boot Manager uses disk partitions to allow as many as three operating
systems to be booted on the system. With Boot Manager, users are
presented with a menu of operating system choices. Except in
extraordinary cases, this approach requires a fresh repartitioning and
reformatting of a drive.
PC Week Labs installed both DOS and OS/2 on a PS/2 Model 90 by creating
a Boot Manager partition and two primary bootable partitions named "DOS"
and "OS2." When the system was booted, the DOS and OS/2 bootable
partition names were presented to PC Week Labs in a menu. By choosing
DOS and booting off a DOS boot floppy, the Labs installed DOS on the
partition. The same process was then followed for OS/2. After DOS and
OS/2 were installed, choosing the bootable partition from the menu
booted the operating syst em off the partition.
Boot Manager is more flexible than Dual Boot and enables other operating
systems such as Novell's DR DOS, IBM's AIX or The Santa Cruz Operation
Inc.'s SCO Unix to be booted. Boot Manager requires complete
repartitioning at the start of the installation process, however, and PC
Week Labs was able to access only the active boot partition. The OS/2
boot partition was not visible when DOS was running, and vice versa.
OS/2 2.0 comes bundled with support for REXX, long a feature of other
IBM operating systems. REXX is similar enough in basic structure to DOS
and OS/2 batch languages that PC Week Labs was able to convert existing
DOS and OS/2 batch files to REXX programs and then add REXX features
such as loops and user interaction.
OS/2 also bundles 24 "Productivity" applications. Some, like the
Enhanced Editor and PM Terminal, are useful, while others are barely
functional, such as the Spreadsheet and Database. None are intended to
compete with commercial applications.
Documentation
IBM has taken a "less is more" approach with the documentation for OS/2.
Although six books are provided, three are more like pamphlets. PC Week
Labs found them deep in introductory material and shallow in reference
material. Indeed, most of the more interesting and informative material
is in the 75K-byte README file.
It is to IBM's credit that it has provided such a substantial README
file. Ninety-nine applications are listed with special instructions for
fixing problems or optimizing performance, or that inform users that
they may encounter some loss of functionality with certain products.
The same documentation philosophy extends to the LAN Server product
tested by PC Week Labs. The documentation is short and complete enough
that the reader can become competent quickly and successfully install
the product. But once it is installed, things change. All the reference
material related to command-line utilities for OS/2, DOS, Win-OS/2, LAN
Server administration and session configuration settings is available
only on-line.
On-line documentation includes a Master Help Index, a glossary, a
command reference, a REXX reference, a tutorial and a program that gives
an overview of significant concepts such as multitasking and printing.
------------------
Company Information
IBM
Armonk, N.Y.
(800) 342-6672
Publicly held;
IBM on NYSE
Year established: 1914
Number of employees: 344,396 (as of Dec. 31, 1991)
Net revenue (1991): $64.8 billion (as of Dec. 31)
Product line: hardware, networking, software
Technical Support: (800) 772-2227
9 a.m to 5 p.m., all time zones Monday-Friday. Free phone support,
first 60 days; after 60 days, $129 per year. Support also available
on CompuServe and IBMLink.
Source: Information supplied by company
------------------
Testing Methodology
PC Week Labs tested OS/2 2.0 on a variety of systems and architectures.
The Micro Channel systems used were IBM PS/2 Models 55 SX-061, 70 386-
A21, 80 386-A21 and 90-0C9. Other systems used were an Austin Computer
Systems 386SX20, a Compaq Deskpro 486/33L, a Dell System 333D Industry
Standard Architecture (ISA) system, a Gateway 2000 486/33E Extended
Industry Standard Architecture (EISA) system and a Gateway 2000 486/33C.
In LAN Server network testing, the PS/2 Model 80 386-A21 was used as the
server and the Models 90-0C9 and 55 SX-061 were used as workstations.
The topology was IBM Token-Ring running at 16M bps. The Austin 386SX20
and PS/2 Model 70 386-A21 were used for the NetWare Requester testing,
also running IBM Token-Ring at 16M bps.
PC Week Labs tested a wide range of OS/2 applications with OS/2 2.0,
including DeScribe's DeScribe Word Processor 3.0, Hilgraeve's
HyperAccess/5, Informix Software's Wingz, Lotus' 1-2-3 for OS/2 version
1.1, and Microsoft's Word for OS/2 1.1 and Microsoft C version 6.00a.
The Windows applications tested included Aldus' Persuasion 2.1; Berkeley
Systems' After Dark 2.0; Borland's C++ 3.0 (including Resource Workshop
and Turbo Debugger); Lotus' 1-2-3 for Windows; Microsoft's Excel for
Windows versions 3.0 and 4.0, Visual Basic 1.0, and Word for Windows
version 2.0a; and Within Technologies' Realizer 1.0.
DOS software tested included Borland's dBASE III+ version 1.1 and
Quattro Pro version 4.0, DataEase International's DataEase 4.5, Lotus'
1-2-3 releases 3.1 and 3.1+, Mustang Software's Qmodem SST 4.5,
MetaWare's High C/C++ 3.0, Ozarks West Software's OzCIS 1.2, Solution
Systems' Brief 3.1, Watcom's C/386 9.0 and WordPerfect's WordPerfect
5.1.
PC Week Labs also tested OS/2 2.0 with a Hewlett-Packard LaserJet III
with Printer Control Language and a PostScript cartridge, a Hayes
Microcomputer Products Ultra 144 modem and an Intel SatisFAXtion fax
board. -- L.S.
------------------
NetWare Requester Beta Performs Well in Tests
From PC Week for June 8, 1992 by Larry J. Seltzer
With NetWare currently the corporate LAN of choice -- more than 60
percent of PC Week's readers have it installed -- strong NetWare support
is clearly essential to corporate acceptance of OS/2.
Version 2.0 of Novell Inc.'s NetWare Requester for OS/2 -- which lets
OS/2 systems connect to NetWare networks -- had been slated for release
at the same time as OS/2 2.0, but the date slipped late in the
development process. It is currently slated to be shipped this week.
PC Week Labs examined a late beta release of NetWare Requester version
2.0 as part of its evaluation of OS/2 2.0. Although the beta version,
which was downloaded electronically, came without any documentation or
server utilities such as PCONSOLE or SYSCON, PC Week Labs was impressed
by the base product.
NetWare Requester 2.0 has been well integrated into OS/2 2.0 and the
Workplace Shell's paradigm, which first became evident in the install
program. Earlier OS/2 NetWare Requester installations were inflexible
and uninformative, simply copying files to the C:\NETWARE directory and
appending a few lines to the CONFIG.SYS file. Previously, the proper
contents of the NET.CFG file, which specify configuration parameters for
the NetWare workstation, were left to the user to conjure from
inadequate documentation.
After using the automated function for installing workstation software,
PC Week Labs tested NetWare Requester for OS/2 2.0's interactive
configuration utility. The program contains three windows: one with the
NET.CFG file being built, another with a list of available options to
enter into the file, and a third with explanations and examples for the
option selected in the second window. This utility greatly eased
workstation configuration.
Installation program options that PC Week Labs did not test include
supervisor utilities for installing server utility software and
installation and configuration of Remote Initial Program Load
workstations, which boot the operating system from a network server.
NetWare Tools for OS/2
The main NetWare Tools for OS/2 program is used for most of the
configuration process. PC Week Labs had no trouble attaching servers and
mapping drives to network directories with the beta NetWare Tools for
OS/2. The program includes a display that shows which logical drives are
mapped to which locations on the various servers. Drive assignments were
changed by simply double-clicking on the line containing the drive
letter. A series of menus and list boxes appear, guiding the user
through the available ser vers and directories.
Other functions in the NetWare Tools beta included the assignment of
printer ports to print queues and the ability to view user lists on a
server.
Once an Industry Standard Architecture (ISA) workstation and a Micro
Channel workstation were configured using IBM Token-Ring hardware and
attached to the test network, drives were mapped and used with
applications. PC Week Labs mapped drives to directories containing
copies of the installation disks for applications and ran the
installation programs, installing the applications to other locations on
the network. The applications -- WordPerfect Corp.'s WordPerfect 5.1,
Microsoft Corp.'s Excel and Symantec Corp.'s Norton Backup for Windows
-- all worked well. Mapped drives appear in OS/2 2.0's Drives folder,
where they can be treated like any other OS/2 drive.
PC Week Labs' tests of the NetWare Requester beta version revealed some
problems. The "Check Disk" option appears on the properties menu for
NetWare drives even though no results are displayed when it is chosen.
Also, many of the help screens and examples in the interactive tools are
incomplete. When PC Week Labs pulled the cable from one of the Token-
Ring adapters (a test that Novell also uses), OS/2 2.0 crashed,
reporting an exception in one of the NetWare device drivers.
If Novell gets NetWare Requester for OS/2 version 2.0 working correctly,
NetWare access will be easy and pleasant under OS/2 2.0.
------------------
For Dealers, 2.0 Release Brings Mixture of Relief, Skepticism
From PC Week for June 8, 1992 by Stephanie LaPolla
Now that OS/2 2.0 has made it to golden code, dealers agree that IBM has
finally delivered on most of its promises of product functionality. How
fast IBM is delivering the product to dealers' shelves, however, is
another story.
The only way Patrick Quick could get his hands on the new OS/2 was to
win a copy at Comdex/Spring in Chicago. "I ordered it from [distributor]
Ingram Micro, but they never had it in," said Quick, president of PC
Plus Computer Sales and Training Inc., a computer retail store in
Naples, Fla.
CompuCom Systems Inc. also had to wait longer than anticipated for its
inventory of OS/2 2.0, said Philip Wise, senior vice president of
product management at the Dallas-based reseller. "We have had it since
April 13th, but that is a little later than I had expected," said Wise.
"Customers saw it advertised and wanted to buy it, but we didn't have
it."
Sharon Costello, sales and marketing manager at Applied Graphics Co., a
computer dealer in Shelburne, Vt., said that although her shelves now
are stocked with OS/2, she had to wait about a month after the product's
official ship date to receive the inventory.
Computers Etc., meanwhile, has had no recent requests for OS/2 -- old
versions or new. "OS/2 2.0 may do better [than earlier versions], but
Windows is really hurting it," said Howard Gelpey, president of the
Peabody, Mass., dealer. At Computers Etc., "Windows 3.1 is getting a lot
of noise."
Quick said that he has had only two requests for OS/2 2.0 from customers
since it became available and that he discourages customers from buying
it. During his tests of the product, he found the 32-bit architecture
extremely slow, difficult to install and demanding of too much hard-disk
space.
"OS/2 2.0 is an excellent operating system, but when you need 8M bytes
of RAM and 40M bytes of hard drive, you are wiping out a whole lot of
working area," Quick said. In addition, he said, "it's just plain slow.
Microsoft Works and PageMaker run at half [of their normal] speed."
One reason for OS/2's slow sales could be IBM's lack of communication
about product availability and technical issues, dealers said. "We
hardly hear from IBM. They don't fill us in," Gelpey said. "So if a
customer comes to us with an OS/2 problem, we can't help them that
much."
An Illinois dealer said that he has had only one customer inquiry about
OS/2 2.0. He sent the order in to IBM when it began shipping the upgrade
but has not heard back yet. As far as he's concerned, he said, "OS/2's
not shipping yet."
Despite delays in receiving the shrink-wrapped product, some dealers
remain optimistic about OS/2's chances for success. Rick Inatome,
chairman of reseller InaCom Computer Centers Inc. in Troy, Mich.,
believes that as soon as IBM extends services such as workshops and
technical support to dealers, product sales will take off.
"IBM feels that dealers are a healthy part" of getting the momentum
going for OS/2, Inatome said.
Costello agreed, explaining that IBM offers plenty of training programs
on OS/2 technology. Dealers, she said, just have to be aware of what is
going on.
David Hall, chief technical advisor at CompuCom, said it's still too
early to know how many people will actually commit to OS/2. "Right now,
customers are evaluating Windows and OS/2," he said. "Within the next
six months, we will be able to look at the true sales and see how many
people are buying [0S/2] because they have made the decision to install
it, as opposed to buying it just to look at it and see what it can do."
Copyright (c) 1992 by Ziff Communications Company. All rights reserved.
Material May not be reproduced or distributed in any form without
