Future Apples (was: NUTS !)

[Pim Blokland <nipp@plane.nl>]

Phoenyx wrote:
> 
> Well, it's a given that if this were to become a reality, the system
> would have to diverge. So eventually compatibility would not be as
> important as it would in the beginning.

I disagree. If you ditch compatibility, why continue along the same
path at all? I mean, then you can just start from scratch, without
looking back on what you have now but simply designing something new
and trying not to make the same mistakes.
That's what Apple did in 1984.
But that's not what we want from our future Apple IIs!

> I like GS/OS. It is a very simple design which
> other GUI systems should take a lesson from. Yet I would like to see
> some improvements, for instance, a little more leniency with filenames.
> I would like them to be longer and accept a broader range of characters.

Oh, Phoenyx. You know very well that GS/OS can handle long file names
(253 chars). It's just that in the current implementation, it can
only use a ProDOS formatted disk for its startup volume, so you're
stuck with ProDOS names on that volume, that's all.
Oh, by the way, did you know that 253 chars was chosen because when
you attach a prefix to it, like '*:', for a full pathname, it still
fits in a Pascal type string. This does mean GS/OS is not fully
compatible with Windows names. The ones that are longer than 253
characters, that is.
The system could use some improvement though. The current version
cannot handle DOS 3.3 disks on which some of the files have the same
names very well. (When two files have the same name, you cannot copy
the second one using the Finder. Funnily enough, you can do a Get
Info on it.)

> With the FST method which GS/OS uses, GB drives are already a fact.
> Unfortunately, it is still limited.

Yes, that's 2 or 4 GB max, isn't it? Not much by today's standards.
But rewriting GS/OS to use larger disks would lead to compatibility
problems with applications that assume disks to have a certain max
size. Disk utilities and so on; these would have to be updated.
Ordinary programs that only utilize GS/OS at the file call level
would be OK.

-- 
Groetjes, Pim

To send me e-mail, insert a t right before the dot.
Which reminds me, I'd better get on with... IT!