A problem that concerns many people when they start letting their children use  
their computers is how to keep the children from destroying important files or  
otherwise wreaking havok on their computer.  Here are some solutions suggested  
by people on misc.kids.computers.  Suggestions for MS-DOS/Windows were  
compiled by Stephen C. Steele, and a more recent copy might be found at
http://qv3pluto.LeidenUniv.nl/steve/reviews/protfile.htm.

Protecting Files under MS-DOS/Windows
	Protecting files under MS-DOS and Windows systems is difficult: both  
Windows and MS-DOS are single user systems that assume a single user who 
should  be permitted full access to all the resources of the computer.
	* Making Backups
	* Marking Files Read Only
	* Program Manager Restrictions
	* Replacement Shell Programs
Note: this is a first draft of this document. Comments, further suggestions,  
and additional information will be gladly received.
	Stephen C. Steel
	reviews@qv3pluto.LeidenUniv.nl

Making Backups
	This is the only absolutely reliable method to protect your data.  
Software can only do so much: it can't guard against a disk crash caused by  
someone flicking the power switch on and off too rapidly, bumping violently  
against the computer, etc. Besides, it will also save your data from your own  
mistakes, lightening strikes on the power line, etc.. If the files are really  
important, especially if you use them to earn your living, then back them up.  
It isn't usually necessary to rush out and purchase a tape drive which can 
back  up your entire hard disk: you can always reinstall your application 
software  from the original media, so you just need to backup the files 
you create with  it. The storage requirements for this are usually much 
more modest: you may  find that a couple of floppies a month is enough. 
This is easier to do if you  keep the files you create separately from the 
application software and its  example files. For example, I keep all my 
data files in subdirectories of  C:\USER\STEVE.  If you configure your 
Windows application icons with the appropriate default working directory 
(using the File|Properties command of  Program Manager), this will be more 
or less automatic. Don't forget to make  backups of important configuration 
files too: CONFIG.SYS, AUTOEXEC.BAT and all  those .INI files in the 
\WINDOWS directory.

Marking Files Read Only
	The read only attribute bit is an underexploited feature of MS-DOS  
that can be quite effective at preventing children from damaging important  
data. If you then limit access to programs that are capable of removing the  
read only attribute, such as the MS-DOS command ATTRIB.EXE and the Windows  
FileManager, the data in these files will be relatively safe: normal programs  
will not be able to delete or overwrite the protected data. There are two main  
difficulties with marking files read only. The first is remembering to mark 
all your work in progress files read only when you're finished working on 
them and then back to normal when you're ready to work again. This can be 
quite tedious  if done manually, although it is much easier if all your data 
files are in one  common directory tree. Then the MS-DOS commands   
cd directory   attrib +R /s *.* can be used to mark an entire directory tree 
read only (or normal if +R is  changed to -R). The second difficulty is 
figuring out which files can be marked  read only without causing problems: 
most applications need write access to some files, and they may crash if 
this isn't enabled. Some DOS programs even expect write access to their 
EXE files in order to store configuration  information. The information in 
files which can't be marked read only can be protected by making a read 
only copy with a different name or in another directory.

Program Manager Restrictions
	There is an optional section to the program manager .INI file that  
allows you to restrict its capabilities. These options do not appear in any of  
the Program Manager menus; they must be added by editing the file PROGMAN.INI  
with an ASCII editor (such as NOTEPAD.EXE). The section must be named  
[restrictions] and the possible entries are :

NoRun  If you include the option NoRun=1, then the File|Run menu entry 	is  
disabled, and it is only possible to run programs from Program 	Manager if  
there is an icon defined in a program group. The NoRun 	option is only  
effective if none of the programs with icons defined can themselves be used  
to start additional programs (such as File Manager, for example).
NoClose    Setting NoClose=1 will make it impossible to exit the 	 
Program Manager, and hence Windows, with the File menu, control menu or  
ALT+F4.
NoSaveSettings     If NoSaveSettings=1, then any changes made to the 	 
arrangement of icons and group windows will not be saved when the 	 
Program Manager exits (regardless of how the Save Settings on Exit menu  
item is set).
NoFileMenu   Setting NoFileMenu=1 will disable the entire File menu of the  
program manager.
EditLevel    Setting EditLevel=n sets the following restrictions on 	 
modifying Program Manager settings:
		o EditLevel=0 allows user to make any changes (the default).
		o EditLevel=1 prevents the user from creating, deleting or 	 
		renaming program groups.
		o EditLevel=2 sets all the restrictions of EditLevel=1, and in  
         			addition, prevents the user from creating or  
				deleting program items.
		o EditLevel=3 sets all the restrictions of EditLevel=2, and in  
         			addition, prevents the user from changing the  
				command lines for program items.
		o EditLevel=4 sets all the restrictions of EditLevel=3, and in  
         			addition, prevents the user from changing any  
				program item properties (although they can 
				still be viewed).

Replacement Shell Programs
	There are a number of these on the market, such as Edmark's KidDesk  
Family Edition for Windows. These programs allow you to limit the applications  
individual users can run. The various users' access can be password protected.  
They have two main weaknesses:  1. They can be bypassed. Booting a computer  
with MS-DOS 5 or later with the left shift key held down will cause it to 
start  up in a simple DOS session, ignoring the contents of the CONFIG.SYS 
and  AUTOEXEC.BAT  files.  2. If you allow your children access to any program 
which writes some sort of data to any filename they specify, then they can 
overwrite your important data files: "Hey Dad, how do you like my new drawing, 
I called it REPORT.DOC".  Although they are not ironclad, the use of a program  
shell in combination with marking important files read only can be quite  
effective (since your children are less likely to need a program that can  
change file attributes than one that overwrite files).

May 5, 1995 Stephen C. Steel  reviews@qv3pluto.LeidenUniv.nl