FileInstall() - Dev team recommended limits?

[johnbear]

Howdy,

A quick question for the dev team - what's the official direction on the limitations of FileInstall, and its intended usage? Eg, "It shouldn't be used for files over **** in size", etc.

The reason I'm asking is that I'm looking at a situation where I might have to have up to 4GB of data bundled into a single AutoIt script using FileInstall, and the data to be included is a single 4GB file. Searching through the forums here, I've found posts indicating that FileInstall was only ever intended to include small files with scripts, and other posts suggesting that FileInstall was expressly designed for including whatever files a user needed with their scripts, regardless of size, etc. The function documentation doesn't include any guidelines.

Thanks,

John

[sleepydvdr]

I'm not an expert by any means, but personally, I wouldn't pack 4 gigs in an executable. If I'm not mistaken, when you run the executable, it is loaded in memory. If the computer doesn't have enough memory to load the file, it can be a problem (most older computers have 1 or 2 gigs - or less). Second, extracting 4 gigs will take some time. And after the files are extracted, each time you run the file, you will load the 4 gig executable every time you run it. It sound a bit ridiculous to me.

I would just include the files in the script directory. Package them in an installer if you want to include everything in one package. The best and easiest installer is Inno Setup. Your program will run much faster this way.

[Tvern]

I'm not a Dev, but I do have some experience with this.

In the past I have tried including installation files in a script that would unpack and then run the installation. Seemed like a good idea at the time, but I quickly moved away from that approach.

I had the following problems when including files. (up to 8GB)

* Building the script takes ages I suspect this was mostly caused by UPX and the fact that the file wouldn't fit in memory, but it's always going to be slow.

* I had to rebuild each time the script was updated.

* I had to rebuild the script each time the included file was updated.

* The above three points also applied for moving the script to my usb drive.

* FileInstall will not return untill it's done, so making a progress indicator is hard. I believe you'd need a secondary process to actually make it work. Best I could do was giving a message saying the program would be unresponsive for a while.

* As the files had to be extracted before being used, the whole installation process got slower.

* Opening large executables was slow on vista, this might be fixed now.

Since then I just throw all reasources in a folder and use them from there, although I have been tempted to give a try as that allows you to use resources without extracting them to a temp location.

[johnbear]

Thanks Sleepydvdr and Tvern.

At the moment we actually don't use FileInstall; instead, we bundle our packages together with the 7zSfx module from Oleg Scherbakov which has been working really well. Unfortunately, we have an upcoming deployment that we may not be able to use 7zSfx for (we need to capture the return code from the AutoIt executable, but the deployment system will only see the 7zSfx return code if we push a 7zSfx wrapped executable), so I was wondering if there was an official statement from the AutoIt developers on usage guidelines for FileInstall when dealing with large amounts of data.

Cheers,

John

[jchd]

Portability is also a concern. A 4Gb executable doesn't work under all Windows OSes. Beyond that, it simply doesn't make sense (at least to me).

The issue about return code(s) seems to be a simple design problem: have AutoIt monitor extraction and its return code and decide from there how to proceed next.

[johnbear]

Portability is also a concern. A 4Gb executable doesn't work under all Windows OSes. Beyond that, it simply doesn't make sense (at least to me).

The issue about return code(s) seems to be a simple design problem: have AutoIt monitor extraction and its return code and decide from there how to proceed next.

Well, for the target platforms I'm working with, all of them support 4GB executables, so for my purposes it's acceptable.

The return code thing is an issue, because this is the layout:

Deployment System > deploys > 7zSfx Wrapper (returns 0) > runs > AutoIT Executable (potentially returns non-zero)

Our deployment system only has visibility of the thing it deploys, which at the moment is our 7zSfx-wrapper executable. It cannot be set up to read changes to the file system or registry, only the return code of the thing it deploys. As a result of the need to capture the AutoIT return code, I'm looking at being forced to go back to using FileInstall(), and wanted to know what the official recommendation from the devs is in terms of usage with large, singular data sets, etc.

Cheers,

John

[AdmiralAlkex]

Can't you deploy files without executing them? Something like this:

1. Deploy archive

2. Deploy script

3. Run script

4. Script does stuff with the sfx/archive

5. Script returns code to deployment system

Unless it must be just 1 file for some reason?