Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!claris!apple!blob From: blob@Apple.COM (Brian Bechtel) Newsgroups: comp.sys.mac.hypercard Subject: Re: CD-ROM; HyperCard; request for info Message-ID: <14269@apple.Apple.COM> Date: 19 Jul 88 14:40:13 GMT References: <183@pai.UUCP> Reply-To: blob@apple.apple.com.UUCP (Brian Bechtel) Organization: Apple Computer Inc, Cupertino, CA Lines: 95 In article <183@pai.UUCP> erc@pai.UUCP (Eric Johnson) writes: >1) With HyperCard, is a CD-ROM drive essentially a large floppy, or >will I have to write special software to access the drive? A CDROM drive is essentially a large,fast floppy. You use the same calls that you use for any HFS volume. (This will continue to be true for High Sierra formatted discs as well.) >It seems the ideal solution would be to create a series of linked >stacks on a hard disk, and then simply copy the stacks to the CD, >treating the CD like a very large hard disk. If you have a large enough hard disk ... :-) Yes, this is correct. But remember the performance hit due to the slow seek time of CDROM drives! >With the links built into the stacks in HyperCard, it seems that >treating the CD as a disk is the easiest way to go. If special >software needs to be written, does anyone have pointers to where >I can find out what to do? No special software needs to be written. >2) Are there any limitations to running Hypercard stacks on a CD? >Obviously the media is read-only, but are there other limitations >that may bite me? The seek time on CDROM is much slower than that of hard disks. You should be sure to optimize the placement of your data so that extensive seeking isn't required. Hypercard 1.2.1 is completely compatible with read-only media. >3) What would be the best type of stack organization on a CD: >many smaller stacks, or a few very large ones? For which is >HyperCard most efficient? I'll have to let someone else comment on this one. On the Learning Disc that we distributed at the Microsoft CDROM Conference, we had five sets of stacks for the demonstrations of work in progress on that disc: * Whole Earth Catalog 18 stacks, plus 66 sound stacks (over 2 hours of processor-quality sound was included in these stacks) * Grollier's U.S. History 13 stacks * Univ. of Southern California Freshman Writing project 5 stacks * Project Perseus (Harvard/Bowdoin Ancient Greek civilization) 21 stacks * Stanford School of Medicine Electronic Cadaver 1 stack So it depends upon what you're trying to do. Logically, I'd suspect that it makes sense to create a new stack if what you are showing the user is a distinct phase of the data. (By the way, we DON'T have any more learning discs; we handed them all out at the conference, and can not press any more.) >4) Is the CD-ROM mastering process much the same for the Apple >drive as for other CD-ROM drives, or do we have to find a special >Apple-compatible masterer? When I read about mastering costing only >$1,500 and reproduction only ~$2 per disk, it looks like the age of >CD-ROM is here. (Now, if only they would make the drives cheaper.) >What are the real costs to be expected for mastering, packaging, etc.? Well, according to a typical example price list I have in front of me, (Discovery Systems) costs are: $1500.00 for mastering the disc $2.00 per disc, duplication fee $0.25 per disc, jewel box $0.05 per disc, insertion of folder, booklets or liner $0.05 per disc, shrink wrap with all printed materials supplied by the customer. >5) What are some common pitfalls others have encountered when creating >similiar applications? Any experiences to share? There is a limitation as to the number of distinct icons that can appear on a volume. The Finder uses the Resource Manager to keep track of the desktop file (containing links from file types to icons). The maximum number of resources in a file is 2,727 (see TN 141). The Finder needs four resources (at least) for each application (BNDL, FREF, ICN#, signature) so this limits you to no more than 681 applications (roughly. You may have other resources in this file, so the actual number may be smaller.) This will be addressed in a future version of the Finder. Meanwhile, keep the number of distinct icons down. This isn't a problem for most applications; people pressing large amounts of public domain software are the only ones we've found so far who hit this limit. Brian Bechtel blob@apple.apple.com "Although this may look like interesting information, it's my opinion, not Apple's."