Path: utzoo!utgpu!attcan!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!agate!pasteur!ames!ncar!tank!uxc!uxc.cso.uiuc.edu!uxg.cso.uiuc.edu!uxf.cso.uiuc.edu!thompson
From: thompson@uxf.cso.uiuc.edu
Newsgroups: comp.sys.mac
Subject: Re: Virii at the U of I
Message-ID: <46700073@uxf.cso.uiuc.edu>
Date: 3 Oct 88 23:43:00 GMT
References: <20200005@uxh.cso.uiuc.edu>
Lines: 66
Nf-ID: #R:uxh.cso.uiuc.edu:20200005:uxf.cso.uiuc.edu:46700073:000:3273
Nf-From: uxf.cso.uiuc.edu!thompson    Oct  3 18:43:00 1988


/* Written by macman@ethz.UUCP in uxf.cso.uiuc.edu:comp.sys.mac */
>In article <46700066@uxf.cso.uiuc.edu> thompson@uxf.cso.uiuc.edu writes:
>>
>> A program which hooks into the "disk insert" notice in System, like
>>Soundmaster does with its sounds, which automatically runs a
>>virus-masher over the inserted disk. 
>
>The disk-insert detection isn't difficult to implement. The problem
>lies in the User-friendliness and in the program chaining.
>
>First the user-friendliness: Would you be happy if you had to wait for
>one or two minutes each time you insert a disk? What if you're working
>on single-drive units? Your students will make a sit-in strike if they
>have to go through this hassle.

I doubt it.  First, the units are all single-drive SEs with a hard
drive.  In general, students bring their data disks, and then just
sit and work with MacWrite or Microsoft Word or whatever (all
available on the hard drive) on their data disks.  I've noticed
that those who do bring their own APPLs in general install them
on the hard drive while they're working, then delete them later.
Second, they *already* have to queue up at the front of the lab
to get their disks checked by the operator at the "disk-check" station.
This process has not decreased lab traffic noticeably.  I doubt
on-line checking would do so.

>
>The chaining: The Macintosh OS is just not conceived for passing
>parameters on a program startup. The only parameters that you may
>pass are one or several documents with the same owner ID and a
>...
>But it is possible, nevertheless, assuming that both the Disk-insert
>trapper INIT and the virus-tracer are specifically written for each
>other. The application would check on startup if any document of
>any type has been passed as parameter, and use the document's pathname
>as information about the volume to check. The INIT would have to
>trap a disk-insert interrupt and start the tracer program with
>any file (e.g. the desktop file, which is on all disks) as parameter.
>
>-- Danny

What I was thinking was more along the lines of an INIT which simply
passed control to the checker.  Then the checker checks *the internal
drive* with no need for documents or such.  Is there any way to
do this?  Or do I *have* to have a "pathname"?  I've only seen
one problem so far: what to do if a disk is inserted while within
another application.  So how about a check in the INIT -- do this
only if in Finder (can you check that somehow? or maybe link the
thing into Finder itself?)  Something like this would protect
the heavily-used Printer Machines (one per laserwriter, used
only for printing) *much* better than the disk-check station.  And
the other machines would benefit as well.

Unfortunately, I ain't got the time or expertise to do this.  I'm
just learning about programming on the Mac.  And whew!  What a machine!
It'll take me a few years before I'm ready to fiddle with my
Mac's insides via INITs.  And hence the "call".

- Mark Thompson                  "The University Neither Knows Nor
  erstwhile T.A.                  Wants To Know What I Am Saying."
  University of Illinois at U-C

  ARPANET: thompson@uxf.cso.uiuc.edu
  BITNET : thompson%uxf.cso.uiuc.edu@uxc.cso.uiuc.edu
  USMAILNET: 202 E Springfield #3B, Champaign IL 61820