LWELCH@COLGATEU.BITNET (03/19/89)
From: GOV%"claris!wombat@AMES.ARC.NASA.GOV" "Scott Lindsey" 15-MAR-1989 1 9:44:07.98 Subj: Re: Disappointed in the IIgs (and Claris) I will admit that programmer interest in the GS at Claris is waning, but I think the principle reason is Apple's seemingly corresponding lack of interest. The battle over the II seems to be raging within Apple as well. There is a desire to support and expand and fix the OS and tools. The Mac is such a pleasure to program for by comparison. My opinion (which I have stated before) is that the GS is a nifty machine. But that's about as far as it goes. I continue to write "nifty" things for it, but writing something powerful... well that's what we tried for with AWGS, and it's something of a behemoth. ------------- If Apple has a desire to expand, fix, and support the OS and tools, what more do you and other programmers at CLARIS want to see from Apple? What nifty things have you written for the GS? AWGS is huge and too slow in many respects. The people at CLARIS deserve congradulations for developing a powerful application for the //GS and not a product that fits into Apple's "K-8 Educational market" for the // family. Appleworks and Applworks GS show that there is a demand forproductive, powerful, small business applications for the // family. Part of the blame for the slowness of Appleworks GS must be placed on Apple since they control the development of the tools and the hardware. Many of the tools need to be fixed, expanded, and speeded up by Apple. This will make Appleworks GS a more practical application. Hardware improvements need to be explored at Apple as well to speed up the incredibly slow graphics display. But, since Scott has said that Apple is working on improving the tools and OS, what else are the programmers at CLARIS looking for from Apple? Part of the blame for the slowness of Appleworks GS needs to be taken on by the people at CLARIS. I hope that they are working to improve the code of Appleworks GS so that it can work faster. There are some indications of this, but I hope their upgrades will go beyond fixing bugs in Appleworks GS and increase the speed and features of the program as well. CLARIS shouldn't rely on Apple to produce all of the improvements to their program simply through tool speedups and system improvements. I think that Appleworks GS is the best thing that could have happened to the // family and the people at CLARIS deserve a lot of credit. The program reveals shortcomings in Apple's hardware & tools and can help show the way towards improvement in the // line at Apple. Appleworks GS establishes 1 Meg of RAM as a minimum standard for future //GS's and shows that the // line can be successful in the business market if Apple and software developers are willing to put in enough effort. | Chip Welch "Apple ][ Forever!" | | Chipmunk Computer Systems | | CU Box L3058 BITNET: LWELCH@COLGATEU.BITNET | | Hamilton, NY 13346 GEnie: CWELCH3 | `----------------------------------------------------------------------------'
jm7e+@ANDREW.CMU.EDU ("Jeremy G. Mereness") (03/20/89)
One thing... I understand that the GS is a pain to write anything big on, but much of that is because there is as yet not that many good development systems for it. GS/OS is still buggy, APW is buggy, and the C language isn't very good either. The Mac was in this situation some years back as well. Heck, originally the damned machine had to be programmed with a Lisa. But people pressed on, and now there are Mac //cx's that burn through compilers from many companies. There is no reason the //gs can't do the same thing if apple put that kind of energy into the machine. I wish people would stop complaining about the //gs' architecture as the source all the problems; dedicated third party vendors get around this, and the //gs is a dream conpared to the original Mac 512, 8 registers and all. If decent development systems were made for the GS (on the same level as ThinkC, TurboC and Turbo Pascal) then developers would not be complaining as much. But not even Apple has done this, and as with the Mac, they have to make the first move. jeremy mereness jm7e+@andrew.cmu.edu (arpa)
wombat@claris.com (Scott Lindsey) (03/20/89)
From article <8903181758.aa00561@SMOKE.BRL.MIL>, by LWELCH@COLGATEU.BITNET: > > If Apple has a desire to expand, fix, and support the OS and tools, what more > do you and other programmers at CLARIS want to see from Apple? What nifty > things have you written for the GS? AWGS is huge and too slow in many > respects. The people at CLARIS deserve congradulations for developing a >powerful application for the //GS and not a product that fits into Apple's "K-8 > Educational market" for the // family. Appleworks and Applworks GS show that > there is a demand forproductive, powerful, small business applications for the > // family. Yes, AWGS is big and is slow in some situations. I myself have called it a behemoth. The size is mainly due to the fact that we were so ambitious for this program. I believe it is the most fully integrated package in the market, period. Not just on the GS. Admittedly using multiple applications under Multi-finder on a Mac comes close, but the level of integration is not there. Yes, some of the slowness is our fault. Work does continue onward on AWGS: bug fixes, speed enhancements, etc. Personally, I don't really see myself as an application programmer. The things I enjoy most are utilities and glue-code etc. To give you an idea, here's what I did on AWGS: About 2/5 of page layout, mainly in user- interface... the rulers, the palette, etc. I also wrote all the charting code which provides an interface from the spreadsheet to the graphics. After that, it gets more difficult to point out: a mergesort routine used by database and spreadsheet; formatting of numbers in spreadsheet; selection routines for database; interface to lowlevel quickdraw cursor routines; and, of course, that nasty little alert that tells you your machine is dead (yes, the text of that is going to be changed. For those who care, Resume meant to resume what the computer was about to do: crash... into the monitor.) I've been working on the ImageWriter driver that Claris has licensed from Apple... A mindless memory tester to try and spot bad chips... Most other stuff is for internal use and probably won't ever see the light of public release (various DA's and utilities). All this is the sort of stuff that I don't consider powerful, nor especially useful to the common person... but it has its place. > But, since Scott has said that Apple is working on improving the tools and OS, > what else are the programmers at CLARIS looking for from Apple? Part of the > blame for the slowness of Appleworks GS needs to be taken on by the people at > CLARIS. I hope that they are working to improve the code of Appleworks GS so > that it can work faster. There are some indications of this, but I hope their > upgrades will go beyond fixing bugs in Appleworks GS and increase the speed and > features of the program as well. CLARIS shouldn't rely on Apple to produce all > of the improvements to their program simply through tool speedups and system > improvements. No, Claris is not depending on Apple for all the fixes. The point was that bugs in tools and OS make figuring out what's really wrong often impossible. Sometimes we end up trying to debug the tools. Fixes, speedups and enhance- ments are in the works (no pun intended). Beyond that I really shouldn't say. > I think that Appleworks GS is the best thing that could have happened to the // > family and the people at CLARIS deserve a lot of credit. The program reveals > shortcomings in Apple's hardware & tools and can help show the way towards > improvement in the // line at Apple. Appleworks GS establishes 1 Meg of RAM as > a minimum standard for future //GS's and shows that the // line can be > successful in the business market if Apple and software developers are willing > to put in enough effort. As I've said before, I think AWGS is a behemoth. I think that in designing it we failed to truly evaluate the abilities of the computer. We tried for too much. Yes, the tools and OS will/have grow(n) to accept the challange and we are fixing and elaborating AWGS, but I really think we might have been better off to have done something that was a little less useful and more usable. Maybe that might have breathed a bit more life into the GS. At the time we designed it though, we were StyleWare, looking for another product to keep a small business going... obviously we wanted to reach for all we could get. One other 'unfortunately': Unfortunately, we currently reccommend 1.25Mb for AWGS. It WILL run with only 1Mb, but those 256K really make a difference. _THAT_'s how close AWGS is to straining its confines. I also say 'currently'. It's possible we might be able to reduce that strain a bit, working toward more memory-efficient code, and improved tools... but don't hold your breath. Not yet. I'm not flaming Apple about the state of the tools etc. We have been work- ing with them, pointing out our biggest concerns. Right now we're pretty much in a wait state. I'm waiting to see what Apple can and will do with the GS. I'd really like to see it turn into a viable platform. Like Jeff, I fear that it may be to late. Unlike Jeff, I haven't quit waiting. -- Scott Lindsey |"Cold and misty morning. I heard a warning borne in the air Claris Corp. | About an age of power when no one had an hour to spare" ames!claris!wombat| DISCLAIMER: These are not the opinions of Claris, Apple, wombat@claris.com | StyleWare, the author, or anyone else living or dead.
krazy@claris.com (Jeff Erickson) (03/20/89)
From jm7e+@ANDREW.CMU.EDU ("Jeremy G. Mereness"):
>
> I wish people would stop complaining about the //gs' architecture as the
> source of all the problems; dedicated third party vendors get around this,
> and the //gs is a dream conpared to the original Mac 512, 8 registers and
> all. If decent development systems were made for the GS (on the same level
> as ThinkC, TurboC and Turbo Pascal) then developers would not be complaining
> as much. But not even Apple has done this, and as with the Mac, they have
> to make the first move.
They have. Just like on the Mac. It's called MPW. It's a cross-development
system.
~~ What!? You can't afford to buy a Mac? Gee, well, I guess you'll have to
stick to APW, then. ~~
It's just as well, though. Scott's found (and reported!) lots of MPW IIgs C
bugs, mostly in the libraries. Unless you want your program to fit in a
single bank (and a few other nasty limitations), it just don't work.
Unless you're Scott. Then you rewrite the library routines. :-)
--
Jeff Erickson \ Internet: krazy@claris.com AppleLink: Erickson4
Claris Corporation \ UUCP: {ames,apple,portal,sun,voder}!claris!krazy
415/960-2693 \________________________________________________________
____________________/ "I'm so heppy I'm mizzabil!" -- Krazy Katwombat@claris.com (Scott Lindsey) (03/20/89)
From article <9109@claris.com>, by krazy@claris.com (Jeff Erickson): > It's just as well, though. Scott's found (and reported!) lots of MPW IIgs C > bugs, mostly in the libraries. Unless you want your program to fit in a > single bank (and a few other nasty limitations), it just don't work. Now that's not quite true. You CAN have a program larger than a bank (remember my rogue-clone port? [still being debugged]). What you're basically limited to is 1 bank (64K) of data. The equivalent of _main() sets the data bank to the bank containing your data (singular) segment. If you don't like this, or if you don't use the start.obj interface, well, then... you look at it sideways, hold your breath and say the magic word. Now, you say, who on earth would want more than 64K of data? How 'bout a program that needs 1.25Mb to run? > Unless you're Scott. Then you rewrite the library routines. :-) And break them, and re-write them. Most of the "bugs" that I've found in the libraries are really dependancies on the short-address memory model used for the IIgs (MPW & APW) C compiler. OK, I admit that a 3 16-bit register CPU isn't really the best candidate for C, but other PC C (not PCC) compilers have made allowances. The IIgs C compilers don't even have a -E option (a standard option for running the preprocessor and nothing else). Oh well, bitch bitch bitch. Hmmm. I wonder how big the GNU kernel will be eventually... Yes, the IIgs GNU subset! What a thought. :-) -- Scott Lindsey |"Cold and misty morning. I heard a warning borne in the air Claris Corp. | About an age of power when no one had an hour to spare" ames!claris!wombat| DISCLAIMER: These are not the opinions of Claris, Apple, wombat@claris.com | StyleWare, the author, or anyone else living or dead.
shankar@haarlem.SRC.Honeywell.COM (Son of Knuth) (03/21/89)
In article <9107@claris.com> wombat@claris.com (Scott Lindsey) writes: >From article <8903181758.aa00561@SMOKE.BRL.MIL>, by LWELCH@COLGATEU.BITNET: >> >&>> Complaints about AWGS's size and speed It looks like I'm in a small minority, but I really like AWGS, and don't find the speed terribly bad, relative to other GS desktop software. I did not buy MultiScribe GS and Word Perfect because they were way too slow for practical use. While AWGS isn't exactly blazing fast, I find it fast enough to be usable, except for the spreadsheet module (and Kermit would be nice for the communications module). I wish Claris continues to write powerful software like AWGS - perhaps in programming tools and utilities. --- Subash Shankar Honeywell Systems & Research Center voice: (612) 782 7558 US Snail: 3660 Technology Dr., Minneapolis, MN 55418 shankar@src.honeywell.com srcsip!shankar
nicholaA@moravian.EDU (03/23/89)
> >>From jm7e+@ANDREW.CMU.EDU ("Jeremy G. Mereness"): >> >> I wish people would stop complaining about the //gs' architecture as the >> source of all the problems; dedicated third party vendors get around this, >> and the //gs is a dream conpared to the original Mac 512, 8 registers and >> all. If decent development systems were made for the GS (on the same level >> as ThinkC, TurboC and Turbo Pascal) then developers would not be complaining >> as much. But not even Apple has done this, and as with the Mac, they have >> to make the first move. >They have. Just like on the Mac. It's called MPW. It's a cross-development >system. >~~ What!? You can't afford to buy a Mac? Gee, well, I guess you'll have to >stick to APW, then. ~~ Um, not really. I used to be a _die hard_ APW person, using all sorts of modified editors and linkers to get APW to perform like it ought to. To properly link ShrinkIT 2.0, I needed a new linker for Merlin 816 (which is what I wrote SrhinkIT 0.7-1.1 with). I borrowed a very fast linker for Merlin 816 from John Brooks (the fellow who wrote Tomahawk/GS), but it really didn't suit my needs. So, It just so happens that Roger Wagner Publishing is now shipping a _very_ fast version of Merlin which runs under GS/OS (not ProDOS 8) and features _significantly_ faster everything. The assembly times are roughly 4-5 times faster than Merlin 816. The link times are 3-4 times faster (for me). I believe that the product is supposed to assemble in the range of 35,000 lines per minute. This is _without_ a Transwarp card, folks. The product is called merlin plus, and it's _very_ fast (at least compared to what we've been used to. No, I'm not affiliated with RWP at all, I just happened to be faily impressed with this. If you do alot of assembly programming to the exclusion of other types of stuff (ie, not linked with C code), then you might want to take a look at the new merlin. Has anyone else bought this? I'd be willing to bet that with a transwarp card, this thing would outrun alot of Mac and PC assemblers, probably in the range of 100,000 lines per minute sustained performace... not all NOPS, either. andy >-- >Jeff Erickson \ Internet: krazy@claris.com AppleLink: Erickson4 >Claris Corporation \ UUCP: {ames,apple,portal,sun,voder}!claris!krazy >415/960-2693 \________________________________________________________ >____________________/ "I'm so heppy I'm mizzabil!" -- Krazy Kat > ---- Andy Nicholas CsNET: shrinkit@moravian.edu Box 435, Moravian College InterNET: shrinkit%moravian.edu@relay.cs.net Bethlehem, PA 18018 liberty!batman!shrinkit@sun.com ---- UUCP: rutgers!lafcol!lehi3b15!mc70!shrinkit I have a CD player, send CD's. rutgers!liberty!batman!shrinkit I have a IIgs, send a GS+. ALink PE: shrinkit
lwv@n8emr.UUCP (Larry W. Virden) (03/24/89)
Interesting historical (??) note - there was back in the dark ages an assembler (by Randy Hyde perhaps?) called LISA. It was advertised as assembly over 100,000 lines a minute of code on an Apple II (not +,c,e,or gs - this was BEFORE those times!). I do not know if the technology is still being used. -- Larry W. Virden 674 Falls Place, Reynoldsburg, OH 43068 (614) 864-8817 75046,606 (CIS) ; LVirden (ALPE) ; osu-cis!n8emr!lwv (UUCP) osu-cis!n8emr!lwv@TUT.CIS.OHIO-STATE.EDU (INTERNET) The world's not inherited from our parents, but borrowed from our children.