karl@sugar.UUCP (Karl Lehenbauer) (05/04/88)
I believe the promise of the '286 processor to provide protected mode
multitasking has not been achieved in any major way in the four years
since the AT's introduction because IBM never got behind the one available
operating system that could support it: Unix. An oft-cited reason why Unix
hasn't become the AT (and above) standard is that vendors balked at moving
their applications, but that's a chicken-and-egg argument. Since most
vendors appear to be going to OS/2, they could have been pushed to do Unix
(Xenix), had IBM and Microsoft decided to do so. Systems built around the
386 have been out for some time, their promise also has been largely
unfulfilled for the same reasons.
The fact is, the problems with Unix could have been fixed far more easily
than writing a new operating system. What's wrong with Unix, at least the
versions I see, is that you still, even on an AT, have to have or be a
guru to install it and keep it running. Surely it is easier to fix this
than writing an operating system from scratch, and judging by OS/2's
lateness (four years, as I see it), bugginess and slowness and the fact
that current 286 and 386 protected mode multitasking multiuser versions
of Unix and Xenix can run DOS proves that it has been true in this case.
(By the way, OS/2 doesn't run in native 386 mode on the 386 - "chopped out
two thirds of me brains.")
Although I can easily envision a shootout at Microsoft in which a bunch
of people who wanted it to be Unix got shot down by a bunch of people
who desperately wanted to "roll their own", I feel more confident that
both IBM and Microsoft saw it to their financial advantage to write
their own ($795 for OS/2 with Presentation Manager, when it comes out.
Unix is effectively a commodity market. No way could they charge that
price indefinitely.) and even more important than that, IBM doesn't want
their customers traipsing off to follow Sun, Apollo, Cray, Apple, Sequent,
Tandem, Control Data, DEC, Amdahl &c &c &c. They wanted them nice and
locked in, so they (PC users) will have to trash all the software they
have in order to move up. Also, multiuser is a no-no. It won't sell
enough computers and competes with profitable, expensive, "lock 'em in"
minicomputers.
A fast '386 is a powerful machine. A few years ago a lot of places would
have hung thirty or forty users on one, or more. The power of the '386,
with its 32 bit architecture and on-board memory manager, places it in the
performance class of what we are calling workstations today. Those systems
all run Unix. For the standardization that would incur, and to the
competitive benefit of our company, I hope Unix becomes the dominant
operating system on IBM PCs and clones equipped with '286 and '386 processors.
-karl
P.S. Please no followups flaming me that a workstation is more than a
386/20. That's totally obvious. I already excluded that stuff anyway by
saying "performance class" and besides, that kind of posting is just a cheap
shot by people who want to post but don't have anything to say.
--
"I think Michael is like litmus paper - He's always trying to learn" - Liz
Taylor ..!{bellcore!tness1,uunet!nuchat}!sugar!karl, Unix BBS (713) 438-5018brad@looking.UUCP (Brad Templeton) (05/05/88)
No, unix wasn't ready, at the time to be the next generation OS for typical PC users. There is some question whether OS/2 is capable of this, as well. Most of those users would have been satisfied with a protected mode, multitasking DOS. Like I said, it's not an easy target that is being aimed at, and OS/2 misses in many of the following places, but here are areas where Unix would require a total rewrite to hit dead on: a) Administration - this has been discussed a lot, so I won't go into details here. b) File system integrity: Unix can't just be turned on and off with a switch like DOS can, and like users expect. c) Fragmented file systems: Unix fragments file systems heavily, and that means you don't want to run it on anything but a fast disk drive. Most people have slower (50-60ms) disk drives. d) Running DOS programs Unix for the 286 might be able to do this the way that OS/2 does, but nobody has done it. That's partly because everybody is interested in the 386 way of doing this, since it isn't a kludge on that chip. e) Real time DOS programs can do real time applications because they own the machine. Not so under Unix f) Easy device driver installation. Typical DOS machines, if they get fancy, have special peripherals, all with their own drivers. All unusual disk controllers come with their own drivers in rom. The link into the kernel method is just too much. Dynamic mount (like QNX) would be best. Load from a list at boot time is what DOS does, which is not as good as dynamic mount, but better than relinking the kernel and rebooting. g) Still run software for the old filesystem, and still use old disks. This is something people want, although they're wrong to want it, and OS/2 was wrong to give it to them by keeping the same file system format. But it is something people want, they just don't know it's bad for them. 8-) h) Convenient floppy disk use The whole mount/unmount scheme is too much for a lot of these users. Some of these things could be fixed with mods, but some of them require essentially an entire rewrite. Now, what they should have done was made an OS that supported both the Unix and DOS system calls, and their almost identical directory structure, but didn't use the same internal file system and process structures. That would have been the answer. -- Brad Templeton, Looking Glass Software Ltd. - Waterloo, Ontario 519/884-7473
tgr@picuxa.UUCP (Dr. Emilio Lizardo) (05/05/88)
In article <1925@sugar.UUCP> karl@sugar.UUCP (Karl Lehenbauer) writes:
:Unix is effectively a commodity market. No way could they charge that
:price indefinitely.) and even more important than that, IBM doesn't want
:their customers traipsing off to follow Sun, Apollo, Cray, Apple, Sequent,
:Tandem, Control Data, DEC, Amdahl &c &c &c.
I suppose that AT&T is part of the &c, in spite of the fact that UNIX is
a trademark of AT&T Bell Laboratories.
BTW, most of what your article said was neither:
a) disputable,
b) new, nor
c) surprising.
(Is that lousy grammar, or what?)
--
Tom Gillespie ( ...ihnp4!picuxa!tgr) | (attmail!tgillespie) (201) 952-1178
AT&T/EDS Product Integration Center 299 Jefferson Rd. Parsippany NJ 07054
"Don't take life so serious ... it ain't nohow permanent." -- Walt Kellyjk3k+@andrew.cmu.edu (Joe Keane) (05/06/88)
> b) File system integrity: > Unix can't just be turned on and off with a switch like > DOS can, and like users expect. > c) Fragmented file systems: > Unix fragments file systems heavily, and that means you > don't want to run it on anything but a fast disk drive. > Most people have slower (50-60ms) disk drives. Blah, this has nothing to do with Unix. The BSD file system was designed with certain things in mind, a PC file system should be different. --Joe
rroot@edm.UUCP (uucp) (05/07/88)
From article <1612@looking.UUCP>, by brad@looking.UUCP (Brad Templeton): .... > Like I said, it's not an easy target that is being aimed at, and OS/2 > misses in many of the following places, but here are areas where Unix > would require a total rewrite to hit dead on: > > a) Administration - this has been discussed a lot, so I won't My friend (edm!neyessa!root) owns an old altos system. Administration needs are almost NIL (once a month, he automatically generates usage stats for our enjoyment) > b) File system integrity: > Unix can't just be turned on and off with a switch like > DOS can, and like users expect. If SYNCs were automatically done whenever the file system was quiescent, this would not be a problem. I really don't know why this isn't done now. > c) Fragmented file systems: > Unix fragments file systems heavily, and that means you Use the BSD file system: It handles (prevents) fragmentation reasonably well. (normal MS-DOS/OS-2 has the same problems as the bell FS anyways) > d) Running DOS programs I've never worried about this, so no coment > e) Real time > DOS programs can do real time applications because they > own the machine. Not so under Unix Basically true for MS-DOS, and false for OS-2. RT work could PROBABLY be done under UNIX (starting with the ability to lock an RT process into memory). Then again, the fact that you DON'T "own the machine" makes it a LOT harder to install a virus. > f) Easy device driver installation. > Typical DOS machines, if they get fancy, have special > peripherals, all with their own drivers. All unusual > .... dynamic mount, but better than relinking the kernel and rebooting. No big problem here. SYSV seems to have runtime-loadable drivers (both the 3B1 and the Convergent Technologies box I am on now seem to have this capability) > g) Still run software for the old filesystem, and still use old disks. Backwards compatibility is fine, but keeping it the standard is, as you said, dumb. > h) Convenient floppy disk use See my answer to b): The same answer applies here. > Some of these things could be fixed with mods, but some of them require > essentially an entire rewrite. As my answers indicate, most of these things can be handled with changes to the device drivers (Hmm, even the fs compatibility could be kludged with a cute device driver -- Then again, I don't think I really want to think about it). Only the RT stuff is a problem, and even that has been solved by some people (albeit with non-trivial changes to UNIX). -- ------------- Stephen Samuel {ihnp4,ubc-vision,vax135}!alberta!edm!steve or userzxcv@uqv-mts.bitnet
brad@looking.UUCP (Brad Templeton) (05/09/88)
In article <3094@edm.UUCP> rroot@edm.UUCP (uucp) writes: >> a) Administration - this has been discussed a lot, so I won't > My friend (edm!neyessa!root) owns an old altos system. Administration >needs are almost NIL (once a month, he automatically generates usage stats for >our enjoyment) You must get a better understanding of the typical DOS user -- the kind who needs a week long training course to learn how to turn the system on, insert disks, print and copy files etc. If you know Unix, you can have an easy enough time running your system if you don't try to do very much with it, but it's still quite a step over DOS. OS/2 probably is, too. >> Unix fragments file systems heavily, and that means you >Use the BSD file system: It handles (prevents) fragmentation reasonably well. >(normal MS-DOS/OS-2 has the same problems as the bell FS anyways) No, there's a big difference. DOS breaks files into extents, but the extents are large if they can be. Regular unix often grabs blocks one at a time as they come in the free list. This can be fixed, of course. >> h) Convenient floppy disk use >See my answer to b): The same answer applies here. No. Sync on quiet is not enough, unless it's of the level of sync before spin-down, and expect the disk to be removed. The original Mac didn't let you get your floppy out unless you requested it from the OS. People *hated* it. Many of these things, as some people have pointed out, can be done and have been done in some cases. But not together, and not as a standard. If you're going to make such massive changes, why not rewrite the thing, and fix the things that we know are wrong after 15 years. That doesn't mean that OS/2 is the answer, but it does mean that an attempt to write a new OS is not a conspiracy against the user community. -- Brad Templeton, Looking Glass Software Ltd. - Waterloo, Ontario 519/884-7473
faustus@ic.Berkeley.EDU (Wayne A. Christopher) (05/10/88)
When people say that PC's should run Unix, they don't care about the filesystem code or the details of administration (as long as it's not too bad). They want it to look like Unix, to have ^Z and vi, and for their Unix application programs to run on it with no modifications, which means system call compatibility. What they DON'T want is to have to use \ instead of / for paths, to have to type "copy" instead of "cp", and to have to learn some marketing person's idea of what an editor should be like instead of what they're used to. I've seen usable Unix systems on PC's (HP systems, mainly) and I'd much rather use them than anything coming out of Microsoft or IBM. As for the disk problems when turning off the machine -- how hard can it be to make the off switch a "soft" power switch, that does a sync before shutting off the power? The problem isn't the technology here, it's the mindset. Wayne
fox@alice.marlow.reuters.co.uk (Paul Fox) (05/10/88)
In article <1612@looking.UUCP> brad@looking.UUCP (Brad Templeton) writes: >Like I said, it's not an easy target that is being aimed at, and OS/2 >misses in many of the following places, but here are areas where Unix >would require a total rewrite to hit dead on: > > a) Administration - this has been discussed a lot, so I won't > go into details here. I agree, but then what does DOS or OS/2 have in the way of sys. admin ? > b) File system integrity: > Unix can't just be turned on and off with a switch like > DOS can, and like users expect. Oh yes it can, ever heard of file system hardening. Granted you shouldn't, but then again, on some PC's you should park the hard disk before removing power. > c) Fragmented file systems: > Unix fragments file systems heavily, and that means you > don't want to run it on anything but a fast disk drive. > Most people have slower (50-60ms) disk drives. Speed of disks is definitely not an issue, although most people think it is. A 2 MB memory cache will solve a lot of problems including slow disks. OS/2 requires in at least 4MB to work properly. Unix needs about .5MB + room for the disk cache. Therefore a 4MB machine will leave users with an ample 1.5MB to play with. How much of this is available under DOS or OS/2 with 4 MB? > d) Running DOS programs > Unix for the 286 might be able to do this the way that > OS/2 does, but nobody has done it. That's partly because > everybody is interested in the 386 way of doing this, since > it isn't a kludge on that chip. Running DOS programs always has been and always will be a kludge. There are very few programs which one will want running in emulation mode, except for say 1-2-3, Windows ? Most of the 'nice' utilities that are used under DOS (eg SideKick, Turbo-*) only exist because of DOS's inability to multi-task. The only thing that Unix lacks is bit-mapped graphics. > e) Real time > DOS programs can do real time applications because they > own the machine. Not so under Unix Absolutely not true. There is a way to do real-time, although it is fiddly but isolating real-time code in device drivers, and performing buffering. This is no more fiddly than using debug under DOS to patch interrupt vectors. Would you patch an interrupt vector whilst the system is running if that system was Unix ? > f) Easy device driver installation. > Typical DOS machines, if they get fancy, have special > peripherals, all with their own drivers. All unusual > disk controllers come with their own drivers in rom. > I agree. Unix really is lacking loadable device drivers. > g) Still run software for the old filesystem, and still use old disks. > This is something people want, although they're wrong > to want it, and OS/2 was wrong to give it to them by > keeping the same file system format. But it is > something people want, they just don't know it's bad > for them. 8-) The thing that kills DOS is the bad disk and file system management. End of story. The only reason that OS/2 kept that old fashioned file system was because of lack of time in there production schedules. It was a bad choice to spend so much of the project worrying about backwards compatability with DOS. > h) Convenient floppy disk use > The whole mount/unmount scheme is too much for a lot of > these users. mount/unmount is a function of the bad user interface of Unix. Remeber that Unix floppy filesystems far outperform DOS floppy disk management. > All flames greatfully accepted. What would you have done if you wanted to take advantage of the 286 architecture whilst maintaining compatability ? By far the most sensible would have been to use something like Unix as a base system and mod it, and include an 8088 emulator. Forget that the h/w can already do this. If it makes the product 4 years late, do it the way the 68* and Acorn ARM people have done it. It must take something like 6 man months to produce an emulator; compare this with the mega man centuries MS have spent on OS2. I really believe that OS/2 is a political and marketing ploy by IBM. (All views expressed are due entirely to my fingers and my behind -- definitely not my brain...) ===================== // o All opinions are my own. (O) ( ) The powers that be ... / \_____( ) o \ | /\____\__/ _/_/ _/_/ UUCP: fox@alice.marlow.reuters.co.uk
friedl@vsi.UUCP (Stephen J. Friedl) (05/11/88)
In article <3230@pasteur.Berkeley.Edu>, faustus@ic.Berkeley.EDU (Wayne A. Christopher) writes: > When people say that PC's should run Unix, they don't care about the > filesystem code or the details of administration (as long as it's not > too bad). They want it to look like Unix, to have ^Z and vi, and for > their Unix application programs to run on it with no modifications, > which means system call compatibility. I would venture to say that the vast majority of multiuser computer users (UNIX included) are entirely unaware of *anything* inside their machine, and this includes filesystem code, admin, ^Z, vi, ls and date. When I was in school I assumed that people used computers for the same reason I did, and at least they were generally comfortable with the shell. In the time then it has been my overwhelming experience that this is false. Most of my customers run business applications, and many of them *never* see a shell and would be scared/confused if they did. Sure, there are some technical markets with smart users (like us :-) ) but I really think that when people say "Yes, I'll buy your accounting/payroll/whatever package" they very well may not have ever heard of UNIX. People buy computers to solve problems, and they are generally unconcerned about the details. As long as the package does what they need ans as long as the box has a nice, safe- sounding name on the outside (IBM, AT&T, etc.) they don't often look any further. Anybody else have something to say on this? -- Steve Friedl V-Systems, Inc. (714) 545-6442 3B2-kind-of-guy friedl@vsi.com {backbones}!vsi.com!friedl attmail!vsi!friedl
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (05/11/88)
In article <3230@pasteur.Berkeley.Edu> faustus@ic.Berkeley.EDU (Wayne A. Christopher) writes: | When people say that PC's should run Unix, they don't care about the | filesystem code or the details of administration (as long as it's not | too bad). They want it to look like Unix, to have ^Z and vi, and for | [...] I use the MKS toolkit to get most of this. It's not perfect, but pretty decent. | As for the disk problems when turning off the machine -- how hard can | it be to make the off switch a "soft" power switch, that does a sync | before shutting off the power? The problem isn't the technology here, | it's the mindset. I think that's the way the AT&T computers work now, at least on the 3B[25] lines. As I recall the "power switch" does a hasty shutdown and then powers down under software control. Someone with a 3B5 correct me if i"ve remembered a "non-fact." -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
lyndon@ncc.Nexus.CA (Lyndon Nerenberg) (05/12/88)
In article <1612@looking.UUCP> brad@looking.UUCP (Brad Templeton) writes: >Like I said, it's not an easy target that is being aimed at, and OS/2 >misses in many of the following places, but here are areas where Unix >would require a total rewrite to hit dead on: > > a) Administration - this has been discussed a lot, so I won't > go into details here. Have you tried installing something like Wordstar under DOS in such a way that it can be accessed from within any directory? Even better, have you documented it in such a manner that a "novice" can duplicate this easily? Trivial applications are (generally) trivial to maintain. As DOS applications (and the DOS environment) grow in complexity, so will the administrative burden. > b) File system integrity: > Unix can't just be turned on and off with a switch like > DOS can, and like users expect. A UNIX box running in single user mode will survive a power down nearly as well as a DOS machine in single user mode. The only reason UNIX is a bit less reliable is due to the use of the disk cache. You could eliminate the problem by eliminating the cache. Is this a reasonable solution? When OS/2 starts supporting multiple users, what will make it immune to FS problems when someone hits the power switch? > c) Fragmented file systems: > Unix fragments file systems heavily, and that means you > don't want to run it on anything but a fast disk drive. > Most people have slower (50-60ms) disk drives. The BSD file system has done a lot to reduce disk fragmentation. If UNIX were limited to 30 meg partitions (ala DOS - I don't know the OS/2 restrictions) it wouldn't (couldn't :-) fragment files much either. > d) Running DOS programs > Unix for the 286 might be able to do this the way that > OS/2 does, but nobody has done it. That's partly because > everybody is interested in the 386 way of doing this, since > it isn't a kludge on that chip. Implementing virtual machines has never been a replacement for running the "real thing." If you insist on doing it you're going to have to accept the performance hit. Hardware assist (on the 80386) always helps. This is not a "UNIX" issue. > e) Real time > DOS programs can do real time applications because they > own the machine. Not so under Unix Most real time applications involve fast response to *external* events. What DOS gains by having exclusive access to the CPU is contradicted by the poor I/O performance of the typical XT/AT hardware environment. If you want to achieve *fast* I/O you're going to have to write your own driver. Odds are the driver will completely bypass the BIOS, there- fore this is no longer a DOS issue - it's a hardware problem. Of course, UNIX is just as much of a pain in the ass when doing things like this. > f) Easy device driver installation. > Typical DOS machines, if they get fancy, have special > peripherals, all with their own drivers. All unusual > disk controllers come with their own drivers in rom. Try hooking up a Microsoft bus mouse, an HP scanner, a multi-port I/O card, a Cordata laser printer, and a hi-res Amdek monitor to an AT. Make it run Ventura Publisher while talking to the mouse, and don't forget to make sure print.com works. Do all of the above in such a manner that you don't have to reboot with and without the mouse and printer drivers loaded in various combinations depending on which application you want to run. Clearly document the procedure. Convince the user this is *easy*. > The link into the kernel method is just too much. Dynamic > mount (like QNX) would be best. Load from a list at > boot time is what DOS does, which is not as good as > dynamic mount, but better than relinking the kernel and > rebooting. Dynamically loadable device drivers are available under CTIX - Convergent Technologies System V port (and on the 3B1 if I remember correctly). It would be nice if CT would license the technology out a bit more freely. > g) Still run software for the old filesystem, and still use old disks. > This is something people want, although they're wrong > to want it, and OS/2 was wrong to give it to them by > keeping the same file system format. But it is > something people want, they just don't know it's bad > for them. 8-) "Where do I plug in the card reader?" :-) > h) Convenient floppy disk use > The whole mount/unmount scheme is too much for a lot of > these users. "...and where does the punch go?" [ see above ] >Some of these things could be fixed with mods, but some of them require >essentially an entire rewrite. Which is the main reason why it will never happen. >Now, what they should have done was made an OS that supported both >the Unix and DOS system calls, and their almost identical directory >structure, but didn't use the same internal file system and process >structures. That would have been the answer. Quick, what does "cd; touch a:" do? -- {alberta,utzoo,uunet}!ncc!lyndon lyndon@Nexus.CA
rroot@edm.UUCP (uucp) (05/12/88)
From article <1623@looking.UUCP>, by brad@looking.UUCP (Brad Templeton):
: In article <3094@edm.UUCP> rroot@edm.UUCP (uucp) writes:
:>> a) Administration - this has been discussed a lot, so I won't
:
: You must get a better understanding of the typical DOS user -- the kind who
:
: If you know Unix, you can have an easy enough time running your system if
: you don't try to do very much with it, but it's still quite a step over
: DOS. OS/2 probably is, too.
Most of the difficult stuff with a UNIX box comes from things like usenet
(4Meg a day can cause headaches for almost ANYBODY). If you assume that
a system isn't gonna be getting something like usenet traffic, there is
very little that needs to be done by the user. I have seen, for example,
an old sun 1 (upgraded to a 68010) that got NIL administration for a
couple of years of use. If you have your CRON scripts set up right,
The system will even tell you which tape to put in for tonight's backup
in your login message - Worry free usage.
If you don't give the user reason to become super-user, then you can even
protect 'important' programs from indescrete removal (thank god for file protection).
:
:>> Unix fragments file systems heavily, and that means you
:>Use the BSD file system: It handles (prevents) fragmentation reasonably well.
:>(normal MS-DOS/OS-2 has the same problems as the bell FS anyways)
:
: No, there's a big difference. DOS breaks files into extents, but
: the extents are large if they can be. Regular unix often grabs blocks one at a
: time as they come in the free list. This can be fixed, of course.
The BSD system uses an extent type system. The nice thing is that, it even
seems resiliant to fragmentation over time (something which can't be said for
the MS-DOS FS). The new AT&T bitmap system also allows for 'extents' (I don't
know, though, if it actually tries to take advantage of this ability),
but probably (like the MS FS) still fragments over time.
:
:>> h) Convenient floppy disk use
:>See my answer to b): The same answer applies here.
: No. Sync on quiet is not enough, unless it's of the level of sync before
: spin-down, and expect the disk to be removed.
Yep: that's almost precisely what I'm talking about (for floppies, anyways).
For HD's things are a bit different (since they never 'spin down', but I see
NO REASON why a file system that's been quiescent for more than a second or
so should have ANY dirty blocks in the system cache. As far as I'm
concerned, this is just lazy programming on the part of the device driver
writers. If you can 'spin down' a floppy, then you should be able to SYNC it.
--
-------------
Stephen Samuel
{ihnp4,ubc-vision,vax135}!alberta!edm!steve
or userzxcv@uqv-mts.bitnetjal@occrsh.ATT.COM (J_Allen_Schones) (05/12/88)
In article <10802@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: [text deleted...] >I think that's the way the AT&T computers work now, at least on the >3B[25] lines. As I recall the "power switch" does a hasty shutdown and >then powers down under software control. Someone with a 3B5 correct me >if i"ve remembered a "non-fact." [text deleted...] The 3B2 line (i.e. 300, 310, 400, 500, 700, 800) perform a "shutdown" sequence when the power switch is turned "off." The 3B5, 3B15, and the 3B4000 will power down, then and there, no "shutdown." I believe the reasoning behind this is that the "user/admin." of a 3B2 will not be as experienced as the larger machines. As an interesting point, I had a supervisor that was known to "pull the plug" when he wanted a quick shutdown. Every time he did this, I winced. -- J. Allen Schones -- AT&T -- Oklahoma City Works MAIL: 7725 W. Reno -- Oklahoma City, OK -- 73125 -- Dept: 11OC0307720 PHONE: (405) 491-4950 | UUCP: {AT&T}!{okcedu|occrsh}!jal FAX: (405) 491-4530 Attn: Schones 0772 x4950
franka@mmintl.UUCP (Frank Adams) (05/14/88)
In article <346@alice.marlow.reuters.co.uk> fox@alice.reuters.marlow.co.uk (Paul Fox) writes: >I really believe that OS/2 is a political and marketing ploy by IBM. Of course it is. On the other hand, the tone of these articles, and especially the subject line, implies that there is something (morally) *wrong* with this. There is not. IBM and Microsoft have every right to try to sell *their* product, at *their* prices. Unfortunately, it appears at the moment that they have the marketing clout to get away with it. This is partly because potential competitors in this area have made little or no effort to get into the market. In other words, the problem isn't IBM and Microsoft; it's everybody else. -- Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Ashton-Tate 52 Oakland Ave North E. Hartford, CT 06108