Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!hacgate!ashtate!dbase!awd From: awd@dbase.a-t.com (Alastair Dallas) Newsgroups: comp.databases Subject: Re: Ashton-Tate (was: Judge reverses ruling) Keywords: dBASE IV, Ashton-Tate Message-ID: <1991May6.194341.6465@dbase.a-t.com> Date: 6 May 91 19:43:41 GMT References: <1991Apr24.160831.9828@dbase.A-T.COM> <182@ahmcs.uucp> <186@ahmcs.uucp> Organization: Ashton-Tate, Inc. Lines: 88 In article <186@ahmcs.uucp>, alan@ahmcs.uucp (Alan Mintz) writes: > I wrote: > > Ashton-Tate publishes Step IVward. > > but you didn't write it. (This may not be fair, I don't know if you > commissioned > the work from Rich or simply bought the publishing rights after the fact). I don't know, either. But Rich Comeau (sp?) certainly wrote it. At essence, Ashton-Tate is a software publisher. We happen to have an in-house development staff, but the business is publishing. > While I agree that SYS(14,1) is somewhat difficult to remember unless you > use it > a lot, the concept of putting "product-specific additions that were not > part of > the language at large" in a generic SYS function would seem to avoid > conflicts > with the syntax of other xBase implementations. Any and all of the SYS() funcs > that StepIVward uses (DOS) .BINs for (not much good on a VAX). I'll dig up the > list I did 3 months ago. Along the same lines, a built-in KEYBOARD command > would save a lot of additional flag-passing code needing to get around it's > absence. dBASE can't really be concerned with avoiding "conflicts with the syntax of other xBase implementations," IMHO. We're the dFACTO standard, moving at glacial speed to implement our user's wishlists. The xBase community gets a few things right, a few things wrong with each release; they're forced to catch up with the standard, not the other way around. (This is my opinion, and I respect that the more rabid xBase fans on the net may feel differently.) dBASE IV 1.1 has a KEYBOARD command, just as you suggest. I would recommend the 1.1 Change document as an adjunct to the StepIVward manual. (Here, BTW, is a good example of the preceding paragraph--people have been asking for a KEYBOARD command for years. The xBase community consists of a lot of ex-Ashton-Tate people who find they can implement wishlist items a lot faster on the outside.) As for .BIN files, we are moving the dBASE language away from platform- specific constructs and adding commands which make applications inherently cross-platform. For example, many people use the RUN command to do a 'cd' on MSDOS. For 1.1, we added the SET DIRECTORY command which is the same RUN cd (done more efficiently) on DOS, but which eliminates the need to invoke the operating system on one of our other supported platforms. We have a cursor on/off .bin file as a sample, but now we have SET CURSOR ON/off, which works cross-platform. > > What people forget is that we're suing [Fox] over the product they sold > > in 1986 which was an absolutely exact clone of dBASE III PLUS. > > I don't remember enough about 2.0 to recall if it was truly a verbatim copy. > If so, you have a point. We're dealing with someone who is trying to do > a look-and-feel copy of our software, and you're right, it's infuriating. Thank you. > > imagine how you'd react to competing with your own product > > in the marketplace. > > Not quite accurate. You were competing with a product that was technically > superior. Well, certainly faster. That makes it even more infuriating :-). > Fox's low market share (by comparison) indicates (IMHO) that the > people that bought Fox were those qualified to judge the technical > differences. > They probably couldn't have cared less how the error messages were worded, > or how the screens looked - they bought it on technical merit. It isn't _that_ good, IMO. I might well recommend it, based on specific requirements, but it is a subset of the dBASE IV functionality and they have taken pains in some places to duplicate our known anomalies. In some areas it's deliberately incompatible. We're each trying to solve the same problems and I don't think our solutions are all that different (while you might disagree with me, please accept my opinion that I am at least "qualified to judge the technical differences"--I've seen the source code to both products). Where Fox leans toward fast benchmarks, dBASE leans toward bureaucratic reliability. We meet in the middle. /alastair/ -- |Disclaimer: I am speaking for myself, not as a spokesman for Ashton-Tate, |which does not monitor my outbursts here. I reserve all rights to my |opinions in terms of commercial endorsements.