Sign in to follow this  
Followers 0
johnbear

FileInstall() - Dev team recommended limits?

7 posts in this topic

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

Share this post


Link to post
Share on other sites



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.


#include <ByteMe.au3>

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.


This wonderful site allows debugging and testing regular expressions (many flavors available). An absolute must have in your bookmarks.
Another excellent RegExp tutorial. Don't forget downloading your copy of up-to-date pcretest.exe and pcregrep.exe here
RegExp tutorial: enough to get started
PCRE v8.33 regexp documentation latest available release and currently implemented in AutoIt beta.

SQLitespeed is another feature-rich premier SQLite manager (includes import/export). Well worth a try.
SQLite Expert (freeware Personal Edition or payware Pro version) is a very useful SQLite database manager.
An excellent eBook covering almost every aspect of SQLite3: a must-read for anyone doing serious work.
SQL tutorial (covers "generic" SQL, but most of it applies to SQLite as well)
A work-in-progress SQLite3 tutorial. Don't miss other LxyzTHW pages!
SQLite official website with full documentation (may be newer than the SQLite library that comes standard with AutoIt)

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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? :)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0