Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!apple!jkc
From: jkc@Apple.COM (John Kevin Calhoun)
Newsgroups: comp.sys.mac.hypercard
Subject: Re: Can one now rename "Home"
Message-ID: <53560@apple.Apple.COM>
Date: 1 Jun 91 18:35:03 GMT
References: <1991May29.074501.5095@vax5.cit.cornell.edu| <53440@apple.Apple.COM> <72664@microsoft.UUCP>
Distribution: comp
Organization: Apple Computer Inc., Cupertino, CA
Lines: 78


In article <1991May30.143908.1@gsbacd.uchicago.edu>
gft_robert@gsbacd.uchicago.edu (opcode ranger) writes:
>OK, I'll bite: under HC 2.1, how does HC know which stack is "Home"
>(doesn't have to be named 'Home' anymore)?

The Home stack still needs to be called "Home" (actually, whatever's in
the relevant string resource) for HyperCard to find it automatically on
launch.  But if HC can't find a Home stack, you can select any stack from
the Standard File dialog as your Home stack for that session.  Next time
you launch HyperCard, it won't remember, so it's not really that big a deal.
But it's better than 1.x, which would quit to the Finder if you picked a
stack from the Standard File dialog that wasn't named "Home".

In article <72664@microsoft.UUCP> jamesth@microsoft.UUCP (James THIELE) writes:
>In article <53440@apple.Apple.COM| jkc@Apple.COM (Kevin Calhoun) writes:
>>HyperCard 2.x is a lot smarter about the Mac file system than 1.x was.
>>This feature is just a part of it.
>
>So what are the other parts of HC 2.x's newfound file system smarts?

I've been waiting since we shipped 2.0 for someone to ask me this question.
:-)

1) In a scripting language such as HyperTalk, the only way to refer to
files is by string -- but a full pathname is not necessarily a unique
name for a file.  For example, you can have two floppy disks named
"Untitled" on your desktop at the same time, both with files named "Fred"
in their root directories.  The File Manager, prior to System 7.0, doesn't
give an application much help with this kind of situation -- if you ask
it to resolve the pathname "Untitled:Fred", it always gives you the "Fred"
that's on the first disk that was mounted.  Well, suppose the "Fred" on
the first disk is a MacWrite document, and the one on the second disk is
a HyperCard stack, and the user says 'go stack "Untitled:Fred"'.  What's
to be done?  HyperCard 1.x won't be able to open the stack.

Now, with System 7.0's Personal FileShare, more people will have more
volumes on their desktop than ever before, and this kind of problem will
occur with greater frequency.  But not in HyperCard 2.x -- in general,
HyperCard 2.x will exhaust all possibilities before giving up on finding
the file you specify.  It has no problem opening stack Fred, under either
System 6.x or 7.0.

2) Even though Apple introduced the Hierarchical File System (HFS) with
the Macintosh Plus over five years ago, people are still concerned about
whether System 7.0 will work with their old MFS disks.  Well, don't bother
trying to use them with HyperCard 1.x -- it has a bug that prevents it
from opening stacks on MFS disks.  I was annoyed by this back when I was
working at Dartmouth, and I submitted a fairly petulant bug report about
it to HYPERBUG$applelink.apple.com.  Sure enough, it came back to haunt
me -- I was responsible for fixing it for 2.0.

3) HyperCard 1.x there are two limits on the number of directories in
which you can open stacks.  First, it has to open a "working directory"
for each directory in which it opens a stack.  These working direcories
remain open until HC quits.  Because there's a limit on the number of
working directories you can have open at once, you eventually won't be
able to open stacks in additional directories.  Second, HyperCard 1.x
remembers the pathnames of the directories in which it opens stacks in a
data structure that's limited to 32K.  Once that 32K is full of pathnames,
you won't be able to open a stack that's in a directory you haven't
visited before.  These limitations come into play with large systems of
stacks.  

Since 1987, when HC 1.0 came out, it has become well-known among Macintosh
programmers that using working directories and full pathnames is not the
right way to do things, but in 1989 someone still had to dig deep into
HyperCard and change everything.  It was a classic "dirty job".  It
wasn't easy, and if it was done well hardly anyone would know about it,
unless they were told.  We were lucky on the HyperCard 2.0 team to have
people who were willing to do such "dirty jobs".  Those limitations, as
well as others I won't mention here, are now gone, and many more things
in HyperCard just work the way they should.  No glitz, no glamour --
they just work.


Kevin Calhoun
jkc@apple.com