new tool

[polass]

hi all, sorry this isnt really a problem or question, but I could not find the best place to post it (and so thought here would be where it would fit in the best.)

I have written a tool for windows which will turn directories into autorun files - so a single file can be distributed, the user runs it and the files inside, which the author decides are run.

This is based upon RISCOS directories, which allowed this, and I thought i would post and get some feedback on it.

The question i have is, do people think this would be a valuable tool or not? Has anyone got any ideas how I might extend it?

The proggie is 200kb and can be downloaded from http://www.helpforce.com/winfold

Thanks,

Nick

[-pops-]

Welcome to NP.

Sorry if this seems obtuse but, can you explain what this will do for me, a computer user (and builder) who is not into the intricacies of the finer points of Windows or its programming.

[Scarecrow Man]

Sounds strangely similar to a batch file, which is easily created with very little knowledge of DOS.

[polass]

sure, sorry if it wasnt too clear from the initial description

Basically, lets say we web developer has a webpage that they wish to send to people fro r viewing before putting it online. A way could be to zip that, with all the supporting files (images etc..) and send it, then the reciever would have to unzip it, ensure all the paths are correct and load the correct page.

My tool would take the directory (and stucture) of the page and its files, with a command file and compress it into a single distributable. When the user double clicks this, it would depack the contents to a temporary directory (usually not obvious to the user), load the webpage up and once the user had finished with this would delete the temporary directory and if nescesary (if the contents have changed) repack the file... so, all the end user would see ever is one file which all they have to do is double click.

This analogy can be swapped over to many different uses e.g. JAVA class files etc.. - where the key is the user believes they are just dealing with one file, whereas behind the scenes its actually a compressed directory and is being depacked, files are being run and then repacked.

So I suppose put very simplistically, it allows the user to treat a directory as one single file, and when this file is executed, will perform actions to the files inside the directory as specified by the user

[ɹəuəllıʍ ʇɐb]

Sounds to me the same what a self-extracting Zip file does. Except that WinZip is not free, of course :)

I will try it out if I have a few spare moments.

[scuzzman]

Reading through the Manual, it looks pretty useful. I especially like the idea of the custom run.ini file. Would you mind elaborating on how it works? Are there any additional runtimes required (eg: the VB, VC++, etc runtime libs)?

[polass]

I do see the similarity with winzip self extracting zip files, however, these files only allow for the execution of a setup or installation file, not other files of different types, and it is very much a situation of unzipping the file, installing the program if required and then thats it - whereas winfold yes depacks the file, but then it runs any files required and then as required repacks the file and deletes the temporary directory - so in essence for many many executions all the user sees is this one file which they can believe is a single one, but it actually hides a directory structure with possible many files inside.

What I am really aiming at is abstracting the user away from having a program in a directory with its supporting files, and just offering the one file to click, but supplying all the supporting files to this execution, and allowing for the update of this single "executable".

To reply to the other point, the installer was written in Visual C++ and the main winfold.exe in JAVA (and so it requires the JAVA Virtual Machine.)

As far as how it works, the program will take the compressed file, depack it internally, then read the depacked run.ini (finding the target name and directory if supplied - if not then a default is used), it will make the temporary directory with the files and structure in, then will execute the file the user has specified in the run.ini. During this, it "sleeps" and wakes up when termination has finished, to delete the temporary directory and update the single compressed version if required in the run.ini.

The end result being the program(s) required have been executed, they have been given access to their files and if any files have been modified then the origional file will be updated with this, ready for the next execution

I found that this approach was the best way- truth be told I was looking into whether or not the depack system could work on a more "Just in Time" concept, so would depack files when the executing programs required it, but this proved to be too complex (for the first version anyway!)