kulp@cs.nps.navy.mil (Jeff Kulp x2174) (07/26/90)
Will stacks written using Hypercard version 1.2.x run under version 2.0? Jeff Kulp kulp@cs.nps.navy.mil
psych@watserv1.waterloo.edu (R.Crispin - Psychology) (07/26/90)
In article <1133@cs.nps.navy.mil> kulp@cs.nps.navy.mil (Jeff Kulp x2174) writes: > > Will stacks written using Hypercard version 1.2.x run under version 2.0? > >Jeff Kulp >kulp@cs.nps.navy.mil I have tried all of my major stacks and they all ran. There is a problem with some of the XCMDS though especially ones that try to work directly with fields (like FileToField). They need to be converted (a simple process) otherwise they are locked. Richard Crispin Phone: (519)888-4781 Dept. of Psychology Bitnet: psych@watdcs University of Waterloo Internet: psych@watserv1.UWaterloo.ca Waterloo, Ont. Canada N2L 3G1
jkc@Apple.COM (John Kevin Calhoun) (07/26/90)
> Will stacks written using Hypercard version 1.2.x run under version 2.0?
Yes. Until you convert them to the new 2.0 file format, they'll operate
as read-only stacks in 2.0, just as they operate in 1.2.x when they live
on locked disks, for example.
The conversion is easy. When you open a 1.x with 2.0, the "Compact Stack"
item in the File menu changes to "Convert Stack". Choose "Convert Stack"
and HyperCard does the rest. It's just as painless as compaction (and
in fact is really the same thing internally). Once a stack is converted,
however, you can't open it anymore with 1.x. There's nothing wrong with
that, unless you discover an incompatibility between your stack and
HyperCard 2.0. It's wise, then, to convert a copy of the stack and check
it out under 2.0 before chucking your old copy of HyperCard.
So, the following question will undoubtedly come up: what incompatibilities
are likely to arise? We've seen two, both of which occur infrequently--
1) An XCMD that worked fine under 1.x has trouble under 2.0. The
cause is usually that the XCMD made some assumption about HyperCard's
world--it's use of memory, for example--that is no longer valid.
The vast majority of XCMDs continue to work under 2.0.
2) A script has an error in code that never executes. The old interpreter
would never see the offending line, and so the script would work. The
compiler knows all, sees all, and will refuse to run the script.
Although you may be thinking to yourself, gosh, I wonder if this will
happen to me, I doubt that you'll run into this. It's more of a
theoretical worry than a practical problem. It hasn't come up very
often in our testing.
Anyway, although incompatibilities will be rare, they will arise. So, my
advice is to convert a copy and check it out. Then, when you come to know
and love 2.0 the way we do, you can abandon the past and take advantage of
the many, many improvements.
Kevin Calhoun
Software engineer
Apple Computergft_robert@gsbacd.uchicago.edu (07/27/90)
----------------- In article <43360@apple.Apple.COM>, jkc@Apple.COM (John Kevin Calhoun) writes... [... >Anyway, although incompatibilities will be rare, they will arise. So, my >advice is to convert a copy and check it out. Then, when you come to know >and love 2.0 the way we do, you can abandon the past and take advantage of >the many, many improvements. Um, is there any clue as to when we might be able to "come to know and love 2.0" the way you do? I know, patience is a virtue, but all this talk of 2.0's features makes me impatient. :-> Robert ============================================================================ = gft_robert@gsbacd.uchicago.edu * generic disclaimer: * "It's more fun to = = * all my opinions are * compute" = = * mine * -Kraftwerk = ============================================================================
bc@Apple.COM (bill coderre) (07/27/90)
|>Anyway, although incompatibilities will be rare, they will arise. So, my |>advice is to convert a copy and check it out. Then, when you come to know |>and love 2.0 the way we do, you can abandon the past and take advantage of |>the many, many improvements. In addition to 1) XCMDS, and 2) semi-buggy code, let me add 3) piggy stacks to the list. Some stacks (games, for example) are very piggy about their running environment, and therefore will take total control of HC, preventing the user from doing other things. This will be painful when you open a games stack "in a new window" and then discover that you have trouble with other open stacks. Workaround: don't do that! Some other, not so piggy stacks also have trouble with the multi-window concept of reality, although most of that trouble won't be harmful. BTW, HC 2.0 will "save a copy" of a HC 1.x stack just as well as HC 1.x will, so that should simplify things for you cautious types. Personal advice: be cautious! Bugs tend to be pitifully inoffensive, but you shouldn't take the chance. Do make a copy, then blindly smash ahead. Better advice: have a LOT of fun! mr HEINOUS final and ultimate arbiter of taste and discretion.
man@eilat.cs.brown.edu (Mark H. Nodine) (07/27/90)
In article <1990Jul26.192703.894@midway.uchicago.edu>, gft_robert@gsbacd.uchicago.edu writes: |>----------------- |>In article <43360@apple.Apple.COM>, jkc@Apple.COM (John Kevin Calhoun) writes... |>[... |>Um, is there any clue as to when we might be able to "come to know and love |>2.0" the way you do? |> |>I know, patience is a virtue, but all this talk of 2.0's features makes me |>impatient. :-> That brings up another question. I currently have an 800K disk with a Finder (Minifinder, actually), a System 6.0.5, HC 1.2.5, the Home stack, and a Ramdisk program. When I start up from it, it creates a RamDisk, copies the stuff exclusive of the RamDisk program to the Ramdisk and makes the RamDisk my startup disk. That way, I can run my HC stacks with no hard disks (useful when I'm traveling). So my question is: how much bigger is HC 2.0 than HC 1.2.5? Do I still have any chance of being able to do this? I think I have about 80K free on the startup disk in my current situation. --Mark
ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) (07/30/90)
In <45998@brunix.UUCP>, man@eilat.cs.brown.edu (Mark H. Nodine) asks about the size of HyperCard 2.0 versus the current version. On my hard disk, HyperCard 2.0B25 takes up 613K, versus 384K for 1.2.5. I guess if you want to continue avoiding hard disks, you'll have to go to a high-density floppy... Lawrence D'Oliveiro fone: +64-71-562-889 Computer Services Dept fax: +64-71-384-066 University of Waikato electric mail: ldo@waikato.ac.nz Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00 And finally, a message for all power users: pay your electricity bills!
bc@Apple.COM (bill coderre) (08/01/90)
Lawrence: |On my hard disk, HyperCard 2.0B25 takes up 613K, versus 384K for |1.2.5. It's a Bad Idea to go predicting code sizes based on betas. Some betas contain debug code, which of course would make them bigger and slower. I wouldn't doubt HC 2 ending up bigger than version 1, though. There's a LOT more features in it. It might make sense to develop in version 1, keeping an eye on version 2 compatibility (not a real challenge, mind you) for those with more memory/disk space/big screens, whatever. bill coderre consultant to apple
SAS102@psuvm.psu.edu (Steven A. Schrader) (08/01/90)
In article <43469@apple.Apple.COM>, bc@Apple.COM (bill coderre) says: > >Lawrence: >|On my hard disk, HyperCard 2.0B25 takes up 613K, versus 384K for >|1.2.5. > >It's a Bad Idea to go predicting code sizes based on betas. Some betas >contain debug code, which of course would make them bigger and slower. > >I wouldn't doubt HC 2 ending up bigger than version 1, though. There's >a LOT more features in it. Actually the size would not bother me greatly if we could compile the code so HyperCard programs could run without HyperCard. Even if HC 2 does become only 500K, that means you have roughly 200K left for a stack (which is not an incredible amount). If we could compile the whole thing to use only those parts of HyperCard we need, out 200K program might turn into 400K, but might not need Hypercard and the Home stack (Which also gets up to 100 - 200 K). This is one of the niggest downfalls of HyperCard--it's reliance on itself to run. If we can compile Hypercard can go from a developing tool to a complete app builder. ========================================================================= Steven A. Schrader (SAS102 @ Psuvm.Bitnet) Graduate Student Consultant Student Support Initiative, The Center for Academic Computing The Pennsylvania State University
man@eilat.cs.brown.edu (Mark H. Nodine) (08/01/90)
In article <90213.091703SAS102@psuvm.psu.edu>, SAS102@psuvm.psu.edu (Steven A. Schrader) writes: |>Actually the size would not bother me greatly if we could compile the code so |>HyperCard programs could run without HyperCard. Even if HC 2 does become only |>500K, that means you have roughly 200K left for a stack (which is not an |>incredible amount). If we could compile the whole thing to use only those parts |> of HyperCard we need, out 200K program might turn into 400K, but might not |>need Hypercard and the Home stack (Which also gets up to 100 - 200 K). The only problem with this suggestion is how do you know what parts of HyperCard will be needed and what parts won't. For example, one of my stacks is being used for keeping my maps and other things during fantasy role playing (a la D&D) expeditions. A great advantage that HyperCard has is that I can draw on and change the maps on the fly, using the paint tools, even though my stack is a complete "application". Also, some of my buttons use the painting tools as well to draw things on the screen. --Mark
APPLEREP@MTUS5.BITNET (08/02/90)
Don't forget, also, that the ability to customize an existing stack is one of Hypercard's greatest strenghts. It gives the user the ability to both utilize parts of someone else's stack in the way that best benefits them, and to learn a great deal about stack construction. If Hypercard stacks were to be saved as compiled applications, I think you would probably lose a lot of that great open-endedness that it has. Tom Amberg Apple Student Rep Michigan Technological University (Go Huskies!!) Disclaimer: (the usual stuff)
bc@Apple.COM (bill coderre) (08/03/90)
In article <90213.175513APPLEREP@MTUS5.BITNET> APPLEREP@MTUS5.BITNET writes: |Don't forget, also, that the ability to customize an existing stack is one |of Hypercard's greatest strenghts. Ahh, but commercial stack developers aren't real keen on this, because it also allows competitors to see how their code works. Thus, incredibly involved pipeworks of protection code. But this is neither dross nor scoria. The problem with compiling HC is that it is, at heart, a "late binding" language. Consider this example: on mouseup get cd fld "code" do it end mouseup Since HC has no idea what is in the field until the moment the mouse goes up, it would have to carry around -- at the very least -- an interpreter or compiler in EVERY compiled stack, to execute the "do." And if HC was "nice," it would carry around all of itself in any compiled stack, just to make sure that any valid hypertalk the user entered could be executed. Thus compiled stacks wouldn't be able to shrink. Note that there are several ways around this. Many popular late binding languages, such as Common Lisp, allow both. 1) Allow the user to specify various lumps of code that can be left out. If HC can't "do" because of missing code, the application vomits. 2) Enforce that any compiled stack cannot contain any "do" that has a non-constant as an argument. This allows lots of code removal, but hinders many other HC features, such as the Message Box, and XCMDs, which often ask HC to evaluate a line of hypertalk. These aren't such big problems to many developers, and indeed a campiled stack would be a wonderful thing: smaller, faster, more secure, and easier to ship (no need to demand a certain HC version on disk). The only problem is simply that it is a gigantic leap in complexity, even assuming that stack scripts are partially compiled now. Many Lisps don't allow "application building" even though they compile all their code. Application building is simply a huganic problem to do "right." This is not to say that Hypercard or Supercard shouldn't do it. It's just to say why it isn't easy, and therefore why it tends not to be done. bc consultant, not mouthpiece
ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) (08/07/90)
In <43469@apple.Apple.COM>, bc@Apple.COM (bill coderre) comments (on my posting about the size of HyperCard 2.0B25) "It's a Bad Idea to go predicting code sizes based on betas. Some betas contain debug code, which of course would make them bigger and slower." I just had a look for debugger symbols, and apart from a small number of glue routines, I couldn't find any. This suggests that most of the debug code has been removed. Lawrence D'Oliveiro fone: +64-71-562-889 Computer Services Dept fax: +64-71-384-066 University of Waikato electric mail: ldo@waikato.ac.nz Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00 "...so she tried to break into the father bear's computer, but it was too hard. Then she tried to break into the mother bear's computer, but that was too easy..."
stadler@Apple.COM (Andy Stadler) (08/08/90)
In article <1170.26bef8bc@waikato.ac.nz> ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: > >I just had a look for debugger symbols, and apart from a small number >of glue routines, I couldn't find any. This suggests that most of the >debug code has been removed. > Besides the normal Mac debugging symbols (which are indeed left out in any external build) HyperCard also includes a complete internal debugging package. Some pieces of this may or may not still exist. Unlike debug symbols, to a disassembler or tracer they would look just like more subroutine calls. However, let's not kid ourselves - HC 2.0 -is- quite a bit bigger than 1.x. --Andy stadler@apple.com
stm@apple.com (Steve Maller) (09/07/90)
In article <45998@brunix.UUCP> man@eilat.cs.brown.edu (Mark H. Nodine) writes: > So my question is: how much bigger is HC 2.0 than HC 1.2.5? Do I > still have any chance of being able to do this? I think I have > about 80K free on the startup disk in my current situation. The final size of HyperCard 2.0 is 684,081 bytes. The Finder says that accounts for 669K on the floppy disk. Steve Maller HyperCard Engineering Team Apple Computer
gaynor@hpuxa.ircc.ohio-state.edu (Jim Gaynor) (09/07/90)
In article <10075@goofy.Apple.COM> stm@apple.com (Steve Maller) writes: > >The final size of HyperCard 2.0 is 684,081 bytes. The Finder says that >accounts for 669K on the floppy disk. Does this mean it's done, Steve? One of my local retailers told me that his Apple guy was stating a shipping date of this week. I'd love to find out that it's true... -=- +-----------------------------------------------------------------------------+ | Jim Gaynor - The Ohio State Univ. - IRCC - Facilities Mgmt. - OCES <whew!> | | Email [gaynor@hpuxa.ircc.ohio-state.edu], [gaynor@agvax2.ag.ohio-state.edu] | |_ "Don't tell me truth hurts, little girl; because it hurts like hell..." _|