PART 6: CUSTOMIZED LAUNCHERS
Pass parameters and collect $200
When Atari created TOS, its software engineers designated two very different ways programs could run. They could be mouse-and-window applications -- PRoGrams, which had to have names ending in ".PRG" -- or they could be text-based applications that did not use the mouse and its associated paraphernalia. These are called TOS applications, and they look for all the world like programs that run under the standard PC operating system, MS-DOS. (They are, in fact, quite similar to DOS programs in some ways.)
But Atari did something unknown in the MS-DOS world when it settled on TOS programs as the non-mouse (or non-GEM) applications that would run on the ST. It made two categories -- one for TOS programs that needed parameters and one for the ones that didn't. If this is all gobbledegook to you, stick with me; TOS programs can be very important, and the way they run can be applied in a more general way, too, now that Atari programmers have learned how to unleash the full power of both GEM and non-GEM software.
I remember how disappointed I was the first week I spent with my new 520ST nine years ago when I discovered that least friendly version of all Atari programs, the .TTP monster. Double-clicking on a .TOS program made it run, but double-clicking on a .TTP program made a box appear on the screen asking me to type something. If I'd wanted to type something at a command line, I would have stuck with my Atari 130XE and its wonderfully adaptable operating system, SpartaDOS. Here was a computer with a graphical user interface that suddenly reverted to the old type-in-your-favorite-command system -- that is, if you were able to remember the command you were supposed to type in. If you ran the early version of ARC in those days, you were supposed to type in "-X" or "-E" or just "X" or "E" (I'm glad I've forgotten which it was!) followed by the path and filename to extract a file, like this: -X A:\ARCFILES\THISFILE.ARC.
I hated .TTP programs. Under later versions of TOS, I found that I could drag the icon of a file to the icon of the .TTP program and get at least part of the command line filled in by TOS. But I had to do the rest. Even NeoDesk 3, the first modern version of Gribnif's desktop, wouldn't free me from this horrible backwater world of command lines and parameters; it still acted like TOS did, forcing me to fill out the rest of the command line. (And NeoDesk 4 still acts the same way, unless you do something about it. The problem is not with the desktop but with the rules of TOS; a .TTP file needs parameters. That's what .TTP means, after all -- TOS Takes Parameters -- and so if you double-click on a .TTP file or drop another file onto it, even NeoDesk 4 will poke a dialog box in your face and tell you to fill it out.) In yer face, indeed! This is NOT my idea of a user-friendly system.
It doesn't have to be that way. I'll tell you how you can get around this inconvenience shortly.
You use parameters every day
But first we need to look at parameters another way. They're not just instructions on a command line you type in. And they don't just go with .TTP programs. Any Atari program can be written to use parameters, and most major pieces of software are, in fact, written that way. We usually don't think of them as using parameters unless we encounter one of those rare .GTP programs -- a GEM program that Takes Parameters. But parameter-passing is common, and it's exactly what takes place any time you drop an icon for a data file onto the icon for a program. (My favorite example is dropping the icon for a ZIP archive onto the icon for STZIP.PRG. The operating system runs STZIP and passes it the parameter of the path and filename of the ZIP file. But another common example is dropping the icon for a text file onto the STeno icon or the icon of any other word processor.)
This is a simple kind of parameter passing. Some specialized programs such as LHARC.TOS (which is generally distributed as LHARC.TTP for no good reason) allow a dozen or more separate parameters to be passed to the program when it runs. Some programs almost beg for parameters in order to run properly. A good example is JonDOS, one of the better command-line interpreters for the Atari, which will misbehave under Geneva unless it is run with "-t" as the parameter. This tells it to act like a TOS program -- no mouse, with all operations occurring within a standard TOS 25-line display -- instead of a GEM program.
(A digression is again in order. LHARC takes parameters, so it is normally distributed as a .TTP program. But this can defeat one of the cleverest features of LHARC, its ability to automatically run and either extract an archive's contents or compress a file or folder without a need for any action by the user. LHARC does this by examining the parameters the operating system passes to it. If the parameters include a filename with the extension ".LZH," LHARC extracts the archive to a folder. If the parameters do not include ".LZH," LHARC creates an archive and compresses the file or folder listed in the parameters. This is all very elegant; drop a folder on the LHARC icon, and it does the rest, creating an archive. Or drop the icon for an LZH file onto the LHARC icon, and it extracts the contents to a folder. But this will NOT happen so elegantly if you insist on using LHARC with its original filename extension, .TTP, because the operating system will stick that dialog box in front of your face and tell you to fill it out, as it must do with .TTP programs.)
To a word processor, a text file can be a parameter. But the same kind of operation can take place with other software, too. You can run Flash, the original high-power telecommunications program for the Atari, by passing it a parameter that consists of the name of one of its DO files. (DO files are scripts that tell Flash what to do.) You can run STalker, a modern Atari telecomm program, with a parameter that consists of the name of a BackTALK script; STalker will run, load the script automatically, and execute the instructions in the script. There are countless other examples.
But how do you do that? Ordinarily, you look at the icon for STalker, and you see only one thing you can do with it to get it to run -- you double-click on it. But you could drag the icon for a BackTALK script onto the STalker icon (or onto its name in a text-only window display, of course) and it would run and execute the instructions in the script. You could do it that way, that is, if you have the script icons and the STalker icon handy; you can't drag something that's not available on the desktop or in a window.
Give me an N! Give me a P!
NeoDesk 4 offers an easier way. It's also a more powerful way. It's called the NeoDesk Program Information file. An NPI can do much more than what I have suggested here -- there is probably no limit to the inventiveness you could put an NPI to -- but at its most basic it can readily automate such tasks as passing parameters. When you set up an NPI, you'll see a dialog for entering the parameters. Keep in mind that some programs do not behave as you might expect when they receive parameters, so you'd be wise to experiment. (You can't hurt anything.) Start with something simple, such as passing a script name to a telecomm program, and then graduate to something more complicated. (With LHARC, you could create one NPI that ran LHARC in minimal-memory mode, another that ran it in maximum-memory mode, and so on. If you double-click on LHARC.TOS with no parameters, you'll see a list of possible commands that can be passed to LHARC on startup.)
NPIs can be named by normal-language conventions ("Mini-LHarc," for example) instead of by the 8-and-3 ("MINILHAR.NPI") requirement of normal filenames. Unfortunately, NeoDesk 4 has a bad habit of overriding the name you have chosen and using its own best-guess filename, which uses the old 8-and-3 convention. If this happens, change the name NeoDesk assigns back to a normal phrase. (Note that a file display under NeoDesk 4 shows the name you assigned, not the 8-and-3 filename, but a display using a utility such as MaxiFile or the Geneva item selector will show the TOS filename.)
Because NPIs are program-launching instructions and not executable files per se, they are very small, taking up only one sector, the minimum amount of individual space that can be allotted on a floppy disk or hard disk. This means you can store all your NPIs in one place without a problem. It also means you can place them in Groups easily. But try to resist the temptation of creating a Group just for NPIs. It makes no sense having one icon in a Group run LHARC and another run STalker; rather, place your NPIs into the Groups they naturally fit into, with archivers in one Group and telecomm software in another, or utility software in one Group and applications in another, and so on.