Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!apple!apple.com!gandalf
From: gandalf@apple.com (Martin Gannholm)
Newsgroups: comp.sys.mac.hypercard
Subject: Re: Problem with HC 2.0 and Netnews reader 1.2.1
Message-ID: <10576@goofy.Apple.COM>
Date: 5 Oct 90 18:29:48 GMT
References: <228@infolog.se>
Sender: usenet@Apple.COM
Distribution: comp.sys.mac.hypercard
Organization: Apple Computer, Inc.
Lines: 41

In article <228@infolog.se> pera@infolog.se (Per Andersson) writes:
> I have a problem using Netnews reader 1.2.1 together with HC 2.0.
> The problem is that the XCMD's in the Netnews stack must be recompiled 
with
> the new HyperXCmd glue.

Using a well-behaved XCMD with 2.0 should require _no_ recompilation or 
other change. I've been using the NetNews reader stack with HyperCard 2.0 
since April or May, and haven't had any problems at all since June (after 
fixing the bugs with it in the early 2.0 betas). There are 2 or 3 script 
typos in the NNR stack 1.2.1 which HC 2.0 complains about at compile-time 
but the interpreter in HC 1.x never encountered them (they were in 
conditional if-then statements). I run the NetNews reader stack in just 
1000K of multifinder memory and never have any problems -- this I think is 
because of the optimizations we did to the memory usage when doing stuff 
with containers (put after, delete word xx...).

The NetNews reader stack was actually a great test of the new HyperTalk, 
since it uncovered *many* ugly, horrible, deadly bugs. Thanks to Harry 
Chesley for writing a stack that exercised a good mix of HyperTalk!

There is one small problem with the NNR stack, and that is that one of the 
XCMDs allocates a pointer in the heap, effectively inhibiting HyperCards 
buffers to grow. This means that you can't go to a bigger stack after 
you've read NetNews (without quitting and restarting). It the NNR stack 
deallocated its memory on closeStack it wouldn't be such a big problem.

So, to all you XCMD-writers out there: if you need to have something 
locked down, allocate a handle, MoveHHi then HLock. Also, if you only have 
the handle locked when it really needs to be, your XCMD won't interfere 
with HyperCard's memory management. An example of a gracious XCMD is the 
one in the HyperScan stack. It allocates a 175K buffer and  writes it to a 
temp file, but leaves the handle purgeable. Then if HC needs the memory 
the handle will get purged and HyperScan can reload the handle -- this 
only takes 18 ticks on a Mac II with a hard disk.

Martin Gannholm
HyperCard 2.0 Engineer
Apple Computer

Exclaimer!!!   I typed this myself = I speak for myself...