17 Bit Software 3: The Continuation/17-Bit_The_Continuation_Disc.iso/amigan/amigan 20/syscheck/syscheck.doc

Text File | 1994-01-27 | 7.2 KB | 155 lines

SysCheck                            Jim Butterfield
Checks your boot disk, libraries          22-Aug-88

[Note: The SYSCHECK program enclosed is dated 14 Oct 1988 and
handles the final, issued version of V1.3 Workbench. Dick Barnes]

So there's a new operating system, Workbench 1.3, and you want
to bring some of your working programs into the new system.

So you run through the docs, copying in the updated commands,
libraries and what-have-you.  It's a dirty job, but somebody's
got to do it.  Which commands and other files need updating?
Can't do a straight backup or global copy ... to make room on
working disks, you've had to slice out the unwanted stuff ...
maybe fonts, or the voice-related stuff (narrator, translator).

To help matters along, there are new commands, libraries and
stuff (such as FF, or NEWCON-HANDLER) that you need to add.

SYSCHECK doesn't help you a bit with this dreary job.  But it
might help you check .. to review whether everything is up to
date, and that the things you left off are MEANT to be left off.


SYSCHECK looks through your system libraries, and checks to see
if each item on its list of 96 files is either:

    --Right there and current version (Yay!!!);
    --Missing (OK, if that's what you intended);
    --Not the "current" version (look out!).

Use CLI to call SYSCHECK.  SysCheck is writ in Assembler, and
is pure (Pure what?) so you can make it resident and check four
disks at a time.  If desired.   Syntax:  SysCheck (<device>)

Examples:  SysCheck            scans current directory
           SysCheck DF0:       scans DF0:
           SysCheck RAM:       ..huh?

              ..well, OK on that last one if you REALLY put your
system in RAM: .. but mostly folks would get a lot of MISSING
messages on that one.

   And of course, you could use DF1: or hard disk or whatever
your finanaces or fairy godmother have provided.

Output goes to the screen.  Use redirection if you want it to go
elsewhere, e.g.:
          SysCheck >ram:SCFile df1:
                 You get two reports .. one, as it's going through
the files (alphabetic order, more or less).  This part goes to a
CON: screen, and won't be redirected.  Then you'll get the results:
separate lists of the three categories.

Let's look at the three possibilities:
    --Right there and current version (Yay!!!).  The file matches
the one the program knows.  It could be a brand new 1.3 version;
it might be unchanged since 1.0 (not too many of those around).
In any case, it's up to date as far as SYSCHECK is concerned.
    --Missing (OK, if that's what you intended).  Everybody strips
away the files they don't plan to use.  If you know why this file
is missing, rest easy.  If you missed it due to an oversight, copy
it over.  If it's "new for 1.3", decide if you need it.
    --Not the "current" version (look out!).  Maybe it's an old
version, and you should have updated it.  Maybe it's so brand-new
that this program hasn't heard about it.  Or.. it could be a
"poisoned" file.  Do you know where your disk has been?

Uses of SYSCHECK:
 --checking that a system you've just updated to 1.3 is OK.
 --examining a 1.2 disk, not because you care, but because you're
curious as to what has changed.
 --looking at a "foreign" disk - one you've just received from
someone else - to see if the libraries are up to date.
 --examining new Commodore releases to see if they have slipped
in any changes, and where.

What is Checked:
   Almost everything in the C directory.  Most of L and LIBS, and
some items from SYSTEM and UTILITIES.

What is Not Checked:
   Things that are often customized, such as FONTS, DEVS and S
scripts.  I'm leaving PREFERENCES alone, too, together with the
SYSTEM-CONFIGURATION file.  No point in getting Change messages
when changes will be commonplace and unimportant.
   Watch the "version" title.  Commodore may change things, and the
new versions won't be recognized until SysCheck is updated.
   SYSCHECK does not examine the boot block area.

Computer Vandalism?
   Hopefully, you know now about nerds who vandalize computers
with viruses (virii?) and other horrors.  And you know to use
utilties such as VCheck1.9 to check whether your disks have been
subjected to such brainless damage.  Such damage takes place in
the "boot block".  SYSCHECK will not spot any changes there;
use a good virus checker.
   Seems to me that the next attack of the mutants could be by
changing the CLI commands or the libraries.  It would not take
much brains - only a level of sociopathy - to replace, say, the
DIR command with a "sport" that will delete every tenth file,
and that will copy itself into any new C directory it finds.
   In spotting changes in the system directories, SYSCHECK will
help guard against such practices.  They would be nasty enough
on floppies .. but a hard disk system could be seriously harmed
by such file-fiddling.
   DO look through files such as your S/Startup-Sequence to make
sure you know what all the commands in there are supposed to be
doing.  It would be possible for one of the great Brain-Damaged
to slip something nasty in there.


On the Brighter Side...
   SYSCHECK is not intended primarily as a doomsday-detector.
It is there mostly to help you keep things up to date...
 ...until SYSCHECK itself goes out of date by being succeeded by
revised libraries.

The 1.3 Update...
   So you've gotten the 1.3 system, and are ready to bring your
software into the current generation.  Good for you.  The following
descriptions use the new 1.3 commands, and assume drive DF1:
contains the disk you're checking.  Best to boot up
on Workbench 1.3 (a backup, please!), and then command:
RESIDENT C:INSTALL (and ...C:INFO and ...C:COPY and ...C:DIR and
even ...SysCheck/SysCheck).
   Test your working disk, the one you're about to upgrade, with
INSTALL DF0: CHECK.  A report of a "non-standard boot" indicates
that it's either copy-protected or has acquired a virus; ask for
help on these.  Otherwise, make a backup of this disk.  Now run a
directory of this disk.  Use INFO to see how full the disk is.
Many commercial disks are jammed full, and the new 1.3 files will
often be bigger than the old ones.  You could run out of space
on the upgraded disk; plan for this possibility.

   Run SYSCHECK and update anything marked NOT CURRENT VERSION.
Use the CLONE feature of COPY (new for 1.3) when you do this.
If the disk is nearly full, think of what might be removed:
for example, if this program group doesn't speak, you won't need
LIBS:TRANSLATOR.LIBRARY or L:SPEAK-HANDLER.  If you don't use
fonts, you may be able to junk that whole library, along with
LIBS:DISKFONT.LIBRARY.  Go through the DEVS:PRINTERS libraries
and throw out the printer drivers you don't use (important:  be
sure to update the ones you DO use from the 1.3 disk).

   Another run of SYSCHECK will show all files current, but some
MISSING.  Here's where you have to make hard system decisions.
If you use CLI, be sure to add L:NEWCON-HANDLER and L:SHELL-SEG,
along with C:NEWSHELL and S:SHELL-STARTUP.  While we're in S:
let's look at the Startup-Sequence:  as a minimum, you should
add the new 1.3 title to your existing file.  Snoop the new
Startup-Sequence file for thoughts on further updates; you'll
see that this file has split into two (the second called StartupII).
Use what seems sensible.