majors@milton.u.washington.edu (Robert Majors) (09/10/90)
Several XCMD/XFCN's that I use either definitely or probably will need to be re-written to work in HC 2.0. These are products like SoundAcess, by Digidesign, and (possibly) The Voyager Videostack, by the Voyager Company. Will it ever become possible for X's to function properly in HC upgrades without modification? What about across platforms? I'm having to jump through loops to get SoundAccess X's to work with AuthorWare Professional, by Authorware. What's involved here: is/will there be a standard for applications and X's which programmers could follow, so that compatibility would not be a problem, or is it more complicated than that? - Bob Majors majors@u.washington.edu
stm@apple.com (Steve Maller) (09/13/90)
In article <7262@milton.u.washington.edu> majors@milton.u.washington.edu (Robert Majors) 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. Of course there are many whizzy new features that you might want to incorporate... Steve Maller HyperCard Engineering Team Apple Computer
chesley@goofy.apple.com (Harry Chesley) (09/19/90)
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).
stm@apple.com (Steve Maller) (09/22/90)
In article <10283@goofy.Apple.COM> chesley@goofy.apple.com (Harry Chesley) 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. Oops. I stand corrected. When I meant "major" rewrites, I meant that things had ceased to operate. What you referred to is a low-level optimization, not really a life-threatening bug. But things will work better after fixing the memory efficiency thingies. Hey, say hi to Tim Pozar for me. I bumped into him a week or so and he said he's working with you. Steve Maller HyperCard Engineering Team Apple Computer