OS/2 Shareware BBS: 14 Text/14-Text.zip/os2wish.zip/wishlist.os2

Text File | 1994-03-19 | 139KB | 3,124 lines

OS/2 Wish List -- Last Updated: 94-03-19

INTRODUCTION

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 shareware authors.

WHERE TO FIND THE WISH LIST

PLEASE send this list everywhere you can!

In the following, a * denotes a site that I personally update, and therefore
has the most up-to-date versions available.  All other sites are updated on
a weekly basis through a mailing list (see the end of this section for
details).

The following FTP sites carry the Wish List:

  Site                  IP Address      Location

* ftp.synapse.org       192.197.166.1   /pub/wishlist
  ftp-os2.cdrom.com     192.153.46.2    /pub/os2/2_x/info

NOTE:  uunet.ca has not begun monitoring the nameserver at synapse.org,
       so ftp.synapse.org will return Unknown Host.  The IP should work
       perfectly fine.

The following FidoNet sites have the Wish List available for FREQ

  Site          Magic File Name

* 1:163/590.0   WISHLIST
  2:51/2.0
  2:500/218     WISHLIST

The following OS2Net sites have the Wish List available for FREQ

  Site          Magic File Name

  81:431/19     WISHLIST

The following Information Services carry the Wish List

  Site                  Area

  America On-Line       OS/2 Forum
  BIX                   ibm.os2/listings
  CompuServe

The following BBSs carry the Wish List

  Site                          Phone Number            Country

* Kinloch Castle OS/2           613 224-9274            Canada
  Exec PC US
  Greater Chicago On-Line       708 895-4042            US
  Minnesota OS/2 User's Group   612 379-8272            US
    When loging in, specify that you are interested in the
    OS/2 User Group section.
  Techni-Link                   X.25 NUA 26410420       Italy
                                X.25 Inside Italy 1421
                                v.32bis [phone]
                                HST     [phone]
                                v.23    [phone]
  The Beaver's Nest             31-53-337444            The Netherlands

The following Internet-accessible BBSs carry the Wish List

  Site                          IP Address

  mclink.mclink.it              192.106.166.93

The following Newsgroups carry the Wish List:

  Group                         Reposted Every...

  Z-NETZ/RECHNER/IBM/OS2        2 weeks

If you would like the list mailed to you every week, please mail me and I
will add you to the distribution list.  Please note what format you'd like
the Wish List to appear in.  The current choices are plain text, zipped and
uuencoded, or no Wish List at all -- just a note that a new version is
available from ftp.synapse.org.

If you want to receive the text version of the Wish List, please make sure
your mail system can support up to 200K messages.  If you want to receive
the zipped and uuencoded version, your mail system must support up to 100K
messages.  Please check with your system administrator before subscribing.

GETTING YOUR WISHES ADDED TO THE LIST

To add your wish to the list, please mail to '[e-mail]'
(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!  All contributors are credited at the end of the list.

NOTE:  This will be the last release of the Wish List before voting beings.
       Please mail any additions/changes ASAP in order for them to be
       reflected in the list people will be voting on.

WARNINGS ABOUT THE LIST

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 become familiar
with the additions and to update their software.
----------------------------------------------------------------------------
TABLE OF CONTENTS

0.  CHANGE LOG
1.  USER & DEVELOPER RELATIONS/SUPPORT
2.  PACKAGES
3.  THE KERNEL
4.  MULTITASKING, MULTITHREADING AND 32-BIT CODE
5.  MEMORY AND VIRTUAL MEMORY
6.  DEVICE SUPPORT
7.  REFERENCING DISKS
8.  FILE SYSTEMS/FILE ACCESS
9.  LOCALIZATION
10.  PRESENTATION MANAGER
11.  WORKPLACE SHELL
12.  TEXT APPLICATIONS
13.  COMMAND LINE SHELL
14.  INSTALLATION
15.  SYSTEM CONFIGURATION
16.  MULTIMEDIA
17.  DOS
18.  WINDOWS
19.  REXX
20.  UTILITIES
21.  APPLETS
22.  HELP SYSTEM
23.  DOCUMENTATION
24.  PRINTING
98.  OS/2 IN GENERAL
99.  CONTRIBUTORS
----------------------------------------------------------------------------
0.0  CHANGE LOG

ADDITION  1.8  USABILITY TESTING
CHANGE    2.5  ADOBE TYPE MANAGER
ADDITION  2.14 OS/2 FOR DOS
CHANGE    8.1  FILE SYSTEM REQUIREMENTS
CHANGE    8.9  CACHING ENHANCEMENTS
ADDITION  8.18 MANIPULATION OF OPEN FILES
ADDITION  8.19 FLOPPY EJECTION/DISK CHANGE RECOGNITION
CHANGE   10.1  MOVE OS2.INI IN TO THE FILE SYSTEM
CHANGE   10.9  X11-STYLE WINDOW CONTROL
CHANGE   10.12 FILE DIALOG
ADDITION 10.27 SYSTEM MODAL DIALOGS
ADDITION 10.28 MAXIMIZED WINDOWS
CHANGE   11.9  DRIVE OBJECTS/DISK TREE VIEW TO GIVE MORE INFORMATION
CHANGE   11.20 'FIND' FUNCTION
CHANGE   11.22 WPS SHUTDOWN FUNCTION
CHANGE   11.42 ARRANGE
CHANGE   11.49 SCHEME PALETTE
ADDITION 11.51 SHUTDOWN FOLDER
ADDITION 11.52 STARTUP/SHUTDOWN FOLDER ENHANCEMENTS
ADDITION 11.53 ICON DISPLAY
ADDITION 11.54 POPUP MENUS
CHANGE   12.1  TEXTUAL USER INTERFACE
CHANGE   12.3  PM-STYLE COPY AND PASTE
CHANGE   13.17 ENHANCE COPY
ADDITION 15.9  ENVIRONMENT VARIABLE SUBSTITUTION IN CONFIG.SYS
ADDITION 17.19 DESQVIEW TIME SLICES
ADDITION 17.20 SLOW DOWN DOS SESSION
ADDITION 18.7  WINOS/2 FULL SCREEN
CHANGE   20.13 FDISK ENHANCEMENTS
ADDITION 20.19 STANDARD ARCHIVER
CHANGE   21.2  BASE WORD PROCESSING
ADDITION 21.8  MOUSE POINTER EDITOR
ADDITION 23.5  THE BIG PICTURE
CHANGE   98.7  MULTIPLE VIDEO CARD SUPPORT
ADDITION 98.11 REMOVE HARDCODED PATHS IN INI FILES
----------------------------------------------------------------------------
1.0  USER & DEVELOPER RELATIONS/SUPPORT

While IBM generally does a good job in supporting users and developers,
there is definitely a lot more can be done.  The following are some
suggestions.

1.1  DRIVER 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.

1.2  DRIVER 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.

1.3  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.

1.4  ENCOURAGE DESIGN BY GROUPS

  IBM should encourage vendors to get together as groups to design software
  for OS/2.  This means things like device drivers, file systems, common
  functionality for applications, etc.  This will help the user enormously
  by creating some form of standards for third party support.

1.5  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.

1.6  BUY OFF DEVELOPERS

  Let's face it -- OS/2 needs some serious applications, and fast!  IBM
  needs to do everything possible, including the transfer of large amounts
  of money or the equivalent, to make developing in a smaller OS/2 market
  much more lucrative.  This also includes getting OS/2 games.  IBM should
  pay some of the top game companies to only release their next few games
  for OS/2 -- that will definitely encourage more home users to make the
  switch, and having more applications will get the attention of the
  corporate world.

1.7  PUBLISH IFS SPECIFICATION

  IBM seems to be very reluctant to give out details on Installable File
  System development.  This is probably why both DCF/2 and Stacker do not
  use IFSs like they outght to.  It is inexcusable for IBM to say that OS/2
  has installable file systems so developers can go write their own, and
  then not provide the information to do so.

1.8  USABILITY TESTING

  OS/2 needs to be given more usability testing, and the test volunteers
  should cover a much broader spectrum of knowledge.  Everyone from the
  neophyte to the OS/2 guru should be included in the test.  One of the
  problems with OS/2 is that the simple things are often simplified such
  that the power user is left with no where to go, and the powerful features
  are often too complex for the average user to figure out.  A middle ground
  must be found so that OS/2 is the perfect choice for people from all kinds
  of computing backgrounds.
----------------------------------------------------------------------------
2.0  PACKAGES

The following lists packages that are available separately that should be
added to the base OS/2 distribution, in addition to ideas for how to package
OS/2.

2.1  PEER-TO-PEER

  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.

2.2  SOM 2.0, DSOM

  The System Object Model 1.0, used in the WPS and elsewhere, should be
  upgraded to SOM 2.0.  DSOM should be added when peer-to-peer or
  other network services are installed.

2.3  OPENDOC

  OpenDoc support must come out-of-the-box.  OpenDoc is at the forefront of
  technology, and would be an important stand for the top document
  technology to be linked with the top desktop operating system.

2.4  C2 SECURITY

  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.  In addition
  file systems supporting encryption are very desirable.

2.5  ADOBE TYPE MANAGER

  Adobe Type Manager 3.0 (with multiple master fonts) should be included in
  the next version of OS/2, along with a greater number of fonts.

  In addition, a greater effort must be made to have Adobe Type 1 fonts look
  as good on screen as a hand-tuned bitmap font.  Eventually, it would be
  ideal to be able to replace the bitmap fonts with Type 1 fonts to allow
  unlimited font sizes.

2.6  OBJECT REXX

  OS/2 is a world of objects -- so the software that controls this world
  must be object-based as well, thus the need for Object REXX to be
  included with OS/2.

2.7  EPM SOURCES (*.E) AND ETPM COMPILER

  The EPM sources (*.E) and ETPM compiler should be included in the base
  operating system.

2.8  CD-ROM VERSION OF OS/2 TO PROMOTE OS/2 SHAREWARE

  Only a small portion of the OS/2 CD-ROM is used.  The remainder could be
  filled with the best OS/2 shareware, bitmaps, fonts, etc.  Software
  should be initially tested for quality, but after that no restrictions
  should apply to who's software can appear, except that it must not be
  commercial.  This will give a real boost to the OS/2 shareware industry
  while not treading on the toes of the commercial vendors.

2.9  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.

2.10  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.

2.11  OS/2 STICKERS

  OS/2 2.0 shipped with really great OS/2 stickers, but 2.1 did not.  They
  should be put back in to the OS/2 package.

2.12  OPENGL

  OpenGL is a 3-D graphics language with much more power and flexibility
  than the current PM API.  It is already available for AIX, and will be
  shipping with the next release of Windows NT, and as such should ship
  with OS/2 as well.

2.13  OS/2 FOR DOS

  There is already an OS/2 for Windows which uses your existing Windows code
  instead of loading a whole new version of Windows on your drive.  What
  about OS/2 for DOS?  There are too many DOSs out there to do it like OS/2
  for Windows, where OS/2 hooks in to an existing configuration -- but what
  about shipping OS/2 with an IBM DOS that, if the user wishes, could be
  configured to be bootable, either through the Boot Manager or with dual
  booting.  This could save a few precious MB for the user, and would be a
  great time saver if OS/2 could make both a DOS and OS/2 setup at the same
  time.

  This would also be a great way to introduce things like long file names
  and HPFS to DOS.  In addition, IBM could sell OS/2 and DOS together
  (atleast in CD form) for the same price as DOS alone, as a means to
  encourage more people to buy OS/2.
----------------------------------------------------------------------------
3.0  THE KERNEL

OS/2's kernel is showing signs of age in relation to the new breed of
microkernels; listed below are proposed ways to improve it.

3.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.

3.2  DYNAMIC DEVICE DRIVER LOADING/UNLOADING

  OS/2 should be able to load and unload device drivers on-the-fly.  This
  would allow, for example, a much faster boot process, as device drivers
  could be loaded as needed, and would allow to user to reconfigure their
  machine without rebooting.

3.3  SIMPLIFY THE INTEL KERNEL

  The OS/2 for Intel kernel is enormously complicated, which leads to bugs,
  and is huge, which leads to slow performance .  IBM should attempt to
  simplify the kernel by doing such things as splitting it up in to
  smaller, more manageable parts.  This would, in effect, make a
  quasi-microkernel; however, to maintain high performance and
  compatibility, the strict academic definition of a microkernel would not
  be enforced.

3.4  MOVE THE INTEL VERSION TO THE IBM MICROKERNEL

  Of course, if you can't beat them, join them.  The portable OS/2 versions
  (ie:  OS/2 for PowerPC) are already being implemented on the IBM
  Microkernel and moving the Intel version to the Microkernel would help
  maintain the uniformity of the kernel feature sets.

  Moving to the IBM Microkernel 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)
----------------------------------------------------------------------------
4.0  MULTITASKING, MULTITHREADING AND 32 BIT CODE

This section deals with wishes refering to how OS/2 multitasks, areas that
need multithreading and 32-bit code.

4.1  BOOT CODE TO BE MULTITHREADED

  To some, OS/2 takes an eternity to boot.  One of the primary reasons is
  that the boot process runs in a single thread.  Multithreading the boot
  proces, in addition to bringing it up to 32 BIT, should give significant
  performance increases.

4.2  DECOUPLE MULTITASKING FROM THE PRESENTATION MANAGER

  OS/2 should be a fully functional, multitasking operating system without
  the help of the Presentation Manager.  This will a text-based Task List.
  Switching between full screen sessions should not require switching to
  the desktop as an intermediate step.

4.3  SORT TASK LIST

  The task list is very awkward to use when lots of programs are running --
  it is simply too difficult to find what you are looking for when the
  tasks are in random order.  The list should be alphabetically sorted,
  with the option to do things like inverse sorts.

4.4  FULL 32 BIT OS/2

  Given that a large part of OS/2 is already 32 BIT, and that the whole
  thing will have to be 32 BIT for the portable OS/2 versions, it makes
  sense to finish the job and make the Intel version fully 32 BIT.  Forcing
  developers to write 16 BIT device drivers and file systems is crazy and
  contradicts IBM's general plan of 32 BIT applications for OS/2 ('We want
  you to write 32 BIT applications, but sorry, you can't use 32 BIT code if
  you want to do this...').  The work is already being done for the
  portable OS/2 project, so the effort is already being spent -- now bring
  the same changes to OS/2 for Intel.

  The move to 32 BIT code should begin with IFSs and device drivers and
  other areas that force developers to use a 16 BIT compiler.  Once those
  are updated, the remaining 16 BIT OS/2 applications that are accessible
  through a 32 BIT compiler via thunks should be converted to full 32 BIT
  code.
----------------------------------------------------------------------------
5.0  MEMORY AND VIRTUAL MEMORY

The following wishes relate specifically to how OS/2 manages memory and
virtual memory.

5.1  LOWER MEMORY REQUIREMENTS

  The standard PC ships with 4 MB memory - not nearly enough to run OS/2
  properly.  To support these standard configurations, OS/2 should be
  modified to run with acceptable speed (comparable to a 6 or 8 MB
  configuration) on 4 MB systems.

5.2  MEMORY STATE RECORDING

  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.  It would be desirable to be able to save the
  memory state for individual applications instead of the memory state of
  the entire system.  This would allow the user to do such things as:

  - interrupt a long debugging session and reload it the next day
  - save the state of a program before attempting a critical manipulation
  - save the state of a program when a bug has occured or is about to
    occure to give to the author for debugging purposes
  - allow a notebook user to save the state of their system, change a
    battery and reboot right where they left off.  This could be combined
    with power management software so that when battery power gets to a
    certain point, the system could automatically dump itself

5.3  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.

5.4  DOSALLOCMEM ENHANCEMENTS

  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.

5.5  DOSQUERYMEM ENHANCEMENTS

  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).

5.6  DOSQUERYRESOURCESTATUS (NEW API)

  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
----------------------------------------------------------------------------
6.0  DEVICE SUPPORT

Device support is essential for getting users to run OS/2; the following
are suggestions on areas that need the most work.

6.1  SCSI STANDARD DEVICES

  OS/2 should support all devices that are part of the SCSI standard
  devices, such as tape drives, scanners, printers, etc.  Each device type
  would have one driver, much like the SCSI CD-ROMs are handled using
  OS2CDROM.DMD.

6.2  PCMCIA

  OS/2 currently provides only the 'socket services' for PCMCIA devices.
  It is up to the manufacturer to write the other side of the socket, which
  unfortunately few other than IBM provide.  Notebook computers are a
  booming market that IBM should concentrate on serving.

6.3  3 BUTTON MICE

  All 3 buttons of a 3 button mouse should be usable under OS/2.  The third
  button could be mapped to return a particular key sequence, or perform a
  particular action (ie:  send a window to the back, etc.)
----------------------------------------------------------------------------
7.0  REFERENCING 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.

7.1  DEVICE ALIASES

  The user should be able to:

  - alias a directory to a disk; ie: alias c:\application to \\apps or e:
  - alias a disk to a directory; ie: alias e: or \\apps to c:\application
  - alias a disk to a disk; ie: alias e: to \\apps

  It should be possible to alias both c:  and d:  to \\apps, with collision
  detection.

7.2  DISK DEVICE NAMES

  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.

7.3  UNC NAMING CONVENTION

  OS/2's APIs already support the Universal Naming Convention method for
  referencing disks by their disk label, in the format
  '\\volume\directory\file'.  Currently, this format is only available for
  network drives; this should be expanded so that drives can be accessed
  by their volume name anywhere in the system.

  When used on a FAT or HPFS drive, the disk label could only be 11
  characters in length (as that is the current disk label size).  Any new
  file systems should support 255 character labels.

  To maintain some sort of compatibility with DOS, all drives would be
  aliased to their 'A:', 'B:', 'C:', etc.  equivalents to support older
  software.

7.4  MOUNTING DRIVES

  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:'.

7.5  STATIC DRIVE NAMES

  Whatever happens, drive names must be static, as opposed to the dynamic
  naming scheme used now.  The dynamic scheme can cause serious headaches
  when a new drive is installed because the drive letters will change to
  accomodate the new drive and so software may be broken.

  This could be achieved by moving to either the UNC naming convention or
  to mounting drives because the aliases that turn the long name back to
  the drive letter would be staticly defined.

7.6  MULTIPARTITION VOLUMES AND VOLUME STRIPPING

  Multipartition volumes are those consisting of 2+ partitions who are
  put together to make 1 volume (note:  this is different from the compound
  device aliases listed above).  There is no way to tell that the drive
  consists of more than 1 partition, except for some big performance
  improvements if volume stripping is used.  Volume stripping divides
  a multipartition volume in to small chunks snd spreads them around the
  available hard drives.  Each drive is assigned a small part of the
  read or write operation, and as such can act in parallel.

  The multipartition volume and volums stripping support should allow
  the user to add drives at any time to the multipartition volume.
----------------------------------------------------------------------------
8.0  FILE SYSTEMS/FILE ACCESS

This section deals with wishes directly related to the OS/2 file systems,
in addition to how files are accessed.

8.1  FILE SYSTEM REQUIREMENTS

  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
  - extended attributes greater than 64K
  - caches greater than 2 MB
  - a maximum file system size in the terabyte range
  - 255 character disk labels
  - symbolic links (shadows).  They could be implemented using extended
    attributes or the abstract file type (see below)
  - new file type (in addition to 'File' and 'Directory') called 'Abstract'.
    Abstract files would be used for imbedding objects in to the file
    system (rather than having the objects exist in an extended attribute,
    so they could be manipulated just like any other file) and could be used
    for implementing symbolic links.
  - file association in the file system

  It should be possible to link multiple directories together to create a
  compound directory containing the files from all its contributing
  directories, with collision detection.

  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.

8.2  FILE SYSTEM CONVERSION UTILITY

  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.

8.3  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:  HPFS)

8.4  CHANGE DIRECTORIES WITH '/' OR '\'

  The OS/2 IFS definition specifically states that both '/' and '\' should
  be usable for changing directories, and yet almost nowhere in OS/2 can
  either be used.  This should definitely be fixed.  This will require
  changing the standard command line switch delimeter to '-' from '/'.  It
  should be noted that most software already uses '-' as the command line
  switch delimiter.

8.5  ALL FILES EXECUTABLE

  Any file should be executable, no matter what its extension.  The shell
  (CMD.EXE or WPS) 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.  The creator's extended attributes would have a default command
  line to use when starting a program this way.

  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 file name 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.

8.6 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'.

8.7  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.

8.8  OPTIONAL CACHING BY DRIVE

  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:'.

8.9  CACHING ENHANCEMENTS

  The following are requests for changes to OS/2's caching system:

  - dynamic caching.  Instead of the static caching employed under OS/2 now,
    a dynamic cache should be employed.  The user would assign a bottom
    limit to the cache, but as memory requirements grow and shrink the
    cache could grow and shrink as well, to maintain maximum performance at
    all times.
  - unified caches.  Currently, each file system has its own caches.  This
    is a horrid waste of system resources because a user may, for example,
    mainly use HPFS, but they still have the cache for their FAT drive and
    for their CD-ROM.  Instead, a single, unified cache should be employed.
    Each file system would access a common cache, meaning that files are
    cached depending on how they are used rather than the file system they
    are on.

8.10  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.

8.11  REDEFINE EA MANIPULATION

  Currently, a program has to read all of a file's EAs in to a complicated
  structure, modify the structure and write the whole record back.  This is
  inconvienient for the programmer, and will become a problem when greater
  than 64K EAs are introduced.  EAs should be indexed to allow the
  programmer to jump right to the position in the EA they want to read in
  and only read and write the blocks they need.  This should also bring
  performance enhancements.

8.12  .LONGNAME EXTENDED ATTRIBUTE

  Long file name support exists in FAT today, in the form of the .LONGNAME
  extended attribute.  Unfortunately, only the Workplace Shell uses this
  attribute.  All the OS/2 file system calls should rely on the .LONGNAME
  attribute instead of the 8.3 file name to provide transparent long file
  name support to the user.

8.13  .SHORTNAME EXTENDED ATTRIBUTE

  Just as the .LONGNAME extended attribute gives long file name access to
  FAT systems, a .SHORTNAME extended attribute could give transparent long
  file name access to DOS applications.

8.14  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.

8.15  MAINTAIN CASE

  While neither of OS/2's file systems are case-sensitive, they do retain
  case (ie:  "MyDiR" is stored as "MyDiR" but can be referenced as "mYdIr"
  or any other arrangement).  This, however, is not reflected in the
  standard dialog box, in CMD.EXE, and hardly anywhere else for that
  matter.  This should be changed.

8.16  CASE-SENSITIVITY ATTRIBUTE

  There is a huge debate over whether OS/2's file systems should be
  case-sensitive, and both sides have valid arguments.  Therefore, to let
  everyone get what they want, a case-sensitivity attribute, much like the
  read-only, system, hidden and archive attributes that are available today
  could be created.  It would be used on a directory to specify that the
  files contained in that directory are to be treated as case-sensitive.
  If a user wanted to make their entire system case-sensitive, they could
  just recursively change all directories to case-sensitive.  If just a few
  applications require case-sensitivity (UNIX applications, primarily) then
  only their directories would be made case-sensitive.  In addition, an
  environment variable would hold what the default setting should be for
  new directories.

8.17  MULTITHREADED FILE SYSTEMS

  Currently, OS/2 has one thread for the file systems.  That mean if the
  kernel blocks on disk access, the entire operating system is stuck.

  To solve this, each logical drive should should run in a separate thread,
  and each file system thread should be independant of the rest of the
  system.

8.18  MANIPULATION OF OPEN FILES

  It should be possible to remove, rename, copy over, etc. an open file.
  This would allow the user to replace things like DLLs without booting off
  floppy.

  To accomplish this, the following procedure would be followed:

  - make the file unavailable to requests from any program but those that
    already have a file handle open to the file
  - rename the file to a special name that denotes the file to be deleted
  - copy the new version
  - when all programs using the original file close the file, the original
    is removed

  Note that this would still permit OS/2's advanced swap file usage because
  the executable is never removed from the disk while the program is
  running. Special provisions would have to be made to ensure the swap file
  can always find the executable.

  Also note that these files must be automatically removed during the boot
  process, in case the system crashed before the files were properly
  removed.

8.19  FLOPPY EJECTION/DISK CHANGE RECOGNITION

  OS/2's floppy driver should support ejecting floppies (and IBM and other
  companies should take the initiative to make self-ejecting floppies) and
  the automatic recognition of floppy changes ie: when a program asks for a
  new disk to be inserted, the program shouldn't need to be told the disk
  was changed for it to proceed.
----------------------------------------------------------------------------
9.0  LOCALIZATION

OS/2 was 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.

9.1  UNICODE

  Unicode is the up and coming standard for international communication and
  must be supported by an up and coming operating system that is designed
  to be international.  Therefore, OS/2 should be converted in to a
  Unicode-based operating system.  Doing so would have the added advantage
  of removing the need for a different version for double-byte character
  sets.

  Code page emulation would be provided to support applications that are
  not Unicode aware, but they should be quickly phased out.

9.2  CYRILLIC AND GREEK CODEPAGES

  OS/2 should have the same 8 BIT codepages for Cyrillic and Greek that are
  available for IBM DOS.

9.3  ISO 8859.1 (ISO LATIN-1) CHARACTER SET

  OS/2 should support the ISO 8859.1 (also known as ISO Latin-1) character,
  used in other operating systems such as UNIX.

9.4  MULTIPLE CODE PAGES

  As OS/2 becomes more widely used internationally, people need to be able
  to exchange documents using different code pages easily.  Therefore, OS/2
  should be modified to support more than 2 code pages.

9.5  STANDARD DATE, TIME AND NUMBER FORMATS

  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.

9.6  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.

9.7  SEPARATE TEXT FROM CODE

  As an example for other vendors, there should be no text imbedded in
  executable code.  All text used in the operating system should be placed
  in language files (*.msg).

  This would allow IBM to release a single OS/2 for use with the 8 bit
  character sets (and a single OS/2 for everyone when Unicode support is
  added).  IBM could ship OS/2 with all the language files for a particular
  country, and the user would just select which language they want to use
  during the installation.

  Optionally, all available languages (or just a selection, depending on
  the user's desires) would be installed along with the rest of OS/2,
  allowing the user to flip between languages.

  Other vendors should be encouraged separate the text from code in their
  applications and to distribute all available languages in one package.

9.8  MORE COUNTRIES

  IBM should support more countries in the country settings.  For example,
  people from New Zealand shouldn't have to use Australia's country
  settings - which can be a problem for programs that use the country
  settings to make assumptions of other things, like country codes for
  dialing internationally.

9.9  COUNTRY SETTINGS DEFINABLE ON A PER-OBJECT BASIS

  OS/2 should allow the user to define country settings on a per-object
  basis.  This would allow a user to use Canadian English for the entire
  system except for the AmiPro for OS/2 French object which would run
  in Canadian French.

9.10  INTERNATIONAL API/REXX EXTENSIONS

  To implement standard number formats, the OS/2 and REXX APIs must be
  expanded to handle the conversion of date, time, floating point
  and integer numbers, currency, etc.  to and from string and number
  formats.
----------------------------------------------------------------------------
10.0  PRESENTATION MANAGER

This section contains wishes for anything related to the Presentation
Manager, including wishes for INI and icon files.

10.1  MOVE OS2.INI IN TO THE FILE SYSTEM

  Program settings, path, window size/position and other information should
  be moved from the INI files in to the file system in the form of extended
  attributes.  This will allow users to retain application 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.

  APIs should be written to allow indirect access to system variables
  contained in the OS2.INI.  This will eventually allow the OS2.INI to be
  entirely removed.

10.2  MULTIPLE MESSAGE QUEUES

  Having PM grind to a halt because of a process holding the message queue
  for too long just isn't acceptable.  Each window handle should be
  assigned its own, independent message queue to ensure that the user can
  always interact with the system, even if an application goes down.

10.3  CHANGE 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.

10.4  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.

10.5  DISABLE 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.

10.6  FONTS USED 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.

10.7  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.

10.8  ENHANCED TASK LIST ENHANCEMENTS

  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.

10.9  X11-STYLE WINDOW CONTROL

  The user should be able to enable X11-style active window behaviour
  (active window follows the mouse pointer) in addition to controlling the
  Z-order of the windows (when a window is activated by moving the mouse
  over it, should it be brought to the surface or not).

10.10  ANIMATED CURSORS

  OS/2 should support animated cursors.  This means for the alarm clock
  cursor, the dial could spin, etc.

10.11  ROLL-UP WINDOWS

  OS/2 should support roll-up windows, like Corel Draw.  This would allow
  users to conserve valuable desktop real estate without having to keep
  running to the task list to bring up a minimized window.  This should be
  enabled by a special Roll-Up/Roll-Down button, along side the 'Minimize'
  and 'Maximize' buttons.

10.12  FILE DIALOG

  The standard file dialog box should be enhanced as follows:

  - should be sizable, so the user can set how many files should be shown
    at a time
  - the user should be able to see a file's size and date stamp
  - file selection box should be wider for long file names
  - integrate the file and directory boxes in to one box, allowing
    lots of space to show long file names and file attributes.  A '+'
    button, as in the WPS Drive objects, would expand/shrink directory
    trees.
  - overall look should be like the Details view in the WPS
  - user should be able to sort the file list by name, type, size or date
  - user should be able to select files by their characteristics, such as
    file name, file type, date ranges, etc.

10.13  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 blink to
  indicate waiting on user input, and the minimized folder could 'glow'
  when occupied.

10.14  DROP-DOWN LIST BEHAVIOUR

  Currently, the user must click on the button to the right of a drop-down
  list to make it drop down.  This should be changed so that the user could
  click anywhere in the entry field in addition to clicking on the button
  to bring down the list.

10.15  ALT-TAB TO WORK LIKE WINDOWS

  The ALT-TAB key combination, which cycles through the running programs,
  should work like in Windows.  This means that rather than flipping through
  the programs, a little box showing the name of a running program should
  appear.  Each time the user hits ALT-TAB, the name of the next running
  program would appear, until there are no more programs and it restarts at
  the beginning again.  When the user finds the program they want, they let
  go of the ALT key to switch to that program.

10.16  SEPARATE PM FROM THE REST OF OS/2

  PM should be more separated from the rest of OS/2, allowing a user to
  function without it when the overhead of a graphic interface is
  undesirable.  This might be a good use for the STARTUP.CMD - OS/2 would
  first start in a text mode and then try to execute STARTUP.CMD -
  STARTUP.CMD would then contain the commands to start PM.

  It should also be possible to quit PM without shutting down the machine.
  Doing so would return the user to the command line.  This would allow
  to do such things as replace locked DLLs, change display drivers etc.
  that would normally require the system to be reset.

10.17  CUA-91 COMPLIANCE

  Quite a number of areas of PM/WPS are not fully CUA-91 compliant.  For
  example, the base edit control (not MLE:  WC_ENTRYFIELD) does not support
  CTRL-LEFT or CTRL-RIGHT accelerators to move to the next word.  It also
  does not support double clicking on a word to mark the word.  The MLE
  control supports both of these and it is inconsistent not to provide this
  support in dialogs.

10.18  MULTIPLE PM SCREENS

  Take the virtual-desktop one step further by allowing multiple PM screens.
  There would be one screen for the WPS, and then the user could run
  applications on a different physical screen.  This would allow multiple
  resolutions while still using the Presentation Manager.  This would be
  very desirable for viewing pictures or other graphics in one screen at
  640x480x16.7 million colours while keeping the Desktop at 1280x1024x256
  colours.

10.19  DO NOT CHANGE THE KEYBOARD FOCUS WHILE THE USER IS TYPING

  It is a huge annoyance to be typing in a window and suddenly find the
  keyboard focus has changed because a window popped up and took control.
  The keyboard focus should not be changed while the user is typing.  The
  window that is popping up should still be put on top of everything so the
  user knows that something needs to be taken care of, but it should not
  become the active window.

10.20  REAL-TIME WINDOW UPDATES WHILE MOVING

  Optionally, windows should update in real-time even when being moved on
  the screen.  New video cards are fast enough to handle such a feat, and it
  is really quite impressive to see the windows still updating even when you
  move them.

10.21  FILE DIALOG TO MAINTAIN DIRECTORY POSITION

  The first time a file dialog is opened, it should default to the current
  directory.  All successive invocations of the file dialog should start
  at the last directory and file opened by the user.

10.22  PM APPLICATIONS TO START 'MINIMIZED'

  PM applications should be able to start minimized.

10.23  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.

10.24  DIRECT MODIFICATION OF INI FILES

  Currently, when an INI file is changed it must be re-copied.  This is
  terribly wasteful and should be corrected.

10.25  SMALL/LARGE FONTS

  All high-resolution (800x600 and up) PM graphics drivers should come with
  a choice of large or small fonts.  This will especially free those users
  running at 1024x768 from the enormous fonts used at the moment, while
  still allowing those that require a bigger font to use one.

10.26  MENU PLACEMENT

  Menus should open such that the pointer is either over the default menu
  item (if one exists), or over the item in the menu.  The current method of
  having the pointer over the bottom-left corner is quite annoying.

10.27  SYSTEM MODAL DIALOGS

  The use of system modal dialogs should be dramatically reduced.  System
  modal dialogs are those that prevent the user from using their machine
  until the dialog is dealt with.  In most cases, they are a major
  annoyance.  System modal dialogs should only be used to warn the user of a
  major problem, for example, there is no swap space left.  Errors like
  "error accessing drive A:" are not major problems.

10.28  MAXIMIZED WINDOWS

  OS/2 has a peculiar habit of sending maximized windows to the top left
  corner of the screen.  It is very poor behaviour, and drives the user
  crazy!  A window that is maximized should move only if necessary to make
  the whole window fit on the screen.  In that case, the window is moved
  only as far as it needs to move from its origin in order to fit properly.

  In addition, when a minimized maximized window is restored, it should
  reappear in its last known position -- not the top left corner of the
  screen.

10.29  SAVE WINDOW SIZES ON CLOSE

  All PM applications should save their last window size upon closing.  It
  is unacceptable for programs like VIEW.EXE to constantly take over the
  entire screen when the user only wants it to take a small portion.
----------------------------------------------------------------------------
11.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.

11.1  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.

11.2  SHADOWS TO USE SYMBOLIC LINKS

  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, when symbolic link support is added to the file system, shadows
  should be changed to use symbolic links instead.

11.3  SHADOWS TO 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 could have a slightly different icon (as templates do).  In
  addition, it should be possible to set the font for shadows independent
  from the font used for other icons.

11.4  TRASH CAN INSTEAD OF A SHREDDER

  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
  all right 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.

11.5  OBJECT SETTING LIST VIEW

  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.

11.6  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.  This option would be very accessible,
  for example through a drop down list in the 'Window' page.

11.7  GRIDDED DESKTOP

  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.

11.8  EXPAND BRANCHES/EXPAND TREE

  The user should be able to expand branches of a tree or to expand the
  entire tree while in a Tree view.  The keystrokes used should be the same
  as in the help system (VIEW.EXE).

11.9  DRIVE OBJECTS/DISK TREE VIEW TO GIVE MORE INFORMATION

  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 and all subdirectories of that directory
  should be shown.

11.10  SAVE CHANGES MADE BY SYSTEM PALETTES

  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.

11.11  OPEN PARENT FOLDER

  The ability to open a folder's parent should be available in the 'Open'
  section of the Desktop menu.

11.12  CLOSE THE CURRENT FOLDER WHEN OPENING A CHILD FOLDER

  Both accessible through the 'Open' section in the Desktop menu
  and by an accelerator key should be the ability to close the current
  folder when opening a child folder.  Similarly, it should be able to
  open a folder's parent when closing a child folder.  These actions could
  also be enabled by default through the folder's settings.

11.13  CASCADABLE MENUS

  The user can add items to the Desktop menu, even sub-menus, but the user
  can not add sub-sub menus.

11.14  MOUSE SPEED, KEY REPEAT SCALING

  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.

  To solve this problem, flexible ballistics should be supported via a
  customizable acceleration curve.  The user would more or less 'pull' on
  the curve to create the acceleration they desire.  A few standard
  configurations would be given for users that do not want to play with the
  curve.

  In addition, the user should be able to disable ballistic tracking for the
  mouse for those who prefer linear mouse tracking.

11.15  SHELL WINDOW CLOSING

  The WPS should optionally not ask for confirmation to close a shell that
  is not running any programs.

11.16  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).

11.17  FULL PATH 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'.

11.18  DISK LABELS DEFINABLE FROM DRIVE OBJECT

  The user should be able to change a disk label from the Drive object.

11.19  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.

11.20  'FIND' FUNCTION

  The 'Find' option, found both in objects (for locating icons, etc.) and
  in the Desktop menu, is much too complicated. It should be replaced with
  a simple file dialog (modified to handle searching for objects as well as
  files).

11.21  SCREEN SAVER ENHANCEMENTS

  The screen saver should be enhanced as follows:

  - should work for both full screen sessions and the Desktop
  - should not require a password to operate

11.22  WPS SHUTDOWN FUNCTION

  The following enhancements are requested to the WPS shutdown function:

  - in the shutdown dialog box, add a check box to automatically reboot the
    machine after shutdown
  - in the shutdown dialog box, add a check box to unconditionally close all
    running programs
  - during shutdown, a list of all tasks should appear.  As each task is
    terminated, it is removed from the list.  This would allow the user to
    find out which tasks are hanging the shutdown process.

11.23  '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.

11.24  '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.

11.25  HOTKEYS

  It should be possible to create hotkeys to start applications from the
  WPS.  For example, the user could design the system such that ALT-1 starts
  a communications package, ALT-2 starts a word processor, etc.

11.26  TREE VIEW TO SHOW MORE SUB-LEVELS

  When opening a sub-level in a window's Tree View, the parent of this
  branch should be moved to the top of the window to allow the user to see
  more of the sub-levels.  It is obvious that the user wants to see what is
  in the sub-levels and the WPS should reflect this.

11.27  DEFAULT START SIZE, POSITION OF AN OBJECT

  It should be possible to set a default start size and position at the
  object level rather than at a program level.  This would allow the user to
  individually set the start size and position of one shell window object
  without affecting any other shell window object.

11.28  TURN OFF OPTIONS IN DESKTOP MENU

  The user should be able to turn off any of the options in the Desktop menu
  in the WPS.  This would allow the user to turn off such functions as
  'Arrange', which can be hazardous to a carefully designed desktop.

11.29  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.

11.30  ICON FILES AND OBJECTS

  When creating an object, the WPS should first check to see if the
  executable contains an imbedded icon.  It should then check to see if
  there is an ICON file with the same name as the executable.  If either of
  these cases are true, the WPS would use the icon available.  If not, the
  standard executable icons would be used.

  Note that this process should support Windows ICO-format files as well for
  use with DOS programs that come with Windows ICO files.

11.31  ENVIRONMENT SETTINGS DEFINABLE THROUGH OBJECTS

  Program objects and folders should have a new settings page where the user
  could specify environment variable settings (like the PATH).  This
  function would work hierarchically - opening a program in a folder on
  the Desktop would set the program's default environment to that of the
  Desktop, then any settings defined in the program's folder would be added
  and then any settings defined in the program's object would be added.
  These settings would also override those specified in the PROFILE.CMD.

11.32  SYSTEM SOUNDS

  The System Sounds should be an object attribute for every object,
  available through a 'Sound' page in it's notebook.  It should have at
  least two fields - open and close - in addition to any
  application-specific sounds.  For example, the Shredder has a sound that
  is played when something is dropped on to it.  If a datafile associated
  with the program has different sound attributes, they will be used instead
  of the application defaults.  Only sounds that are specific to the WPS
  should be defined in the System Sounds object, such as warning messages.

11.34  DEFAULT WORKING DIRECTORY

  The default working directory for program objects should be the directory
  with the executable.  This will prevent things like KLONDIKE.INI appearing
  in the root directory.

11.35  HIDE TITLE BARS

  For programs that run all the time, having a title bar takes up valuable
  screen real estate with little gain.  Therefore, there should be an option
  in the settings notebook to hide the title bars for the application.

11.36  DRAG-AND-DROP FOLDERS TO THE DESKTOP MENU

  It is possible to add programs to the Desktop menu by dragging them to the
  Menu page of the Desktop settings notebook, but it is not possible to do
  so for folders.  This should be changed to allow users to, for example,
  put the Command Prompts folder in the Desktop menu.

11.37  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 parent process (for example, a shell) and not to the WPS.

11.38  SIMPLIFY THE NOTEBOOKS

  The current notebooks can sometimes be a pain to use because in some ways
  they are so complicated.  For example, it took me a while to figure out
  how to change the Default Setting for a menu - it should be an option
  in plain view on the page.

11.39  CHANGING PAGES IN A NOTEBOOK

  <- and -> in the Notebook can be used to flip between pages - although
  most people just use the tabs at the side to change between sections.
  Because many people decide the arrows do the same thing as the tabs at the
  side, they don't even bother with the arrows.  This is a real problem when
  there are 3 or 4 pages to a section - the user only gets to see the very
  first one.  One suggestion is to remove the arrows unless there are
  multiple pages in the notebook - and print beside the arrows in the
  standard window text "Continued on Next Page" along with the page number.

11.40  MULTIMEDIA CLOCK OBJECT

  The clock should be able to play a WAV file every hour and possibly each
  half an hour, in addition to user-defined times (alarms).  It should be
  possible to assign different WAVs for different occasions.

11.41  OBJECT LOCKING

  WPS objects should include a lock field.  If set, the object could not
  be moved by the user, either through dragging or the 'Arrange' function.
  It should support ACL to allow an administer to arrange a user's desktop
  while preventing the user from customizing their setup.

11.42  ARRANGE

  The arrange function should bring up a dialog with the following options:

  - abort!
  - visibility (make sure that icons only land in a certain rectangle so
    they do not hide behind programs that are always running, like a clock)
  - arrange method - left-to-right icon arrangement
                   - top-to-bottom icon arrangement
                   - Mac-look icon arrangement (where devices are ordered
                     separately from the other objects - starting in one
                     corner of the screen)
                   - user defined methods created by 'drawing' the order

11.43  USER-EDITABLE ROOT MENUS

  The user should be able to edit the root of the Desktop menu - meaning
  the user should be able to change the properties of things like the
  'Lockup Now' (maybe have it run a different screen saver, etc.)

11.44  PROGRAMMABLE SCREEN SAVER

  The screen saver should be programmable.  This means the user should be
  able to plug-and-play DLLs dictating what will be shown when the screen
  is blanked.  This would give easy access to third party vendors who could
  write screen saver extensions to do things like play a movie or do nifty
  animations, rather than the usual lock flying around the OS/2 rings.

11.45  NOTEBOOKS GO SIDEWAYS

  Monitors are wider than they are high, which means that windows that are
  wider rather than higher make better use of screen real estate.  Notebooks
  should thus be changed to go sideways (wide rather than tall).

11.46  MORE ROOM FOR NOTEBOOK ENTRY FIELDS

  The entry fields are too small -- you usually can't see the complete field
  contents without scrolling.  This can, in most cases, be accomplished by
  just making the entry fields bigger, or by scaling the entry field size
  by the notebook size, but may require the notebooks to go sideways in
  order to get enough room on a page.

11.47  DECOUPLE SOUND AND ANIMATION

  Currently, when animation is turned off, an opening/closing folder does
  not activate the System Sounds.  This should be changed so that a user
  could choose to use the sounds even with animation off.

11.48  ALT DISABLES WORK GROUP STARTING

  Holding down ALT when opening a work group folder should suppress restoring
  applications to the state they were in when they closed -- but not lose
  the application status, so that the next time the work group is opened the
  applications are restored.

11.49  SCHEME PALETTE

  The Scheme Palette currently contains colour schemes, fonts, window
  border sizes, etc.  It should be divided up in to the Colour Scheme, Font
  Scheme and Window Scheme.  In addition, a new type of palette, the Bitmap
  Palette, would contain bitmaps that a user could drag-and-drop on a
  folder to change the background bitmap.

  The Font Scheme would define things like:

  - font used in standard dialog boxes
  - font used in the desktop menus
  - anywhere else where a standard font is used

  The Window Scheme would define things like:

  - location of scroll bars
  - location of scroll buttons (at the end of the scroll bars, or
    all 4 together in a corner)
  - window border size
  - standard window gadgets (ie:  maximize, minimize, hide, system menu)
  - 3-D or 2-D representation
  - ovals vs.  boxes to indicate the currently selected option in the
    Desktop menu and elsewhere
  - space between icons
  - turn on/off border around minimized icons (when using the Minimize to
    Desktop feature)
  - location when minimized icons will appear (when using the Minimize to
    Desktop feature): top, bottom, left, right, etc.

11.50  '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.

11.51  SHUTDOWN FOLDER

  In addition to the Startup folder, there should be Shutdown folder that is
  processed when the 'Shutdown' command is activated from the Desktop menu.
  All programs would close down and then the Shutdown folder would be
  processed.

11.52  STARTUP/SHUTDOWN FOLDER ENHANCEMENTS

  The Startup/Shutdown folders should be enhanced to:

  - allow the user to definie a startup/shutdown sequence; that is, instead
    of starting all the programs in random order, they should start by a
    pre-defined sequence.  This could be done via a 'priority' number in the
    object's settings.  When two programs with the same priority are to be
    started, alphabetical order is used.
  - optionally wait for the last program to complete before starting the
    next program.

11.53  ICON DISPLAY

  Currently, an icon can be viewed at "Normal Size", "Small Size", or not at
  all ("Invisible").  An option should be included in the View page of the
  settings notebook for folders to show only the icon (with no text).

11.54  POPUP MENUS

  Submenus inside popup menus are access by moving on to an arrow at the
  right side of the menu.  If the menu does not have enough room to draw
  the submenu on the right, it draws the menu on the left, but the user
  still has to go to the right of the menu to press the arrow, and then move
  to the left to access the menu.  The arrow should be moved such that it
  appears on the side that the submenu will appear on.
----------------------------------------------------------------------------
12.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.

12.1  TEXTUAL USER INTERFACE

  Provide a text user interface API, a type of textual Presentation Manager.
  This would allow PM-like constructs like windows, dialog boxes, scroll
  bars, etc. to be implemented simply and with standard methods.

  This interface should conform to the general PM specification as
  much as possible.  For example, Pressing ALT-SPACE in a full screen
  session should bring down a the equivalent of the toolbar menu for a
  windowed session, with functions to copy, paste, change settings, etc.

  Note that ALT rather than ALT-SPACE is currently used to bring down the
  toolbar menu for windowed sessions.  This is contrary to the ALT-SPACE
  used in PM, and should be changed to maintain conformity.

12.2  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.

12.3  PM-STYLE COPY AND PASTE

  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 then SHIFT-INS to paste.  For windowed sessions, selecting the
  text could be done with a mouse.  For full screen sessions, the selection
  process could start from a "Mark" option in the title bar menu (invoked
  using ALT-SPACE); a mouse cursor could then be enabled for the user to
  select the text as with a windowed session.

12.4  FULL ANSI X3.64 SUPPORT

  The complete ANSI X3.64 terminal specification should be available for
  text sessions.

12.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.

12.6  RESIZABLE FONT

  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.

12.7  ANY FONT USABLE

  Any font, be it bitmapped or an Adobe Type 1, should be available in shell
  windows.

12.8  DRAG-AND-DROP FONTS CHANGES

  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).

12.9  VIO FONT RESOLUTIONS

  There should be more VIO font resolutions, especially because more and
  more users are using higher resolution monitors and could benefit from
  bigger fonts.  A definite plus would be for the System VIO font to be
  turned in to a vector font so it could be scaled to the resolution the
  user desires.
----------------------------------------------------------------------------
13.0  COMMAND LINE SHELL

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.

13.1  SCROLL-BACK BUFFER

  A scroll-back buffer of user-definable size should be available for all
  shells, be it full screen or windowed, DOS or OS/2.

13.2  WILDCARD EXPANSION

  OS/2's current wildcard expansion scheme is not acceptable and needs
  to be changed.

  The command shell should, by default, provide limited wildcard expansion.
  Command names/executable names with wildcards would be fully expanded,
  but parameters would not be in order to preserve sanity with existing
  applications, ie:  'cop* \tmp\* .' would expand to 'copy \tmp\* .', or
  'my* hello' would expand to 'myexe hello'.

  As a option, the command shell should fully expand the entire command
  line.  Therefore, 'copy \tmp\* .' would expand to 'copy \tmp\1 \tmp\2
  \tmp\3 .'.  To permit this, the internal shell commands should be changed
  so as to take a list of files on the command line.  In the case of the
  copy command, the last file would be the target -- and to make sure the
  system has some degree of safety, the last file would have to be a
  directory if more than 2 files are listed on the command line.  Full
  wildcard expansion should be available as an environment variable, so
  that it can be enabled and disabled at will.  This will particularly
  benefit users using UNIX-style applications that work best with the
  UNIX shell-style command expansion.

13.3  COMMAND ALIASES

  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.

13.4  JUMP-SCROLLING

  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.

13.5  NOTEBOOK SETTINGS

  The Notebook settings for a shell should include:

  - screen resolution
  - font and font size
  - CAPS LOCK and NUM LOCK settings

  This would allow shells to be individually customized depending on the
  needs of the user's applications.

13.6  OVERWRITE WARNINGS

  When copying, moving or renaming files, OS/2 should give an overwrite
  warning if a file would be overwritten.  The user would have the option
  to allow the procedure to continue.  A command line switch ('/n', to
  retain compatibility with DEL's '/n' switch) would be used to turn off
  any warnings.

13.7  DIR EXTENSIONS

  The DIR command should optionally:
    - show the .COMMENT extended attribute
    - show the number of HPFS extents used by a file

13.8  VERBOSE COPY/MOVE/DEL

  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.

13.9  CDD TO CHANGE DRIVE WITH DIRECTORY

  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.

13.10  COMMAND HISTORY

  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.

13.11  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 -- however, it should only be available optionally, to protect
  the user from 'ANSI bombs'.

13.12  FILE NAME COMPLETION

  Pressing 'TAB' while entering a path in a shell would try to perform
  'file name 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.  'SHIFT-TAB' would move
  backwards through the list of possible matches.

13.13  FIX HANDLING OF '*' AND '.'

  The current handling of '*' and '.' in a shell are terribly outdated,
  being remnants of the old FAT file system.  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
  file names) to only run when it is started as 'myprog.'

13.14  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.

13.15  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.

13.16  MOVE ACROSS DEVICES

  The MOVE command should work across devices - this means it would have to
  do something like copy and then delete the files.  When MOVE is used on a
  directory, it should move the entire contents of the directory across to
  the destination drive.

13.17  ENHANCE COPY

  The COPY command should be enhanced as follows:

  - there is no need to have both a COPY and XCOPY command when OS/2 can
    offer XCOPY functionality (copying huge chunks of files rather than many
    tiny parts).  If the shell commands are turned in to DLLs, a stub XCOPY
    could use the same code as the shell's COPY command.
  - multithread the copying process
  - optionally, the user should be prompted to change disks when there is
    not enough room to write a file on a disk

13.18  SUBDIRECTORY RECURSION FOR FILE COMMANDS

  All file commands modification, such as 'DEL' and 'COPY' should
  have an option to recurse subdirectories.  The switch '-s'
  (subdirectories) is recommended for enabling the recursion option.

13.19  DOS/WINDOWS SETTINGS

  The text shells should have the ability to set DOS and WinOS/2 settings
  without the need for the WPS.  This would allow a machine to be almost
  fully-functional without the need for Presentation Manager as the user
  could run full screen OS/2 applications in addition to full screen DOS and
  WinOS/2 sessions.

13.20  WINDOW TITLE

  A shell's title should be more meaningful than the current 'OS/2 Window'.
  If no programs are running in the shell, the title should be the current
  current path.  If a program is running in the shell, the title would be
  name of the program.  This title would also be reflected in the Task List.

13.21  START ENHANCEMENTS

  The following changes are requested to the START command:

  - all start types available via the API calls should be available; ie: add
    /VIEWER and /DESKTOP to minimize to either the Minimized Window Viewer
    or the Desktop
----------------------------------------------------------------------------
14.0  INSTALLATION

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.

14.1  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 operation of the parallel port

  and anything else that could cause problems for OS/2 down the line.

  The text mode install program should contain stripped down versions
  of FDISK and FORMAT (perhaps in the form of DLLS) which would load and
  execute in the background while the user is reading installation notes.

  The PM part of the install should install the MMPM/2 and video drivers
  rather than forcing the user to install the MMPM/2 and extra video
  drivers after everything is installed.

  Even the dialogs used in the installation program must be simplified.
  Before doing anything, the user should be asked if they have ever
  installed OS/2.  If not, before anything else the user must be given a
  detailed description of how to use the system, what is going to happen,
  etc.

  Each of the prompts should have detailed descriptions of what is happening
  and how to respond to the prompt.

14.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.  This disk would
  include such utilities as CHKDSK and a text editor.  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.

14.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.  This install
  program would use CID scripts to perform the installation and would allow
  administrators to create their own scripts.  The process for creating CID
  scripts would have to be documented to allow anyone to make their own
  scripts.  Installation scripts would be processed hierarchally and the
  granularity of packages should go down to individual programs, for
  example:

  - OS/2 Base System
     - Tools and Games
        - EPM
        - Chess
     - Multimedia
        - Software Motion Video
     - Video Drivers

  If, for example, the user chose to install the Software Motion Video
  drivers, the MMPM/2 would be installed if it was not already installed,
  while uninstalling Tools and Games would remove EPM, Chess and everything
  else in the package.

  The installation process should support SOM object registration and
  CONFIG.SYS updating.  Uninstalls should remove all traces of the program's
  existence, including entries in any system INI files (ie:  OS2.INI).

14.4  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.

14.5  TEST IF USER IS VISUALLY IMPAIRED

  The OS/2 install program should ask the user if they are visually
  impaired, perhaps along with a simple colour test.  This would allow IBM
  to include one set of icons and schemes for the visually impaired and
  another set, a much more colourful one, for those who are not.

14.6  NEAT TIPS, TRICKS AND OTHER INTERESTING INFORMATION

  During the installation process, little banners showing nifty tips, tricks
  and other interesting information should appear, giving the user not only
  something to watch during a lengthy installation, but practical knowledge
  about an often unfamiliar system.

14.7  SEPARATE APPLICATIONS

  Putting every application/game that comes with OS/2 in the \OS2\APPS
  directory is not a great idea.  The programs should be put in their own
  directory, under the \OS2\APPS tree.

14.8  CONFIGURE DURING THE INSTALL

  OS/2 is a multitasking operating system -- and so it should show off its
  multitasking abilities during the installation process.  When enough is
  installed, OS/2 should start asking about what colour scheme the user
  wants, etc.  Basically, run through the System Setup folder so that when
  the user reboots, the system is fully configured already.

14.9  TEXT-BASED INSTALL

  The OS/2 install program doesn't need to be GUI based to be useful.  In
  fact, it would probably be much easier to install everything the user
  wants from a text install program and then boot OS/2 graphically.  This
  would allow, for example, OS/2 to be booted in high-res mode the first
  time, etc.
----------------------------------------------------------------------------
15.0  SYSTEM CONFIGURATION

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.

15.1  DISTRIBUTE THE CONFIG.SYS

  The CONFIG.SYS is a huge and enormously complex file, but it doesn't have
  to be.  The first step to simplifying the CONFIG.SYS is by splitting it up
  in to its main parts -- OS/2 drivers, OS/2 environment variables and DOS
  drivers and settings.

  To maintain compatibility with DOS, the DOS configuration file would be
  called CONFIG.SYS.  This is because many DOS packages attack OS/2's
  configuration file, which can cause problems for the user.  The CONFIG.SYS
  would only be accessed when a DOS session is started.

  OS/2's device driver file would be called CONFIG.OS2.  This file would be
  referenced during the boot process.

  A PROFILE.CMD would hold the environment variables.  It would be
  referenced each time a program is executed to provide the program's
  environment.  This would allow users to change items like the system path
  without needing to reboot; the user would simply have to close the window
  they are running in and open it again to get the updated environment.

15.2  TURN OS/2 SETTINGS INTO ENVIRONMENT VARIABLES

  The LIBPATH, AUTOFAIL, etc.  should be turned in to environment variables
  so they can be changed on-the-fly by the user.  Any system variables that
  can not be turned in to environment variables should be evaluated for
  usefulness -- for example, the THREADS setting (which defines the
  maximum number of threads in the system) would not be a good candidate;
  however, should there be a maximum number of threads in the first place?

15.3  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 (||).

15.4  DRIVER CONFIGURATION DATABASE

  A database-based tool for configuring device drivers could be created to
  simplify their management.  The database would contain information on what
  switches 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.

15.5  MULTIPLE CONFIGURATIONS

  Like DOS, OS/2 should support multiple configurations.  However, OS/2's
  multiple configuration support must be much simpler than DOS's.  One
  method of ensuring simplicity would be to look for files named CONFIG*.*
  in the root directory of the boot drive.  OS/2 would show a menu of all
  the CONFIG*.* files during boot up, with the default being CONFIG.SYS.
  The user can then select which configuration to start.

15.6  LAST KNOWN GOOD CONFIGURATION

  During each boot, OS/2 should make a copy of the CONFIG.SYS.  If the
  configuration makes it through the shutdown procedure, it would become the
  'Last Known Good Configuration'.  During boot up, the user could hit a key
  combination to switch to the last known good configuration instead of the
  regular CONFIG.SYS.

15.7  GET RID OF THE CONFIG.SYS

  Of course, the real solution is to replace the CONFIG.SYS all together.

  A folder called \STARTUP would be used to store the device drivers,
  installable file systems and programs that would normally be started from
  the CONFIG.SYS.  There would be various possible times the driver
  could be loaded - for example, base-level support for hard drive
  controllers etc.  would be loaded very early in the boot process while
  things like extra file systems would be started later on.  The extended
  attributes for each file would contain the setting for when the driver
  would be started.  The extended attributes would also contain any
  necessary command line options.

  This directory would be managed by a WPS configuration object that would
  allow users to do drag-and-drop configuration and set the boot order and
  command line options for each program to be started.

  The WPS configuration object would be supplemented by a text configuration
  program to allow the user to change their configuration when booted
  off floppy.

15.8  EXE PATH SEARCHED BEFORE LIBPATH

  The path an executable is run from should be searched before the libpath
  for DLLS.  This would allow:

  - DLLS located in the same directory as their EXEs would not require their
    own statement in the LIBPATH
  - programs would often run immediately after installation because their
    installation would not necessarily require the LIBPATH to be changed
  - multiple versions of a program could be simultaneously installed without
    a LIBPATH conflict

15.9  ENVIRONMENT VARIABLE SUBSTITUTION IN CONFIG.SYS

  It should be possible to use environment variable substitution in the
  CONFIG.SYS, to do things such as:

  SET PROGRAMDIR=D:\PROGRAM
  SET PROGRAMFILE=%PROGRAMDIR%\MYFILE

  After substitution, 'PROGRAMFILE' would contain 'D:\PROGRAM\MYFILE'.
---------------------------------------------------------------------------
16.0  MULTIMEDIA

One of OS/2's best features is the MMPM/2; the following are suggestions for
making it even better.

16.1  LOOP FEATURE

  A feature to continuously loop a video clip or sound file (MIDI or Digital
  Audio) should be provided.

16.2  VIDEOS TO BE UPDATED

  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.

16.3  VIDEO FORMATS

  Support for the following additional formats should be provided by the
  Software Motion Video extension:

  - FLI
  - FLC
  - Indeo 3
  - MPEG-I
  - MPEG-II (when finalized)
  - QuickTime
  - Video for Windows 1.0 AVI
  - Video for Windows 2

16.4  AUDIO FORMATS

  Support for the following additional formats should be provided by Digital
  Audio player:

  - AIFF
  - AU
  - IFF
  - RAW
  - SND
  - VOC
  - Compressed WAV

16.5  GRAPHICS FORMATS

  BMP format is fine for OS/2, but in the outside world there are lots of
  formats to contend with.  Support for viewing and converting the following
  formats is requested:

  - GIF
  - IFF
  - ILBM
  - JPEG
  - PCX
  - TARGA
  - TIFF

16.6  MUSIC FORMAT

  OS/2 should support some kind of standard music format, like a MOD.  The
  problem with supporting MOD format is that there are so many versions out
  there, and all of them are very obscure and are impossible to find
  information on.

  To get around this, IBM would design a standard music format.  The
  standard General MIDI format would be used as a base.  In fact, the first
  part of a file would be exactly the same as a General MIDI file.  At the
  end would be the samples, in WAV format.  This would allow a few things:
  IBM could create a music format using standard formats and the files could
  be created using MIDI authoring software with the samples attached
  afterwards using a separate program.  Conversion utilities could be
  written to convert between this format and the various MOD formats.

16.7  DSP SUPPORT

  Support for DSP boards, such as the IBM MWave, should be added to the
  MMPM/2 to off-load the CPU from such tasks as graphics manipulation,
  voice recognition, text-to-speech, audio compression and video playback.

16.8  MPU-401 SUPPORT

  The MPU-401 is the standard for MIDI interfaces, yet it is not supported
  by the MMPM/2.  MPU-401 support is essential for those who with to use
  OS/2 as a music creation platform and support must be provided for these
  users.

16.9  FILE FORMAT SUPPORT VIA DLL

  Multimedia file format support should be implemented using DLLs.  This
  would allow programmers to easily support new formats by creating DLLs to
  handle them.
----------------------------------------------------------------------------
17.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.

17.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.

17.2  LONG FILE NAMES IN DOS (IBM DOS AND OS/2 DOS)

  The main problem is not that OS/2 does not support long file names in DOS,
  but that DOS does not support long file names at all!  All but the
  directory listing functions in DOS could use long file names, given a
  file system that could handle them.

  The FINDFIRST and FINDNEXT calls (INT 21, AH=4E and AH=4F) could take
  in CX an attribute bit for long file names.  A register, say BX, could
  tell how much room for the file name is in the DTA.

  COMMAND.COM should be changed to list these long file names with a special
  command-line switch, say /al (for attribute long).  Allowing long
  file names should not be a default option because many DOS programs refuse
  to handle them, and non-technical users would not understand why.  If the
  same support is put in to the next IBM DOS, DOS programmers are sure to
  start using it, and finally DOS will be more or less 'free' from 8.3
  file names.

  In the meantime, something has to be done about OS/2 only showing 8.3
  file names in DOS and WinOS/2 sessions.  This is an extreme problem for
  those with HPFS drives and a desire to use them to their full potential.

17.3  SVGA IN DOS WINDOWS

  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).

17.4  DOS WILDCARD EXPANSION

  DOS wildcard expansion should be changed to act exactly as in IBM DOS 6.1.

17.5  EXTENDED ATTRIBUTES TO STORE DOS CONFIG INFO

  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.

17.6  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.

17.7  DOS-RELATED FILES TOO INTRUSIVE

  Move all DOS-related files to the \OS2\MDOS directory, like AUTOEXEC.BAT,
  etc.  so that they do not clutter up the root directory.

17.8  WRITE HPFS FOR DOS

  An HPFS device driver should be written to allow DOS users to migrate
  their systems to HPFS while still maintaining full DOS compatibility.
  While it is recognized that pretty well everyone should be using HPFS,
  a large amount of the OS/2 population does not because, should they
  move to HPFS, they would loose access to their DATA through DOS, an
  environment that they will probably have to continue using even after
  they install OS/2.  The OS/2 Install program should offer to install
  the driver in to an existing DOS CONFIG.SYS, when applicable.

17.9  SIMPLER DOS SETTINGS

  For the uninitiated, the DOS settings are a beast.  The DOS settings
  window should be re-designed to the following specifications:

  The settings should be divided in to groups - memory , video, keyboard,
  DOS settings, multitasking, printer, etc.  to make it easy to find a
  particular setting even if you do not know the exact name.  The groups
  would be accessed by a pull-down menu at the top of the window.

  Next to the group pull-down menu would be a pull-down menu for the
  individual settings.  Instead of a cryptic setting name, all names should
  be in plain language (ie:  instead of 'KBD_CTRL_BYPASS', say 'Turn Off
  Control-Escape').

  Below would be a window saying why you should use this setting.  For
  example, for 'Turn Off Control-Escape' it would say 'If your application
  uses Control-Escape for something special, you should turn this setting
  ON.  Otherwise, leave it OFF.'.

  Below the description and to the left would be the actual setting.  This
  could either be done using radio buttons, a slider or an entry field.
  The user should never have to type in formatted data, as in the case of
  the current DOS_VERSION setting, where the user has to type in a cryptic
  statement in order to get the thing to work.

  Below the description and to the right would be instructions on how to
  set the setting.  For example, for 'Turn Off Control-Escape' it would
  say 'Click the radio button labeled 'ON' to turn on or the button labeled
  'OFF' to turn off'.

17.10  BLOCK DEVICE DRIVERS

  OS/2's DOS should allow the user to load block device drivers.  This would
  allow the user to load such things as a CD-ROM driver for a unit not
  supported by OS/2 without having to use a specific DOS version.

17.11  DIRECT ACCESS TO HARDWARE

  OS/2 currently gives DOS programs almost total access to hardware or
  no access at all (PROTECTONLY=YES).  There should be a middle ground -
  like OS/2 1.3 had.  DOS applications could run, but not touch the
  hardware.  NT has a similar scheme, where programs can only talk to the
  hardware if a virtual device driver for that device exists.  This would
  perhaps cause some overhead, but would bring much more stability to the
  operating system.

  To be a little better than the rest, this option should be definable on
  a per-DOS object basis.

17.18  EXIT FROM SPECIFIC DOS SESSION

  A user should be able to type 'EXIT' to end a specific DOS version
  session, rather than having to close the window manually or run 'EXITVDM'

17.19  DESQVIEW TIME SLICES

  OS/2 currently supports Windows-aware programs that can give up time
  slices, but does not support DesqView aware programs.  This support should
  be added.

17.20  SLOW DOWN DOS SESSION

  There should be an option in the settings notebook to slow down DOS
  sessions. This would allow, for example, old games whose timing depends
  on processor speed to run on newer, faster processors.  A slider could
  determine what percentage of a normal time slice the DOS session would
  receive, for example a setting of 42% would mean the DOS session would
  only receive 42% of its normal share of time slices.
----------------------------------------------------------------------------
18.0  WINDOWS

Everyone said IBM could never get Windows to run under OS/2, and yet they
did and it runs amazingly well under most configurations.  To enhance IBM's
support for Windows, the following wishes were made.

18.1  WIN32S SUPPORT

  Win32s support should be included as part of the base system to allow
  users to run such applications as MathCad 4.0.  This also means full VXD
  support should be available.

18.2  FULL SCREEN DRIVER INSTALL

  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.

18.3  OS/2 FOR WINDOWS SUPPORT IN STANDARD OS/2

  The standard OS/2 distribution should be able to perform the same magic
  that OS/2 for Windows can when it comes to starting Windows.  This means
  that a user should be able to use the Windows already on their drive
  instead of having to install WinOS/2 - even if the user bought the
  standard OS/2.

18.4  WINDOWS FOR WORKGROUPS 3.11

  IBM should support the enhancements brought by Windows for Workgroups
  3.11, such as the enhanced file system routines.  While it is debatable as
  to the need for full Windows for Workgroups support (meaning the
  networking functionality), the user should be able to run Windows for
  Workgroups using OS/2 for Windows' Windows technology.

18.5  WABI-STYLE WINDOWS SUPPORT

  The future of Windows support is looking a bit grim as IBM will no longer
  get source code to any new additions to Windows.  Therefore, it should
  look to porting the Windows APIs to OS/2 APIs - in effect, giving OS/2 its
  own version of Wabi.  This would reduce the disk requirements as a full
  Windows install would not be required and would be faster and more
  efficient that loading up a full copy of Windows.

18.6  SYSTEM RESOURCES

  OS/2 is fully capable of providing unlimited system resources; the same
  should go for OS/2's Windows support, as it was done in Windows NT.

18.7  WINOS/2 FULL SCREEN

  Currently, when a full screen WinOS/2 session is started, OS/2 first
  starts a DOS session in text mode, then switches back to graphic mode
  again.  For people whose monitors have terrible syncing problems, it can
  be a real annoyance as the monitor will lose sync during the switch to
  text mode, and again from text mode to graphic mode.  If possible, there
  should be a way to skip the text mode altogether and only change the
  screen mode if required by the Windows drivers.
----------------------------------------------------------------------------
19.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.

19.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.

19.2  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.

  REXX also needs much better INI control - the current INI management
  routines are extremely slow.

19.3  PROCESS CONTROL AND SHUTDOWN FUNCTIONS

  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.
----------------------------------------------------------------------------
20.0  UTILITIES

The following are suggestions for changes to existing OS/2 utilities and
suggestions for new ones.

20.1  WORKPLACE SHELL BACKUP/RESTORE

  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 file system where they can be easily backed up
  using any backup software.

20.2  PROCESS PRIORITY CONTROL

  Command line utilities for setting process priority should be available.

20.3  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).

20.4  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.

20.5  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.

20.6  SYNC UP DOS AND OS/2 FUNCTIONALITY

  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.

20.7  RESOURCE OWNERSHIP VIEWER

  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.

20.8  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.

20.9  '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
  file name 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.

20.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.

20.11  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.

20.12  MIGRATE DATABASE DISTRIBUTION

  Assuming IBM periodically updates the migration database (which it should
  if it does not right now), it should be posted to the IBM BBS as well as
  to the Internet regularly.

20.13  FDISK ENHANCEMENTS

  The following enhancements are requested to FDISK:

  - changing drive tables should not require a reboot.  Any drive that is no
    longer available should simply disappear, leaving other drives available
    for use.
  - non-destructive partition management.  It should be possible to resize
    partitions without having to re-format.  The defragmentation utility
    could be used to move files closer to the beginning of a partition to
    allow for room for the expanded partition.  If enough room can not be
    made, the user would be asked to delete files to make room, or to
    destroy the contents of the partition.

20.14  ATTRIB FOR DIRECTORIES

  ATTRIB should work on directories in addition to files.

20.15  MIGRATE UTILITY TO REMEMBER WHAT HAS BEEN MIGRATED

  The Migrate utility should remember what it has migrated and by default
  not show any applications that have already been migrated in the lists of
  found applications.  An option to 'Show All' would allow the user to
  select programs that have been installed before.

20.16  PM DISKCOPY

  There should be a PM version of DISKCOPY included with OS/2.  When
  introduced, it would replace the text DISKCOPY as the 'Copy Disk' command
  on in the Drives object in the WPS.

20.17  CRC CALCULATOR

  OS/2 should ship with a CRC calculator program.  This would be used to
  compare the CRCs of system files (and possibly user-defined files) from
  a database it would contain to make sure they have not been damaged.  This
  program could be configured to run on bootup.

20.18  FONT CONVERTER

  There are many different font formats, but as far as the OS/2 user is
  concerned, the "one true format" is Adobe Type 1.  Unfortunately, the rest
  of the world does not necessarily feel that way.  To help resolve this
  problem, a font converter, supporting atleast TrueType to Adobe Type 1
  and Windows Type 1 to OS/2 Type 1 conversions, should ship with OS/2.

20.19  STANDARD ARCHIVER

  OS/2 should come with a standard compression/decompression suite, as is
  the case with UNIX. This suite would include a program to back up files
  (like 'tar') and a program to compress (like 'compress').  This suite
  would be available on all the platforms that IBM currently supports, and
  must support the special characteristics of the file systems of differing
  operating systems, such as OS/2's extended attributes.
----------------------------------------------------------------------------
21.0  APPLETS

OS/2's applets should be one of the highlights of the operating system, and
yet they are rarely used.  To remedy this problem, the following wishes
should be taken in to consideration.

21.1  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.

21.2  BASE WORD PROCESSING

  A small word processor should be included with the operating system.  It
  would have to support things like multiple fonts, bold, underline,
  page breaks, alignment, etc. This might be a good way to show off OpenDoc.

21.3  REPLACE SOFTERM

  Softerm is an eyesore.  It is impossible to use and less than functional.
  It should be replaced.  Like the other productivity software, Softerm's
  replacement must show off the features of OS/2 -- meaning SOM support.  It
  must support all the popular file transfer protocols including Zmodem,
  and must have very accurate terminal emulations.

21.4  E SHOULD NOT ASK FOR A FILE TYPE

  It is a major annoyance to be asked for every file you edit for the file
  type.

21.5  ICON EDITOR

  The Icon Editor needs a real overhaul.  It is very difficult to use
  (especially for multi-mode colour icons) and is full of bugs.  For
  example:

  - it always defaults to version 1.2 icons instead of 2.0, even when you
    save the icon as version 2.0
  - you can have 256 colour icons stored as EGA type - impossible!
  - if you close without saving, it asks you if you want to save - even if
    say yes, the icon does not get saved
  - one user reports the icons keep going black and white on him

  In addition, the following changes should be made:

  - rearrange the menus so that it is easy to switch between different icon
    formats
  - a control should indicate which icon format is being edited and should
    allow quick switching between views
  - use a different term for 'device' - 'image' for example.  'Device' is
    much too obscure.

21.6  PULSE METER

  The Pulse Meter is not terribly helpful.  It should be replaced with a
  true system performance meter, showing memory usage, CPU usage, I/O usage,
  etc.  all on a general system level as well as a per-application level.

21.7  FILE MANAGER

  While the Workplace Shell already has perfectly acceptable file management
  capabilities, many users are uncomfortable working with the Drive objects,
  and as such IBM should bring back the OS/2 1.3 File Manager.  This would
  also allow the user to manage their drives with an easy to use PM program
  even if they are not running the WPS.

21.8  MOUSE POINTER EDITOR

  OS/2 should have a mouse pointer editor.  The editor would allow the user
  to create their own pointers, or use one of a few samples, and assign that
  pointer as the standard pointer.  There should be an option to return back
  to the standard pointer.  This pointer editor should also be able to
  change the pointers for special system events, such as the alarm clock
  that appears when the system is busy.
----------------------------------------------------------------------------
22.0  HELP SYSTEM

  When in trouble, the on-line help system is usually the only place to
  turn, so it should be easy to use and intuitive to use and reasonably well
  featured.  Unfortunately this isn't necessarily the case.  The following
  are suggestions on how to correct this.

22.1  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.

22.2  SEARCH FEATURE SHOULD FIND PARTIAL MATCHES

  Searching for complete words can be a trial-and-error game if you don't
  know exactly what you are looking for.

22.3  PM-STYLE COPY FROM VIEW.EXE

  It should be possible to just mark and copy from a INF file using the same
  PM-style methods as everywhere else, meaning the user should be able to
  drag to highlight an area and then use CTRL-INS to copy.

22.4  INF FORMAT TO TEXT CONVERSION

  It should be possible to turn a partial or entire INF in to a text file.

22.5  PRINTER SELECTION OPTION IN VIEW.EXE

  It should be possible to select alternate printers from within VIEW.EXE.

22.6  TEXT MODE INF VIEWER

  Your machine is dead and you have to boot up off floppy to fix it and you
  forgot the command line switch for the utility that would make it all
  right again.  Not a good time to find out that the help system only runs
  with the Presentation Manager.  A text mode viewer is definitely needed.
----------------------------------------------------------------------------
23.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.

23.1  ON-LINE USER GUIDE AND INSTALLATION GUIDE

  The provision of the 'User Guide' and 'Installation Guide' as INF files
  would be much appreciated.

23.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.

23.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.

23.4  DOCUMENT PRODUCTIVITY FOLDER

  There is no documentation for the software included in the Productivity
  folder beyond the on-line help for each package.  IBM should include some
  kind of user's guide for each program.

23.5  THE BIG PICTURE

  OS/2's documentation tends to concentrate on the specifics, without giving
  a user the 'big picture' of what is happening to their machine.
  Documentation that explains more of why an option is there, why a user
  might want to use it, scenarios where different combinations of options
  would be desirable and how it relates to the rest of OS/2 would be very
  useful.
----------------------------------------------------------------------------
24.0  PRINTING

So, you've use the new-and-improved OS/2 productivity applications, or maybe
some nifty OS/2 applications you picked up at your favourite computer store,
and you've made the greatest presentation ever -- now you just have to print
it.  The following are wishes for getting what's on screen on to paper.

24.1  FONT SUBSTITUTION

  Printers today come packed with built-in fonts.  There should be a
  substitution table for converting, for example, 'Times New Roman' to the
  printer's internal 'Times' font.

24.2  ALL FONTS IN A DOCUMENT SENT IN DOCUMENT HEADER

  When using the PostScript printer driver, all fonts to be used in a
  document should be optionally sent with the document header.  This will
  decrease the size of print jobs astronomically as the fonts used in a
  document are sent once - not with every page.

24.3  LAST PAGE FIRST

  Some printers stack printed paper with text up, the result being that
  the user must reverse sort the printed output.  Support for printing
  the last page first would stop this.  This option would be incompatible
  to print while spooling.

24.4  HOLD PRINTER

  When a printer is put on 'Hold' the print should stop at the end of the
  next page or when the print buffer is empty.  Currently, the print
  job continues until the end of the current job.

24.5  PRINT FROM SPECIFIC PAGE

  It would be very useful to be able to restart a print job from a
  particular page.

24.6  SPOOLER GRAPH

  There should be a graph showing the percentage complete of a print job as
  well as the percentage complete of all the print jobs in the spooler.
----------------------------------------------------------------------------
98.0  OS/2 IN GENERAL

The following are items that do not fit in to any other category.

98.1  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.  These progress indicators should also be used during the
  boot process, showing loading device drivers etc.

98.2  NUMLOCK STATE

  On boot-up, OS/2 should leave the NUMLOCK state alone, as it is defined in
  the BIOS.  To support 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.3  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.4  LOCATE ALL OF OS/2 IN \OS2

  The entire operating system should be held within \OS2 - this includes the
  PSFONTS, SPOOL and DESKTOP directories, and possibly even the multimedia
  support.

98.5  LOG BOOT PROCESS

  Often error messages fly off the screen during boot up.  To allow the user
  to diagnose problems, a log of the boot process showing everything sent to
  the screen should be created.

98.6  DISCOURAGE USE OF OS/2 INI FILES

  Vendors should be discouraged from using the OS2.INI to store information.
  First, it increases the size of the file thereby slowing down the whole
  system, and second it means that any application-specific information is
  lost when OS/2 is reinstalled.

98.7  MULTIPLE VIDEO CARD SUPPORT

  OS/2 should multiple video cards in a single machine.  It should combine
  all the cards that support high-res graphics together in to one virtual
  desktop, like the Mac does.

  Monochrome or low-res graphics cards would each get a full screen text
  screen that the user could type in, independant of any of the other
  cards.  That way a user could still access their machine if, for example,
  a program hung while holding the message queue.  This would be a great
  boost to PM developers, especially new ones, whose applications may
  routinely hang while holding the message queue.

98.8  SERIAL PORT ARBITRATOR

  Many users have any combination of terminal programs, FAX software, UUCP
  software, Fido mailers and BBSs all fighting for time on the serial port.
  There needs to be a central serial port arbitrator - a program to manage
  the port.  It would answer the phone and pass control to a particular
  program based on a string received by the remote modem.  That program
  would use the file handle passed to it by the arbitrator to access the
  port.  Software could also ask it for temporary control of the port to do
  automated dialouts or for interactive sessions with a terminal program.
  If the port is already in use, there should be an option to wait for the
  port to be free and then give access to the port on a
  first-come-first-serve basis along with a time-out, or to fail immediately.

98.9  INTERRUPT BOOT PROCESS

  It should be possible to interrupt the OS/2 boot process by holding down
  SHIFT, just like in DOS.  It would start up an OS/2 Full Screen and must
  not lock any of the system files.  This would allow a simple way to
  perform maintenance without having to resort to floppies.

98.10  READ/WRITE TO A PROCESS'S STANDARD INPUT/OUTPUT

  It should be possible to read a process's standard output and write to its
  standard input.  This could be done by setting up special pipes.  Each
  process would have a bidirectional pipe in \PIPE\PROGRAM\ named its
  process ID.  A program's standard input and output would be sent through
  this pipe.  Other programs could open the pipe and read/write just as they
  would to any other pipe.

  This would have the added bonus of immensely simplifying remote-control
  software, as a program could connect itself to the standard input and
  output of a task and redirect it over a network or over serial ports.  In
  addition, it could be used to log the output of a program.

  REXX functions to access these pipes would be required, as would some way
  of reading and writing to the pipes from the command line.

98.11  REMOVE HARDCODED PATHS IN INI FILES

  OS/2 currently hardcodes paths to system files in the INI files.  This is
  a real problem for people who want to move OS/2 from one drive to
  another, or if OS/2's drive letter is changed by adding or removing
  devices.

  The fact is that OS/2 should not be using the INI files to store hardcoded
  paths in the first place.  A much better place for this information is in
  the CONFIG.SYS in the form of environment variables, where the user can at
  least change the information.
----------------------------------------------------------------------------
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.

I would especially like to thank Rodger Bagnall ([e-mail]) for
all the effort he put in to the voting program for the OS/2 Wish List.
Thanks very much, Rodger!

Also, many thanks to Jay Swackhamer for proof reading the list for me.

  Abbott, Darren ([e-mail])
  Aiyagari, Sanjay ([e-mail])
  Babcock, Bob ([e-mail])
  Behrens, Frank ([e-mail])
  Behrens, Stacy John ([e-mail])
  Benoit, Scott ([e-mail])
  Berkley, Rich ([e-mail])
  Bonnaud, Laurent ([e-mail])
  Bononno, Robert ([e-mail])
  Brown, Michael ([e-mail])
  Burdette, Davidd ([e-mail])
  Byrne, Peter ([e-mail])
  Cadiz, Bombim ([e-mail])
  Caldwell, Larry ([e-mail])
  Caples, Jon ([e-mail])
  Charlap, David ([e-mail])
  Coen, Paul R. ([e-mail])
  Coker, Russell (3:633/363)
  Corrigan, John (1:3406/15)
  Cotner, Carl F. ([e-mail])
  Cox, Sam ([e-mail])
  Derbyshire, Drew ([e-mail])
  Dhir, Al ([e-mail])
  Duffy, Patrick ([e-mail])
  Echeruo, Okechukwu Chima ([e-mail])
  Edwards, Paul (3:711/934)
  Eng-Keong, Lee ([e-mail])
  Fahller, Bjorn ([e-mail])
  Freeborg, John ([e-mail])
  Fischer, Kevin ([e-mail])
  Freeman, Jerry ([e-mail])
  Green, Meir Israel ([e-mail])
  Gile, Michael R. ([e-mail])
  Glaser, Rann ([e-mail])
  Gurganus, James ([e-mail])
  Harden, John ([e-mail])
  Heiden, John ([e-mail])
  Henry, Andrew ([e-mail])
  Hernandez, Manolo ([e-mail])
  Hicks, Adrian ([e-mail])
  Huttunen, Ari ([e-mail])
  Janssen, Peter ([e-mail])
  Jensen, Lew ([e-mail])
  Kaaret, Philip ([e-mail])
  Karasch, Bernt ([e-mail])
  Kiehl, Horst ([e-mail])
  Kimber, Richard ([e-mail])
  Kint, Rene ([e-mail])
  Kohtala, Marko ([e-mail])
  Konrads, Thomas (2:2490/1517)
  Knotts, Brian ([e-mail])
  Kwilas, Kris ([e-mail])
  Lassiter, Vincent ([e-mail])
  Lempriere, Mike ([e-mail])
  Leung, Tedman ([e-mail])
  Lin, Tai-Shan ([e-mail])
  Liskov, Nate ([e-mail])
  Longton, Andrew (1:109/347)
  Lonngren, Fredric ([e-mail])
  Hamblen, Nathan ([e-mail])
  Hammel, Kevin ([e-mail])
  Hanser, Per M. ([e-mail])
  Hicks, Adrian ([e-mail])
  Horvath, Joshua ([e-mail])
  Mack, Thomas ([e-mail])
  Mackintosh, David (1:163/557)
  Martin, Steve ([e-mail])
  Masalehdan, Babak ([e-mail])
  Menard, Francois (1:257/445)
  Mueller, Stefan
   (stefan=[e-mail])
  Narramore, Mattison ([e-mail])
  Neades, Daniel J. ([e-mail])
  Ngo, Jonathan Vincent ([e-mail])
  Palmer, Ronald B. ($[e-mail])
  Patanen, Jani ([e-mail])
  Petersen, Martin Kasper ([e-mail])
  Petrilli, Jack ([e-mail])
  Raine, Michael John ([e-mail])
  Reaume, Daniel ([e-mail])
  Regoli, Luca ([e-mail])
  Roderick, Richard ([e-mail])
  Rodgers, Robert Stephen ([e-mail])
  Salo, Mike (1:282/108)
  Samuel, Joshua ([e-mail])
  Shiu, Venone ([e-mail])
  Skinner, Joseph ([e-mail])
  Sobral, Daniel (4:806/18.0)
  Stephenson, Dan ([e-mail])
  Stevens, Warren ([e-mail])
  Swackhamer, Jay ([e-mail])
  Swanson, Craig (1:202/354)
  Tan, Cheng-Yang ([e-mail])
  Teittinen, Marko ([e-mail])
  Timms, Ian ([e-mail])
  Utans, Joachim ([e-mail])
  van Os, Adriaan ([e-mail])
  Venkateswar, Ravikumar ([e-mail])
  Verburg, Bram (2:500/137.21376)
  Veronese, Luciano ([e-mail])
  Vezeau, Danny ([e-mail])
  Vulis, Dimitri ([e-mail])
  Wiencken, Marcus ([e-mail])
  Wilcock, Oliver ([e-mail])
  Wilcox, Duncan ([e-mail])
  Wiley, George ([e-mail])
  Wood, Victor ([e-mail])