iarocci@eneevax.UUCP (Bill Dorsey) (12/19/86)
I just finished reading a couple of messages about Beckemeyer's products. One person seems upset with them and is considering legal action. The other said he had heard nothing but praise for their products. I posted the following review of MT C-Shell to the atari16 mailing list, but for the benefit of those who may not have access to/may have missed it, here it is again. -------------------------------------------------------------------------- Being a unix fan, and having recently seen a number of favorable reviews of Beckemeyer Development Tool's MT C-SHELL, I decided to give them one more chance and bought the package. I have previously purchased Micro C-Shell and Micro C-Tools and been disappointed due to the multitude of bugs, compatibil- ity problems, and poor documentation. Having had MT C-shell up and running for several days now, I can say that I am quite disappointed in the product and would certainly not recommend it to anyone. In fact, I would caution people against buying it. It has many prob- lems including bugs, compatibility, and poor documentation. I have listed some of the problems with it below. MT C-Shell is a massive memory hog. It is most certainly useless on a 512k machine as one will be unable to run all but the smallest of programs. Even on my 1 meg machine, I cannot always compile in the background and run the editor. Consider, I have approximately 900k free before running MT C-Shell and I can't even run a compiler (each file is less than about 80k) and an editor (approximately 50k). This is truly ridiculous. I have seen unix boxes with less than 1 meg of core run more and bigger programs than this without using a virtual memory system. Another major problem is compatibility. The package claims compatibility with TOS programs. I have found that for every TOS program that runs under MT C- Shell, another one doesn't. And even more annoying is those TOS programs which seem to run, only to crash the system at a later time. The same goes for GEM programs executed using the GEM command, only here even fewer programs work properly. Of course, there's the problem of the documentation (or lack of it). While the documentation provided is reasonably clear, much remains to be said. One would normally expect two to three times the volume of documentation with a similar product. For those of you not familiar with the operation of unix, setting up the system and getting it to work could be a major hassle. But I suppose the subject on which the documentation is especially lacking is technical information. If you are a programmer and want to write programs to be run in the MT C-shell environment, there is no documentation to tell you what to do or not to do. Can you say "Trial and error?" Well, those are the major problems I have encountered with MT C-Shell. There are many others some of which I'll mention below. Many of these can be fixed with a "kludge." However, kludges should not be necessay with a commercial product. If your current working directory is on a drive different from that which you booted, and you try to execute any of the utility commands which refer to the passwd file (finger, passwd, etc.), they won't work. Apparently these com- mands refer to \etc\passwd instead of c:\etc\passwd assuming you booted from drive c:. This can be quite annoying, especially when your home directory is not the same as the boot directory. Speaking of home directories, if you wish an account to have a home directory on a drive other than the one from which you booted, you must use another "kludge." Since the delimiters in the passwd file are colons and the drive delimiters are also colons, the system will get confused is you try to specify a drive in the pathname for the home directory. So, you must create a home directory on the boot drive and put a login shell in the directory to change the home directory to the desired drive and then change directories to it. You would think someone capable of writing a multi-tasking operating system could think of a way around this! There are many more lesser bugs like the two above. Lesser because there exist kludges to circumvent them. For example, the ~ command always returns \usr\name where name is the argument. In cases where the home directory is other than \usr\name, problems can arise. I could go on, but I think you get the point. My advice to prospective buyers of MT C-Shell: STAY AWAY! Look into OS9 or XINU. Unless Beckemeyer Development Tools Inc. gets their act together and releases a bug-free well-documented version of this product, it isn't worth the time or hassle much less the money. In my opinion, BDT, Inc., has a history of releasing products before they are ready. MT C-Shell V1.00 (I believe this is the latest version) should really be V0.01! And until I am certain they have changed, I shall never again purchase one of their products.
jmc@ptsfa.UUCP (Jerry Carlin) (12/20/86)
Yet Another Opinion: I have MT C-SHELL and liked it well enough
to buy the Hard Disk Cache product which has worked perfectly.
MT C-SHELL is imperfect and does need work. On the other hand,
it has a large number of commands that work just fine in single
user mode (I had problems after "init2").
Beckemeyer has tried to do something very difficult - put a multi user
OS in the same address space as underlying single tasking TOS/GEM -
not something faced by OS9. The result is a "pioneering" program and
the usual accompaning arrows in the back are the result.
Since the first release of IBM MS-DOS (remember) had a BASIC with
a bad error is only one of a long list of what version 1.0 of any
program is like, I would state the MT C-SHELL is no worse than
any Microsoft/IBM/... product.
Given that, if you don't like version 1 product, wait until 1.01/1.1/2.0.
One final note, I've read that a Microsoft/IBM MS-DOS 3.0 version had
a backup/restore program that had a bad bug, maybe its even worse than
I've just said. Let's all have a cup of Christmas cheer to Saint
Murphy - our omnipresent benefactor :-)
--
voice= 415 823-2441
uucp={ihnp4,dual,qantel}!ptsfa!jmc