Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!julius.cs.uiuc.edu!apple!goofy.apple.com!chesley
From: chesley@goofy.apple.com (Harry Chesley)
Newsgroups: comp.sys.mac.hypercard
Subject: Re: XCMD/XFCNs in HC & elsewhere: standardization?
Message-ID: <10283@goofy.Apple.COM>
Date: 18 Sep 90 20:02:54 GMT
Sender: usenet@Apple.COM
Organization: Apple Computer, Inc.
Lines: 24
References:<7262@milton.u.washington.edu> <10187@goofy.Apple.COM>

In article <10187@goofy.Apple.COM> stm@apple.com (Steve Maller) writes:
> > Several XCMD/XFCN's that I use either definitely or probably will need
> > to be re-written to work in HC 2.0
> 
> On what authority do you make this statement? Have you tried these XCMDs 
> in 2.0? We have tried very hard to keep things compatible and eliminate 
> the need for major rewrites.

Most of the communications-oriented XCMDs which I've written need to be 
rewritten, at least in some minor ways. This is because HyperCard 2.0 is 
picky about how XCMDs do memory management. In particular, you cannot do 
NewPtr when allocating memory which will continue to exist across XCMD 
calls. Instead, you need to do NewHandle/MoveHHi/HLock. If you use NewPtr, 
then HyperCard cannot open a larger card/window than the one it had open 
when you did the NewPtr, and until that NewPtr'd block is disposed of.

This affects the Serial Port Toolkit, MacTCP Toolkit, and the 
soon-to-be-available Comm Toolbox Toolkit (beta release coming any second 
now, available on the next Developer CD, from AppleLink, and for anonymous 
FTP from apple.com). In fact, in the case of the Comm Toolbox, I can't do 
anything to fix it, since the CTB does it's own memory allocation and uses 
NewPtr. I assume the Videodisc Toolkit is also affected (unless you've 
changed it to not use the same XCMDs as the Serial Port Toolkit, Steve; I 
haven't looked at it recently).