---WinFold Version 1.0------
By Nick Brown 2005

Winfold is free, however, if you have found this useful then please support the author and make a small donation. To make a donation, please goto www.helpforce.com/winfold

a) Installation
---------------

	In order to install Winfold, please copy both winfold.exe and installer.exe to the desired directory (they must be in the same directory) and run installer.exe . This will associate the required .run files with winfold. Installer.exe can then be removed if you wish.
	Congratulations, you have just installed WinFold!

b) WinFold Introduction
-----------------------

	WinFold is based upon the auto executable directories available on the RISCOS machines of the early 1990s. It is often the case that for a program to run, many files must be transferred in this process. Their are numerous ways of doing this, however, often they require substantial user interaction and can be messy.
	What WinFold does it to compress a directory and its contents, then, when the user runs this it will depack the directory to a temporary one, execute any files required and as the user requires can update the compressed data.

	This application has many many uses, from distributing html, java, complete programs to installing programs and ZIP files.

c) Running WinFold
------------------

	To depack a directory, either double click it, or, open it via the File -> Open menu (available when Winfold.exe is run.)

	To pack a directory, run winfold.exe and enter the directory address under "Input Directory". The Output Name is the file to generate.
	Please see the next section for information about directory commands.


	In order for users to run the winfold directories, they will need to have winfold installed upon their machines, although it will run transparently to them.


d) run.ini File
---------------

	In order to provide some options as to how the system should deal with this compressed directory, a file called run.ini should be generated. In this file is provided details as to what directory to unzip to, default name of the file, file to execute etc...

dir=[dir name]   e.g. dir=c:\    
This sets the directory into which the file should be depacked into. There is a default if this is not specified.

name=[name of directory] e.g. name=hello	
This sets the name of the directory to create. If not specified it is the name of the input file

eg. dir=c:\mytest and name=hello will depack to the directory c:\mytest\hello - if any of the specified directories do not exist (mytest or hello in this case) then they will be created.


run=[filename] 	
This sets which file to run once the directory has been depacked. For more information upon this, please see section (e)

args=[argument]
Supplementary argument to be supplied to the file being run (there can be any number of these)

complete=[delete||copy||both]
This tells the system what to do once the run file (if any) has FINISHED executing (i.e. the system has finished with the depacked directory.)
delete will remove the directory, copy will update the origional packed directory file and both will perform both of these functions.
If NOT specified, then the system will simply do nothing (i.e. the origional packed file will remain unchanged and the created directory will still exist on the computer.)


By default, the system deals with different files in different ways. It makes a distinction between ASCII and Binary files. The settings are internal to the program, however, from time to time, if files come out incorrectly then these might need to be changed. The default settings can be overridden from the run.ini file by the following two commands:

binary=[extension]
Causes the program to treat all files with that extension as binary ones.

ascii=[extension]
Causes the program to treat all files with that extension as ASCII ones.

e) The run.ini run command
--------------------------

	Due to constraints imposed upon JAVA and Windows machine compatability, it might not always be possible to fully execute all required commands from this file. However, there is another way upon which this can easily be achieved.

	In the most part, files can be run via supplying their name under the run=[filename] command and any arguments with args=[argumment] command. If the absolute file path is NOT specified (i.e. run=dir2\me.exe) then the filename shall be internally prefix to the directory in which the temporary unpacked directory is located, as to run it. (Therefore, the creator need not know the actual name or path of the temporary directory.)

	If more complex commands need be executed, then it is suggested that the user creates a batch executable file (.bat) and that they specify this as the runnable file in run=[filename] of the run.ini file. 

	If this is done, then the system will automatically pass to the batch file the base command line (the address of the unpacked temporary directory) as an additional argument, which will be placed as the last argument.

For example, if the user wishes to use notepad to open a text file called me.txt in the base unpacked temporary directory, the command in the batch executable would be (assuming no other arguments have been passed from the run.ini file.)

notepad %1\me.txt			(note: %1\me.txt without the notepad would also be fine)

e.g. 2: There is an HTML file in a directory called "web" which is within the root directory of the auto folder

%1\web\internetfile.html

e.g. 3: You wish to open a normal "my computer" file view to the root directory of the auto folder

explorer %1

e.g. 4: You wish to open a normal "my computer" file view to a dir called "me" within the root directory of the auto folder

explorer %1\me

e.g. 5: You wish for JAVA to run a class file called client.class which is in the root directory

java %1\client

e.g. 6: You know that the directory will be unpacked to c:\temp and the name will be "mytest" (i.e. c:\temp\mytest)

java c:\temp\mytest\client


PLEASE NOTE: Due to the threading involved in explorer and many other webbrowsers, it is impossible to determine when exactly that application terminates. Therefore, for that special type of threading only, the system will NOT update or delete the temporary folder. This is only applicable to that threading type and will not affect the majority of other applications, which do not employ this.

f) Integrity and Security
-------------------------

	There has been special attention paid to the safe operation of this system. There are a number of measures in place which will keep your system as a whole safe. If the directory already exists, then the files will simply be added to it and upon the delete, only the files which are in the compressed directory file will be deleted.

g) Warranty
-----------

	Although every effort has been made to ensure that this is a reliable system, it comes with absolutely no warranty and no responsibility can be taken for any loss or effect caused by the failure of Winfold. The author and/or publisher assumes absolutely no responsibility for it.

	The user is reminded of the need for frequent backups of his/her data and of the fact that the compressed file should not be the only copy of the origional data available.

h) Involvement
--------------

	Winfold was written by Nick Brown, published by Helpforce, all work remains copyright and the property of Nick Brown.
Thanks to Michael Dunn's Shell Extensions tutorials, upon which the install executable is heavily based.

i) Contact
----------

	Any contact about Winfold can be made to the author, via support@helpforce.com