Path: utzoo!attcan!uunet!lll-winken!ames!mailrus!tut.cis.ohio-state.edu!ucbvax!pro-sol.cts.com!andyn
From: andyn@pro-sol.cts.com (Andy Nicholas)
Newsgroups: comp.sys.apple
Subject: The Future of the Apple II
Message-ID: <8902050738.AA25948@crash.cts.com>
Date: 5 Feb 89 06:28:55 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: pnet01!pro-sol!andyn@nosc.mil
Organization: The Internet
Lines: 52

While everyone was harping on this subject, I thought I'd get my 2 cents in:

Assuming Apple makes a faster IIgs, just assuming that they do this, right
after they do this, the machine will be in a very good position as far as
software goes.  Why?

Many (alright, almost all) IIgs programmers have to *REALLY* work at their
code to optimize it *ALOT* to get commercial quality speed out of it.  A
faster IIgs would not only take advantage of those existing programs, but
apple will have inadvertently have trained an enormous amount of people to
program fairly tight, fast code, yielding faster, hopefully better programs.

If you know anyone who works at a publishing house that works on IIgs code,
and if that person and/or company has any kind of pride in their work, you
already know that people work on squeezing every ounce of speed out of the
machine that they can...  aside from user-friendlyness, once a faster IIgs is
out, the II community will have some of the the fastest development systems
for lower-priced machines.  Granted Orca and APW are slow... but look at the
latest copies of Merlin 816 and the Lisa development systems.  Lisa flies
now..  how fast you think it'll go when the speed is tripled?

just a few random thoughts,

-------

SHRINKIT Notes:

Now a few words about ShrinkIt. -- ShrinkIt 0.95 currently doesn't do very
effective error recovery from almost any outside disturbance while
packing/unpacking files and disks.  The most notable of these is when you are
packing files to a device which gets filled up.  The file OUGHT to be
truncated and the master header of the archive fixed to reflect the change so
that the archive would still be usable, but it is not.  Try listing an archive
after that happens and hang on...  These problems will be fixed in V1.0

A number of people have complained that ShrinkIt 0.95 disconnects their
extended ramdisks, even if they aren't using bank 0 of aux memory.  ShrinkIt
1.0 respects any thrid-party ramdisk drivers and doesn't disconnect a /ram
disk if it doesn't have to.

A few people have also complained about the speed at which ShrinkIt
packs/unpacks stuff.  I am optimizing the algorithms I use to pack/unpack
things, so there will be about a 10-20% speed improvement over previous
versions.  More speed than that will require the use of more memory or a more
advanced processor than the 65c02 (can you say, shrinkit/gs?).

Version 1.0 corrects most of the known problems with previous versions and
should be released 2-3 weeks from this weekend.  I'm very busy at college
right now and am having a hard time working on ShrinkIt as much as I would
like. c'este la vie.

andy