CLIMAX Have you ever wished your CLI window had 25 lines of 80 characters, just like a good old fashioned non-windowing computer? The answer is here: CLImax by Paul Kienitz. It creates a custom screen with a borderless backdrop CLI window. The CLI will be a Shell if you have the Shell-Seg resident. I find it very useful, but it has some idiosyncrasies that you should be aware of: In order to use CLImax, YOU MUST BE USING CONMAN. (As of now (3/89) the newest ConMan is on Fish disk 165.) Furthermore, the Run program, and preferably the Execute program, must be available in your C: directory. (Execute may be in your resident list instead, but the goddamn DOS Execute() function, which I'm still using in this version (though I despise it) doesn't have the sense to look for Run on the resident list.) To end CLImax and erase the screen, just use EndCLI as usual. Unfortunately, IT DOES NOT WAIT FOR OTHER OUTPUT TO THE WINDOW TO STOP. This is apparently a ConMan shortcoming. So don't EndCLI while other output is going to the window from some Run'ed program, or you'll seek enlightenment from the Guru. (Speaking of the Guru, I've noticed that GOMF 1.0 likes to nuke the CLImax screen for no good reason. I don't know about newer commercial versions of GOMF.) UNFORTUNATELY, you can't just say "climax" in CLI like you would say "newcli". This version is primarily intended for running from Workbench or your startup sequence, and it needs to be RunBack'ed. AmigaDOS 1.3 users can use "run > nil: climax". ARP users can ARun it. (I suppose you could WBRun it.) In the future, I'll probably come up with a version that doesn't have to wait for the CLI to end. That would also use about 10K less memory. Command-line/ToolType options: So far there are three. Each consists of just a single letter. From CLI, put the letter(s) after the word CLImax; from Workbench, you can use the Info menu option to modify the ToolType OPTION= which is followed by any or all of these three letters. The letters can be either case with anything in between. The word OPTION must be uppercase with no space before the equal sign. If you say "OPTION= I" or "Run > nil: CLImax I" you get an interlaced screen with fifty lines. You might want to go "setfont topaz 11 window" in the interlaced CLImax, to give you 36 lines with better readability. Of course, European users get 32 lines without interlace anyway, or 46 in interlace with topaz 11. The second option, "OPTION= G", causes the colors to change to black text on a greenish background, a good combination for interlaced text. Ordinarily it uses the same colors as the Workbench screen. Maybe someday I'll add RGB options, but for now if you want different colors you'll have to either use a Palette type program or recompile CLImax with new values. The other option is "V" (for Vanilla; I want to save "C" to mean "color"). The V option makes it ignore the Shell-Startup script and use CLI-Startup. By default, it attempts to start up by executing s:Shell-Startup whether it's a Shell or not. (If you don't use the Shell, this can be a special script that makes your CLI non-vanilla some other way; it will affect NewShell and the Workbench Shell icon too. If you're a 1.2 user, Shell- Startup will be for CLImax only.) If it can't find Shell-Startup, or if you use the V option, it tries s:CLI-Startup. If it actually is a Shell, it will still look like a vanilla CLI in most ways. In this it is like the Workbench CLI program, which it does indeed resemble closely in its internal workings. In fact, even NewCLI will actually produce a shell if the Shell- Seg is resident. CLImax will give a usage summary instead of running if a question mark or letter H appears in the CLI command argument line. In the upper right corner of the screen you'll see parts of the two screen depth gadgets. The screen is actually four lines overscanned vertically, and so (though you can't see it) there is a piece of screen title bar above the top of the window, which you can use to slide the screen vertically, or to click the depth gadgets which are partially uncovered. I know it sounds unaesthetic, but it's not really so bad. Many of the programs you run will create windows and stuff on the Workbench screen, and will seem to be doing nothing if you just look at the CLImax screen. One program that is very useful with CLImax for switching screens is wKeys by Davide Cervone, available on Fish disk 128. Or you might prefer Matt Dillon's DMouse. Personally, I use a modified DMouse with wKeys-like screen flipping features, and a couple of other improvements. If anybody wants a copy of this DMouse I can give you one, but I'm not mass- distributing it because Matt Dillon doesn't like it. Anyway, it's out of date relative to Matt's latest version, which I haven't got yet. It's possible that if you have CLImax and LoadWB both in your startup- sequence that you might end up facing an inactive CLImax window which ignores your typing because the workbench backdrop activated the moment the initial CLI window vanished. Try readjusting positions of these things in startup-sequence; especially try putting CLImax at the very end. One command you might want to put in your Shell-Startup if you use either the Shell icon or CLImax from the Workbench is CD "" (that is, change directory to the empty string in quotes). What this does is correctly set the string that tells what your current directory is, for the prompt (if you use %s in the prompt string). If you don't do this it will show SYS: instead of a real name. This will cost a bit of extra disk access. CLImax when run from Workbench CD's to wherever SYS: is currently assigned. Future plans/hopes: 1) Eliminate need for Run(back) command from CLI. This shouldn't be too far away. Eliminate dependency on ConMan, I hope, which should also make it wait properly for other window output when ending. Options for RGB colors, startup command, etc, and tooltype for startup CD. Someday, no need for Run program, or Execute (present version) or NewShell (near future version). This would make it dependent on the Global Vector, probably. Maybe option to use Execute() if the GV changes on me. CLImax is in the public domain. Feedback is appreciated. If you want to, you can consider this to be $hareware, especially if you want to see an improved version any time soon. (My personal policy is (when I can) to treat all software, from PD to copy-protected, as if it were shareware.) Paul Kienitz 6430 San Pablo ave. Oakland, CA, 94608 USA E-mail: none REVISION HISTORY: First version thrown together 11/27/88. It has I option. It works, but it sucks. Like, "please insert" requesters appear back on the workbench screen, starting from workbench leaves it with no command path and a null current directory, and you have to RunBack it. Next day: made the new screen a WBENCHSCREEN. This makes NewCLI and request- ers etc. appear on the screen they were provoked from. I have no idea if this is kosher or not, so I'll just try it for a while and see if anything breaks. 1/16/89: Made it a custom screen again; made error requesters appear on new screen with pr_WindowPtr. Much less trouble with programs that use CloseWorkBench() to have only one wbenchscreen. Now I want a way to NewCLI onto this screen. (Hey, ConMan 1.3 solves this; use CON:S*/n/n/...) And some programs still put up requesters specifically on the workbench screen. Made it use different default colors for interlace (no choice). 2/13/89: Workaround for ConMan 1.3 change, which I thought at the time was a bug, (no CloseWindow before CloseScreen) and support for Eurousers by checking IntuitionBase->MaxDisplayHeight. New code for using NewShell and letting the CLI clean up the screen itself somehow is partly written but #if'd out. ******* Woops, the workaround is not good with the old ConMan. 2/24/89: I found out how the CLI (aka Shell) program manages to set current dir etc. from workbench. It appends a phony struct CommandLineInterface onto its own struct Process! Then it just goes Execute("execute s:CLI-startup", con, 0); (or Shell-startup) same as I've been doing. It does not set pr_TaskNum. I was amazed to find how it sets the path; the Workbench has a struct CommandLineInterface too! (The path is in cli_CommandDir.) It tests whether the startup script exists before trying to execute it (I hadn't), and if not, goes Execute("", con, 0). New version incorporates the features mentioned above, which considerably increases the complexity of the program. Next day, handled CloseWindow in a way compatible with either kind of ConMan; scan screen's window list first. (Bill Hawes says you're supposed to let ConMan close the window, and if anything the older ConMan was the one with the bug.) Gaaah! Some days, it loses 56 bytes every time it's run from Workbench! Or does it? 3/12/89: Added V option and usage summary. Wrote doc file not long ago. 3/16/89: Added G option. Changing spew() from a macro to a function saved 650 bytes! Preparing for imminent public release... 3/26/89: Still not released. Added OPTION=V/I/G tooltype. ~ 5/20/89 ?! why did I take this long to get it out the door? I've been trying to disassemble NewShell and EndCLI in order to see how to do CLImax better... This involved disassembling chunks of kickstart in order to understand Global Vector calls... I can tell you this much so far: The BCPL compiler produces TRULY BAD CODE. The only reason BCPL programs come out smaller than equivalent C programs is that they have all kinds of library stuff available in the Kickstart that the rest of us never get to use. HEY YOUSE GUYS AT COMMODE-AMIGA -- put something in the Dos library so we can use some of those useful GV entries like #121 (call a loaded program as a subroutine in a CLI environment) and #78 (parse CLI argument line according to a template string, I think) and #33 (the core of NewCLI) and whatever else is useful in there that I haven't found yet! And by the way, the whole idea of the GV is way dumb... an Exec library could do the same job better. At least half the lameness of the BCPL shit is not the language but the compiler implementation. (°¿°) <- Official Seal of Dorkiness certifies that CLImax was written without the use of ROM Kernel Manuals.