VP/ix could be good...

[Tom Yager]

In article <408 at mjbtn.MFEE.TN.US> root at mjbtn.MFEE.TN.US (Mark J. Bailey) writes:
         [ familiar complaints about real VP/ix problems deleted ]
> I AGREE!  When *IS* it going to get fixed?  With the price that SCO charges
> for the product (a commercial $$$), shouldn't we expect more results?  
>
> Mark J. Bailey                                   "Y'all com bak naw, ya hear!"
> USMAIL: 511 Memorial Blvd., Murfreesboro, TN 37129 ___________________________
> VOICE:  +1 615 893 0098                            |         JobSoft
> UUCP:   ...!{ames,mit-eddie}!killer!mjbtn!mjb      | Design & Development Co.
> DOMAIN: mjb at mjbtn.MFEE.TN.US                       |  Murfreesboro, TN  USA

Before I present what will probably be an unpopular view, let me say that
EVERYONE is right. What hasn't been pointed out yet, however, is that the
problem isn't just with VP/ix. 

MS-DOS and the software written to use it are more than partly to blame. Most
commercial packages build in some form of direct device access in order to
improve performance. This is necessary--MS-DOS i/o is pretty horrid. But for
the people who have to write the software to make it multitask, this presents
an almost insurmountable problem: all of these direct i/o requests have to be
intercepted and routed through handlers. Other OS software to multitask DOS
fairs similarly. Even the ones who have had years to sort it out, like Software
Link, still have to constantly patch and add to their code to accomodate some
package that breaks the rules in a new way. I think you'll find this to be
true: any piece of software that always uses the BIOS for i/o and otherwise
acts according to the "well-behaved" guidelines will run flawlessly under
VP/ix, Concurrent DOS, DOS-merge, or what-have-you. The software that meets
this criteria, however, makes a very short (and often uninteresting) list.

The 80386 hardware makes it somewhat easier with its virtual 8086s, but some
code still needs to be built in to trap attempted port i/o and decipher
direct memory access. I'm afraid, for VP/ix and other programs like it, there
will always be exception cases that just don't run.

Complexity of the task is one factor, but another, non-technical issue bears
considering: what if ISC just sat on the product until they felt is was
perfect? Then this forum would be overflowing with unpleasant comments about
how long we've all waited for this stuff. The pre-release and the subsequent
"released-before-ready" versions of VP/ix were put out because of stiff
competition and overwhelming market demand. Look at all the flack Lotus and
Ashton-Tate have taken over holding back releases. Being careful costs software
companies business, and ISC (SCO/AT&T) must weigh marketing as well as
technical considerations. We'd all be hard-pressed to buy anything from a
company that failed to turn a profit.

Until the "art" of software development is raised to a level where perfection
is attainable, we should learn not to expect so much from recently-released
products. Anyone in the industry would tell you that VP/ix, from conception
to present, is still just an infant. It will grow and improve, but don't be
critical of ISC for grouping the improvements together instead of dribbling
them out a bit at a time. This is expensive, and only serves to raise the ire
of those whose pet bug fixes/enhancements didn't make it into the latest
incremental release.

Is there anything good to be said for VP/ix? I think so. It's saved us all
the expense of a second machine (it certainly runs faster than any system
you could build for $500, considering the cost to network it in with your
Unix box), and rescues us from the "Unix-reboot-DOS-reboot-Unix..." cycle. In
short, it's a convenience. A luxury. Nobody on the planet NEEDS this product,
but we all want it.

Does this mean I'm not in favor of these discussions? Hardly--it helps people
set their expectations. Many consultants considered using VP/ix as a way to
run DOS applications on multiple dumb terminals. Frighteningly, some are
selling it as just that (pity their poor customers), but the informed ones
have either heard the news or seen it for themselves: its capabilities don't
stretch that far. 

For the record, I'm a registered owner of VP/ix, running under SCO Xenix, and
soon will be running it under ISC's 386/ix. I agree that it is flawed, but
frankly my experience with it has been fair. My work is 90% Unix, and I kick
over to DOS for some telecommunications and Unix-->DOS development. I'm running
Turbo C 2.0, Carbon Copy (communications) and a host of other applications. I
have seen some anomalies and learned to work around them. I much prefer the
dynamically-sized "pseudo drive" to a dedicated DOS partition. I look forward
to performance and reliability gains, but for my purposes, it will do for now.

For all those who complained: I don't take lightly the frustration and dis-
pleasure you feel over VP/ix, and hope that ISC is working feverishly on
solutions that we will all find satisfactory. Good luck to all.

Thanks for lending an eye to my opinions.
(ty)

-- 
+--Tom Yager, Apollo Computer R & D----------------------------------------+
|  ARPA: tyager%maxx at m2c.m2c.org (preferred) -or- tyager at apollo.com        | 
|  I speak only for (and to) myself                                        |
+--"I like life; it's something to do."------------------------------------+