Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Legacy Syndrome

0 views
Skip to first unread message

Christopher J. Barr

unread,
May 1, 1996, 3:00:00 AM5/1/96
to

Legacy Syndrome: the tendency for programmers to continue to program as if for
the Operating System they first programmed for.

Symptoms: Rectangular windows with menu bars across the top and large, often
unused, work areas below. Monolithic design in which all functions are handled
by one executable file or from one user interface. Proprietary index and file
systems, Failure to accomodate drag and drop in a practical manner.

Action: STOP writing DOS/Windows 3.1 applications for OS/2. Start using OS/2
and its resources. Implement by adding to those resources rather than building
on top of them.

Case Study: PostRoad Mailer. A decent mail program. I use it. (But it is
facing competition from PMMail). But why is it designed the way it is? Before
it came along, I was able to implement my own mail system using just drag and
drop, desktop shadows, templates, and objects representing small REXX command
files using TCP/IP's built-in facilities. However, I lacked the programming
skill to really make it work without some effort. PostRoad came along and did
ot all for me in one monolithic package. But why recreate all the services
already built into the operating system itself? Why not create a class of
inboxes that shadow received messages or shadows of inbox folders that allow
access to received messages? Drag and drop mailbox. Archive functions using
the file system (perhaps with compression). Database functions to keep track
of messages and the info about them. The system shredder.

I maintain that by failing to integrate the application with the Operating
System, both suffer. PostRoad lacks flexibility and ease of use. The Desktop
is not fully mail enabled. It would have been so easy to recreate all the
functionality of PostRoad as small utilities and modifications or additions to
base classes. The result would have been something much easier to use. Much
more stable. Much more customizable.

When I first installed TCP/IP for OS/2, back in the pre-Warp days, I was taken
aback, at first, by the myriad of little independent objects I had to cope
with. I yearned for a single master console that would allow me to do the
things I wanted. When it came, I tried it, and soon deleted it from my hard
drive. One soon becomes used to the freedom and flexibility and ease of use of
a desktop integrated application.

Let me give another small example. I have a HP 4c scanner with ADF to use as
fax and copier (with FaxWorks Pro and CopyShop). But the HP ADF has the bad
habit of locking up the desktop (even the mouse) between pages in its cycle.
So I moved it off my Workstation onto a machine on the Peer Lan that is
dedicated to other functions. Either my wife or I can run it from that
computer and direct the output files (MCR files, a sort of compressed PCL, I
guess) to a folder on our respective systems. I shadowed a subdirectory called
IMAGES onto our desktops. I also shadowed the FaxWorks PCL5 Print Object and
the network HPDJ4+PCL object into that same directory. I start the scanner and
walk back to my desk. When it finishes, I open Images and drag and drop the
new MCR file onto the printer to print or onto the Fax device to fax. Or I
leave it there until I need it. This is a very simple example of the way we
ought to be interacting with OS/2.

In general, a native OS/2 application ought to (1) employ native services
where they are available rather than recreating them, (2) improve or add to
the native services when they are not available or are inadequate and (3)
build entirely new structures on top of native services only when absolutely
necessary.

One function that is missing, or is buried out of the normal user's reach is
the ability to deal with data files as objects without messing around in the
hard drive directory structure. I can shadow a directory to the desktop and
look for a DeScribe file. Or I can create a special directory and copy files
to it I might want to drag and drop. I ought to be able to automatically
create shadows of data files in specific places as I need them. Received Faxes
in Faxworks ought to be shadowed to the desktop or a folder on the desktop, if
I configure them to be. Email likewise. WordProcessing and SpreadSheet data
files too. This might be a setting on the settings page along with
associations.

I want a drag and drop environment. But everything is configred for drag and
drop except many of the objects I most want to drag and drop.

The Unite people (Unite Lite) are heading the right direction. Everything I
have seen of theirs exploits the poer of the desktop and enhances that
functionality. They went a bit too far with Unite Lite, in my opinion, but
they have the right idea. Some programs really do lend themselves to
rectangular windows with menu bars. And certainly some of the functions
performed by most applications really have to be presented that way. But there
is nothing more irksome than having a big gaudy window taking up all the space
on one's desktop when all one is doing is making a simple menu selection or
pushing a button.

sou...@nextlevel.com

unread,
May 2, 1996, 3:00:00 AM5/2/96
to

In <4m8976$2v...@news-s01.ny.us.ibm.net>, cb...@fsrl.com (Christopher J. Barr) writes:

>Legacy Syndrome: the tendency for programmers to continue to program as if for
>the Operating System they first programmed for.
>
>Symptoms: Rectangular windows with menu bars across the top and large, often
>unused, work areas below. Monolithic design in which all functions are handled
>by one executable file or from one user interface. Proprietary index and file
>systems, Failure to accomodate drag and drop in a practical manner.
>
>Action: STOP writing DOS/Windows 3.1 applications for OS/2. Start using OS/2
>and its resources. Implement by adding to those resources rather than building
>on top of them.

Talking to a couple of the guys who developed Fastback for OS/2, they
said they ran into exactly the same mentality with the corporates above
them.

Fastback/2's "native" operation is purely drag-and-drop: Want to backup
C: to your SCSI tape, just drag the C: object to the SCSI tape object.
Want to set a specific properties for compression, preformatting, etc.
for a backup device, just pull up that device's object settings. There
are templates of all the different devices available, so you can create
different backup devices with different settings for whatever backup job
you want to do.

Fastback/2 itself exists entirely as a set of WPS classes. There are no
executeables; it's fully modular.

And yet there's a "Fastback for OS/2" icon that provides standard a
pulldown menu interface in a single (as you put it) monolithic,
menu-across-the-top, large-empty-workspace-below rectangular window
(although even that is a workplace class, not an executeable :).

Why is this?

Way I hear it is, the Windows-minded man at the top of the ladder
insisted on it. He simply couldn't (or wouldn't) grasp the concept of
dragging a drive object to a tape object to backup the drive; he had to
have the old Backup -> Select Files -> Select Device -> Begin Backup
menu chain. <sigh>


Your friend and mine,
Matt
----------------------------------------------------------------------------
"Maybe all I need, besides my pills and surgery,
Is a new metaphor for... Reality..." -- Queensr˙che

Opinions expressed do not necessarily reflect those of Next Level
Productions, or anyone else of sound mind from this planet or dimension!


Terrell Larson

unread,
May 4, 1996, 3:00:00 AM5/4/96
to

>Fastback/2's "native" operation is purely drag-and-drop: Want to backup
>C: to your SCSI tape, just drag the C: object to the SCSI tape object.
-------------------------
I've got 10 drive letters on this system! There is NO way I want to sit around
waiting for the opportunity to drag another drive letter into the object. How long
do you think it takes to back up 3+ GB's anyway?

I'll get flame for this, but this is about the dumest way to do it IMHO.

As a user I want to set up the backup in a "batch" job. It doesn't change from
week to week and if I have to do it manually, not only will I make a mistake on
the *only* backup I *really* need - it wastes my time!

Some tasks should be set up for interactive use - some in batch, and system
backups belong in the later category.

In fact - pretty much everything of a repetative nature belongs in the later
category.

I developed some software for a major oil company - production plots by pool/well
/formation ...

Programs ran interactively but had batch capibility built in. Users used to fire off
100's of plots to a high speed plotter in a matter of minutes. Compare the
efficency of this approch to sitting in a spread sheet: Call up data set one, set
plot options, ask for plot, wait until done, call up data set two ...

Spending $300 per day for a person to move a mouse around is NOT a very cost
effective use of an employees time!


Christopher J. Barr

unread,
May 6, 1996, 3:00:00 AM5/6/96
to

In message <318b0...@news.cyberstream.net> -
te...@nucleus.com@nucleus.com (Terrell Larson)4 May 96
07:20:50 GMT writes:
:>
:>>Fastback/2's "native" operation is purely drag-and-drop: Want to backup
:>

Not sure there is really a contradiction with my original
post. In fact, one of the things I dislike about a lot of
apps recently is that they are neither drag and drop, OO
applications, nor do they give you command line utilities to
use in batch files. When I first started to use Windows apps
after the DOS versions, I noticed that the lack of a simple
batch language in Windows caused developpers to forget the
command line entirely. Everything was controlled by the
moune through interaction with that omnipresent rectangular
box with menu bar. This habit now infects a lot of OS/2
applications: Fax programs, email programs, etc.

OS/2 apps should, where possible, expand the command
inventory of OS/2 and allow integration with the Workplace
shell where appropriate.

Chris


Oliver Chung

unread,
May 6, 1996, 3:00:00 AM5/6/96
to

-----BEGIN PGP SIGNED MESSAGE-----

In article <4mjngj$2d...@news-s01.ny.us.ibm.net>,
cb...@fsrl.com (Christopher J. Barr) wrote
[delete]


>OS/2 apps should, where possible, expand the command
>inventory of OS/2 and allow integration with the Workplace
>shell where appropriate.

Agreed! OS/2 apps should provide command line controls to help
automating tasks, and optionally close itself when the task is done. I
found that I am using more and more unix ports as I use more and more
scripts to do things. And of course, adding WPS integration is always
welcomed, but I think a simple command line options interpreter is
pretty easy to implement.

______
Oliver Chung
> My opinions are my own < > Happy Warp user <
PGP Key fingerprint: 3E 86 59 AD 08 35 BE 54 DF 63 B9 F8 F7 8B 10 3B

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMY4d9XNBYa8g7KHRAQG3KgP/Y+nzkt3ZdaxzOuz8LbeU1bNQZcYNlSaS
i+e2JOYL8qdejp69WkBy2A9Kx1iYlBtL2HlFXVZ3oK3QKc8YOQ70R3X6wYb6KEbQ
Pfv7bvSoyl/qISau2qRiB+wTd3dFp8V0z7ZCn+8mHvec3CEWhYhgS6gnCBfmy/SY
XRCOi7BlyMo=
=peP8
-----END PGP SIGNATURE-----

Paul Speed

unread,
May 6, 1996, 3:00:00 AM5/6/96
to

Terrell Larson (te...@nucleus.com@nucleus.com) wrote:
: >Fastback/2's "native" operation is purely drag-and-drop: Want to backup

: >C: to your SCSI tape, just drag the C: object to the SCSI tape object.
: -------------------------
: I've got 10 drive letters on this system! There is NO way I want to sit around
: waiting for the opportunity to drag another drive letter into the object. How long
: do you think it takes to back up 3+ GB's anyway?

: I'll get flame for this, but this is about the dumest way to do it IMHO.

: As a user I want to set up the backup in a "batch" job. It doesn't change from
: week to week and if I have to do it manually, not only will I make a mistake on
: the *only* backup I *really* need - it wastes my time!

: Some tasks should be set up for interactive use - some in batch, and system
: backups belong in the later category.

Still following the WPS paradigm, couldn't you make a batch
folder object and put your drive/directory shadows into it? I'm not sure
how the backup software works, but it seems like you might then be able
to just drag the batch folder to the backup system. If not then you
should be able to.
This is not a flame. We've all been using the
full-screen-app-with-a-menu paradigm for so long, that we have trouble
thinking any other way. In fact, it's only when an app. doesn't fully
follow the WPS paradigm that it causes problems.

FWIW,
-Keys


Jonathan de Boyne Pollard

unread,
May 7, 1996, 3:00:00 AM5/7/96
to

Terrell Larson (te...@nucleus.com@nucleus.com) wrote:
| >Fastback/2's "native" operation is purely drag-and-drop: Want to backup
| >C: to your SCSI tape, just drag the C: object to the SCSI tape object.
| -------------------------
| I've got 10 drive letters on this system! There is NO way I want to sit
| around waiting for the opportunity to drag another drive letter into the
| object.

Have you tried selecting all 10 objects and dragging them all at once ?

Hint : use the control key to select multiple objects.

| Some tasks should be set up for interactive use - some in batch, and system
| backups belong in the later category.

On the other hand, this is fair enough, and begs the question "does FastBack/2
have a command-line interface in addition to its WPS interface?". Not
having FastBack/2 myself, I don't know. Does it ?

sou...@nextlevel.com

unread,
May 13, 1996, 3:00:00 AM5/13/96
to

In <318b0...@news.cyberstream.net>, te...@nucleus.com@nucleus.com (Terrell Larson) writes:

>>Fastback/2's "native" operation is purely drag-and-drop: Want to backup
>>C: to your SCSI tape, just drag the C: object to the SCSI tape object.
>-------------------------
>I've got 10 drive letters on this system! There is NO way I want to sit around

>waiting for the opportunity to drag another drive letter into the object. How long
>do you think it takes to back up 3+ GB's anyway?

So select all the drives and drag the lot of them to the SCSI tape
object. Geez, it's not brain surgery, it's *the Workplace Shell*

>I'll get flame for this, but this is about the dumest way to do it IMHO.

So you're saying that using mouse to draw a box around multiple drive
objects and then dragging those to an icon for the SCSI tape drive is
slower, less intuitive, or more difficult than using the standard "old"
procedure?
1. Open backup program
2. Select "Backup"
3. Choose the files/folders/drives you want to backup
4. Set compression, compare, and other parameters
5. In some cases, select backup device
6. Finally begin the backup

>As a user I want to set up the backup in a "batch" job. It doesn't change from
>week to week and if I have to do it manually, not only will I make a mistake on
>the *only* backup I *really* need - it wastes my time!

So create a backup profile from the "Fastback Procedure" template and
stick it in the Startup folder. Or create another tape object, call it
"weekly backup", set the proper scheduling flags in the Settings
notebook, then drag the drive(s), folder(s) or file(s) you want backed
up to it onto that object. Bing, bang, boom.

>Spending $300 per day for a person to move a mouse around is NOT a very cost
>effective use of an employees time!

Before you decide to slam a program, try finding out a little something
about it first, hmm? Everything you've described can be done very
easily in Fastback/2, using only the OS/2 Workplace Shell
drag-and-drop and Settings notebook paradigm.

sou...@nextlevel.com

unread,
May 13, 1996, 3:00:00 AM5/13/96
to

In <4mn6jm$7...@silver.jba.co.uk>, Jd...@jba.co.uk (Jonathan de Boyne Pollard) writes:

>| I've got 10 drive letters on this system! There is NO way I want to sit
>| around waiting for the opportunity to drag another drive letter into the
>| object.
>

>Have you tried selecting all 10 objects and dragging them all at once ?
>
>Hint : use the control key to select multiple objects.

Like I said, it ain't rocket science :) You can also "draw" a box
around all the objects to select them all.

>| Some tasks should be set up for interactive use - some in batch, and system
>| backups belong in the later category.
>
>On the other hand, this is fair enough, and begs the question "does FastBack/2
>have a command-line interface in addition to its WPS interface?". Not
>having FastBack/2 myself, I don't know. Does it ?

It doesn't (except for the FBCR recovery program you run from boot
disk). But that wasn't the point - the whole point (building on the
original post about "legacy syndrome") was in how it gets away from the
"legacy" Windows-type interface look-and-feel and operation, and to a
small degree, how that type of interface was added simply to please the
bigwigs.

It's certainly not all things to all people, but then what software is?
As far as Terrell's whining about automated backup procedures, it
handles scheduled full, incremental and differential backups quite
nicely, thanks - also fully accessible via drag-and-drop and Settings
notebooks, the way the Workplace Shell was intended to operate.


Your friend and mine,
Matt
----------------------------------------------------------------------------
"Maybe all I need, besides my pills and surgery,

Is a new metaphor for... Reality..." -- Queensrÿche

0 new messages