Article View: comp.os.os2.misc
Article #17382OS/2 Wishlist [94-01-14]
From: Evan Champion
Date: Sat, 15 Jan 1994 15:14
Date: Sat, 15 Jan 1994 15:14
1806 lines
83415 bytes
83415 bytes
OS/2 Wish List -- Last Updated: 94-01-14
This is the OS/2 Wish List, compiled from OS/2 users worldwide from networks
such as the Internet and Fidonet. This document hopefully represents the
direction in which OS/2 users would like OS/2 to go and the tasks that must
be accomplished to get OS/2 there.
This list does not necessarily represent what OS/2 users want IBM to do, but
what OS/2 users want done for OS/2 in general. Therefore, it could be a
valuable source of information for commercial vendors and sharewares
authors. I will maintain a list of any shareware authors working on a
particular area so that people working on similar areas can get in touch
with one another.
PLEASE send this list everywhere you can!
To simplify the process of updating the wish list, each user who sends in an
addition to the list will get their name added to the contributors section
rather than to the wish they contributed to. This will also help keep the
file size down as the list grows by only including each contributor once in
the list. Also to simplify the process of updating the list, do not mail a
message listing the items that you support. Although I really do enjoy
it when people mail me saying that they really support certain parts of the
list, it takes a lot of time to process each message. I would, however,
like anyone who has questions or comments on a wish to mail me.
To add your wish to the list, please mail to 'evanc@spatial.synapse.org'
(Internet) or 'Evan Champion @ 1:163/590' (Fidonet). Please make sure that
your full name and mailing address are in the message to make it easier for
me to add your name to the contributors list. I try my best to pick up
wishes from UseNet or FidoNet Echos, but I do not always read every
message and as such might miss your wish - so to make sure it gets in,
please send it in mail!
Often one idea does not make sense without another, or would bring the most
benefit with the introduction of another, and whenever this is the case I
have indicated a wish to reference.
It is understood that some of these options would increase the size of OS/2
astronomically, thus causing problems for OS/2's distribution. Whenever
this is the case, the item should always be included on the CD-ROM
distribution, and should be made available for media charges only for the
floppy distribution.
Some of the items in this list represent major changes to OS/2 and
specifically dictate the removal of old methods of doing things. It is
recommended that such changes be implemented as a two version process
whenever possible - the first release would implement the addition and the
next release would remove support for the old method. This will allow the
user the time between major releases (usually a year) to update their
software and become familliar with the additions.
I do not necessarily understand everything I add to the list, so if I
misunderstand something, please set me know!
----------------------------------------------------------------------------
NOTE: This is probably the last version of the list that will be posted.
It has simply grown too large. I will work on making the list available for
FTP and FREQ for the next issue.
----------------------------------------------------------------------------
TABLE OF CONTENTS
0. ADDITIONS/CHANGES/DELETIONS
1. THE KERNEL
2. FILE SYSTEMS
3. HANDLING DISKS
4. DEVICE DRIVERS
5. OS/2 AS AN INTERNATIONAL OPERATING SYSTEM
6. PRESENTATION MANAGER
7. TEXT APPLICATIONS
8. WORKPLACE SHELL
9. SHELLS
10. MULTIMEDIA
11. UTILITIES
12. DOS
13. WIN-OS/2
14. REXX
15. API SET CHANGES
16. PRODUCTIVITY FOLDER
17. INSTALLATION AND CONFIGURATION
18. DOCUMENTATION
19. PACKAGES
20. CONFIG.SYS
98. OS/2 IN GENERAL
99. CONTRIBUTORS
----------------------------------------------------------------------------
0.0 ADDITIONS/CHANGES/DELETIONS SINCE 94-01-10
This section contains references to all new sections and changed sections of
the Wish List since it was last released. When a section is deleted, an
explanation as to why is given. I am currently running the OS/2 2.1
ServicePak Beta, which may give different results than the OS/2 2.1 GA.
CHANGED 2.9 MAKE ALL FILES EXECUTABLE
CHANGED 3.5 NEW BOOT SECTOR
CHANGED 5.2 STANDARD DATE TIME AND NUMBER FORMATS
CHANGED 5.4 SUPPORT OF ISO 8859.1 (ISO LATIN-1) CHARACTER SET
DELETION 6.14 IMPROVE THE ICON EDITOR
Using ICONEDIT to edit multi-mode (16x16, 32x32, 40x40, 64x64) 16 and 256
colour icons is awkward. Re-arrange the menus so that it is easy to
switch between different icon formats. Make the editor automatically show
all icon sizes and colour depths. Use the first icon created as a base
for all other icons and provide a way to paste from one icon format to
another.
REASON: another user confirmed that this is already done.
CHANGED 6.15 ENHANCED TASK LIST
ADDITION 6.19 MINIMIZE BUTTON GOES FIRST TO TITLEBAR ONLY, THEN HIDDEN
DELETION 6.18 RETAIN POSITION FOR OS/2 WINDOW
If an OS/2 window starts a DOS program, it should always return to the
same position when the DOS program ends. Sometimes it ends up in the
upper left-hand corner of the screen. Similarly, doing a Restore from a
Maximized window should return the window to it's original position, and
not move the window to the upper left-hand corner.
REASON: I tried the scenario described above and everything worked as it
should - the OS/2 window returned to the right place after returning from
DOS, even when the OS/2 window was maximized.
ADDITION 6.20 ENHANCE FILE DIALOG BOX
ADDITION 6.21 STATE-REVEALING ICONS
ADDITION 7.9 ALLOW MARK AND COPY AS 1 FUNCTION
CHANGED 8.1 GLOBAL CHANGE OPTION FOR THE WPS
ADDITION 8.22 PUT FULL PATH IN IN DIRECTORY TITLEBAR
ADDITION 8.23 ABILITY TO SET DISK LABELS FROM THE DRIVE OBJECT
ADDITION 8.24 ADD 'CHANGE' OPTION TO RIGHT MOUSE BUTTON MENU
ADDITION 8.25 TEAR-OFF MENUS
ADDITION 8.26 SIMPLIFY 'FIND' PAGE
ADDITION 8.27 NO PASSWORD FOR SCREEN SAVER
ADDITION 8.28 ADDITIONS TO THE WPS SHUTDOWN FUNCTION
ADDITION 8.29 'CLEAN DESKTOP' FUNCTION IN THE DESKTOP MENU
ADDITION 8.30 'ACCESSING DISK' NOTICE
CHANGED 9.1 SCROLL-BACK BUFFER FOR OS/2 WINDOWS
CHANGED 9.2 SUPPORT WILDCARD EXPANSION IN THE SHELL
CHANGED 9.13 CD WITH A DRIVE CHANGES CURRENT DRIVE
ADDITION 9.22 ALLOW THE USER TO DROP FONTS ON TO SHELL WINDOWS
ADDITION 9.23 PLUG-AND-PLAY SHELL
ADDITION 9.24 SINGLE COMMAND LINE
ADDITION 9.25 DELETE TO END OF LINE
CHANGED 10.1 SUPPORT MORE VIDEO FORMATS
ADDITION 10.4 SUPPORT FOR MODE AUDIO FORMATS
ADDITION 10.5 ADD DSP SUPPORT
CHANGED 11.2 LIST/KILL PROCESS COMMANDS
MOVED 11.9 PM CONFIG.SYS MANAGER now is 20.5
ADDITION 11.11 SUBDIRECTORY RECUSION FOR FILE COMMANDS
ADDITION 11.12 PROGRAM SCHEDULER
ADDITION 11.13 KEYBOARD DEFINITION UTILITY
MOVED 12.3 SEPARATE DOS DEVICE DRIVERS FROM THE OS/2 CONFIG.SYS now
is now 20.6
ADDITION 12.5 DOS WILDCARD EXPANSION
ADDITION 12.6 DOS HPFS DEVICE DRIVER
ADDITION 12.7 ALLOW SETBOOT /IBD:X TO BE RUN FROM DOS
ADDITION 12.8 USE EXTENDED ATTRIBUTES TO STORE DOS CONFIG INFO
AdDITION 12.9 DRAG-AND-DROP DOS SETTINGS
ADDITION 13.2 SIMPLE WAY TO INSTALL WIN-OS/2 FULLSCREEN DRIVERS
ADDITION 15.3 MAKE ALL APIS PUBLIC
ADDITION 15.4 ENHANCEMENTS TO DOSALLOCMEM
ADDITION 15.5 ENHANCEMENTS TO DOSQUERYMEM
ADDITION 15.6 NEW API - DOSQUERYRESOURCESTATUS
CHANGED 17.2 RECOVERY DISK
ADDITION 17.4 SUPPORT FOR PLUG-AND-PLAY ISA
ADDITION 17.5 PROGRESS INDICATORS
MOVED 20.* OS/2 IN GENERAL is now 98.*
ADDITION 20.3 SEPARATE CONFIGURATION INFO FROM DEVICE DRIVERS
ADDITION 20.4 GET RID OF THE CONFIG.SYS
ADDITION 20.7 DRIVER CONFIGURATION DATABASE
MOVED 21.* CONTRIBUTORS is now 99.*
MOVED 98.* sections that had to do with the CONFIG.SYS are now in 20.*
ADDITION 98.10 UPGRADE SOM TO SOM-II, ADD DSOM W/PEER-TO-PEER
ADDITION 98.11 ADD SUPPORT FOR OPENDOC
ADDITION 98.12 SUPPORT SWAP PARTITIONS
DELETED 98.7 CHANGING THE ROLE OF STARTUP.CMD
STARTUP.CMD has become useless with the introduction of the WPS. Its role
should change to that of a program that is run every time an OS/2 window
is opened. It should contain all environment variables (rather than
having them in the config.sys), so that they can be easily changed without
rebooting the machine.
REASON: Would cause too many problems. Replaced by 9.20.
ADDITION 98.8 OPTIONAL SAVING OF MEMORY STATE TO THE SWAPFILE ON SHUTDOWN
ADDITION 98.9 ABILITY TO CHANGE LIBPATH WITHOUT REBOOTING
----------------------------------------------------------------------------
1.0 THE KERNEL
The OS/2 kernel is showing signs of age in relation to the new breed of
microkernels; listed below are proposed ways to improve it.
1.1 INCLUDE SMP SUPPORT
Included with the base system should be the kernel support for handling
SMP (symmetric multiprocessing). It is understood that most users can not
take advantage of SMP, however its inclusion would be a powerful weapon
against those vendors who claim their operating system is superior because
they support SMP.
1.2 MOVE THE INTEL VERSION TO THE IBM MICROKERNAL
Of course, if you can't beat them, join them. The portable OS/2 versions
(ie: OS/2 for PowerPC) is already moving to the IBM Microkernel and by
moving the Intel version to the Microkernel as well as keeping uniformity
between versions of OS/2 for different architectures. This would allow:
- dynamic loading/unloading of device drivers
- greater stability as device drivers run in user space and not kernel
space
- would provide architecture-independent device support as drivers
interact with the kernel and not directly with the hardware.
- would require less memory
- faster boot off floppy as less has to be loaded at boot time (device
drivers could be loaded as needed by an installation program that would
search for supported devices)
---------------------------------------------------------------------------
2.0 FILE SYSTEMS
This section deals with all wishes directly related to changes and additions
to the OS/2 file systems.
2.1 UTILITY TO CONVERT BETWEEN FILE SYSTEMS
It is very difficult to convince a user to format their FAT drive to install
HPFS. Therefore, a utility to convert between file system formats
non-destructively should be provided.
2.2 INSTALLABLE FILE SYSTEMS FOR REMOVABLE DEVICES
Installable file systems must be made available for removable devices,
including floppies. It is unacceptable for a user with optical disks to
be forced to use FAT instead of a better file system (ie: HFPS)
2.3 LONG FILE NAME SUPPORT IN FAT
Long file name support already exists in FAT, in the form of the .LONGNAME
extended attribute. All file system calls should rely on the .LONGNAME
extended attribute instead of the 8.3 file name to provide transparent
long filename support to the user.
2.4 FILE SYSTEM REQUIREMENTS (see 3.4)
The needs of OS/2 users are constantly changing and the file systems need
to move with them. The following is a list of the new file system
requirements.
- access control lists (ACL) for file security
- journalling
- support extended attributes greater than 64K
- support caches greater than 2 MB
- support a maximum file system size in the terabyte range
- 255 character disk labels
- new file type (in addition to 'File' and 'Directory' called 'Abstract'
to handle symbolic links (shadows) and imbedding objects in to the file
system
- file association in the file system
Most of these requirements would probably require a new file system to
support them. Those that can be implemented in HPFS should be, and those
that can not should be implemented in a new file system.
2.5 MAKE '/' AND '\' ACT THE SAME FOR CHANGING DIRECTORIES
OS/2's API set should be changed to allow changing directories using
either '/' or '\'. This requires changing the command line switch
delimiter to '-' from '/'. It should be noted that except for IBM's
software, most programs already use '-' instead as a command line switch
delimiter.
In addition, the OS/2 IFS definition specifically states that '/' and '\'
should both be usable for changing directories.
2.6 STANDARD TAPE FILESYSTEM
A standard tape-backup filesystem should be provided to allow sharing of
information on tape between OS/2 configurations. The filesystem should be
designed to allow multiple backups on one tape and should allow the backup
of any information stored on a disk filesystem, meaning support for long
filenames, extended attributes, security, etc.
2.7 FILE SYSTEM-INDEPENDENT DISK COMPRESSION
A file system-independent disk compression scheme should be provided with
OS/2 to help offset the increased disk space requirements over DOS/Windows
systems.
2.8 ADDITIONAL FILE SYSTEM SUPPORT
OS/2 should ship with support for the following file systems:
- NTFS
- common UNIX disk formats
- Macintosh
2.9 MAKE ALL FILES EXECUTABLE
Any file should be executable, no matter what its extension. The shell
should first determine whether whatever the user asked it to open is
actually an executable. If it is, the program starts normally. If not,
the file is assumed to be some sort of data file, and the operating system
tries to find the creator (using the extended attributes) of the file and
starts it, instructing the creator to open the file. If it can't find the
creator, it should return back an error message saying that the file was
not executable and the file's creator could not be found. The current
rules for special file extensions should be removed as they are not
appropriate for a free-form filename system. Something like a REXX script
or batch file that generally has no file type could be started as 'cmd
rexxscript'. Typing just the name of a directory would change in to the
directory.
2.10 UTILITY TO VIEW/SET EXTENDED ATTRIBUTES
A utility should ship with OS/2 to allow the user to view and edit a
file's extended attributes. This would be particularly necessary if all
files are considered executable, as the user may want to specially assign
creators for files so they can be automatically opened, or to allow a REXX
script or batch file to run without having to run 'cmd rexxscript'.
2.11 SECURE SYSTEM FILES
Display a warning every time a system file (typically one in the \OS2
directory) is going to be replaced by an application. To implement this,
a file holding the names of files that should not be changed without
giving notice to the user could be used.
2.12 ALLOW OPTIONAL CACHING ON A DRIVE BASIS
The user should be able to specify drives to cache (or not to cache). For
example, the user could ask for drives 'C:', 'D:' 'F:' to be cached, but
not 'E:'.
----------------------------------------------------------------------------
3.0 HANDLING DISKS
Pretty well every OS/2 user agrees that calling disks 'A:', 'B:', 'C:' just
doesn't cut it. Unfortunately, not everyone is agreed on how this problem
should be solved. There are 2 opposing arguments, one for mounting drives
off of a root directory and the other for using the already present disk
labels as disk names.
3.1 DEVICE ALIASES (see 3.2, 3.3, 3.4)
The user should be able to alias a directory to a disk name or a disk to
another disk name. This is to support wishes 3.2, 3.3 and 3.4. This
would be used in the case of wish 3.3 to alias '/' to 'C:', '/floppy' to
'A:'. It would be used in the case of with 3.4 to alias device 'MYDISK:'
to 'C:'.
3.2 DISK DEVICE NAMES (see 3.1)
Instead of calling disks 'A:', 'B:', 'C:', etc, disk devices could be
referenced internally as 'FDx:' for floppies and 'HDx:' for hard drives.
This would allow an unlimited number of available partitions. Device
aliases could be created to alias back 'FDx' and 'HDx' to the DOS
equivalents to allow older software to work while allowing those who have
surpassed the 26 available drives to use their full capacity.
3.3 MOUNTING DRIVES INSTEAD OF HAVING DRIVE LETTERS (see 3.1)
Drives would be mounted as directories off of the boot drive (for example,
'D:' could be mounted as '\applications'). For programs that are not
designed to handle such a system, the root drive would be aliased to 'C:'
and the floppy drives would be aliased to 'A:' and 'B:'.
3.4 USING DISK LABELS INSTEAD OF DRIVE LETTERS (see 3.1)
Disk labels, currently an unused feature of the file systems, could be
used as device aliases as well. For example, if a disk label is
'MYDISK', the drive could be accessed as 'MYDISK:' This would make
accessing disks much more intuitive.
When used on a FAT or HPFS drive, the disk label could only be 11
characters (as that is the current disk label size). Any new file systems
should support 255 characters and the APIs to support the new drive
schemes should support 255 character labels.
Disk labels should be allowed to contain any character usable in the file
systems.
3.5 NEW BOOT SECTOR
The current OS/2 boot sector (created by FORMAT/PMFORMAT) is next to
useless. It displays a cryptic message that few people bother to even look
up. A new boot sector that just skips over the disk and continues the
boot process if it can't boot OS/2 should be implemented.
3.6 BOOTING TAKES TOO LONG (see 1.2)
Booting OS/2 off hard disk is a long process for many users, but loading
off of floppy (for example, during the install process) is almost
unbearable. An unexperienced user could think that the computer has
crashed while booting. As a first step, a progress indicator should
appear telling the user that something is happening. To really solve the
problem would require less to be loaded during the boot process (which
would mean moving to the IBM Microkernel). In addition, reducing the
number of install disks from 2 to 1 would be a big improvement.
----------------------------------------------------------------------------
4.0 DEVICE DRIVERS
Device drivers are at the heart of the operating system and yet they are
often the one of the greatest sources of heartache for users. The
following is a list of wishes designed to fix that.
4.1 SUPPORT
Without device driver support for devices the user can't use their
investments and would likely rather stay in DOS than have to give up
access to their hardware. IBM must do everything possible to get third
party vendors to write device drivers. This includes a service for
vendors to pay IBM to write the device drivers at a reasonable cost.
4.2 QUALITY
Not all third party vendors give the same driver quality that we are used
to IBM providing. To solve this, IBM should have an independent lab to
do device driver testing at low or no charge. IBM should also set up a
volunteer device driver testing corps based on Team OS/2 (maybe even using
Team OS/2 members). IBM could manage a database with each member's
configuration and would make the database available to any manufacturer on
request. This solution would satisfy everyone: it is low cost for IBM to
support and for vendors to use, provides the vendor with diverse system
configurations and would help to provide the user the best quality
drivers.
4.3 ALLOW DYNAMIC LOADING AND UNLOADING OF DEVICE DRIVERS (see 1.2)
OS/2 should allow device drivers to load and unload as desired by the
user. This would be handled easiest by moving to the IBM Microkernel, but
should be made available even if the current kernel is maintained.
4.4 SUPPORT FOR ALL SCSI STANDARD DEVICES
OS/2 should provide drivers for all devices that are part of the SCSI
standard devices, such as tapes, scanners, etc. Each type of device would
get one driver, much like the way SCSI-2 CD-ROMs are handled using the
OS2CDROM.DMD.
----------------------------------------------------------------------------
5.0 OS/2 AS AN INTERNATIONAL OPERATING SYSTEM
OS/2 is designed as an international operating system, to be used anywhere
in the world along with other platforms. Unfortunately, OS/2 in it's
current state is far from being an international operating system; the
following are wishes designed to solve this.
5.1 UNICODE
Unicode support should be included in the base operating system. This
would also remove the need for a different double byte character set
version of the operating system.
5.2 STANDARD DATE TIME AND NUMBER FORMATS (see 14.4, 15.1)
The system date time and number formats (as defined in the Country object
in the System Setup folder' should be used everywhere in the operating
system. Reading huge numbers like those returned by CHKDSK and DIR
which are currently not broken up by the 1000s separator and ambiguous
date formats are almost enough to drive the user insane.
These formats should also be a lot less restricted. The user should be
able to build the formats any way they like. This means the user should
be allowed to do things like 'yyyy-mm-dd' (ISO date format), dd/mm-yy (old
Swedish style) and even things like dd-mmm-yy to get a 3 character short
form for the month.
5.3 SUPPORT FOR 8-BIT CODE PAGES FOR CYRILLIC AND GREEK
OS/2 should have the same 8-bit code pagers for Cyrillic and Greek that is
provided for IBM DOS.
5.4 SUPPORT OF ISO 8859.1 (ISO LATIN-1) CHARACTER SET
OS/2 should support the ISO 8859.1 (also known as ISO Latin-1) character
set, used in other operating systems such as UNIX.
5.5 SUPPORT FOR MORE THAN 2 CODEPAGES
There must be support for more than 2 codepages. As OS/2 becomes more
widely used internationally people need to be able to exchange documents
using different codepages simply.
----------------------------------------------------------------------------
6.0 PRESENTATION MANAGER
This section contains wishes for anything related to the Presentation
Manager, including wishes for INI and icon files.
6.1 INI EDITOR
An INI editor should be included as part of the base system.
6.2 MOVEMENT OF INFORMATION FROM THE OS2.INI TO THE FILE SYSTEM
Icon information etc. should be moved from the INI files in to the file
system in the form of extended attributes. This will allow users to
retain system settings even when replacing the operating system as all the
necessary settings are kept along in the application's extended attributes
which can be backed up, and would ensure that deleted application settings
do not live on forever in the INI files as all settings would disappear
along with the application.
6.3 MULTIPLE INPUT QUEUES
Having PM grind to a halt because of a process holding the message queue
for too long just isn't acceptable. Every thread that uses the PM should
be assigned its own, independent message queue to ensure that the user
can always interact with the system, even if one application goes down.
6.4 CHANGING THE GRAPHICS DRIVER ON-THE-FLY
Being able to change the graphics driver on the fly would be a big plus.
This means that the system should not have to be rebooted to handle the
new driver, and all video changes should take effect immediately.
6.5 COLOURFUL ICONS
The default icon set in OS/2 is a bit bland and unappealing. A splash of
colour would really improve the looks of the WPS.
6.6 RIGHT MOUSE BUTTON ACTION FOR PROGRAMS THAT DON'T USE IT
The commands in the toolbar menu (at the top left corner of each window)
as well as the menubar (in the case of PM application) should form a
right mouse button pop-up menu for applications that do not explicitly
support the right mouse button.
6.7 MOVEMENT OF OS/2 LOGO TO AFTER PM GETS STARTED
Moving the OS/2 Logo to just after PM gets started (as the first thing
that is shown on the screen) just makes more sense - the graphical
environment is up and running and all the routines are there for showing
bitmaps. In addition, it would allow more colourful OS/2 bitmaps to be
shown on start-up without pain.
6.8 OPTIONAL DISABLING OF MENU DROP DOWN ON RIGHT ALT KEY
On many international keyboards, the right ALT key is used to type special
characters such as brackets. An accidental slip on the keyboard while
doing an ALT key combination can cause a menu to drop down, and thus is a
real annoyance. For people using international keyboards, an option
either the Country object or Keyboard object should determine whether only
the left ALT key or both ALT keys should bring down menus.
6.9 BACKGROUND COLOUR ON ICON TEXT
Icon text should have the background colour underneath in order to be able
to see the text with some bitmaps.
6.10 AUTOMATIC CONVERSION OF WINDOWS ICO FILES TO OS/2 ICONS
Windows ICO files should be automatically converted to OS/2 icons, or
there should atleast be a utility included in OS/2 to allow turn the icons
in to OS/2 ones. This is required for DOS software that comes with
Windows icon files.
6.11 USE FONTS LIKE DLLS
A font should only be kept in memory as long as there is a program using
the font; keeping fonts loaded forever is a waste of valuable system
resources. After the last process to use a font is terminated, the font
should be unloaded.
6.12 ALLOW DIRECT MODIFICATION OF INI FILES WITHOUT COPYING THEM
Having to re-copy INI files to change them is terribly wasteful and
should be corrected.
6.13 VECTOR ICONS
Allow vector graphic files in addition to bitmaps and allow the icon to
be scaled to a fixed size no matter what the resolution is.
6.15 ENHANCED TASK LIST
There should be a 'Details' view of the task list, showing more
information about a program - ie: priority, memory usage, idle time, CPU
usage, process ID, parent ID, command line parameters, etc. From here the
user should also be able to change task priorities.
6.16 OPTIONAL 'KEYBOARD FOCUS FOLLOWS THE MOUSE SUPPORT'
Optionally, the user should be able to enable X11-style 'keyboard follows
the mouse pointer' support. The active window and keyboard focus are
changed as the mouse pointer moves from one window to another. Note that
the new active window is not brought to the surface, only the keyboard
focus changes.
6.17 DISPLAY POSTSCRIPT
PC's have become powerful enough to handle Display Postscript, and
definitely the next generation of PC's - the PowerPC's - could handle
display Postscript with no problems at all. With fonts playing an
increasingly important role, it is important for what is on the screen
to look as much as possible as printed output.
6.18 ANIMATED CURSORS
OS/2 should support animated cursors. This means for the alarm clock
cursor, the dial could spin, etc.
6.19 MINIMIZE BUTTON GOES FIRST TO TITLEBAR ONLY, THEN HIDDEN
The minimize button could be (optionally) changed to first minimize down
to the titlebar only and then another click on the minimize button would
hide the window. Pressing the maximize button when at the titlebar-only
stage would bring the window back to its original size. This would be a
great screen saver while not inconvieniencing people with having to keep
running to the Window list to bring up a minimized window.
6.20 ENHANCE FILE DIALOG BOX
Enhance the file dialog box so that it is possible to see the size and
date stamp on a file, in addition to just the file name. An example of
how this would look is the folder Details view in the WPS. Also, be very
desirable to be able to sort the list of files by name, size or date from
within the standard file dialog box.
6.21 STATE-REVEALING ICONS
Icons should reveal the state of the program they belong to. For example,
the printer icon could change to indicate that there are jobs in the
spooler, a minimized interactive program's icon could bink to indicate
waiting on user input, and the minimized folder could 'glow' when
occupied.
-----------------------------------------------------------------------------
7.0 TEXT APPLICATIONS
This section is for wishes related to text applications. While it is
desirable to have most applications as PM programs, reality states that some
programs work best in text mode and can not have the overhead associated
with a graphic interface and these wishes are designed to specifically
address those applications.
7.1 TEXT-MODE MULTI-TASKING
From full screen DOS or OS/2 sessions, CTRL-ESC should bring up the
a text version of the task list rather than switching to the desktop.
Pressing ALT in a full screen session should bring down a text the
equivalent of the toolbar menu for a windowed session, with functions to
mark, copy, paste, change settings, etc. Switching between full screen
sessions should not require switching to the desktop as an intermediate
step.
7.2 TEXTUAL USER INTERFACE
Provide a text user interface API, a type of textual Presentation Manager.
7.3 SWITCHING FROM FULL SCREEN TO WINDOW MODE FOR OS/2 SHELLS
The same ALT-HOME functionality available to DOS shells should be made
available for OS/2 shells. There are features that a full screen shell
can do that a windowed one can't - then again, with DOS shells, there are
resolutions that can be handled in full screen mode that can't in windowed
mode; OS/2 just says 'I can't do that' and pauses the window until it goes
full screen again. Why not do the same thing for OS/2 shells?
7.4 SWITCHING FROM FULL SCREEN TO WINDOW MODE
The same ALT-HOME functionality available to DOS software should be made
available for OS/2 text applications. There are features that a
full screen shell can do that a windowed one can't - then again, with DOS
shells, there are resolutions that can be handled in full screen mode
that can't in windowed mode; OS/2 just says 'I can't do that' and pauses
the window until it goes full screen again. The same type of message
could be given for text applications that try to do unsupportable actions
while windowed.
7.5 USE THE PM METHOD FOR COPY AND PASTE IN TEXT MODE
OS/2's current method for doing copy and paste's from a text session is
very awkward. A much simpler and more natural method should be used,
namely the one implemented for PM applications. The user simply selects
the text they want to copy and then press the standard PM CTRL-INS to
copy and SHIFT-INS to paste.
7.6 MAKE COPY AND PASTE FEATURES AVAILABLE TO FULL SCREEN SESSIONS
There is no reason why full screen sessions should not be able to use the
same copy and paste features of windowed sessions.
7.7 FULL ANSI X3.64 SUPPORT
The complete ANSI X3.64 terminal specification should be enabled for text
sessions.
7.8 VT-100 SUPPORT
Text sessions should have complete VT-100 support.
7.9 ALLOW MARK AND COPY AS 1 FUNCTION (see 7.5)
The Mark and Copy features should be integrated in to 1 action.
----------------------------------------------------------------------------
8.0 WORKPLACE SHELL
The WorkPlace Shell is something a user must interact with every day and so
it is important for the shell to meet the user's needs. The following is a
list of wishes directly related to the WorkPlace shell.
8.1 ADDITION OF MASTER TEMPLATES
'Master Templates' are default settings for any object, like a folder or a
program. By changing the settings in the Master Template, the settings in
every object of that type would also be changed. This will allow the user
to accomplish something like 'make all folders look like this one'. By
default, an object would always inherit any changes to the master;
however, by turning off a setting in the object's settings (named, for
example, 'Inherit from Master') the user could disable such a feature to
allow for customization for specific objects.
Master templates could also be used as a replacement for the command
association features of the WPS. A Master Template for '*.ZIP' could
execute UNZIP when a ZIP file is run.
8.2 MOVEMENT OF SHADOWS IN TO THE FILE SYSTEM (see 2.4)
The Shadows are one of the most complex parts of the WPS because often
users don't understand that a shadow only exists in the desktop.
Therefore, shadows (or 'symbolic links') should become part of the file
system.
8.3 SHADOWS SHOULD STAND OUT BETTER
It is often difficult to tell whether an object is a shadow or not
as the only distinguishing characteristic is a different icon text colour.
Shadows should have a slightly different icon (as templates do), or the
icon text could be in italics.
8.4 RELIABLE WORKPLACE SHELL BACKUP/RESTORE (OS2.INI AND DESKTOP DIRECTORY)
(see 2.4)
There needs to be a way to backup and restore the Workplace Shell setup,
including things like the desktop and object settings. Possibly this
could be achieved most easily through the movement of desktop information
from the INI files to the filesystem where they can be easily backed up
using any backup software.
8.5 RANDOM BACKGROUND SELECTION FOR THE WPS
A list of desirable backgrounds could be selected for the WPS and upon
startup, the WPS could randomly choose a background to display.
8.6 TURNING THE SHREDDER IN TO A TRASH CAN
The Shredder needs to be turned in to a trash can, meaning that files put
in it need to be recoverable. This means tighter integration of the WPS
object with the SET DELDIR= option. Files should remain in the trash can
until they are explicitly cleaned out (as an option in the object and a
command line utility). When there is not enough space to perform a
function, the operating system should first see if there are files that
could be cleaned up to make room. If so, the user is asked if it is
alright to remove files, and then proceeds to make space. If the user
says 'no', or there are no files to remove, the write fails normally.
Files would be removed in chronological order, starting with the oldest
files and proceeding until enough room is made or there are no more files
to remove.
8.7 LIST VIEW FOR OBJECT SETTINGS
There could be a list view for object settings - it would basically be a
dump of all the possible settings there are for the given object, sorted
alphabetically and not grouped together in notebook sections. This would
make it very easy to find a particular setting when you don't exactly know
where to look (but you know what to look for). As many as could fit on
one notebook page would be shown at a time, and arrows at the bottom of
the notebook would allow flipping between pages.
8.8 ENHANCED TASK LIST
There should be a 'Details' view of the task list, showing more
information about a program - ie: priority, memory usage, idle time, CPU
usage, process ID, parent ID, command line parameters, etc.
8.9 STARTING PM APPLICATIONS 'MINIMIZED'
The feature for starting a program minimized should be enabled for PM
applications.
8.10 DEFAULT VIEW OPTION IN OBJECT SETTINGS
Any object for which the type of view can be variable (for example, a
folder can be viewed in the 'Icon' view, 'Tree' view and 'Details View')
should have a default view option.
8.11 ADD GRID/CHANGE THE MEANING OF ARRANGE
The Icon view named 'Non-grid' should be renamed to 'Gridded'. An option
for defining the grid of user-defined size (or to turn off the grid, for
functionality similar to the 'Non-Grid' mode) Arrange would move the icons
to nearest point on a the grid. In addition, there should be an option in
the window settings for to always snap icons to the grid.
8.12 EXPAND ALL BRANCHES/EXPAND TREE FEATURE FOR TREE VIEWS
The user should be able to expand all branches of a tree or to expand
the entire tree while in a Tree view. * and CTRL-* are used in the help
system to provide similar functionality, and their use is recommended
here as well.
8.13 MORE INFORMATION FOR DRIVE OBJECTS/DISK TREE VIEWS
Below the name of the drive in a drive object (ie: 'Drive C') the
amount of free disk space should be shown (note: this should only be
shown for disks that are writable; no matter how long you look at a
CD-ROM, it will always say 0 bytes free). In a Tree view, below each
folder name, the number of files in the directory and the size of the
contents should be displayed.
8.14 SAVE CHANGES MADE BY THE PALETTES IN THE SYSTEM SETUP FOLDER
ALL IBM software, including the help system and INF files, must support
saving changes to fonts definitions, colour schemes etc. made by
performing a drag-and-drop from any of the various 'Palette' objects in
the System Setup folder. This includes the 'Font Palette', 'Colour
Palette' and 'Colour Scheme' objects. Third party vendors should be
encouraged to follow IBM's example.
8.15 OPEN PARENT FOLDER
The ability to open a folder's parent should be available in the 'Open'
section of the right mouse button menu.
8.16 CLOSE OF THE CURRENT FOLDER WHEN OPENING A CHILD FOLDER
Both accessible through the 'Open' section in the right mouse button menu
and by an accelerator key should be the ability to close the current
folder when opening a child folder.
8.17 CASCADABLE MENUS
The user can add items to the right mouse button menus, even sub-menus,
but the user can not add sub-sub menus.
8.18 ASSOCIATE VIEW.EXE WITH INF FILES
Associating VIEW.EXE with INF files will make starting INF files from the
WPS much easier for the user.
8.19 REDEFINE SCALING OF MOUSE SPEED, KEY REPEAT SETTINGS ETC.
The current scale used for mouse speed, key repeat delay, etc. is much to
slow for most users. As most users use the settings at their fastest
rate, there is not much point in having the settings there in the first
place. To make them useful, the fastest speeds need to be many times
faster than those available now.
In additon, the user should be able to disable ballistic tracking for the
mouse for those who prefer linear mouse tracking.
8.20 SHELL WINDOW CLOSING
The WPS should not ask for confirmation to close a shell that is not
running any software programs.
8.21 COLOUR PALETTE CHANGES ICON TEXT COLOUR
Dragging a colour from the Colour Palette should change the icon text
colour for that particular icon (or group of icons if more than 1 is
selected).
8.22 PUT FULL PATH IN IN DIRECTORY TITLEBAR
When the user chooses a directory from the Drives object, the title bar of
the directory window should contain the full path to the directory, and
not just the directory's name. For example, it should say 'D:\MYDIR'
instead of 'MYDIR'.
8.23 ABILITY TO SET DISK LABELS FROM THE DRIVE OBJECT
The user should be able to change a disk label from the Drive object.
8.24 ADD 'CHANGE' OPTION TO RIGHT MOUSE BUTTON MENU
An option to 'Change' a view from one type to another (for example, from
Tree to Icon view) should be added to the right mouse button menu. This
would allow the user to see a different view of a window without the old
view staying on the desktop.
8.25 TEAR-OFF MENUS
Tear-off menus were a rather interesting part of the OS/2 2.0 betas, and
unfortunately were left out of the final product to ensure compatibility
with all existing applications. It would be nice if IBM could resolve the
compatibility problems and return the tear-off menus to OS/2.
8.26 SIMPLIFY 'FIND' PAGE
The notebook 'FIND' page is much too complicated. It should be replaced
with a simple file dialog (slightly modified to handle the WPS).
8.27 NO PASSWORD FOR SCREEN SAVER
The screen saver should not require a password in order to operate.
8.28 ADDITIONS TO THE WPS SHUTDOWN FUNCTION
Two additions are preposed to the WPS shutdown function. First, there
should be an option (in the dialog asking to shut down) to automatically
reboot the machine after shutdown. Second, there should be an option to
unconditionally close all running programs, without asking for the user's
consent.
8.29 'CLEAN DESKTOP' FUNCTION IN THE DESKTOP MENU
A 'Clean Desktop' function should be added to the desktop menu (the one
that appears with the right mouse button). This function would minimize
all open windows.
8.30 'ACCESSING DISK' NOTICE
The initial disk access in the WPS (especially for floppies) can take some
time. A message indicating that the system is, in fact, doing something
should appear so the user is not left wondering what is happening.
----------------------------------------------------------------------------
9.0 SHELLS
A huge number of users prefer using the command line over any other method
of controlling the system, and yet it has not significantly evolved over the
COMMAND.COM from DOS. The following are wishes related to OS/2's shell
(CMD.EXE) designed to remedy this oversight.
9.1 SCROLL-BACK BUFFER FOR ALL SHELLS
A scroll-back buffer of user-definable size should be available for all
shells, be it full screen or windowed, DOS or OS/2.
9.2 SUPPORT WILDCARD EXPANSION IN THE SHELL
The OS/2 command shell (CMD.EXE) should provide wildcard expansion. For
example, a user should be able to 'cd \desk*' to change in to '\desktop'.
As another example, 'copy' would copy all the files in the wildcard
expansion in to the last file given on the command line. Therefore, 'copy
\mydir\* .' would copy all files in '\mydir' in to the current directory.
To ensure that such a change would be safe for the user, commands such as
'copy' would be modified to complain if a file will be overwritten. A
command line switch would override this.
The addition of shell wildcard expansion will also simplify application
development as well, as each piece of software does not need to have its
own wildcard expansion routines.
9.3 COMMAND ALIASES IN CMD.EXE
The OS/2 command shell (CMD.EXE) should support command aliases. This
allows users to alias a complex or cumbersome command with a short, simple
name. Aliases should be executed before any internal commands.
9.4 JUMP-SCROLLING FOR SHELL WINDOWS
Windows currently scroll too slowly - jump-scrolling, whereby only what
can be put to the screen in a reasonable amount of time is shown, would
improve performance dramatically.
9.5 RESIZABLE SHELL WINDOWS
Being limited to fixed resolutions (80x??) is an unnecessary limitation
for shell windows. They should be changed to be dynamically resizable -
simply pull on the resizing borders to resize the screen. During the
process, the title bar could change to show the current resolution.
9.6 RESIZABLE FONT FOR SHELL WINDOWS
Similar to having dynamically resizable shell window resolutions, there
should be dynamically resizable font sizes. The amount of text that could
be shown a one time in the window remains constant, but the font size is
changed (using the resize borders). This should be an option in the
titlebar menu and not default behaviour.
9.7 JUMP-SCROLLING FOR SHELL WINDOWS
Windows currently scroll too slowly - jump-scrolling, whereby only what
can be put to the screen in a reasonable amount of time is shown, would
improve performance dramatically.
9.8 RESIZABLE SHELL WINDOWS
Being limited to fixed resolutions (80x??) is an unnecessary limitation
for shell windows. They should be changed to be dynamically resizable -
simply pull on the resizing borders to resize the screen. During the
process, the title bar could change to show the current resolution.
9.9 RESIZABLE FONT FOR SHELL WINDOWS
Similar to having dynamically resizable shell window resolutions, there
should be dynamically resizable font sizes. The amount of text that could
be shown a one time in the window remains constant, but the font size is
changed (using the resize borders). This should be an option in the
titlebar menu and not default behaviour.
9.10 ANY FONT IN SHELL WINDOWS
Any font, be it bitmapped or an Adobe Type 1, should be available in shell
windows.
9.11 EXTENSIONS TO THE DIR COMMAND
The DIR command should optionally:
- show the .COMMENT extended attribute
- show the number of HPFS extents used by a file
9.12 VERBOSE COPY/MOVE/DEL FOR SHELLS
The copy/move/del etc. commands should, by default, show each file being
processed. An option to process quietly ('/Q' perhaps) should be
available for those not interested in seeing each file being processed.
9.13 CD WITH A DRIVE CHANGES CURRENT DRIVE (see 9.3)
In a shell, using 'CD' with a drive (ie: 'CD D:\MYDIR') changes the
the current directory of the 'D:' drive to '\MYDIR', but does not move
the user to 'D:'. A new command to move the user to the new drive (for
example, 'chddir' or 'cdd' for a short form) should be created to allow
users to use the old method while allowing them to take advantage of the
new one. If aliases are added to CMD.EXE, the user could opt to alias
'cdd' to 'cd' to always change the drive when changing directories.
9.14 ADDITIONS TO SHELL COMMAND HISTORY FUNCTIONS
Pressing 'PAGE UP' in a shell should print out the complete
available command history.
If the user uses the new 'PAGE UP' function or the 'UP' and 'DOWN'
arrows when there is already a command partially entered on the command
line, the shell should try to match the first part of the command with
something in the history. 'PAGE UP' would show all items in the history
that start with the partial command, and 'UP' and 'DOWN' would move to
the next match. Partially completed commands should be matched up to the
current cursor position only. If there are no matches, the system moves
forward or backward as usual and 'PAGE UP' returns 'No Matches'. In order
to implement this feature, OS/2's shell will have to stop moving the
cursor position to the end of the line after searching in the command
history.
9.15 ALLOW OPTIONAL ANSI KEY REMAPPING WITH COMMAND HISTORY ENABLED
It is undesirable to have OS/2 only allow either ANSI key remapping or
command history for shells. This is an unnecessary limitation and should
be removed.
9.16 FILENAME COMPLETION IN SHELLS
Pressing 'TAB' while entering a path in a shell would try to perform
'filename completion', that is, fully resolve the path. The first 'TAB'
would find the first match for the partial command; subsequent 'TAB's
would cycle through the items that match, until it runs out of matches at
which point it restarts at the beginning.
9.17 LICENSE 4OS2 FROM JPL SOFTWARE AS OS/2'S DEFAULT SHELL
Most of the shell wishes could be easily solved by replacing OS/2's
command shell 4OS/2 by JPL Software.
9.18 FIX THE HANDLING OF '*' AND '.' IN A SHELL
The current handling of '*' and '.' in a shell are terribly outdated,
being remnants of the old FAT filesystem. The following is how they
should be interpreted.
'*' = select all files
'*.' = select files ending in a '.'
'.*' = select files starting with a '.'
'myprog' = execute a program named 'myprog'
'myprog.' = execute a program named 'myprog.'
Not that it is not acceptable for '*' to equal '*.' and for a program
named 'myprog' (no extension, as they are not required with free-form
filenames) to only run when it is started as 'myprog.'
9.19 CHANGE WHEN INTERNAL SHELL COMMANDS ARE EXECUTED
Internal shell commands (like copy, del) should only be executed after
searching the path for the program. This would allow people to replace
the default commands with their own versions.
9.20 PROFILE.CMD TO STORE COMMANDS TO RUN FOR OS/2 SHELLS
A program, PROFILE.CMD, should be run every time a shell is opened. It
would contain all environment variables (rather than having them in the
config.sys) so that they can be easily changed without rebooting the
machine.
9.21 FIX RETURN TO PARENT PROCESS FOR SPAWNED TASKS
When returning from a spawned process (for example, the 'HELP' program,
which starts up the system help in another task), control should return to
the shell and not to the WPS.
9.22 ALLOW THE USER TO DROP FONTS ON TO SHELL WINDOWS
Instead of having to go in to the titlebar menu to change the font, the
user should be able to drop any font from the Font Palette on to a shell
window (be it DOS or OS/2).
9.23 PLUG-AND-PLAY SHELL
Implementing some of the proposed changes to the shell will no doubt cause
third party vendors to worry (as they must provide the same level of
functionality to make sales) and possibly users, who may be uncomfortable
with the changes. Thus, it is proposed that IBM turn CMD.EXE in to a
bunch of DLLs, linked together through a single interface, CMD.EXE. In
effect, CMD.EXE would be just a dispatch system - sending out the work to
DLLs. This would allow users to make custom shells to suit their needs
by plugging in different DLLs, and would allow shareware authors and
commercial vendors to use IBM's technology as a stepping stone for their
own products.
9.24 SINGLE COMMAND LINE
A single command line should be created to allow users to execute OS/2 and
DOS software from the same command line. A similar scheme as available
right now for specifying DOS configuration could be used (as part of the
shell options), and the extended attributes could hold specific
configuration options for DOS applications. This would also allow IBM to
remove the entire set of DOS utilities as a DOS program could not tell
whether an application was DOS or OS/2, allowing seamless integration of
the two operating systems.
9.25 DELETE TO END OF LINE
The shell should support a key combination to clear the current command
line to the end of the line.
----------------------------------------------------------------------------
10.0 MULTIMEDIA
One of OS/2's best features is the MMPM/2; the following are suggestions for
making it even better.
10.1 SUPPORT MORE VIDEO FORMATS
Support for the following additional formats should be provided by the
Software Motion Video extension:
- MPEG-I
- MPEG-II (when finalized)
- FLI
- FLC
- Video for Windows 1.0 AVI
- Video for Windows 2
- Indeo 3
10.2 'LOOP FEATURE'
A feature to continuously loop a video clip or sound file (MIDI or Digital
Audio) should be provided.
10.3 UPDATE THE OS/2 CD-ROM VIDEOS
Each full release of OS/2 should come with a totally new set of videos.
They should emphasize human interaction, wild technology and something
that could be used as an in-store demo (an introduction to OS/2, perhaps)
or something that uses the word 'OS/2' in a way that makes the user think
about it.
10.4 SUPPORT FOR MODE AUDIO FORMATS
Support for the following additional formats should be provided by Digital
Audio player:
- AU
- SND
- VOC
- Compressed WAV
10.5 ADD DSP SUPPORT
Support for DSP boards, such as the IBM MWave, should be added to the
MMPM/2 to offload the CPU from such tasks as graphics manipulation,
voice recognition, text-to-speech, audio compression and video playback.
----------------------------------------------------------------------------
11.0 UTILITIES
The following are suggestions for changes to existing OS/2 utilities and
suggestions for additional utilities.
11.1 CONTROLLING PROCESS PRIORITY
Command line utilities for setting process priority should be available.
11.2 LIST/KILL PROCESS COMMANDS
As part of the base operating system, a command to kill processes must be
provided. There must be some means to kill off a program that has gone
awry quickly and simply. In addition, to become useful to the average
user, 'pstat' must be simplified. It is recommended that, by default,
'pstat' should show only the base amount of information (ie: PID of the
main thread and the program command line).
11.3 SHUTDOWN UTILITY
There must be a utility to shutdown from the command line. By default,
it should ask to confirm whether to shutdown the machine or not, but there
should be a command line option to unconditionally shutdown. In addition,
it should have the ability to reboot the machine automatically at the end
of a shutdown. This could then be called by remote users (say, on a
network) who could reboot a troubled machine without having to go down to
the system.
11.4 DEFRAGMENTATION UTILITY
It is unacceptable to have to boot DOS in order to defragment a FAT
partition - especially when many DOS defrag utilities mutilate extended
attributes. A defrag utility for HPFS would be good as well.
11.5 SYNCING UP DOS AND OS/2 UTILITY FUNCTIONS
All command-line utilities, such as DIR and FORMAT, should have the same
functionality as those included with IBM DOS 6.1. This means the same
command line options and the same behaviour (for example, COPY should ask
before overwriting an existing file, FORMAT should be able to QuickFormat,
etc.) Whether OS/2's way of doing things or DOS's way of doing this is
chosen, they should both be the same for compatibility and consistency
across platforms.
11.6 UTILITY FOR FINDING THE OWNER OF A RESOURCE
There should be a utility to show the program and process ID of the owner
of a particular system resource, be it a pipe, queue, device, file, drive
or any other system resource. For example, assuming the program was
called 'OWNER.EXE', the user could type 'OWNER \PIPE\MYPIPE' and find out
that it is owned by 'MYPROGRAM' running at PID 135, along with any other
useful information.
11.7 MIGRATION DATABASE MAINTENANCE
Included in the Migrate program should be a method for updating the
database to change settings as well as adding and deleting programs.
11.8 NEW 'MORE' UTILITY
The OS/2 'more' utility is showing its age and should be replaced with a
faster and more feature-packed version. It should be able to get a
filename to read from the command line (ie: you should be able to type
'more myfile'), it should NEVER scroll when showing a full page (should
clear the screen and show the full page), should have forward and backward
movement using 'UP' and 'DOWN' arrows for moving single lines and 'PAGE
UP' and 'PAGE DOWN' for moving entire pages. 'SPACE' would move forward 1
page, 'RETURN' would move forward 1 line. It must have some kind of
search capabilities.
11.10 TEXT-MODE EDITOR
A text editor that can be used when booting from floppies must be included
for emergency measures. I recommend using the same editor that comes with
IBM DOS 6.1 which is based on TinyEd, an IBM EWS product.
11.11 SUBDIRECTORY RECUSION FOR FILE COMMANDS
All file commands modification, such as 'ATTRIB', 'DEL' and 'COPY' should
have an option to recurse subdirectories. The switch '-r' is recommended
for enabling the recursion option.
11.12 PROGRAM SCHEDULER
Include a program to schedule programs to start at different times during
the day, allowing support for starting programs at any minute, hour, day
of the week, day of the month and month. While it is understood that the
ALARM applet can do it, ALARM is not really designed as a task scheduler,
and furthermore is probably overlooked by many users because it is quirky
to use.
11.13 KEYBOARD DEFINITION UTILITY
The user should be able to define their keyboard as they desire instead of
being restricted to the keyboard layouts defined by the Country setting.
----------------------------------------------------------------------------
12.0 DOS
One of the benefits of OS/2 over any other operating system is its ability
to run both existing applications as well as the newer, faster and more
functional OS/2 ones. The following are suggestions to keep OS/2's DOS
support on the cutting edge.
12.1 UPDATE DOS CODE
OS/2's DOS code should updated to IBM DOS 6.1 or higher and should include
full DPMI 1.0 support.
12.2 AUTOMATIC TRUNCATION TO 8.3 FILENAMES IN DOS/WINDOWS APPLICATIONS
Currently, OS/2 will only show filenames that are 8.3-compatible in a
DOS/Windows session, which is an extreme problem for those of us with HPFS
drives and like to use the long filename feature to its full potential.
12.4 BETTER SVGA IN DOS WINDOWS SUPPORT
OS/2 needs better SVGA support for DOS window sessions. All resolutions
supported by a card should be available for windows. As long as a window
would not cover more area than available on the desktop it should be shown
(or perhaps a method for 'squishing' the windows to make them fit on the
desktop could be developed).
12.5 DOS WILDCARD EXPANSION
DOS wildcard expansion should be changed to act exactly as in IBM DOS 6.1.
12.6 HPFS DEVICE DRIVER
Create a device driver to seemlessly handle HPFS disks when booting from
real DOS and offer to include it in a user's DOS CONFIG.SYS, if present.
12.7 ALLOW SETBOOT /IBD:X TO BE RUN FROM DOS
Having this command would allow the user to boot OS/2 from DOS without
having to go through the Boot Manager.
12.8 USE EXTENDED ATTRIBUTES TO STORE DOS CONFIG INFO (see 9.24)
The extended attributes would store a list of device drivers and
environment settings (like EMS, XMS, priorities, etc) for a DOS program,
so that any time the program is run it's specific configuration is
enabled. This moves the dependance on configuration information from the
shell to the application, where it belongs in the first place.
12.9 DRAG-AND-DROP DOS SETTINGS
It should be possible to drag the DOS settings from one program to another.
This would greatly simplify the configuration of DOS programs.
----------------------------------------------------------------------------
13.0 WIN-OS/2
Everyone said IBM could never get Windows to run under OS/2, and yet they
did and it runs amazingly under most configurations. To enhance IBM's
support for Windows, the following wishes were made.
13.1 WIN32S SUPPORT FOR WINOS/2
Win32s support should be included as part of the base system to allow
users to run such applications as MathCad 4.0.
13.2 SIMPLE WAY TO INSTALL WIN-OS/2 FULLSCREEN DRIVERS
Provide an easy way to change the Win-OS/2 FS device drivers to
the manufacturers accelerated ones. One of the biggest problems
with Win-OS/2 is the slow FS performance. This turns off many
people moving from Windows. Including the video card manufacturers
accelerated drivers with an option to install them as the FS ones
would help improve this perception.
----------------------------------------------------------------------------
14.0 REXX
REXX is one of the greatest features of OS/2 because of its simple way of
allowing any user to write very powerful programs. The following are
suggestions to make a good thing even better.
14.1 INTEGRATION OF REXX QUEUES WITH API QUEUES
Why must there be two separate queues in OS/2 - the system queues invoked
using the API calls and the REXX queues? Would it not make more sense to
have both use the same queues? The transmission between the API calls and
REXX could be done using shared memory which is freed after the element is
taken off the queue. All that would be passed through the queue would be
the address to the shared memory segment. This would not only remove the
confusion as to why there are two separate queues, but would allow the
user to create very powerful yet simple software with REXX-based clients
talking to a C-based server using queues.
14.2 MORE INTEGRATION OF THE WPS AND REXX
The ability to query and control objects is greatly needed in REXX. This
means passing data to and from an object, as well as doing things like
instantiating objects (for example, opening a WPS folder). Being able to
query objects would make it much easier to document and compare object
settings.
14.3 PROCESS CONTROL AND SHUTDOWN COMMANDS FOR REXX
REXX should have commands to allow process control (starting new tasks,
killing tasks, setting process priority) as well as a command to shutdown
the system.
14.4 INTERNATIONAL FUNCTIONS (see 5.3)
To implement the standard formats asked for in section 5.3, the REXX API
must be expanded to handle the conversion of date, time, floating point
and integer numbers, currency, etc. to and from string formats.
----------------------------------------------------------------------------
15.0 API SET CHANGES
The following are requests for changes or additions to the OS/2 API set.
15.1 INTERNATIONAL FUNCTIONS (see 5.3)
To implement the standard formats asked for in section 5.3, the OS/2 API
must be expanded to handle the conversion of date, time, floating point
and integer numbers, currency, etc. to and from string and number
formats.
15.2 APIS FOR ALL STANDARD SCSI FUNCTIONS
OS/2's API function set should be expanded to include any standard SCSI
device, such as CD-ROMs, scanners, tape drives, etc.
15.3 MAKE ALL APIS PUBLIC
It is unacceptable for part of OS/2's API set to still be hidden away,
forcing programmers to hack the libraries to find out how to use these
functions.
15.4 ENHANCEMENTS TO DOSALLOCMEM
Two new memory allocation types should be added for DosAllocMem. The
first is PAG_RESIDENT which would make the memory object from being paged
out or discarded. This would be helpful for those programs that need to
have deterministic behaviour in order to maintain real-time I/O
responsiveness in heavy workload situations.
The second memory allocation type is PAG_DISCARDABLE which would allow
OS/2 to throw away the contents of pages of the object rather than paging
them out. This would be useful for application-managed caches. For
example, DB2/2 could cache database information in a higher-level form
than depending on file system caches. Multimedia applications could cache
recently used images or read-ahead data to improve responsiveness to the
user.
Two new exception type should be added to help applications using
discardable memory to handle accessing pages that have been discarded. The
first exception could be named XCPT_PAGE_NOT_PRESENT and would be issued
when an attempt to access a discarded page is made. The default behaviour
would be to terminate the application.
The second exception type could be named XCPT_DISCARDING_PAGE and would be
issued whenever a range of discardable pages are being thrown out. This
would help applications update status tables to reflect that pages have
been discarded. The default behaviour would be to ignore the exception
and continue.
15.5 ENHANCEMENTS TO DOSQUERYMEM (see 15.4)
DosQueryMem should be modified to be able to report resident and
discardable page types and also to be able to report whether a discardable
page is present (in RAM) or not present (it was discarded).
15.6 NEW API - DOSQUERYRESOURCESTATUS (see 15.4)
A new API call named DosQueryResourceStatus should return the amont of
used and unused physical resources such as physical memory, virtual memory
and CPU time. This would aid programs that maintain caches allocated with
PAG_DISCARDABLE by giving them more informatino to decide how big to make
discardable caches.
The following is a proposed definition for DosQueryResourceStatus.
APIRET DosQueryResourceStatus( PID processID, RES_TYPE sourceType,
RES_MEASURE resourceMeasure, RES_UNIT resourceUnit, PULONG pResult );
processID - process ID for which information is to be returned or 0 for
global information for the entire system
resourceType - type of resource: RESTYPE_PHYSICAL_MEMORY,
RESTYPE_VIRTUAL_MEMORY, RESTYPE_DISCARDABLE_MEMORY RESTYPE_CPU_TIME
resourceMeasure - type of measure: RESMEAS_UNUSED, RESMEAS_USED
resourceUnit - unit to use for results: RESUNIT_BYTES, RESUNIT_PAGES,
RESUNIT_PERCENT, RESUNIT_MILLISECONDS
pResult - pointer to 32-bit unsigned integer to receive the result
----------------------------------------------------------------------------
16.0 PRODUCTIVITY FOLDER
OS/2's productivity folder should be one of the highlights of the operating
system, and yet it the applications contained in it are rarely used. To
remedy this problem, the following wishes should be taken in to
consideration.
16.1 REVAMPING THE PRODUCTIVITY FOLDER
The productivity folder should not only be made up of useful applications,
but should also be a reflection of what OS/2 is capable of. They should
be technology statements. This means that the applications should be
usable, should be SOM-based, support standards like OpenDoc when
applicable, etc. They are often the first exposure a user has to OS/2
applications, and IBM should do everything possible to make sure it is a
positive first step.
16.2 PROVIDE BASE WORD PROCESSING ABILITIES
A small word processor should be included with the operating system. It
would have to support things like multiple fonts, bold, underline, etc.
This might be a good way to show off OpenDoc.
----------------------------------------------------------------------------
17.0 INSTALLATION AND CONFIGURATION
Installing OS/2 has been a horrible experience for many users; the following
suggestions are designed to simplify the install procedures and make sure
they work for everyone.
17.1 A SIMPLE, ROCK SOLID INSTALL PROCESS
OS/2 has in the past had a reputation for a terrible install process.
Whether many of the problems have been solved or not, the fact remains
that many people still have problems, and even more people fear installing
OS/2 in the first place because they have heard about the 'OS/2 Install
Monster'.
In addition to just installing the operating system, the install program
should do some initial hardware testing and provide useful feedback to
the user about what to do to correct any problems. Things to be checked
include:
- cache memory (works or not)
- change line in diskette drives
- proper operating of parallel port
and anything else that could cause problems for OS/2 down the line.
17.2 RECOVERY FLOPPY/PARTITION
OS/2 should allow the user to create a 'Recovery Disk', with only the code
needed to get the particular installation of OS/2 up and running for
correcting problems, replacing system files, etc. The user should
be able to specify whether they want to make a recovery floppy or a
recovery partition - the partition, in conjunction with Boot Manager,
would allow a user to boot off hard drive to fix problems. Either way,
these options would allow the system to boot much quicker than using the
2 install disks.
17.3 COMMON INSTALL/UNINSTALL PROGRAM
A single, common install and uninstall program should come with OS/2 and
IBM should insist that all 3rd party vendors make use of it. This install
program should even be used for the OS/2 installation. I recommend the
one that comes with IBM SearchManager/2. Whichever install program is
chosen, it MUST have the ability to selectively install software - down
to individual productivity applications, and the user should have the
option of where to install each individual package (possibly down to the
application level if the configuration would allow it). This install
program must also support CID and allow LAN adminstrators to create their
own CID scripts. The process for creating CID scripts should be documented
to allow anyone to make configuration scripts. When uninstalling, all
traces of the program's existence should disappear, including entries in
any system INI file.
17.4 SUPPORT FOR PLUG AND PLAY ISA
OS/2 should support the Plug and Play ISA specification by Microsoft and
Intel to ensure simple installation and configuration of ISA bus cards.
17.5 PROGRESS INDICATORS
Any task that will take longer than 5 seconds to accomplish should have a
progress indicator to assure the user that the system is, in fact, still
functioning.
----------------------------------------------------------------------------
18.0 DOCUMENTATION
Some parts of OS/2 have not been documented very well or not at all. The
following are suggestions of which parts should be included as on-line
documentation or enhancements to existing documentation.
18.1 MORE ON-LINE DOCUMENTATION
The provision of the 'User Guide' and 'Installation Guide' as INF files
would be much appreciated.
18.2 MAKE THE OS/2 TECHNICAL LIBRARY FREELY AVAILABLE
Releasing the complete IBM OS/2 Technical Library would be greatly
appreciated by all OS/2 users. If this is not possible, at least the
OS/2-specific parts should be released. This includes such items as the
Redbooks. They are chocked full of useful information for any OS/2 user
and would be put to good use by many people.
18.3 AN ON-LINE, IN-DEPTH DESCRIPTION OF THE CONFIG.SYS
There should be an on-line, in-depth description of the CONFIG.SYS
consolidated in one INF file. This file should have descriptions of each
and every valid command in the CONFIG.SYS, along with useful tips and
recommendations.
----------------------------------------------------------------------------
19.0 PACKAGES
The following are packages that are not included in the base system and
should be for future releases.
19.1 PEER-TO-PEER IN BASE SYSTEM
The base OS/2 kit should include some sort of peer to peer networking as
an option. Basic TCP/IP networking would be good for cross-platform
networking.
19.2 INCLUSION OF EPM SOURCES (*.E) AND ETPM COMPILER
The EPM sources (*.E) and ETPM compiler should be included in the base
operating system.
19.3 C2 SECURITY IN BASE SYSTEM
Optional C2 security should be available in the base system, complete with
a file system to handle file permissions. Support for even higher levels
of security would be great, as a separate product.
19.4 USE THE CD-ROM VERSION OF OS/2 TO PROMOTE OS/2-SPECIFIC SOFTWARE
Include sample OS/2 programs from commercial and shareware vendors (demos,
product information, etc.) with an easy way to order these programs or 800
numbers to call for more information. Optionally, each company could pay
for the space used on the disk (which would also subsidize the cost of the
disks) but small vendors and shareware authors that produce OS/2-only
software should have the opportunity to be listed at little or no charge.
19.5 PROVIDE A SEPARATE OS/2 SOFTWARE CD WITH OS/2 ON CD-ROM
Ship each version of OS/2 on CD-ROM with an extra CD of vendor software.
Each disk would contain fully featured OS/2 applications that work for a
limited number of uses (say, 10 uses). After that, the application must
be paid for (by using an 800 number). When ordering the application, the
user receives a key to unlock that application so it can be used unlimited
times, and the user would have the opportunity to order manuals etc. on
the phone.
19.6 INCLUDE MORE EWS PROGRAMS IN THE BASE PRODUCT
The IBM Employee Written Software collection is chocked full of really
useful software. The entire EWS collection should be provided in the
CD-ROM version. The floppy version should contain the most useful of the
EWS programs - namely TinyEd, ExDesk, MSHELL/TSHELL, etc.
----------------------------------------------------------------------------
20.0 CONFIG.SYS
The CONFIG.SYS can be a mortal enemy for some users. It is difficult to
update and often a little frightening to the novice user. The following are
recommendations designed to solve that.
20.1 MULTIPLE-LINE CONFIG.SYS ENTRIES
CONFIG.SYS entries should be allowed to span multiple lines to enhance
readability and ease of editing the CONFIG.SYS with editors that can not
handle the long lines. Entries that span multiple lines could, for
example, be enclosed in double quotes ("") or the end of a line could be
delimited with two pipes (||).
20.2 ABILITY TO CHANGE LIBPATH WITHOUT REBOOTING
Not being able to change the LIBPATH without rebooting is a real problem.
The user should be able to change the LIBPATH that all new processes will
inherit; existing processes will retain their existing LIBPATH.
20.3 SEPARATE CONFIGURATION INFO FROM DEVICE DRIVERS (see 9.20)
The only thing the CONFIG.SYS should hold is device drivers, and even
then, only OS/2 device drivers. Putting configuration information (like
the LIBPATH, environment variables) in to the CONFIG.SYS makes OS/2 a
problem to reconfigure as the system needs to be rebooted for changes to
take effect. Such configuration information should be kept in the
PROFILE.CMD and executed for every OS/2 process that is started.
20.4 GET RID OF THE CONFIG.SYS
Of course, the real solution is to replace the CONFIG.SYS all together.
It should be replaced by a WPS based configuration manager, where all the
work the user would have to do is to find the file for the driver to add
and drop it on to the configuration manager. From there the user could
change what order the drivers should be started in, parameters to pass to
the drivers, etc. The configuration information could be stored in an INI
file somewhere.
20.5 PM CONFIG.SYS MANAGER (see 20.4)
A PM CONFIG.SYS manager is required to help the user get their machine
configured as they need it hassle-free until such time as it can be
replaced by the WPS Configuration Manager.
20.6 SEPARATE DOS DEVICE DRIVERS FROM THE OS/2 CONFIG.SYS
It is unnecessarily complex to have OS/2 device drivers included in the
same file as DOS device drivers. Another file should be used to hold DOS
device drivers instead. It would replace the DOS_DEVICE setting in the
program settings for a DOS program; instead, only an option to specify a
path to the file should be provided. Any option that is allowable in a
DOS CONFIG.SYS should be allowed in here; OS/2 can choose to ignore those
that do not apply.
20.7 DRIVER CONFIGURATION DATABASE (see 20.4, 20.5)
A database-based tool for configuring device drivers could be created to
simplify their management. The database would contain infomration on what
swithes exist, what they do, which drivers must be loaded before this
driver can be loaded, examples of use, etc. A GUI utility would use this
database to help the user edit the CONFIG.SYS.
----------------------------------------------------------------------------
98.0 OS/2 IN GENERAL
The following are items that do not fit in to any other category.
98.1 MAINTAINING THE NUMLOCK STATE (AS DEFINED BY THE BIOS)
On bootup, OS/2 should leave the NUMLOCK state alone, as it is defined in
the BIOS. For machines without a BIOS option for NUMLOCK, the NUMLOCK
state could be defined by an environment variable (for example, 'SET
NUMLOCKSTATE=[ON|OFF|DEFAULT]')
98.2 BETTER INTERNET SUPPORT
IBM needs to provide better support to people on the Internet. This means
assigning people to monitor the Usenet newsgroups (comp.os.os2.*), making
available Internet-addressable mailboxes for IBM support, making IBM
support board message areas Internet accessible and especially keeping
the IBM Internet site complete and up to date (software.watson.ibm.com).
This means that EVERYTHING available on IBM's Support BBS in Boca Raton
should be on this system at the most 1 day after it appears in Boca
Raton. Of course, making the IBM's Support BBS Internet-accessible would
be the optimum solution.
98.3 CHANGE CTRL-ALT-DEL MEANING
The first CTRL-ALT-DEL should bring up a window asking the user whether
they would like to kill the application that had the keyboard focus at the
time of the CTRL-ALT-DEL, reboot the machine or cancel. The second
CTRL-ALT-DEL will unconditionally reboot the machine.
98.5 BOOT DRIVE SELECTION
There should be a variable in the CONFIG.SYS to denote the boot drive,
which could be used for anything (such as LIBPATH entries or entries in
the OS2.INI) that knows it will always be running from the boot disk.
This would give a sort of disk independence for boot disks and make the
task of transferring configurations much simpler.
98.6 SLIM OS/2
There should be an OS/2 that will run in less than 4 MB (ie: start up in 2
MB, but for performance run in 4, much like OS/2 starts in 4 now but for
performance people use 8). It should also use less disk space.
98.8 OPTIONAL SAVING OF MEMORY STATE TO THE SWAPFILE ON SHUTDOWN
The user should be able to save the memory state of the machine to the
swapfile as an option during shutdown. This would allow the machine to
start up with all programs and documents opened to the exact place they
were before shutting down.
98.10 UPGRADE SOM TO SOM-II, ADD DSOM W/PEER-TO-PEER (see 19.1)
Upgrade OS/2's SOM and the WPS to SOM-II. When Peer-to-Peer services are
installed, install DSOM.
98.11 ADD SUPPORT FOR OPENDOC (see 16.1)
Support for OpenDoc should be included with the operating system.
98.12 SUPPORT SWAP PARTITIONS
OS/2 should support swap partitions in addition to swap files. Swap
partitions eliminate costly file I/O overhead by allowing the operating
system to do block writes right to the device. OS/2 should also support
multiple swap partitions, allowing the user to spread the swap activity
over many disks.
98.13 KEYBOARD DEFINITION UTILITY
The user should be able to define their keyboard as they desire instead of
being restricted to the keyboard layouts defined by the Country setting.
----------------------------------------------------------------------------
99.0 CONTRIBUTORS
Without the many contributors from networks all over the world, this list
would not be possible. I would like to thank each and every person who
helped me make this list what it is today.
Abbott, Darren (abbott@batman.dynetics.com)
Aiyagari, Sanjay (sanjay@cs.columbia.edu)
Babcock, Bob (peprbv@cfa0.harvard.edu)
Behrens, Frank (frank@sax.sax.de)
Bononno, Robert (bononno@acf2.nyu.edu)
Cadiz, Bombim (cadizht@csgrad.cs.vt.edu)
Caldwell, Larry (larryc@teleport.com)
Caples, Jon (jcaples@netcom.com)
Cox, Sam (slc00@lvld.hp.com)
Derbyshire, Drew (software@kew.com)
Dhir, Al (adhir@betelgeuse.iagi.com)
Duffy, Patrick (duffy@theory.chem.ubc.ca)
Fahller, Bjorn (bjorn@ludd.luth.se)
Freeborg, John (johnf@persoft.com)
Freeman, Jerry (n6140299@henson.cc.wwu.edu)
Gurganus, James (gurganus@ecn.purdue.edu)
Harden, John (johnh@splat.com)
Heiden, John (jheiden@uoft02.utoledo.edu)
Henry, Andrew (bspahh@ss1.bath.ac.uk)
Hernandez, Manolo (manolo@rcf.rsmas.miami.edu)
Huttunen, Ari (ari.huttunen@hut.fi)
Jensen, Lew (lrj@helios.tn.cornell.edu)
John, Michael Raine (michael-raine@uiowa.edu)
Karasch, Bernt (bernt.karasch@ruba.rz.ruhr-uni-bochum.de)
Kiehl, Horst (h.p.kiehl@kfa-juelich.de)
Kint, Rene (kint@tudebg.et.tudelft.nl)
Knotts, Brian (bknotts@mcimail.com)
Kwilas, Kris (kris.kwilas@gco.com)
Lassiter, Vincent (lassiter@pentagon-hqdadss.army.mil)
Leung, Tedman (tedman@sfu.ca)
Liskov, Nate (nate@miki.lcs.mit.edu)
Longton, Andrew (1:109/347)
Hamblen, Nathan (nathan@crl.com)
Hanser, Per M. (perhans@mmf.ruc.dk)
Hovarth, Joshua (pari4038@nova.gmi.edu)
Mack, Thomas (mack@ips.cs.tu-bs.de)
Mackintosh, David (1:163/557)
Martin, Steve (steve@dlomas.com)
Masalehdan, Babak (tillman+@pitt.edu)
Menard, Francois (1:257/445)
Narramore, Mattison (jmn@gandalf.rutgers.edu)
Patanen, Jani (japa@mits.mdata.fi)
Petrilli, Jack (jack.petrilli@rose.com)
Regoli, Luca (mc0280@mclink.it)
Roderick, Richard (richard@kira.csos.orst.edu)
Rodgers, R S (rsrodger@wam.umd.edu)
Salo, Mike (1:282/108)
Samuel, Joshua (josh@werple.aphana.org.au)
Shiu, Venone (h9218919@hkuxa.hku.hk)
Skinner, Joseph (joe@jsnode.equinox.gen.nz)
Swackhamer, Jay (c/o Evan Champion, evanc@spatial.synapse.org)
Swanson, Craig (Craig_Swanson@f354.n202.z1.fidonet.org)
Tan, Cheng-Yang (cytan@tristan.tn.cornell.edu)
Teittinen, Marko (marko@cs.umd.edu)
Timms, Ian (itimms@ariel.ucs.unimelb.edu.au)
Veronese, Luciano (veu@necsy.it)
Vezeau, Danny (spice@bmerha2f.bnr.ca)
Vulis, Dimitri (dlv@bwalk.dm.com)
Wiley, George (magrw@levels.unisa.edu.au)
--
EVAN CHAMPION ==================================================
Team OS/2 Member! To add your ideas to the OS/2 Wishlist,
Ottawa, Ontario, Canada mail to: evanc@spatial.synapse.org
================================================================
Technical Details
Message-ID:
<2d380870.5350415449414c@spatial.synapse.org>Path:
arc1-ca.pugleaf.net!gmd.de!newsserver.jvnc.net!news.edu.tw!news!nctuccca.edu.tw!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!news2.uunet.ca!uusynap.synapse.org!spatial.synapse.org!evancShow Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1044c2,f63ae696bae4295c,start X-Google-Attributes: gid1044c2,public X-Google-Thread: 10cd94,f63ae696bae4295c,start X-Google-Attributes: gid10cd94,public X-Google-ArrivalTime: 1994-01-15 08:49:13 PST Path: arc1-ca.pugleaf.net!gmd.de!newsserver.jvnc.net!news.edu.tw!news!nctuccca.edu.tw!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!news2.uunet.ca!uusynap.synapse.org!spatial.synapse.org!evanc From: evanc@spatial.synapse.org (Evan Champion) Newsgroups: comp.os.os2.misc,bit.listserv.os2-l Subject: OS/2 Wishlist [94-01-14] Distribution: world Message-ID: <2d380870.5350415449414c@spatial.synapse.org> Date: Sat, 15 Jan 1994 10:14:56 -0500 X-Newsreader: TIN [version 1.2 PL2] X-Posting-Software: UUPC/extended 1.12h inews ( 7Jan94 11:16) Lines: 1806