Masterclass Which is the most important file on your Workbench disk? We reckon it's the Startup-sequence, and here's why. S Revisted ---------- (ma1.iff) Although we have touched on it before, the S directory is so important, it's worth taking another look at its contents. Here is what you will see if you open up the S directory on a virginal Workbench 3 machine. You'll need to use the Window menu and pick Show.. All Files to see the contents of S, because by default the files do not have any icons attached. Here's the list of what S contains, and a brief explanation of that the various files do. Startup-Sequence Without a doubt, this the most important file of all. When the Amiga starts to boot up after being switch on, it looks in the S: directory to see if Startup-sequence is present. If it is, it loads it and starts executing the list of AmigaDOS commands it contains. Several very important things are done by the startup-sequence, including patching any bugs in the operating systems, setting the keymap used by the keyboard, creating important directories and copying files to the RAM disk. Eventually, startup-sequence loads the Workbench environment. Here's what a typical startup-sequence looks like. I've added the line numbers -- they aren't present in the file. [ 1] ; $VER: startup-sequence 39.9 (9.8.92) [ 2] [ 3] C:SetPatch QUIET [ 4] C:Version >NIL: [ 5] C:AddBuffers >NIL: DF0: 15 [ 6] FailAt 21 [ 7] [ 8] C:MakeDir RAM:T RAM:Clipboards RAM:ENV RAM:ENV/Sys [ 9] C:Copy >NIL: ENVARC: RAM:ENV ALL NOREQ [10] [11] Resident >NIL: C:Assign PURE [12] Resident >NIL: C:Execute PURE [13] [14] Assign >NIL: ENV: RAM:ENV [15] Assign >NIL: T: RAM:T [16] Assign >NIL: CLIPS: RAM:Clipboards [17] Assign >NIL: REXX: S: [18] Assign >NIL: PRINTERS: DEVS:Printers [19] Assign >NIL: KEYMAPS: DEVS:Keymaps [20] Assign >NIL: LOCALE: SYS:Locale [21] Assign >NIL: LIBS: SYS:Classes ADD [22] Assign >NIL: HELP: LOCALE:Help DEFER [23] [24] IF NOT EXISTS SYS:Fonts [25] Assign FONTS: [26] EndIF [27] [28] BindDrivers [29] C:Mount >NIL: DEVS:DOSDrivers/~(#?.info) [30] [31] IF EXISTS DEVS:Monitors [32] IF EXISTS DEVS:Monitors/VGAOnly [33] DEVS:Monitors/VGAOnly [34] EndIF [35] [36] C:List >NIL: DEVS:Monitors/~(#?.info|VGAOnly) TO T:M LFORMAT "DEVS:Monitors/%s" [37] Execute T:M [38] C:Delete >NIL: T:M [39] EndIF [40] [41] SetEnv Workbench $Workbench [42] SetEnv Kickstart $Kickstart [43] UnSet Workbench [44] UnSet Kickstart [45] [46] C:IPrefs [47] [48] C:ConClip [49] [50] Path >NIL: RAM: C: SYS:Utilities SYS:Rexxc SYS:System S: SYS:Prefs SYS:WBStartup ..SYS:Tools SYS:Tools/Commodities [51] [52] IF EXISTS S:User-Startup [53] Execute S:User-Startup [54] EndIF [55] [56] Resident Execute REMOVE [57] Resident Assign REMOVE [58] [59] C:LoadWB [60] EndCLI >NIL: Here's an what some of the more important lines are doing in the startup-sequence. [ 3] Use the SetPatch command to fix any bugs in the operating system. The Quiet option stops any text from appearing on screen: this would cause the Shell to be displayed instead of the blank screen suddenly being replaced by the Workbench as it pops up. [ 4] Use the Version command display the current Workbench and Kickstart release. However, the output is not printed on screen -- it's sent to the dummy device NIL: So, why do it? Because the command also passes the version into special variables "Kickstart" and "Workbench" [ 5] This command sets aside some memory to act as a buffer for the internal floppy disk. This speeds up access. If you have a reasonable amount of RAM you might want to increase this number to 25. You can also add buffers to hard drives and other floppies if you wish: five are always added by default. [ 6] This makes sure the script won't stop with an error if something bad happens. The error will be reported, but the script will carry on to the end. [ 8] Four directories are created in the RAM disk: T, Clipboards, ENV and Sys. [ 9] The contents of the directory ENVARC (including any sub-directories) are copied from the boot disk to the ENV directory in the RAM disk. It's here that many programs store their preferences and so copying to RAM can speed them all up quite a lot. It also ensures that any changes made to them are temporary until the contents are also saved to ENVARC. The NOREQ keyword stops any requestors from appearing on screen. [11] Makes the command Assign resident, which means it is copied into memory to speed things up a little. Notice the use of the keyword PURE to force the command resident. [12] Makes the command Execute resident. [14] to [26] Makes some important assigns, that is, creates a new device name (such as REXX:) which points to directory or device which already exists. It's a way of creating shortcuts. [28] BindDrivers is hardly used, but when it is it causes any extra hardware to appear to the Amiga by instigating it's driver software. So there. [29] This line mounts all the AmigaDOS devices present in the directory DEVS:DOSDrivers. This could include CrossDos devices, CDROM drives or specialist virtual devices such as PIPE:. Notice how all the files are mounted, except the icons files (which all end in .info) because of the use of ~(#?.info) which means "Not any file ending in ".info". [31] to [39] These instructions process the list of monitors available by creating one large file (stored in T: and called M), executing it and then deleting it. [41] Creates a variable in ENV: called Workbench, which contains the value in the variable called Workbench. This was defined way back in line [4] remember. [42] Creates the Kickstart variable, as above. [43] Deletes the temporary variable Workbench. The variable in ENV: is still available though. [44] Deletes the temporary variable Kickstart. [46] Runs the IPrefs program, which sets the preferences in the Workbench (colours, fonts, background and so on) [48] Starts the console clipboard manager program. [50] This long line defines the various paths which AmigaDOS will use when looking for commands. When you open a Shell and enter a command, AmigaDOS will examine all these directories in this order until it finds the command. [52] to [54] If there is a file called user-startup in the S: directory, exectute it. This means that instead of adding commands to s:startup-sequence, you can add them instead to the file called user-startup. [56] Remove the resident command Execute from memory. [57] Remove the resident command Assign. [59] Load the Workbench! [60] Shut down the (invisable) Shell which has been executing this start-up sequence. Shell-Startup Everytime you open up a Shell window to enter some commands, this script is loaded and executed. The default script is pretty tame: ; $VER: Shell-Startup 40.1 (9.2.93) Prompt "%N.%S> " Alias Clear "Echo *"*E[0;0H*E[J*" " Alias XCopy "Copy CLONE " You can see that it defines the prompt which each Shell will use, and creates two more commands called Clear and XCopy. Clear will clear the window using a sequence of control codes. XCopy is useful for copying entire disks or directories in one go. If you would like to include you own AmigaDOS commands, this is where you define them. Ed-startup As you may know, AmigaDOS comes with its own text editor called ED. ED is a lot smarter than many people realise. By editing this file, you can customise the menus which Ed uses. There isn't space to go into detail now, but take a look at the file and try creating your own designer ED program to impress your mates. PCD This is another script, but one designed to be used as a command. It's based on the AmigaDOS command "CD" which is used to change the current directory. If you use the command in the same was as CD, you won't notice any differrence for example: (ma2.iff) However, when you enter PCD by itself, it returns to the last location you moved to, like this: (ma3.iff) DPAT & SPAT These are two more scripts which can be treated like commands. They are used when you want to perform the same command on multiple files, and although there use is limited (not least because many commands already allow use on multiple files) they can occasionally be very useful. SPAT is a "Single file PATtern" program. It allows you to include wildcards in commands. Wildcards are special symbols which can represent multiple files: #? Means "all files" #?.info Means "all files ending in .info" test.??? Means "all files starting in test. and ending with three letters, e.g. test.doc test.iff and test.bak" Here's an example. Let's say you wanted to examine the version number of a library in the LIBS: drawer, you could do it like this: (ma4.iff) Now if you wanted to do it to all the file in the LIBS: drawer, you might try this. As you can see, it doesn't work. (ma5.iff) That's where SPAT comes in. Use it instead and you'll achieve the original aim. (ma6.iff) DPAT works in a similar way except that it allows you to enter two filenames