tom@wcc.oz (Tom Evans) (11/23/90)
I just got a copy of HyperCard 2. I need it in order to test the configuration stack we ship with our product. However, HC2 wants at least system version 6.x.5, and I'm running 6.x.4. If I upgrade my Mac (to 6.x.7 - the only other version I have), what "normal" 1.2.x HyperCard can I run on it? Summary: Does anyone have a (complete?) "This version HyperCard runs on this version System" list? It would be most useful. Thanks. ======================== Tom Evans tom@wcc.oz.au Webster Computer Corp P/L, 1270 Ferntree Gully Rd Scoresby, Melbourne 3179 Victoria, Australia 61-3-764-1100 FAX ...764-1179
jdevoto@Apple.COM (Jeanne A. E. DeVoto) (11/24/90)
In article <1180@wcc.oz> tom@wcc.oz (Tom Evans) writes: >I just got a copy of HyperCard 2. I need it in order to test the >configuration stack we ship with our product. However, HC2 wants at >least system version 6.x.5, and I'm running 6.x.4. If I upgrade my Mac >(to 6.x.7 - the only other version I have), what "normal" 1.2.x >HyperCard can I run on it? > >Summary: Does anyone have a (complete?) "This version HyperCard >runs on this version System" list? It would be most useful. Since 6.0.7 has the new Sound Manager, it's not compatible with any HyperCard version previous to 2.0. If you don't use any sound ("play", "dial", or "beep"), it should probably work without major problems. What I'd suggest is that you, by hook or by crook, get a copy of 6.0.5, since it has the distinction of being the only version that supports HyperCard 1.2.5 and 2.0. System 6.0.2 6.0.3 6.0.4 6.0.5 6.0.7 HyperCard 1.2.2 x x 1.2.5 x x 2.0 x x -- ========= jeanne a. e. devoto ======================================== jdevoto@apple.com | You may not distribute this article under a jdevoto@well.sf.ca.us | compilation copyright without my permission. ______________________________________________________________________ Apple Computer and I are not authorized | CI$: 72411,165 to speak for each other. |
ollef@sics.se (Olle Furberg) (11/25/90)
In <46787@apple.Apple.COM> jdevoto@Apple.COM (Jeanne A. E. DeVoto) writes: >Since 6.0.7 has the new Sound Manager, it's not compatible with any >HyperCard version previous to 2.0. If you don't use any sound ("play", >"dial", or "beep"), it should probably work without major problems. In what sort of circumstances could I get a crash when using sound in HC 1.2.x together with System 6.07 ? Apparently it does work anyway, or am I doing something wrong? :-) Even worse: I could play both beep and boing in a copy of the very old HyperCard 1.1 (e.g. "play boing a f g e"). This is an important question because a lot of (end)users find HC 2.0 to slow (running it on a MacPlus) and to big (you can't fit it on a 800 Kb disk together with a minimalized System (this was possible with HC 1.*).
smelly@polari.UUCP (Tom Benedict) (11/29/90)
The HC2.0 vs System compatibility problems has one other aspect which is notable: The new machines (Classic,LC,si) MUST runs system 7x6.07. Since ONLY HC2.0 will run under 6.07 HC1.2x will NOT run on a new machine. The upgrade situation is a real thorn for system administrators who would like to stick with HC1.2x for performance reasons yet must run HC2 on some machines. Also, for stack developers, the assumption that potential users will have HC2.0 is no longer valid. User's need a compelling reason to upgrade (spend money) not just an interest in running someone's stack.
jdevoto@Apple.COM (Jeanne A. E. DeVoto) (11/29/90)
In article <1990Nov24.235328.10009@sics.se> ollef@sics.se (Olle Furberg) writes: > In what sort of circumstances could I get a crash when using sound in >HC 1.2.x together with System 6.07 ? Apparently it does work anyway, or am >I doing something wrong? :-) Even worse: I could play both beep and boing >in a copy of the very old HyperCard 1.1 (e.g. "play boing a f g e"). Sorry; "I only know what they tell me." I don't have a machine set up with 6.0.7, although some people have told me they've crashed using 1.x sound commands under System 6.0.7. I suppose it depends on your exact configuration. -- ========= jeanne a. e. devoto ======================================== jdevoto@apple.com | You may not distribute this article under a jdevoto@well.sf.ca.us | compilation copyright without my permission. ______________________________________________________________________ Apple Computer and I are not authorized | CI$: 72411,165 to speak for each other. |
ba0k+@andrew.cmu.edu (Brian Patrick Arnold) (12/01/90)
Howdy, On 28-Nov-90 in Re: HyperCard Vs System Ver.. user Tom Benedict@polari.UUCP writes: > The upgrade situation is a real thorn for system administrators > who would like to stick with HC1.2x for performance reasons yet > must run HC2 on some machines. No offense to the wonderful HyperCard team and users striving for a stronger, better, faster HyperCard, but experience tells me you shouldn't even be using HC if (script) performance is an issue. The relative tradeoff of upgrading is nothing compared to your decision to use HC over something else. "Hmm, abysmal performance or worse-than-abysmal performance, hmm...I'll pick abysmal performance..." HyperCard is great for some tasks, but if you can use an analog watch to time the performance of a script, it's time to consider the alternatives. Perhaps I have overstated the understatable. - Brian
bc@Apple.COM (bill coderre) (12/03/90)
Brian Patrick Arnold: |No offense to the wonderful HyperCard team and users striving for a |stronger, better, faster HyperCard, but experience tells me you |shouldn't even be using HC if (script) performance is an issue. The |relative tradeoff of upgrading is nothing compared to your decision to |use HC over something else. "Hmm, abysmal performance or |worse-than-abysmal performance, hmm...I'll pick abysmal performance..." |HyperCard is great for some tasks, but if you can use an analog watch to |time the performance of a script, it's time to consider the alternatives. Although Hypercard stacks do not run as fast as compiled programs, there are many applications where this is not a problem. For instance, any application which is, essentially, just a user interface to a complex data structure, or a front end for an application running on a mainframe, will prove eminently suitable to Hypercard development for the following reasons: Hypercard is fast enough -- users rarely are made to wait (careful app designers will only make users wait when the users expect to wait -- for instance, when the user presses the "Save" button) There is the possibility that time-critical code segments can be commissioned as XCMDs, which will drastically increase performance and are much easier to write than C or Pascal Macintosh applications. It has a dramatically quicker turnaround than any other programming language. A new programmer can begin work in days, and an experienced programmer can bang out a FUNCTIONAL proto in mere hours. It requires drastically less code to be written than other programming languages. It insulates the program from the Mac Toolbox. It provides for a very standard user interface, easily. It provides applications which run on most all Macs, first time. It has a better debugger than other programming languages. Thanks to gurus like Harry Chesley, complex interprocess communication (like TCP-IP or SQL) can be implemented as easily as any other function call. When I was called onto a "demo tomorrow" contract, I used HyperTCP and MitemVIEW to send SQL queries to a (huganic) database service. By the end of the afternoon, I had all the queries in and was putting the company logo onto cards, and polishing the interface. In contrast, the X windows + Motif guys (four of the best in the area, I was told) were rebuilding the Unix kernel again. Late that night, the other groups were using MY stack to test their queries. When the queries changed, I was back on line within MINUTES. Program speed? One second response overhead for any transaction, which usually took between 5 and 15 seconds each. Assuming C runs at the speed of light, I paid 16% extra (maximum) to write my code in Hypercard. There is more to programming than processor speeds and code optimization. Although some hackers would never admit it, a simpler program is always a better one. Hypercard programs are simpler to maintain, upgrade, and debug than many others. Sure Hypercard is not as fast as C, but if the program in question is not filled with complex, iterative calculations, Hypercard will be nearly as fast as a compiled application. And the program will be delivered much sooner, and with much more user feedback, than a custom app. bill coderre former Hypercard consultant not an apple spokesperson