home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
OS/2 Shareware BBS: 14 Text
/
14-Text.zip
/
LAMENT.ZIP
/
LAMENT.MSG
Wrap
Text File
|
1993-02-25
|
11KB
|
191 lines
I started using OS/2 about five months ago. My main interest in OS/2 is
in writing a book on it, although I would also like to be able to use
it as my primary operating system. I've already written a book on Unix,
"UNIX for the Impatient", that has been very well received and is selling
quite briskly. That experience proved that I don't have to like an
operating system to write a useful book about it. In fact, not liking
the system can even add to the value of the book. Recognizing and
explaining a system's faults helps a reader deal with those faults.
I wish I could feel better about OS/2, especially as compared with
Windows. I know that OS/2 has a far sounder underlying structure. Yet
my experiences with it have been a series of major and minor
frustrations. In this file, which I also published as a series of
messages in the OS2USER forum, I will explain those frustrations. If
OS/2 is to succeed in its goal of displacing Windows, it will have to do
better. Some of the points I raise may seem minor, but a few minor
irritations easily add up to a major one, especially since they affect
the total feel and experience of the system.
(1) Support for video boards and communications ports is dangerously
weak. Since video board manufacturers have less motivation to produce
drivers for OS/2 than for Windows, it is really incumbent on IBM to
produce the drivers itself and make them work properly, at least for the
time being. Perhaps a moral case can be made that the drivers are the
responsibility of the board manufacturers, but making that case will not
win over many users. Word processor vendors, for example, have long
realized that they need to produce printer drivers and not rely on
printer manufacturers to do it for them. As to communication drivers
(for the serial ports), the existing ones simply don't work for many
people, including me. There have also been problems with hard disk
drivers, although my impression is that this area is now under control.
Perhaps Microsoft can rely on others to produce drivers for their
products; given the present marketplace, IBM can't.
(2) The user interface seems heavy and clunky compared with Windows.
The heaviness has several apparent causes: the slow response time for
many operations, the number of actions needed to accomplish a task, the
screen clutter caused by the uneconomical use of screen real estate, and
the accumulation of unwanted window objects as one is performing a task.
(3) Although much has been made of the "fact" that OS/2 is more
stable and reliable than Windows, that hasn't been my experience,
even though the superior underlying implementation paradigm suggests
that it should be.
Whatever its immunity to application errors, OS/2 itself has a tendency
to implode, leaving you with a screen dump and a message "The system has
stopped", a black screen, or a totally locked-up keyboard and mouse. The
recovery from a screen dump seems not to have been thought out at all.
Nothing but a cold boot will restart the system---not kind to folks who
don't have a reset button. No method is provided for mechanically
recording the dump information. One way to handle that would be to dump
to a named file on a specified drive. Even if the hard disk has gone
south, it should be possible to dump to a floppy. Then an analysis
program can reprocess the information when the system has recovered.
Furthermore, the message (contact your customer service rep or something
like that) is totally inappropriate for most users, who have bought the
system off the shelf. IBM needs a better channel for receiving dump
information---like a special P.O. box named "Dump", or perhaps as well a
CIS ID for receiving these reports.
Although OS/2 is supposed to be well protected against application
errors, I haven't found that to be entirely true. For example,
applications that get into a resource-consuming loop can lock up the
system (I've heard this is a known problem with icon libraries). Other
malfunctioning applications can seize the mouse and keyboard, providing
no way to terminate them (although in this case a soft reboot will at
least bring down the system gracefully).
(4) Many facilities make poor use of screen real estate. Folders, for
instance, can't hold very many icons. The Detail views, which might
offer some hope, aren't very clever about this; they ought to trim off
the blank space for unused columns. Moreover, the leading between rows
is excessive and can't be removed by using a different font. Compare the
number of files that can be shown in a Detail view versus the number that
can be shown in the same space by Windows File Manager.
(5) Navigation down through a sequence of folders tends to accumulate
unwanted folders. There needs to be a way to select an object from a
folder that causes the folder to be closed when the object is selected.
In fact, that should be the default. This problem is particularly acute
when navigating through drives. Work-area folders do not solve this
problem. The problem is exacerbated by the fact that the full workplace
is restored on reboot. That restoration should be optional; the
Ctl-Shift-Button1 action on bootup is not an adequate substitute for the
option.
(6) The Drives objects are exceedingly awkward to work with. Drive and
subdirectory windows are slow to open and awkward to navigate. An
example of when this is very visible is when using the Drives option of
Locate within Find. Subdirectories in the icon view, which is the view
one gets by default, are not sorted alphabetically. Compared with
Windows File Manager, working with Drives feels heavy and klutzy. Some
operations such as creating a subdirectory are far more difficult and
unobvious than they should be. (Try finding "subdirectory" in the Master
Help File.)
(7) The facilities for arranging icons within a folder lack the most
obvious one: neaten the icons in horizontal rows or vertical
columns without changing their order. Any attempt to arrange icons
causes them to be sorted, often not what is wanted. In fact, I haven't
seen any difference between the default Sort action and the Arrange
action on a folder's popup menu. Arrange should just arrange, not sort.
(8) The mouse drivers apparently don't provide for using the third button
on a mouse that has one. Of course the use of the third button should be
restricted to user-defined actions and should never be the default.
(9) Many of the applets are less polished than their Windows
counterparts. For example, compare the graphics in Klondike (what most
users try first) with those in Windows. Or compare the speed of
playing OS/2 Klondike with the speed of playing Windows Klondike. OS/2
Klondike is sluggish (no matter what options you select); Windows
Klondike is snappy. Or look at the Calculator---while it does have a
"tape", which Windows Calculator doesn't, it lacks many of the functions
provided by Windows Calculator such as hex/decimal conversions.
(10) Icon handling is generally weak. Icon collections are reputed to eat
up resources rapidly and so are limited in size. Importing icons from
Windows is impossible without shareware programs and difficult even with
them; OS/2 should be able to handle Windows icons whether they appear as
separate files, in Windows DLL format, or within executable files.
Furthermore, the icon editor lacks some obviously needed facilities. It
should be possible to save the current icon to the initially designated
file; this could be achieved with a command-line parameter that causes
the current icon to be saved to that file on exit. Without this
facility, moving icons around on the General page of the Settings
notebook is very awkward.
(11) The OS/2 command interface lacks some of the useful facilities of
DOS. The SUBST command, which I rely on heavily for creating virtual
drives and thus making my drive letters independent of reconfigurations,
is not supported by CMD.EXE. Moreover, there is no analogue for
AUTOEXEC.BAT (granted that there are ways to program around this). It
seems inexplicable that no provision is made for reading AUTOEXEC.CMD at
the beginning of every OS/2 session; such a file could happily coexist
with AUTOEXEC.BAT without any ambiguity.
(12) The way that SYSTEM.INI grows continually is a booby trap, made worse
by the fact that you can't access it during normal system operation.
Better maintenance tools, preferably invoked automatically, are needed
both to condense the file and to back it up. For example, an automatic
generational backup could be made every n'th reboot, with cleanup
performed automatically after the backup (with appropriate user options
selected at install time and recorded in CONFIG.SYS).
(13) A method is needed for setting system-wide defaults, e.g., DOS
settings and fonts, so that these need not be set individually for each
object. Cloning families of objects provides a little help here, but not
much.
(14) Help windows cannot be forced behind the applications to which they
pertain. Although sometimes it's helpful to have help windows always in
front, that behavior should be optional, not compulsory. Here again,
Windows gets it right.
(15) The installation process should be made more flexible. In
particular, it should be possible to install from the B: drive. To
achieve that, the first install diskette should include an INSTALL.EXE
program that would initiate installation. When called either from DOS or
OS/2, the INSTALL program would preempt the current operating system and
reboot from the current drive. (If necessary, only calls from DOS could
be permitted.)
(16) Better methods of system repair are needed that can work from the
command processor. In particular, OS/2 needs an editor like the DOS EDIT
program that does not depend on the Workplace Shell. The ShiftRtn
utility, which provides a method of initiating the command processor from
CONFIG.SYS, should be made a standard part of the OS/2 distribution since
getting to the command processor by reloading the first two installation
diskettes is painfully slow.
----
I intend these comments in a constructive spirit. If IBM is to see OS/2
survive and prosper, it can't afford to slough off the obvious problems.
I find the attitude of many folks in this forum worrisome; knocking
Windows and Windows NT for their faults or Bill Gates for his obnoxious
comments is not going to help OS/2 in the long run. Even if Windows NT
is late and the first release of it is a mess, later releases are not
likely to have the same defects. Look at the history of Windows, or for
that matter, of OS/2. Early releases of Windows were almost unusable;
that certainly cannot be said of the recent ones. A successful operating
system must adapt and improve; if OS/2 fails to do that, it will become
increasingly marginalized in the marketplace.
Paul Abrahams