Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!amdahl!kim From: kim@uts.amdahl.com (Kim DeVaughn) Newsgroups: comp.sys.amiga Subject: Re: S/W Installation methodology Message-ID: Date: 4 Jan 89 18:24:26 GMT References: <2071@van-bc.UUCP> Organization: Amdahl Corporation, Sunnyvale, CA 94086 Lines: 125 [ ... ] I'm posting the following for Mike Robinson, WRT s/w installation: /kim vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv Here is a clarification that you might wish to post to the net for me. - - - - Let me clarify and expand upon my previous append: Software that requires a complicated install procedure should be accompanied by a program that carries out that procedure. It should make assumptions that are true for most "vanilla" installations. But since not all installations are "vanilla," as Andy Finkel pointed out, the install procedure should be some sort of a script, which can be modified at will by those who need to do so, or simply printed off and followed by hand, again by those who need to do so. This is a logical application for REXX, because it is much more expressive than EXECUTE and Because It Is There. ======= == == ===== REXX has made an enormous impact on the VM/CMS community. But I hasten to point out that this impact would not have occurred if REXX had been a separately licensed program product. It is bundled with every operating system, so every user has it. That is a critical element in its success; otherwise, its power would be wasted. Simple corollary? (You knew it was coming.) Hypercard. Nice program. Clever idea. Some would say innovative. Maybe so. But what we CAN say about it right now is that it WILL have an impact on the Macintosh community, no matter how good or bad it is. Two reasons: it has Apple's official sanction, and BECAUSE IT IS THERE. Since application developers know that the software has been bundled with Release X.X of the Macintosh system, they will begin to write programs that install themselves using Hypercard scripts, and they will begin to write programs that actually incorporate Hypercard as part of their functionality. Leverage, my dear Watson. Leverage!! No, no. Hypercard is not REXX, and REXX is not Hypercard. But they share a common trait: they are an externally-developed, generally-available piece of software that amplifies the existing functionality of other tools that are able to coexist with them, and which reduces the cost of developing programs that use their features. And for one of the products at least, a large part of its impact BECAUSE IT IS THERE! We're hobbling along with Amiga BASIC and EXECUTE scripts because C-A officially supports and supplies them. Meanwhile, Macintosh users are using MacPaint and MacDraw and Hypercard because Apple officially supports and supplies them. There is another corollary here... I am NOT criticizing Commodore-Amiga or comparing the Amiga unfavorably with the Macintosh. This is a constructive suggestion for something that I believe would make the Amiga a better computer than it already is, and do so at a minimum cost. Thank you for your time and attention. /mr/ ------------------------ Mike further writes --------------------------- In hope of not overtaxing your offer to post to the network, consider one more short one: ---------- I want to see programs and subroutines coming out on Fish disks to help me write Amiga programs more easily. For example, think about how much work you have to go through to create menus and dialog boxes in Intuition. I come not to bury Caesar, but there are better ways to approach this than to code all those data structures by hand. Just *look* at the "SpeechToy" program on the Lattice compiler disks! All necessary, yes, but what a mess! How many times did the author recompile that thing, "diddling" with it until it finally looked right? How about a program that will allow you to construct a menu, or a dialog box, or a control panel... interactively? Take a look at this month's DR. DOBB'S for inspiration. You design the control panel the way you want it, and presto! Out comes "C" source code, or even an object file, to do what you want. It could save days. (If an interactive program is too ambitious, then a simpler design which uses a flat file prepared with a text editor would a good alternative.) Instead of coding all those menu statements by hand, how about this? MAKEMENU(WINDOW,"\001Project\002About...\002Quit\001File\002Open") This subroutine would read the string, and build standard control blocks in memory at runtime. Otherwise they would be a black box. You get the idea. Arguably, these convenience tools would not do anything that you could not do by hand, nor everything that you might want to do. But that is the case with any compiler, and we do not question the usefulness of those. They would give us a head start in writing "most" "typical" applications, and that is enough. /mr/ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -- UUCP: kim@amdahl.amdahl.com or: {sun,decwrl,hplabs,pyramid,uunet,oliveb,ames}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 BIX: kdevaughn GEnie: K.DEVAUGHN CIS: 76535,25